¿Cuál es su experiencia de la vida real, quién debería ser responsable de una selección de herramientas de planificación ágil para ser utilizada por el equipo ágil/scrum?En equipos ágiles/scrum que es responsable de la elección de las herramientas de planificación ágil
El equipo debe decidir si se va a utilizar una herramienta; pero creo que la sugerencia más comúnmente proviene del Scrum Master ya que es más probable que tenga experiencia en el uso de herramientas. Cualquier miembro del equipo puede sugerir herramientas, por supuesto.
De todos modos, mi sensación es que, dada la filosofía de Scrum, todo el equipo debe ponerse de acuerdo sobre esto en mi opinión. Por lo general, las cosas comienzan con "probemos esto, veamos si funciona", y se refina a lo largo del camino, como cualquier otra cosa en Scrum. No debe ser una aplicación de arriba hacia abajo, del mismo modo que el uso de la metodología de Scrum debe ser una decisión del equipo, no transmitida desde la parte superior.
"En caso de duda, pregúntele al equipo" – kenwarner
@qntmfred Creo que es más importante tener la actitud de "probemos esto, ver si funciona" con mucho sentido común, que dejarlo totalmente al equipo y preguntarles . Scrum es tan transparente que, si forma un equipo interdisciplinario de idiotas que no saben nada sobre el desarrollo de software, elegirán una herramienta horrible, tomarán decisiones idiotas y producirán software deshonesto, Scrum lo hará consciente de esto después de 1 iteración (2 semanas o un mes) y luego algunos inspeccionar y adaptar cambiarán las cosas. – sjt
Mi punto es que las decisiones deben tomarse usando el sentido común. Una organización no debe simplemente seguir ciegamente la decisión de los Equipos, especialmente en el caso de un equipo inexperto. ¿Qué pasa si el equipo no tiene suficiente experiencia en ese campo? Lo más probable es que elijan una herramienta horrible y pierdan un mes averiguándolo. Que así sea, pero ¿por qué perder un mes cuando puede obtener sugerencias de alguien que tiene más experiencia en ese campo? En cambio, el Equipo debe estar abierto y tomar sugerencias si es necesario, y tomar una decisión basada en eso. Una buena persona para tomar sugerencias es un experimentado ScrumMas. – sjt
Gran pregunta. Hay mucho valor para abrazar la auto organización de ágil y permitir que los equipos elijan sus herramientas. Sin embargo, generalmente hay restricciones impuestas por el negocio. Por ejemplo, es posible que la empresa no pueda apoyar/querer que cada equipo de scrum desarrolle su propia solución scm. Cuanto más establecido es el negocio, más restricciones y retrocesos. Incluso las empresas establecidas pueden cambiar. No tema cuestionar una restricción si el equipo puede justificar el cambio.
Las herramientas de planificación Agile seguirán estas mismas reglas. Es posible que la empresa tenga una solución completa de gestión del ciclo de vida del software. Esta solución puede tener o no un módulo ágil. Sin embargo, la empresa puede tener razones (industrias reguladas, por ejemplo) para exigir que las entradas/salidas de diseño estén documentadas en la solución de software de gestión del ciclo de vida que tienen. Por lo general, la empresa necesita equilibrar mantener contentos/productivos a los equipos para mantenerse en el negocio.
No creo que haya una solución en blanco y negro (a menos que sea uno de los primeros desarrolladores en una puesta en marcha). Los equipos ágiles deberán abrazar la comunicación abierta. Si las herramientas son impedimentos que la empresa necesita saber.
¿Cuál es su experiencia en la vida real, quién debería ser responsable de una selección de herramientas de planificación ágil para ser utilizada por el equipo ágil/scrum?
Bueno mi experiencia de la vida real es que, ciertos instrumentos "ágiles herramientas de planificación" fueron entregados a los equipos de Scrum antes de que incluso comenzaron sus Sprints, afortunadamente, los equipos gustó, pero que eran libres para inspeccionar y adaptarse a las usando algo más si no funcionó para nosotros.
Creo que debe estar en el poder de los equipos para usar, aceptar o rechazar una herramienta de una manera completamente transparente. Podrían tomar sugerencias del Scrum Master o de un Coach Ágil porque podrían tener más conocimientos en el área de Herramientas Ágiles. En segundo lugar, el Equipo debe ser lo suficientemente valiente como para tener una discusión colectiva y decidir usar una herramienta basada en las sugerencias de Agile Coach, y ver cómo funciona para ellos, y adaptar y ajustar su uso si no funciona para ellos (productividad -wise)
la pregunta más grande que tú no preguntar es, ¿cómo manejar el conjunto de herramientas diferentes caos cuando la empresa escalas en tener múltiples equipos Scrum que utilizan sus propias herramientas rápida planificación ?. Bueno, creo que, en una compañía de software ágil de escalado, un poco de uniformidad en el uso de herramientas en los equipos Scrum puede ser beneficioso y productivo, pero puede ser dirigido por el equipo de proyecto empresarial autoorganizado en lugar de que cada equipo tenga sus propias herramientas . Por supuesto, puede haber excepciones, donde ciertos equipos están trabajando en funciones completamente diferentes y necesitan un conjunto de herramientas totalmente diferente, pero el beneficio de usar herramientas comunes de Agile ayudará a los proyectos de escala a ver el progreso de sus Equipos sin mucho cambio de marcha.
Lo anterior puede hacerse teniendo una historia técnica, de infraestructura y de herramientas de proceso que no muchas compañías usan o crean. Esta historia de EPIC puede ser el punto de partida para la discusión sobre qué herramientas Agile y otras herramientas se pueden usar, para tener una pequeña uniformidad dentro del proyecto. Al derivar la historia de EPIC, todo el equipo del proyecto podría participar en el inicio del proyecto, si es demasiado grande, entonces 1 - 2 miembros pueden representar a cada uno de los equipos. La historia podría ser desglosada exactamente como las historias de usuarios de negocios, y modificada en consecuencia y calibrada, estimada y priorizada a través del proyecto desde un punto de vista de infraestructura y herramientas. Avísame si quieres que vaya con más detalle sobre esto.
Voy a hacer una respuesta simple, porque en realidad creo que esta es una pregunta simple.
El equipo de WHOLE es responsable de eso.
Déjame explicarte un poco. Primero tenemos que aceptar que cada contexto es diferente, por lo que esta no es una respuesta bíblica.
Digamos que usted comienza su proyecto. Siempre amo comenzar mis proyectos/productos sin nada. NADA. A veces, solo un tablero de tareas, con todo, en proceso, hecho.
Eso es todo. Y llené la columna Todo.
Y ese es todo mi punto: construyo mi proceso ágil de forma incremental e iterativa. ¿Por qué debería crear un gráfico de quema? Porque la alfabetización me lo dice?
Infierno no, porque, tal vez, eventualmente, en algún momento, podría necesitar algo de visibilidad para mi planificación.
Lo mismo con todo. Y nunca olvides que las herramientas ágiles sirven de soporte para el proceso.
Entonces, eres un PO, estás cansado de la lista de tareas pendientes, ¿y no necesitas hacer una lista de espera? 2 Soluciones: - usted ya está en un equipo altamente maduro, solo tiene que decirles a todos durante la reunión de pie que usted está tomando la iniciativa. Eventualmente, necesitará una retrospectiva para aceptar eso. - está migrando desde un V, W o cualquier modelo de gestión de productos. Luego, espere la retrospectiva y pregunte a todos y explique su dolor. Da solución (aquí la cartera de pedidos) y pide una oportunidad.
Así que, usted es un maestro del scrum, y encuentra un "error sistémico" en su proceso, tomemos el clásico: Demasiados errores. Luego tome la iniciativa para promover TDD o pruebas sistemáticas.
Entonces, eres un líder tecnológico y te sientes ... Bueno, me entendiste.
Mi punto es: nunca sobre la herramienta de su proceso al principio. Desarrolle el proceso lentamente, agregue herramientas lentamente, cuando las necesite. Y al hacerlo, no se preocupe, las personas tomarán responsabilidad para crear la herramienta y agregarla al proceso, para cabildear ante el resto del equipo.
Espero que esto ayude.
Error típico que experimenté como entrenador fue la decisión tomada por los gerentes o incluso la alta dirección según algún estudio realizado por un "especialista" o incluso consultor externo. Esas personas muchas veces no están al tanto de qué, cómo y quién usará la herramienta. En este caso, veo personas decepcionadas una vez que deberían usar la herramienta elegida.
Debe tener en cuenta quién va a utilizar la herramienta la mayor parte del día. Los miembros del equipo son una mejor comunidad objetivo. La herramienta debe ser compatible con el rol de ScrumMaster debido al trabajo diario que necesita hacer. Incluya a los propietarios de productos experimentados en la selección de la herramienta, ya que las herramientas tienen un soporte diferente para la planificación que es necesario usar.
Tenga en cuenta su organización (complejidad de los productos, proyectos, número de localizaciones)
ideal sería que el scrum master, pero pueden heredar algún legado, que necesita un poco de la evolución.
Si la organización es nueva en Scrum, un Scrum Master experimentado debería poder aconsejar las mejores herramientas para la madurez del equipo.
Normalmente, si un equipo ya tiene algunas herramientas, un scrum master puede adaptar lo que ya existe, independientemente de la opción de la organización. Algunas de las mejores tarjetas están en hojas de cálculo de Excel y funcionan tan bien como un sistema especialmente diseñado. Toda tecnología crea 'restricción'. Por lo tanto, le corresponde al maestro de scrum apoyar al negocio para garantizar que las herramientas sean adecuadas para el propósito y entreguen el valor que el equipo necesita.
La responsabilidad (y la autoridad) de la elección de una herramienta de planificación debería estar con el equipo . A menudo, la organización circundante tendrá una participación en términos de costos de licencias y consistencia entre los equipos. Dependiendo de cuán autónomos sean sus equipos, debería estar bien que ellos elijan su propia herramienta.
Dentro del equipo, el propietario producto por lo general tiene la mayor participación en la decisión, ya que será el que se va a usar al máximo para el refinamiento continuo y priorizar. El resto del equipo a menudo solo interactúa con la herramienta de planificación durante las sesiones de refinamiento y planificación una o dos veces en cada carrera. Por lo general, él es quien impulsa la toma de decisiones, pero definitivamente debe involucrar al equipo.
Si la herramienta elegida también incluye una pizarra que el equipo usa a diario para seguir su trabajo, querrán tener más voz en la elección.
Esta pregunta no está relacionada con el tema porque no está dentro del alcance de este sitio, como se define en [¿Qué temas puedo preguntar aquí?] (// stackoverflow.com/help/on -topic) También vea: [Qué tipos de preguntas que debo evitar preguntar?] (// stackoverflow.com/help/dont-ask) Puede solicitar en [otro sitio de Stack Exchange] (// stackexchange.com/sites#name), por ejemplo [ pm.se] o [softwareengineering.se]. Asegúrese de leer la página del tema en el centro de ayuda de cualquier sitio en el que desee publicar una pregunta. – Makyen