Desventajas del SCRUM

Recientemente se habla mucho de las ventajas de las metodologas giles, y en concreto de SCRUM. Sin embargo, como toda metodologa, tiene sus altibajos, la idea de exponerlos es para que podamos tenerlos en cuenta en caso de que se apliquen a nuestros proyectos. Al final, lo importante es saber detectar los riesgos y mitigarlos adecuadamente.

En

general,

dificultad

de

aplicacin

en

grandes

proyectos.

Se requiere de un agile champion, experto en la metodologa que monitorice su cumplimiento. Parte del paradigma consiste en usar el mtodo tal cual, evitando adaptarlo a la empresa (supuestamente esto saca a la luz problemas en la metodologa de desarrollo existente). Claro, si por otro lado arrancamos con el mtodo ya adaptado a la empresa, es posible que no estemos aprovechando las ventajas de la metodologa gil. Plantea un problema si el desarrollo est restringido por una fecha de entrega y un precio de entrega cerrados por contrato Presupone que los requerimientos cambian, pero no de forma que el cliente acepte un diseo funcional/tcnico. Presupone que el equipo est muy formado y motivado Presupone que el cliente est muy involucrado en el desarrollo, participa de forma activa y continua, y revisa frecuentemente el avance de la funcionalidad conforme salen a la luz los sprints. Esto sin embargo no parece producirse en la mayora de nuestros proyectos: el cliente participa,

pero no hasta el punto de dedicar tiempo y recursos para revisar pequeos avances en el desarrollo. Presupone que el cliente no exige ni necesita toda la documentacin que manejan actualmente las empresas y que las diversas normativas internacionales requieren. Desde el punto de vista de la metodologa parece que hay muchas, y as es. Pero esto no deja de ser una visin general de riesgos como en cualquier otro proyecto.
Fuente: http://www.optimus-software.com/noticias/2011/11/28/desventajas-del-scrum/

Mtodo Scrum en Administracin de proyectos de Software

Qu es SCRUM? Scrum es una metodologa para el desarrollo gil de productos, expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el artculo The New New Product Development Game [Harvard Business Review Ene-Feb 1986] en el que ponen de manifiesto que: - El mercado competitivo de los productos tecnolgicos, adems de los conceptos bsicos de calidad, coste y diferenciacin, exige tambin rapidez y flexibilidad. - Los nuevos productos representan cada vez un porcentaje ms importante en el volumen de negocio de las empresas. - El mercado exige ciclos de desarrollo ms cortos. El artculo compara al desarrollo tradicional de ciclo de vida formado por fases separadas y equipos especializados con las carreras de relevos, donde un equipo pasa el testigo al siguiente hasta finalizar el desarrollo del producto. Siguiendo el smil deportivo, se compara al nuevo modelo de desarrollo, basado en el solapamiento de las fases y en un nico equipo multi-disciplinar, con la evolucin del juego del rugby; y de l se toma el trmino scrum. Nonaka y Takeuchi extraen las bases de scrum de las prcticas que observan en las empresas con buenos resultados de rapidez y flexibilidad en la produccin: Xerox, Canon, Honda, NEC, Epson, Brother, 3M o Hewlett-Packard; y son: Inestabilidad consustancial al entorno de desarrollo. Equipos auto-organizados. Solapamiento de las fases del desarrollo. Multi-aprendizaje. Control sutil. Transferencia de aprendizaje a nivel organizacional. Aunque surgi como modelo para el desarrollo de productos tecnolgicos, tambin se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones

frecuentes en el desarrollo de determinados sistemas de software. Jeff Sutherland aplic el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integrara en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo present junto con Ken Schwaber como proceso formal, tambin para gestin del desarrollo de software en OOPSLA 96. Ms tarde, en 2001 seran dos de los promulgadores del Manifiesto_gil. En el desarrollo de software scrum est considerado como modelo gil por la Agile Alliance. La ficha adjunta incluye una descripcin sinptica del proceso y sus elementos que son: Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados. Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento. Reuniones Planificacin del sprint, Revisin diaria, Revisin del sprint. Sprint Scrum por sus caractersticas no es vlido para cualquier proyecto ni para cualquier persona o equipo de personas. Es ms, Scrum segn muchos especialistas de esta metodologa, es ptima para equipos de trabajo de hasta 8 personas, aunque hay empresas que han utilizado Scrum con xito con equipos ms grandes. Se puede decir que para el 90% de los proyectos y empresas, es una metodologa vlida, pero no es una metodologa vlida al 100%. Es ms, no hay metodologa mejor que otra ni vlida al 100% para todas las personas y empresas. Scrum es por lo tanto, una metodologa ms de las muchas que hay, y sta en concreto, se basa en la filosofa del desarrollo gil que fue expuesto por dos japoneses alrededor del ao 1986. Scrum no es ni la mejor metodologa ni la nica, pero es una metodologa que est empujando muy fuerte por la facilidad de implantacin y por su agilidad en cuanto a cambios y lo que propiamente aporta en comparacin con otras metodologas. Por un lado, Scrum evita la burocracia y la generacin documental. No es que con Scrum no se deba o no se pueda documentar, si no que con Scrum no se exige documentar nada para iniciar un proyecto, algo que en otras metodologas es impensable. Con Scrum por otro lado, la idea principal es la de ponerse a trabajar prcticamente desde el primer momento y empezar a sacar frutos de ese trabajo para que el cliente vaya viendo los avances y se quede satisfecho con lo que se est haciendo y cmo se est haciendo. Como se Aplica? El scrum es simple en su composicin, lo podemos ver como 3 grandes bloques principales Las personas Las ceremonias Los documentos o artefactos Las personas Scrum introduce simplificaciones sobre algunas estructuras tradicionales de la administracin de proyectos; todos tienen su lugar en un Scrum, solo que su funcin ha sido redefinida de forma que los equipos sean ms funcionales y menos burocrticos.

Las principales personas alrededor de un scrum son: El dueo del producto El scrum master El equipo

El dueo del producto El dueo del producto representa a la empresa, a los usuarios y en general a todas las personas que intervienen en la empresa. Por un lado tiene la responsabilidad de hacer que el producto d un beneficio para los intereses econmicos y estratgicos del negocio. Por otro lado tiene la responsabilidad de asegurarse que todos los requerimientos de los diferentes grupos de usuarios del sistema sean contemplados. Sus funciones y responsabilidades ms importantes son: Define los requerimientos y funciones del sistema. Prioriza las funciones a desarrollar de acuerdo al valor que aporten al negocio o mercado. Decide cuando liberar el producto del proyecto. Es el responsable directo sobre la recuperacin de la inversin (RoI). Acepta o rechaza el resultado del trabajo del equipo.

El scrum master La figura de lder de proyecto, como persona que tiene la responsabilidad del xito o fracaso del proyecto; quien determina que tareas se deben hacer, quien debe hacerlas, cuando y durante cuanto tiempo y cuanto costaran esas tareas; se transforma de un administrador del proyecto a un coordinador de actividades cuya principal responsabilidad es mantener la efectividad y productividad del equipo protegindolo de fuerzas externas que distraigan el esfuerzo de desarrollo. Los equipos en scrum son auto-administrados por lo que no se requiere alguien sirviendo de gerente o manager. Sus funciones y responsabilidades esenciales son: Que el esfuerzo de desarrollo sea exitoso. Protege al equipo de interferencias externas. Mantiene el enfoque y efectividad del equipo. Evangeliza los principios, valores y prcticas de scrum en toda la organizacin. Es un facilitador. Elimina los impedimentos que el equipo de desarrollo tenga para hacer su trabajo.

El equipo de desarrollo Esta compuesto por las personas que disean, programan, prueban e implementan el sistema o producto de software. Sus caractersticas y funciones son: Tpicamente de 5 a 9 personas.

 Multifuncional (todos disean, programan, prueban). De tiempo completo. Auto-administrados. No se les asigna trabajo, cada quien selecciona tareas de la lista de tareas por hacer conocida como el sprint backlog. La composicin del equipo no puede cambiar durante la iteracin. El tamao del equipo puede ser tan pequeo como 2 personas y tan grande como 8; por encima de 8 son demasiadas las lneas de comunicacin y los espacios fsicos requeridos. Entre ms pequeo el equipo menor ser su velocidad y por consecuencia ms largo el tiempo de entrega. Los dems interesados en el proyecto se involucran activamente en el proyecto mediante una de las ceremonias de la metodologa, el scrum diario. Adicionalmente, cualquier interesado puede hacer que sus necesidades y requerimientos sean considerados pero lo hacen exclusivamente a travs del dueo del producto.

Las ceremonias Scrum obliga unas cuantas ceremonias, todas obligatorias. Las juntas de Scrum tienen todas como caracterstica principal que estn estrictamente limitadas a los tiempos preestablecidos obligando a los involucrados a ser efectivos y hacer uso inteligente del tiempo. Las ceremonias son: La junta de planeacin del sprint El scrum diario La revisin del sprint La retrospectiva del sprint. La junta de planeacin del sprint

Scrum es un proceso cclico de sprints donde el resultado de cada uno debe ser una pieza de software funcionando por encima de diagramas, textos de diseo, etc. Para lograrlo, la planeacin es clave. Sin embargo se planea solamente el esfuerzo que se puede realizar durante la duracin de un sprint. La reunin de planeacin tiene dos objetivos: Definir el objetivo del sprint. Este objetivo es una descripcin textual de una meta tipo SMART que tanto el dueo del producto, el scrum master y el resto del equipo puedan fcilmente visualizar. Hacer una estimacin del tiempo de los requerimientos de ms alta prioridad y seleccionar sobre esa base cuantos se pueden lograr terminar en el sprint. Para hacer lo anterior, el equipo y el scrum master desglosan las tareas de programacin necesarias para poder considerar terminado cada uno de los requerimientos aceptados para el sprint. El resultado de la planeacin del sprint es lo siguiente: La meta del sprint El backlog del sprint La duracin de la junta de plantacin del sprint debe ser suficiente para poder hacer el anlisis y

las estimaciones de los requerimientos de ms alta prioridad. Si es necesario, el dueo del producto debe repriorizar las tareas acumuladas del producto para obtener lo que sea de ms valor para la empresa. En general se puede obtener una buena plantacin con un da completo de trabajo separado en 2 partes. Anlisis, evaluacin, repriorizacin y estimacin de las tareas acumuladas del producto Desglose y estimacin de las tareas de los requerimientos aceptados por el equipo. No se recomienda extender esta planeacin ms all de un da laboral completo, scrum depende de que las fechas y los compromisos sean respetados por todos.

El Scrum diario Al igual que el resto de las ceremonias, el scrum diario esta estrictamente limitado en su tiempo y para este caso es de 15 minutos, no ms y no menos. Ocurre todos los das laborales a la misma hora y en el mismo lugar. Cada uno de los miembros del equipo y el maestro scrum tienen la responsabilidad y obligacin de asistir todos y cada uno de los scrum diarios, por ello un equipo scrum debe estar 100% dedicado al proyecto. El dueo del producto puede asistir para informarse sobre el proyecto, pero no esta obligado a responder las 3 preguntas. Un aspecto clave de esta reunin es que cualquier interesado en el proyecto puede asistir a los scrums diarios con la nica condicin que no pueden interrumpir de ninguna forma el trabajo del equipo durante esos 15 minutos. Scrum provee diversos mecanismos por medio del cual los interesados en el proyecto pueden conocer el progreso del proyecto y agregar sus propios requerimientos al backlog del producto. La junta diaria es uno de los mecanismos de transparencia de scrum y uno muy poderoso que no debe ser desaprovechado por los interesados o el dueo del producto. Durante estos 15 minutos cada miembro del equipo responde a tres preguntas: Que hiciste/lograste ayer? Que vas a hacer/lograr hoy? Que impedimentos tienes para lograrlo? Las primeras 2 preguntas son en base a tareas del backlog del sprint. Los equipos scrum son autoadministrados y cada miembro toma libremente tareas de la lista del backlog del sprint en lugar de ser asignadas por el scrum master; por lo anterior, la respuesta a las primeras 2 preguntas giran alrededor de tareas que se lograron terminar en las ultimas 24 horas y cuales se pueden lograr durante las siguientes 24. El desglose de cada requerimiento se hace en tareas que no son mayores a 12 horas o menores a 4; de forma que los miembros del equipo pueden comprometerse a terminar una o ms tareas en el tiempo entre dos scrums. El scrum diario no debe convertirse o manejarse como el mecanismo tradicional de control y rendicin de cuentas de un gerente de proyectos. Cada miembro del equipo en respuesta principalmente a la segunda pregunta asume un compromiso personal con cada uno de los miembros del equipo de terminar lo que dice que puede terminar. Si no puede terminarlo debe tener la honestidad, la integridad y el coraje de aceptar que no puede terminarlo, determinar que SI puede terminar y comprometerse a ello.

El maestro scrum tiene la responsabilidad de registrar los impedimentos que el equipo haya sealado y de eliminarlos a toda costa. Si la lista de impedimentos no se disminuye con cada scrum o si peor an empieza a crecer, el maestro scrum no esta haciendo una de sus funciones principales. En tal caso el equipo puede sugerir que se interrumpa el sprint de forma extraordinaria. Cada miembro del equipo debe conocer a detalle lo relacionado con los requerimientos y en base a ese conocimiento se auto-asigna tareas y se compromete a terminarlas de un scrum a otro. La redaccin de las preguntas dice que hiciste ayer y que vas a hacer hoy, sin embargo en trminos prcticos significan: Que hiciste/lograste desde el ultimo scrum y este? Que vas a hacer/lograr entre este scrum y el siguiente?

La revisin del sprint La revisin del sprint se programa anticipadamente como resultado de la planeacin del sprint, todo el equipo esta enfocado en lograr la meta que se defini para el sprint, de ah su nombre, scrum. Al final de los 30 das, el equipo hace una demostracin de la funcionalidad de la pieza (o piezas) de software que se terminaron durante el sprint. Esta demostracin se hace directamente en las computadoras del equipo de desarrollo sin mucha preparacin previa. La preparacin necesaria se hizo a lo largo del sprint y lo que se presenta es lo que interesa al dueo del producto y el resto de los interesados. Los invitados a esta reunin son: El dueo del producto El maestro scrum Todo el equipo Cualquier interesado en el proyecto La duracin de esta demostracin debe ser por lo menos de 4 horas y de 8 como mximo. El equipo de desarrollo hace las pruebas de funcionalidad para cada uno de los requerimientos aceptados para el sprint en la planeacin que se hizo 30 das antes. Si se descubren nuevos requerimientos durante la revisin del sprint, estos se integran al backlog del producto para ser priorizados por el dueo del producto antes de la reunin de planeacin del siguiente sprint. El dueo del producto debe aprovechar esta reunin para conocer las opiniones del resto de los interesados, integrar sus propios requerimientos y adaptar el proyecto con una visin renovada. De esta manera estamos cumpliendo con el fundamento de adaptabilidad.

La retrospectiva del sprint La retroalimentacin, el aprendizaje y la experiencia son fundamentales tanto para el sprint como para cualquier otra metodologa. Despus de la revisin del sprint, el equipo se rene para evaluar el desempeo durante el sprint recin terminado y como se puede aprender de lo que acaba de terminar para mejorar lo que esta por empezar. Cada miembro del equipo se responde los siguientes interrogantes: Que SI funciona para seguir hacindolo...

 Que NO funciona para dejar de hacerlo y... Que podemos empezar a hacer para que funcione MEJOR

Los artefactos o documentos Scrum propone y obliga solo 3 documentos fundamentales que son usados tanto para gestionar el proyecto y sus tareas como para dar seguimiento, visibilidad y transparencia al proceso: El backlog del producto o bitcora priorizada de requerimientos El backlog del sprint o bitcora priorizada de tareas La grafica de burndown Tambin se recomiendan la grafica de Burnup, la bitcora de impedimentos y otros, sin embargo estos tres son fundamentales para el buen funcionamiento del un equipo Scrum.

El backlog del producto El estudio y la experiencia nos han demostrado que frecuentemente, el cliente no es capaz de definir puntualmente su problema y mucho menos lo que necesita y como podemos nosotros programarlo si l mismo no lo sabe. Las metodologas tradicionales ensean que los requerimientos deben fijarse al principio del proyecto y definirse de tal forma y con tal alcance que no haya dudas, mal entendidos o cambios en los mismos; he ah la raz del problema, ya que las cosas cambian inesperadamente y no podemos esperar desarrollar sistemas funcionales y que den valor a nuestros clientes si exigimos que los requerimientos se congelen en el tiempo mientras nosotros desarrollamos el producto. Es muy comn que el cliente al ver el producto visualiza la solucin de forma distinta, es decir, la misma solucin crea nuevos requerimientos o cambia los existentes. El libre manifiesto de ideas provoca e incentiva los cambios. Scrum define el Backlog del producto para este fin. En su forma ms esencial el Backlog del producto o bitcora de requerimientos es un simple listado de requerimientos expresados en forma de Historias de Usuario (User Stories) y estimados en alguna unidad representativa del tiempo. Estas Historias de Usuario deben estar expresadas exclusivamente en el lenguaje del negocio y deben aportar un valor real al mismo que pueda ser definido y visualizado por cualquiera que conozca el problema. El backlog del producto debe incluir el mayor numero de requerimientos (User Stories) que se puedan obtener de los usuarios y dems interesados del proyecto a travs del dueo del producto y en base a las estimaciones del equipo de programacin sirve para estimar el numero de sprints necesarios para terminar con el proyecto. El backlog del producto es la herramienta principal para desarrollar y estimar el plan de liberacin del producto. De este backlog el equipo selecciona los requerimientos de ms alto nivel que puede completar en 30 das en base a su capacidad y velocidad de desarrollo y produce el siguiente artefacto documental del Scrum, el backlog del sprint.

El backlog del sprint Una vez que se seleccionan los requerimientos del Backlog del producto, se definen y estiman las

tareas de programacin necesarias para cumplir con cada uno de los requerimientos aceptados para el sprint. La duracin de cada una de las tareas se puede estimar en horas o en las unidades que se estiman los elementos del backlog del producto. Pero no dejan de ser solo estimaciones, a medida que pase el tiempo el equipo puede volver a plantear estos tiempos si lo ve necesario. Las tareas de programacin deben ser tareas especficas para que puedan ser completadas por un miembro del equipo en un da laboral. Si es menor de 4 horas quizs sea necesario considerar esa tarea como parte de otra, si es mayor a 12 horas la tarea debe desglosarse un poco ms. El objetivo es que se desglosen tareas a las que un miembro del equipo se pueda comprometer terminar de un scrum a otro. La grfica de burndown Este grfico permite conocer de manera gil y visual el progreso o no de los trabajos del proyecto. Diariamente cada miembro del equipo de desarrollo actualiza la(s) tarea(s) en que esta trabajando y estima de nuevo el tiempo necesario para terminar la tarea. La suma de las estimaciones de las tareas pendientes por terminar de cada da es graficada como un punto en la grfica; en el eje horizontal se determina un punto por cada uno de los das del sprint y de esta forma se obtiene una imagen casi en tiempo real del progreso del trabajo del equipo de desarrollo.

Valores Scrum es una metodologa muy simple en su composicin, sin embargo sus fundamentos tericos y los valores en los que se fundamenta es lo que hace a su complejidad. Los valores de scrum y del manifiesto gil son la goma que une a los personajes en las ceremonias y a travs de los documentos y les permite cumplir con sus compromisos da a da, sprint a sprint hasta el xito del proyecto. Compromiso - Estar dispuesto para comprometerse a una meta. La metodologa la da a las personas la autoridad que necesitan para cumplir con sus compromisos. Enfoque Haz tu trabajo - Enfoca todos tus esfuerzos y habilidades para trabajar en lo que te comprometiste a hacer. No te preocupes por nada ms. Alguien lo har por ti. Apertura / honestidad - SCRUM mantiene todo acerca del proyecto visible a todos. Respeto - Los individuos estamos formados por nuestros orgenes y nuestras experiencias. Es importante respetar las diferentes a las personas del equipo y sus formas de pensar. Coraje - Tener el coraje para comprometerse, actuar, ser honesto y esperar respeto.

Ventajas Se obtiene software lo ms rpido posible y este cumple con los requerimientos ms importantes. Se trabaja en iteraciones cortas, de alto enfoque y total transparencia. Se acepta que el cambio es una constante universal y se adapta el desarrollo para integrar los cambios que son importantes.

 Se incentiva la creatividad de los desarrolladores haciendo que el equipo sea auto administrado. Se mantiene la efectividad del equipo habilitando y protegiendo un entorno libre de interrupciones e interferencias. Permite producir software de una forma consistente, sostenida y competitiva. Las reuniones se dedican a inconvenientes recientes, evitando el estancamiento

Desventajas Requiere delegar responsabilidades al equipo, incluso permite fallar si es necesario. Es una metodologa que difiere del resto, y esto causa cierta resistencia en su aplicacin para algunas personas

Fuente: http://www.taringa.net/posts/apuntes-y-monografias/1079954/Metodo-Scrum-enAdministracion-de-proyectos-de-Software.html