Planificación a largo plazo y ágil?

Mi equipo recientemente pasó por el proceso de diseñar un plan de casi un año para nuestro trabajo. Separamos el plan en tres fases. Cada fase incluirá un par de lanzamientos.

Me pregunto, desde un punto de vista ágil, ¿está mal? Creo que no es una mala idea, porque no hemos pasado demasiado tiempo diseñando nada más que los primeros pasos. Es posible que cambiemos de dirección. Al mismo tiempo, es bueno que no actuemos solo a corto plazo.

Tener una visión de hacia dónde va el proyecto es un Good Thing ^TM .

Creer que eso es precisamente lo que sucederá no lo es.

"Al prepararme para la batalla siempre he descubierto que los planes son inútiles, pero la planificación es indispensable".

-- Dwight D. Eisenhower

El enfoque que adoptan las metodologías ágiles es descomponer las cosas en piezas digeribles y reajustar la visión después de que cada pieza haya sido digerida.

Eso significa que su punto final en un año a partir de ahora no será exactamente lo que ahora piensa que es. Sin embargo, debería haber abordado todos los elementos de alto valor en su lista y haber mantenido a sus partes interesadas comprometidas y felices a medida que avanza.

OK, a la gerencia se le ha presentado un mito para planificar. Espero, por tu bien, que no te retengan. Porque, sin ser visto, estoy dispuesto a apostar dinero a que su equipo no logrará nada como lo que dice ese plan a largo plazo. De hecho, si alcanza el promedio de la industria, perderá aproximadamente un factor de 2. Y en la mayoría de las organizaciones, una estimación, una vez dada, se convierte en el club en el que son libres de vencerlo todo lo que quieran.

Probablemente pienses que solo estoy siendo cínico. Después de todo, acaba de comunicar tiempos imprecisos para conjuntos de características no especificadas que todos saben que podrían ocurrir mucho más lento o más rápido de lo previsto, ¿verdad? Lo sentimos, la mayoría de eso puede ser cierto, pero no es así como la gente tiende a escuchar esos números. Han escuchado fechas, y una fecha una vez que se habla tiende a escucharse como más sólida de lo que dijiste que era. Además, si hay una cadena de comunicación, se volverá aún más sólida. Y una vez que las ventas hayan prometido algo a los clientes externos según lo que usted dijo, de repente descubrirá que hay mucha menos flexibilidad en esos números de lo que debería haber. Y te garantizo que has subestimado el tiempo que tomarán las cosas.

Con ese punto obvio fuera del camino, te recomendaré que leas Estimación de software para aprender algo sobre cómo se debe hacer realmente la estimación de software . Aprenderá mucho sobre lo que hizo mal y cómo hacerlo mejor la próxima vez. (En el proceso aprenderá por qué estoy tan seguro de que sobreestimó lo que hará).

Dicho esto, ágil se trata principalmente de reducir el proceso a lo que es apropiado para un equipo pequeño. Con frecuencia, una buena forma de reducir el proceso es tratar de reducir la planificación a largo plazo a gran escala a favor de planificar cosas más pequeñas a corto plazo. También tiende a ser más honesto, porque no sabes lo que sucederá en el futuro. Sin embargo, eso a menudo no se ajusta a las necesidades comerciales más grandes, por lo que, independientemente de si se declara ágil, a veces necesita establecer planes más largos.

Dicho esto, le recomiendo encarecidamente que descubra un hecho clave sobre las fechas que ha comunicado, que desafortunadamente es probable que vuelvan como plazos para morderlo. Y ese hecho es este. ¿Qué le importa a la gente, la fecha o el conjunto de características? Esto es lo que quiero decir con eso. Con frecuencia, las organizaciones tienen fechas específicas que importan. Por ejemplo, hacer algo para una conferencia o antes de las vacaciones. En ese caso, lo que importa es liberar algo, y no tanto si ese algo está completo. Otras veces hay un conjunto de características que realmente necesitan ser lanzadas juntas, y la integridad es más importante que cuando sucede exactamente. Si puede descubrir en qué situación se encuentra, su equipo estará en una posición mucho mejor para planificar cómo manejar los (casi) inevitables problemas que se avecinan.

Está bien tener un plan siempre y cuando lo consideres trabajo en progreso y no algo escrito en piedra.

La clave aquí es hacer lanzamientos regularmente (al menos mensualmente), recopilar comentarios reales de sus usuarios y actualizar su plan en función de esos comentarios.

Esto significa que su plan cambiará cuando cambie el alcance del proyecto. Esto es algo bueno , porque significa que sus usuarios han aprendido más sobre lo que quieren.

Suponiendo por project-managementy agileque significaba Scrum, esto no sería la forma más exacta para ir.

En la Scrumperspectiva, si tienes un plan de un año, al menos deberías tener tantos Sprints como meses en un año. Por lo tanto, su plan de un año se está volviendo más ágil, ya que es cambiante entre dos Sprints.

A no Sprintpuede ser más de un mes, donde el se Teamcompromete a llevarlo Sprint Backlog Itemsal estado de Done.

Donees una palabra importante aquí, y cada uno de los Scrum Teamdebe tener una definición de hecho, es decir, donde no queda trabajo por hacer. Cuando una Sprint Backlog Itemestá Listo , esto significa que la documentación de análisis, la arquitectura y la técnica está escrito, y que la función ha sido probado a fondo (pruebas unitarias, pruebas de integración, pruebas funcionales ...).

Una vez que Product Backlogestá en su lugar, y los Elementos priorizados con características menos importantes en la parte inferior, y los más importantes en la parte superior, el Equipo (de desarrolladores) determina cuánto tiempo debe Product Backlog Itemllevar el desarrollo de cada uno en función de su propia experiencia. Ahí es donde puede determinar que el proyecto requerirá un año completo de trabajo. Considere que solo elProduct Ownerpriorizará los Artículos, ya que es él quien es responsable del retorno de la inversión, o de lo contrario, sabe qué es lo más importante para el usuario final. Además, el Equipo evaluará el tiempo requerido para desarrollar completamente una característica, aunque podría haber piezas de código reutilizables aquí y allá que puedan adaptarse a las necesidades de esta característica, es decir, para evitar una mayor complejidad y asegurarse de que un Artículo no tome más de lo que el Equipo dijo que requeriría. ¡La cartera de productos no necesita ser perfecta! La simple enumeración de historias de usuarios que podemos pensar en el sistema a desarrollar es suficiente en ese paso del proceso.

Es durante el Sprint Planning Meetingque el Equipo se comprometerá en lo que se desarrollará para el próximo Sprint, creando así el Sprint Backlog. La Sprint Backlogconsiste en un subconjunto basado en la Product Backlog Itemsque los Teamcompromete a hacerse al final del Sprint. Teniendo en cuenta, por ejemplo, una acumulación de productos de 50 elementos, y todos los 50 elementos requerirán un año para completarse, entonces el equipo podría seleccionar, digamos 5 elementos de la cartera de productos, y crear la reserva de Sprint con estos 5 elementos. Estos mismos 5 artículos pueden expandirse / explotarse en varios otros artículos cuando sea necesario, lo que hace que el equipo cambie de opinión después de la revisión y se comprometa a hacer solo 4 artículos de los 5 artículos seleccionados previamente de la cartera de productos.

Una vez que finaliza la reunión de planificación de Sprint, que no puede durar más de 8 horas durante un mes completo de Sprint, dentro del cual el equipo no solo se compromete a hacer el trabajo para los elementos seleccionados, sino que también planea cómo hará el trabajo. para que todos en el Equipo sepan exactamente lo que tiene que hacer, Sprintcomenzará. Es importante que el equipo sea multifuncional por el bien del proyecto.

Dicho esto, al final de cada Sprint, que dura un mes en la situación actual, todos los Artículos que se Teamcomprometieron a hacer serán una pieza entregable de características completamente funcionales dirigidas a los Artículos seleccionados de la Lista de Producto. Tiene que ser entregable, pero no es obligatorio que se entregue si no tiene sentido hacerlo de acuerdo con el Product Owner.

Es durante el momento Sprint Review Meetingen que Product Ownerse requiere que se convoque que Teamdemuestra lo que se hizo durante el Sprint, y donde necesita decir por qué no ha realizado, si corresponde, todo el trabajo al que se comprometió. El trabajo deshecho se vuelve a colocar en el Product Backlogy está disponible para el siguiente Sprint. Asegúrese de que estos artículos deshechos se incluirán en el próximo Sprint a menos que el propietario del producto indique lo contrario, en caso de que el objetivo haya cambiado. Pero lo más importante, aunque el objetivo de un sistema cambió durante un Sprint, no lo interrumpa a menos que sea absolutamente necesario. Solo el propietario del producto tiene la autoridad para interrumpir el Sprint.

Una vez Sprint Review Meetingque termine, que no debería durar más de 4 horas para un Sprint mensual (si no recuerdo mal), es hora de llegar al Sprint Retrospective Meeting. El Sprint Retrospectiveresulte necesario a los Teamque ocurren de manera que pueda discutir, en presencia del Scrum Master y el propietario del producto (opcional) lo que salió mal, cómo el Equipo Scrum puede mejorar su rendimiento, etc. y llevar los ajustes necesarios.

Cuando Sprint Retrospectivese acabe el tiempo para el , Sprint Planning Meetingse producirá lo nuevo para planificar el siguiente Sprinty crear el nuevo Sprint Backlog.

Recuerde, el Teamresponsable es mantener la Daily Scrumreunión de 15 minutos en la que cada miembro del equipo responde las tres preguntas (no en ese orden en particular):

1. ¿Qué has hecho desde el último Daily Scrum?
2. ¿Qué planeas hacer hasta el próximo Daily Scrum?
3. ¿Cuáles son los problemas o impedimentos que encontró desde el último Daily Scrum?

El Scrum Masterno es obligado a estar allí, pero se requiere para asegurar que el Equipo se reúna en el Daily Scrum y que los Miembros respondan las tres preguntas correctamente.

Scrum Master es responsable del respeto de las Reglas de Scrum por parte de los demás miembros del equipo Scrum (Scrum Master, propietario del producto y equipo).

Al final, siguiendo estas simples reglas, su equipo de desarrollo se volverá ágil. La agilidad es la capacidad de ponerse al día con cualquier cambio tan rápido como pueda el Equipo, es decir, al final de cada Sprint, donde puede conocer los cambios introducidos por el Propietario del Producto en el Backlog del Producto. En caso de un desastre total y un cambio completo de orientación, la pérdida máxima que la empresa tiene que absorber es un mes de desarrollo, lo cual es bastante descuidado, teniendo en cuenta que solo hay aproximadamente 20 días hábiles en un mes.

Si necesita más información detallada sobre Scrum y el desarrollo de software ágil, consulte Scrum.org y su Guía de Scrum .

Bueno, esa es una gran respuesta! Espero que esto al menos lo ayude a través de la gestión de su proyecto.

EDITAR # 1

Mientras planea hacer tres o cuatro fases, como lo llama, es más probable que su equipo pierda el enfoque desde el punto de vista objetivo primario. Si demuestra después de solo el primer trimestre lo que ha hecho su equipo, puede haber algunos cambios importantes para traer que requerirán un rediseño importante y un replanteamiento de la arquitectura de su software, reanudando tal vez más de 20 días de trabajo perdido. El principio de agilidad es poder ponerse al día con los cambios tan pronto como ocurran, o tan pronto como sea posible dentro de un período de tiempo razonable, es decir, para Scrum, la caja de tiempo de un Sprint.

1. Creo que deberías tener tantos lanzamientos como puedas. La única retroalimentación / métrica real para el progreso en el desarrollo de software es el código implementado en producción. Entonces, sea cual sea el proceso que use, cuanto más a menudo implemente en vivo, más ágil será. Es decir, obtienes comentarios reales de usuarios reales antes y puedes adaptarte antes.

2. Si bien no deberías hacer Big Design Up Front , creo que es bueno pensar en el panorama general cada vez que estás a punto de ajustar y reponer la acumulación, tanto para Scrum (para el próximo sprint) como para Kanban / flow (cuando hay espacio en el límite de WIP). Si considera el conjunto (producto, servicio, etc.), es más fácil considerar qué elementos de trabajo le darán más valor a continuación.

3. Tenga en cuenta que el panorama general cambia. Tan a menudo como considere la acumulación, el ajuste de prioridades, etc., también considere los cambios en el panorama general. Las cosas cambian con el tiempo, incluidas las necesidades de clientes específicos e incluso mercados enteros. Su panorama general debe reflejar esto para que sus prioridades puedan alinearse con la realidad cada vez que reponga el trabajo atrasado, y no solo al comienzo cuando haga el plan.

En resumen, creo que se vuelve más ágil cuanto más inspecciona y se adapta.

La planificación del panorama general no toma tanto tiempo, y es crucial para los grandes proyectos tener el panorama general en mente cuando define sus sprints, de lo contrario, los atajos tomados en un sprint pueden crear problemas más adelante.

Debieras:

1. Tenga un plan maestro (preferiblemente sin fechas límite adjuntas), que evolucionará a medida que avance.

2. Cuando define un sprint, se asegura de que el sprint sea consistente con el panorama general. Esto no siempre significa que cambie su idea de lo que se desea para el sprint. A veces descubrirá, al definir un sprint, que su imagen general debe ajustarse. De una forma u otra, el plan general y el sprint deben ser consistentes entre sí al entrar al sprint.

3. El plan maestro debe ajustarse a medida que avanza. Aprenderás cosas mientras trabajas. Surgirán nuevas oportunidades, surgirán puntos de conflicto en el plan. Puede ajustar el plan maestro sobre la marcha, a medida que avanza. Pero casi siempre debes volver a visitarlo entre sprints, para incorporar las lecciones del último sprint y asegurarte de que el próximo sprint esté en armonía con el panorama general.

Creo que es mejor si el trabajo atrasado y el plan del gran proyecto son estructuras separadas. El propietario del gran proyecto mantiene el plan maestro en un formato de esquema jerárquico para mantener el contexto, y luego las características / tareas se pueden extraer de él para alimentar el trabajo atrasado, lo que, a su vez, alimentará el próximo sprint.

El backlog, a diferencia del plan maestro, puede ser agregado por otros miembros del equipo. Depende del propietario del proyecto principal asegurarse de que los elementos de la cartera de pedidos y el plan general se mantengan en armonía, a veces ajustando el elemento de la cartera de pedidos y, a veces, el plan general.

Este método mantiene el poder de la agilidad y el poder de alinear todos los elementos de su proyecto lo mejor que pueda en un momento dado a través de la planificación general.

Jim

Agregaré la forma corta de mi diatriba anti-Ágil aquí.

Agile puede ser muy destructivo para grandes proyectos, especialmente cuando se construyen bibliotecas y marcos que serán fundamentales para el desarrollo futuro. Una preocupación realmente importante en las primeras fases es "¿mi diseño admitirá las características que necesitamos entregar durante el próximo año?". La mayoría de las estrategias ágiles no permiten ese tipo de visión de futuro y, por lo tanto, se crean puntos de falla del proyecto.

Estoy un poco adolorido en este punto porque me acabo de quemar. Estamos reescribiendo algunas de nuestras bibliotecas principales. Las primeras fases se realizaron y cumplieron los objetivos de características para sus sprints. Todo es muy ágil. Luego, me incorporaron para agregar algunas características de carga dinámica. Sin embargo, estuve estancado unas seis semanas porque lo que se escribió antes suponía que nunca habría una carga dinámica, perdí mucho tiempo reescribiendo y trabajando en lo que ya estaba allí. La peor parte es que la carga dinámica estaba en las especificaciones al principio; Si el trabajo inicial tuviera en cuenta todos los requisitos futuros y realizara el 'gran trabajo de diseño por adelantado' que las prácticas ágiles consideran malo, podría haber implementado mi función en unos pocos días.

La lección es usar agile para cosas pequeñas que estás dispuesto a tirar. Puede ser genial a veces. Sin embargo, no es la única forma verdadera de desarrollo de software. Al escribir código fundamental que sea de alto riesgo o que tenga una larga vida útil, haga el gran diseño.