Ágil para el desarrollador en solitario

¿Cómo alguien implementaría conceptos de procesos ágiles como desarrollador en solitario? Agile parece útil para desarrollar aplicaciones a un ritmo más rápido, pero también parece muy orientado al equipo ...

• Al hacer un desarrollo basado en pruebas
• Desarrollándose en pequeños sprints.
• Al tener mucho contacto con el cliente

Recuerdo haber leído una tesis sobre Cowboy Development, que es esencialmente ágil para desarrolladores en solitario, pero no recuerdo dónde la encontré.

Además de la respuesta de klez (todas buenas sugerencias), sugeriría lo siguiente:

• Mantenimiento de una cartera de productos La cartera de
  productos es básicamente una lista de todos los elementos que tiene la intención de completar en algún momento para este producto.
• Mantenimiento de una carga de sprint y una carga de producto
  Una carga de sprint comienza con una lista de todas las tareas que ha decidido completar en este sprint (un subconjunto de la cartera de pedidos de su producto que se completará durante un período de tiempo establecido, por ejemplo, 2 semanas) junto con La estimación del trabajo requerido. A medida que marca las cosas, las marca como hechas; reduciendo así (o quemando) el trabajo restante para ese sprint.
  Del mismo modo, una carga de producto rastrea el trabajo restante para toda la cartera de productos.
• Adopción de los conceptos de estimación y velocidad
  relativas La estimación relativa es una técnica de estimación que utiliza las otras tareas (o historias) como guía. Por ejemplo, si sabe que la tarea A es más fácil que la tarea B y tiene el doble de complejidad que la tarea C, se aseguraría de que los "puntos" para la tarea A fueran correctos en relación con esas expectativas.
  El énfasis no está en adivinar correctamente la cantidad de trabajo requerido, sino en mantener las estimaciones consistentes entre sí.
  La velocidad es una medida de cuántos "puntos" logras en un sprint. Si su estimación relativa es garantizar la coherencia, esta velocidad se puede utilizar para estimar qué tareas es probable que realice en los próximos sprints. Sin embargo, tenga en cuenta que la velocidad debe revisarse constantemente.

• Limite el trabajo en progreso (además del tiempo de boxeo). Incluso si utiliza un método iterativo (a diferencia de Kanban), supongamos que su velocidad es de 8 puntos por iteración. No empieces a trabajar en los 8 a la vez. Limitar WIP por el número de historias o puntos de historia está bien.
• Realice pruebas de aceptación automatizadas para todas sus historias de usuario. Automatiza todo lo que puedas en general.
• Errar al hacer que las historias de los usuarios sean demasiado pequeñas. Como regla general, haga que la proporción de la historia más grande a la más pequeña sea 3: 1 . Si subestimas una historia en Scrum y resulta demasiado grande, varios desarrolladores pueden enjambrarla para volver a encarrilarla. Pero no tienes suficiente gente.
• Si, en un contexto de equipo de tamaño regular, dudaría si dividir un pico de una historia de usuario, en el contexto de un solo o de un equipo pequeño, haga el pico sin dudarlo. Esto ayuda a mantener las historias más pequeñas y más predecibles.
• Las retrospectivas son importantes en agile en general, por lo que Kanban (que sería Kanban personal) obtiene puntos extra aquí, porque su proceso retrospectivo está más basado en datos. Es difícil jugar Triple Nickels cuando no tienes suficientes personas.

Estas cosas se aplican probablemente a situaciones en solitario y en equipos pequeños (2 o 3 desarrolladores).

AGREGADO: en algún momento después de escribir esta respuesta, encontré esta charla de conferencia y quedé muy impresionado: Kanban personal: Optimizando el codificador individual

• Trabaje en sprints bien definidos o elija deliberadamente un enfoque Kanban. No termines accidentalmente en Kanban
• Errores primero, características segundo.
• Todavía manténgase enfocado en Valor vs. hinchazón de características. (YAGNI sobre chapado en oro)
• Las retrospectivas son igual de valiosas. E igual de importante, realice cambios en el proceso en pequeños fragmentos. No decida que hoy comenzará a utilizar TDD, Mock e IoC de una sola vez, a menos que realmente no tenga características externas para entregar cajeros automáticos. Trae uno a la vez.

En última instancia, defino a Agile realmente como "hacer lo que tiene sentido para su equipo y cliente y no adherirse a las prácticas antiguas porque parecían funcionar en el pasado".

Ágil funciona tan bien para las personas como para los equipos. Se trata de encontrar un proceso que funcione para usted y permitirle adaptarse a las circunstancias cambiantes una vez que su proyecto ya haya comenzado. También se trata de entregar valor a su cliente regularmente, independientemente de si el software está realmente "terminado" o no.

Los procesos ágiles son altamente iterativos. El trabajo se realiza en cortos TimeBoxes / sprints / cycles / iterations. Es posible que se requiera un trabajo de diseño por adelantado, pero se puede refactorizar a medida que aprende más sobre qué es lo que necesita que haga un sistema. Las pruebas unitarias son la columna vertebral de casi todos los métodos de desarrollo ágil, ya que le indican si su software está funcionando y si las adiciones / cambios en su software romperán la base de código existente.

Si se adhiere a BDD / TDD, permita que sus requisitos cambien con el viento y pueda ajustar las prioridades de sus características en consecuencia, si construye todo su sistema y ejecuta todas las pruebas con frecuencia, y si entrega un código de trabajo al final de cada sprint , ya eres ágil.

Guau. Intentaba mantener a un amigo al teléfono al que podía llamar cuando estaba en problemas, y hablar sobre el problema de codificación. Sabes a lo que me refiero ... solo el hecho de explicar un problema en voz alta me trae una solución el 90% del tiempo.