Tengo problemas para describir el Proceso de Desarrollo de mi proyecto.
Estoy haciendo mi pasantía en una empresa como diseñador de Sistemas de Información y desarrollador de Java EE, para graduarme. Necesito hablar sobre el proceso de desarrollo y la organización del proyecto en mi informe.
Le pregunté a mi jefe sobre el proceso de desarrollo que están realizando en la empresa y me confirmó que es Scrum.
Mi tema es sobre Intranet. Hemos comenzado por el módulo más complejo de la intranet. El plazo de tiempo previsto para terminarlo es de 5 meses. Después de terminar este módulo, comenzamos otro.
Entonces, durante estos 5 meses, esperamos especificar los requisitos del módulo, diseñar un sistema de información que satisfaga los requisitos, diseñar una arquitectura de software, desarrollar, luego integrar, probar, validar y luego pasar a otro módulo. Estos pasos me hacen sentir que hemos utilizado el V-Cycle descrito aquí .
Sin embargo, hemos estado haciendo prácticas de Scrum, como hacer un seguimiento diario entre el Equipo Scrum y el Scrum Master (¿qué hiciste ayer? ¿Tienes alguna dificultad? ¿Qué harás hoy?...) durante una reunión de 5 minutos. Somos un equipo de 3 personas, tenemos un Scrum Master y 2 Product Owners.
Hablé con mi jefe y me dijo que dividirá 5 meses en sprints de 2 o 3 semanas (un sprint de diseño, un sprint de implementación de un prototipo funcional...,..., un sprint de pruebas).
Sin embargo, lo que aprendí en mi universidad es que cada sprint nos da una versión, un producto que podemos usar pero que debemos mejorar.
Perdón por este texto tan largo, pero necesitaba hacerlo en mi contexto para poder ayudarme a describir el proceso de desarrollo de este proyecto. ¡Muchas gracias!
¿Podrían ser estos Sprints?
Desafortunadamente, no estás haciendo Scrum. Simplemente aplicas ciertas prácticas, pero no sigues la mentalidad. Estás cerca cuando dices que "... cada sprint nos da una versión, un producto que podemos usar pero que debemos mejorar" . Sin embargo, los sprints no necesariamente producen versiones y en Scrum nuestro objetivo es la retroalimentación en primer lugar.
Entonces, hacemos Scrum para recibir comentarios más rápidos sobre nuestro producto. Por supuesto, puede usar las prácticas de scrum, también usamos un par de ellas, pero sus procesos están lejos de ser un proceso de Scrum.
Cuando describa su proceso, olvídese de Scrum, describa el proceso y, cuando haya terminado con su borrador, actualice su ensayo con las herramientas de Scrum y cómo lo ayudan a usted o a su organización. Sea realista y no escriba algo que pueda verse bien, pero que en realidad no lo hace.
NO puedes hacer un sprint de diseño, uno de codificación, uno de prueba. Cada sprint debe hacer todo lo posible para ofrecer alguna funcionalidad de trabajo.
Ese enlace no es a una imagen del modelo V. Sin embargo, es un concepto erróneo popular.
El modelo V no tiene flecha del tiempo. Tiene flechas de dependencia. No puedes hacer esto hasta que hayas hecho aquello. Scrum no viola el modelo V. Sin embargo, mientras V-model dice que no puede probar, hasta que haya escrito el código. Agile establece que puede y debe escribir las pruebas antes de escribir el código. Agile también dice que no tienes que hacer todo esto antes de hacer aquello. (No haga todo el diseño, luego toda la codificación, luego todas las pruebas)
Para ágil (lo básico):
Verá que hay un orden, es lo mismo que el modelo V, excepto que el modelo V original no reconoce que podemos escribir pruebas antes del código de producción. Tampoco reconoce la codificación como diseño. (el código es la parte más grande del diseño)
No hay una manera agradable de decir esto, es una cascada. Lo único bueno de la cascada es que, si usted es un contratista, puede mantener el proyecto en marcha durante mucho tiempo, sin que los clientes/gerentes se den cuenta de que hay algo mal.
Todd A. Jacobs
usuario1847726
jmort253
usuario1847726