CentOS 8 Cómo configurar y administrar el firewall

Un firewall es un método para monitorear y filtrar el tráfico de red entrante y saliente. Funciona definiendo un conjunto de reglas de seguridad que determinan si se permite o bloquea el tráfico específico. Un firewall configurado correctamente es uno de los aspectos más importantes de la seguridad general del sistema.

CentOS 8 se envía con un demonio de firewall llamado firewalld . Es una solución completa con una interfaz D-Bus que le permite administrar el firewall del sistema de forma dinámica.

Conceptos básicos de Firewalld
firewalld utiliza los conceptos de zonas y servicios. Según las zonas y los servicios que configurará, puede controlar qué tráfico está permitido o bloqueado hacia y desde el sistema.
Firewalld se puede configurar y administrar mediante la firewall-cmdutilidad de línea de comandos.

En CentOS 8, iptables se reemplaza por nftables como el servidor de seguridad predeterminado para el demonio firewalld.

Zonas Firewalld
Las zonas son conjuntos predefinidos de reglas que especifican el nivel de confianza de las redes a las que está conectada su computadora. Puede asignar interfaces y fuentes de red a una zona.
A continuación se muestran las zonas proporcionadas por FirewallD ordenadas según el nivel de confianza de la zona de no confiable a confiable:

drop : todas las conexiones entrantes se eliminan sin ninguna notificación. Solo se permiten conexiones salientes.
block : todas las conexiones entrantes se rechazan con un mensaje icmp-host-prohibited para IPv4 y icmp6-adm-prohibited para IPv6n. Solo se permiten conexiones salientes.
public : para uso en áreas públicas no confiables. No confía en otras computadoras en la red, pero puede permitir conexiones entrantes seleccionadas.
external : para usar en redes externas con enmascaramiento NAT habilitado cuando su sistema actúa como puerta de enlace o enrutador. Solo se permiten conexiones entrantes seleccionadas.
internal : para usar en redes internas cuando su sistema actúa como puerta de enlace o enrutador. Otros sistemas en la red son generalmente confiables. Solo se permiten conexiones entrantes seleccionadas.
dmz : Usado para computadoras ubicadas en su zona desmilitarizada que tienen acceso limitado al resto de su red. Solo se permiten conexiones entrantes seleccionadas.
work : Utilizado para máquinas de trabajo. Otras computadoras en la red son generalmente confiables. Solo se permiten conexiones entrantes seleccionadas.
home : utilizado para máquinas domésticas. Otras computadoras en la red son generalmente confiables. Solo se permiten conexiones entrantes seleccionadas.
trusted : se aceptan todas las conexiones de red. Confíe en todas las computadoras en la red.

Servicios de firewall
Los servicios Firewalld son reglas predefinidas que se aplican dentro de una zona y definen la configuración necesaria para permitir el tráfico entrante para un servicio específico. Los servicios le permiten realizar fácilmente varias tareas en un solo paso.

Por ejemplo, el servicio puede contener definiciones sobre cómo abrir puertos, reenviar tráfico y más.

Firewalld Runtime y configuraciones permanentes
Firewalld usa dos conjuntos de configuración separados, tiempo de ejecución y configuración permanente.
La configuración de tiempo de ejecución es la configuración real en ejecución y no persiste en el reinicio. Cuando se inicia el demonio firewalld, carga la configuración permanente, que se convierte en la configuración de tiempo de ejecución.

De manera predeterminada, al realizar cambios en la configuración de Firewalld utilizando la firewall-cmdutilidad, los cambios se aplican a la configuración de tiempo de ejecución. Para que los cambios sean permanentes, agregue la --permanentopción al comando.

Para aplicar los cambios en ambos conjuntos de configuración, puede usar uno de los dos métodos siguientes:

Cambie la configuración del tiempo de ejecución y hágalo permanente:

sudo firewall-cmd <options>
sudo firewall-cmd --runtime-to-permanent
Cambia la configuración permanente y recarga el demonio firewalld:

sudo firewall-cmd --permanent <options>
sudo firewall-cmd --reload
Habilitar FirewallD
En CentOS 8, firewalld está instalado y habilitado de manera predeterminada. Si por alguna razón no está instalado en su sistema, puede instalar e iniciar el demonio escribiendo:
sudo dnf install firewalld
sudo systemctl enable firewalld --now
Puede verificar el estado del servicio de firewall con:

sudo firewall-cmd --state
Si el firewall está habilitado, el comando debería imprimir running. De lo contrario, lo verás not running.

Zonas Firewalld
Si no lo ha cambiado, la zona predeterminada se establece en publicy todas las interfaces de red se asignan a esta zona.
La zona predeterminada es la que se usa para todo lo que no está asignado explícitamente a otra zona.

Puede ver la zona predeterminada escribiendo:
sudo firewall-cmd --get-default-zone


Fuente: https://linuxize.com/post/how-to-configure-and-manage-firewall-on-centos-8/

Por que no funciona Scrum o Agile en Colombia

Tenermos estudios mundiales que dan algunas luces sobre las barreas en la adopcion de los modelos  nuevos de gestion de proyectos como agiles y scrum.
Algunas de mas mencionadas x versionone en el 2019:

Cultura organizacional en desacuerdo con valores ágiles, Organización general resistencia al cambio
Inadecuada gestión de apoyo y patrocinio, Falta de habilidades / experiencia con métodos ágiles
Insuficiente capacitación y educación., Procesos y prácticas inconsistentes entre los equipos.
Falta de disponibilidad de negocios / clientes / propietarios de productos, Generalidad de los métodos de desarrollo tradicionales.Herramientas fragmentadas y datos / mediciones relacionadas con el proyecto. Colaboración mínima e intercambio de conocimientos. Cumplimiento normativo o problema gubernamental
Pero en Colombia por que seria ?? Yo propuse esta encuesta online x 1 semana a ver que dice

¿Por qué es importante desarrollar épicas en Scrum?

En términos simples, las epicas son requisitos del usuario que el equipo de Scrum debe cumplir

¿Qué son las Epicas? Es posible que las historias de usuario tengan que escribirse constantemente a lo largo de la duración del proyecto. En las etapas iniciales de la escritura, la mayoría de las Historias de usuarios son funcionalidades de alto nivel. Estas historias de usuario se conocen como Epic (s). Las épicas generalmente son demasiado grandes para que los equipos las completen en un solo Sprint. Por lo tanto, se dividen en historias de usuario más pequeñas.

Reuniones de grupos de usuarios

En la Metodología Scrum, las reuniones de grupos de usuarios involucran a las partes interesadas relevantes (principalmente usuarios o clientes del producto) y proporcionan al equipo central de Scrum información de primera mano sobre las expectativas de los usuarios. Esto ayuda a formular los Criterios de aceptación del producto y proporciona información valiosa para el desarrollo de Epics. Las reuniones de grupos de usuarios son vitales en la prevención de costosas modificaciones, que pueden resultar de la falta de claridad con respecto a las expectativas y requisitos. Estas reuniones también promueven la aceptación del proyecto y crean un entendimiento común entre el equipo central de Scrum y las partes interesadas relevantes.

Las epicas se escriben en las etapas iniciales del proyecto, cuando la mayoría de las Historias de usuarios son funcionalidades de alto nivel o descripciones de productos, y los requisitos están ampliamente definidos. Son grandes historias de usuarios sin refinar en la cartera de productos priorizada. Una vez que estas epicas aparecen en el Backlog priorizado de productos para completar en un próximo Sprint, se dividen en Historias de usuarios más pequeñas y detalladas. Estas historias de usuario más pequeñas son generalmente funcionalidades simples, cortas y fáciles de implementar o bloques de tareas que se completarán en un Sprint.

Riesgos identificados

Al crear Epics, se pueden identificar nuevos riesgos y dichos riesgos identificados forman una salida importante de esta etapa. Estos riesgos contribuyen al desarrollo de la cartera de productos priorizada (que también podría denominarse cartera de productos ajustada por riesgo). Los miembros del Equipo Scrum deberían intentar identificar todos los riesgos que podrían afectar el proyecto. Solo mirando el proyecto desde diferentes perspectivas, utilizando una variedad de técnicas, pueden hacer este trabajo a fondo. La identificación de riesgos se realiza a lo largo del proyecto y los riesgos identificados se convierten en insumos para varios procesos de Scrum, incluyendo la creación de una reserva de productos priorizada, la reserva de productos priorizados del novio y la demostración y validación de Sprint.

fuente: http://blog.scrumstudy.com/why-is-it-important-to-develop-epics-in-scrum/

Qué tan bien funciona ágil para grandes organizaciones

El éxito de las organizaciones de hoy depende de qué tan bien puedan adaptarse al huracán de los cambios que se extienden por su industria. ¿Cómo pueden hacer esto? Muchas organizaciones están buscando a Agile como la respuesta.

A pesar de su popularidad, Agile no ha sido acogido calurosamente por las grandes organizaciones. Una de las razones obvias para esto es que las grandes organizaciones no realizan cambios importantes a menos que sea absolutamente necesario. Otra razón está relacionada con el hecho de que Agile es diferente de las filosofías tradicionales de gestión de proyectos desde las raíces hasta las hojas. Las grandes organizaciones son bastante ortodoxas cuando se trata de sus estructuras organizativas y gestión.

La implementación exitosa de Agile en un entorno burocrático es extremadamente difícil, porque uno de los fundamentos centrales de Agile es la mejora continua del proceso, mientras que la burocracia moribunda apuesta por la ilusión de la estabilidad del proceso. Sin embargo, las grandes organizaciones están comenzando a sentirse atraídas por la importancia y la tasa de éxito de Agile. Los conglomerados de software como Microsoft, IBM y SAP están implementando con éxito Agile para proyectos de desarrollo de productos seleccionados.

Para que Agile tenga éxito, una organización debe decidir que está lista para implementar los principios básicos de Agile. Tiene que liberarse de sus formas rígidas de abrazar la cultura ágil. Es esencial que una empresa comprenda las condiciones en que la implementación de Agile conducirá al éxito:

Condición 1: un equipo pequeño que trabaja en una ubicación, en lugar de un equipo grande que opera desde diferentes ubicaciones

Condición 2: iteraciones cortas y frecuentes durante las cuales los problemas se pueden identificar más rápido que en ciclos extensos del proyecto que tienden a ocultar problemas hasta el final del proyecto

Condición 3: El proyecto incluye la participación del cliente durante el desarrollo del proyecto. Si la compañía es estricta acerca de una ruta burocrática y basada en formas para llegar al cliente, Agile se verá obstaculizado por la misma burocracia.

Condición 4: Empoderar al equipo para tomar decisiones sobre el desarrollo es un componente necesario para lograr el éxito en la metodología Agile. Agile fracasará si la empresa cree en una jerarquía rígida de toma de decisiones.

Condición 5: Agile hace hincapié en trabajar el software en lugar de documentar los códigos, lo que se puede hacer más adelante. Si la empresa tiene que confiar en una extensa documentación para las auditorías, Agile puede proporcionar mejoras de proceso inferiores a las deseadas.

No se establece que estas condiciones adviertan o asusten a las grandes empresas de adoptar Agile. Se afirma que evitan que las empresas adopten Agile de manera ciega y parcial y luego se quejen de que Agile no funciona. Cualquier organización grande debe tener en cuenta sus necesidades comerciales inmediatas y los recursos disponibles, y comprender claramente qué es exactamente lo que desea lograr. Luego, los ejecutivos de la organización deberían decidir si adoptar la metodología Agile totalmente o adoptar un enfoque pragmático. Cualquiera sea la decisión que tomen, el apoyo ejecutivo inquebrantable y holístico es uno de los requisitos principales para que Agile trabaje en una organización grande.
fuente: http://blog.scrumstudy.com/how-well-does-agile-function-for-large-organizations/

Qué NO es un equipo autoorganizado

Comiencemos por reconocer los errores y mirar oportunidades de mejorar los equipos.

La autoorganización es un proceso y una característica, no algo que se hace de una vez por todas .

La autoorganización, desde la perspectiva de los sistemas sociales, solo significa que el equipo puede crear nuevos enfoques y adaptarse para enfrentar los nuevos desafíos en su entorno.

conceptos erróneos

1. Los equipos autoorganizados son completamente autónomos, autogestionados y no necesitan gerentes.
2. Todo lo que necesita hacer para formar un equipo autoorganizado es proporcionar un objetivo y aplicar presión.
3. Dado que el equipo se autoorganiza, pueden acomodar a las personas que se mueven dentro y fuera del equipo fácilmente.

Los equipos ágiles autoorganizados tienen autoridad limitada para hacer sus propios compromisos, organizar y asignar su propio trabajo. Diseñan estrategias apropiadas para lograr sus objetivos y toman decisiones con un impacto económico y organizacional (nuevamente limitado).

Los gerentes deben crear las condiciones que permitan a los equipos prosperar y continuar autoorganizándose . Los gerentes deben trabajar en toda la organización para crear un sistema de trabajo que permita a los equipos entregar valor a los clientes y a la organización.

“No se puede soltar a la gente y dejar que un equipo tome todas las decisiones. Arruinarán las cosas. Y con todos estos Scrum Masters, entrenadores y equipos autoorganizados, parece que no tengo trabajo ”

Concepto erróneo 2: el (time box) limite de tiempo obliga a cualquier grupo a convertirse en un equipo. Reúna a un grupo de personas y entrégueles un desafío y se unirán. No apostaría por eso, y tú tampoco deberías.

Los equipos necesitan un objetivo de trabajo claro y convincente . Sin eso, no hay razón para formar un equipo.
Time boxing es una de las estructuras que puede ayudar a los equipos a tener éxito al proporcionar enfoque. Trabajar en cajas de tiempo crea un ritmo natural de retroalimentación y conexión con el propósito del equipo. Pero una caja de tiempo y un objetivo, en sí mismos, no crean un equipo.

También necesitan las habilidades técnicas requeridas por el trabajo y las habilidades interpersonales para trabajar en equipo . Necesitan recursos como herramientas y acceso a información y educación. Necesitan una conexión con la organización más grande.

Los equipos necesitan tiempo para desarrollar las estrategias y la confianza que permite un alto rendimiento . Necesitan tiempo para comprender las fortalezas y debilidades de cada uno, desarrollar conocimientos compartidos y aprender a aprender juntos.

Cuando nuevas personas constantemente llegan y se van, un grupo nunca puede desarrollar los enfoques compartidos y el conocimiento compartido que les permite superar a un grupo de individuos.

Fuente : https://dzone.com/articles/what-a-self-organizing-team-is-not?edition=521296&utm_source=Zone%20Newsletter&utm_medium=email&utm_campaign=agile%202019-09-02

Contratos en proyectos con Scrum

Algunos de los tipos más comunes de contratos utilizados en los proyectos Scrum son los siguientes:

1. Contrato de entrega incremental: este contrato incluye puntos de inspección a intervalos regulares. Ayuda al cliente o partes interesadas a tomar decisiones sobre el desarrollo de productos periódicamente durante todo el proyecto en cada punto de inspección. El cliente puede aceptar el desarrollo del producto, decidir detener el desarrollo del producto o solicitar modificaciones del producto.

2. Contrato de empresa conjunta: este contrato se usa generalmente cuando dos o más partes se asocian para realizar el trabajo de un proyecto. Las partes involucradas en el proyecto lograrán un Retorno de la Inversión porque los ingresos o beneficios generados serán compartidos entre las partes.

3 Contrato de Desarrollo en Fases: este contrato pone a disposición fondos cada mes o cada trimestre después de que se completa con éxito un lanzamiento. Proporciona incentivos tanto para el cliente como para el proveedor y garantiza que el riesgo monetario para el cliente se limite a ese período de tiempo particular, ya que las liberaciones fallidas no se financian.

4. Contrato de incentivo y penalización: estos contratos se basan en el acuerdo de que el proveedor será recompensado con un incentivo financiero si los productos del proyecto se entregan a tiempo, pero incurrirá en penalidades financieras si la entrega se retrasa.

fuente : http://blog.scrumstudy.com/types-of-scrum-contracts/

Historias de usuario lo mejor para entregar valor a nuestros clientes

Que es una historia de usuario ?

1. Tarjeta
2. Conversacion
3. Confirmación

Estos tres componentes son una trinidad inseparable. Elimine cualquiera de ellos, y el valor se pierde de inmediato . Examinemos estos componentes para entender por qué.

La tarjeta

La tarjeta es la primera representación física de la historia del usuario. Como dije anteriormente, la tarjeta suele ser su índice promedio. Su pequeño tamaño es intencional. Estamos evitando la tentación de documentar exhaustivamente el requisito . Una definición de historia típica será solo una oración:

"Como gerente de laboratorio, debería poder filtrar una lista de reactivos para poder localizar fácilmente los que necesito usar".

También te puede interesar: La tarjeta no es una historia de usuario

Notarás este mismo patrón en muchas historias de usuarios. Este patrón es tan frecuente que ha heredado su propio nombre, "Role-Goal-Motivation". Hablaremos sobre los roles en un artículo posterior. Por ahora me gustaría centrarme en el objetivo y la motivación.

El objetivo es "lo que tengo que hacer". La motivación es "por qué tengo que hacerlo". El porqué representa el VALOR que brindará esta historia en particular. Siempre trato de asegurarme de que nuestras historias estén representadas de esta manera para que no nos olvidemos de la parte del valor .

De hecho, evitar el olvido es el valor principal proporcionado por la tarjeta. No estamos tratando de documentar todo. Solo estamos creando lo que Jeffries llama "una ficha". Incluso podría referirse a él como un kanban del mundo delgado. Su propósito principal es recordarnos que tengamos esas conversaciones .

La conversación

La conversación es donde ocurre la captura de valor real . Es en las conversaciones cara a cara regulares entre los clientes y los desarrolladores que cada participante adquiere una comprensión común de lo que se trata un requisito particular.

Estas conversaciones tienen lugar varias veces en el transcurso del desarrollo. Inicialmente ocurrirán cuando se defina la historia y se cree la tarjeta. Volverán a ocurrir cuando llegue el momento de estimar y programar la historia para su implementación. Deben ocurrir con frecuencia en el transcurso de la iteración en la que se implementa una historia determinada. Ocurrirán una vez más cuando la historia se "complete" y las nuevas capacidades del software se demuestren por primera vez.

Cada una de estas conversaciones resulta en el intercambio de "pensamientos, opiniones y sentimientos" con respecto al valor que debe agregarse. Estas conversaciones son el corazón de cómo mitigamos los problemas con las especificaciones de los requisitos de software.

Debido a que nuestras conversaciones nunca son inamovibles, ya que no existe un proceso de control de cambios, podemos responder de manera eficiente y efectiva a nuestra comprensión cambiante de la mejor manera de entregar valor . Debido a que no intentamos documentar exhaustivamente nuestra comprensión del valor requerido, podemos permitir que nuestra comprensión evolucione a lo largo del diseño y la implementación del software . Debido a que estas conversaciones ocurren continuamente en lugar de por adelantado, no hay demoras entre la elaboración de los detalles y la implementación de esos detalles .

Nuestro problema de cambio de contexto ha sido eliminado.

La confirmación

Las conversaciones en sí mismas, sin embargo, no son suficientes. ¿Cómo sabemos cuándo hemos terminado? El último componente crucial de la historia es la confirmación o "prueba de aceptación".

Las pruebas de aceptación son pruebas automatizadas que documentan de manera maleable nuestra mejor comprensión actual de cómo se entregará el valor para una historia dada. Deben ser entendibles tanto por el cliente como por el desarrollador. El aumento en la disponibilidad de herramientas de desarrollo impulsado por el comportamiento , como Cucumber,  proporciona un medio excelente para crear pruebas de aceptación.

Debido a que estas pruebas son maleables, se pueden cambiar fácilmente a medida que ocurren conversaciones adicionales sobre la historia y a medida que el software evoluciona. Debido a que son automatizados y ejecutables, podemos decir fácilmente en cualquier momento dado si el software cumple con nuestra mejor comprensión actual de lo que requiere una historia dada.

No hay riesgo de que el software y los "requisitos" se desincronicen siempre y cuando estas pruebas se ejecuten de manera regular . Si es posible, esto debería suceder cada vez que se confirme un nuevo código en el repositorio de origen.

Resumen

El desarrollo de software se trata principalmente de entregar valor a nuestros clientes . Dado que ese es el caso, deberíamos estar utilizando las mejores herramientas disponibles para garantizar que estamos entregando continuamente el valor que nuestros clientes esperan. Espero que a través de este artículo haya podido arrojar algo de luz sobre por qué las historias de los usuarios son una excelente herramienta para lograr la entrega de valor.

Fuente:  https://dzone.com/articles/use-stories-deliver?edition=513292&utm_source=Weekly%20Digest&utm_medium=email&utm_campaign=Weekly%20Digest%202019-08-07

La era agile llego, titulo del best seller de Amazon 2018

Unos minutos de la charla realizada al equipo de Pulxar de Bogota, sobre como la Era Agile, llego y esta ayudando a las organizaciones a realizar innvaciones y seguir el camino de la transformacion digital.

Slow Agile, Agile a un ritmo natural , placentero y mas - video CAS 2017 de Thomas Wallet

La era agile llego, titulo del best seller de Amazon 2018

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/

Dia Mundial Retrospectiva 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

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/ 

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/

Scrum Master mejora los equipos y promueve la auto organizacion

Somos conscientes del hecho de que Scrum Master desempeña el papel de un líder servidor que satisface las necesidades del Equipo Scrum. Un Scrum Master no se involucra con el desarrollo de los entregables del proyecto y permite que el Scrum Team funcione por sí solo. Un Scrum Master prepara a la organización y los miembros del equipo para adoptar el marco de Scrum para entregar proyectos con éxito. Aparte de estas responsabilidades, un Scrum Master también tiene la capacidad de actuar como un agente de cambio dentro de la organización. Ahora, veamos cómo.

La Guía Scrum o el SBOK (Una Guía para el conocimiento de Scrum sostiene que un Scrum Master sirve a la organización de varias maneras, que incluyen:

Mentor del equipo scrum para adoptar Scrum
Responsable de la implementación de Scrum en la organización.

Ayudar a los miembros que no son del núcleo a entender Scrum y acostumbrarse a la idea del desarrollo empírico de productos

Preparar un entorno propicio que mejore la productividad del equipo Scrum;
Colaborar con Scrum Masters de otros equipos para aumentar la eficiencia de la aplicación de Scrum en la organización.


Scrum Guide o SBOK Guide no han identificado explícitamente a Scrum Master como un agente de cambio organizativo, pero de acuerdo con muchos coaches ágiles, si algún rol tiene la capacidad de generar un cambio en el sistema en un entorno ágil, entonces, es Scrum master.

Consideremos un ejemplo. Scrum master, al ser un facilitador, identifica varios problemas (que deben abordarse antes del próximo Sprint. Según los expertos de Scrum, Scrum Masters debe informar los problemas a los miembros de la alta gerencia, como un CTO. Sin embargo, todos sabemos que la accesibilidad para la alta gerencia de manera oportuna puede ser un problema en sí mismo. Entonces, ¿cómo puede un Scrum Master abordar esta compleja situación?

Una forma de abordar esto es establecer una junta o un grupo de Scrum Masters que trabajen en diferentes proyectos de la organización y recopilar información sobre todos los problemas a los que se enfrenta Scrum Master. Los problemas a los que se enfrentan pueden ser iguales o diferentes y el truco aquí no es agruparlos sino tratar de determinar el panorama más amplio de por qué surgen los problemas. Este proceso de identificación y recolección de impedimentos es seguido por una serie de pequeñas discusiones con miembros del equipo en forma de un pequeño grupo. Los participantes en los grupos son los que tienen una responsabilidad directa o indirecta sobre el tema. Ahora, al combinar las vistas, puede pasar el asunto al CTO o a cualquier autoridad de toma de decisiones.

Esta forma de escalar problemas se recomienda especialmente para las organizaciones que tienen una estructura jerárquica o una organización de múltiples capas. Uno de los principales beneficios de esta técnica es que las organizaciones pueden permitir que los empleados expresen su opinión sobre la estructura organizativa y el sistema existentes sin inhibiciones.

Según la guía Scrum, Scrum Master es un facilitador que garantiza que el equipo Scrum reciba un entorno propicio para el desarrollo del producto. El Scrum Master debe explorar todas las vías de su competencia para permitir la entrega exitosa del proyecto. Por lo tanto, un Scrum Master debería minimizar todos los obstáculos que tienen el potencial de reducir la velocidad del Sprint. Al actuar como un agente de cambio, el Scrum Master solo intenta asegurar una coordinación sin problemas y contrarrestar una posible visión de túnel que, de nuevo, no es más que un paso firme hacia el logro de la agilidad.