Scrum en Español

Comunidad Agilmática

2008-09-06T22:18:00.000-07:00

Este sitio deja de ser actualizado a favor del sitio comunitario comunidad.agilmatica.com

El contenido ha sido copiado y puede ser consultado y comentado alla.

Te esperamos en la comunidad.

http://comunidad.agilmatica.com

Agilmática

2008-03-14T10:42:00.001-07:00

En Febrero del 2001 un puñado de las más influyentes mentes de la ingenieria de software moderna se reunierón en un resort en Utah y discutierón durante 3 días la necesidad de adoptar mecanismos más ágiles para el desarrollo de software. 17 fuerón los signatarios originales de lo que hoy se conoce como el "Agile Manifesto". A esa reunión asistierón representantes de varias metodologias en uso al momento (DSDM, Scrum, XP, Desarrollo adaptivo, entre otras). Las conclusiones resultado de este "mind-meld" quedarón plasmadas en una declaración de principios que a la fecha establece la base para desarrollar software exitosamente de forma rápida y que da valor a los que pagan el software.

En Noviembre del 2007 y resultado de la imperiosa necesidad de arreglar un proyecto de desarrollo quebrado descubri Scrum [1]. De aplicar con un buen grado de exito la metodologia de Schwaber y Sutherland, nos vimos gradualmente necesitando más y mejores prácticas. Scrum nos enseño que el tradicional metodo de la cascada es una falacia que jamas debio ver visto la luz del día y menos aún haber sido impartida a millones de aprendices de programación. Tuvimos que aprender de nuestros fracasos.

Sin embargo, y los mismos creadores lo indican, Scrum solo ofrece un marco de trabajo que garantiza el exito de un proyecto de desarrollo de software (como si esto fuera poca cosa). Adicionalmente se necesitan de forma integral prácticas y disciplinas que nos ayuden a escribir mejor código, de más calidad y con menos "pulgas". Extreme Programming (XP) consolida estas prácticas, las documenta y las integra en una metodología que por si sola ofrece grandes beneficios para programadores y clientes por igual.

El estudio de estas prácticas ágiles me ha llevado a conocer partes de otras metodolologías que cuando se aplican de forma integral y en cualquier medida resultan en un cambio dramatico en las formas de hacer las cosas alrededor de la programación, un cambio que trae como consecuencia mayor productividad y calidad en el desarrollo y lo que es más importante: verdadero valor y respuesta ágil a las necesidades de los consumidores del software.

Los franceses acuñarón en 1976 el termino "Telematiqué" para referirse a la convergencia de las disciplinas relacionadas con la computación y las comunicaciones. Por otro lado la Informática se refiere a la disciplina que estudia el tratamiento automatizado de la información por medio de ordenadores y la mecamática se refiere al estudio de los fierros sobre los cuales se implementan las soluciones informaticas.

En este orden de ideas podemos entonces sugerir que la "Agilmática" es la disciplina que se encarga del estudio, desarrollo y promoción de prácticas y metodologías ágiles aplicadas al desarrollo de productos de software.

Alistair Cockburn sugiere que el desarrollo de software no es naturalmente una rama de la ingenieria y sugiere la necesidad de reemplazar el termino "Ingeniera de Software" [2].

En el idioma ingles se usa el termino "Agility" o "Agile software development" para referise al conjunto de metodos y prácticas ágiles, creo que podemos encontrar un término más apropiado. Asi entonces dejo a su consideración lo siguiente...

Agilmática: La disciplina de la informática que se encarga del desarrollo, estudio y promoción de prácticas y metodologías ágiles aplicadas de forma integral, profesional y sostenida al desarrollo exitoso de productos de software mediante una gestión iterativa del trabajo alrededor de ese desarrollo.

Mario Estrella
Aprendiz de Agilmática.

Referencias

1. Mike Cohn, 2005; Do_It_Yourself_Oct05 - StickyMinds.com
(http://www.mountaingoatsoftware.com/system/article/file/17/Do_It_Yourself_Oct05.pdf)

2. Cockburn, 2004; The end of software engineering and the start of economic-cooperative gaming
(http://www.comsis.fon.bg.ac.yu/ComSIS/Volume01/InvitedPapers/AlistairCockburn.htm)

Yahoo's scrum lessons

2008-02-18T08:42:00.001-08:00

Yahoo has implemented scrum since 2005 and currently have more than 600 teams using scrum. This are some of their lessons.

read more | digg story

Entrevista con la directora de procesos de Yahoo

2008-02-18T08:24:00.001-08:00

Gabrielle Benefield es la directora de metodologias y procesos de Yahoo y esta es una entrevista con ella respecto de la implementación de Scrum en los equipos de desarrollo.

read more | digg story

scrumalliance wiki / Firms Using Scrum

2008-02-07T20:02:00.001-08:00

Mexico

scrumalliance wiki / Firms Using Scrum

Getting Clueful: 7 Things CIOs Should Know About Agile Development - CIO.com - Business Technology Leadership

2008-02-07T20:01:00.001-08:00

Getting Clueful: 7 Things CIOs Should Know About Agile Development - CIO.com - Business Technology Leadership

History: the Agile Manifesto.

2008-02-06T22:16:00.001-08:00

History: the Agile Manifesto.

Scrum en muchas palabras

2007-12-03T22:27:00.001-08:00

Este articulo describe Scrum detalladamente, para una explicación más breve sigue la liga a Scrum en pocas palabras.

Scrum es una metodología ágil de desarrollo de software que esta centrada en entregar la funcionalidad de más valor para el cliente en el tiempo más corto posible. Al mismo tiempo ofrece la transparencia y control necesarios para el éxito del proyecto. La palabra Scrum no es un acronimo, es el nombre por el que se conoce al esfuerzo esencial de un equipo de Rugby para lograr el objetivo de mover el balón hacia adelante en busca de la meta.

El "framework" scrum es simple en su composición, lo podemos ver como 3 grandes bloques principales

Las personas
Las ceremonias
Los documentos o artefactos

Ningún bloque es más importante que el otro, cada uno aporta un valor equivalente y constituyen entre si un esquema de desarrollo sostenido y sólido.

Las personas

Scrum introduce simplificaciones sobre algunas estructuras tradicionales de la administración de proyectos; los interesados o "stake-holders", el project manager y el equipo, todos tienen su lugar en un Scrum, solo que su función ha sido redefinida de forma que los equipos sean más funcionales y menos burocráticos.

Las principales personas alrededor de un scrum son:

El dueño del producto
El scrum master
El equipo

El dueño del producto

El dueño del producto representa a la empresa, a los usuarios y en general a todos los stake-holders. Es exclusivamente función de solo una persona jugar este papel y representar genuinamente a todos los grupos de interesados en el proyecto.

Por un lado tiene la responsabilidad de hacer que el producto sea redituable para los intereses económicos y estratégicos del negocio; en pocas palabras es el responsable del ROI del producto. 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 más 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 recuperación de la inversión (ROI).
Acepta o rechaza el resultado del trabajo del equipo.

El scrum master

En la gestión tradicional de proyectos el líder del proyecto o project manager es la persona quien tiene la responsabilidad del éxito o fracaso del proyecto y es quien determina que tareas se deben hacer, quien debe hacerlas, cuando y durante cuanto tiempo y cuanto costarían esas tareas.

En Scrum esa figura se transforma de un administrador del proyecto a un coordinador de actividades cuya principal responsabilidad es mantener la efectividad y productividad del equipo protegiéndolo 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:

Es el responsable de 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 prácticas de scrum en toda la organización.
Es un facilitador.
Elimina los impedimentos que el equipo de desarrollo tenga para hacer su trabajo.

El equipo de desarrollo

El equipo de desarrollo de un scrum esta compuesto por las personas que diseñan, programan, prueban e implementan el sistema o producto de software. Son equipos pequeños de 3 a 8 personas.

Sus características y funciones son:

Típicamente de 5 a 9 personas.
Multifuncional (todos diseñan, 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 composición del equipo no puede cambiar durante la iteración.

El tamaño del equipo puede ser tan pequeño como 2 personas y tan grande como 8; por encima de 8 son demasiadas las líneas de comunicación y los espacios físicos requeridos. Entre más pequeño el equipo menor será su velocidad y por consecuencia más largo el tiempo de entrega.

Los demás interesados en el proyecto se involucran activamente en el proyecto mediante una de las ceremonias de la metodología, el scrum diario. Adicionalmente, cualquier interesado puede hacer que sus necesidades y requerimientos sean considerados pero lo hacen exclusivamente a través del dueño del producto.

Las ceremonias

Manteniéndose fiel a los principios del manifiesto ágil, Scrum obliga solo unas cuantas ceremonias, pero son obligatorias todas. Las juntas de Scrum tienen todas como característica principal que están estrictamente limitadas a los tiempos preestablecidos obligando a los involucrados a ser efectivos y hacer uso inteligente del tiempo. Es algo difícil de lograr, pero cuando se logra se obtiene la efectividad de los equipos; lo anterior sucede tan pronto como el 2do sprint y tan tarde como el 4to dependiendo de los impedimentos que se presenten y la agilidad que el equipo logra.

Las ceremonias son:

La junta de planeación del sprint
El scrum diario
La revisión del sprint
La retrospectiva del sprint.

La junta de planeación del sprint

Scrum es un proceso cíclico de sprints donde el resultado de cada uno debe ser una pieza de software funcionando por encima de diagramás, textos de diseño, etc. Para lograr lo anterior de forma exitosa, la planeación es clave. Sin embargo se planea solamente el esfuerzo que se puede realizar durante la duración de un sprint. La reunión de planeación tiene dos objetivos:

Definir el objetivo del sprint. Este objetivo es una descripción textual de una meta tipo SMART que tanto el dueño del producto, el scrum master y el resto del equipo puedan fácilmente visualizar.
Hacer una estimación del tiempo de los requerimientos de más 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 programación necesarias para poder considerar terminado cada uno de los requerimientos aceptados para el sprint.

El resultado de la planeación del sprint es lo siguiente:

La meta del sprint
El backlog del sprint

La duración de la junta de plantación del sprint debe ser suficiente para poder hacer el análisis y las estimaciones de los requerimientos de más alta prioridad. Si es necesario, el dueño del producto debe repriorizar el backlog del producto para obtener lo que sea de más valor para la empresa. En general se puede obtener una buena plantación con un día completo de trabajo separado en 2 partes.

Análisis, evaluación, repriorización y estimación del backlog del producto
Desglose y estimación de las tareas de los requerimientos aceptados por el equipo.

No se recomienda extender esta planeación más allá de un día laboral completo, scrum depende de que las fechas y los compromisos sean respetados por todos.

El Scrum diario

Las bases teóricas de scrum tienen su origen en el control empírico de procesos. Esté indica que la inspección frecuente y la adaptabilidad son clave para la creación de nuevos productos. Scrum facilita este principio por medio de la segunda ceremonia, el Scrum diario o junta de paraditos.

Esta junta de paraditos se conoce así porque se realiza prácticamente con todos los miembros del equipo parados alrededor de un pizarrón o pared de control del proyecto. 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 más y no menos. Ocurre todos los días 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 obligación de asistir todos y cada uno de los scrum diarios, por ello un equipo scrum debe estar 100% dedicado al proyecto. El dueño del producto puede asistir para informarse sobre el proyecto, pero no esta obligado a responder las 3 preguntas.

Un aspecto clave de esta reunión es que cualquier interesado en el proyecto puede asistir a los scrums diarios con la única condición 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 de paraditos es uno de los mecanismos de transparencia de scrum y uno muy poderoso que no debe ser desaprovechado por los interesados o el dueño 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 auto-administrados 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 ultimás 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 más tareas en el tiempo entre dos scrums o juntas de paraditos.

El scrum diario no debe convertirse o manejarse como el mecanismo tradicional de control y rendición 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 señalado y de eliminarlos a toda costa. Si la lista de impedimentos no se disminuye con cada scrum o si peor aún 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 redacción de las preguntas dice que hiciste ayer y que vas a hacer hoy, sin embargo en términos prácticos significan:

¿Que hiciste/lograste desde el ultimo scrum y este?
¿Que vas a hacer/lograr entre este scrum y el siguiente?

La revisión del sprint

La revisión del sprint se programa anticipadamente como resultado de la planeación 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 días, el equipo hace una demostración de la funcionalidad de la pieza (o piezas) de software que se terminaron durante el sprint. Esta demostración se hace directamente en las computadoras del equipo de desarrollo sin mucha preparación previa. La preparación necesaria se hizo a lo largo del sprint y lo que se presenta es lo que interesa al dueño del producto y el resto de los interesados.\

Los invitados a esta reunión son:

El dueño del producto
El maestro scrum
Todo el equipo
Cualquier interesado en el proyecto

La duración de esta demostración debe ser por lo menos de 4 horas y de 8 como máximo. El equipo de desarrollo hace las pruebas de funcionalidad para cada uno de los requerimientos aceptados para el sprint en la planeación que se hizo 30 días antes. Los asistentes hacen preguntas y discuten el resultado del sprint. Si se descubren nuevos requerimientos durante la revisión del sprint como resultado de la misma, estos se integran al backlog del producto para ser priorizados por el dueño del producto antes de la reunión de planeación del siguiente sprint.

El dueño del producto debe aprovechar esta reunión para conocer las opiniones del resto de los interesados, integrar sus propios requerimientos y adaptar el proyecto en base a las nuevas condiciones (si las hay) del entorno de negocios. De esta forma se cumple con el segundo principio fundamental del control empírico de procesos, adaptabilidad. Cada 30 días se tiene la oportunidad de dirigir el esfuerzo de desarrollo y alinearlo a las necesidades actuales de la empresa.

La retrospectiva del sprint

Fundamental para esta y cualquier otra metodología es la retroalimentación, el aprendizaje y la experiencia. Después de la revisión del sprint, el equipo se reúne para evaluar el desempeño durante el sprint recién terminado y como se puede aprender de lo que acaba de terminar para mejorar lo que esta por empezar.

Cada uno de los miembros del equipo hace una retrospectiva del sprint contestando las siguientes preguntas:

Que SI funciona para seguir haciéndolo...
Que NO funciona para dejar de hacerlo y...
Que podemos empezar a hacer para que funcione MEJOR

Los artefactos o documentos

Muchos de los esfuerzos de formalizar el proceso de desarrollo de software han incluido la creación y mantenimiento de diversos "artefactos" documentales que pretenden dar tangibilidad a un proceso de producción de intangibles. La gestión tradicional de proyectos, resultado de los métodos predictivos de control de procesos no cuenta con las herramientas adecuadas para controlar el desarrollo de nuevos productos como lo es el software.

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 bitácora priorizada de requerimientos
El backlog del sprint o bitácora priorizada de tareas
La grafica de burndown

Se proponen documentos adicionales a los anteriores como la grafica de Burnup, la bitácora de impedimentos y otros, sin embargo estos tres son fundamentales para el buen funcionamiento del un equipo Scrum.

El backlog del producto

Uno de los retos más grandes que ha enfrentado la ingeniería de software ha sido el análisis y definición de requerimientos; se han definido, estudiado, implementado y refinado diversos mecanismos para poder saber y registrar lo que el cliente quiere del software. El estudio y la experiencia nos han demostrado que frecuentemente, el cliente es el menos indicado para definir la solución de su problema y por ende la dificultad de conocer lo que necesita; es decir, si el mismo cliente no sabe lo que quiere, como podemos nosotros programarlo. Las metodologías tradicionales enseñan 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 raíz del problema, si hay una constante en el universo es que las cosas cambian y no podemos esperar desarrollar sistemás funcionales y que den valor a nuestros clientes si exigimos una definición exhaustiva de los requerimientos y una congelación de los mismos mientras desarrollamos el producto.

Es ya muy conocido que el cliente al ver el producto visualiza la solución de forma distinta, es decir, la misma solución crea nuevos requerimientos o cambia los existentes. Querer obligar lo contrario es anti-natural y produce sistemás inflexibles que obligan al cliente a adaptarse al sistema. El manifiesto ágil abre las puertas del cielo e invita el cambio, lo provoca y lo incentiva. Scrum define el Backlog del Producto para este fin.

En su forma más esencial el Backlog del producto o bitácora 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. Este listado se puede fácilmente llevar y controlar en una hoja electrónica. 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 dominio problema.

Este listado es priorizado por el dueño del producto de manera permanentemente y estimado por el equipo en cada reunión de planeación.

El backlog del producto debe incluir el mayor numero de requerimientos (User Stories) que se puedan obtener de los usuarios y demás interesados del proyecto a través del dueño del producto y en base a las estimaciones del equipo de programación sirve para estimar el numero de sprints necesarios para terminar con el proyecto u obtener versiones implementables en entornos productivos. El backlog del producto es la herramienta principal para desarrollar y estimar el plan de liberación del producto.

De este backlog el equipo selecciona los requerimientos de más alto nivel que puede completar en 30 días 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 el equipo de desarrollo se compromete a un conjunto finito de requerimientos del Backlog del producto, se definen y estiman las tareas de programación necesarias para cumplir con cada uno de los requerimientos aceptados para el sprint. Esta tarea de desglose de tareas es el equivalente al WBS (Work Breakdown Schedule) de la gestión tradicional de proyectos y solo puede ser realizado por el equipo de desarrollo, particularmente por los miembros que van a trabajar esos requerimientos.

La duración de cada una de las tareas se puede estimar en horas o en las mismás unidades que se estiman los elementos del backlog del producto. Al igual que las estimaciones del backlog del producto, estas no son compromisos para terminar en ese tiempo; más bien son estimaciones honestas de parte del equipo de desarrollo que podrán ser revisadas según se descubran detalles específicos del trabajo a realizar.

Las tareas de programación deben ser tareas especificas y suficientemente atómicas para que puedan ser completadas por un miembro del equipo en un día laboral típico o menos, es decir la estimación de la duración de la tarea debe ser entre 4 y 12 horas. Si es menor de 4 horas quizás sea necesario considerar esa tarea como parte de otra, si es mayor a 12 horas la tarea debe desglosarse un poco más. El objetivo es que se desglosen tareas a las que un miembro del equipo se pueda comprometer terminar de un scrum a otro.

La suma del trabajo de las tareas de un elemento del backlog del producto debe completar el 100% del requerimiento al que pertenecen. Es necesario considerar todas las tareas necesarias para considerar que el requerimiento ha sido completado a satisfacción; el significado de completado es más amplio que lo tradicionalmente entendido, hay que considerar el tiempo de diseño, programación, pruebas, documentación técnica y de usuario entre otras cosas. La definición de completado es un articulo en si mismo y lo atenderemos por separado.

La gráfica de burndown

La gráfica de burndown es al mismo tiempo un mecanismo de control del proyecto y de transparencia del mismo. Este gráfico 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 día es graficada como un punto en la gráfica; en el eje horizontal se determina un punto por cada uno de los días del sprint y de esta forma se obtiene una imagen casi en tiempo real del progreso del trabajo del equipo de desarrollo.

Con el avance del sprint se obtienen suficientes puntos como para poder calcular una línea de tendencia que indica el éxito o fracaso del sprint mucho antes de la fecha de terminación y esto permite adaptar el trabajo del sprint para asegurar que el equipo termine el trabajo y que este sea el más importante.

Puesto que las re-estimaciones de las tareas se realizan de forma diaria y estas estimaciones pueden ser tanto a la baja como a la alta, la gráfica de burndown permite fotografiar el avance de forma diaria y conocer con suficiente anticipación cualquier tendencia fuera de lo normal y poder adaptar el proceso hacia el éxito.

Valores

Scrum es una metodología muy simple en su composición, sin embargo sus fundamentos teóricos y los valores en los que se fundamentan tienen implicaciones que van más allá de la simplicidad de sus componentes. Los valores de scrum y del manifiesto ágil son la goma que une a los personajes en las ceremonias y a través de los documentos y les permite cumplir con sus compromisos día a día, sprint a sprint hasta el éxito del proyecto.

Compromiso
Estar dispuesto para comprometerse a una meta. La metodología 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 más. Alguien lo hara por ti.
Apertura / honestidad
SCRUM mantiene todo acerca del proyecto visible a todos.
Respeto
Los individuos estamos formados por nuestros orígenes 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.

Scrum en pocas palabras

2007-12-01T18:54:00.001-08:00

Scrum es una metodología ágil de desarrollo de software que esta centrada en entregar la funcionalidad de más valor para la empresa en el tiempo más corto posible. Al mismo tiempo ofrece la transparencia y control necesarios para el éxito del los proyectos de desarrollo de software.

En pocas palabras scrum es:

Un marco de trabajo ("framework") para agilizar el desarrollo de software y asegurar que lo más valioso del producto se termine en el tiempo más corto posible. Esta compuesto por equipos multi‑funcionales y auto-administrados encabezados por un Scrum Máster que trabajan en ciclos repetitivos de 30 días conocidos como Sprints. El trabajo a realizar durante cada una de estas cortas iteraciones es seleccionado por el equipo de desarrollo de una lista conocida como el "Product Backlog"; este es un simple listado de requerimientos priorizado por el Dueño del producto en base al valor que cada requerimiento da al negocio. Al principio de cada Sprint se lleva a cabo una reunión de planeación ("Sprint Planning Meeting") donde se analizan los requerimientos más prioritarios y se estima el esfuerzo necesario para completarlos. De ese Product Backlog el equipo selecciona los requerimientos más prioritarios que puede desarrollar completamente en 30 días y define y estima las tareas necesarias para cumplir con esos requerimientos; ese listado de tareas se conoce como el "Sprint Backlog". El equipo trabaja sobre esta lista de tareas durante 30 días con el objetivo de tener una pieza funcional de software al final del Sprint. Al final del sprint el equipo de desarrollo hace una demostración del software que termino al Dueño del producto y cualquier otro interesado del proyecto, esta demostración se conoce como "Sprint Review Meeting". Después de esto, el equipo se reúne para hacer una retrospectiva del sprint que termino para evaluar que se hizo bien, que se hizo mal y que cosas nuevas pueden hacerse para mejorar el siguiente sprint. Este proceso se repite tantas veces como sea necesario hasta que el Dueño del producto determina que tiene un producto que puede ser implementado y puesto a disposición de los usuarios.

Beneficios

Scrum es un proceso mediante el cual se desarrollo software en un marco de trabajo simple, de alta transparencia y efectividad que privilegia la interacción entre las personas por encima de seguir un plan detallado y lleno de documentos. Los beneficios esenciales de hacerlo así son:

Se obtiene software lo más rápido posible y este cumple con los requerimientos más 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.

El fracaso del desarrollo de software

2007-11-30T16:11:00.001-08:00

El desarrollo de software ha sido durante mucho tiempo un mal necesario para las empresas. Se necesita de más y mejor software para mantener o elevar la competitividad, bajar los costos, aumentar las ventas, aumentar la productividad, tener la inteligencia para tomar decisiones; sin embargo el desarrollo cuesta mucho, no se entrega a tiempo, cuando finalmente se entrega se descubre que no era lo que se quería, que no se definieron correctamente los requerimientos y que las condiciones que obligaron el desarrollo ya cambiaron.

Las nuevas tecnologías, el Internet y la velocidad de los mercados multiplican significativamente la complejidad del desarrollo de nuevos productos de software.

Durante este tiempo que las empresas han necesitado del software, también han tenido que sufrir el dolor de tener que desarrollarlo; no solo el dolor de pagar por el desarrollo, eso se puede aliviar con una buena dosis de ROI; sino que las empresas han tenido que sufrir la ineficiencia de los programadores, la falta de comprensión de sus requerimientos, la falta de un seguimiento formal de proyectos, la falta de transparencia del proceso y muchas otras dolencias.

Miles de proyectos han sido abandonados por no terminarse a tiempo o por superar los presupuestos asignados. Miles de proyectos han sido concluidos pero solo para encontrar que no cumplen con lo que la empresa necesita y que apenas instalado el nuevo producto hay que hacerle cambios. Miles de proyectos han sido prometidos para una fecha pero son entregados fácilmente con años de retraso. Miles más ni siquiera se emprenden por no ser costeable el grandísimo esfuerzo.

El desarrollo de software no responde adecuadamente a los cambios, de hecho los resiste.

Las empresas han tenido que cargar con lo anterior y simplemente incluirlo en su costo de hacer negocios.

La industria del desarrollo del software no ha estado satisfecha con lo anterior. Por el contrario, se ha investigado, se ha estudiado, se ha documentado, se ha formalizado y se han implementado diferentes procesos para hacer que el desarrollo de software funcione.

Durante el paso de los años hemos visto como la ingeniería de software ha intentado (con poco éxito en la opinión de este que escribe) mejorar el proceso para hacer que igual que en otras disciplinas éste sea predicable, controlable, productivo y que de los resultados esperados.

Primero se nos enseño que la programación estructurada era la forma de controlar el desarrollo, después pensamos que un proceso de fabricación secuencial era lo adecuado, cuando eso no funciono hicimos un proceso en cascada que poco después lo complementamos con el prototipeado y el desarrollo en espiral.

Al mismo tiempo Booch nos dijo que la programación orientada a objetos era la panacea y que todo debía ser orientado a esos objetos y reorientamos el análisis y el diseño con OOA y OOD. Poco después el proceso unificado nos prometió que si hacíamos casos de uso y de ahí descubríamos esos objetos y regulábamos el proceso con herramientas como RUP tendríamos resultados.

Otros tuvieron otras ideas e inventaron otros procesos, pero tampoco cumplieron la promesa de convertir el desarrollo de software en una actividad eficiente y que diera resultados rápido.

Pensamos durante mucho tiempo que fabricar software tenia que ser muy parecido a construir edificios y que podíamos controlar el proceso de una forma similar. Lo único que obtuvimos fue burocratizar el proceso, haciéndolo mas lento, mas inflexible y mas caro.

Ninguna de esas metodologías han conseguido revolucionar el proceso, solo le han agregado candados, documentación y pasos que dan poco o ningún valor a los que nos compran estos productos.

¿Y entonces?

Muchas de las respuestas y muchas de las soluciones a los problemas del desarrollo de software están en los procesos ágiles como Scrum y eXtreme Programming.

Bienvenida y propósito

2007-11-30T10:28:00.000-08:00

Scrum es un "framework" de desarrollo de software que en los últimos años ha demostrado que el desarrollo de software SI puede funcionar y que SI puede agregar valor a los negocios y que los programadores SI podemos tener mas vida que nuestras computadoras y compiladores.

El Internet ha permitido que ésta y otras metodologías ágiles se diseminen rápidamente por el mundo, sin embargo el 90% de lo que se puede encontrar esta en el casi universal idioma del ingles (para bien o para mal).

Este espacio es un esfuerzo adicional para que estos conocimientos, recursos, artículos y ocurrencias estén al alcance de aquellos que por una razón o por otra no le entran al ingles.

Una de las responsabilidades del Scrum Master es evangelizar los principios del scrum y con este espacio busco cumplir con esa misión.

Bienvenidos al mundo scrum, su viaje será placentero...