¿Qué grupos deberían participar en Agile?

Question

En mi empresa, todos los programadores, desarrolladores, diseñadores y equipos de UX participan en grupos Agile. No soy un maestro ágil, pero entendí que todos los miembros de un equipo deberían ser capaces de hacer cualquier parte del trabajo. Hacer que los diseñadores, el equipo de UX, los desarrolladores frond y los administradores de sistemas se unan a una votación para estimar cuánto tiempo llevará una tarea de back-end me parece una locura. ¡Apenas sé! Entonces mi pregunta es ¿soy demasiado duro? ¿Puede esto funcionar en un entorno Agile?

Answer 1

Tiene el concepto de base equivocado ... todos los miembros deberían poder trabajar a través de las historias. No funcionalidad cruzada total ... un desarrollador no puede emerger repentinamente como diseñador de UI.

Y no. de miembros por equipo está limitado a 7 -10. Entonces ese grupo debe ser segmentado en consecuencia.

Answer 2

La respuesta corta es sí.

Incluso los equipos de desarrolladores puros tenderán a autoorganizarse en especialidades o propietarios de subsistemas específicos (a menos que tengas que obligarlos a rotar el trabajo, pero ese es un tema para un problema diferente). Por lo tanto, estará estimando historias con un número significativo de miembros en la sala que tienen poco conocimiento del trabajo del subsistema asociado con la historia.

Se supone que la estimación de la historia se trata más de comparar escalas de complejidad/trabajo. Es dos veces, cuatro veces, ocho veces (o escalas similares) más trabajo que el punto base definido. O, ¿es similar a este otro artículo que calificamos en ocho? Al menos ese es el objetivo. En el nivel de sprint (versus backlog general), encuentro que los equipos prefieren estimar con escalas más concretas (es decir, horas).

Para personas en disciplinas específicas, puede o no desear que se incluyan en el proceso de estimación. Si esas personas tienen una comprensión razonable de la complejidad de la tarea, las estimaciones pueden ser tan buenas como la de otro miembro. De lo contrario, no deberían proporcionar una estimación.

Uno de los beneficios de incluir sus estimaciones ya que a menudo crea estimaciones más alejadas (demasiado altas o bajas). Cuando tenemos un artículo con estimaciones fuera de un sobre razonable, es un desencadenante para tener una discusión corta, pero más profunda del trabajo. A menudo, esa discusión obliga a un grupo a descubrir el trabajo/la complejidad que no era obvio a partir de la descripción de la historia y los criterios de aceptación.

Answer 3

Se supone que los equipos ágiles son "multifuncionales", es decir, tienen muchos especialistas trabajando en conjunto con algunas superposiciones.

Para el desarrollo web, e incluso para la infraestructura de TI, puede tener sentido tener un DBA, diseñadores, analista de negocios, programadores (cualquiera que sea el conjunto de habilidades que necesite) y personas de infraestructura de TI en el mismo equipo.

No todos los miembros del equipo tienen que estar trabajando en él a tiempo completo - pero cualquier departamento o especialidad que podrían retrasar el proyecto o causar malentendidos por no estar involucrado tiene que ser representado por alguien con suficiente poder o la habilidad para hacer esas acciones.

No se olvide de involucrar a la gente:

• que necesitan para firmar cosas,
• personas que administran las instalaciones comunes, como DNS, LDAP
• administrador de red
• personas que compran y mantienen hardware,
• gente de seguridad ...

He estado involucrado en proyectos donde el software estaba listo a tiempo, pero el DNS o el hardware no lo estaban, lo que es un error en lo que respecta al cliente. ¿Qué cosas fuera de tu control necesitarás? Los líderes del equipo, los entrenadores y los maestros del scrum deberían estar mirando una o dos iteraciones para involucrar a las personas adecuadas.

Conseguir todas las personas adecuadas que participan en las estimaciones y reuniones iniciales - incluyendo ventas técnicas y el negocio es crítica. ventas Tech pueden pensar que no pueden ayudar pero a menudo pueden responder preguntas sobre lo que el cliente quiere que puede ayudar a crear un consenso en las estimaciones.

Answer 4

ágil se trata de la cooperación y el sentido común. Dicho eso, creo que básicamente se reducirá al equipo real. ¿Pueden cooperar de manera eficiente? De lo contrario, es posible que tengas que arreglarlo. ¿Qué te dicen tus retrospectivas? Agile es una ruta, no el destino

Hoy en día, con todas las tecnologías mixtas que deben trabajar juntas en un producto, todos los desarrolladores deben tener una visión más amplia de cómo su parte interactúa con el resto del producto. Creo que hacer que un equipo se mezcle es bueno, pero lograr que el equipo hable abiertamente y trabaje en conjunto no siempre es fácil. La gente puede ser difícil.

Answer 5

En mi empresa, todos los programadores, desarrolladores, diseñadores y equipos de UX participan en grupos Agile. No soy un maestro ágil, pero entendí que todos los miembros de un equipo deberían ser capaces de hacer cualquier parte del trabajo.

IMO, esto es un malentendido. Al ser un equipo multi-funcional no significa que cada persona del equipo debe poder hacer cada trabajo. Significa que el equipo debe ser una combinación correcta de personas con las habilidades correctas (en conjunto) trabajando hacia un objetivo común. En otras palabras, Agile no está buscando una persona con todas las habilidades, Agile no está en contra de la especialización. Todos no pueden y no serán igualmente buenos en todo.

Tener diseñadores, el equipo de UX, desarrolladores finales fronda, y sys administradores se unen en una votación para estimar cuánto tiempo una tarea de fondo tendrá parece una locura para mí. ¡Apenas sé! Entonces mi pregunta es ¿soy demasiado duro? ¿Puede esto funcionar en un entorno Agile?

En primer lugar, al utilizar el póker de planificación, nada indica que debe haber convergencia en la primera ronda. En realidad, creo que tener divergencias es bueno, solo deja que las personas expliquen por qué votaron de esta manera, con sus certezas y sus dudas, y ve a la siguiente ronda. Independientemente del área de experiencia de las personas, apuesto a que no tomará más de 3 rondas para encontrar un consenso. En segundo lugar, después de unas pocas iteraciones, usted tiene suficientes datos históricos para comparar contra ("esta historia es como éste") y esto le ayudará mucho, independientemente de la especialización de los miembros del equipo.En tercer lugar, como lo recuerda el JeremyMcGee en un comentario, los miembros del equipo obtendrán una mejor comprensión de lo que está sucediendo y de los roles de los demás, lo cual es otro gran efecto. Por lo tanto, para mí, sí, esto puede funcionar y tener diferentes habilidades es una fortaleza, en realidad no es una debilidad.