Trabajo en una empresa que ha reducido en varias ocasiones el tamaño de su equipo de desarrollo, hasta el punto de que los equipos anteriores de 10 personas ahora se reducen a un desarrollador por producto (y un par de probadores compartieron entre 5 productos). Solíamos ser bastante pesados ​​en el proceso, después de haber sido una escisión de una empresa más grande, y heredamos su proceso de cascada en varias etapas.

Del equipo ejecutivo se deduce que no estamos lanzando el software lo suficientemente rápido, y que esto es probablemente la culpa del proceso (que puede ser un factor contribuyente, aunque la pérdida del 90% de mano de obra probablemente no ayudó). Ha habido un impulso para que pasemos a un proceso ágil para evitar perder tiempo escribiendo documentos de diseño, etc.

Creo que tengo curiosidad por saber si un cambio a Agile ayudará con los equipos de una sola persona. Entendí que muchos de los beneficios provienen de una mayor visibilidad y una mayor comunicación entre los miembros del equipo, pero sé lo que estoy haciendo y mi gerente también. Ya hago TDD ya que de todos modos no tenemos a nadie para probar el producto.

TL; Versión DR: supongo que lo que realmente estoy preguntando es, ¿puede implementar Agile con 'equipos' de una sola persona, y ve algún beneficio de esto, o es generalmente algo que es más efectivo para equipos más grandes?

Echa un vistazo a https://groups.google.com/forum/#!forum/solo-scrum

y /programming/829497/agile-methods-specífico-taylored-to-working-solo

Actualización:
El primer enlace es al Grupo de Google Solo Scrum. El beneficio más obvio del que se habla aquí es el uso de sprints en cajas de tiempo para administrar el alcance y determinar la velocidad del proyecto, ambas cosas muy buenas.

El segundo enlace es a una discusión previa sobre Stackoverflow, que podría indicar que esta es una pregunta duplicada, pero pensé que sería más útil vincularla. A su vez, se vincula a http://c2.com/xp/ExtremeProgrammingForOne.html, que tiene muchos enlaces e información sobre cómo hacer XP solo (sin programación de pares).

uno

el tamaño mínimo del equipo es uno

Agile es una colección de principios y prácticas, que usted elige para adaptar el flujo de trabajo. Si eres un espectáculo individual, eliges lo que funciona para ti.

XP / TDD funciona maravillosamente para equipos de un solo hombre. Y puede omitir las prácticas potencialmente perdidas de tiempo de las reuniones diarias y la programación de pares.

Su principal problema no es "volverse ágil", sino la documentación. Este artículo sobre la documentación Agile / Lean de Scott Ambler probablemente sea una lectura interesante para usted y sus compañeros de trabajo.

Agile no se trata de no documentar. Todavía documenta, es solo que elige qué y cómo va a documentar para maximizar el valor y minimizar el tiempo dedicado a crearlo. Todavía captura los requisitos, realiza el diseño, documenta sus decisiones de implementación y tiene una trazabilidad completa durante todo el ciclo de vida según sea necesario, pero solo en la medida en que el proyecto lo necesite. No capturar la información y las decisiones clave del proyecto es una forma segura de que un proyecto falle.

Para un pequeño bono divertido, aquí está mi opinión sobre ágil para las personas:

Las metodologías ágiles están diseñadas para equipos. Scrum generalmente necesita entre 3 y 9 desarrolladores junto con un propietario del producto y un Scrum Master (y el propietario del producto y el Scrum Master no deberían ser la misma persona). La programación extrema a menudo requiere de 4 a 7 personas.

La razón es que una serie de prácticas de uso común en las metodologías ágiles convencionales no se reducen a un solo desarrollador. Un excelente ejemplo de esto es el énfasis en la programación de pares y las revisiones de código en XP: realmente no puede hacer esto con un desarrollador en solitario.

Un único desarrollador puede ser ágil, pero tendrá que ser un proceso personalizado. La mayoría de los métodos ágiles requieren una combinación de integración continua, pruebas unitarias, desarrollo basado en pruebas, refactorización, principios KISS y YAGNI, etc. Muchos de estos se han convertido en "mejores prácticas", incluso en metodologías más basadas en planes. No hay razón para que un desarrollador en solitario no pueda aprovechar algunos de ellos, siempre que no interfieran con la producción y entrega de software.

Si desea limitar la documentación, me concentraría en eso si esto lo está frenando. La documentación es solo una parte ágil y no parece que haya nadie en su empresa que sepa cómo implementarla. Esto podría retrasar la liberación de su código a corto plazo debido a la capacitación, la aceptación, el ajuste, etc.

Viniendo de un equipo de un solo hombre (aunque con suerte no por mucho tiempo).

Me esfuerzo por alcanzar Agile para mí en el sentido de que tengo la intención de que sean más desarrolladores que solo yo para futuros proyectos. Escribo un WBS de alto nivel, creo historias de usuarios, tareas bajo historias de usuarios, casos de prueba y mantengo un buen seguimiento de los proyectos de una manera que mi gerente pueda ver y comprender. Puede ser un poco engorroso porque "solo sé" en mi cabeza dónde estoy, pero de todos modos me tomo el tiempo para hacerlo, simplemente para mantenerme diligente con el mítico futuro equipo que me han prometido pero que aún no ha ocurrido. Me gustaría pensar que estoy marcando buenos procesos para las personas que vendrán después de mí.

Documentación que hago en pequeñas cantidades y que es principalmente diagramas de flujo y diagramas de casos de uso, pero generalmente nada de bajo nivel a menos que haya algo realmente complicado o importante al respecto que no quiera olvidar. También hago diagramas de implementación para el beneficio de las personas futuras cuando tienen que lanzar un nuevo entorno para "capacitación" o similar.

Me estoy enseñando TDD lentamente, pero aún no lo he perfeccionado, es extremadamente difícil de hacer en el sentido puro para aplicaciones heredadas sin refactorizar grandes y arriesgadas franjas de funcionalidad. Nueva funcionalidad complicada con la que todavía lucho, pero todavía busco una cobertura del 100%, que es el juego final de TDD después de todo. Sin embargo, es posible que no tome el mejor camino para llegar allí.

Definitivamente se puede hacer, pero por necesidad en su mayoría.

¿Por qué hacer Agile como un equipo de un solo hombre cuando en su lugar puede formar un solo equipo de cinco desarrolladores con una sola cartera de productos para sus cinco productos? Pruebe iteraciones de una o dos semanas y enfóquese en un producto a la vez y vea cómo mejora su productividad con cinco ingenieros trabajando juntos como un equipo cohesivo de autoorganización. Dependiendo de la frecuencia con la que planee lanzar, es posible que deba ajustar la longitud del sprint. Supongo que es posible que la empresa no quiera esperar 10 semanas entre actualizaciones de un producto, en cuyo caso la duración del sprint de 1 semana podría funcionar mejor. Podrías trabajar en dos productos en un solo sprint, pero haría todo lo posible para evitar esto para que puedas concentrarte en un solo objetivo de producto y hacerlo productivamente y con calidad.

OMI, tener una sola persona dedicada a un solo producto es probablemente un enfoque imprudente cuando hay cinco desarrolladores y cinco proyectos en total, independientemente de la metodología elegida.

Muchas prácticas ágiles rinden frutos para los equipos> 0. El control de la fuente y el desarrollo sin fricciones, por ejemplo, y siempre darán resultado, sin importar cuán pequeño sea el equipo.

Esto realmente depende de si hay aceptación desde el lado comercial, o simplemente algo nuevo para que la administración culpe al desarrollo (lo que suena como la situación, basado en la reducción del 90% en el tamaño del equipo). El higher visibility and more communication between team membersno solo significa entre desarrolladores. Es importante que la parte comercial vea a dónde va su tiempo y establezca las prioridades correctas.

Hemos visto un gran aumento en la confianza entre los negocios y el lado de TI de nuestra empresa, porque cada equipo ahora tiene un Propietario de producto que participa en las actividades diarias, y ven a dónde va nuestro tiempo, y son el los que toman las decisiones sobre lo que trabajamos a continuación. En lugar de que los gerentes sean bombardeados constantemente con solicitudes, y luego se culpe al desarrollo cuando las cosas se escapan o no hay suficiente tiempo en el día para hacer todo, ahora son los propietarios del producto los responsables de establecer las prioridades y hacer decisiones sobre lo que se incluye en un sprint.

Entonces, si hay un compromiso de los Propietarios de productos que van a participar en el proceso, entonces sí, el proceso Agile puede ser muy efectivo incluso para un equipo de uno. Pero si esta es solo otra forma de convertir a los desarrolladores en chivos expiatorios, Agile fallará para todos.