Algunas de las diferencias entre Agile, Business Agility y Enterprise Agility

Esta es la opinión de Enterprise Agility University y puede diferir de la de otros.       

  Fuente :  https://enterpriseagility.university/cc-confirmation-03b/   

Scrum Master mas que un lider servicial y facilitador

Un Scrum Master ayuda al equipo a comprender y optimizar las dependencias técnicas y organizativas, al tiempo que protege al equipo de influencias externas. Alinea los recursos requeridos con transparencia. Esto ayuda a los equipos a comprometerse con los plazos al tiempo que crea una cultura de responsabilidad.

Además: 

:

• es el 'líder servidor' del equipo Scrum que modera y facilita las interacciones del equipo como entrenador y motivador del equipo.
• es responsable de asegurar que el equipo tenga un ambiente de trabajo productivo eliminando cualquier impedimento.
• es responsable de hacer cumplir los principios, aspectos y procesos de Scrum.
• está en el mismo nivel jerárquico que cualquier otra persona en el Scrum Team; cualquier persona del Scrum Team que aprenda a facilitar proyectos Scrum puede convertirse en Scrum Master para un proyecto o para un Sprint.
• facilita la selección del Scrum Team y la creación del Collaboration Plan y el Team Building Plan.
• determina la duración del Sprint con el equipo Scrum e implementa pasos esenciales para maximizar la productividad del equipo.
• Facilita al Equipo Scrum la creación de la Lista de tareas para el próximo Sprint.
• ayuda al Equipo Scrum a estimar el esfuerzo requerido para completar las tareas acordadas para el Sprint.
• apoya al Equipo Scrum en la creación de los Entregables acordados para el Sprint.
• facilita la presentación de los entregables completados por el equipo Scrum para la aprobación del propietario del producto.
• representa al Scrum Core Team para proporcionar lecciones del proyecto actual, si es necesario.

fuente: 

Desperdicio en Lean manufacturing se dice Muda

Muda es la palabra con la que se designa desperdicio en el Lean Manufacturing. Buscando una definición más precisa de lo que se entiende por desperdicio sería: Muda es cualquier actividad en un proceso que consume recursos (esfuerzo) y que no añade valor al producto o servicio desde el punto de vista del cliente.

Si tus proyectos tienen de fondo el mundo de la manufactura no habrás tenido ningún problema en comprender los desperdicios, es más, seguramente ya los conocieras. Si perteneces a otro mundo, como por ejemplo del software, lo mismo piensas que algunos de ellos no aplican a tu caso y nada más lejos de la realidad.

Es su magnífico libro “ Lean Software Development: An Agile Toolkit “ el matrimonio formado por Mary y Tom Poppendieck hacía la correlación perfecta de los 7 Mudas al mundo del software. Si no has leído el libro ya, te lo recomiendo.

La asociación de los muda al software la vamos a ver a continuación:

1. Características extra. Dentro del software existe un nombre para esto y se llama Gold Plating. Aunque puede parecer un servicio al cliente, incluir algo que no te han pedido es un desperdicio.

2. Trabajo hecho parcialmente. Todo trabajo que no se haya completado y esté esperando para serlo es un desperdicio. Si finalmente no lo llevamos a cabo el esfuerzo y recursos que hayamos empleado se habrá tirado a la basura.

3. Sobreproceso. Es uno de los desperdicios que mejor casa. No necesita explicación.

4. Esperas. Pasa igual que en el caso del lean manufacturing. Tenemos que esperar por cosas o a que haya disponibilidad de algo. Sigue siendo un desperdicio en el software como lo era antes para Toyota.

5. Defectos. Otro que casa perfectamente con el software. Un defecto en producción es un desperdicio claro.

6. Cambio de tareas. Asignar a las personas a múltiples proyectos donde deban realizar múltiples tareas de las que tendrán que ir cambiando de unas a otras implica un desperdicio. Sobre el papel parece muy rápido el poder cambiar de una tarea a otra, pero la realidad es que necesitamos tiempo para poder volver a continuar con una tarea anterior.

7. Movimientos. Aquí se orienta por ejemplo a cómo de sencillo es para un desarrollador encontrar la respuesta a una pregunta. Si tiene que preguntar a negocio ¿puede preguntar directamente? ¿necesita seguir un protocolo? Todo ese tiempo es un desperdicio.

El artífice del Lean, quien introdujo esta nueva manera de fabricar en Toyota, fue Taiichi Ohno (1912 – 1990), cuya estrategia se fundamentó en tres bases:

–  Construir sólo lo necesario.

–  Eliminar todo aquello que no añade valor.

–  Parar si algo no va bien (lo que está relacionado con el principio de cero defectos).

Además, conviene destacar que el Lean incluye siete importantes principios, los siguientes:

Eliminar desperdicios (Eliminating Waste)

Amplificar el aprendizaje (Amplifying Learning)

Decidir lo más tarde posible (Deciding as Late as Possible)

Entrega lo más rápido posible (Delivering as Fast as Possible)

Capacitar, potenciar, al equipo (Empowering the Team)

Construir con integridad (Building Integrity In)

Ver el todo (Seeing the Whole)

fuentes: https://www.laboratorioti.com/2020/11/09/los-7-desperdicios-lean-de-tu-proyecto/

https://www.javiergarzas.com/2012/01/lean-software-development.html

Scrum puede aportar a nivel de portafolio, programa y proyecto.

Entendamos ahora cómo se definen el programa y la portafolio  :

Programa : Un programa es un grupo de proyectos relacionados, con el objetivo de generar resultados comerciales como se define en la Declaración de la visión del programa. El Backlog del programa priorizado incorpora los Backlogs del producto priorizados para todos los proyectos del programa.

portafolio  : un portafolio  es un grupo de programas relacionados, con el objetivo de ofrecer resultados comerciales según se define en la Declaración de la visión del portafolio . El Backlog del portafolio  priorizado incorpora los Backlogs de programas priorizados para todos los programas del portafolio .

A continuación, se muestran algunos de los ejemplos de programas y portafolio  de diferentes industrias y sectores:

Ejemplo 1: Empresa de tecnología de la información (TI) 

Programa: desarrollo de un sitio web de comercio electrónico completamente funcional

Portafolio: todos los sitios web desarrollados por la empresa hasta ahora

Ejemplo 2: Empresa constructora

Programa: construcción de un complejo de viviendas

Portafolio: todos los proyectos de vivienda de la empresa

Ejemplo 3: Organización aeroespacial

Programa: lanzamiento exitoso de un satélite

Portafolio: todos los programas satelitales activos

El como dice la guia SBOK Scrum puede aportar a nivel de portafolio, programa y proyecto y se puede aplicar a cualquier entregable que tenga valor para el negocio o algun grupo de interesados :-)

Si aun no tiene la guia SBOK (440 paginas) en español, contactame y te la envio. Happy day.

FUENTES:

SBOK, guia de conocimiento de Scrum de Scrumstudy

http://blog.scrumstudy.com/scrum-in-programs-and-portfolios/

GLPI Gestion de TI open source

Gestión de TI:con el poder de la libertad

GLPI es una increíble herramienta de software ITSM que lo ayuda a planificar y administrar los cambios de TI de una manera fácil, resolver problemas de manera eficiente cuando surgen y le permite obtener un control legítimo sobre el presupuesto y los gastos de TI de su empresa.

Explore las características del  increíble  software ITSM, GLPI ,  que lo ayuda a planificar y administrar los cambios de TI de una manera fácil, resolver problemas de manera eficiente cuando surjan y le permite  tomar el control de  la infraestructura de TI de su empresa.

GLPI ofrece  numerosas funciones avanzadas para la gestión de inventario, activos y dispositivos móviles . Obtenga la información completa sobre el estado de: PC y servidores, impresoras, monitores, consumibles y cartuchos, teléfonos IP, software, ubicaciones, conmutadores, enrutadores, etc.

https://glpi-project.org/community/

El poder del software de código abierto, lecciones de YouTube

Una historia conocida :-)
Se compara la transmisión de televisión con el poder de YouTube y cómo un impacto similar ha sido positivo para la industria del software.
¿Recuerdas un momento en que YouTube no existía? Si no, déjame pintarte un cuadro.

Antes de YouTube
Antes de YouTube, la televisión abierta era el rey reinante.

Algunos programas se transmitieron por radio o por algún servicio de televisión que las personas sintonizarían para mirar.

Esos programas fueron administrados por la red que los transmitía. En los primeros días, los televidentes usaban el periódico para acceder a la guía de transmisión. Más tarde, un periódico semanal llamado TV Guide ayudó a localizar algo para ver. En aquel entonces, no era tan fácil encontrar algo que quisieras ver.

También te puede interesar: Las 8 principales tendencias tecnológicas para 2020 y más allá

Luego estaban los comerciales. Esas mismas redes decidieron qué comerciales serían transmitidos, el tiempo en que serían transmitidos y la frecuencia también. Antes de los días de transmisión de dispositivos de grabación, nos vimos obligados a sentarnos y ver estos comerciales, para no perder un momento del programa que sintonizamos para ver. La mayoría se volvió buena para cuidar las cosas durante los comerciales. Escuchando atentamente para regresar antes de que se reanude el programa.

Entra en YouTube
YouTube se convirtió en un jugador importante en la vida cotidiana de las almas conectadas. El queso se movió por todo lo relacionado con la programación de transmisión, muy probablemente para consternación de las redes que tuvieron un fuerte control sobre las opciones de control para los espectadores durante décadas.

Con YouTube, todo el panorama cambió:

Los usuarios pueden buscar lo que quieren.
Cualquiera tenía el poder de cargar / transmitir cualquier contenido que quisiera compartir.
Los anunciantes lo siguieron rápidamente, permitiendo que los editores exitosos se beneficien económicamente.
Comencé a preguntarme cómo este mismo ciclo ha beneficiado a los profesionales de TI a lo largo de los años.

El poder del software de código abierto
Un ejemplo común donde veo un enfoque similar es con el software de código abierto (OSS).

Al comparar el desarrollo de software de mis primeros días posteriores a la universidad con mi proyecto más reciente, los conceptos subyacentes de programación permanecen en su lugar. Sin embargo, no existe ninguna de las mismas herramientas que en 1992.

Al comenzar el desarrollo, lanzaría un entorno de programación de una empresa como Borland. En ese momento, su conjunto de herramientas C / C ++ era popular y efectivo. También existían herramientas similares para Turbo Pascal. Conectarse a otros electrónicamente a menudo significaba usar un módem para conectarse a un Usenet o un sistema de tablón de anuncios (BBS) donde los hilos podrían ser revisados ​​y discutidos. A menos que desee pagar por una biblioteca de terceros (si pudiera encontrarla), escribiría el código usted mismo.

Cuando OSS se convirtió en un punto de discusión, hubo dudas. La opinión común era que el código resultante solo sería tan bueno como el peor trabajo del desarrollador en el proyecto. (No es mi percepción, pero lo que era común escuchar en ese entonces.) La mayoría no estaba ansiosa por permitir que el código extranjero ingresara a la base de código de una corporación sin ninguna garantía o consecuencia. También existía el temor de que una biblioteca OSS dada exponga a una corporación o allane el camino para que los piratas informáticos ingresen a sus sistemas, inesperadamente.

Con lenguajes de programación como Java, las opciones de OSS comenzaron a surgir y el poder de Internet ayudó a promover opciones exitosas. Luego, cuando los equipos comenzaron a trabajar en su próxima función, se dieron cuenta de que el uso de un marco, como Hibernate , proporcionaba todo el código repetitivo necesario para que el proyecto se conectara a bases de datos, recuperara datos e incluso persistiera.

Como resultado, las opciones de OSS se volvieron comunes para los desarrolladores de características. Avancemos rápidamente a mi proyecto actual (28 años después) y la cantidad de opciones de OSS implementadas tanto en el lado del cliente como del servidor del desarrollo es una "lista de quién es quién" de actores clave en la industria de OSS.

Al adoptar este enfoque, los desarrolladores del equipo de características han podido centrarse en escribir código de programa que imponga y controle la lógica empresarial para las necesidades que se satisfacen. Este enfoque también ha llevado a un cambio más rápido para las características y la funcionalidad, eliminando el código repetitivo en el camino.
Fuente : https://dzone.com/articles/youtube-and-the-effect-on-software?edition=570297&utm_source=Zone%20Newsletter&utm_medium=email&utm_campaign=agile%202020-02-03

¿Qué es la metodología ágil?

El término "ágil" generalmente se refiere a ser capaz de moverse o responder rápida y fácilmente; siendo ágil Por lo tanto, en cualquier tipo de disciplina de gestión, ser ágil como cualidad debería ser un buen objetivo. La gestión ágil de proyectos específicamente, implica ser adaptativo durante la creación de un producto, servicio u otro resultado.
Una serie de metodologías ágiles se originaron y ganaron fuerza en la década de 1990 y principios de 2000. Aquí están los diversos métodos ágiles populares que se utilizan.

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

Programación extrema (XP): Originado en Chrysler Corporation, ganó tracción en la década de 1990. XP permite 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 estrecha colaboración y la vinculación de los impulsos a largo y corto plazo de todos los involucrados.

Métodos Crystal: introducidos por Alistair Cockburn a principios de la década de 1990, los métodos Crystal tienen cuatro roles: patrocinador ejecutivo, diseñador principal, desarrolladores y usuarios experimentados. Los métodos Crystal 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 es administrado por 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 haber", "Podría haber" y "No tendrá" categorías

Desarrollo dirigido por funciones (FDD): presentado 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 fundamentales: 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 adaptativo (ASD): este método surgió del rápido trabajo de desarrollo de aplicaciones realizado por 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 ágil (AUP): Evolucionado del proceso unificado racional de IBM y desarrollado por Scott Ambler, AUP combina técnicas ágiles probadas y probadas en la industria, como Test Driven Development (TDD), Agile Modeling, gestión ágil de cambios y refactorización de bases de datos, para entregar un producto funcional 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 su comunidad se deriva de su adhesión al Manifiesto Agile.