Actualmente soy desarrollador en una pequeña empresa de desarrollo de software y estamos comenzando a adoptar filosofías Agile (específicamente, Scrum) en nuestra cultura y estilo de gestión de proyectos. Solo tenemos unos pocos desarrolladores, por lo que es importante optimizar el trabajo facturable y la eficiencia.
Por experiencia personal, nuestros desarrolladores siempre tienen más trabajo que nuestros diseñadores, quienes, empíricamente, tienen un 60% menos de trabajo en promedio por proyecto. Si se estima una sola historia de usuario en función de un esfuerzo unificado (contribución de puntos de historia), veo que surgen algunos problemas:
Por lo que puedo decir, esto da como resultado un sprint que comienza con un desequilibrio significativo de trabajo, que se inclina hacia los desarrolladores. Esto no será evidente debido a una estimación unificada.
En cambio, ¿es mejor estimar a nivel de persona y detenerse cuando los desarrolladores tengan un sprint completo? Claro, los diseñadores aún terminarán temprano, pero al menos se sabe por su propia velocidad personalizada.
Scrum estricto puede decir que el diseñador debe trabajar para agregar valor adicional de formas alternativas (refinamiento, deuda de código en el CSS, etc.) pero dado que somos pequeños, debemos asegurarnos de que cada hora que invertimos sea significativa , justo a tiempo. valorar.
EDITAR: Esto podría resultar en un fenómeno de corte continuo de historias en áreas equivalentes, hasta cierto punto, pero no creo que ese sea el punto.
tratando de entender esta pregunta, así que perdóname si me equivoco. Voy a abordar esto asumiendo su facturación como equipo. También voy a asumir que un diseñador es una persona de interfaz de usuario.
El equipo tiene una velocidad, no los individuos. Por lo tanto, la planificación de su sprint debe centrarse en lo que todo el equipo puede gestionar en el sprint. Si sus desarrolladores son su limitación, entonces el sprint está planificado para esa limitación.
Si intenta programar el trabajo para cada área funcional, puede desincronizarse rápidamente y causarse más problemas. Esto sucede a menudo cuando las empresas intentan volverse ágiles mientras mantienen el control de calidad como un sprint separado o incluso más tarde en el mismo sprint de desarrollo. A menos que un equipo de control de calidad tenga una automatización completa, rara vez puede mantenerse al día con un equipo de desarrollo de alto rendimiento. Entonces, el equipo de desarrollo se adelanta cada vez más al control de calidad y eso significa que pasa más tiempo desde que se crea un error hasta que se identifica. Cuanto más tarde lo identifique, más difícil será solucionarlo.
Entonces, volviendo a su ejemplo, si sus diseñadores pueden hacer todo el trabajo que necesitan hacer en la mitad del tiempo que lo hacen los ingenieros, entonces tiene demasiados diseñadores o no hay suficientes ingenieros para la planificación. Varias soluciones para esto, que incluyen: - Capacitación cruzada: los diseñadores podrían aprender el trabajo de prueba o codificación. Un equipo fuerte y ágil tiene la capacidad de desempeñar más de un rol. - Comparte tus diseñadores. Digamos que tiene dos proyectos de ingeniería, haga que los diseñadores trabajen en ambos. Esto no es ideal, ya que llama la atención, pero a menudo sucede con recursos compartidos como base de datos, localización y demás. - Contrate más ingenieros: obtenga suficientes ingenieros para mantenerse al día con los diseñadores, envíe más productos más rápido. - Reducir el número de diseñadores: uno de esos elefantes en la habitación de los que nadie quiere hablar. No lo hace menos válido, sólo menos deseable.
Joel Bancroft-Connors
Joel Bancroft-Connors
Daniel
AdrianGW