Solo un equipo está haciendo Scrum, pero el resto de la empresa (incluidas las ventas, la administración, los recursos humanos) todavía piensan a la antigua usanza. Ejemplos:
La interacción continua con el cliente y la participación del cliente es muy importante.
RR.HH. debe comprender que el desempeño del equipo es más importante que el desempeño de las personas. KPI debe cambiar a eso.
La definición de características es un proceso continuo. La definición del proyecto evolucionará durante el desarrollo por los comentarios de los clientes. Debido a la fecha límite del proyecto, el presupuesto requerido o el conjunto de características de resultados pueden cambiar (después de la aprobación de las partes interesadas).
El cambio es parte del proceso.
La estimación es un proceso continuo que no puede decir al comienzo del proyecto que terminará con todas las funciones (muchas de ellas desconocidas al principio) dentro de los 5 meses.
El equipo está facultado para tomar decisiones. El equipo se compromete a la cantidad de características entregadas durante el próximo sprint. Esto no se puede exigir ni ordenar.
Sprint es zona segura para el equipo. Una vez que el equipo se compromete con algunas historias de usuario definidas, el compromiso no puede modificarse fuera del equipo.
Parte de la antigua estructura de la organización no tiene sentido cuando se cambia a Scrum. Scrum define tres roles: Scrum master, Product owner, team. Hay otros roles, pero estos tres suelen ser suficientes para entregar la aplicación. El sentido común es tener Scrum master, líder de equipo, propietario de producto y uno o más gerentes de proyecto. El gerente de proyecto y el líder del equipo son roles redundantes en Scrum.
The most basic approach is including analysis and documentation in acceptance criteria for user stories.Esa es mi reacción inicial también. Si la historia tiene criterios de aceptación, esa es la mejor documentación que puede tener. Pero si el equipo decide crear algunas documentaciones adicionales (piense en README en el tronco o en un wiki con información útil), entonces no veo ningún problema. Creo que la gente teme que SCRUM = nada se escriba nunca.El mayor problema que he notado en más de 10 años de xp y scrum, es cuando los equipos que aún no se "agilizan", deciden "ser flexibles con respecto a lo ágil" y comienzan a personalizarlo, dejando caer ciertas partes, etc., sin Una comprensión clara de lo que hace cada parte y por qué está allí.
He visto que los equipos tienen más éxito con scrum cuando hacen las cosas según el libro al principio, que los equipos que cambian lo que todavía no "entienden".
Ahí es cuando obtienes cosas como "primer sprint, haremos todos los requisitos. Segundo sprint todo el diseño, etc., etc., último sprint todas las pruebas". También conocido como cascada. O incluso cosas simples como "vamos a sentarnos de todos modos, ¿qué pasa con este negocio standup?".
Algo que ver con Shuhari ( http://c2.com/cgi/wiki?ShuHaRi ).
fuente
El mayor problema es siempre la aceptación. Si algún equipo o personas clave no han comprado (gestión de proyectos, control de calidad, desarrollo, etc.), entonces el fracaso está casi asegurado.
Otro problema relacionado es hacer que todos los involucrados sean conscientes de qué es el scrum real y qué no.
He visto entornos en los que la gestión de proyectos realmente ha tomado esto como un boleto para llegar directamente a los desarrolladores con los cambios y espero que se haga mañana, ya que estamos utilizando el gran proceso nuevo. Cualquiera que haya estado en esta situación o en otros intentos fallidos de implementar Scrum y tenga un sabor amargo en la boca. Estas personas a veces tratarán de descarrilar el proyecto también.
Otro problema que he visto son las reuniones de pie. Siempre obtendrá al tipo que quiere sentarse durante una reunión de stand ... "Tengo problemas de espalda" o lo que sea. Siempre parece ser el mismo tipo que no tiene idea de cuál es el objetivo detrás del enfrentamiento, y no se callará sobre política o lo que hizo ese fin de semana. Las reuniones de pie, he descubierto, son la clave para una comunicación efectiva. Es importante no dejar que nadie envenene estas reuniones.
fuente
management has actually taken this as a ticket to come directly to developersEse es un buen ejemplo de una situación en la que el proceso SCRUM no se entiende, ¿verdad? Que el equipo no puede aceptar nuevas historias en medio de un sprint.Tratando de hacer todo el análisis para el código que estábamos desarrollando en el mismo sprint, en realidad lo estábamos codificando.
fuente
Nos mudamos a scrum hace un tiempo y, francamente, la administración que lo maneja trató cada scrum como un proceso de cascada de 2 semanas. ¡Hubo tal adherencia a las reglas de scrum que se convirtió en un proceso en sí mismo!
Este es el problema que encuentro, todas las metodologías ágiles deberían tener que ver con la flexibilidad para trabajar eficazmente de la manera que funcione para usted. No es la forma en que está proscrito por los procesos. Por ejemplo, teníamos scrums de 2 semanas, y un equipo dijo que sentían que 2 semanas no eran suficientes para hacer un buen trabajo (no con el tiempo de inactividad causado por el final de la demostración de scrum y la revisión de los requisitos iniciales), por lo que querían pasar a 3 semana. Shock horror! La gerencia se negó porque habían decidido que 2 semanas por scrum eran ideales y eso ahora estaba documentado en los procedimientos de calidad.
Scrum es el menos ágil de los métodos ágiles, y quizás por eso ha sido tan popular: es más fácil de vender a la vieja guardia. se supone que debes eliminar cosas que no te gustan, pero no creo que eso suceda. Mi consejo es ir con una más flexible, menos basada en reglas y agregar las reglas que necesita en su lugar. Prefiero Crystal por esto.
En última instancia, solo recuerda el manifiesto ágil medio arsed .
fuente
El mayor problema es que también su cliente necesita aceptar el proceso SCRUM y volverse ágil también. La mayoría de los clientes quieren escuchar esto al comienzo del proyecto:
Suena razonable, pero es absolutamente incompatible con ágil. Debe explicarle a su cliente por qué es ágil bueno para él en lugar de cascada.
fuente
how much will it cost?y esperan una respuesta detallada en ese momento. Mi respuesta a esta preocupación es siempre "si al final sabes exactamente lo que quieres, no necesitas ser ágil. Simplemente codifícalo". Pero todos sabemos que eso no va a suceder. ;-)Tuvimos dos grandes problemas en mi primer intento en SCRUM:
1) Realmente no teníamos un dueño del producto. Nuestro jefe tuvo que desempeñar el papel porque nadie que debería haber sido dueño del producto estaría de acuerdo en hacerlo. Esto hizo que las cosas se enredaran porque en realidad no siempre sabía las respuestas.
2) Fuimos malos contando componentes externos. Nuestros primeros sprints involucraron la realización de pruebas automáticas completas y en repetidas ocasiones tuvimos problemas para automatizar los simuladores que estábamos usando. De alguna manera, nunca mejoramos al darnos cuenta de que esto iba a suceder.
fuente
El principal problema que enfrento en mi proyecto es que la recopilación de requisitos se lleva a cabo después de que hayamos estimado para el próximo sprint. Estimamos en base a los criterios de aceptación. Durante la recopilación de requisitos, descubrimos que la CA ajustada es mucho más grande, por lo que la tarea inicial estimada para 8 horas ¡ahora es realmente 24 horas! Entonces, ¿puedo cambiar mi reserva de sprint y revisar las estimaciones y reducir mis historias? ¡No señor! ¡Agile requiere que no puedas cambiar el retraso del sprint! Eso es lo que dice mi TL. ¡No debería también estar codificando según los criterios de aceptación originales para los cuales había estimado el tiempo como 8 horas! ¡Dios! ¡No! No puedes hacer eso! ¡Eso no sería ágil, verdad!
fuente