¿Cómo planificar grandes proyectos de software?

Question

Hemos comenzado un gran proyecto. Sabemos cómo debe lucir, pero no cómo implementarlo. Comenzamos escribiendo prototipos para probar diferentes implementaciones. Lo que nos falta es la visión general del progreso general del desarrollo. No sabemos si pasamos demasiado tiempo en los detalles o si esos detalles son lo suficientemente importantes como para pasar el tiempo.

Empecé por crear una lista de tareas que tenemos que hacer, cosas como "implementar la característica X", "verificar cómo implementar Y". Ahora tengo un gran mapa mental con aproximadamente 500 tareas. El próximo paso que podría hacer es definir dependencias entre las tareas. De esta forma sabría qué implementar primero y las tareas de las cuales más se depende son las más críticas. Pero no puedo hacer este tipo de pedidos con la herramienta de mapas mentales. Es muy frustrante

¿Cómo planifica grandes proyectos de software?

Answer 1

Esto es lo que me ayudó a empezar:

[1 ] Comience con un documento de requisitos. Escribir desde el punto de vista de los clientes. Escriba todo lo que el software debería poder hacer. Evita dar soluciones. Ser explícito Si una funcionalidad recibirá información, especifique qué es exactamente lo que puede esperar, cuánto debería esperar y cómo debería actuar en situaciones de error.

No olvide especificar los límites. Todo tiene un límite. Si su solución va a administrar cuentas, ¿cuántas debería poder manejar? 20 o 10 millones?

Su documento de requisitos debe incluir requisitos funcionales y no requisitos funcionales. Los requisitos no funcionales son: rendimiento, estabilidad, uso de recursos, seguridad, etc.

[2] Cuando termine de especificar los requisitos, otorgue a cada requisito un puntaje de importancia: debe tener, importante, opcional.

[3] Ahora escribe un documento donde se especifica cómo se llevará a cabo todos los requisito. Ten cuidado con los detalles. No vayas a lo profundo. Ve por la regla 20/80. Especifique el 20% de la funcionalidad en profundidad que afectará al 80% de la solución.

Probablemente notará que no puede describir cómo se implementarán todos los requisitos. Está bien escribir "No tengo ni idea de cómo implementar esto". ¡Pero es importante que lo anotes! La cantidad de "no sabe" le dirá cuán arriesgado es su proyecto.

[4] El siguiente paso es hacer una lista de tareas. Necesitarás saber qué tienes que hacer en realidad. Para cada requisito, tendrá un par de tareas para realizar.

Una de esas tareas es averiguar cómo implementar los requisitos de "no sé". No trates de aclarar cada "no sé". Ve por lo imprescindible y los importantes. Aclarar algunos de los "no sabe" puede incluso ser un proyecto mini sub.

[5] Una vez que tenga sus tareas, estime el tiempo que necesita para completarlas. No seas tímido de estimar. Es imposible estimar con precisión cuando estás al comienzo del proyecto. A medida que el proyecto avance, volverá a estimar las tareas y sus estimaciones serán más precisas.

Me fue muy útil hacer las llamadas estimaciones de tres puntos. Estime el tiempo que necesitará si todo va bien. Este es tu momento optimista. Luego, calcule cuánto tiempo llevará si encuentra problemas. Este es tu tiempo pesimista. Luego estima un tiempo realista. El lapso entre el tiempo optimista y pesimista le dirá cuán incierto es usted acerca de la implementación.

[6] Ahora deberá llevar las tareas en el orden en que serán implementadas. Algunas de las tareas tendrán dependencias que su pedido deberá reflejar. Hay una herramienta muy buena para ayudarlo a visualizar este orden: el muro de su oficina. Escribe tus tareas en post-its y ponlas en la pared. Seriamente. Me funcionó muy bien.

[7] Ahora ya está en el medio de su proyecto. La suma de sus estimaciones le dará dos fechas de lanzamiento (la optimista y la pesimista). Puedes establecer piedras de milla. Actualice las estimaciones de sus tareas periódicamente. El cambio de la fecha de lanzamiento calculada le dirá cómo se está desempeñando.

Answer 2

Haga su trabajo en iteraciones. Concéntrese en lo que es esencial para una iteración en particular. si te centras en todos los detalles al mismo tiempo, fallarás.

En primer lugar, decida qué funciones generales le gustaría tener y diseñe para eso.

En los siguientes pasos agregará más y más características avanzadas.

Cuando tiene una estructura metálica de arquitectura estable, puede dividir el proyecto en módulos y distribuirlos entre varios equipos. Los equipos también trabajarán en iteraciones.

Nadie puede diseñar un gran proyecto de software desde el principio. El enorme proyecto está creciendo lentamente, con todos los problemas infantiles habituales.

Answer 3

Hay una serie de buenos artículos y libros sobre este tema. Pero, en resumen, reduzca las dependencias, mantenga las cosas simples pero flexibles, y comience por escribir componentes rápidamente codificables, esto le brinda una mejor "sensación" de cómo deberá hacer las cosas. Prepárese para que sus diseños evolucionen y se prepare para reescribir un poco de código.

No intente escribir el sistema perfecto desde cero. Establezca para escribir un sistema simplista y es posible que, por accidente, eventualmente termine escribiendo el sistema perfecto.

Answer 4

Un bocado a la vez.

En serio, mirar todo es bueno siempre y cuando no te centres completamente. Tenemos que dividirlo en proyectos cada vez más pequeños hasta que podamos abrazarlo.

Si aún no ha ido de esta manera, cualquiera de las metodologías Agile funciona mejor. Scrum es genial, XP es bueno. Estos usan iteraciones, que están obteniendo pequeños bits de funcionalidad lo más rápido posible.

Tratando de abrazarlo todo es realmente, muy difícil y lo he encontrado extremadamente desmotivante. Pero con una técnica ágil, los usuarios ven el progreso de inmediato y nuestro equipo se emociona porque su código se usa en la vida real.

Answer 5

Todo esto debe provenir del documento de requisitos del proyecto, esto le permitirá saber qué características son en realidad requisitos y qué características se agregaron en el alcance fluencia. Asegúrate de implementar lo que quieren.

Mi consejo siempre hable con la persona a la que necesita entregar el proyecto, elabore un cronograma de cuándo tendrá la función importante x completada por. Averiguar qué se debe hacer es comenzar a través de un documento de requisitos y para prioridades de proyectos grandes (y pequeños) establecidos en qué tarea se debe entregar primero.

Talk talk talk es la mejor manera de asegurarse de que todos sepan lo que está sucediendo en todo momento.

Answer 6

Comience con 1 pieza, desarrolle, perfeccione y aprenda de ella. Una vez que hayas hecho esto, pasa a la siguiente pieza. Al hacer cada pieza, agregue a su biblioteca el código reutilizable. A medida que avanza, el proceso debería ser más refinado, y el tiempo de desarrollo debería disminuir. Lo peor que puedes hacer es desarrollar todo en un enfoque basado en cascada. Consigue algo que funcione y perfeccionalo, esto no solo te permitirá mostrar las piezas de los jefes, sino que también te permitirá encontrar el equilibrio natural entre la planificación y la codificación.

Si desea una forma formal de planificar, recomendaría el desarrollo ágil. Le dará una buena guía sobre cómo planificar sus tareas y ejecutarlas. Pero sigo pensando que un equipo de desarrollo caerá en un ritmo que mejor se adapte y un enfoque gradual lo permitirá.

Answer 7

Obviamente, usted quiere romperla en pedazos más pequeños, recordar al hacer la (Estructura de Desglose del Trabajo) WBS no sólo para dividirla en pedazos más pequeños, pero que también:

• definir qué piezas serán trabajado en la primera (prioridad a la mayoría de los importantes negocios)
• plan de entrega, muchos proyectos de entregar código, pero entonces tendrá un momento difícil en la promoción, planificar cómo cada versión será entregado y los impactos potenciales a los usuarios
• hacer algo temprano/rápidamente - nada genera confianza como una victoria temprana
• desarrolle su plan de comunicación - quién necesita saber qué y cuándo - Por ejemplo: para cada versión iterativa que necesita ser notificado del cambio/impacto
• determine si volverá a evaluar los comentarios durante las entregas para determinar si el orden de entrega o funcionalidad se cambia
• das cuenta de que cuanto antes se libera a la producción cuanto antes se necesita para apoyarlo, así como continuar con el desarrollo