Aprenda Scrum como si estuviera en primero (I) Noviembre 17, 2008
Posted by ravelus in Informática.5 comments
En este artículo pretendo mostrar las características básicas de esta metodología de desarrollo software creada en 1990 por Ken Schwaber y Jeff Sutherland, en el marco de lo que posteriormente se denominó como metodologías ágiles de desarrollo de software. La redacción de este artículo es totalmente propia, si bien cuenta con numerosa documentación al final.
Ideas fundamentales
¿Qué diferencia a Scrum (el nombre viene de una técnica de rugby) de otras metodologías? Fundamentalmente una cosa: Scrum entiende el desarrollo de software como algo empírico, y no determinista. Esto significa que Scrum comprende que crear software es algo muy complejo, sujeto a multitud de variaciones e incertidumbres, sobre todo al comienzo. Además cada problema es diferente y no existe una solución mágica o bala de plata que se pueda aplicar a cualquier proyecto (Peopleware, deMarco y Lister). Por ello trata de acometer esta incertidumbre y estos riesgos desde el propio modelo de desarrollo.
Otra caracterísitica fundamental de Scrum es la visibilidad. Scrum trata de que todo el mundo involucrado en el proyecto conozca perfectamente en qué punto del desarrollo se encuentra el proyecto y qué falta por hacer. Esto se consigue a través de las numerosas reuniones de control, que no tratan de informar al jefe de proyecto o los stakeholders, sino más bien a TODAS las personas involucradas en el proyecto. El objetivo no es sólo el control del proyecto, sino la involucración y el conocimiento por parte de todos. Además, es importante que el equipo esté cohesionado y colaboren unos miembros con otros, se solapen y se apoyen mutuamente.
Scrum no es una metodología “mágica” (Peopleware, deMarco y Lister), sino un marco de posibles estrategias, respetando unas reglas prefijadas. Una plantilla a la que después se puede acoplar distintas técnicas de planificación, gestión, control, estimación, análisis, diseño, implementación y pruebas. En esta simplicidad radica su potencial. Las reglas del juego se aprenden más rápido que aprender a jugar al parchís, realmente.
Otra idea fundamental de Scrum es que trata todo el desarrollo del software desde el punto de vista del sentido común. A medida que profundicemos en la metodología en las siguientes secciones (y opcionalmente consultando la bibliografía adjunta) conoceremos cómo se utiliza el sentido común para desarrollar software. También veremos que es una metodología flexible.
Desde el punto de vista de desarrollo, se trata de un proceso fundamentalmente iterativo. Más adelante se detallan las fases y cómo se estructuran las iteraciones.
Aplicabilidad de la metodología
Por lo expuesto anteriormente, se entiende que Scrum es aplicable a cualquier tipo y tamaño de proyectos, si bien es especialmente útil en proyectos medios y grandes en cuanto a complejidad o a tamaño, o bien en aquellos proyectos donde la incertidumbre es grande, bien por el campo en el cual se desarrolla, o bien porque los requisitos no están bien definidos desde el principio y son muy susceptibles de cambiar durante el desarrollo.
Conceptos
La metodología utiliza una serie de tecnicismos para referirse a determinados artefactos, roles y actividades (desde el punto de vista de la terminología RUP), stakeholders y demás:
Backlog: documento en el cual se detallan, de forma priorizada, los requisitos del sistema.
Sprint: cada una de las iteraciones de que se compone el desarrollo con Scrum. Si existe razón de suficiente peso, puede abortarse el sprint y comenzar uno nuevo.
Backlog sprint: “trozo” de backlog que nos comprometemos a implementar de forma satisfactoria en el sprint (iteración) actual.
ProductOwner: Cliente fundamental del sistema. El que desea o propone el software. El propietario del producto. El ‘input’ principal para poner en marcha el nuevo proyecto. Es fundamental que la persona que desempeña este rol se implique al máximo en el proyecto, para que éste tenga garantías de éxito.
ScrumMaster: Gestor del proyecto un poco especial: motiva al equipo. Crea un clima en el cual el equipo trabaje a gusto y sin interrupciones: protege a su equipo. Sin embargo, le deja trabajar libremente. No debe fallar al equipo. No debe faltar a ninguna reunión. Siempre estará ahí, para atender las necesidades del equipo. Es más un “líder” que un “gestor” al uso. Ken Schawber dice que es como el perro pastor de un rebaño de ovejas. Vigila y protege a las ovejas, pero sin molestarlas, sin intervenir prácticamente en sus cometidos.
Team: Equipo de desarrollo. Cada equipo estará compuesto por 7 +-2 personas (es decir: entre 5 y 9 personas, preferiblemente 7). El ScrumMaster jamás intervendrá aquí. El equipo debe estar cohesionado y debe promoverse la filosofía de “todos ayudan a todos”. El equipo se autogestiona a sí mismo. Los miembros del equipo no tienen roles: colaboran entre ellos y “todos hacen de todo”: análisis, diseño, implementación, pruebas y documentación. De este modo no se rompe la continua colaboración y desarrollo de las funcionalidades del proyecto.
En esta metodología existen dos roles bastante graciosos y que dan forma a Scrum: cerdos (pigs) y gallinas (chicken). La denominación viene de un popular chiste: Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: “Hey, ¿por qué no abrimos un restaurante?” El cerdo mira a la gallina y le dice: “Buena idea, ¿cómo se llamaría el restaurante?” La gallina piensa un poco y contesta: “¿Por qué no lo llamamos “Huevos con jamón?” “Lo siento pero no”, dice el cerdo, “Yo estaría comprometido pero tú solamente estarías involucrada”.
En Scrum, los cerdos (aquellos que están comprometidos de forma seria con el proyecto) son desempeñados por los subroles Team, ScrumMaster y ProductOwner. El rol gallina está constituído por otros clientes y stakeholders (ejecutivos, etc.). Al final, todos los roles “cerdo” son gestores (managers), desde el momento en el que se dice que están comprometidos con el proyecto.
NOTA: A pesar de mi marcado desprecio del uso de anglicismos y del ’spanglish’, mantendré el nombre de los roles en inglés, por correspondencia con la idea original.
(Continuará)
Gestión de proyectos Software (II) Noviembre 11, 2008
Posted by ravelus in Informática.add a comment
En otra ocasión hablé de un libro que trata sobre Gestión de Proyectos Software, estrategias para conseguir objetivos de productividad y que la gente de tu equipo disfrute haciendo lo que más le gusta: la informática.
En este artículo pretendo terminar con aquellos teamicides de los que hablaban los autores, añadiendo tres más que la experiencia de los años les permitió descubrir. Finalmente, hablaré de buenas prácticas, que nos permitirán construir una organización sana y productiva. Recordemos que tratamos con ideas, estrategias, y no con técnicas fijas ni “balas de plata”. Todo, claro está, incluye mis propias aportaciones a lo que el libro contiene.
Otros factores de inhibición en el crecimiento de un equipo (’teamicides’)
Ya hablamos de siete factores que hacen mucho daño al crecimiento y la productividad del equipo. Aquí expondremos otros tres factores clave:
Los pósters corporativos
Las perogrulladas que anuncian estos carteles, en primer lugar, ponen en duda la imagen profesional de la empresa por un lado, porque lo que hace falta es trabajo duro y no autobombo. No hace falta recordar a los empleados lo importante que es su trabajo. Estos carteles no consiguen motivar a nadie, y menos cuando lo que dicen dista mucho de la realidad bien conocida por los propios trabajadores. Más bien insultan a la inteligencia humana. La motivación se consigue por otros medios, no con propaganda barata. Publicidad: en el buzón del portal, por favor.
Horas extras: un efecto colateral no previsto.
Las prisas y el cansancio acumulado nunca fue bueno: errores, cansancio, recuperar con “horas-de-menos”… Muchas veces la gente se queda en la oficina haciendo horas extras para hacer presencia, porque realmente no puede hacer más; no está produciendo, simplemente trata de hacer ver que trabaja lo que puede.
Y en un equipo que marcha bien, que es productivo, que se compenetra bien, etc, las malas estimaciones pueden ser totalmente desastrosas. Y la única solución que se antoja para corregir las malas estimaciones es… hacer horas extra. Y quizá la gente sepa que hace lo que puede, sabe que trabaja bien (mejor, quizá, que otros equipos de su misma organización) y no esté dispuesta a pagar tal sobre-explotación. Unos quizá no quieran; otros sí… envidias, disensiones, y al final un equipo bien cohesionado se va al garete.
Competición dentro del equipo
Suscita envidias. Revisiones de sueldo por méritos, incentivos, objetivos, premios, favores, beneficios, ránkings de productividad… la excelencia o el fracaso va para el equipo como un todo, no para uno sólo. Mima a los miembros de tu equipo, haz que resuelvan sus problemas por sí mismos, que se apoyen mutuamente, que se fraternicen. Que no compitan entre sí, pues no tiene sentido que lo hagan. Que unas veces sean unos los expertos en alguna materia y en otras los aprendices de otro asunto. El gestor debe moderar y coordinar el diálogo.
A grandes males… mayores virtudes
Contra todos los “pecados capitales” identificados arriba y en otros artículos, tenemos una serie de buenas prácticas que harán de nuestra organización un lugar en el que la gente se sienta a gusto para trabajar.
El culto por la calidad
Decir que un producto imperfecto es suficiente es desastroso. Sin embargo, decir que lo único que vale es la perfección constituirá un reto muy interesante para el equipo, para desarrollar sus habilidades y tratar de sentirse al final orgullosos por su trabajo. Una cosa son las labores de planificación: qué costes, cuánto tiempo, cuánta funcionalidad. Otra bien distinta es entregar esa funcionalidad con la mayor calidad posible.
Proveer abundantes finales satisfactorios
Saber que se alcanzan metas, objetivos, productos finales, que los proyectos se terminan. Y que terminan bien. Algo que nunca se acaba es desesperante. Para evitar esto, es conveniente pensar en sacar muchas versiones, por ejemplo. Esto hace que la gente vea objetivos cumplidos, y lo cual motiva a los individuos.
Construir un sentimiento de excelencia
Hacer sentir a los empleados que están trabajando en una gran corporación, que se les mima, que su trabajo es profesional e indispensable. Hacer sentir que cada persona es única. Es preferible gente centrada y productiva que gente controlable. Es imposible controlar a un buen profesional. Déjale que trabaje a gusto; seguramente te sorprenderá gratamente, agradecerá la confianza depositada en él. Déjalos progresar; no presiones a tu equipo.
Preserva y protege equipos victoriosos
Facilita el que si un equipo ha funcionado bien en un proyecto, tenga la oportunidad de realizar más proyectos juntos, si así lo desean. El valor añadido así es muy grande y fundamental. Aprovecha la armonía creada entre los miembros en proyectos pasados.
Provee estrategias, no tácticas
No institucionalices metodologías mágicas que pretenden ser infalibles para todo. El proceso de desarrollo de software es complejo y debe ser desarrollado por personal cualificado. Se han de tener en cuenta riesgos y sucesos no controlados. Es un proceso empírico, no determinista (Ken Schwaber, metodologías Ágiles, SCRUM). No existen las balas de plata. Existen estrategias que nos ayudan a afrontar problemas con cierto abanico de posibilidades de actuación.
Trata de formar grupos heterogéneos
El gestor no forma parte del equipo; es externo. No es un igual a los demás. No debe haber liderazgos en el equipo. Facilita estructuras de red, no de jerarquía. Que cada uno aporte algo distinto; que los miembros del equipo se complementen, aprendan unos de otros.
“Peopleware, Productive projects and teams”
Tom DeMarco y Timothy Lister
Dorset House Publishing Co.,




