He estado utilizando una metodología ágil (SCRUM) durante aproximadamente tres años y veo ciertas ventajas, especialmente en la retroalimentación a corto plazo en muchos niveles (de clientes que tienen acceso temprano a funciones implementadas, de probadores que pueden probar características como tan pronto como se implementen, de otros desarrolladores que pueden proporcionar comentarios muy tempranos sobre el nuevo código a través de la revisión, etc.
Por otro lado, tengo dos problemas abiertos, el primero de los cuales trataré de explicar en esta pregunta.
Problema: dificultad para obtener un buen diseño
Intento refactorizar tan pronto como el código se vuelve desordenado, escribo pruebas unitarias tanto como puedo (lo que ayuda a prevenir errores en general y cuando refactoriza en particular). Por otro lado, desarrollar algunas características complejas en pequeños incrementos, con compromisos diarios y repensar continuamente el código cuando se desestructura, no me permite producir un diseño realmente bueno.
El único módulo bien diseñado que pude producir recientemente lo obtuve adoptando un enfoque diferente: analicé el problema durante unos días (en realidad, tuve el problema en mi mente durante un par de meses antes de comenzar a trabajar en serio ), esbocé un diseño bastante detallado de todas las clases involucradas y sus relaciones durante un par de días más, y luego me encerré en mi oficina y escribí todo el código trabajando sin interrupción durante aproximadamente tres semanas. El resultado fue lo mejor que he producido en mucho tiempo, con muy pocos errores que fueron bastante fáciles de localizar y corregir, y con un diseño muy claro, que no ha requerido ningún cambio relevante desde entonces.
Entonces, hasta ahora, me resultó mucho más efectivo obtener una imagen general de lo que quiero hacer de antemano que comenzar a escribir código en pequeños incrementos con la esperanza de que la gran imagen surja mágicamente en el proceso. Con mi mejor esfuerzo, el enfoque de desarrollo de incrementos pequeños siempre me ha llevado a un peor diseño.
Pregunta : ¿Alguien ha tenido una experiencia similar? ¿Estoy aplicando SCRUM de forma incorrecta o a qué debo prestar atención si deseo desarrollar en pequeños incrementos y aún así terminar con un software bien diseñado? ¿O debería programar una historia de usuario de diseño antes de comenzar la codificación real? ¿Se considera esto una buena práctica, al menos para características que son más complejas que el promedio?
EDITAR NOTA
Soy consciente del hecho de que un buen diseño no es algo absoluto y no tiene un valor en sí mismo, sino que depende del contexto, y que uno debe apuntar a un diseño que sea lo suficientemente bueno para el problema en cuestión.
Por ejemplo, no me importa (demasiado) el buen diseño si tengo que implementar un componente simple que (1) debe estar listo lo antes posible, (2) se va a usar solo una vez, (3) no utilizado por otras partes del sistema (YAGNI).
Me importa el buen diseño cuando un componente (1) se usará varias veces y en varias versiones diferentes de un producto, (2) debe mantenerse y ampliarse con el tiempo, (3) tiene muchos otros componentes dependiendo de él .
The only well-designed module I could produce recently I obtained by taking a different approach-- Usted contestó su propia pregunta. Todavía necesita un diseño inicial; no se puede esperar que un buen diseño simplemente crezca orgánicamente de la refactorización. No funciona de esa manera.Respuestas:
Entonces no hagas eso.
No todo encaja en la bonita caja ágil. Muchas veces un producto tendrá algunas cosas complejas que no pueden ser cultivadas por individuos y no pueden completarse de manera sensata dentro de un sprint. Forzarlos a esa caja solo causará problemas. Pero estos deberían ser pocos y distantes entre sí. Si encuentra que muchos de sus componentes son así, el propietario de su producto debe trabajar para dividir las cosas mejor (con su equipo). Estoy bien haciendo lo que hiciste: toma la historia, diseñala, luego házlala lo antes posible con la expectativa de que tomará algunas semanas.
En el caso más general, hay 3 cosas que he visto hacer para obtener un buen diseño en Agile:
Realmente diseño : muchos lugares que he visto comienzan su carrera y simplemente comienzan a codificar. Obtendrá un mal diseño de esta manera. Agile no cambia el proceso de desarrollo de plan - código - prueba - lanzamiento, solo lo acorta a piezas más granulares. Al comienzo del sprint, siéntate según sea necesario y diseña tu solución.
Tenga un arquitecto / líder : una vez que su proyecto sea lo suficientemente grande, terminará con varios equipos scrum trabajando en diferentes partes de la aplicación. Es muy útil tener a alguien (o varias personas dependiendo del tamaño de la aplicación) cuyo trabajo principal es saber qué están haciendo todos los equipos desde el punto de vista del diseño. Pueden responder preguntas y guiar a los equipos hacia un diseño general más armonioso. También he visto que cada equipo de scrum tiene una ventaja que sabe la mayoría de lo que otros equipos están haciendo y que fue muy efectivo.
Sé un pragmático . Cubrí esto arriba. Agile es una herramienta, y como cualquier herramienta; No se aplica a todos los problemas. Si no tiene sentido aplicar a algún componente, no lo aplique allí. Su objetivo es enviar un buen software; no lo olvides
fuente
Es muy posible implementar en pequeños incrementos y terminar con un código mantenible bien estructurado. En teoría, es muy simple: si se asegura de que el código esté bien estructurado después de cada cambio, siempre estará bien estructurado. Su código está mal estructurado porque continúa agregando código cuando debería refactorizarlo.
No importa cuánto tiempo dedique al diseño, eventualmente los requisitos cambiarán de manera imprevista y tendrá que escribir código que no se ajuste al diseño original. Entonces tendrá que hacer un cambio incremental. Si tiene un buen conjunto de pruebas unitarias y es experto en refactorización, podrá mantener el código bien estructurado a medida que cumpla con los nuevos requisitos.
fuente
"Bien diseñado" es subjetivo
¿Qué significa "bien diseñado" para ti? al propietario del producto? ¿al cliente?
¿Es "bien diseñado " un objetivo del propietario del producto? un objetivo del cliente? o solo tu?
¿Lo que considera "no bien diseñado" sigue cumpliendo con las expectativas de los propietarios de productos y haciendo feliz al cliente? Entonces eso es bastante "bien diseñado" .
Lo suficientemente bueno y yagni
Nada en la mayoría de las metodologías ágiles habla de "bien diseñado", porque cualquier sistema en el que el propietario del producto acepta las historias como completo y los clientes creen que cumple con sus requisitos está "bien diseñado" .
Se espera que los desarrolladores sean profesionales y usen pragmáticamente las mejores prácticas, diseños apropiados y expresiones idiomáticas para implementar las características y las historias.
Si no tiene en cuenta el tiempo para hacer las cosas correctamente, es un problema del desarrollador, si el Propietario del producto exige cosas en menos tiempo de lo que se puede hacer, es su prerrogativa hacer esto, y es su responsabilidad educarlos sobre consecuencias en forma de historias técnicas de deuda .
MELÉ
La metodología ágil que se puede escribir, no es la metodología ágil. "- Jarrod Roberson
Se supone que SCRUM es un marco de herramientas para administrar el ciclo de vida total de un producto de software. No se supone que sea un conjunto rígido de cosas, solo un buen lugar para comenzar y, con suerte, mejorar.
La mayoría de las tiendas en las que he trabajado tienen lo que se llama Sprint ZERO, Sprints para que los miembros principales del equipo esbocen una arquitectura general o un tema del producto.
Las historias que son más grandes que 20 por lo general se desglosan hasta que en realidad son unas historias de 3 a 5 puntos. Una de estas historias es: "Como equipo tenemos que reunirnos para discutir cómo vamos a diseñar esta característica, de modo que tengamos la menor deuda técnica posible dado el tiempo asignado".
En general
En general, un sistema "bien diseñado" es lo suficientemente bueno y sigue a YAGNI.
Agile, y SCRUM, en particular como una implementación de Agile, son más acerca de cómo producir un producto de la forma más transparente posible para el Propietario / Patrocinadores del producto.
No se trata de nada de diseño técnico / arquitectura inteligente. Es más una filosofía sobre cómo abordar la entrega de software que satisfaga las necesidades y expectativas de los clientes. Si no hay lo que llamas partes "bien diseñadas" , eso no es un error en sí mismo, ya que no es una parte fundamental de la filosofía.
fuente
Hemos estado trabajando con scrum durante varios meses y quiero compartir mi experiencia con respecto a su problema.
Hace unos meses me dieron una gran pieza para implementar. Tenía todas las especificaciones listas, así que tuve que implementar nuevas funciones en consecuencia. La tarea consistía en demorar entre 5 y 6 semanas (como calculé). Pasé la primera semana trabajando solo en diseño. La tarea era un poco complicada: había un objeto principal que, como concluí de la especificación, tenía 15 estados diferentes, y la IU debía tener comportamientos diferentes para cada estado.
Luego diseñé todo el flujo de trabajo y la estructura y clases de DB.
No veo ningún otro enfoque en mi caso. Si me sumergiera en la codificación de una vez, habría tenido un gran desastre al final, casi imposible de mantener y extremadamente difícil de realizar más cambios. Pero los cambios llegaron en las próximas 2 semanas, así que tuve que volver a trabajar el código. Esto fue fácil ahora, con el diseño pensado inicialmente. Esto nos ahorró tiempo, dinero y nervios.
Después de esta experiencia, estoy absolutamente seguro de que vale la pena hacer un diseño aceptable al principio, que espero que con algún milagro lo tenga al final.
fuente
La vista trasera es de 20-20. Si tenía la información a su disposición al comienzo del proyecto para resolver todo y luego escribir el código en unas pocas semanas, le sugiero que lo haga.
No está otorgando suficiente crédito a todas las ideas que adquirió, los enfoques que se probaron y fallaron / tuvieron que cambiarse, y la mayor capacidad del cliente / usuario para proporcionar los requisitos de crédito suficiente.
¿Por qué alguien con un historial de proyectos exitosos de caída de agua, cambiaría a una metodología ágil?
fuente
Siempre necesita una imagen más amplia de cuál debería ser el objetivo final, y qué características están destinadas a implementarse y cuándo, antes de comenzar un proyecto. Trabajar en historias como tareas atómicas es pedir problemas. Debe tener en cuenta los requisitos futuros tanto como sea posible.
fuente