Agile para el desarrollador Solo

• Haciendo un desarrollo guiado por pruebas
• Desarrollando en pequeños sprints
• Al tener mucho contacto con el cliente

Recuerdo haber leído una tesis sobre Cowboy Development, que es esencial para Agile para desarrolladores en solitario, pero no recuerdo dónde lo encontré.

Además de la respuesta de klez (todas las buenas sugerencias), sugiero lo siguiente:

• Mantener un registro de productos
  Una acumulación de productos es básicamente una lista de todos los elementos que pretende completar en algún momento para este producto.
• Mantener una reducción del sprint y una reducción del producto
  La quema de sprint comienza con una lista de todas las tareas que ha decidido completar en este sprint (un subconjunto de la acumulación de productos que se completará en un período de tiempo determinado, por ejemplo, 2 semanas) junto con la estimación del trabajo requerido. Al marcar las cosas, las marcas como hechas; por lo tanto, se reduce (o se quema) el trabajo restante para ese sprint.
  De manera similar, la quema de un producto rastrea el trabajo restante para todo el trabajo acumulado del producto
• Adopción de los conceptos de estimación relativa y velocidad
  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 casi el doble de compleja 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 coherentes entre sí.
  La velocidad es una medida de cuántos "puntos" se realizan en un sprint. Si su estimación relativa es asegurar la consistencia, esta velocidad se puede usar para estimar qué tareas es probable que realice en los próximos sprints. Tenga en cuenta que la velocidad debe revisarse constantemente.

• Limitar el trabajo en progreso (además del tiempo de boxeo). Incluso si usas un método iterativo (a diferencia de Kanban), digamos que tu velocidad es de 8 puntos por iteración. No empieces a trabajar en los 8 a la vez. Limitar el WIP por la cantidad 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.
• Erradiquese por hacer las historias de usuario 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 subestima una historia en Scrum y resulta demasiado grande, varios desarrolladores pueden enjugarla 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 equipo o equipo pequeño, haga el pico sin dudar. Esto ayuda a mantener las historias más pequeñas y más predecibles.
• Las retrospectivas son importantes en ágil en general, por lo que Kanban (que sería Personal Kanban) obtiene puntos extra aquí, porque su proceso retrospectivo está más orientado a los datos. Es difícil jugar Triple Nickels cuando no tienes suficientes personas.

Estas cosas se aplican probablemente a situaciones tanto en solitario como en equipo pequeño (2 o 3 desarrolladores).

AGREGADO: poco después de escribir esta respuesta, encontré esta charla de la conferencia y quedé muy impresionado: Kanban personal: optimizando el codificador individual

• O bien, trabaje en sprints bien definidos, o elija deliberadamente un enfoque Kanban. No termines accidentalmente en Kanban
• Los errores primero, las características segundo.
• Aún manténgase enfocado en el valor vs. (YAGNI sobre Chapado en oro)
• Las retrospectivas son igual de valiosas. Y, lo que es igual de importante, hacer cambios en el proceso en pequeños trozos. No decida que hoy va a comenzar a utilizar TDD, Mock y IoC de una sola vez, a menos que realmente no tenga funciones externas para entregar ATM. Trae uno a la vez.

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

Agile funciona tan bien para los individuos 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 con regularidad, independientemente de si el software está o no "terminado".

Los procesos ágiles son altamente iterativos. El trabajo se realiza en cortos TimeBoxes / sprints / ciclos / iteraciones. Es posible que se requiera algún trabajo de diseño por adelantado, pero se puede refactorizar a medida que aprende más sobre qué es lo que necesita un sistema para hacer. Las pruebas unitarias son la columna vertebral de casi todos los métodos de desarrollo Agile, lo que le da una indicación de si su software está funcionando y si las adiciones / cambios a 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 según corresponda, si construye todo el sistema y ejecuta todas las pruebas con frecuencia, y si entrega el código de trabajo al final De cada sprint, ya eres ágil.

Wow. Intentaría mantener a un amigo en el gancho al que podrí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 trae una solución para mi mente el 90% del tiempo.