h1

Implementando Scrum: un caso de la vida real (Parte 2)

07/14/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

La suerte no es un factor. La esperanza no es una estrategia. El miedo no es una opción.

James Cameron (n. 1954), director, guionista, productor de cine y explorador marino canadiense.

En el post pasado mostré un ejemplo de la vida real, con algunos de los tropiezos con los que podemos toparnos durante una implementación de Scrum. En resumidas cuentas, el usuario es nuevo en el paradigma ágil y por la premura de cerrar el contrato, a nosotros nos falló conseguir al personal adecuado, así como capacitarlos correctamente en las mejores prácticas de desarrollo ágil. Sin embargo, esto sólo es la punta del iceberg, ya que durante las siguientes iteraciones y para los demás equipos, tendremos que incluir una serie de medidas de control para asegurar la efectividad y eficiencia del proceso, así como de la calidad de los entregables.

Uno de los requerimientos más importantes para el cliente es una elevada productividad por cada Sprint, así que nos decidimos por un esquema de “trabajo especializado en paralelo”:

Tiempo (día) Planeación Análisis Diseño y Codificación Pruebas Despliegue
Planeación del Sprint
1 Recolectar reqs. del backlog        
2 Transf. de conocimiento de analistas hacia resto del equipo

Atomización de reqs. en tareas

Reunión de Sprint planning

     
3        
Ejecución del Sprint
4 – 13   Análisis para crear/insertar nuevos reqs. en backlog (siguiente Sprint) Diseño Ágil

Codificación

Pruebas Unitarias

Pruebas Funcionales

 
Cierre del Sprint
14         Reunión de Sprint review
15 Retro.        

Ciclo de “especialización en paralelo” con Scrum. Nótese cómo mientras una parte del equipo se enfoca a desarrollar los entregables del Sprint actual, otra parte (dos analistas) se dedica a realizar el análisis de requerimientos del siguiente Sprint.

Este modelo de tres semanas con análisis en T+1 es posible ya que cada célula incluye dos analistas de sistemas. Ciertamente esto contradice el paradigma ágil, ya que en teoría, todos los integrantes del equipo deben ser milusos o como dicen nuestros vecinos del norte, jack of all trades. Sin embargo, la misma figura literaria también dice: jack of all trades, master of none o lo que es lo mismo: quien mucho abarca, poco aprieta. Es decir, en algunas ocasiones es recomendable tener gente especializada en la célula que nos ayude a maximizar la eficiencia del equipo, pues por citar un ejemplo, un desarrollador promedio puede conocer PL/SQL y obtener buenos resultados, pero un DBA experimentado, “creará magia”.

Cabe recalcar que este esquema resultó exitoso en cuatro células pero falló catastróficamente en una de ellas. La manera más objetiva de demostrarlo es a través de números fríos: mientras la célula más productiva ha generado 819 story points durante las últimas 13 semanas, la peor ha generado tan sólo 130 que aun así, están siendo impugnados por el cliente. Esta falta de productividad fue achacada inicialmente a una falta de seguimiento en el proceso Scrum, sin embargo en términos generales, dicho proceso fue seguido al pie de la letra; el problema derivó en no implementar correctamente la construcción de los entregables. Este proceso, separado de Scrum, es conocido como el ciclo de vida de desarrollo de software (Software Development Life Cycle o SDLC).

El desarrollo de software se compone de dos procesos

Cualquier proyecto de desarrollo de software está compuesto por dos familias de procesos fuertemente ligados que atacan aspectos muy diferentes del proyecto:

• El proceso de gestión de proyectos, que de acuerdo al Project Management Body of Knowledge (PMBOK), se compone por diez áreas de conocimiento: integración, alcance, tiempo, costos, calidad, recursos humanos, comunicación, riesgo, adquisición y stakeholders.

• El proceso de desarrollo de software o SDLC, enfocado a la entrega del producto y conformado por las disciplinas ya conocidas por todos: análisis de requerimientos, diseño, construcción, pruebas, despliegue, mantenimiento y gestión de la configuración.

El problema es que los neófitos en el paradigma ágil creen que cualquier metodología define ambos procesos, algo que es tan FALSO como que el PMBOK nos indique cómo implementar un plan de pruebas. Scrum está enfocado al proceso de gestión de proyectos, dejando que el equipo decida cómo implementar a nivel operativo sus desarrollos; por el contrario, metodologías como Extreme Programming (XP) se enfocan de lleno a la ingeniería de software y por ende, a la entrega y calidad del producto. Es así como una de las metodologías híbridas más utilizadas en la industria es la mancuerna Scrum/XP, ya que ésta permite una combinación ganadora:

↑ Prácticas de gestión de proyectos Gestión de Costos Gestión de adquisiciones Gestión del tiempo

Sprint

*40 Hrs./Semana

Gestión de RRHH

Scrum master

*Propiedad colectiva del código

*Cliente on-site

*Coach, no PM

  Alcance y reqs.

Product Owner

Product Backlog

*Juego de planeación

*Cliente on-site

*Historias

Gestión de la comunicación

Scrum diario

Reunión de Sprint planning

Reunión de Sprint review

*Cliente on-site

*Historias

Gestión de la integración

Sprint

Reunión de Sprint planning

Sprint backlog

*Juego de planeación

*Liberaciones cortas

Gestión del riesgo

Reunión de Sprint planning

Reunión de Sprint review

Scrum diario

*Juego de planeación

*Liberaciones cortas

*Programación orientada a pruebas

*Cliente on-site

↓ Prácticas de desarrollo de software Diseño de software

*Metáforas

*Diseño simple

Construcción de software

*Programación por pares

*Refactoring

*Propiedad colectiva del código

*Estándares de codificación

Gestión de la configuración

Build diario

*Integración continua

Gestión de la calidad

Reunión de Sprint review

*Programación orientada a pruebas

*Refactoring

*Cliente on-site

*Estándares de codificación


Combinación de metodologías de gestión de proyectos y desarrollo de software. En este caso, Scrum y Extreme Programming. Nota: las prácticas con (*) pertenecen a XP. (Fuente: just-another-blog-for-kicks @ blogspot.com)

Esta combinación incluye controles entre las disciplinas de gestión de proyectos y desarrollo de software, dejando fuera sólo la gestión de adquisición y costos, que podrían ser llevadas a cabo de forma adecuada por una Oficina de Proyectos o PMO. Como opinión personal, este ejercicio debería ayudarnos a entender que Scrum por sí solo no resolverá nuestros problemas, ya que no hay soluciones técnicas para problemas de gestión, pero puede haber soluciones administradas para problemas técnicos. Por ello la necesidad de complementarlo con mejores prácticas de otras metodologías o frameworks enfocados al nivel operativo.

Asegurando que todos hacen lo que dicen que hacen

Es así como hemos decidido verificar el seguimiento de estas prácticas a través de un checklist aplicado por un experto en la materia (Subject Matter Expert o SME) en colaboración con el resto del equipo, incluyendo el líder técnico (TL), los analistas (BA), los desarrolladores (DEV), el tester (TE) y el Scrum master (SCM):

Fase Punto de revisión Responsable Evidencia Resultado
Análisis Documentación elaborada por analistas está completada al 100% y están de acuerdo al objetivo de las historias de usuario seleccionadas para el presente Sprint. BA/TL Documento
Análisis La documentación aprobada está publicada, distribuida y disponible para todos los miembros del equipo. BA/ TL/ SCM TFS/ Sharepoint
Diseño Modelo de persistencia y modelo conceptual cumplen con alguno de los tres enfoques ORM: esquema primero, modelo primero, código primero. TL TFS/RSA
Diseño La arquitectura ya ha sido definida y comprendida por todo el equipo: cliente-servidor, N-capas, SOA. TL TFS/RSA
Construcción Los estándares de código han sido aplicados a todo artefacto de software construido de acuerdo a la filosofía de codificación adoptada. TL TFS/RSA
Construcción El ambiente de desarrollo está correctamente instalado y configurado en las instalaciones del cliente y si aplica, en las laptops de los desarrolladores. TL Ambiente verificado
Pruebas Unit tests para cada artefacto de software. TE/DEV Artefactos de software
Pruebas Matriz de pruebas actualizada con todos los casos y escenarios de prueba. TE Documento
Despliegue Obtener la documentación con los procedimientos de instalación y configuración de los entregables de software en los ambientes de QA, PERF y PROD TL Documento
Despliegue Verificar que existan procedimientos de gestión de cambios para los ambientes de QA, PERF y PROD. TL Documento

Lista de verificación para mejores prácticas del SDLC ágil.

Este es sólo un ejemplo, ya que dependiendo de la madurez del equipo o empresa que está implementando el proyecto, la lista puede tener más de 150 controles. De momento, nosotros no requerimos tantos (sólo 50-60 dependiendo de la tecnología usada), pero nuestra área de SQA ya nos adelantó la noticia que dentro de 6-8 meses certificaremos la cuenta en CMMI-5. Por ello, muy probablemente, acabaremos con una lista muy extensa, comprobada no sólo por nuestros SMEs, sino también por SQAs calificados o los appraisers que otorgan la certificación CMMI.

Conclusiones

El SDLC es el proceso que empleamos para desarrollar nuestros entregables. Y sin importar la metodología que ocupemos, si nuestro SDLC es inmaduro o deficiente, estamos en serios problemas. Sin embargo, NO existe un proceso único que pueda ser implementado por todos; incluso, debería ser lo suficientemente flexible como para cambiarlo de acuerdo a las necesidades de negocio o conforme va creciendo el alcance de nuestro proyecto. La situación es que siempre es necesario tener un proceso formal y comprendido por todos los involucrados, que pueda seguirse de forma sustentable. La alternativa es trabajar de forma desorganizada, o confiar ciegamente en que el equipo sabe lo que hace. Así que, nuestra mejor opción al adoptar ágil, consiste en adherirse al proceso de gestión, definir un SDLC formal, y hasta que estemos seguros que ambos procesos sean llevados a cabo de forma natural y repetible, es necesario introducir medidas de control para asegurarnos que todo funciona correctamente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: