¿Cómo manejas el diseño en Scrum?

¿Cómo manejas el diseño en Scrum? ¿Todavía tiene documentos de diseño bien escritos para cada iteración de scrum? ¿Acabas de hacer notas de diseño con diagramas UML? ¿O simplemente tienes un código bien comentado?

Cada iteración puede implicar un cambio de diseño, por lo que solo quería saber cómo las personas capturan esto para que los nuevos desarrolladores tengan un trabajo fácil de entender el dominio y participar lo más rápido posible.

¡solo porque sea scrum no significa que todo cambie cada sprint!

Scrum se trata de hacer lo necesario (pero no más) . Aún necesita hacer el diseño y aún debe documentar. Es solo que la cantidad no está fijada ni cómo hacerlo.

Parte de la planificación de cada sprint es decidir qué se debe hacer. Si hay que diseñar algo en la cartera de pedidos porque afecta a otras cosas, entonces debe agregar una tarea específica para los procesos de diseño y hacerlo antes de la tarea de implementación.

Tengo mucho que decir sobre este tema. He visto muchos casos en los que las empresas / equipos / personas dicen que están utilizando un enfoque ágil para el software, pero en realidad, quieren cosechar las recompensas que prometen los métodos ágiles sin cumplir con los principios.

Para que funcione la iteración rápida, debe hacer un desarrollo basado en pruebas (me detuve antes de decir que tiene que hacer TDD de mala gana). En TDD, sus pruebas expresan el diseño y la intención del código (cuando dicen "el código es la documentación", lo que deberían decir es "las pruebas son la documentación"). Al escribir pruebas unitarias que expresan su comprensión de la función en cuestión, está declarando explícitamente lo que cree que debe hacer el código. Luego escribes el código que lo hace. Luego refactoriza ese código para que se adhiera a los principios arquitectónicos buenos "Red-Green-Refactor".

La ejecución de las pruebas unitarias con cada registro (o incluso antes de cada registro) verifica que el nuevo código que ha escrito no rompe la funcionalidad esperada en alguna otra área de la aplicación. Esto proporciona una red de seguridad que le permite cambiar el código con abandono sin control. A medida que aumenta su comprensión de los requisitos disponibles, puede modificar la prueba para reflejar ese nuevo conocimiento. El diseño real reside en las pruebas unitarias. Todo lo demás (incluido el código que no está cubierto) es una mentira.

Aquí hay algunas lecturas recomendadas

• Código limpio
• Principios, patrones y prácticas de desarrollo ágil de software
• El programador pragmático

Estos son buenos lugares para comenzar a buscar y aprender cómo abordar verdaderamente el desarrollo ágil.

Scrum es una metodología de gestión de proyectos, no una metodología de desarrollo de software. Scrum se usa generalmente junto con una metodología ágil. Ahí está tu respuesta.

No hay tanto diseño inicial como los requisitos cambian con frecuencia. Por lo tanto, diseñar hasta el nivel de clase suele ser una pérdida de tiempo. Sin embargo, puede valer la pena esbozar decisiones arquitectónicas de alto nivel.

El problema con hacer documentos de diseño pesado es que son obsoletos casi tan pronto como se crean. Entonces, lo que funciona mejor es, por lo general, la documentación de alto nivel que es poco probable que cambie por completo en un corto período de tiempo.

Scrum es un modelo iterativo e incremental basado en valores ágiles . Eso significa que no tiene una fase de diseño separada. La idea es que debe estar constantemente lidiando con el diseño, así como constantemente con el análisis, la implementación, las pruebas y la integración a lo largo del proyecto.

Necesita un poco de planificación para que esto funcione. Ingrese a la reunión de planificación del sprint , donde el equipo estima las tareas para el sprint que le espera. La mayoría de las personas no se dan cuenta de que esto no es solo una reunión de estimación, sino también un esfuerzo de diseño. Por ejemplo, una tarea podría ser "Agregar código para el nuevo modelo de automóvil". Todavía no puede estimar esto, necesita saber un poco más. Por lo tanto, el equipo discute el diseño y presenta una solución amplia ("¿subclase de automóvil?") Y agrega eso como un recordatorio de la tarea. Raramente necesitas más formalidad que eso. Ahora tiene una idea de cómo resolver el problema. Todavía no tiene todos los detalles y eso está bien, conoce lo suficiente del diseño para poder hacer una estimación cómoda. Sin tener que crear ningún diagrama en absoluto (en este punto).

Para obtener documentación física real , recomiendo crear un diagrama general de sistemas en una pared para que todos lo vean. El resumen solo necesita tener las clases y módulos más importantes incluidos y rara vez debe actualizarse. Además, crear algunos diagramas de estado para las clases más importantes del sistema es muy útil. Espolvorea con algunos diagramas de secuencia seleccionados de casos de uso típicos para que sea más fácil para las personas ver rápidamente cómo están conectadas las cosas. Supongo que puede generar diagramas de jerarquía de clases a partir de su código, por lo que ese problema se resuelve fácilmente.

Tenga en cuenta que todos los diagramas se crean después de la implementación real. Esto se mantiene con el "software de trabajo sobre la documentación completa" y el diseño justo a tiempo.

Y sí, el código legible es definitivamente documentación.

La arquitectura general del proyecto y el diseño de alto nivel se realizarían fuera de los equipos scrum cuando los propietarios del proyecto estén creando las historias.

Es necesario que haya un diseño general suficiente escrito de cualquier forma para ayudar a ver la relación entre las historias y las expectativas del cliente.

Parte del diseño necesario para cada historia se haría en la planificación y negociación con el propietario del producto durante la planificación.

La mayor parte del esfuerzo de diseño para una historia se haría en el sprint.

Si la historia no está lo suficientemente definida como para estimar, entonces se podría reservar un cuadro de tiempo en el sprint actual para hacer el trabajo de diseño suficiente para que se pueda crear una historia adecuada para un sprint posterior.

Tengo entendido que usted hace un diseño de nivel superior con los requisitos iniciales que reúne al comienzo del proyecto. Usted documenta bien este diseño.

Luego, cuando vaya a implementar el requisito, cambiará el diseño de nivel inferior según lo necesite, pero evitará cambiar el diseño de nivel superior.

Bueno, así es como me lo explicaron hace cinco minutos ...

Hoy existe una división dentro de la comunidad Eclipse entre las herramientas UML tradicionales centradas en MDD en las que el modelo impulsa el código / desarrollo y Omondo que considera que las iteraciones deberían impulsar el proceso de desarrollo y ciertamente no solo el modelo.

Estoy de acuerdo con ellos porque MDD es una mierda, mientras que UML es realmente una excelente manera porque se estandariza para comunicarse con otros miembros del equipo.