it-swarm-es.com

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

136
kelleystar
  • 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é.

66

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

  • Mantener una cartera de productos
    Una 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.
  • Mantener un burndown de sprint y un burndown de producto
    Un burndown 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 de El 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
  • Adoptando 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 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" obtienes 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.
39
Damovisa
  • 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, establezca la relación de la historia más grande a la más pequeña 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, duda 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 tanto en solitario como 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: Optimización del codificador individual

21
azheglov
  • 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 el valor vs. (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".

9
MIA

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

3
S.Robins

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

1
codeyoung