martes, 12 de marzo de 2019

metodologías ágiles, algunas conocidas

Varias metodologías ágiles se originaron y ganaron terreno en los años 90 y principios de los 2000. Aquí están los varios métodos populares de Agile que se utilizan.

Lean Kanban: el concepto Lean optimiza el sistema de una organización para producir resultados valiosos en función de sus recursos, necesidades y alternativas, al tiempo que reduce el desperdicio. Kanban significa literalmente un "letrero" o "cartelera" y respalda el uso de ayudas visuales para asistir y rastrear la producción.

Programación extrema (XP): O riginated en Chrysler Corporation, ganó terreno en la década de 1990. XP hace posible evitar que el costo de cambiar el software aumente radicalmente con el tiempo. Los atributos clave de XP incluyen el desarrollo incremental, la programación flexible, los códigos de prueba automatizados, la comunicación verbal, el diseño en constante evolución, la colaboración estrecha y la vinculación de las unidades a largo y corto plazo de todos los involucrados.

Métodos de cristal: Introducidos por Alistair Cockburn a principios de la década de 1990, los métodos de Cristal tienen cuatro roles: patrocinador ejecutivo, diseñador principal, desarrolladores y usuarios experimentados. Métodos de cristal recomiendan varias estrategias y técnicas para lograr la agilidad.

Métodos de desarrollo de sistemas dinámicos (DSMD): este marco se publicó inicialmente en 1995 y lo administra el consorcio DSDM. DSDM establece la calidad y el esfuerzo en términos de costo y tiempo desde el principio y ajusta los entregables del proyecto para cumplir con los criterios establecidos al priorizar los entregables en "Debe tener", "Debería tener", "Podría tener" y "No tendrá" categorías

Feature Driven Development (FDD): Introducido por Jeff De Luca en 1997 y opera según el principio de completar un proyecto dividiéndolo en pequeñas funciones valoradas por el cliente que se pueden entregar en menos de dos semanas. FDD tiene dos principios básicos: el desarrollo de software es una actividad humana y el desarrollo de software es una funcionalidad valorada por el cliente.

Test Driven Development (TDD): también conocido como Test-First Development, y fue presentado por Kent Beck, uno de los creadores de Extreme Programming (XP). Es un método de desarrollo de software que implica escribir primero el código de prueba automatizado y desarrollar la menor cantidad de código necesario para pasar esa prueba más tarde.

Desarrollo de software adaptable (ASD): este método surgió del rápido trabajo de desarrollo de aplicaciones de Jim Highsmith y Sam Bayer. Los aspectos más destacados de ASD son la adaptación constante de los procesos al trabajo en cuestión, la provisión de soluciones a los problemas que surgen en grandes proyectos y el desarrollo iterativo e incremental con prototipos continuos.

Proceso Unificado Agile (AUP): evolucionado del Proceso Unificado Racional de IBM y desarrollado por Scott Ambler, AUP combina técnicas Agile probadas y probadas en la industria, como el Test Driven Development (TDD), el modelado ágil, la gestión ágil de cambios y la refactorización de bases de datos. Para entregar un producto de trabajo de la mejor calidad.

Diseño impulsado por dominio (DDD): este enfoque fue diseñado para manejar diseños complejos con implementación vinculada a un modelo en evolución. Fue conceptualizado por Eric Evans en 2004 y gira en torno al diseño de un dominio central.

Todos estos métodos de Agile difieren entre sí en una variedad de aspectos, pero sus puntos en común se derivan de su adhesión al Manifiesto de Agile.

fuente: http://blog.scrumstudy.com/what-is-agile-methodology/

miércoles, 20 de febrero de 2019

Kanban Limitar el trabajo en proceso (WIP)

Limitar el trabajo en proceso (WIP)
Los límites del WIP (work in progress - trabajo en curso) consisten en acordar
anticipadamente, la cantidad de ítems que pueden abordarse en cada actividad (es
decir, en cada columna del tablero). El principal objetivo de establecer estos límites,
es el de evitar cuellos de botella.

Reunión de retrospectiva cuantas practicas ?


Reunión de retrospectiva del sprint—Esta reunión tiene un time-box de cuatro horas en un sprint de un mes, y se lleva a cabo como parte del proceso Retrospectiva del sprint. Durante esta reunión, el Equipo Scrum se reúne para revisar y reflexionar sobre el sprint anterior en relación a los procesos que se siguieron, las herramientas empleadas, la colaboración y los mecanismos de comunicación, así como otros aspectos de interés para el proyecto. El equipo discute lo que salió bien durante el sprint anterior y lo que no salió bien, con el objetivo de aprender y mejorar sprints futuros. Algunas oportunidades de mejora o las mejores prácticas de esta reunión también podrían actualizarse como parte de los documentos del Scrum Guidance Body.

Retrospectiva del proyecto—En este proceso, mismo que concluye el proyecto, los stakeholders y miembros del equipo principal de Scrum se reúnen para hacer una retrospectiva del proyecto e identificar, documentar e internalizar las lecciones aprendidas. A menudo, estas lecciones llevan a la documentación de Agreed Actionable Improvements, que se implementarán en futuros proyectos.
Retrospectiva de lanzamientos del programa o portafolio—En este proceso, el Program Product Owner o el Portfolio Product Owner y los stakeholders clave se reúnen para hacer una retrospectiva sobre el lanzamiento de un programa o portafolio e internalizar las lecciones aprendidas. Por lo general dichas lecciones aprendidas llevan a mejoras aceptadas (Agreed Actionable Improvements) para ser implementadas a futuro.
11.2.2.1 Reunión de retrospectiva del sprint*
La reunión de retrospectiva del sprint es un elemento importante del framework de “inspección-adaptación” de Scrum y es el último paso en un sprint. Todos los miembros del Equipo Scrum asisten a la reunión, misma que organiza y modera el Scrum Master. Se recomienda que asista el Product Owner, aunque no es obligatorio. Un integrante del equipo se desempeña como secretario y documenta las discusiones y los elementos para acciones a futuro. Es esencial celebrar esta reunión es un entorno abierto y relajado a fin de fomentar la completa participación de todos los miembros del equipo. Las discusiones en la reunión de retrospectiva del sprint abarcan tanto lo que salió mal como lo que salió bien. Los objetivos primordiales de la reunión son identificar tres elementos específicos:
1) Las cosas que el equipo necesita seguir haciendo: mejores prácticas
2) Las cosas que el equipo necesita empezar a hacer: mejoras en el proceso
3) Las cosas que el equipo necesita dejar de hacer: problemas de proceso y embotellamiento 
Estas áreas se analizan y se crea una lista de mejoras accionables aceptadas (Agreed Actionable Improvements).
11.2.2.2 Explorador—Comprador—Vacacionista—Prisionero (ECVP)
Es un ejercicio que se puede llevar a cabo al inicio de la reunión de retrospectiva del sprint para entender la mentalidad de los participantes y establecer el tono de la reunión. Se les pide a los asistentes que indiquen de forma anónima lo que mejor representa su punto de vista en la reunión.
• Explorador (Explorer)—Quiere participar y aprender todo lo que se discutió en la retrospectiva
• Comprador (Shopper)—Quiere escuchar todo y elegir lo que entiende de la retrospectiva
• Vacacionista (Vacationer)—Quiere relajarse y ser turista en la retrospectiva
• Prisionero (Prisoner)—Quiere estar en otro lugar y asiste a la retrospectiva por ser obligatorio
El Scrum Master reúne las respuestas; prepara y comparte la información con el grupo.
11.2.2.3 Speed Boat
El Speed Boat es una técnica que se puede utilizar para llevar a cabo la reunión de retrospectiva del sprint. Los miembros juegan el rol de la tripulación en una lancha. La lancha debe llegar a una isla: simbólicamente la visión del proyecto. Los asistentes utilizan notas adhesivas para llevar un registro de motores y anclas. 
Los “motores” ayudan a llegar a la isla, mientras que las “anclas” son cosas que están obstaculizando la llegada. Este ejercicio tiene un time-box de unos cuantos minutos. Una vez que se documentan todos los elementos, se reúne la información, se discute y se prioriza por medio de un proceso de votación. Se reconocen los motores y se planifican las acciones de mitigación para las anclas dependiendo de la prioridad
11.2.3.5 Lecciones aprendidas del Equipo Scrum
Se espera que el Equipo Scrum (equipo auto organizado y empoderado) aprenda de los errores cometidos durante el sprint y que estas lecciones aprendidas ayuden a mejorar su desempeño en futuros sprints.
Estas lecciones aprendidas también pueden documentarse en las recomendaciones del Scrum Guidance Body para compartirse con otros equipos de Scrum.
Puede haber varias lecciones positivas aprendidas como parte de un sprint. Estas lecciones positivas aprendidas son parte clave de la retrospectiva y deben compartirse adecuadamente dentro del equipo y con el Scrum Guidance Body conforme el equipo avanza hacia una auto-mejora continua.
12.2.2.1 Reunión de retrospectiva del proyecto*
La reunión de retrospectiva del proyecto es una reunión para determinar las formas en las que la colaboración y eficacia del equipo puede mejorarse en futuros proyectos. También se analizan las oportunidades positivas, negativas y potenciales para mejorar. Esta reunión no tiene un time-box asignado y se puede llevar a cabo en forma presencial o en formato virtual. Entre los asistentes se encuentran: el equipo del proyecto, el Chief Scrum Master, el Chief Product Owner y el (los) stakeholder(s). Durante la reunión, se documentan las lecciones aprendidas y los participantes buscan oportunidades para mejorar los procesos y atender las ineficiencias.
Retrospect Sprint Log(s)
Los registros de la retrospectiva del sprint, o Retrospect Sprint Log(s), son registros de las opiniones, debates y elementos accionables planteados en la reunión de retrospectiva del sprint. El Scrum Master puede facilitar la creación de dicho registro con la aportación de los miembros del equipo principal de Scrum.
Fuente SBOK

lunes, 18 de febrero de 2019

La autoorganización principio esencial en Scrum

La autoorganización como principio esencial en Scrum conduce a lo siguiente:
  • La participación del equipo y la propiedad compartida.
  • Motivación, que conduce a un mejor nivel de rendimiento del equipo.
  • Entorno innovador y creativo propicio para el crecimiento.
Aunque la priorización la realiza principalmente el propietario del producto, que representa la voz del cliente, el equipo Scrum autoorganizado está involucrado en el desglose y estimación de tareas. Durante estos procesos, cada miembro del equipo es responsable de determinar qué trabajo realizará. Durante la ejecución de un Sprint, si los miembros del equipo necesitan ayuda para completar sus tareas, Scrum lo soluciona a través de la interacción regular obligatoria con las reuniones diarias de soporte. El Equipo Scrum en sí mismo interactúa con otros equipos a través de las Reuniones de Scrum of Scrums (SoS) y puede buscar orientación adicional según lo requiera el Cuerpo de Orientación de Scrum.

Finalmente, Scrum Team y Scrum Master trabajan estrechamente para demostrar el incremento del producto creado durante el Sprint donde se aceptan los entregables debidamente completados. Dado que los entregables son potencialmente enviables, (y las historias de usuarios priorizan la acumulación de productos priorizados en el orden de valor creado por ellos), el propietario del producto y el cliente pueden visualizar y articular claramente el valor que se crea después de cada Sprint. y los Equipos Scrum, a su vez, tienen la satisfacción de ver que el cliente y otras partes interesadas aceptan su arduo trabajo.
Scrum cree que los empleados se motivan a sí mismos y buscan aceptar una mayor responsabilidad. Por lo tanto, ofrecen un valor mucho mayor cuando se autoorganizan. El estilo de liderazgo preferido en Scrum es el "liderazgo de servicio", que enfatiza el logro de resultados al enfocarse en las necesidades del Equipo Scrum. La autoorganización no significa que a los miembros del equipo se les permita actuar de la manera que ellos quieran. Solo significa que una vez que se define la Visión del producto, se identifican el Propietario del producto, Scrum Master y el Equipo Scrum. Además, el propio Scrum Core Team trabaja muy de cerca con los interesados ​​relevantes para mejorar los requisitos de refinación. La experiencia del equipo se utiliza para evaluar los insumos necesarios para ejecutar el trabajo planificado del proyecto. Este juicio y experiencia se aplican a todos los aspectos técnicos y de gestión del proyecto.
fuentes: http://blog.scrumstudy.com/what-is-self-organizing/ 

miércoles, 13 de febrero de 2019

Priorizacion de historias de usuario, tecnicas

A continuación se presentan 4 de las técnicas mas utilizadas para priorizar las Historias de usuario o los requisitos en el Registro de productos priorizados, en función del valor comercial:

1. Esquema de priorización de MoSCoW: el  esquema de  priorización de MoSCoW deriva su nombre de las primeras letras de las frases "Debe tener", "Debería tener", "Podría haber" y "No tendrá". Este método de priorización es generalmente más efectivo que los esquemas simples. Las etiquetas están en orden de prioridad decreciente, con "Debe tener" Historias de usuario sin las cuales el producto no tendrá ningún valor y "No tendrá" Las Historias de usuario serán aquellas que, aunque sería bueno tener, no son necesarias ser incluido
2. Comparación por pares:  en esta técnica, se prepara una lista de todas las Historias de usuarios en el Registro de productos priorizados. A continuación, cada historia de usuario se toma individualmente y se compara con las otras historias de usuario de la lista, una a la vez. Cada vez que se comparan dos Historias de usuarios, se toma una decisión sobre cuál de las dos es más importante. A través de este proceso, se puede generar una lista priorizada de Historias de usuarios. 
3. Método de 100 puntos: el método de  100 puntos fue desarrollado por Dean Leffingwell y Don Widrig (2003). Implica dar al cliente 100 puntos que puede usar para votar por las Historias de usuario que son más importantes. El objetivo es dar más peso a las Historias de usuario que son de mayor prioridad en comparación con las otras Historias de usuario disponibles. Cada miembro del grupo asigna puntos a las diversas Historias de usuarios, lo que da más puntos a aquellos que consideran más importantes. Al finalizar el proceso de votación, la priorización se determina calculando los puntos totales asignados a cada historia de usuario.
 4. Análisis de  Kano: el análisis de Kano fue desarrollado por Noriaki Kano (1984) e incluye la clasificación de características o requisitos en cuatro categorías según las preferencias del cliente:
Exciters / Delighters: características nuevas o de alto valor para el cliente
Satisfechos: características que ofrecen valor al cliente.
Insatisfechos: características que, si no están presentes, pueden hacer que al cliente no le guste el producto, pero no afectan el nivel de satisfacción si están presentes
Indiferente: características que no afectarán al cliente de ninguna manera y deben eliminarse.

Curiosamente, las características generalmente bajan la lista de clasificación a lo largo del tiempo; los clientes llegarán a esperar características (por ejemplo, cámaras en los teléfonos) y estas características pasarán de ser excitantes / encantadoras a satisfechas y eventualmente a insatisfechas

A nivel de programa o cartera, normalmente hay una cantidad menor de requisitos / historias de usuario que a nivel de proyecto. El porcentaje de historias de usuarios con un valor muy tangible / necesidad empresarial / impacto en el usuario suele ser mucho menor que en el nivel de proyecto. Eso significa que la selección de técnicas que son útiles a nivel de programa o cartera será menor. Por ejemplo, el análisis de Kano tiene limitaciones porque no habrá desilusionadores ni excitantes. Sin un número significativo de partes interesadas, especialmente los usuarios, el método de 100 puntos tiene un valor limitado. La técnica MoSCoW también tiene limitaciones porque no habrá ninguna característica "agradable de tener" o "No tendrá" a nivel de programa y cartera.
Fuente : http://blog.scrumstudy.com/user-story-prioritization-techniques/