Desarrollo iterativo y la mejora continua

Una de las ventajas que presenta scrum como metodología de desarrollo de software, es que el desarrollo se organiza de manera iterativa e incremental, estableciendo de esta manera un proceso que está dividido en etapas y permitiendo obtener al final de cada una un producto potencialmente productivo con las funcionalidades mínimas y mas importantes y además estable.

Dividimos entonces el desarrollo en varias iteraciones llamadas Sprints, donde al final de cada uno no solo obtendremos un producto terminado, sino que contamos con la posibilidad de mejorar nuestro proceso de una manera continua, realizando una reunión de retrospectiva para evaluar lo que ha ocurrido en el último Sprint y proponer cambios para el siguiente. Al final del desarrollo podemos también realizar una reunión para evaluar el resultado del proyecto en su totalidad.

Estos conceptos para la calidad y mejora no son para nada una novedad y no fueron utilizados por primera vez con el manifiesto ágil, ni para el desarrollo de software iterativo ideado para responder ante las debilidades del modelo en cascada.


El cíclo de Shewhart

Walter Shewhart entre 1930 y 1940 ideó una técnica para organizar el trabajo y seguimiento de proyectos de cualquier tipo.

Es un procedimiento valioso que ayuda a perseguir la mejora en cualquier etapa.
La razón para estudiar los resultados de un cambio consiste en tratar de aprender a mejorar el producto de mañana, o la cosecha del año que viene.

De esta manera, el paso 4 del circulo nos llevará a:

a) Mejorar en cualquier etapa
b) Satisfacer mejor al cliente en esa etapa.

Puede que los resultados no indiquen ningún cambio, por lo menos por ahora.
También se puede hacer un bucle entre tres o mas etapas, para mejorarlo todo estudiando la interacción de los cambios sobre una o mas etapas del ciclo de Shewhart otra vez.

Por último es importante tener presente que cualquier actividad y cualquier trabajo forma parte del proceso. Cualquier proceso dividirá el trabajo en etapas y en cada etapa hay un cliente, la etapa siguiente.
La etapa final enviará el producto o el servicio al cliente final que es quien compra el producto o servicio.

Al Ciclo de Shewhart se lo conoce también como el Ciclo de Deming ya que fue éste quien lo implementó exitosamente en Japón en 1950.



Referencias:

Edwards Deming, Calidad, productividad y competitividad. La salida de la Crisis.
1989, ediciones Diaz de Santos SA

Paradigma Dominante I

Si ya decidiste implementar Scrum en tu organización, es porque habrás escuchado o leído sobre el tema, y estas seguro de que te va a ayudar a gestionar los proyectos de manera ágil, donde los equipos de desarrollo son autogestionados, incorporando funcionalidades de forma iterativa e incremental, entregando valor en cada iteración y mejorando el proceso de desarrollo continuamente. Nada mas cierto que esto. El resultado que conseguirán en cada proyecto será notable.

Pero, para que esto suceda, deben darse algunas condiciones. Scrum es bastante fácil de aprender y bastante dificil de implementar.
Esto es cierto, y en algunos casos costará más y en otros casos costará menos.

¿Donde puede estar entonces el inconveniente?
¿Acaso no todos los que implementaron scrum lo hicieron de manera exitosa?
La respuesta es no.

El primer impedimento que tendrás que enfrentar a la hora de implementar Scrum o alguna otra metodología, y que nadie te ha contado, es el Efecto Paradigma.

Los paradigmas son ideas, pensamientos y creencias incorporadas que se aceptan como verdaderas o falsas sin ponerlas a prueba de un nuevo análisis.

El problema está ocasionado por lo que se denomina Paradigma Dominante y se refiere a los valores o sistemas de pensamiento en una sociedad estable, en un momento determinado.

Para muchas organizaciones, su concepción de paradigma se acerca al de cultura organizacional, ya que se refiere a la forma como se han venido haciendo y se hacen las cosas aquí y a la forma como se seguirán haciendo.

En la próxima entrada te contaré las condiciones que facilitan que un sistema de pensamiento pueda convertirse en un paradigma dominante y poder así Romper ese paradigma.

Estimaciones ¿Por qué terminan siendo incorrectas?

Mientras participaba en una discusión sobre prácticas en gestión de proyectos de software, surgió el tema que nos afecta a todos y que parece no tener solución.
Tanto si formas parte de un equipo de desarrollo como si gestionas proyectos de software, te has tenido que enfrentar con las estimaciones, que por lo general terminan siendo incorrectas.

Según Shari Lawrence Pfleeger en su libro Ingeniería de Software teoría y práctica, hay muchas razones por las que se hacen estimaciones incorrectas.
Una investigación llevada a cabo en 150 empresas, indica que el 35% de los gerentes afirmaron que las estimaciones fueron insatisfactorias por las siguientes causas:

- Pedidos frecuentes de cambio por parte de los usuarios
- Tareas pasadas por alto- Pérdida de comprensión de los usuarios de sus propios requerimientos
- Análisis insuficiente cuando se desarrolla una estimación
- Pérdida de coordinación del desarrollo de sistemas, servicios técnicos, operaciones, administración de datos y otras funciones durante el desarrollo
- Pérdida de un método adecuado o guías para la estimación

Incluso se menciona el tema de los costos ocultos, por ejemplo que a veces se necesita un mínimo de espacio y silencio para trabajar, no recibir llamadas, visitas, etc, etc.

Todas las metodologías que se utilicen para estimar, ya sean los 38 factores de productividad de Walston y Felix, el metamodelo de Bailey y Basili, COCOMO I y COCOMO II de Barry Boehm e incluso las estimaciones en puntos de historia para nuestros proyectos ágiles, requieren de experiencia acumulada. O sea, muchos proyectos que el equipo haya realizado junto.

Todavía recuerdo cuando estimamos nuestro primer proyecto con Planning Poker asignando puntos de historia. No teníamos la menor idea de cuantos puntos ponerle a cada historia de usuario.En el segundo proyecto ya arrancamos con las métricas de velocidad del primero. En el tercero fue aún mejor.

Es cuestión de experiencia y sobre todo tener presente que las estimaciones en equipo son siempre mas precisas que la estimación de un solo experto.

De todas formas voy a diferir con uno de los puntos mencionados en el libro.
No creo que un problema se deba a que los usuarios no saben lo que quieren o a la pérdida de comprensión de sus propios requerimientos, ya que es nuestra tarea guiarlos para que se puedan bajar correctamente sus necesidades y transformarlas en requerimientos.

¿Que opinan ustedes?

Herramientas Ágiles I

Buscando alguna herramienta para gestionar proyectos de manera ágil, encontré el TAIGA, desarrollado por la empresa española KALEIDOS.

Características:

Fue desarrollada utilizando Python, Django, Postgresql para el backend y Angular-JS para el frontend.

Puede utilizarse como servicio en su propia infraestructura o descargarse el código fuente de su repositorio en github e instalarlo en servidores propios.

La licencia con la cual se ha publicado es la Affero GPL.

Funcionalidad:

Apenas se ingresa a la aplicación, se presenta los proyectos que se han creado y la opción de crear nuevos, que aquí brinda dos posibilidades: KANBAN o SCRUM.

Aquí les dejo algunas capturas de pantalla donde se puede ver que hay dos proyectos creados
y algunas tareas de prueba.

Como verán es muy simple y posee una gráfica bastante acertada.

Pantalla inicial con los proyectos creados:

Pantalla donde seleccionamos el nuevo tipo de Proyecto:

Vista del proyecto con las tareas y los sprints definidos:

El sitio web de la herramienta: https://tree.taiga.io/login

El sitio web de la empresa:http://kaleidos.net/

Les dejo el resto para el que quiera investigar !!!

Jornadas Nacionales de Metodologías Ágiles

Te cuento que se estan organizando las Primeras Jornadas de Metodologías Ágiles en la Universidad de Belgrano los días 26 y 27 de Septiembre de 9 hs a 18 hs, son totalmente gratuitas y ya confirmaron su presencia 200 personas.
Este es el link para que no dejes pasar esta oportunidad: http://aa2014.agiles.org/

Las jornadas se desarrollarán en formato Open Space en el cual no hay una agenda preestablecida de los temas que se presentarán o tratarán, sino que son propuestos por todos los participantes al comenzar el evento.
Sin embargo, ya hay una lista de las sesiones propuestas por los que nos anotamos y son las siguientes:


Software craftsmanship y los programas de apprenticeship
El coaching Agil como una profesión
El zen y el arte de desarrollar software
El chamuyo del scrum
¿Como puede ayudar la agilidad a la educacion formal?
Refinamiento de las historias ¿Mucho, poquito o nada?
¿Agil o frágil?
Relacionamiento entre equipos de desarrollo ágil y el resto de las áreas de sistemas
Errores comunes en proyectos ágiles
Dojo de retrospectiva
Role of leadersip in Scaling Agile
Lo que queda cuando no queda nada
#OpenAllocation y #NoManagers
Reporting en ambientes ágiles. Que y como reportar
Agilidad y calidad de software
Introduccion al espíritu de la agilidad
Cooperativas líquidas: la agilidad al palo
Rol de Scrum Master como coach del equipo Scrum
Como trabajar la motivación en un equipo distribuido
Agilidad vs seguridad
Agilidad en ONGs
Practica con nuevas formas de innovación iterativa e incremental
Cual es la diferencia entre un PO y un PM



Estos temas ya están siendo votados en la página que te pasé mas arriba y vos podés hacerlo también


Espero que puedas asistir

Nos vemos allá !!!!

¿Scrum?

Hace unos años, cuando comencé a interesarme por las metodologías ágiles, leía todo lo que se me cruzaba sobre Scrum, Kanban, XP y técnicas Lean ya sea en blogs o libros impresos y digitales. Asistía a toda jornada y actividad que pudiera y que me acercara mas a esta espectacular forma de organizar el trabajo.
En todos los casos descubrí que siempre hay una mejor manera de hacer las cosas y sobre todo de disfrutar del trabajo bien organizado y en equipo (lo mejor de todo).
Casi toda mi vida profesional la dediqué a desarrollar software y nunca conté con documentación detallada del sistema. Apenas un borrador de una pantalla, reporte o diagrama de estados pero, no había casos de uso. Ni uno solo. Menos todavía diagramas UML. Menos que menos una metodología, ni ágil ni de ninguna clase.... Y sobreviví.

Un día estábamos con mis compañeros totalmente rendidos por la dinámica de un trabajo en el que los requerimientos cambiaban casi a diario, eran inmanejables y no había manera de entregarle valor a los clientes ya que todo era prioritario, y en un momento y casi sin querer escuché:

-Quizás lo que nos pueda ayudar sea una metodología ágil como Scrum.
-¿Scrum? - pensé -. ¿Que es Scrum?

Gracias a eso y a líderes de área y gerencia que apoyaron el cambio de paradigma, pudimos implementar una metodología en el área de desarrollo prácticamente sin darnos cuenta. Implementamos Scrum !!!

Siguiendo el consejo de mi amigo Gaston que me impulsó a crear este blog, intentaré transmitirte la corta experiencia que tuvimos con aquellos proyectos. Los buenos momentos y los no tan buenos. Las cosas que salieron bien y las cosas que tuvimos que mejorar.
Espero también que con tu aporte y la ayuda de este espacio podamos intercambiar opiniones, seguir aprendiendo y mejorar día a día nuestros procesos de desarrollo de software.

Sin extenderme mucho mas, nos doy la bienvenida a Zona Ágil