domingo, julio 26, 2020

Algunas Prácticas Técnicas de Equipos Ágiles y DevOps

Hola a todos

La búsqueda de la Excelencia Técnica debe ser la obsesión de toda empresa, área y equipo que trabaje con tecnología, obvio de nada sirve la excelencia técnica sino hay personas trabajando en equipo, empoderadas y con seguridad sicológica (recordemos soy agilista y este tipo de empoderamiento da resultado y ha sido demostrado miles de veces en la industria), pero también es cierto, que sin excelencia técnica no hay agilidad, ni nada. Sin buen software todos estamos perdiendo el tiempo.

"Sin buen software, todos estamos perdiendo el tiempo"

A continuación, les comparto el listado del prácticas técnicas más usadas por los equipos hoy (Julio 26 de 2020) según el 14th State of Agile:



  • Unit testing
  • Coding standards
  • Continuous integration
  • Refactoring
  • Continuous delivery
  • Automated acceptance testing
  • Continuous deployment
  • Pair programming
  • Test-driven development
  • Collective code ownership
  • Sustainable pace
  • Behavior-driven development (bdd)
  • Emergent design


Y las prácticas usadas por los equipos de élite  DORA Reseaarch (2):



  • Code Maintainability
  • Continuous Integration
  • Continuous Testing 
  • Database Change Management
  • Deployment Automation
  • Empowered Teams
  • Loosely Coupled Architecture
  • Monitoring & Observability 
  • Proactive Notifications
  • Shift Left on Security
  • Test Automation
  • Test Data Management
  • Trunk-Based Development
  • Version Control
Marqué en rojo las únicas que están en común, queda en tus manos determinar cuales utilizar en tu equipo, y si es que existe alguna brecha, cómo será tu proyecto de adopción.

Saludos ágiles
Jorge Abad


Notas, Referencias, Aclaraciones, Comentarios y Observaciones


  1. https://stateofagile.com/
  2. Dora Reseach Program
  3. Alguno links sobre excelencia técnica

martes, julio 21, 2020

Algunas Frases y Referencias Claves sobre Gestión de Equipos (post en construcción)

Tomado de (13)



Hola a todos

A continuación te comparto algunas frases claves de gestión de equipos, algunas desde mi experiencia y otra citando las fuentes.

Nota: lo que encuentras entre paréntesis, son referencias a links con información que sustenta la afirmación.


Equipos
  • Autónomos (1)
  • Coubicados (2)
  • Multidisciplinarios (3)
  • Autoorganizad4os(4)
  • Pequeños (4 a 6 personas)(5)(24)
  • Estables(6)
  • Competentes técnicamente (7)
  • Con seguridad sicológica (28)(29)
  • Con acuerdos y normas correctas (28)(29)
  • Con foco (que no trabajen en paralelo, sino en una o dos cosas a la vez)(8)
  • Que tienen tiempo para la mejora y la innovación (aproximadamente un 20%)(9)
  • Con control sutil, autoorganizado, avanzando en ciclos cortos y con un objetivo retador(10)
  • Felices y motivados (11)
  • Que hacen el daily son más(25)
  • Que alcanzan resultados, estarán mas motivados y por ende (7)
  • Que tienen objetivos alcanzables (máximo un mes), estarán más motivados y por ende (12)
  • Que terminan temprano, aceleran más rapido y por ende (13)
  • Que hacen retrospectivas ( - añadiría que hacen buenas retrospectivas (15)- )(16)
  • Que incluyen la mejora más importante en la planeación y ejecución de su siguiente ciclo de trabajo -scrumming the scrum - (17)
  • Que guardan en su planeación espacio para las interrupciones (18)
  • Que para planear usan el clima del día de ayer (19)
  • Que construyen historias de usuario pequeñas - o ítemes de backlog pequeños - , es decir de 2 a 3 dias en alcanzar la Definition of Done (21)
  • Que usan la Definición de Preparado - Definition of Ready-  (23) y la Definición de Terminado - Definition of Done (24) para la planeación, ejecución y entrega de su trabajo.
  • Que usan radiadores de información (tableros kanban, burndown, burnup, entre otros) y son transparentes respecto a su progreso (12).
Respecto a lo técnico
  • Orientados a la excelencia técnica (22)
  • Que tienen Practicas Ágiles Técnicas (clean code, automatización, etc) (26) (27)
  • Que remueven constantemente su Deuda Técnica (27)
son más veloces y productivos (20)

"Tener cadencia en un escenario complejo, genera cierta predictibilidad en las estimaciones y en la construcción de lo pactado" (7)
-------

"Equipos exitosos en un contexto agresivo, no tendrán resultados sostenibles o no generarán resultados(7)
-------

"Dar resultados, pero tener un equipo infeliz no es sostenible en el tiempo"(7)
-------

"Un equipo feliz que no da resultados, no es sostenible en el tiempo"(7)
-------

"Un equipo motivado que no da resultados, no es sostenible en el tiempo"(7)
-------
"Un equipo multidisciplinario con las competencias erróneas, no dará nunca resultados"(7)

-------
"El verdadero desempeño tiene poco que ver con la presión y todo que ver con la motivación" (true performance has little to do with pressure, and everything to do with motivation)"(30)
---

Hasta acá este compartir, si tienes alguna frase que quieras compartir, te invito a hacerlo en la zona de comentarios, con seguridad nos servirá a todos.

Saludos ágiles

Jorge Abad.


Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. http://scrumbook.org/product-organization-pattern-language/development-team/autonomous-team.html
  2. http://scrumbook.org/product-organization-pattern-language/development-team/collocated-team.html
  3. http://scrumbook.org/product-organization-pattern-language/development-team/cross-functional-team.html
  4. http://scrumbook.org/product-organization-pattern-language/development-team/self-organizing-team.html
  5. http://scrumbook.org/product-organization-pattern-language/development-team/small-teams.html
  6. http://scrumbook.org/product-organization-pattern-language/development-team/stable-teams.html
  7. Observación, deducción, multiples lecturas o experiencia.
  8. http://scrumbook.org/product-organization-pattern-language/development-team/swarming--one-piece-continuous-flow.html
  9. http://www.lecciones-aprendidas.info/2016/10/slack-o-el-tiempo-para-afilar-el-hacha.html
  10. https://hbr.org/1986/01/the-new-new-product-development-game
  11. Sobre la felicidad en los equipos
  12. Inferido de la guía de Scrum - https://scrumguides.org/
  13. https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern-language/teams-that-finish-early-accelerate-faster
  14. Photo credit: woodleywonderworks on Visual Hunt / CC BY
  15. http://www.lecciones-aprendidas.info/2019/11/y-tus-retrospectivas-cuando-van-ser-de-tipo-elite.html
  16. Sobre la retrospectiva
  17. https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern-language/scrumming-the-scrum
  18. https://sites.google.com/a/scrumplop.org/published-patterns/value-stream/estimation-points/yesterday-s-weather
  19. En este caso concreto la velocidad se refiere a que construyes el producto correcto. De nada sirve construir algo el mercado no quiere.
  20. Sobre las historias de usuario pequeñas
  21. http://agilemanifesto.org/iso/es/principles.html  - "La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad."
  22. http://scrumbook.org/value-stream/product-backlog/definition-of-ready.html
  23. http://scrumbook.org/value-stream/definition-of-done.html
  24. https://www.qsm.com/process_improvement_01.html
  25. El daily
  26. http://www.lecciones-aprendidas.info/2020/07/algunas-practicas-tecnicas-de-equipos.html
  27. Deuda Técnica
  28. http://sdhumancapital.com/2018/09/24/los-secretos-de-google-sobre-como-trabajar-en-equipo/
  29. Seguridad Sicológica
  30. https://www.thoughtworks.com/insights/blog/how-to-grow-effective-teams

    lunes, julio 20, 2020

    Sobre la Métrica de la Felicidad


    Tomado de (1)
    Hola a todos

    He observado que existe un prejuicio de escepticismo al acercarnos a ciertas prácticas sencillas, y en consecuencia por su sencillez creemos que no son poderosas, la métrica de la felicidad es una de ellas, es decir, es una práctica sencilla, poderosa y que genera excelentes resultados a nivel de personas, equipos y organizacional.

    Quisiera en este artículo compartirles varios pensamientos y conclusiones que he tenido usando esta métrica.

    En que consiste

    Consiste en reportar a todo el equipo de trabajo de forma frecuente (entre un día y una semana) que tan:
    • felices estamos con lo que hacemos,
    • contentos,
    • o cómodos con el trabajo,
    hemos estado en general, es decir, cómo percibimos la suma de las interacciones laborales, los emails, los clientes o proveedores, y todo lo concerniente al trabajo, en ese periodo de tiempo. 

    Usualmente se emplea un calendario, con colores o caritas:

    Tomado de (2)

    Niko Niko Calendar
    Tomado de (3)

    Management 3.0 Niko Niko Calendar
    Tomado de (3)

    En mi caso, con mi equipo de trabajo acordamos reportar semanalmente en una hoja de cálculo online como estuvo la anterior semana, y la calificamos con seis posibles valores:
    1. Muy mal
    2. Mal
    3. Regular
    4. Normal
    5. Muy bien 
    6. Genial

    En la empresa de gran un amigo reportan como estuvo el día:

    Estado general del equipo de trabajo durante la cuarentena del COVID-19

    Resultados que brinda
    • Si eres líder de un equipo, no lideras máquinas sino personas y las personas son seres emocionales y racionales, parte de ese liderazgo es validar si existe bienestar en ellos con lo que están haciendo y con la empresa en general, con el objetivo de brindar ayuda en un área donde puedas intervenir.
    • Existen suficientes evidencias científicas que permiten afirmar que los equipos felices o que experimentan mayor bienestar laboral son más productivos (3)(4)(5). No se trata poner la felicidad por encima de los resultados - sobre este punto volveré más adelante-, pero si tienes un equipo desanimado, muy posiblemente sus resultados y calidad no sean los esperados.
    • Mejor entendimiento del bienestar a nivel de personas, equipos y empresa
    • Identificación de tendencias, en una persona o el equipo de trabajo que te permitan realizar una intervención oportuna, por ejemplo: en un área de la empresa donde trabajo actualmente implementaron esta práctica durante la crisis del COVID (y el trabajo remoto) y alguien que por tres días seguidos se reportó regular, su líder al indagar identificó que tenía problemas de zona de trabajo en casa, se corrigieron los problemas y el bienestar cambio al siguiente día.
    • Los miembros del equipo se hacen conscientes del estado de ánimo de sus compañeros y su ayuda es útil en caso de dificultades.

    Cómo implementarlo

    • Comparta a todos el propósito de la práctica, es decir, conocer el bienestar laboral o la felicidad laboral de las personas y del equipo, con el objeto de brindar ayuda en caso de requerirse. Haga énfasis en esto: es solo información respecto al ámbito laboral.
    • Logre un acuerdo sobre el uso de la práctica con todo el equipo.
    • Comparta que se va a hacer con la información que se recolecta.
    • Identifique la frecuencia de actualización: diaria, semanal; no recomiendo periodos más largos.
    • Si es al final del daily o un ejercicio de sincronización semanal, pregunté y que califiquen el ultimo día o semana.
    • Pregunte abiertamente si quienes han compartido su estado de ánimo quieren compartir la razón del mismo, no obligue a nadie.
    • Como líder usted es responsable del entorno laboral de las personas a cargo - esa es su área de influencia -, si afloran retos personales, remita a su compañero a talento humano o bienestar laboral para que tenga asistencia por parte de profesionales especializados en esa área.

      Qué hacer durante 

      • Ponga atención a las señales
      • Si alguien por varios periodos ha compartido malestar, acérquese e indague ¿qué le tiene con malestar? ¿o qué sucede en ese equipo? y ¿qué puede hacer por esa persona o el equipo?
      • Obtenga promedios por áreas y por personas y generales, identifique tendencias.
      • Actúe acorde a las tendencias, es posible, que alguien o el equipo requieran su intervención.

      Qué no hacer

      • Comprenda que no siempre tenemos días o semanas perfectas, no haga de esto una carga, ni para usted, ni para los demás
      • Respete la vida personal, 
      • Adicional a lo anterior, no trate de convertirse en el sicólogo de su equipo, su intervención limítela a lo laboral, pero si observa que es necesario otro profesional, remita a las a personas con dificultades a las áreas de bienestar laboral de su organización
      • No obligue a las personas a explicar por qué calificaron un determinado estado de ánimo (recuerde solo invite, si la respuesta es no, no pasa nada).
      • No convierta la felicidad en su objetivo máximo, y en consecuencia se vuelva todo un estado de complacencia o de chamanismo para que todos tengan cara sonriente, pero sin orientación al logro,

        ¡No! su objetivo y el de su equipo es generar resultados, es decir, ganar el partido (futbolísticamente hablando), por lo tanto:
        • busque ganar el partido
        • pero no pase por encima de las personas, ni las maltrate, no tiene sentido desde ningún punto de vista
        • pero tampoco se vuelva tan complaciente que no les exija generar los resultados a los que se han comprometido al hacer parte de la organización, el área y el equipo de trabajo.
        • como líder del equipo, genere las condiciones para ganar, identifique impedimentos, fricciones; resuélvalas. Ganar genera felicidad y satisfacción, espíritu de equipo, y en consecuencia mejores resultados

      "Ganar, genera felicidad y satisfacción, espíritu de equipo, y en consecuencia mejores resultados"


      Por último

      Recuerde, usted lidera y acompaña a personas, no muebles y enseres, ser empático y entender el estado de ánimo de su equipo y las personas que lo componen le ayudará avanzar mejor.

      Hasta acá este compartir.

      Saludos ágiles

      Jorge Abad


      Notas, Referencias, Aclaraciones, Comentarios y Observaciones

      jueves, julio 02, 2020

      Un ejemplo sobre: Épicas, MVP, Historias de Usuario, Agregar Valor Incrementalmente y Agregar Valor


      Hola a todos

      Debido a recurrentes conversaciones y aclaraciones sobre:
      • Épicas
      • Historias de Usuario
      • MVP (Minimun Viable Product o Producto Mínimo Viable)
      • Agregar Valor
      • Agregar Valor Incrementalmente
      • y Scrum
      Voy a desarrollar un ejemplo hasta llegar a la planeación de los primeros tres sprints de un producto de solicitud de crédito, esto con el fin de ilustrar varios conceptos.

      Comencemos.

      Paso 1. Durante el Inception (9) se creó el siguiente User Story Map




      Paso 2. Durante el Inception (9) se realiza la estimación de cada release

      Se realiza una estimación de alto nivel y se identifica que aproximadamente (7) cada release tomará:

       Release 1 - MVP  7 sprints
       Release 2   6 sprints
       Release 3   6 sprints






      Paso 3. Inception - Durante el Inception se identifican las historias de usuario de los siguientes tres sprints (11)

      El equipo técnico luego de tener conversaciones con el PO y los Stakeholders estima que las dos primeras historias épicas son suficiente para los primeros tres sprints, quedando identificadas de la siguiente manera:


       Release  Épica  Historia de Usuario
       Release 1 - MVP Formato de solicitud básico
      • HU1 - Datos personales
      • HU2 - Datos familiares
      • HU3 - Datos laborales
      • HU4 - Referencias laborales
      • HU15-Información del cónyuge
      • HU5 - Ingresos
      • HU6 - Egresos
      • HU7 - Bienes
      • HU8 - Deudas
      • HU9 - Tipo de crédito solicitado
      • HU16 - Declaración de salud
      • HU10 - Validación rápida contra base de datos interna
      • HU11 - Validación de preaprobados
      Validar referencia personales
      • HU12 - Validar veracidad de referencias contra base de datos interna
      • HU13 - Registro de llamadas a referencias dudosas
      • HU14 - Escalar problemas a superior 
      Validación centrales de riesgo 1 y 2  Pendientes por definir (10)
      Calificación  Pendientes por definir (10)
      Creación del crédito  Pendientes por definir (10)
      Desembolso a cuenta propia  Pendientes por definir (10)


       Release Sprint  Historia de Usuario
       Release 1 - MVP Sprint 1
      • HU1 - Datos personales
      • HU2 - Datos familiares
      • HU3 - Datos laborales
      • HU4 - Referencias laborales
      • HU15-Información del cónyuge
      Sprint 2
      • HU5 - Ingresos
      • HU6 - Egresos
      • HU7 - Bienes
      • HU8 - Deudas
      • HU9 - Tipo de crédito solicitado
      • HU16 - Declaración de salud
      Sprint 3
      • HU10 - Validación rápida contra base de datos interna
      • HU11 - Validación de preaprobados
      • HU12 - Validar veracidad de referencias contra base de datos interna
      • HU13 - Registro de llamadas a referencias dudosas
      • HU14 - Escalar problemas a superior 
      Sprint 4  Pendientes por definir (10)
      Sprint 5  Pendientes por definir (10)
      Sprint 6  Pendientes por definir (10)
      Sprint 7  Pendientes por definir (10)


      Ya que llegaste hasta acá, déjame compartirte cuál es mi punto

      Realmente no es un punto, son varios, veamos:
      1. Observa que no existe relación entre la cantidad de épicas y la cantidad de sprints.
      2. El sprint backlog identificado se mantuvo entre 5 historias aproximadamente, la experiencia de varios autores sugiere que un buen Sprint Backlog debería tener entre 6 - 10 historias de usuario de similar tamaño (en la medida de lo posible), menos no es recomendable.
      3. El formulario o Épica de Solicitud de Crédito, NO ES UNA HISTORIA DE USUARIO, es una épica y el principal criterio es que un equipo se demorará más de un sprint en terminarlo (rompiendo los criterios de INVEST y CCC), por lo tanto, para ver progreso de VALOR INCREMENTAL, lo partimos en historias de usuario que nos permiten ver progreso en la construcción del formulario.
      4. Obvio, cuando se termine el sprint 1 tal vez tengamos las historias: HU1 - Datos personales, HU2 - Datos familiares, HU3 - Datos laborales, HU4 - Referencias laborales, HU5 - Ingresos; pero no tendremos nada que liberar a producción, lo que si es cierto, es que habrá sofware funcionando potencialmente liberable (o en producción apagado) esperando el resto del MVP para ser liberado cuando el PO dé la orden.
      5. El formulario o Épica de Solicitud de Crédito se terminará de construir aproxidamente en la mitad del sprint 3, como PO, ¿no prefieres ir observando progreso cada sprint? o ¿deseas luego de mes y medio (suponiendo que cada sprint fuera de 2 semanas) de estar comiendote las uñas, pensando que el equipo no te muestra avance? la verdad, creo que es mejor ver valor incremental; los PO con los que he trabajado luego de conocer el mundo del VALOR INCREMENTAL, de las pequeñas entregas, no desean volverse al anterior. Te invito a leer estos dos post respecto a la necesidad de tener historias de usuario pequeñas para poder observar progreso:
      6. Cuando se termine el formulario o Épica de Solicitud de Crédito, se le agregará VALOR al producto, pero este valor no se hará tangible hasta después que se ponga en producción. Recuerda: "el Software solo adquiere valor cuando es usado".
      7. Se dice aproximadamente, pues realmente no se sabe a ciencia cierta cuanto tiempo va a demorar en construirse cada release, lo que si sabemos es que vamos a estar priorizando por valor y tan pronto tengamos algo que genere impacto lo liberaremos.
      8. Realmente se Agregará o Generará VALOR cuando salga a producción el MVP, antes solo se genera satisfacción al PO y a los stakeholders, pues estos ven progreso. Recuerda: "el Software solo adquiere valor cuando es usado".
      9. El Inception consta de más actividades (ver un ejemplo acá -http://www.lecciones-aprendidas.info/2017/08/ejemplos-de-artefactos-agiles-inception.html )
      10. Estas historias de usuario no se escriben o refinan en el Inception, se detallarán más adelante. Se realiza en la vista del Discovery del Product Owner (ver http://www.lecciones-aprendidas.info/2020/03/product-owners-views-explicacion.html), además como estamos en un mundo tan volátil, es probable que tengan cambios en el futuro y sean fácilmente obsoletas. Recuerda, en ágil nos enfocamos mucho en no hacer activdades de desperdicio, o como dice el principio 10 del Manifiesto Ágil (clic aquí): "La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial." 
      11. Es altamente recomendado que como resultado de un Inception, se tengan las historias de usuario de los primeros tres sprints refinadas o preparadas para ser desarrolladas. Estas historias podrán tener formato o modo de representación que desees (ver http://www.lecciones-aprendidas.info/2019/05/modos-de-representacion-de-las-historias-de-usuario.html )
      12. En caso que para el PO y los stakeholders sea de valor liberar la Épica-Solicitud de Crédito (tal vez, porque les ahorra muchos procesos manuales), aunque esta no sea el MVP, pueden hacerlo, (¿quién se los impide?), y para acabar de ajustar no es necesario esperar al review del tercer sprint para ponerla activa en producción, perfectamente pueden liberarla en la mitad, no es necesario que esperen (no te lo imaginabas, ¿cierto 🤯? ). La referencia a esta práctica de liberación continua en la guía de Scrum (ver acá), es la siguiente:  "(Scrum se ha usado para) Liberar productos y mejoras tantas veces como sea posible durante el día".
      Espero te sirva este post para el desarrollo tu producto y puedas aprovechar los beneficios del desarrollo incremental.

      Hasta acá este compartir, bienvenido el feedback.

      Saludos ágiles

      Jorge Abad