Primer intento de The Tea Podcast

Una nueva instancia de conversación con mi amigo Franco Morales Castro, de temas que involucran al área informática en general. Disculpen los impropetios, pero salen de por ahi :).

Opiniones?

 http://www.mediafire.com/?5uyaemqemdg (para bajarlo ;))

El manifiesto Agil

El manifiesto ágil es como los diez mandamientos, del desarrollo de software… el sagrado pergamino, sólo eso. Evidentemente uno puede entrara a dar sus puntos de vista y discutir libremente.

A continuación se exponen las reglas de oro del maninifesto ágil celebrado el 2001.

1.- La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.

2.- Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.

3.- entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

4.- La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.

5.- Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.

6.-  Dentro de un equipo de desarrollo es mediante la conversación cara a cara. La forma más eficiente y efectiva de comunicar información de ida y vuelta.

7.- El software que funciona es la principal medida del progreso

8.- Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.

9.- La atención continua a la excelencia técnica enaltece la agilidad.

10.-  La simplicidad es esencial.

11.- Las mejores arquitecturas, requisitos y diseños emergen de equipos que se autoorganizan.

12.- En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y  ajusta su conducta en consecuencia.

Opiniones?

En que consiste un Coach Agil?

El coaching consiste en generar conversaciones de calidad en las cuales el coach ayuda al coachee a ver nuevas perspectivas y posibilidades, de manera que pueda tomar el siguiente paso en su crecimiento personal y profesional. En el contexto de los equipos ágiles, el coaching asume dos posturas: de coaching y de mentoring. Si, se hace coaching para ayudar a alguien a alcanzar su próxima meta en su vida. También se comparten conocimientos de experiencias ágiles e ideas, se los guía para usar métodos ágiles. El coaching y el mentoring se cruzan para desarrollar talentos ágiles, de manera que puedan alcanzarse más y mejores resultados para el negocio.

Ocurre lo mismo a nivel de todo el equipo. El coaching ayuda a mejorar el desempeño del equipo. El mentoring transfiere conocimientos ágiles y experiencias al equipo a medida que resultan relevantes. Ambas partes de la ecuación se combinan para que el pensamiento ágil florezca en el equipo.

Cada parte -coaching y mentoring- es útil y puede ser una herramienta poderosa por si misma. Juntas, son una fuerza fundamental para ayudar a que el equipo adopte ágil y lo use correctamente. El contexto de ágil nos convierte en mentores; el foco en el equipo nos hace coach.

En el coaching profesional, la agenda del cliente es lo que guía la relación. El coach es exclusivo para el cliente. En el contexto ágil no es así, ya que el coach no sólo atiende al cliente (a un miembro del equipo, por ejemplo) sino también al equipo en su conjunto, y también a las personas que rodean al equipo en la organización. No somos verdaderos coach, a pesar de que usamos este término libremente. Somos mentores con experiencia en ágil. Educamos a partir de esta experiencia y usamos habilidades de coaching para ayudar a cada persona a hacer una buena transición hacia ágil.

Recompensa Individual vs Recomensa del equipo

Las “mejores prácticas” que usa Recursos Humanos seguirán siendo desafiadas a medida que la adopción de Scrum vaya madurando en la organización. De hecho, si ustedes ya están teniendo estos problemas ahora mismo, puede ser un signo de madurez en su adopción de Scrum. Uno de estos desafíos aparece en la forma de la siguiente pregunta: “¿Debería existir la recompensa individual en un equipo de Scrum?”.

Y obviamente hay distintos puntos de vista. Personalmente creo que no sirve ya que se trabaja en equipos y no en grupos (principio de confianza) por lo que, una frase celebre que describe eso, esta aquí:

” Los equipos de Scrum funcionan porque se forman lazos muy cercanos entre los miembros.El reconocimiento individual puede romper estos lazos y crear distancia entre los miembros del equipo”.

Y Archit tiene un muy buen punto aquí. Uno de los diferenciadores más importantes de Scrum es el énfasis en el equipo como unidad, y en valor superlativo del producto que crean. De algún modo, Scrum busca crear una mentalidad de darle importancia al desarrollo mediante la entrega de productos que satisfagan las necesidades del cliente. De hecho, desde el punto de vista de la salida, al cliente no le importa si el esfuerzo lo hizo un individuo o todo el equipo; todo lo que les interesa es obtener un gran producto que cumpla las especificaciones. Queda claro que los actos heróicos individuales (y las recompensas que conllevan) deben dejarse a un lado por el bien común.

Hace poco me contaron una reflexión interesante, que comparto: las recompensas se dan por los logros del trabajo en equipo. Y por lo tanto, las recompensas deben ser para todo el equipo: es el resultado del esfuerzo y coordinación grupal lo que generó el logro que se quiere premiar. ¿Y entonces qué pasa con las habilidades individuales, los aportes que crea cada individuo? Los desempeños individuales también se premian, a través del salario. Y ahí hay una distinción interesante entre recompensa y salario: la recompensa es por el trabajo en equipo, por el resultado; el salario es en base a las capacidades individuales y su aplicación en la práctica.

Opiniones?

Errores ágiles: buscar estimaciones perfectas

Un equipo que adopta Ágil por primera vez tiende a cometer varios errores durante los primeros días. Uno de los errores más comunes es intentar hacer una estimación precisa. Durante la Reunión de Planificación del Sprint de la primera iteración, el equipo no conoce su velocidad y tiende a gastar tiempo intentado crear estimaciones “precisas” o estima usando “colchones” arbitrarios. Gastan demasiado esfuerzo detallando las tareas y estimándolas.

Los métodos Ágiles desalientan a que los equipos gasten demasiado esfuerzo intentando lograr la perfección de una, especialmente si hablamos de estimaciones. Ágil recomienda que los equipo apliquen un modelo de control empírico, haciendo inspecciones frecuentes de las estimaciones y adaptándolas. De hecho, recomienda usar la técnica de re-estimaciones diarias.

Re-estimación diaria

Los métodos Ágiles recomiendan que:

•durante la Reunión de Planificación del Sprint, la estimación de los requerimientos se debe hacer con el conocimiento que se tenga a ese momento.

•A medida que se realiza la re-estimación diaria se intenta ir ajustando y llegar así a estimaciones más precisas.

•Usar estimaciones optimistas en vez de estimaciones pesimistas. Iteraciones siguientes Desde la primer iteración el equipo debe hacer un seguimiento de algunas parámetros clave, como por ejemplo:

•Esfuerzo planificado vs. Esfuerzo actual

•Cantidad de historias comprometidas vs. Cantidad de historias terminadas

•Cantidad de tareas nuevas descubiertas durante la iteración

•Presupuesto de recursos planificado vs. Presupuesto de recursos real Una vez que el equipo conoce su velocidad, las iteraciones futuras pueden ser estimadas y planificadas de mejor forma. Conclusión

•Intentar detallar todas las tareas, intentar crear estimaciones precisas, planificaciones y análisis detallados son los vestigios del modelo en Cascada.

•Ágil recomienda entregas frecuentes de software que funciona en vez de gastar tiempo en un análisis/parálisis.

Opiniones?

CMMI + Scrum… se puede?

Hace algún tiempo pensaba en si dos metodologías de desarrollo de software, una tradicional, y una ágil, podrían ser combinables, y pues, a simple vista es difícil dimesionar si dos aspectos distintos de hacer las cosas pueden convivir bajo una misma nube, y llegué a la conclusión que si, pues usualmente las metodologías tradicionales proponen estructuras de trabajo en base a procesos, mientras que las ágiles, apoyan el postulado de basarse en las personas para lograr que un proyecto sea exitoso.

Y visitando hace unos dias www.chileagil.cl me encuentro con un podcast bastante interesante en el cual relata las experiencias sobre combinar una metodología como es CMMI, con Scrum; dándonos muchos puntos de vistas que pocas veces imaginamos, como declararnos ágiles, con certificaciones CMMI nivel 4, por ejemplo.

Podcast 1: http://podcaster.cl/download?id=18573

Podcast 2:http://podcaster.cl/download?id=18590

Opiniones?

Porque, si importa el software terminado…

Es bien sabido que en Scrum es muy importante tener software que funcione al final de cada sprint. Pero… ¿por qué?. Existen 4 buenas razones por las cuales tenemos que enfocarnos en tener software que funciona, siempre.

 1. Las malas noticias no mejoran con el tiempo.

Dicho de otra manera, es más barato arreglar un bug ahora que arreglarlo más tarde. O la arquitectura, o el diseño. Tiene que estar terminado.

2. Lo reconozco cuando lo veo.

Los usuarios no pueden dar feedback sin algo concreto que mirar. Por lo que “terminado” también significa eso. Tiene que ser los suficientemente concreto para permitir el feedback (y si, a menudo eso son más malas noticias, antes).

3. No está terminado hasta que está terminado.

 Y vaya si habremos vivido esta pesadilla. Sólo si está terminado vamos a tener una idea de nuestro progreso real. Y de ahí podremos saber cuándo haremos la entrega.

4. No construir sobre una mala base.

No queremos construir software nuevo por encima de software con errores. Si cambiamos algo abajo, la casa entera se nos podría caer. Nuevamente, ningún bug debe escapar al sprint.

Seguramente a ustedes se les ocurren más motivos por los cuales debemos tener software funcionando, siempre. Estos son algunos de los motivos por los cuales la Definición de Terminado es un artefacto esencial dentro de Scrum.