¡Mi pregunta favorita para responder! Gracias por preguntar…
TL; DR : No es trivial y depende del proyecto. Pero la estrategia para calcular el costo es relativamente similar.
Hagamos algo de comida para perros y creemos lo que llamamos una Estructura de Desglose del Trabajo (WBS) [1]: algunos pasos pueden o pueden ser aplicables dependiendo de dónde se encuentre en el proceso, pero intentaré dar una descripción general y completa (puede use esta misma técnica para calcular también el costo de su iniciativa de software)
- ¿Cuál sería un buen cronograma con respecto a las áreas de aprendizaje en informática cada semana para convertirse en un desarrollador de software de la industria competente?
- ¿Cuál crees que sería una buena estrategia para superar la escasez de talento para el desarrollo de software?
- ¿Cuál es una buena posición de nivel de entrada para un programador / desarrollador de iPhone?
- ¿Por qué no ves desarrolladores mayores de 40 años?
- ¿Podré encontrar empleo como desarrollador de software junior si completo el campo de entrenamiento en línea Ruby on Rails en la Academia Tealeaf?
- Recopilación de requisitos
- Planificación inicial de alto nivel + discusiones
- Comprensión de los objetivos: qué / por qué estamos haciendo y cómo planeamos llegar allí
- Más discusión / ideación sobre los diversos “cómo” que pueden provenir de #i arriba
- El análisis del retorno de la inversión para ayudar a determinar qué aspectos realmente importan o vale la pena seguir, podría ser formal u orientado a argumentos. Pero lleva tiempo (= dinero)
- Estrechando / limpiando lo anterior
- Volver a reunirse, negociar y priorizar y llegar a un consenso sobre el plan para avanzar
- Desglose más preciso de los requisitos planificados (suponiendo que cada requisito planificado sea una característica épica o mínima comercializable (MMF))
- Tome esos MMF y cree guiones gráficos / diseños / maquetas de UI para mostrar cómo se vería (esto puede haberse hecho en el n. ° 1 anterior y se refinaría aquí)
- Posibles iteraciones múltiples del diseño visual: puede ser arriesgado comenzar el desarrollo demasiado pronto.
- Una vez que los diseños son “bastante estables”, especialmente con respecto a los datos necesarios, haga un desglose del nivel de la historia: ¿cuáles son las historias individuales, rebanadas verticales delgadas de desarrollo / trabajo de características en las que se trabajará?
- Esto podría ser una o tres historias dependiendo del tipo de trabajo:
Front-end, back-end, si el back-end llama al servicio que necesita ser construido, etc., - Ponga las historias en el trabajo atrasado, pero si es posible trabaje primero en las más importantes. No detalle a los demás, excepto aquellos que definitivamente serán trabajados en el próximo mes más o menos.
- Tamaño / alcance discutir las historias más importantes
- Es común tener 1–2 reuniones con algunas de ida y vuelta antes de tener bastante confianza en lo que implica la historia
- Desglose de tareas de las historias (puede ser parte de la misma reunión que #d)
- Aquí se detallan las tareas que uno debe hacer: alto nivel. Ejemplo, construir una biblioteca de mensajería, pruebas de unidad e integración, agregar claves de seguimiento, etc., ya no detalla.
- Puede hacer la estimación de la tarea si lo desea (si es kanban, entonces esto es opcional y también lo es #d. Pero las discusiones aún son buenas)
- Avanzar hacia la implementación:
- Desarrolladores: comience el análisis / codificación relacionado con la historia, estableciendo sucursales u otras cosas necesarias para ser productivo y ofrecer funciones
- QA: si está separado del desarrollador, comience a escribir casos de prueba y configure suites para pruebas.
- Implemente y avance entre dev / QA: la cantidad de trabajo que se puede hacer por unidad de tiempo depende del equipo. Pero si quieres pensar en sprints / puntos de historia, obtendrás una idea aproximada sobre la capacidad. Digamos 2 semanas X puntos de historia.
- Implementación / Prueba : esto supone una forma de canalización de CI / CD que puede implementarse en un entorno de ensayo donde otras personas además de QA también pueden probar / jugar con la aplicación. Estas pruebas están en un nivel diferente que las pruebas de unidad / integración. Debe planificar esta prueba de aceptación.
Luego puede acumular las estimaciones de tiempo aproximado para obtener el tiempo total que cree que tomaría. Inicialmente estarías apagado por [matemáticas] +/- 20x [/ matemáticas] (hablando heurísticamente). Las estimaciones de finalización planificada mejorarán. Solo conocerá los costos reales una vez que se complete el proyecto, hasta entonces, todo serán estimaciones. Una vez que sepa el tiempo, ¡es simple multiplicar el tiempo total por los salarios totales de los empleados para obtener el costo de desarrollo!
… Pero, no es tan simple en la práctica.
Habrá muchas cosas que puede hacer o no para su proyecto, o simplemente hacerlo todo en su cabeza. A veces, solo estimarse es mucho más difícil. De cualquier manera, lo que tendrá son solo estimaciones y nada más.
Cada uno de los pasos anteriores no es tan sencillo en la práctica y se sorprenderá de cuánto tiempo se dedica a toda la planificación y las reuniones, incluso antes de que se escriba una sola línea de código ; no es tiempo perdido, sino tiempo bien empleado para asegúrese de que no comencemos a piratear cosas que no importan.
Existen varias técnicas para la estimación y sugiero encarecidamente los libros fenomenales:
- Estimación de software: desmitificar el arte negro [2]
- Return on Software [3]: el libro que le muestra cómo calcular el costo del software y analizar el ROI, todo en términos monetarios.
- Software Engineering Economics [4]: un clásico seminal sobre varios enfoques para comprender lo que implica el desarrollo de software y las formas de planificar con esa economía. Toneladas de estimación también, un poco anticuadas, pero aún relevantes
- Estimación y planificación ágiles [5]: cómo funciona la planificación y la estimación livianas para ayudar a medir el costo del desarrollo de software
Estimación de la mejor de las suertes: es una gran pregunta para responder, pero al final solo sabrás cuán acertado (o incorrecto)
Notas al pie
[1] Estructura de desglose del trabajo – Wikipedia
[2] Estimación de software: desmitificar el arte negro
[3] Retorno del software
[4] Economía de la ingeniería de software: Barry W. Boehm: 0076092033097: Amazon.com: Libros
[5] https://www.google.com/url?sa=t&…