Estoy probando Scrum en un pequeño proyecto de una sola persona. Durante mi primer sprint, me di cuenta de que todas las historias que elegí son realmente épicas y deberían dividirse en partes mucho más pequeñas. El problema es que he elegido muy pocos puntos de historia, es decir, dividir significaría que tengo historias de .25, .1 puntos de historia de las epopeyas originales.
Mi instinto me dice que rompa las epopeyas después del sprint y vuelva a estimar. Dado que este es el primer sprint, no estropeará los datos históricos y me permitirá comenzar desde cero.
¿Qué piensas?
Antes de responder, debo señalar que realmente odio la estimación y la velocidad de Scrum como se hace tradicionalmente, por lo que si bien esto puede darle algunas ideas, siéntase libre de adaptar su proceso existente en consecuencia.
La razón por la que tienes que dividir las "epopeyas" en historias y características más pequeñas es porque no encajan en la caja de tiempo de un sprint. Solo hay algunas razones para estimar y usar timeboxes:
Obtener comentarios de las partes interesadas
No necesita desglosar las cosas para obtener comentarios, si solo se está enfocando en hacer algo que obtendrá los comentarios de las partes interesadas. Elija cualquier cosa sobre la que crea que podría necesitar comentarios, luego haga que algo funcione y hágalo cada vez más realista dentro del marco de tiempo (¡y si puede recibir comentarios temprano, mucho mejor!) Por ejemplo, codifico una interfaz de usuario y se la muestro a alguien, luego lo hago funcionar con un mapa hash en la memoria, luego lo acoplo a las capas de persistencia y luego a la base de datos ( cuando los usuarios son las partes interesadas que pueden darme su opinión, de todos modos).
Conseguir la confianza de las partes interesadas
Si sus partes interesadas no confían en usted, concéntrese en entregar algo valioso . Es posible que deba dividir sus "épicas" para hacer eso, pero este debería ser su enfoque, en lugar de "hacer algo dentro del sprint". Si este es el caso, elija cosas pequeñas y seguras que pueda hacer fácil y rápidamente, porque su relación con la parte interesada es probablemente el mayor riesgo. Una vez que te hayas ganado su confianza, puedes comenzar a probar las cosas difíciles y obtener sus comentarios.
Planificación del lanzamiento y ajuste del alcance
Si desea ajustar el alcance en función del historial, siempre puede hacerlo con las estimaciones "épicas" originales. Estas son estimaciones, por lo que es probable que sean incorrectas; no puede usar una pequeña muestra de ellos para predecir el futuro, por lo que es probable que el ajuste del alcance sea continuo y se reduzca a medida que se acerca el lanzamiento. (Idealmente, está creando un Producto mínimo viable y lo lanza de todos modos, por lo que este punto es discutible).
Descubrir la incertidumbre y la incomprensión
Si está utilizando estimaciones para descubrir malentendidos, es posible que aún se pierda algunos. Sugiero hablar con ejemplos de cómo podría funcionar la aplicación, a la BDD.
Dividirlos como y cuando
En lugar de centrarse en tener historias lo suficientemente pequeñas para un sprint, puede que le resulte más útil centrarse en las razones para tener el sprint en primer lugar. Sea lo que sea en lo que te encuentres trabajando como resultado, ponlo en la pizarra y la vida será mucho más fácil, con reuniones de planificación más cortas.
Puede ser útil si determina si sus "épicas" son capacidades (proporciona la capacidad de comerciar con cobre, por ejemplo) o características (una de las muchas interfaces de usuario potencialmente concretas que brindan la capacidad). Dividir las capacidades en características y tener algunos esquemas esbozados antes del sprint está bien en mi opinión. Después de eso, deje que el equipo de desarrollo divida las historias como mejor les parezca, según los principios anteriores. Esto también lo ayudará a obtener un equipo autoorganizado y le da al equipo un enfoque claro para cada período de tiempo.
Craig Larman me dijo que la razón original de los sprints de un mes era porque en realidad podías concentrarte en lanzamientos pequeños, con solo los diferentes MVP priorizados por el negocio. La retroalimentación estuvo disponible todo el tiempo, y cuánto se podía lograr y publicar dentro de ese mes dependía completamente del equipo de desarrollo. Creo que esta visión original de Scrum se ha corrompido y se echa mucho de menos.
Si está pensando en dividir sus historias en tareas, lea esto también.
Las épicas siempre se dividen en partes más pequeñas, antes de comenzar el sprint. Trate de concentrarse en entregar valor (pedido por el cliente y también importante), así que no se moleste con sus datos históricos. Si la epopeya es lo más importante, divídala y comience a trabajar en ella. Después de un par de sprints, tendrás suficiente experiencia y datos para establecer la velocidad y usarla.
No vuelvas a planificar un sprint completo. En cambio:
Trate las anomalías de datos como tales y no permita que su marco Scrum gire en torno a puntos de datos que no pretenden ser mandatos estrictos o predicciones infalibles.
Durante mi primer sprint, me di cuenta de que todas las historias que elegí son realmente épicas y deberían dividirse en partes mucho más pequeñas.
Si es su primer sprint, todavía está aprendiendo a estimar historias y a estimar su propia capacidad, por lo que es de esperar errores de estimación. Sin embargo, en tu caso particular, tienes dos opciones:
Se trata menos de la asignación de puntos de la historia que de decidir si ha estimado correctamente su capacidad para el sprint. Si crees que puedes hacer suficientes historias para alcanzar tu Sprint Goal, pruébalo.
Scrum no requiere perfección; solo requiere que inspeccione y adapte, y falle temprano cuando la falla sea inevitable. Si puede ofrecer valor en este sprint, hágalo y luego use lo que ha aprendido en este sprint para refinar su proceso de estimación y planificación la próxima vez. Si no se puede derivar ningún valor durante el sprint, entonces una terminación anticipada es ciertamente apropiada.
Si se encuentra con una gran historia o épica en sus manos, sin duda puede dividir la historia en tareas del tamaño adecuado en el Sprint Backlog. Solo gana puntos por las historias de Product Backlog que completa al final del sprint, pero descomponer una historia en tareas tiene varios beneficios:
Scrum no requiere que completes todas las historias durante el sprint, aunque obviamente ese es uno de los objetivos. El verdadero objetivo es cumplir el Sprint Goal. Si descompone sus historias correctamente en Sprint Backlog, es posible que pueda completar una o más historias que cumplirán con el Sprint Goal aunque no haya completado todo el conjunto de historias de usuario. ¡Esto sería una victoria!
Mi instinto me dice que rompa las epopeyas después del sprint y vuelva a estimar. Dado que este es el primer sprint, no estropeará los datos históricos y me permitirá comenzar desde cero.
Por favor, no hagas esto. Si lo hace, ya va por el camino de tratar la velocidad como un objetivo de gestión, en lugar de una herramienta de planificación de la capacidad o un límite WIP.
Por todos los medios, revise su proceso de preparación de la cartera de pedidos y planificación de Sprint, y vea dónde ha fallado su estimación, y quizás lo que es más importante, su proceso para seleccionar un volumen apropiado de historias de la cartera de productos. Este es un uso valioso del proceso Sprint Retrospective.
Sin embargo, volver a estimar o volver a planificar su sprint a posteriori es una pérdida de tiempo, a menos, por supuesto, que haya terminado su sprint antes de tiempo y haya regresado a Sprint Planning. Si eso no es lo que está haciendo, mantenga sus puntos de datos y continúe con el proceso.
Al final de un sprint, su Sprint Backlog, las estimaciones de la historia y los gráficos de trabajo pendiente le brindan datos para revisar su proceso. Estos datos generalmente incluyen:
Una estimación de la historia es solo un punto de datos único con un par de interpretaciones adjuntas. Si se trata de datos no válidos, puede optar por descartarlos. Sin embargo, en su caso, es muy posible que sean datos válidos, en el sentido de que reflejan con precisión un problema de proceso subyacente que afecta la productividad de su implementación actual de Scrum. Si ese es el caso, ¡mantenga el punto de datos!
La estimación, por su propia naturaleza, requiere más experiencia y un conjunto de datos más grande de lo que puede obtener en un solo sprint. A menos que no pueda corregir su proceso con el tiempo, su único punto de datos eventualmente se convertirá en un valor estadístico atípico . Wikipedia dice:
[S]algunos puntos de datos estarán más alejados de la media de la muestra de lo que se considera razonable. Esto puede deberse a errores sistemáticos incidentales o fallas en la teoría que generó una supuesta familia de distribuciones de probabilidad, o puede ser que algunas observaciones estén lejos del centro de los datos. Por lo tanto, los puntos atípicos pueden indicar datos defectuosos, procedimientos erróneos o áreas en las que una determinada teoría podría no ser válida. Sin embargo, en muestras grandes, es de esperar un pequeño número de valores atípicos (y no debido a ninguna condición anómala).
En otras palabras, una sesión de Planificación de Sprint produce valores atípicos útiles cuando:
Toda esta es información valiosa para el proceso de inspección y adaptación. Aprenda de la experiencia y luego descarte los valores atípicos o guárdelos para futuros análisis. Al final, su elección en el asunto es solo eso, y realmente no afecta la eficacia del marco general tanto como puede pensar.
Algunos puntos realmente buenos aquí: déjame arrojar otro centavo o dos.
En primer lugar, en realidad no estás haciendo Scrum si eres una persona que actúa como Product Owner, Scrum Master y el equipo de desarrollo. Para citar la guía de Scrum, "los roles, artefactos, eventos y reglas son inmutables". No es algo malo, yo mismo hago desarrollo ágil, tomando muchos consejos de Scrum y trabajo en un equipo de dos personas, en dos plataformas; así que, realmente, soy solo yo para mi plataforma.
El tamaño ideal de un equipo, según la evaluación que puede realizar en Scrum.org e implícita en la guía, es 6 +/- 3. Según la guía, cuando cae por debajo de 3 desarrolladores, pierde una diversidad de conocimientos, y cuando Si obtienes más de 9, aumentas el potencial de que se formen subequipos y se reduzca la comunicación entre equipos.
Los puntos de historia son solo un método para estimar un nivel de esfuerzo requerido para una historia/tarea determinada, que es una práctica común, pero no forma parte del marco Scrum. Finalmente, Scrum, como marco, es bastante flexible y te permite hacer lo que sea necesario para hacer el trabajo... todo lo demás, como historias y epopeyas, la estimación de puntos de la historia en lugar de horas, etc. es bastante mucha preferencia personal (según los fundadores originales).
De acuerdo, dejando de lado los tecnicismos, pasemos ahora al meollo de tu pregunta: atomizar y estimar el trabajo.
Parece que tiene un problema de preparación de trabajos pendientes, junto con un problema de metodología de estimación. Si insiste absolutamente en usar puntos de historia, una idea es encontrar la historia más simple que pueda, que se convierte en 1, es una línea base conocida de complejidad contra la cual se pueden comparar todas las demás historias. Personalmente, sigo prefiriendo las estimaciones basadas en el tiempo, pero depende totalmente de usted, solo acepte que las posibilidades son: (1) se equivocará; (2) a medida que su definición de hecho cambia/mejora, el nivel de esfuerzo para completar una historia de nivel 1 aumenta técnicamente en relación con el tiempo y la complejidad, pero no cambiará el valor real; y (3) a medida que continúa el desarrollo de un proyecto, sus estimaciones aumentarán en su incorrección si no se ajustan antes de cada iteración.
Este último punto es un aspecto de caer en un estado "hiperproductivo", que en realidad es nuestra incapacidad para predecir la evolución de nuestro sistema y cómo las piezas finalmente encajan y de repente provocan un ticket valorado en 500 (estimado en 30 días). colapsar a algo más como 100 (6 días).
Con respecto a cómo construir y arreglar una cartera de pedidos, tiendo a recomendar comenzar alto y atomizar lo más cerca posible de un día completo para lograr algo desde el principio hasta el final. Entonces, en mi práctica, esto significa que una estimación de historia/requisito debe ser de 8 horas o menos, incluida la escritura de pruebas unitarias, codificada, refactorizada, documentada y (opcionalmente) revisada por otra persona (algo difícil de hacer en una operación de una sola persona). Lo que generalmente da como resultado algo similar a una WBS con "Crear un producto fantástico" en la parte superior, que luego se desglosa, se verifica si hay áreas reutilizables, etc., etc.
Si se comprometió en exceso para el sprint y no puede completar todos los elementos antes de que finalice el cuadro de tiempo, entonces el SM-usted debe informar al PO-usted debe saber, y luego el PO-usted debe decidir si abandonar el sprint o no basado en toda la información recibida de partes interesadas externas y el resto del equipo (porque solo el PO puede abandonar un sprint). No se preocupe por la validez de los datos históricos: es su primera iteración y deberá hacer dos o tres más antes de tener suficientes puntos de datos para siquiera considerar revisarlos en busca de un potencial de mejora "científico".
Por último, permítanme volver al Manifiesto Ágil y decir, no se atasquen en los procesos (Scrum, XP, etc.) y las herramientas (historias, epopeyas, puntos de la historia, gráficos de quemado, etc.) - y concéntrese en las interacciones que tiene con su equipo (incluso si es una especie de equipo virtual entre sus compañeros Stackers), y siéntase libre de abandonar el plan (completar el sprint porque lo planeó y se comprometió con el trabajo), eso es perfectamente aceptable. - Es mejor detenerse y elegir una nueva dirección que continuar yendo en la dirección equivocada solo porque dijiste que lo harías.
Guía Scrum http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf#zoom=100
Autoorganización: Jeff Sutherland http://www.youtube.com/watch?v=M1q6b9JI2Wc
Marco Scrum: Lyssa Adkins http://www.youtube.com/watch?v=_BWbaZs1M_8
Scrum y otros: Ken Schwaber http://www.youtube.com/watch?v=IyNPeTn8fpo
Manifiesto ágil: http://agilemanifesto.org
Tenga en cuenta que los equipos SCRUM deben incluir 7 personas +/- 2, por lo que puede resultarle incómodo planificar, estimar, calcular la velocidad, ser el SM, etc. en un equipo de un solo hombre.
andres claro