¿Tiene que entregar software que funcione en un timebox/sprint Agile?

Más allá de los cuatro valores, estos principios también son relevantes:

Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso.

y

Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

y

El software que funciona es la medida principal del progreso.

Las ventajas del desarrollo de software ágil se obtienen mejor a través de la entrega frecuente de software funcional.

También es importante señalar que los timeboxes no son inherentes al desarrollo ágil de software. Las palabras "iterativo", "incremental", "iteración" y "caja de tiempo" no aparecen en ninguna parte del Manifiesto. Sin embargo, algunas metodologías se basan en timeboxes: Extreme Programming y Scrum son dos marcos populares que usan timeboxes. Otros no: Kanban se puede usar con un flujo continuo.

Tendría que preguntar a los creadores de cada metodología por qué usan iteraciones de tiempo limitado. Hay algunas ventajas, especialmente para los equipos menos maduros, para garantizar que todas las cosas que deben suceder realmente sucedan. Cuando diferentes eventos y actividades suceden justo a tiempo, es fácil descuidar o pasar por alto los eventos.

El resultado de cada iteración depende del marco. Por ejemplo, Scrum exige que los elementos de la lista de pedidos del producto cambien el estado del producto para que se completen en cada Sprint. Otras metodologías pueden no tener esta definición estricta. Podrías definir una metodología que entregue valor. Varios métodos de "doble vía" también definen el valor en términos de trabajo de descubrimiento y entrega.

Consideraría que su proceso de desarrollo de productos es ágil si sigue los valores y principios del Manifiesto para el desarrollo ágil de software. En cuanto a la frecuencia con la que se entrega el software, el único requisito es la frecuencia de "un par de semanas a un par de meses". Si usa timeboxes o no, o entrega software que funcione al final de cada timebox, no lo hace ágil ni le impide ser ágil.

¿Tiene que entregar software que funcione en un timebox/sprint Agile?

Si está creando un producto de software utilizando sprints, entonces sí, debe entregar software que funcione en cada sprint. El objetivo de un sprint es tener una cadencia de actividades y un punto de inspección en el que observe lo que ha construido, recopile comentarios, ajuste su comprensión en función de la información recibida y del contexto actual, y planifique sus próximos pasos hacia su objetivo. meta. Si no produce software que funcione en cada sprint, pierde esta oportunidad de inspeccionar y adaptar.

Cualquier equipo puede tener un mal sprint de vez en cuando y no entregar un incremento en el producto al final, eso no es realmente un problema, puede ocurrir. Pero si sucede constantemente, entonces pierde muchas oportunidades de averiguar si está construyendo lo correcto. Doce meses después tienes un producto que el cliente no puede usar y te dicen que deberías haberlo hecho de otra manera desde el primer mes si hubieras tenido algo que mostrar por tu trabajo.

Sin embargo... introduces una perspectiva interesante con estas preguntas:

• ¿Los pensamientos anteriores significan que un sprint/timebox Agile no tiene que entregar un software que funcione, sino solo algo que funcione, donde el trabajo se define como algo que puede probar la hipótesis de un producto?
• Dado que un sprint entrega algo que puede probar la hipótesis de un producto, ¿hay límites para esto? Tomando el ejemplo de un sprint que prueba las reglas comerciales, ¿podría un sprint entregar solo las reglas comerciales escritas en papel y luego enviar a una persona a interactuar con un usuario final y calcular las entradas del usuario final siguiendo las reglas y midiendo si el usuario final obtuvo valor de la salida?

Respondí a su pregunta en el título con "Si está creando un producto de software", y dije que sí. Si su producto es software, el próximo incremento o mejora del producto, por supuesto, será en forma de software. Lo que está preguntando con las otras preguntas me parece más un estudio exploratorio o alguna actividad de descubrimiento para determinar qué debe incluirse en su producto de software.

En este caso, puede usar un Spike dentro de su sprint para realizar el estudio exploratorio. Luego, al final del sprint, entrega alguna funcionalidad en el producto de software (no tanta como en otros sprints debido al pico), más el resultado de su estudio (en forma de formularios en papel o lo que sea). Luego puede usar el nuevo formulario del producto y los formularios en papel para decidir qué hacer a continuación (qué agregar al software, si necesita más estudios exploratorios, tal vez los formularios en papel se puedan mejorar, cambiar, etc., para reunir mejor información, etc.).

En caso de que el pico se trague el tiempo de todo el sprint, pausaría los sprints mientras no hago ningún trabajo en el software. El nuevo trabajo que agregue al producto de software debe respetar algún tipo de "definición de hecho" para que sea seguro lanzarlo a los clientes, y esto debe mantenerse de sprint a sprint. Si uno de sus sprints produce formularios en papel, entonces no tendrán nada en común con su "definición de hecho" para las características del software. Por lo tanto, no encaja del todo con el resto de los sprints que producen software. En ese caso, vuelves a usar un pico de menos tiempo, o (personalmente) usaría una pista de producto diferente para eso:

• una pista de software para desarrollar el producto y entregar el software;
• una pista exploratoria que brinda información, conocimiento, perspectiva sobre lo que debe suceder a continuación en su proyecto de software.

Luego puede cambiar entre estas pistas según sea necesario, así:

o así:

Por lo tanto, mantiene las cosas bien organizadas, no tiene que mezclar diferentes resultados con la misma "definición de hecho", sus métricas no se confunden de un tipo de sprint a otro, etc. Ambas pistas también pueden continuar. al mismo tiempo, si tiene personas que pueden trabajar en el producto de software mientras otros juegan con formularios en papel en busca de información.

Por supuesto, esto es más trabajo y necesita más coordinación que usar un clavo con otro trabajo en una sola pista.

Un enfoque aún más simple sería usar Kanban y renunciar por completo a los sprints, los picos y las pistas, y simplemente trabajar en lo siguiente que se necesita y aporta valor (ya sean formularios en papel, entrevistas con usuarios o funciones integradas en el software). luego decida una cadencia para introducir algunos puntos de inspección para que aún pueda recopilar comentarios y adaptar sus próximos pasos hacia su objetivo.

Como ya mencionaron otros, los sprints son parte de Scrum. No tienen nada que ver con Agile.

Solía ​​​​ser que la Guía Scrum establecía las ideas claramente, pero cuanto más avanzamos, más oscuro se vuelve *. La guía Scrum actual dice que tenemos que entregar un incremento al final del sprint, y el incremento se relaciona con el "valor". Parece que los autores intentan cubrir una gran cantidad de situaciones con 1 herramienta y es por eso que intentan no ser precisos. Entonces... Creo que el documento en sí está tratando de decir que no, que no tienes que lanzar una nueva funcionalidad para PRD al final del Sprint. Pero lo que la mayoría de la gente considera Scrum, resultaría en un lanzamiento al final de cada Sprint.

¿Por qué tenemos sprints?

Esa es una gran pregunta. Y espero que usted (y todos los demás) se den cuenta algún día de que no los necesitamos.

Los sprints nos permiten abordar un proyecto a través de fragmentos de trabajo más pequeños entregados con frecuencia.

Los sprints por sí solos no facilitan los lanzamientos frecuentes. Puedes hacerlo sin ellos. Además, a menudo podría entregar más rápido que Sprints. Puede usar Just-in-time y/o Continuous Delivery para lanzar software con mucha más frecuencia que lo que haría con sprints.

Lo que estoy describiendo es solo una metodología de desarrollo de productos y Agile es un subconjunto de eso.

El desarrollo ágil simplemente significa que si ve cómo puede mejorar su proceso, lo mejora. No es una metodología, es una mentalidad que permite crear/cambiar tu proceso.

Escribir reglas comerciales es solo documentación que no es tan útil como el software en funcionamiento. Relacionado con el siguiente punto.

Los requisitos de escritura (parece que eso es lo que quiere decir con documentación) podrían ser un trampolín para un software que funcione, lo que se hace más adelante. Por supuesto, el software que funciona es mejor porque significa que se ha hecho más trabajo. Tanto en los métodos continuos (ToC, JiT, CD) como en los enfoques basados ​​en el tiempo (Waterfall, Scrum), primero escribirá los requisitos y luego el software.

Manifiesto ágil cuando se habla de software sobre documentación se refiere a:

1. Procesos de desarrollo en los que, si desea hacer algo (enviar código para probar, implementar en algún entorno, cambiar la configuración, etc.), deberá completar una gran cantidad de documentación. Así que se trata de burocracia.
2. Casos en los que escribiría muchos requisitos por adelantado antes de implementarlo. Y esto no es bueno porque después de tu primer lanzamiento descubrirás que has cometido muchos errores y muchos de esos requisitos son inútiles. En ToC y JiT, esto se refiere a los términos "trabajo sin terminar", "trabajo en progreso", "costos de inventario": cuanto más haya hecho que no se publique , más lo retrasará.

Construir en el orden en que se describen las capas (reglas de negocios, código que calcula esas reglas (que generalmente se encuentran en el backend), interfaz de usuario) es una cascada e introduce los riesgos de la cascada.

Cascada puede significar muchas cosas. En la mayoría de los casos, las personas se refieren a procesos de desarrollo que rara vez se publican (por ejemplo, una vez cada 6 meses). ¡Y esto no es necesariamente malo! Algunos proyectos requieren mucho pensamiento, modelado, simulación y prueba antes de que se pongan en marcha. Hay casos de uso para la cascada (más de lo que mucha gente piensa).

Sigues mencionando "entrada del usuario", pero eso NO es lo que necesitamos para crear un gran software. Necesitamos información . Y dependiendo del proyecto la información más importante puede variar:

• Viabilidad: ¿estamos seguros de que realmente podemos implementar tal idea? ¿Quizás la tecnología aún no está allí? O tal vez la tecnología está ahí, pero la idea es prohibitivamente cara/lenta/incómoda.
• Educación: cuanto más implementamos (no necesariamente lanzamos) mejor entendemos el dominio y la idea
• Inversión: ¿estamos seguros de que conseguiremos financiación para esta idea? Quizás lo que necesitamos es un prototipo y no un software real en RPD.
• Y por supuesto los típicos objetivos como: ¿estamos seguros de que estamos resolviendo los problemas de nuestros usuarios? Ese es el caso que definitivamente se beneficiaría de lanzamientos frecuentes.

Esto también puede estar relacionado con la etapa en la que se encuentra el proyecto. Por ejemplo, al principio necesitaríamos mucho trabajo por adelantado (algunos proyectos necesitan 6 meses, otros, 3 años). Pero después de que se haya realizado el trabajo inicial, es posible que deseemos lanzar con más frecuencia. Y no solo por los comentarios. Tal vez cometimos un error y nos gustaría solucionarlo pronto, o marketing necesita esta función rápidamente porque ya lo prometieron.

*Parece que están tratando de cubrir sus huellas porque cada vez que trato de encontrar la primera versión de la Guía Scrum, se vuelve más y más difícil :)