SCRUM

Scrum – Libro interesante.

En este enlace:

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Podeis descargar el libro «SCRUM desde las trincheras». Es un libro excelente (fácil y rápido de leer) de como los autores del mismo han puesto en práctica SCRUM en su organización y las lecciones aprendidas.

SCRUM es ya una de las metodologías más usadas hoy en día en las organizaciones dedicadas al desarrollo del software. Curiosamente es una metodología que no fue concebida inicialmente para desarrollar software (quizás de ahí su potencia). Para este curso debeis leer los siguientes capítulos (aunque os recomiendo la lectura completa):

– CÓMO HACEMOS PILAS DE PRODUCTO

– CÓMO HACEMOS LA PLANIFICACION DE SPRINT

– CÓMO HACEMOS PILAS DE SPRINT

– CÓMO HACEMOS LA DEMO DE SPRINT.

How Do Scrum and CCPM Compare?

  • admin 

Fuente: http://www.reformingprojectmanagement.com/2003/11/14/273/

How Do Scrum and CCPM Compare?

A reader asked the group how Scrum compares with Critical Chain Project Management (CCPM). 

Scrum is one of several Agile/Lean Software Development techniques. The opposite of Scrum/Agile/Lean is the waterfall development lifecycle where analysis, design, development, system testing, and user acceptance testing are done in sequential phases. Scrum/Agile/Lean works in short iterations – between 1 and 12 weeks each.

THE CORE CONFLICT FOR SOFTWARE DEVELOPMENT PROJECTS (AND MOST OTHERS I IMAGINE) LOOKS LIKE THIS.

[This is a fine example of Goldratt’s Evaporating Cloud]

    D - Allow change throughout project
  B - Build functionality required by customer
A - Have a successful software project
  C - Deliver on time and to budget
    D'- Agree scope up-front and don't allow change throughout project

[Read the above chart this way: I want (A) a successful software project. To be successful I need (B) to build the functionality required by my customer. And I need (C) to deliver on time and on budget. For me to build the functionality required by my customer I need (D) to allow for change throughout the project. However, for me to deliver on time and budget I need (D’) to agree to the scope up-front and not allow changes throughout the project. (D) and (D’) are in conflict and cannot coexist.]

In a traditional/waterfall environment «change control» is the mechanism used to do both D and D’ poorly.

The agile approaches attack three assumptions:

Assumption CE1
We can prevent change if we spend enough time to ensure we get everything agreed and signed off up front. Agile/lean says that CE1 is just plain wrong (in all but the simplest environments). Therefore, E doesn’t even give you C. Even if we get the requirements right up front, they will change, so if we don’t change them as we go then while C (finish on time and budget) is satisfied, we won’t satisfy B (customer gets what they need) so that A (the project) isn’t successful.
Assumption CE2
It is many times more expensive (i.e. Boehm’s cost of change curve) to change the further we get into the project. Agile/lean says that CE2 is wrong too. For instance XP (eXtreme Programming), a cousin of Scrum, suggests that the cost of change curve quickly becomes flat when using test-driven development and refactoring in a iterative/incremental approach.
Assumption CE3
The project only delivers value when it is finished. Agile/Lean says that you don’t have to deliver everything at once to get value. Instead you can get value quite quickly by delivering small high-priority increments of the product. At the very least you gain value by discovering what’s not working much, earlier.

[Clarke examines three cause and effect assumptions behind the evaporating cloud as it was described. He sets out to invalidate each one.]

THE KEY POINTS OF SCRUM ARE:
A product owner manages a product backlog.
This is a list of high-level requirements/features – e.g. user can register, user can login, user can add items to a shopping cart, user can search for books, etc – that has been prioritized by the product owner. It will also include «technical things» – e.g. install server, upgrade source management system – added to it if requested by the developers and agreed by the owner.
Every 30 days a new «sprint» starts.
Each sprint is a 30-day iteration where the development team picks a set of features from the product backlog that they estimate they can «deliver» within the next 30 calendar days. They then work on that sprint for the next 30 days.
During this time no changes can be made to the sprint unless suggested by the developers.
«Delivered» means that the feature could potentially, although not necessarily, be shipped or implemented.
It’s fully coded and tested, the help is prepared, it’s not going to break when the users get hold of it.
Each scrum team is self-managing with guidance from the «Scrum master».
Initially the team will struggle with self-management but, apparently, they learn quickly. Each day a 15 minute meeting is held where each person answers 3 questions – what did I do yesterday?, what will I do today? And what obstacles are holding me up? It is the Scrum master’s job to clear the obstacles.
The theory behind scrum says that complex processes, such as software development, change too much and are too difficult to manage.
They need to be managed empirically, with constant inspection and adaptation.

[Those of you who use the Last Planner System™ will recognize similarities with Scrum. The backlog of tasks grows, as does a weekly work plan, as the project goes along. Project performers take tasks from the backlog making promises to complete them. The Scrum approach is done or not done. No credit for effort. And very much like lean, people understand their projects as complex and evolving.]

HOW DOES SCRUM DIFFER FROM CRITICAL CHAIN?
  • CC aims to get the project finished as quickly and reliably as possible. Scrum aims to get working functionality delivered as quickly as possible.
  • CC buffers with time. Scrum buffers with functionality.
  • CC says «Don’t put the safety in the task; put it in the project». Scrum says «Don’t try and figure it all out up front because you can’t. Things will change too much as you go. Instead, build working software quickly, inspect and adapt».

Despite these differences I believe that CC and Scrum are not only complimentary but synergy should be gained by using both together. That said, I don’t know of anyone doing this. Scrum is mostly used in IT along with changed engineering practices, but it has been used in non-IT projects.

¿Scrum vs ITIL o Scrum + ITIL?

  • admin 

fuente: http://www.re-inventa.com/scrum-vs-itil/

¿Está ITIL reñido con Scrum o, por el contrario, son compatibles? Principalmente es una duda que le surge a personas del ámbito de desarrollo de software que están dando sus primeros pasos en el agilismo y que han oído hablar sobre ITIL y sus bondades, aunque todavía no lo conocen con suficiente profundidad.

Pues bien, la respuesta es simple pero compleja al mismo tiempo. ITIL y Scrum, aunque pueden guardar cierta relación, son cosas muy distintas. Están completamente enfrentados a nivel de objetivos y de filosofía subyacente pero, a pesar de ello, pueden compatibilizarse sin que necesariamente haya menoscabo de ninguno de los dos enfoques. En mi opinión, el objetivo tiene que ser obtener lo mejor de ambos mundos y, por experiencia personal, puedo asegurar que se trata de algo completamente factible.

En esta línea, ya escribí una entrada sobre lo que yo denomino Agile ITIL, en la que explico mi experiencia aplicando Scrumban + ITIL en el área de sistemas de BikoEn este post, en cambio, mi objetivo es aclarar en mayor medida cuáles son las diferencias y algunos de los nexos de unión entre Scrum e ITIL.

.

¿Qué es Scrum?

Scrum es una metodología ágil de gestión de proyectos (project management) orientada a ámbitos poco ordenados:

  • Metodología:  Scrum admite cierta flexibilidad en su implementación pero exige que se apliquen todos sus roles, procesos y artefactos. Podemos llevar a cabo un daily scrum que dure 5 o 15 minutos, llevar el product backlog en un Excel, en Jira o en ScrumWise, tener 3 o 20 columnas de estado en nuestro panel… pero si no llevamos a cabo el scrum diario, no tenemos product backlog, no tenemos panel, no existe la figura de product owner o no hacemos retrospectivas… lo que hacemos podría considerarse ‘agile’, dependiendo del caso, pero no sería Scrum. Sólo con que prescindamos de uno de estos elementos, no estaremos haciendo propiamente Scrum (en la forma en que Jeff Sutherland y Ken Schwaber lo definieron, otra cosa es el concepto de ‘campo de scrum’ de Nonaka y Takeuchi en The New Product Development Game).
  • Ágil: es acorde a los principios del manifiesto ágil, por lo que el énfasis de la gestión se traslada a las personas y las interacciones, al producto funcionando, a la colaboración con el cliente y a la respuesta ante el cambio. En consecuencia, como toda metodología ágil, Scrum es especialmente adecuado cuando lo que prima es el conocimiento tácito.
  • Gestión de proyectos: los proyectos son un esfuerzo temporal para crear un producto, un servicio o un resultado único. Tienen un principio y un final bien definidos.
  • Ámbitos poco ordenados: son aquellos entornos cambiantes, en los que además hay muchas variables que influyen en los resultados y, por ello, se hace difícil la predicción apriorista. El desarrollo de software es un ámbito poco ordenado porque, entre otras cosas, como bien sabemos, por detallado que sea el análisis de requisitos inicial, siempre surgen nuevos requerimientos a medida que avanzamos en el proyecto.

¿Qué es ITIL?

ITIL es un marco predictivo de buenas prácticas en gestión de servicios de TI, que suele aplicarse en ámbitos ordenados:

  • Marco (framework): ITIL reúne herramientas y principios de gestión generalmente aceptados como buenas prácticas. Al tratarse de un marco, no es rígido en su implantación, en el sentido de que permite implementar únicamente los procesos o grupos de procesos que nos interesen: gestión de la configuración, gestión de cambios, gestión de incidencias, etc.
  • Predictivo: a diferencia de las metodologías ágiles, ITIL pone énfasis en los procesos y las herramientas, en la documentación, en las relaciones contractuales y los SLAs y en el seguimiento de procedimientos y planes predefinidos. En consecuencia, los mejores resultados con ITIL se obtendrán cuando el conocimiento explícito tenga preponderancia sobre el tácito para la ejecución del trabajo o de una tarea concreta.
  • Buenas prácticas: las buenas prácticas son mejores prácticas cuyo uso se ha extendido y sobre las que existe un consenso generalizado de que su aplicación contribuye al éxito del servicio. En consecuencia, el cuerpo de buenas prácticas identificadas por ITIL evoluciona con el paso del tiempo, mientras que los roles, procesos y artefactos de Scrum son los que son.
  • Gestión de servicios: los servicios son operaciones, una función de la organización que se efectúa permanentemente. Por lo tanto, en comparación con los proyectos tienen un marco temporal muy distinto. En consecuencia, los principios de gestión generalmente aceptados para ambos también son diferentes.
  • Ámbitos ordenados: son aquellos en que las variables que influyen en el resultado de una acción están bien identificadas, por ello los modelos que dan mejores resultados son los predictivos.

Analogías entre Scrum e ITIL

Aunque llegados a este punto resulta sencillo identificar las diferencias entre Scrum e ITIL, anexo la siguiente tabla que resulta más gráfica:

Scrum e ITIL: Tabla comparativa

Además de los puntos ya mencionados en las definiciones, en la tabla he añadido elproceso de mejora continua. Aunque el proceso de mejora de ambas metodologías se basa en la filosofía del ciclo de Deming (PDCA)Scrum, con sus retrospectivas, hace mayor énfasis en el expertise y la percepción de los miembros del equipo (orientación a personas); mientras que ITIL se fundamenta en métricas objetivas relacionadas con el nivel de desempeño de los procesos (orientación a procesos). Obviamente, cada una tiene sus pros y sus contras.

Otro aspecto diferencial es la amplitud de miras. Mientras que el ámbito de Scrum es genuinamente el proyecto, obviando los aspectos a nivel organizacional y confiando en la auto-organización del equipo, ITIL tiene una perspectiva más holística: destaca la relevancia de alinear los proyectos y servicios con las necesidades y los objetivos de negocio, el desarrollo de los profesionales del equipo para que puedan responder a las necesidades organizativas, la gestión del conocimiento, etc. Para tal propósito, ITIL explicita diversos procesos y funciones específicos.

Como puede verse, las diferencias son múltiples y reseñables. Sin embargo, a pesar de ello, existen más nexos de unión entre ambos enfoques de lo que pueda parecer a primera vista. Saber combinar e hibridar las prácticas y herramientas de ambos enfoques de la manera adecuada, es la clave para obtener lo mejor de los dos mundos y un rendimiento extraordinario.

Nexos de unión (I): ITIL + Scrum

Vamos a poner como ejemplo que nuestro núcleo duro es la gestión de operaciones. Nuestro equipo se dedica a gestionar varios servicios de tecnologías de la información para una organización determinada: administrar y mantener una intranet, un servicio de correo electrónico, un ERP, etc. En este caso, ITIL debería tener un gran peso en la gestión de nuestro día a día.

Sin embargo, llega el momento de implantar un nuevo servicio. Esto se trata de un proyecto en toda regla.

ITIL nos indica aspectos que debemos tener en cuenta en el diseño de dicho servicio: gestión del nivel de servicio, gestión de la disponibilidad del servicio, gestión de la capacidad del servicio, gestión de la seguridad del servicio…

Sin embargo, ITIL no entra en el detalle de cómo debe gestionarse el proyecto de implementación en sí mismo. No habla sobre si el equipo debe ser multidisciplinar o no, ni de los roles que debe haber dentro del equipo, ni cómo deben gestionarse el alcance, el cronograma, la calidad, la comunicación con los interesados o el riesgo.

En este punto es donde fácilmente pueden entrar en juego diversas metodologías y marcos de gestión de proyectos, es más, es más que recomendable incorporarlos. Entre las distintas metodologías, obviamente podemos optar por ScrumAdemás, por tratarse de una metodología iterativa, personalmente, la recomiendo con especial profusión. En este punto, Scrum e ITIL tienen una elevada afinidad porque comparten el enfoque PDCA, como ya hemos comentado.

Tomando en cuenta esta perspectiva, parece muy adecuado realizar pruebas piloto (podríamos considerarlas el símil de los prototipos) a usuarios clave durante la fase de transición del servicio y, obviamente, implantar el servicio siguiendo una filosofía incremental; poniendo en vivo primero aquellos aspectos más prioritarios del servicio y desarrollando posteriormente aquellos más accesorios, a medida que se obtiene feedback y fruto de ello se introducen otros cambios. Es más, esta forma de implementar un servicio, que se percibe tan afín a Scrum, sigue al 100% el ciclo de vida de los servicios planteado por ITIL.

Por otra parte, mencionar que dos mecanismos de coordinación de Scrum que son muy valiosos y que pueden incorporarse fácilmente en una organización que ya esté realizando  ITIL son el scrum diario o reunión de seguimiento y las reuniones de retrospectiva.

Nexos de unión (II): Scrum + ITIL

Ahora vamos al caso contrario. Una organización orientada a proyectos, como suele ser la clásica consultora de comunicación online especializada en portales corporativos.

En este entorno, lo que debe predominar es Scrum. No hay dos proyectos iguales y, quienes conozcan bien este ámbito, sabrán que los requerimientos cambian frecuentemente a lo largo del proyecto y que la pericia del equipo de desarrolladores, consultores, etc. juega un papel fundamental en el éxito del proyecto (muy por encima de trazar un buen plan al inicio del proyecto).

Este es un buen ejemplo de cómo podemos enriquecer Scrum con prácticas procedentes de otros enfoques y marcos, ya sean o no ágiles. Por ejemplo: podemos crear un híbrido con Kanban (Scrumban) para gestionar todas esas pequeñas peticiones que nos llegan durante el transcurso de una iteración, podemos incorporar prácticas comoTDD (que viene de XP) para enriquecer nuestro sistema de gestión de la calidad… ytambién podemos incorporar procesos y funciones de ITIL. Por ejemplo:

  • Los procesos de diseño del servicio, aunque sea ejecutándolos a alto nivel, sin entrar en demasiado detalle, pueden ser muy prácticos de cara a valorar aspectos que lamentable y frecuentemente suelen quedar descuidados en equipos excesivamente orientados a desarrollo, como es el dimensionamiento de las infraestructuras, la disponibilidad de personal capaz de resolver incidencias del producto en producción en ciertos periodos estacionales, la formación a usuarios, etc.
  • Que el cambio sea bienvenido en las metodologías ágiles, no significa que puedan llevarse a cabo de forma alegre. Aparte de la consecuente gestión del alcance, si nuestro producto ya está en producción, implantando los procesos y las políticas de transición del servicio de ITIL rellenaremos un vacío de Scrum y nos curaremos en salud de más de un posible susto.
  • No conozco a ninguna compañía orientada a proyectos que no realice operaciones, aunque a veces pasen desapercibidas. En ocasiones, en una empresa como la ejemplificada, los últimos flecos de un proyecto o la resolución de bugs en el periodo de garantía se gestionan mediante un equipo de postventa. Igualmente, tengamos un equipo concreto o no para estos temas, implementar lafunción de service desk e incorporar los procesos de gestión de incidencias y de gestión de problemas puede reportar mejoras de productividad sustanciales, además de mayor visibilidad en este proceso. Obviamente en este punto podemos aplicar también Kanban para beneficiarnos de sus bondades.
  • Otras funciones de ITIL como la gestión técnica o la gestión de aplicacionestambién son fundamentales para el desempeño de un equipo en el largo plazo. Scrum no hace referencia a estos aspectos, sin embargo, en ITIL encontramos un marco de referencia.

Aunque las posibilidades son múltiples y sé que se me quedan muchas en el tintero, por no hablar de profundizar en mayor medida y con mayor detalle en las ya expuestas, espero haber cumplido con mi objetivo y haber resuelto las principales dudas que tenían en mente aquellos que alguna vez me han preguntado por el tema.

Obviamente estoy abierto a responder a todas las dudas que me dejéis en la forma de comentarios, así como a entablar un constructivo debate con aquellos que no compartan mi visión sobre la compatibilidad entre Scrum e ITIL. 😉

Scrum

  • admin 

Scrum es una metodología de gestión de proyectos de software y es por eso que se percibe más cercana al desarrollo de la solución que la metología sugerida en el PMBOK, que es más genérica.

Roles

Roles en Scrum

– Dueño del Producto mantiene la orientación del equipo hacia los requerimientos del cliente. El Product Backlog está a su cargo.
– Scrum Master es quién mantiene la correcta aplicación de las prácticas Scrum al interior del equipo.
– Equipo Scrum, dentro del cual están los desarrolladores.
– Los Usuarios y Clientes también son roles considerados en la metodología Scrum.

Artefactos

Artefactos en Scrum

Los artefactos principales son:
– Product Backlog: Es una lista con las funcionalidades del sistema con sus correspondientes niveles de prioridad. Nuevas funcionalidades pueden ser adicionadas a esta lista.
– Sprint Backlog: Es un documento detallado que indica la forma en la que se van a cubrir los requerimientos. Las tareas no deben ser demasiado extensas por lo que sí se admite que sean numerosas.

http://www.scrumalliance.org/welcome_to_scrum_alliance

http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf

 

PMBOK vs Scrum

  • admin 

Fuente http://blog.pucp.edu.pe/item/42262/pmbok-vs-scrum

Expondré el porqué de Scrum como metodología adecuada para un proyecto de fin de carrera como es una tesis universitaria. Específicamente para uno que incluye un desarrollo en el área de Tecnologías de la Información.

En principio la metodología sugerida por el PMBOK supone:
– Especialización: Miembros de equipo y roles bien delimitados y casi independientes lo que no considera una interacción cercana entre roles.
– Fases: Delimitadas y rígidamente definidas, por lo que las tareas se concluyen en una fase y la acción de los roles se encuentra encasillada en una o más fases.
– Requisitos detallados: Los requerimientos llegan al equipo de desarrollo a través de un artefacto. El cliente no interactúa estrechamente con el producto durante su desarrollo.
– Seguimiento del plan: No se experimenta con opciones atractivas que se puedan presentar durante el transcurso del proyecto sino que se controla rígidamente el plan establecido.

En contraposición Scrum conssidera:

Solapamiento de actividades

Scrum establece ciclos en los que las fases se solapan de forma muy amplia lo que permite actualizar los requerimientos del proyecto, ajustar la planificación e incluso poder reformular el alcance. De esta forma, más que fases que se realizan de forma secuencial, se tienen actividades que se ejecutan en el momento en que se requieren. Educción de requisitos, análisis, codificación, pruebas e integración se
van realizando en cada momento según las necesidades en la evolución del proyecto. Todo esto está guiado por la gestión del alcance que otorga principalmente la exploración medida de actividades. Si se presenta la oportunidad de avanzar algún aspecto del proyecto sin correr riesgos pues este avance se realiza hasta que se vea la dimensión real del aspecto referido y plantear la planificación más adecuada en el contexto correspondiente y tratando de aprovechar los avances completados.

Visión del producto

Queda claro que se busca obtener un producto. La afirmación del concepto del producto tiene mucho más peso que los requisitos específicos del sistema. Se hace necesaria la dirección estratégica ante la ausencia de un plan detallado.

Roles

Para Scrum se considera su compatibilidad con un equipo multidisciplinar. Para el caso de una tesis, el tesista es el único encargado de los roles al interior del proyecto.
Otros roles pertenecen al asesor, asesores que realizarán correcciones al borrador del documento de tesis y el jurado.
– El asesor es cliente del documento de tesis y del producto del proyecto.
– El jurado es cliente del proyecto en su conjunto.
– Los otros asesores que realizarán una corrección al borrador del documento es un cliente no del proyecto sino de su propia apreciación del documento de tesis. Se debe atender sus apreciaciones en la medida que su posición es tan externa como lo es la de los miembros del jurado del proyecto de tesis.
El equipo de desarrollo es auto-organizado y en el caso particular de este proyecto es la unidad auto-organizada representada por el tesista.

Adaptación a los cambios

Pueden ser modificados, dejados de lado o cambiados:
– La elaboración del documento por su correspondencia con el producto a desarrollar.
– La selección de herramientas de desarrollo del producto y de gestión del proyecto.
– El software de terceros.
– El alcance hasta una etapa temprana y fijada del proyecto.

La modificación de un requisito no existe como tal ya que no ha existido la fase de requisitos tradicional sino que se ve enriquecida para concretar la visión del producto.
La incertidumbre es observada constantemente y por eso se permite el descubrimiento paulatino durante el desarrollo y se tiene cuidado con las circunstancias que se van produciendo.
El principal motivo para la elección de Scrum es que el margen de libertad amplio es propicio para que los encargados del proyecto aporten con su ingenio y compromiso.

Por ser un proyecto unipersonal son importantes las disciplinas de
– Autocontrol: Se genera un ambiente de responsabilidad y de gusto por el trabajo que se realiza.
– Autosuperación: Se desarrollan soluciones que son evaluadas, analizadas y mejoradas.

Por ser un proyecto único se considera:
– Muchos proyectos, como una tesis, no son parte de procesos industriales y no es el plan producir muchos sino un único producto, es un proyecto particular.

De acuerdo al Manifiesto Ágil se reconoce valor en los procesos formales que sugiere el PMBOK pero que considera preferibles otros aspectos:

Individuos y su interacción frente a Procesos y herramientas

Software que funciona frente a Documentación exhaustiva

Colaboración con el cliente frente a Negociación contractual

Respuesta al cambio frente a Seguimiento de un plan