jueves, septiembre 26, 2013

Scrum: Sobre el Sprint 0 (Sprint Cero) o Inception


En ninguna de las guías de scrum hablan sobre un Sprint 0 (cero) pero es de las recomendaciones que he recibido de quienes nos han hecho coach en scrum.

Este sprint realmente no tiene ítemes de producto, corresponde a todas las actividades preparatorias para poder comenzar a ejecutar el proyecto, dentro de este sprint se pueden realizar cualquiera  (o todas) de las actividades siguientes:


  • Definir los releases y plan del producto (se puede emplear una técnica como el user story mapping)
  • Definir la arquitectura base del producto sobre la cual se va a evolucionar.
  • Definir las pruebas a realizar
  • Definir los lineamientos gráficos del sistema (si aplica)
  • Realizar todas las instalaciones  en los diferentes ambientes (desarrollo, pruebas, pre-producción y producción)
    • IDEs
    • Servidores de aplicaciones
    • motores de bases de datos
    • Nota: Que todos los ambientes sean lo más similares entre sí posibles (sistemas operativos, versiones de productos, conectividad, etc)
  • Preparar y configurar los repositorios de control de versiones
  • Configurar los scripts para el servidor de integración continua de forma que logremos que una linea de codigo quede probado y desplegado en los respectivos ambientes
  • Escribir el 'hola mundo" que logre pasar por:
    • el repositorio del control de versiones
    • probado por las diferentes pruebas definidas
    • que en los diferentes servidores automáticamente quede:
      • código validado con reglas automáticas
      • compilado
      • probado
      • y desplegado en los diferentes ambientes
    • Nota:  Es como tender la carretera pavimentada para que las líneas de código pasen sin inconvenientes de inicio a fin.
  • Escribir las historias de usuario para el primer planning. Posiblemente mostrarlas al equipo para que realice un primer acercamiento.
  • Definir herramientas de gestión que utilizará el equipo
    • Kanban
    • Burndowns
    • hojas de cálculo
  • Definir la DoD (Defnition of Done( (Definición de Hecho/Realizado/Completado) para el proyecto
  • Definir los criterios de liberación del producto / liberación de releases
    • Aprobaciones
    • historias completadas
    • valor de negocio entregado
  • Definir como se calculará el ROI del proyecto y/o el éxito del mismo
  • Definir forma de puntuar las historias 
    • si con pivote funcional o,
    • pivote de días ideales
  • Definir estándares de codificación y documentación del código
  • Definir documentación a emplear y como se va a actualizar en el proyecto
  • Definir tamaño de los sprints

Suficientes tareas, ¿no cierto?



Unas recomendaciones:
  • Cree Historias de Usuario Técnicas asociadas a cada una de las tareas definidas, y recuerde ponerle criterios de aceptación, de manera que se verifique que puede cumplirlas
  • Realice estimaciones sobre las Historias de Usuario Técnicas, realice el "taskeo" (identifique las tareás)
  • No olvide a scrum para este sprint:
    • Defina la duración: Definir un timebox (tiempo definido fijo) para este sprint (consideraría 2 semanas suficientes, pero la casuística me impide afirmarlo categóricamente), con el objeto de no eternizarnos en la planeación y definición, cayendo en un antipatrón de la gerencia del proyectos llamado (parálisis por análisis  o en inglés Analysis Paralysis)
    • Realice el daily con todos los involucrados en este sprint
    • Si es el Scrum Master, realice la debida gestión de impedimentnos y si es team member por favor notifíquelos
    • Al final realicen review y retrospectiva, identifiquen las lecciones aprendidas y feliz comienzo del sprint 1.


Saludos ágiles y
hasta la próxima


Recomendaciones y lecciones aprendidas


-

Lo poco o lo mucho que hagas, hazlo siempre muy bien 

(aplica para cualquier escenario, y debería ser una costumbre)





En el mundo hay dos tipos de personas, las que hacen que las cosas pasen y las que les pasan cosas

(¿cuál eres tú?, ¿de cuáles quieres estar rodeado en tu proyecto?)


-

lunes, septiembre 16, 2013

Scrum: Comprometiéndonos un poco más allá en el planning

Hola a todos

Aunque existen estrategias para mejorar la velocidad de un equipo (ver algunas aquí) y como lo he expresado es mejor ser más productivos que más veloces (clic aquí), les comparto un pequeño tip para que el equipo vaya ganando velocidad en su construcción de producto.

Por lo general, cuando los equipos comienzan o fallan son temerosos escogiendo la cantidad de historias a implementar que harán parte del sprint backlog. Una buena forma de alejar el temor y lograr la confianza (basándonos obvio en el principio) de transparencia es:

"Ok, comprometámonos con lo que nos sentimos seguros (15 puntos por ejemplo) y dejemos esta historia como opcional (ej:3 puntos), y si alcanzamos a hacerla, pues ¡Genial!"



Si el equipo compra la idea, al final pueden darse las siguientes situaciones:
  1. Se logré solo lo inicialmente comprometido (cero líos, no hay ningún problema)
  2. Logren hacer lo adicional, en este caso 18 puntos (excelente)
  3. Si el equipo nota que después de varios sprints cumple el reto adicional, ellos mismos, el Product Owner o el Scrum Master pueden considerar que se puede aumentar la velocidad para el siguiente sprint, en este caso 16, 17 ó hasta los mismos 18 puntos, lo que decidan en consenso.


Saludos ágiles

Jorge Abad

martes, septiembre 10, 2013

No hay razones para trabajar horas extras bajo un escenario normal de trabajo.

A lo largo de la vida profesional he aprendido que no hay razones para trabajar horas extras.

Si tu o tu equipo trabajan horas extras se debe a alguna de las siguientes razones, identifícalas y trabaja sobre ellas.

Situación
Si eres tu
Si es alguien que tienes a cargo
Consecuencia
Mala definición de cargo y funciones
Habla con tu superior
Revisa si esta situación es temporal o como puedes hacerla lo más corta posible.
Cualquier persona en ese cargo/rol terminará por renunciar.

En estos casos la vida personal paga los platos rotos y llega el momento que ningún sueldo del mundo compensa la vida personal y/o familiar.
Sobre-asignación de tareas
Habla con tu superior y demuéstrale con hechos y  números lo que sucede.
Haz que esta situación sea lo más corta posible
Igual que el anterior
Estas asumiendo responsabilidades que no son tuyas, o quieres hacer todo tu.
Tú sabrás que haces con tu vida y tu tiempo y con qué objetivo te estás sob-e esforzando,  aun así, no es aconsejable prolongar esto en el tiempo pues, pues puede que:
·         Nadie recompense tu sobre-esfuerzo
·         Se considere un esfuerzo normal que no merezca ser recompensado
·         Por fin te recompensen y logres el objetivo
·         Pierdas muchas cosas importantes (familia, amigos, salud, tiempo invaluable de tu pareja e hijos ) y lo logres
·         Pierdas muchas cosas importantes (familia, amigos, salud, tiempo invaluable de tu pareja e hijos ) y NO LO LOGRES

De igual forma, identifica si tienes problemas con delegar y confiar en el trabajo de los otros , si es así,  comienza a trabajar en esta zona con ayuda de tu superior, recursos humanos, etc.,  pues es claro que tienes problemas serios de trabajo en equipo.
Revisa los objetivos con esta persona que tienes a cargo, y determina si puede alcanzarlos, de forma que se identifuque la viabilidad de las expectativas y reconocer si se puede o no seguir sacrificando en el corto, medio o largo plazo.

Identifica si la persona a cargo tiene problemas con delegar y confiar en el trabajo de los otros , si es así, ayúdale a salir de esta zonan esta zona con ayuda de tu superior, recursos humanos, etc.
Depende de lo que esté en juego, tanto laboral como en el entorno personal
No tienes información/formación para hacer lo que te encomendaron y te toma más tiempo de lo que lo hace una persona “normal”
Solicita información, formación, ayuda o realiza autoestudio para cubrir pronto la curva de aprendizaje.

Ponte metas claras en el corto y mediano plazo a lograr cubrir el GAP y no eternizar la situación.
Determina si esta es la situación, y si es del caso brinda información, formación, ayuda o estimula autoestudio para cubrir pronto la curva de aprendizaje.

Ponle metas claras en el corto y mediano plazo a lograr cubrir el GAP y no eternizar la situación.
Frustración y se pone en riesgo la continuidad laboral.
Pierdes demasiado tiempo en la oficina haciendo cosas que no son  y luego tu conciencia te dice que debes quedarte para compensar el tiempo perdido
Te recomiendo lee estos dos artículos [1] y [2],y te informo que estas en riesgo de ser despedido.

Aun  así, Identifica si la razón de la procastinar/postergar está ligada con que estás haciendo algo que no te gusta y toma acciones.
Te recomiendo lee estos dos artículos [1] y [2], y hables directamente con la persona a cargo y le propongas un plan de acción y seguimiento de forma que identifiques mejora, continuidad o detrimento de la actitud. 

En caso de continuar o tener un detrimento en la actitud, es mejor prescindir de esta persona y encontrar quien tiene la motivación para hacer correctamente el trabajo.

Indaga si la razón de la procastinar/postergar está ligada con que la persona haciendo algo que no te gusta y toma acciones como reasignación de cargo o funciones en caso de ser posible.
Si no hay mejora en esta situación, siempre se tendrá en juego la continuidad laboral

En caso de que el proyecto, o la situación sea temporal y se requiera un sobre-esfuerzo, te recomiendo leer este post [3].


Saludos

Jorge Abad




Referencias

[1] Postergarlo todo, un hábito poco saludable - http://www.eltiempo.com/vida-de-hoy/salud/postergar-las-cosas-no-es-bueno-para-la-salud_12989998-4
[2] La Procastinacion: El Enemigo de Tu Productividad - http://www.marthacaballero.com/procastinacion-enemigo-de-tu-productividad/
[3] Recomendaciones sobre el sobre-esfuerzo del equipo en un proyecto- `http://lecciones-aprendidas.blogspot.com/2012/10/recomendaciones-sobre-el-sobre-esfuerzo.html

domingo, septiembre 08, 2013

CMMi y SCRUM: Mi punto de vista

Hola a todos:

Hace algunos días venia pensando en este post, pues sé que puede herir susceptibilidades y generar controversia, pero la reflexión y la sensatez me ha llevado ha escribirlo. Comenzaré entonces el post con las dos conclusiones con las que quiero terminar:
  • CMMi es un modelo  prescriptivo que incluye muchas componentes y elementos,  su adopción es lenta y bastante costosa para los equipos y organizaciones, e incluso adoptándolo no se garantiza que "todo vaya a ir bien"
  • SCRUM es un marco poco prescriptivo que tiene excelentes prácticas de gerencia de proyectos, gestión de requisitos y habilita de una forma rápida la mejora continua, su adopción es simple y poco costosa, adicionalmente su correcta implementación hará que pronto "todo vaya bien".
Ya que saben mi conclusiones, espero estén interesados en conocer mis argumentos. Voy a manejarlos en forma de cuadro comparativo:

Característica
CMMi (Capability Maturity Model Integration)
SCRUM
Tiempo de adopción
·         Lo normal es que la adopción de cada nivel toma aproximadamente entre 12 a 18 meses [1]

·         La adopción completa de CMMi nivel 5 toma entre 3 a 5 años empleando técnicas de Six Sigma [1]
·         Aplicar Scrum y toma poco tiempo, aproximadamente 3 a 4 sprints de 2 semanas para estar ejecutando bien el framework. Se sugiere acompañamiento (coach) o mucha lectura para hacerlo bien [4]
Costo
Mínimo 100.000 dólares por cada nivel, compartido entre consultorías, adopción y adaptación del modelo dentro de la organización[12]
Sin información.

Nota: Se puede adoptar el framework y las prácticas técnicas a muy bajo costo para los equipos.
Capacidad
La "capacidad certificada" de hacer software solo se demostrará después del primer nivel (nivel 2) certificado (he concluido,  que seguirás fallando en proyectos)
La capacidad es dada por el software funcionando cumpliendo la Definición de Hecho/Realizado (Definition of Done - DoD), disponible desde el primer sprint.

Aunque es cierto, también se puede fallar en Agile [7][8][9], pero un equipo con coraje y el poder de las retrospectivas pueden cambiar favorable y rápidamente esta situación.
Complejidad del modelo
Entender CMMi requiere de entrenamiento y es un documento de 482 páginas (esta es la hora que nó me lo termino de leer)[2]
Para entender Scrum requiere de máximo una tarde leer la guía oficial que tiene 16 páginas [3]. ( y bueno, mucha reflexión y lecturas complementarias [4] para comprender este marco que te da límites y libertad.)
Universalidad del entendimiento del modelo
Muchas cosas dependen de la interpretación del consultor y de quien haga la evaluación (frase que se escucha con frecuencia mucho en el mundo CMMi).
He observado que entender el marco a pesar de ser simple, requiere de acompañamiento y mucha lectura. 

El framework te proporciona unos límites claros y mucha libertad para moverte dentro de ellos.

La recomendación en este caso es:
·        cumpla las reglas,
·         haga todas las reuniones
·         no fusione roles
·         no alargue el sprint
·         Lea a los líderes
Áreas de interés
CMMi se involucra con muchas áreas dentro de la organización, los proyectos y la ingeniería [5][2]:
·         Administración de procesos
o   Entrenamiento
o   Innovación
·         Ingeniería
o   Requisitos
o   Verificación
o   Validación
o   Solución técnica
·         Gestión de proyectos
o   Gestión
o   Administración de proveedores
·         Soporte
o   Medición
o   Auditorías al proceso y producto
o   Gestión de la configuración
o   Análisis de causas
o   Análisis de decisiones

Scrum con respecto a  CMMi solo se encuentra fuertemente asociado a la gestión de proyectos y a la gestión de requerimientos [6]

Respecto a la Ingeniería esta no se encuentra definida en Scrum, la responsabilidad es delegada al equipo auto-organizado que sabe y conoce como lograr el producto:"el equipo decide como pasar de una lista de requerimientos a un producto potencialmente entregable durante el sprint".

Por lo tanto, los equipos SCRUM se apoyan fuertemente en las prácticas técnicas (para cumplir el manifiesto ágil el cual hace el llamado a la excelencia técnica) y así lograr la DoD (Definition of Done).

Dentro de las prácticas técnicas se encuentran [10]:
  • TDD
  • BDD
  • ATDD
  • Continuous deployment
  • Pair Programming
  • Refactoring
  • Gestión de la configuración
  • Métricas
  • Entre otros


Es de observar que estas prácticas técnicas dan soporte a las diferentes áreas de CMMi, dejando por fuera a:
  • Entrenamiento
  • Administración de proveedores
Ciclos de mejora
Aunque se realizan auditorías tanto  a los proyectos como a la organización  y se recolectan y aplican las lecciones aprendidas, los ciclos de mejora toman tiempo y dependiendo de la organización se realizarán entre 2 a 4 en el año.

Y la aplicación de las mejoras depende de las políticas de la organización
Se realizan mejoras cada sprint (el cual finaliza entre 2 a 4 semanas), habilitando el PHVA en ciclos cortos y potencializando inmediatamente la mejora continua de los equipos de desarrollo.

Scrum no está orientado a la organización,  sino a  los equipos y estos son los directamente beneficiados con el framework .

Es natural el compromiso del equipo con la mejora (kaizen)

 Bajo lo expuesto anteriormente, concluyo:

Es más fácil lograr CAPACIDAD* con Scrum que con CMMi, en términos de costo y tiempo. 

-
-

"Con Scrum el proceso de alcanzar capacidad es más rápido, barato, natural y convergente que con CMMi."[14]

-
* Hablo de capacidad pues la "C" de CMMi es de Capacidad que es el argumento de venta del modelo y considerando dicha capacidad como la facultad de hacer software de alta calidad funcional y técnica que cumpla con las expectativas de los clientes y usuarios, por parte de la organización y sus equipos de trabajo.




Ahora resulta que todos son ágiles

Es frecuente encontrar artículos del SEI y al PMI y otros de corrientes de la ingeniería de software clásica, apegados a modelos rígidos diciendo:
-
"si, si, y además nosotros también somos ágiles. Miren pueden pagarnos estos cientos o miles de dólares para que yo lo certifique o certifiquemos su empresa en agilidad bajo nuestro modelo"


Observo que se les esta yendo el negocio de las certificaciones y las consultorías de las manos, pues cada vez las empresas y los equipos de software están encontrando más pronto la EXCELENCIA y CAPACIDAD de hacer software con altísima CALIDAD en el agilismo, que bajo los esquemas tradicionales y rígidos como son CMMi, PMBoK, RUP, entre otros.


En la misma línea del párrafo anterior, es una moda el uso la palabra ÁGIL / AGILE (o en su defecto SCRUM), y muchos quieren ponerla de prefijo o de apellido a su negocio, framework, título, etc., cosa buena pues apunta a que los agilistas tienen la razón y cosa mala pues habrán muchos diciendo que son ágiles sin serlo. Más temprano que tarde el mercado y los hechos demostrarán quienes son o no del mundo agile, y esto será dictado por el cumplimiento del Manifiesto Ágil  y sus Principios [11], y el éxito en la forma de ejecutar lo que se comprometen en un entorno complejo.

¿Además qué grande (léase: google, facebook, yahoo, microsfot, etc) del software tiene CMMi nivel 5?



Volviendo al inicio

Termino entonces este post con las conclusiones prometidas:
  • CMMi es un modelo  prescriptivo que incluye muchas componentes y elementos,  su adopción es lenta y bastante costosa para los equipos y organizaciones, e incluso adoptándolo no se garantiza que "todo vaya a ir bien"
  • SCRUM es un marco poco prescriptivo que tiene excelentes prácticas de gerencia de proyectos, gestión de requisitos y habilita de una forma rápida la mejora continua, su adopción es simple y poco costosa, adicionalmente su correcta implementación hará que pronto "todo vaya bien".
Queda abierta la discusión


Saludos y un abrazo ágil a todos





Referencias:

[1] http://www.sei.cmu.edu/library/assets/bridging-gap.pdf
[2] CMMI for Development, Version 1.3. http://www.sei.cmu.edu/reports/10tr033.pdf
[3] The Scrum Guide -https://www.scrum.org/Scrum-Guides
[4] Por dónde comenzar a leer y a estudiar de Scrum http://lecciones-aprendidas.blogspot.com/2013/05/por-donde-comenzar-leer-de-scrum.html
[5] Framework para el Desarrollo De Software En Entornos Académicos - https://docs.google.com/file/d/0B5JZ11Z2PoWWWDlheXY2SnhUc2M/edit?pli=1
[6] Can Scrum help to improve the project management process?  A study of the relationships between Scrum and Project Management process areas of CMMI-DEV 1.3. http://www.javiergarzas.com/2013/03/cmmi-scrum.html
[7] Ways to Fail with Scrum!- Jeff Sutherland  http://www.gbcacm.org/sites/www.gbcacm.org/files/slides/3B%20-%207%20Ways%20to%20Fail%20with%20Scrum!.pdf
[8] How to Make Scrum Fail - http://agile.dzone.com/articles/how-make-scrum-fail
[9] Scrum Fails? -Ken Schwaber http://kenschwaber.wordpress.com/2011/04/07/scrum-fails/
[10] What are the Most Important and Adoption-Ready Agile Practices?  http://www.infoq.com/research/agile-practises?utm_source=infoqresearch&utm_campaign=rr-content#.UUmgOcTIFVw.twitter
[11] Manifiesto Ágil  -http://agilemanifesto.org/
[12]Profiles of Level 5 CMMI Organizations - http://www.compaid.com/caiinternet/ezine/reifer-profiles.pdf
[13]Jeff Sutherland. Scrum and CMMI Level 5: The Magic Potion for Code Warriors "http://systematic.com/media/282221/Scrum_and_CMMI_Level_5___The_Magic_Potion_for_Code_Warriors.pdf
[14] Texto de mi autoría adicionado el 15 de septiembre de 2013

miércoles, septiembre 04, 2013

Tips para el Sprint Backlog: Primero las HU Riesgosas y luego las prioritarias

Hola a todos

Recordemos:

  • Sprint backlog: ítemes de backlog (en nuestro caso Historias de Usuario - HU) comprometidos a construir durante el sprint.


De las primeras cosas que aprendí en Scrum, al ver que un sprint fallaba fue:

Hacer de primero las HU más riesgosas y aunque no sean las prioritarias para el Product Owner (PO)


Razones:
  • si comienzas muy tarde a hacer la HU es probable que por sus dependencias o complejidad no la termines.
  • Obvio después de la(s) riesgosa(s) poner las HU que tengan más prioridad de forma que siempre estemos dando el máximo valor a medida que avanza el sprint.

Sugerencias:
  • Hacer ver al PO por que va esta(S) HU(s) de primero.- La verdad no es complejo-.
  • Debido a que esta historia va primero solicitar los insumos para hacerla, en caso que no estén,  poner una fecha máxima para la recepción de insumos, en caso contrario,  hacer ver que si no se reciben oportunamente la historia se cae (no se culmina), y esos puntos no se logran.
  • Lo ideal y recomendado es comenzar el sprint con los insumos (información, componentes, definiciones, etc) claros y resueltos para que el Sprint avance sin tropiezos.
  • Si una es HU riesgosa y se observa que la posibilidad de completarla es casi nula debido a su complejidad:
    • Definir un Spike (tarea dentro del sprint) con timebox definido (léase timebox=tiempo fijo) y objetivos definidos
    • Ese spike debe tener como objetivo eliminar la complejidad y adquirir el conocimiento necesario para lograr estimar y construir esa HU en el siguiente sprint
  • No tener muchas historias de usuarios riesgosas, a lo sumo 2 de un máximo de 7 HU (un sprint debería tener a lo sumo entre 6 y 8 HU), debido a que si son muchas el sprint puede ser un fiasco y no completar nada. (situación que viví y de la cual aprendimos como equipo)
  • Enfocarse y enfocar al equipo durante la ejecución del sprint en máximo 2 historias al tiempo de forma que se evacue siempre lo primero. Esto en Kanban se llamaría un limite de 2.

Saludos y abrazos ágiles a todos

Jorge Abad