Archivo de la etiqueta: agile

Mejorando la metodología Agile


Reuniones de “estado” todos los días???
A quién les gusta? A mi no!

Hoy en día todos los equipos utilizan metodologías Agile (Scrum, XP, Kanban) y normalmente se reunen 15m por día para hacer un status de su trabajo.

Pero realmente utilizar una reunión para saber estados, hoy en día, con las herramientas que existen (project management, team collaboration, task managemente, etc) es inútil, porque podemos extraer esta información cómo y cuándo queramos y nos queda el mismo resultado.

Agile dice que hay que hacerse tres preguntas:

Qué hice ayer? Qué hago hoy? Qué impedimientos o problemas tengo?

Voy a poner en jaque esto, porque para mi, esto es recolectar estados y no necesito reunirme 15m para saberlo.

Conocí Agile (aplicando Scrum) hace unos 7 años. Se escuchaba por todos lados y el dueño de la empresa quería “acelerar tiempos de producción” le habían dicho que con Agile Scrum lo iba a solucionar… no entendió nada.

Al ponerme en contra de Agile (me encanta cuestionar todo, sin cuestionamiento, no sabemos los motivos reales, ni podemos progresar) propondría un cambio:

Primero, el Agile Coach, debería exponer los cambios que detecta del día anterior al de hoy, es decir, qué cosas ve que están demoradas, qué cosas están trabadas y qué cosas cambiaron de estado, qué situaciones cambiaron en el equipo, qué personas están disponibles en el día, etc. En resumen, el Coach tiene que comunicar a todo el equipo, en que situación se encuentran, qué es lo que él ve sobre la situación del o los proyectos. Porque en los días que corren, el día a día nos come crudos, las definiciones cambian, los clientes deciden otras cosas, se interactua con otros equipos, con otros tipos de equipos, con tecnología que nos brinda información constante y que hace que la toma de decisiones sea cada día más corta y se tenga que responder a las situaciones en menor tiempo. Y el equipo interacturar y dar sus puntos de vista sobre estos temas, explicando cómo puede ayudar al equipo, cómo pueden resolverse los problemas, qué cosas ve negativas, etc.

Segundo, cada vez más tenemos integrantes del equipo trabajando remotamente, parcial o total y a nadie le interesa estar 15m escuchando por un auricular o parlante lo que estuvieron haciendo los demás, incluso, las personas que están trabajando remotamente, necesitan una información más concreta y precisa, para “sentir” al equipo.

Tercero, el principal problema de los equipos (lo veo desde que comence a trabajar en sistemas) es la comunicación “communication is breakdown is only the same”.
Desde integrantes insatisfechos que le aburren sus jefes o que tienen coordinadores o superiores que no tienen idea de que les tienen que pedir (hace muchos años con compañeros llamabamos a un jefe “cabeza de pulpo” porque sólo quería manejar a “sus” tentaculos para satisfacerse; te tratan como una extensión suya y no saben delegar: “no no, pero aca pone esto asi, que va andar, hace como te digo yo”), integrantes desmotivados, integrantes que no necesariamente deberían involucrarse en algunos temas, integrantes con diferentes skills, etc. Somos personas, no robots, todos los días cambiamos, por ende, todos los días necesitamos comunicarnos para el éxito en grupo, el grupo es una simbiosis de tareas, estados, ánimos, objetivos, problemas, etc, etc.
Lo ideal, es todos los días, comunicar todo a todos, pero para los que manejan los equipos esto es un problema no?, sienten que pierden su real funcionalidad (no me voy a extender sino ya me meto en un terreno filosófico de poder).
Es importante que el Agile Coach deje en claro los objetivos, lo qué espera de cada uno y comunicar todo lo que ocurre desde dentro del equipo como todo lo que llega desde afuera, sino no es un equipo, es una persona con subditos que hacen lo que les pide (siempre el futbol sirve como ejemplo para explicar estos temas). Los integrantes tienen que proponer objetivos personales también y en el día a día comunicarlos al equipo (tengan o no que ver con el trabajo, porque somos personas, lo vuelvo a recalcar, tenemos que compartir con sinceridad nuestros miedos, logros, etc, a veces ni nos enteramos que un compañero realizó un curso o tiene un proyecto propio donde todos podemos cooperar y fortalecer los lazos del equipo).

Concluyendo y sintetizando, es fundamental trabajar en equipo, pero realmente “en equipo”, tiene que haber profesionalismo, comunicación, manejo de la moral, objetivos claros, desafíos continuos (si no los hay los buscamos y los proponemos), hay que ser productivos, solidarios, tener emociones, festejos, derrotas, retos, “castigos”, y minimo una charla mano a mano entre todos por mes, para decir lo que cada uno ve en el equipo y que cosas quiere mejorar, modificar o eliminar. Y fundamental un lider que transmita pasion, interes en el equipo, qué guie a la unión y sepa lo que tenemos que hacer para triunfar (sino nos vamos a la B! jajaja)

Espero escuchar tus comentarios, esto me salió así del momento, creo que interactuando, podrían salir “filosofías” nuevas de trabajo.

Gracias!

Anuncios

Deja un comentario

Archivado bajo Filosofía de Equipo

ITIL DEVOPS AGILE PROCESS – El proceso de desarrollo de software a escala organizacional


El proceso de desarrollo de software Agile DEV+OPS en el marco ITIL consta de los siguientes pasos:

The Agile DEV + OPS software development process in the ITIL framework consists of the following steps:

itildevopsagile

scrum.png

Se describen las tareas y roles en los siguientes:

Tasks and roles are described in the following steps:

  1. Development OnDemand
  2. Projects Backlogs
  3. Planning
  4. Sprints
  5. Stories
  6. Technical Induction
  7. Development
  8. Unit Testing
  9. Code Review
  10. QA Deploy & Quality Review
  11. Release Package
  12. Deploy & Delivery
  13. Support & Monitoring
  14. HotFix

Deja un comentario

Archivado bajo Filosofía de Equipo, Teoría

ITIL DEVOPS AGILE PROCESS – HotFix


  • En caso de incidents en producción, se generan nuevas demandas que administraran los KAM/PL/PM para iniciar nuevamente el proceso de desarrollo (ITIL Change Management).
  • In case of production incidents, new demands are generated that will manage the KAM / PL / PM to initiate the development process again. (ITIL Change Management).
KAM: Key Account
PL: Project Lead
PM: Product Manager

←Support & Monitoring

Development OnDemand→

Deja un comentario

Archivado bajo Filosofía de Equipo, Teoría

ITIL DEVOPS AGILE PROCESS – Support & Monitoring


  • Luego de la puesta en producción se realiza seguimiento, monitoreo y soporte con el cliente a cargo de los PL y/o PM. (ITIL Service Desk)
  • After the deploy on production, monitoring and support are carried out with the client by the PL and / or PM. (ITIL Service Desk)
PL: Project Lead
PM: Product Manager

←Deploy & Delivery

HotFix→

Deja un comentario

Archivado bajo Filosofía de Equipo, Teoría

ITIL DEVOPS AGILE PROCESS – Deploy & Delivery


  • El recurso asginado realiza el deploy (ITIL Application Management).
  • En caso que el deploy corresponda al cliente, se entrega el paquete de deploy con la documentación correspondiente para realizarla (ITIL Application Management).
  • Assigned resource performs deploy (ITIL Application Management).
  • In case the deploy corresponds to the client, the deploy package is delivered with the corresponding documentation to perform itself (ITIL Application Management).
PO: Product Owner
SM: Scrum Master
SA: Solution Architect
PL: Project Lead
PM: Product Manager

←Release Package

Support & Monitoring→

Deja un comentario

Archivado bajo Filosofía de Equipo, Teoría

ITIL DEVOPS AGILE PROCESS – Release Package


  • Cuando se aprueba el product desarrollado, los PL/PM solicitan la generación de paquete para implementar en el cliente (ITIL Release Management).
  • El recurso asignado genera el paquete para instalar en el cliente (el ideal sería automatizar el proceso, siempre y cuando se cumplan los requisitos) (ITIL Release Management).
  • When the developed product is approved, the PL / PM request the generation of package to be implemented/deploy in the client (ITIL Release Management).
  • The allocated resource generates the package to be installed on the client (ideally, the process would be automated, as long as the requirements are met) (ITIL Release Management).
PO: Product Owner
SM: Scrum Master
SA: Solution Architect
PL: Project Lead
PM: Product Manager

←QA Deploy & Quality Review

Deploy & Delivery→

Deja un comentario

Archivado bajo Filosofía de Equipo, Teoría

ITIL DEVOPS AGILE PROCESS – QA Deploy & Quality Review


  • El SA planifica el deploy en QA para pruebas funcionales y de integración. (ITIL Test Strategy)
  • El SA gestiona el deploy en QA y asigna la tarea al recurso correspondiente (o el mismo la realiza). (ITIL Release Component)
  • El SA proporcionará herramientas para deploy en QA. (ITIL Release)
  • El equipo de testing o PL/PM realizarán las pruebas funcionales de product. (ITIL Quality Management)
  • El PO con el SM y los PL/PM realizarán el Quality Review para aprobar el product esperado (ITIL Quality Management).
  • The SA plans the deploy in QA for functional and integration tests (ITIL Test Strategy).
  • The SA manages the deploy in QA and assigns the task to the corresponding resource (ITIL Release Component).
  • The SA will provide tools to deploy in QA (ITIL Release).
  • The testing team or PL / PM  will perform functional testing of product (ITIL Quality Management).
  • The PO with the SM and the PL / PM will carry out the Quality Review to approve the expected product (ITIL Quality Management).
PO: Product Owner
SM: Scrum Master
SA: Solution Architect
PL: Project Lead
PM: Product Manager

←Code Review

Release Package→

Deja un comentario

Archivado bajo Filosofía de Equipo, Teoría