Empecé a trabajar en un corredor de bolsa que me contrató a mí y a más dos desarrolladores para crear un software que los ayudara. Soy el miembro más nuevo del equipo de desarrollo. Mi amigo, otro desarrollador del equipo, me pidió que creara un modelo de ingeniería de software para aplicar en el proyecto, porque la forma en que lo están haciendo ahora no está funcionando. No tienen un modelo específico a seguir, solo deciden qué hacer verbalmente, los dos dueños del corredor de bolsa (que en este caso son los clientes) les piden que desarrollen una función para que los desarrolladores dejen de hacer lo que estaban haciendo. y empezar a trabajar en ello, no tienen una lista específica de requisitos o características que debe tener el producto...
Mi idea originalmente era intentar implementar y adaptar Scrum en los siguientes términos:
Cree una cartera de productos lo antes posible. El rol de propietario del producto sería ocupado por los propietarios de la empresa. El otro desarrollador y yo seríamos el Equipo Scrum. Uno de los desarrolladores sería Scrum Master. Tendríamos un sprint por semana. Reuniones todos los viernes para revisar el último sprint y planificar el siguiente. (Revisión de Sprint, Retrospectiva y Planificación) No veo la necesidad de una reunión de revisión diaria. Pensé que podríamos hacer reuniones esporádicas durante los sprints cuando uno de los miembros lo sienta necesario. ¿Es posible que esto vaya a funcionar? ¿Qué puedo hacer para mejorarlo?
¿Es posible que esto vaya a funcionar?
Esto está bastante basado en opiniones. Si quieres mi opinión, la respuesta es "tal vez". Thomas plantea buenos puntos sobre posibles dificultades, pero dependiendo del equipo, estos pueden superarse fácilmente. Lo que me lleva a...
¿Qué puedo hacer para mejorarlo?
"No lo sé, pruébalo y verás". La herramienta más valiosa en Scrum (y posiblemente en Agile) es la Retrospectiva. Intenta algo. Inspeccione qué tan bien funcionó. Adaptar. Los preceptos de Agile no tienen que aplicarse solo al producto. También pueden (y deben) aplicarse al proceso.
Por lo tanto, no pierda demasiado tiempo preocupándose por qué probar. Simplemente elija un proceso y pruébelo. Luego (como un equipo completo) refínelo, o simplemente deséchelo e intente otra cosa.
No use Scrum, no parece apropiado para esta situación. Escribí una respuesta en Software Engineering Stack Exchange sobre el número mínimo de personas para implementar Scrum. En este momento, usted describe el número mínimo de personas para formar un equipo Scrum (un propietario de la empresa como propietario del producto, 3 desarrolladores, uno de los cuales es el Scrum Master).
Puedo ver algunos contratiempos con este plan. En primer lugar, el Scrum Master debe poder ser un entrenador para el propietario del producto, así como para la organización: ¿puede la persona que seleccione para desempeñar este rol tener la influencia necesaria con el propietario que actúa como propietario del producto y el resto de ¿la organización? Segundo, ¿las personas que ha identificado tienen el tiempo, el conocimiento y la experiencia necesarios para funcionar como Product Owner y Scrum Master?
En lugar de Scrum, comenzaría por buscar un enfoque inspirado en Kanban.
Primero, cree un tablero para contener elementos de trabajo. Trabaje con el equipo y las personas que administran el producto para determinar qué información es necesaria para que el equipo pueda trabajar. Esto a veces se denomina Definición de Listo . En lugar de que los propietarios interrumpan el trabajo, comienzan a formular un elemento de trabajo que cumpla con la Definición de Listo. Sin embargo, es posible que necesiten la ayuda del equipo para hacer esto: reserve tiempo regularmente para manejar esto. Puede obtener orientación de las sesiones de "preparación" o "refinamiento del trabajo pendiente" de Scrum sobre cómo administrar la Definición de Listo y asegurarse de que el trabajo esté en buen estado.
Luego, priorice los elementos de trabajo. Intentaría asegurarme de que una persona tenga la última palabra en el orden de prioridad. El orden de los elementos de trabajo determina el orden en que trabajan los desarrolladores. Tan pronto como un desarrollador finaliza un elemento de trabajo, mira la parte superior de la cartera de pedidos y elige el elemento superior que es capaz de hacer, progresando de "pendiente" a un estado terminado. Es importante tener límites de trabajo en curso (WIP) establecidos y aplicados.
En general, los principios de Lean Software Development deberían ser útiles. Sus actividades de planificación, revisión y retrospectivas deben realizarse de manera adecuada. Puede elegir un enfoque más parecido a Scrum, donde esto ocurre con una cadencia regular. O puede elegir un enfoque en el que sucedan según sea necesario.
Si tiene un trabajo atrasado decente, buenas definiciones de "listo" y "terminado" para las historias y buenos hábitos de planificación, revisión y retrospectiva, debería poder escalar su proceso. Si su equipo crece, puede considerar adoptar un marco como Scrum. Si comienza a crecer a varios equipos, puede buscar otros marcos como Nexus o LeSS para escalar Scrum. También puede aprender de Disciplined Agile Delivery con respecto a la adaptación y el crecimiento de su proceso.
alan larimer