Servicios Integrales de e-Business.

Crowdsourcing, SCRUM, e-Marketing, CRM, SCM, ERP, e-Logistic, e-Learning, Software, Hardware, Internet, Intranet, Extranet, CM, e-procurement, Web, e-commerce, teletrabajo, freelances, Outsourcing, SMS, m-Business, SEM, SEO, Redes Sociales - Community Management, hosting, cloud computing, arquitectura de software, m-Business, migración de entornos...

 ... Y contenidos de articulos, blogs, redes sociales, noticias  de tecnología, negocio internet...

info[@]canaldenegocio.com
Messenger
My status
+34 93 185 285 7
   
Nuestro Objetivo:
Su Beneficio con eBusiness
Servicios canaldenegocio.com
Empleo. Dejanos tu curriculum
contactar
¿autónomo?¿empresa? de servicios e-Business.
contactar
¿emprendedor?. Cuentanos tu idea.
contactar
Qué es SCRUM y las Metodologías Ágiles (Kanba, XP...). 

canaldenegocio.com


¿Qué es SCRUM?

Scrum es una metodología para el desarrollo ágil de productos, expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el artículo 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 tecnológicos, además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad.

- Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas.

- El mercado exige ciclos de desarrollo más cortos.

El artículo 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 símil deportivo, se compara al nuevo modelo de desarrollo, basado en el solapamiento de las fases y en un único equipo multi-disciplinar, con la evolución del juego del rugby; y de él se toma el término scrum.

Nonaka y Takeuchi extraen las bases de scrum de las prácticas que observan en las empresas con buenos resultados de rapidez y flexibilidad en la producción: 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 tecnológicos, también 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 integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían 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 descripción sinóptica 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

Planificación del sprint, Revisión diaria, Revisión del sprint.

Sprint

Scrum por sus características no es válido para cualquier proyecto ni para cualquier persona o equipo de personas. Es más, Scrum según muchos especialistas de esta metodología, es óptima para equipos de trabajo de hasta 8 personas, aunque hay empresas que han utilizado Scrum con éxito con equipos más grandes.

Se puede decir que para el 90% de los proyectos y empresas, es una metodología válida, pero no es una metodología válida al 100%. Es más, no hay metodología mejor que otra ni válida al 100% para todas las personas y empresas.

Scrum es por lo tanto, una metodología más de las muchas que hay, y ésta en concreto, se basa en la filosofía del desarrollo ágil que fue expuesto por dos japoneses alrededor del año 1986.

Scrum no es ni la mejor metodología ni la única, pero es una metodología que está empujando muy fuerte por la facilidad de implantación y por su agilidad en cuanto a cambios y lo que propiamente aporta en comparación con otras metodologías.

Por un lado, Scrum evita la burocracia y la generación 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 metodologías es impensable.

Con Scrum por otro lado, la idea principal es la de ponerse a trabajar prácticamente 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 cómo se está haciendo.

¿Como se Aplica?

El scrum es simple en su composición, 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 administración de proyectos; 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 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 económicos y estratégicos 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 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

La figura de líder 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 costarían 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 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:

• 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

Esta compuesto por las personas que diseñan, programan, prueban e implementan el sistema o producto de software.

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

Scrum obliga unas cuantas ceremonias, todas obligatorias. 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.

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

  Descripción: http://www.christiamalvarado.com/wp-content/uploads/2010/04/scrum1-300x233.jpg

 

Scrum es un proceso cíclico de sprints donde el resultado de cada uno debe ser una pieza de software funcionando por encima de diagramas, textos de diseño, etc. Para lograrlo, 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 las tareas acumuladas 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 de las tareas acumuladas 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

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 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 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 más tareas en el tiempo entre dos scrums.

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. Si se descubren nuevos requerimientos durante la revisión del sprint, 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 con una visión renovada. De esta manera estamos cumpliendo con el fundamento de adaptabilidad.

La retrospectiva del sprint

La retroalimentación, el aprendizaje y la experiencia son fundamentales tanto para el sprint como para cualquier otra metodología. 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 miembro del equipo se responde los siguientes interrogantes:

• 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

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

También se recomiendan 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

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 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, 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 común 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. El libre manifiesto de ideas provoca e incentiva los cambios. 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. 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 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. 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.

Descripción: C:\Users\Alberto\AppData\Local\Microsoft\Windows\Temporary Internet Files\FrontPageTempDir\b053d3be.jpg

El backlog del sprint

Una vez que se seleccionan los 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.

La duración 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 programación deben ser tareas específicas para que puedan ser completadas por un miembro del equipo en un día laboral. 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 gráfica de burndown

 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.

Descripción: C:\Users\Alberto\AppData\Local\Microsoft\Windows\Temporary Internet Files\FrontPageTempDir\504764fe.jpg

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 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 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 hará 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.

Ventajas

• 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.

• Las reuniones se dedican a inconvenientes recientes, evitando el estancamiento

Desventajas

• Requiere delegar responsabilidades al equipo, incluso permite fallar si es necesario.

• Es una metodología que difiere del resto, y esto causa cierta resistencia en su aplicación para algunas personas



Autor: Alberto Fernandez (Pionero de Internet en España, MeBA, Scrum Master y Especialista en entornos Microsoft)
Freelance Más información en @AlbertoFdez
Más información en info @ canaldenegocio.com
noticias y novedades e-Business
Artículos en otras Webs
Blogs de e-Business
¿Más información?. Usa nuestros buscadores especializados:
Buscar en documentos cientificos:
Productos de interés:
Libros gratuitos:
Cargando libros, un momento...
Cargando libros, un momento...
Cargando libros, un momento...

canaldenegocio.com

Hemos colaborado para: AUDI - SEAT - WV (GEDAS), La Caixa, SONY, LEVI'S, FIATC, Grupo Godó (La Vanguardia), acv-spain.com, Banc Sabadell, Deutsche Bank, Circulo de Lectores (Grupo Planeta - Group Bertelsmann), Bodegas Peñuela Ontañón, naturmedicapro.com, Comunidad de La Rioja, G y D - Generalitat de Catalunya, Industrias VIGAR, internauto.com, Caixa Tarragona, Caixa Terrassa, Gran Hotel Balneario Blancafort, In&Out, Colegio Arquitectos Islas Baleares, Prénátal, Belfil, Quimicas BIOKIT, ASPACE (Ministerio Asuntos Sociales), internauto.com, BioKit, LEVI'S...
NIF B64641533 * REG.MERCANTIL: BARCELONA, anuncio: 464372, libro 0, seccion 8, inscripcion I/A 1, folio 53, fecha inscripcion 2007-08-20, hoja 353620, tomo 39845.
Todos los derechos reservados de los textos e imágenes pertenecientes a (c)canaldenegocio.com. Para la publicación del contendido, debe solicitarse autorización del Site y del autor del contenidos.