Ágil para el desarrollador en solitario

133

¿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 ...

Kelleystar
fuente
77
¡Intenté adoptar la programación de pares como desarrollador en solitario, y mejoró la calidad de mi trabajo!
Wizard79

Respuestas:

66
  • 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é.

Federico klez Culloca
fuente
18
Estoy totalmente en desacuerdo con la afirmación de que el desarrollo "Cowboy" es ágil, incluso para un desarrollador en solitario
Travis Christian
44
@TravisChristian: es más Lone Ranger.
JeffO
99
Aquí hay un enlace a la tesis , que @ a.brookshollar intentó dejar como edición.
Scott Whitlock
66
Apuesto a que ni Travis ni las 11 personas que votaron su comentario han leído la tesis en cuestión. El título completo es "Vaquero: una metodología de programación ágil para un programador en solitario" y, aunque está un poco anticuado, vale la pena leerlo.
Brien Malone
2
El enlace a la tesis está muerto, pero el archivo lo tiene: web.archive.org/web/20150914220334/http://…
Tobias Kienzler
39

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.
Damovisa
fuente
La acumulación de productos, el consumo, la estimación relativa (puntos de historia) y la velocidad son prácticas ágiles esenciales. Ninguno de ellos es específico para la situación de practicante solitario.
azheglov
44
... al igual que TDD, sprints y contacto con el cliente ...
Damovisa
55
sería bueno si también dijeras lo que significa toda esta jerga. Estoy tan perdido como estaba antes de leer esta respuesta ..
Haga clic Upvote
2
@Damovisa: No necesito tus descripciones o una búsqueda en la web, muchas gracias. Describe con bastante precisión algunas prácticas comunes de Scrum. Este es exactamente el punto de partida de la pregunta del OP. Sí, estas prácticas existen, pero están orientadas al equipo, ¿cómo las aplico en la microescala? No hay nada en sus descripciones que sea específico de la microescala.
azheglov
44
@azheglov Wow, no necesitaba causar ofensa. Estaba destacando qué partes de Scrum creo que son más útiles en un escenario de desarrollador en solitario en lugar de cómo aplicarlas. Ninguna de estas técnicas debería cambiar en absoluto para un solo vs un equipo, por lo que se aplicarían exactamente de la misma manera. Para reflejar sus palabras, no hay nada en estas técnicas que sea específico de la microescala.
Damovisa
21
  • 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

azheglov
fuente
9
  • 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".

desaparecido en combate
fuente
3

Á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.

S.Robins
fuente
0

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.

codeyoung
fuente
8
Esa es la MAYORÍA del valor que obtengo de algún lugar, como stackoverflow. No puedo decir cuántas preguntas he escrito y luego no presionar enviar.
Dan Ray el
55
Relacionado: c2.com/cgi/wiki?RubberDucking
Jo Liss
2
El patito de goma es un gran concepto (discutido en las preguntas relevantes aquí), pero ¿cómo responde esto a la pregunta que se hace? "¿Cómo alguien implementaría conceptos de procesos ágiles como desarrollador en solitario?"
mosquito