Ponte ágil
Sugeriría lo siguiente:
Editando los mismos archivos
Primero, use Git (o un sistema de versiones concurrente similar). Mientras esté editando diferentes partes de los mismos archivos, no obtendrá conflictos. Si tiene conflictos, se marcarán claramente como tales.
Intentar administrar un proyecto de múltiples desarrolladores sin Git es como intentar hacer un budín sin un tazón de budín. Es posible, pero se volverá bastante complicado bastante rápido.
Como se ha señalado en los comentarios, Git no es una panacea, pero combinado con pruebas automatizadas, sin duda ayuda mucho.
Lista todas las características
En segundo lugar, divida el proyecto en funciones visibles para el usuario. Por ejemplo, "cuando el usuario se registra, debe recibir un correo electrónico" o "El usuario puede agregar un elemento". Involucre a todos los interesados aquí. Pon a todos en una habitación y haz que todos griten sus características.
Estas deben ser características visibles para el usuario, puede hablar sobre la estrategia de implementación más adelante.
Escriba todas las sugerencias en las fichas, incluso las tontas. Racionalice rápidamente la lista para eliminar duplicados y coloque todas las tarjetas en una mesa grande, o incluso en el piso.
Agregue cualquier tarjeta adicional que sea necesaria. Digamos que su aplicación enviará alertas de texto SMS. Es posible que no sepa cómo hacer eso, por lo que tiene una pregunta. Escriba "Investigar portales de SMS" en una tarjeta. Del mismo modo para cualquier otra gran incógnita. Tendrás que desempacar estos más tarde. Estas características probablemente no llegarán a tu primer sprint.
Ahora ordenar las tarjetas en grupos, mezclarlas sobre, obtener una sensación para ellos. Este es el alcance de su proyecto.
Planificación de póker
Intenta planificar el póker. Aún con todos juntos, entregue a todos los desarrolladores tarjetas que digan "1 punto", "2 puntos", etc., hasta "4 puntos". También una tarjeta "más". Un punto es aproximadamente equivalente a una hora.
Ir a través de la lista de características una por una. A medida que lees una característica, todos tienen que jugar una carta. Si una persona juega 1 y otra persona juega 4, hay un problema de comunicación allí. Una persona entiende que la característica significa algo diferente de la otra persona. Discuta y calcule lo que realmente significaba y anótelo en la tarjeta.
Si acepta que una característica es un "más", esa característica es demasiado grande. Tienes que romper esa característica. Haga esto de la misma manera que antes.
Como haya acordado, escriba los números en las tarjetas en un bolígrafo de color diferente.
Los puntos son mejores que horas
El uso de puntos en lugar de horas quita la cosa del macho "mira lo rápido que puedo codificar" en la que los desarrolladores a menudo nos involucramos. Es una diferencia sutil, pero he descubierto que funciona bastante bien.
Ahora componga un sprint
Un sprint es una explosión rápida hacia una meta. Decida la duración del sprint, tal vez 5 o 10 días. Multiplique la cantidad de días por la cantidad de desarrolladores por la cantidad de puntos por día.
Asume inicialmente 6 puntos por día por desarrollador. Este es un número alcanzable. Si tienes 5 personas, eso es 5 * 5 * 6 = 150 puntos. En conjunto con todos los desarrolladores y la administración, seleccione características de la lista, hasta 150 puntos. Ese es tu sprint.
Nunca se sienta tentado a apretar más de lo que cabe. Prometer excesivamente perjudica a todos a largo plazo, incluido usted.
Deberá tener en cuenta las dependencias aquí. Por ejemplo, la configuración del entorno obviamente debe incluirse en el primer sprint. En realidad, esto es relativamente fácil de hacer cuando todos están presentes. Tienes 6 cerebros en la habitación, todos diciendo "esto depende de esto", etc. Luego puedes barajar las cartas para demostrar las dependencias.
Una vez que tiene su sprint, no se le puede agregar nada, está bloqueado durante los 5 días. El arrastre de características estresará al equipo, dañará la moral y ralentizará a todos. Eventualmente, creep detendrá un proyecto. Como líder de equipo, debe proteger a su equipo de la aparición de características. Si llega una nueva solicitud de función, debe agregarse al siguiente sprint. SI el próximo sprint ya está lleno, se debe sacar algo más.
Nunca se sienta tentado a exprimir los extras. Demasiado prometedor le brinda alrededor de 1 día de cliente feliz, seguido de 4 días de estrés en el equipo y, eventualmente, varios clientes descontentos cuando el equipo no puede entregar a tiempo.
Ahora ve a ello.
Entregue tarjetas, pregunte quién quiere hacer qué. Tiene visibilidad completa de lo que se está haciendo, y puede contar los puntos hasta cero. Póngase de pie al comienzo de cada día para que todos sepan quién está trabajando en qué y qué se ha hecho.
5 o 6 desarrolladores motivados decentes que trabajan juntos como una unidad en objetivos manejables claramente definidos pueden lograr una cantidad bastante gruesa de cosas en un sprint de 5 días.
Mantener la visibilidad
Asegúrese de que todos puedan ver cuál es el estado del proyecto. Bluetack todas las cartas a la pared. A la izquierda hay tarjetas en las que aún no se ha trabajado. A la derecha están las cartas hechas.
Cuando un desarrollador está trabajando en una tarjeta, la quitan de la pared y la colocan en su escritorio. Esto mantiene la visibilidad y evita que las personas se pisen demasiado los pies.
Existen alternativas tecnológicas a las tarjetas de índice, pero nada mejor que tener una pantalla de papel masiva del estado del proyecto en la pared.
Si es posible, haga que todos estén en la misma habitación durante la duración del proyecto. Haga que las partes interesadas estén lo más cerca posible, idealmente todos los días.
Quemar
Puede graficar sus puntos progresando hacia cero en un gráfico de quemado. Si su línea de mejor ajuste cruza cero antes de alcanzar su límite de tiempo, es probable que esté encaminado. De lo contrario, es posible que deba informar a su cliente ahora, antes de acercarse demasiado a la fecha límite.
Si vas a fallar, fracasa temprano.
Puedes hacer un burndown usando software, pero prefiero solo un gran trozo de papel en la pared. Dibuja y escribe sobre él.
Pruebas automatizadas
Cuando tienes varios desarrolladores trabajando en las mismas cosas al mismo tiempo, es probable que de vez en cuando rompan el código del otro. La comunicación y la visibilidad ayudan con esto, pero es probable que desee introducir alguna tecnología para ayudar a encontrar problemas.
Las pruebas unitarias son el proceso de escribir pruebas para cada parte individual de su base de código (idealmente, cada método). Las pruebas unitarias deben ejecutarse con frecuencia, con cada salvamento si es posible. Hay muchas herramientas que pueden ayudar con esto, por ejemplo, Karma o Rspec.
Las pruebas de extremo a extremo implican probar su proyecto en su conjunto, tratando las partes internas como una caja negra. Base estas pruebas en sus requisitos empresariales de alto nivel, por ejemplo: "El usuario puede registrarse" o "El usuario puede ver una lista de elementos". Transportador es un buen ejemplo de un marco de prueba basado en web de extremo a extremo.
Hay libros completos escritos sobre las pruebas, pero tener al menos algunas pruebas de aceptación en su lugar puede ayudarlo a asegurarse de que nada se rompa mientras trabaja en su proyecto.
Evitar deudas técnicas y llegar a lo hecho
La deuda técnica es un concepto que describe cosas que tendrán que limpiarse más adelante. Una fuente común de deuda son las características que fueron marcadas como hechas, pero que nunca fueron "hechas". Una característica de hecho está registrado en Git, ha sido aprobada por la parte interesada y tiene una prueba.
No marque sus funciones hasta que estén listas. Nunca masajee el gráfico. Nuevamente, esto perjudica a todos a largo plazo, incluido usted.
Esta es una razón por la cual inicialmente solo cotizamos 6 puntos por desarrollador, por día. Listo-hecho requiere trabajo extra, pero se siente genial y le da un impulso al equipo.