Cuando un equipo logra el consenso sobre algún tema significa que el grupo apoya la decisión; no tienen que pensar todos que sea la mejor decisión, sino que todos acuerdan poder vivir con ella. Puño hasta Cinco es una herramienta muy facil para crear consenso en los equipos.
¿Están preparados? Aquí está el secreto... para ser ágil deben... ¡romper todas las dependencias a cualquier costo!
Las depedencias se crean cuando dos elementos discritos dentro de la organización se necesitan mutuamente para hacer parte (o todo) de su trabajo. Las dependencias están por todos lados a nivel organizacional. Son creadas por la forma en la que estructuramos el negocio y cómo preaparamos y ejecutamos el trabajo de nuestros proyectos. Esto hace que sea muy dificil identificarlas, y más dificil todavía eliminarlas.
Introducir una metodología nueva para el desarrollo de software tiene todo su propio conjunto de desafíos, que van desde "resistencia al cambio" hasta "técnicas mál adoptadas", que pueden llevan al fracaso. Varias empresas pasaron por estos desafíos cuando comenzaron a implementar Scrum. Conocer estos desafíos y contar con una estrategia para superarlos puede hacer que la adopción resulte más facil para las organizaciones.
Repasemos entonces los 9 desafios más importantes que deberá enfrentar una organización al comenzar con Scrum.
Hacer una buena Retrospectiva en las metodologías ágiles puede ser dificil. Muchas equipos tienen la sensación de que ocurrieron varias interrupciones durante la iteración que fueron causadas por personas "externas" al equipo. Sin embargo, muchas veces nadie puede dar ejemplos concretos y todos tienen apreciaciones diferentes. Ni siquiera, luego de toda la iteración, se tiene en claro qué ocurrió, más allá de una sensación vaga de molestia.
Entonces, ¿cómo podemos manejar esto? Muy facil, ¡con una víbora en la pared!
En un reciente debate en la lista ScrumDevelopment explican la forma en que las prácticas de desarrollo ágil que benefician directamente a las personas involucradas. El consenso fue que un ambiente ideal para el crecimiento individual puede ser creado por la implementación de prácticas ágiles tales como inspeccionar-y-adaptar, programación en parejas, TDD, constante colaboración y comunicación.
Arturo Pérez inició el debate preguntando: "¿Qué es lo que Scrum (u otro método Agil), ofrece a una persona que busca mejorar?" No pasó mucho tiempo para las respuestas empiezaran a llegar.
Usar puntos u horas es un debate recurrente cuando se adoptan métodos ágiles. Así que decidí escribir un artículo sobre el tema que se puede descargar aquí. En este artículo quisiera recordar los porqués de estimar y explico el sistema de puntuación de Fibonacci.
Medir tamaño/esfuerzo y no tiempo tiene varias ventajas que se enumeran a continuación. Recuerde que también es posible ser ágil utilizando medidas de tiempo, como hombre/día (HDia) para clasificar el costo de sus historias y, para tratar de ser imparcial, listo algunos inconvenientes de la utilización de puntos.
El Control de Cambios es un proceso común en la gestión tradicional de proyectos para gestionar los cambios. En un proyecto tradicional el control de cambios suele consistir en llenar un formulario detallado de petición de cambios, que incluye atributos como detalles del cambio, impacto al proyecto, riesgos, mitigación, etc. También necesita la aprobación de varias personas. El control de cambios tradicional queda fuera de lugar en las metodologías ágiles porque entra en conflicto con el principio de "Responder al cambio por sobre seguir el plan". Se torna dificil poder responder al cambiol cuando deben completarse formularios extensos y se necesitan listas de aprobaciones.
¿Cuándo y cómo debe hacerse un seguimiento de cambios en Scrum? ¿Cuál es la mejor forma?
Los talleres son un formato muy común en la educación, útiles para la transmisción de información y la adquisición de capacidades.
Sin embargo, muchas veces se desaprovechan y malgastan todo el potencial de aprendizaje que pueden ofrecer los talleres. De hecho, muchos talleres no funcionan como tales: los participantes están callados, se convierten en asistentes pasivos; el coordinador del taller da una "charla" al grupo; y están ausentes las preguntas y discusiones.
Veamos juntos qué es un taller exactamente, y qué podemos hacer para crear talleres verdaderamente efectivos.
En su discurso en la conferencia Prácticas de Desarrollo Ágil, Brian Marick describe los valores que faltan en el Manifiesto Ágil. Su opinión es que el Manifiesto era esencialmente un documento de marketing, con el fin de obtener que las propias empresas le dieran una oportunidad a la agilidad. Ahora que gran parte de ese objetivo se alcanzó, un amplio conjunto de valores son necesarios para ayudar a los equipos a cumplir las promesas del manifiesto.
Al comenzar a desarrollar usando la técnica de Desarrollo Guiado por Tests (TDD - Test Driven Development) es común preguntarse qué hacer con los métodos privados. ¿Cómo se deben probar? ¿Qué ocurre con estos métodos que no podemos acceder directamente desde las pruebas unitarias?
Si realmente estamos haciendo TDD, los métodos privados tienen cobertura garantizada. Cuando el diseño y la implementación en el código se guia a partir de las pruebas unitarias, ningún método se crea como privado. En cambio, los métodos privados se extraen (el refactor) de un método público ya existente.
La siguiente historia les puede resultar de interés si son nuevos en las metodologías Ágiles, o si están planeando adoptar ágil con todo entusiasmo.
La empresa Xlabs comenzó la adopción de Ágil con grandes anuncios. Contaba con el apoyo de la alta gerencia, y el equipo estaba convencido sobre el valor y los resultados que lograrían. Pero luego de cuatro iteraciones, Xlabs comenzó a sentir que las cosas no estaban resultando como habían esperado. Intentaron algunas iteraciones más, logrando resultados aún más decepcionantes. Finalmente llegaron a la conclusión de que Ágil estaba sobrevalorado, y que sólo servía para algunas organizaciones. Decepcionados por los resultados, volvieron a la forma que venían haciendo las cosas, en cascada. Sin embargo, la gerencia había leído varias historias de éxito de todo el mundo usando desarrollo ágil, y decidieron averiguar la causa raíz de lo que salió mal.
Luego de una semana de investigación por un equipo dedicado, encontraron el error principal con la forma que habían adoptado Ágil. XLab no conocía el concepto de Shu-Ha-Ri, y por lo tanto adoptaron Ágil de una manera incorrecta, lo que llevó al fracaso.Entonces, ¿qué es Shu-Ha-Ri, y por qué es tan importante?
Nuevo logo, nuevo buscador, nueva portada, podcast mensual... ¡y muchas novedades más!
"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"
Bernard Shaw