viernes, febrero 26, 2016

Historias de usuario "de sistema" - Una propuesta de escritura

Hola a todos

Cuando comenzamos a introducirnos en el mundo de las historias de usuario y de Scrum, queremos poner todo en este formato, no digo que no se pueda, pero scrum en ninguna parte dice que debamos usar historias de usuario, o casos de uso, o requerimientos en prosa, solo dice es necesario ítemes de backlog para priorizar en el Product Backlog y para trabajar en el Sprint Backlog -y nada más-.

Entonces bajo esa premisa, que es decisión nuestra escribir requerimientos del sistema como historias de usuario, quiero compartir con ustedes una propuesta de como escribirlas y algunas reglas (heurística) que me han resultado útiles

La primera idea es usar el formato propuesto por Mike Cohn, para escribir historias de usuario

YO COMO______ usuario_______________
DESEO _________funcionalidad__________
PARA _______beneficio de negocio________

Por lo tanto supongamos que existe la siguiente necesidad en nuestro sistema

 "a las 12:10 AM se corra un job que determine que clientes son morosos (con moras iguales o superiores de 30 días ), les envíe un email a quienes tiene moras superiores a 30 días y múltiplos de 15 (ejemplo: 45, 60, 75, etc) sobre el estado de la deuda, y a luego envíe al callcenter un listado con las personas a llamar, y notifique si el proceso fue exitoso o fallido."

¿wow, mucho no cierto?

como muchos venimos con el paradigma de los casos de uso (y vemos el sistema como un actor, cosa correcta), nos vemos tentados a escribir la siguiente historia de usuario



HU30:  Notificaciones Email y CallCenter para Morosos
YO COMO sistema
DESEO generar el listado de morosos
PARA notificarles su estado crediticio y activar la llamada del callcenter


Esta aproximación yo no la veo correcta, pues el beneficio de negocio no le importa al sistema, le importa a alguien que tal vez sea el Gerente de Créditos, además en esta primera versión observamos el beneficio de negocio son más funcionalidades, en vez de algo como "mejorar la gestión de cartera a través del callcenter y notificación electrónica", reescribiendo sería:


HU30:  Notificaciones Email y CallCenter para Morosos
YO COMO Gerente de Créditos
DESEO generar el listado de morosos,
PARA mejorar la gestión de cartera a través del callcenter y notificación electrónica


Perfecto, pero donde nos quedaría el resto del problema: las notificaciones, el callcenter y la notificación, pues quedaría en los criterios de aceptación,  veamos:


HU30:  Notificaciones Email y CallCenter para Morosos
YO COMO Gerente de Créditos
DESEO generar el listado de morosos,
PARA mejorar la gestión de cartera a través del callcenter y notificación electrónica

Criterios de Aceptación
  1. Enviar un email a quienes tiene moras superiores a 30 días y a  múltiplos de 15 (ejemplo: 45, 60, 75, etc) sobre el estado de la deuda
  2. Enviar al callcenter un listado con las personas en mora a llamar, 
  3. Notificar si el proceso fue exitoso o fallido


Esta versión me gustó más,  pero comenzaría preguntas como:

respecto al criterio de aceptación 1:
  • ¿Cuál sería el formato del mensaje?
  • ¿Qué diria el subject?
  • ¿Qué contendría el cuerpo del email (montos, fechas, intereses, saludo, logo, etc)?
  • ¿y si el email rebota?
respecto al criterio de aceptación 2:
  • ¿qué información enviaríamos al callcenter
  • ¿qué formato sería: csv, pipes, xml?
respecto al criterio de aceptación 3:
  • ¿a quién notificaríamos?
  • ¿que tipo de mensaje: texto, mail, whatsapp?
  • ¿contenido del mensaje?

Repito: 

"mucho ¿no cierto?¿no creen que es mucha funcionalidad, partiendo de la premisa que las historias de usuario son pequeñas y a lo sumo debe costarnos 3 días para lograr el DONE?"

Además si aplicamos INVEST (ver más aquí), toda esta cantidad de funcionalidad no sea estimable fácilmente por el equipo y tal vez su tamaño implique que requiera construirse en varios Sprints.

Por lo tanto, tal vez sea necesario partir la historia de usuario en dos:



HU30:  Notificaciones Email para Morosos -
YO COMO Gerente de Créditos
DESEO generar el listado de morosos,
PARA mejorar la gestión de cartera a notificación electrónica

Criterios de Aceptación
  1. Enviar un email a quienes tiene moras superiores a 30 días y a  múltiplos de 15 (ejemplo: 45, 60, 75, etc) sobre el estado de la deuda
  2. Notificar si el proceso fue exitoso o fallido

***

***

HU35:  Notificaciones  CallCenter para Morosos
YO COMO Gerente de Créditos
DESEO generar el listado de morosos,
PARA mejorar la gestión de cartera a través del callcenter y notificación electrónica

Criterios de Aceptación
  1. Enviar al callcenter un listado con las personas en mora a llamar. Mora mayor o igual a 30 días. 
  2. Notificar si el proceso fue exitoso o fallido

***

Ahora, la pregunta es ¿entramos al detalle de especificar los puntos 1 y 2 de los criterios de aceptación de cada HU?
Y la respuesta es: depende del Product Owner y del equipo

Tal vez así sea suficiente para el equipo y con las preguntas que se hacen en el planning queden todos tranquilos.

O, tal vez requieran que las preguntas sobre los criterios de aceptación 1 y 2 se especifiquen en formato BDD (clic acá para ver).

La respuesta, no la tengo yo, la tiene cada equipo en su inspección y adaptación del proceso.

Espero les haya servido

Saludos ágiles


Jorge Abad


Post complementarios y relacionados


  • Tres ideas cortas sobre las historias de usuario - Clic aquí.
  • Cómo luce (se ve) una historia de usuario - un pequeño ejemplo  - Clic aquí.
  • Características de una buena historia de usuario   - Clic aquí.


El Lego y la plasticidad del software




Hola a todos

Como muchos saben, comencé en el mundo del software desde mi carrera de origen, "la ingeniería civil" - muchos en el mundo del software venimos de otras áreas -, en esta carrera se programa bastante (al menos en mis tiempos) y luego profesionalmente fuí girando desde sistemas de información geográfica hasta estar completamente en el mundo de las clases, los métodos, los NullPointerException, etc, hice mi especialización, terminé mi maestría, y desde hace un buen tiempo navego en el sinfín de certificaciones, cursos, amores y desencantos de los proyectos de software.

Muchas cosas me quedaron de mi "anterior reencarnación":

  • saber a simple vista como una columna esta torcida, 
  • saber presupuestar proyectos civiles y cantidades de obra, 
  • saber cuando comprar o no una casa.
  • entre otras


Hoy en día cuando comparto con mis compañeros gerentes de proyectos de software, aprendices a Scrum Master, desarrolladores, tanto en los cursos como en nuestras discusiones sobre proyectos, hablamos de que no aplican los principios de planeación predictiva de ingeniería civil a ingeniería de software - y eso que dudo que seamos una ingeniería -, y es solo mirar este APU (Análisis de Precios Unitarios)

APU (Análisis de Precios Unitarios) (1)

Tan pulido, tan perfecto, que hasta tiene determinado cuanto va a ser el desperdicio de cantidades de obra (10%). Es sino decir cuanto va a medir el muro y sabremos:

  • cantidades de obra (ladrillo, cemento, arena)
  • tiempo de construcción
  • elementos adicionales requeridos


Cuanto quisiéramos nosotros que fuera así para nuestra industria, pero la incertidumbre en software es brutal -es nuestro pan de cada día-, se encuentra entre el 25% y el 400% tendiendo con mayor seguridad al 400% (todos sabemos que sí), ver el cono de la incertidumbre para software:


Cono de la incertidumbre (2)


Y para acabar de ajustar aunque te encuentres en la zona de construcción del software del cono, le preguntas a alguien del equipo:

- ¿y en cuanto crees que terminas esa funcionalidad?
- mmm, pues yo creo que en tres horitas más
- Ok, quedo atento, me cuentas cuando termines(3)

y resulta que era el mejor ingeniero y se demoró 6 horas, que sucedió entonces:

  • algo se desconfiguro en el servidor
  • la clase era mas compleja de lo esperado
  • no le refrescaba bien lo que quería ver
  • o simplemente ese día "no daba pie con bola"- pues hacer software es una actividad intelectual y creativa-  pero se levantó al siguiente y todo quedó resuelto.


¿y es mal ingeniero? 

¿se robó esas tres horas de más? pues ese tiempo no era el estimado (una pequeña reflexión a este respecto acá - Una pequeña diatriba: ¿quién/cómo van a reponer ese tiempo? )


Hombeeeee.. la verdad no..

Solo que un estimado, es un valor que tiene asociado un valor de probabilidad, que lo vamos ajustando en la medida que avanzamos en el conocimiento de lo que estimamos, y solo sabremos cuanto duraría la tarea (hablo de software) cuando por fin la terminamos.


Como decía Peter Drucker si "el reto en el siglo pasado era  la productividad de los trabajadores de manufactura, el reto de este es la productividad de los trabajadores de conocimiento"(4), y resolver esto será la clave del éxito de nuestras organizaciones de conocimiento. Pero tengamos seguro algo, las herramientas de uno, no funcionaran bien en otro.

Yo le insisto mucho a mis compañeros con frases como:
  • no estamos pegando piezas de lego, que son lisas y encajan perfecto
  • es que no son albañiles, no se puede hacer como con los muros, que si el muro quedo a la mitad no puede llegar otro a terminarlo con las mismas características (gracias @luchosalazarc por este ejemplo)
  • como Carlos se imagina la solución no es igual a como la hace Luisa ambos piensan distinto e interpretan diferente, uno lo ve menos acoplada, otro más dinámica.
  • metiendo más gente no vamos a terminar más rápido, van a estorbar manos, igual en un edificio donde se tengan muchos obreros llegará el momento en que se dirá: "no más", después de este punto somos improductivos
  • No podes pedir predictibilidad sobre algo incierto y plástico que 
    • Carlos lo ve gigante 
    • Luis lo ve pequeño
    • Juan lo ve complejo
    • y Diana lo ve de tamaño regular
    • y para acabar de ajustar todos tienen la razón pues la claridad con la que se acercan al problema depende de cuantos problemas similares hayan resuelto, cuanta experiencia tengan con la herramienta, y de la ayuda de sus compañeros
He observado que es más exitoso en soportarse en las herramientas que proporciona la agilidad:
  • frameworks como scrum
  • la gestión empírica de proyectos basada en la inspección y adaptación
  • el planning poker y su escala de fibonacci
  • los sprints de 2 semanas que nos permite conocernos como equipo y conocer la complejidad de estimación del sistema
  • las retrospectivas como habilitadoras del aprendizaje
  • Apuntarle al pareto del sofware (20% del software resuelvel el 80% de las necesidades de negocio) y no constuir software innecesario
  • Soltar el alcance fijo, tiempo fijo, y costo fijo y centrarnos en la generación de valor fundamentada en la confianza de un gana-gana entre cliente y proveedor
Es más provechoso ser ágil


Concluyo con tres frases importantes:

HACER SOFTWARE NO ES UNA ACTIVIDAD PREDICTIVA
HACER SOFTWARE NO ES UNA ACTIVIDAD PREDICTIVA
HACER SOFTWARE NO ES UNA ACTIVIDAD PREDICTIVA


Saludos ágiles
Jorge Abad


Notas, Observaciones y Referencias

(1) Para ver más análisis de precios unitarios clic aquí  
(2) Tomado de "Estimating" en msdn.  clic aquí
(3) En scrum no ocurre esto, pues hay dos mecanismos de actualización uno el tablero kanban y el segundo es el daily donde todos sabemos que se terminó y que sigue en curso.
(4) Parafraseando un poco lo que el decía, la cita original es:  Según Peter Drucker1: “ La más importante, y en realidad la verdaderamente única, contribución de la ciencia de la gestión en el siglo XX fue el incremento, en 50 veces, de la productividad del trabajador manual en la producción.
La más importante contribución que la gestión necesita hacer en el siglo XXI es, de manera similar, incrementar la productividad del trabajo del conocimiento y del trabajador del conocimiento. El activo más valioso de una compañía del siglo XX era su equipo de producción. El activo más valioso de una institución del siglo XXI (sea o no de negocios) serán sus trabajadores del conocimiento y su productividad.” para ver más clic aquí.
(5) ¡Me desahogué!, hacia tiempo tenía pendiente escribir este post.

martes, febrero 23, 2016

Tres preguntas de Nexus

Hola a todos

Hace un tiempo vengo en un proyecto aplicando ciertos principios de Nexus (1), y uno de ellos es la sincronización entre Product Owners, Scrum Masters y Liderés técnicos, entre todos tenemos un grupo de Whastapp (2)  y hacemos  luego de los dailys de los equipos (o sea, diaramente) y a la misma hora, estas tres preguntas:
  1. ¿Qué dependencias se identificaron?
  2. ¿Qué tema crítico necesita ser resuelto?
  3. ¿Qué información desea compartir con otros equipos?
Luego cada cual responde e identificamos un responsable y acciones a seguir.




Espero les sirva, pues a nosotros nos ha servido mucho.

Saludos ágiles
Jorge Abad



Notas, Referencias y Aclaraciones:

  • (1) Nexus es un exoesqueleto para escalar Scrum - es decir, tener varios equipos scrum y un solo backlog -  (ver más acá)
  • (2) Usamos Whatsapp, debido a que tenemos equipos de trabajo en diferentes ciudades.
  • (3) Tweet para compartir la imagen (clic aquí)

domingo, febrero 21, 2016

Equipos Scrum: El equipo es multifuncional, no los team members polivalentes



Hola a todos

Cuando alguien se aproxima a Scrum (desde el desarrollo de software), se encuentra con que los equipos son multifuncionales (1) y comienza a buscar en la literatura y en las experiencias de otros equipos, como rayos implementar esto.

Comprendemos que multifucional consiste en tener todos integrantes requeridos con las habilidades (skills) requeridas para lograr un incremento en la construcción del producto, es decir, ya no esta tester y desarrollo aparte, sino que trabajan juntos.

                  - ¿como así?,
                     ¿ya no nos podemos acusar mutuamente?

                  - pues si, ya no son ellos y nosotros,
                    ya somos un solo team (wow, tremendo cambio)

Activando un riesgo

En esa búsqueda de referentes en internet, se encuentra que equipos muy maduros no tienen personas con el rol de tester, sino que el equipo toma sobre sí la responsabilidad del producto, y por ende,  se puede caer en una interpretación riesgosa es: "no necesitamos personal de testing, la calidad del producto debe ser garantizada por el equipo de desarrollo", no digo que este enfoque esté del todo mal, pero perdemos de tajo las habilidades de alguien experto en calidad del producto y le delegamos esta responsabilidad al equipo de trabajo que deberá aprender:
  • a verificar el producto,
  • a aprender de estrategia de pruebas
  • a buscar lo que no se ha perdido, 
    • es decir, intentar casos de prueba extraños para identificar comportamiento del producto.
    • adicional, los desarrolladores tienden a probar los caminos que saben que funciona, lo que deja huecos "funcionales" o "no funcionales".
    • Solo un desarrollador con gran disciplina y orientado a pruebas (tdd - test driven development) cubriría muchos de estos escenarios sin garantizarlo - y la verdad de eso he visto poco en estos años -.
  • a pensar como usuario
  • entre otras fortalezas de un buen tester
Implicando que los team members sean polivalentes(2), esto se puede lograr con el tiempo - no lo dudo -, pero esta transición deberá pagarla alguien con plena seguridad:
  • el equipo: pues le reclamarán tempranamente por habilidades que no tiene
  • el cliente: recibirá un producto que no tendrá full "Done / Terminado / Completado"
  • el scrum master: le dirán que por que no removió este impedimento oportunamente
  • el product owner: pues confió en el equipo y este le entrego un producto que tiene alta probabilidad de incidencias
  • la empresa proveedora: por el desagrado del cliente y el desgaste del equipo de trabajo.


Qué significa realmente un equipo multifuncional

La multifucionalidad significa que tenemos todos los roles y solo los roles requeridos para lograr el incremento del producto - ya lo había dicho -, por lo tanto, es muy probable que un buen Equipo de Desarrollo para software podría estar constituido por:
  • Desarrolladores de software
  • Tester
  • Tester automatizador (depende del proyecto y producto)
  • Base de datos (depende del proyecto y producto)
  • Diseñador gráfico  (depende del proyecto y producto)
Pues lo que se quiere en "Agile" es romper los silos y permitir que quienes saben construir la solución interactúen de forma más efectiva y eficaz, sin tropiezos y barreras burocráticas.

No dudo - como me ha sucedido - que los miembros del equipo comiencen a compartir conocimiento y a enseñarle a otros para verse apoyados en momentos que el producto tiene un aumento de esfuerzo en un tipo de especialidad específica, me ha sucedido que:

  •  los testers se apoyan en sus compañeros de desarrollo para probar, 
  • o que desarrolladores enseñan a testers a programar,
  • expertos de bases de datos y desarrolladores
  • etc
 y así poco a poco lograr una "polivalencia" pero el equipo reconoce en que hay al interior expertos que lideran un campo de conocimiento y se apoyan en ellos para encontrar la mejor solución.

Hasta acá la reflexión del día de hoy, espero les haya servido, pues encontrar quienes hacen todo bien es más difícil que encontrar quienes hagan bien unas cuantas cosas.



Saludos ágiles
Jorge Abad.



Notas y Aclaraciones:

  • (1) Guía oficial de Scrum (clic aquí)
  • (2) Polivalente: que vale para muchas cosas (clic aquí: http://dle.rae.es/?w=polivalente), en la industria de la manufactura, significa que puede realizar correctamente muchas labores

jueves, febrero 18, 2016

Una reflexión: A mayor presión sobre el equipo, mayor fricción // Una serie de hechos desafortunados


Hola a todos

Les comparto esta reflexión de como nos "perseguimos la cola" en proyectos en crisis, todo comienza cuando estamos atrasados (obvio bajo contexto de alcance, tiempo y costo fijo -llave en mano-) y se decide aumentar la presión sobre el equipo para cumplir compromisos, comencemos pues:



A mayor presión sobre el equipo, mayores carreras
a mayores carreras, mayor fricción
a mayor fricción y carreras, menos creatividad y menor cuidado al escribir código 
menos creatividad y menor cuidado al escribir código, mayores errores
a mayores errores, mayores reprocesos

Opción 1
a mayores reprocesos, mayor demora en generar los entregables
a mayor demora en generar los entregables, mayor estrés y por ende mayor presión.

Opción 2
a mayores reprocesos, mayor desgaste y menos resultados
mayor desgaste y menos resultados, mayor descontento
a mayor descontento, menor cumplimiento del propósito*
y a menor cumplimiento del propósito, mayor deserción laboral**
a mayor deserción laboral, menor capacidad para cumplir el cronograma y compromisos (alcance pactado)
a menor capacidad de cumplir el cronograma y compromisos (alcance pactado), mayor presión sobre el equipo


En últimas a mayor, presión mayor fricción
y en consecuencia menor éxito.

(las opciones 1 y 2 NO son mutuamente excluyentes)



Notas y comentarios:

* El propósito es aquello con lo que nos hace sentirnos conectados con la vida y con nosotros mismos, cuando alguien pierde el propósito comparte expresiones como: "No sé que estoy haciendo aquí", "este luche y luche para nada", etc.

** No falta quien dice: "pues tengamos un listado de personas pendientes por contratar para reemplazar los que se van" convirtiendo el proyecto en una máquina de moler gente. Opinen ustedes si este es el camino

Haz tus proyectos con Ágil
Más #Agile, Más #Scrum

Algunos Tweets sobre Scrum y la Agilidad













domingo, febrero 07, 2016

Otra Responsabilidad más del Scrum Master: Velar por el Proceso Organizacional



Hola a todos

Recurrentemente cuando soy el facilitador/instructor en los entrenamientos de Scrum (de 1, 2, 3 ó 5 días) al profundizar dentro de las tareas y responsabilidades del rol de Scrum Master (1)(2) enumero:

  • Velar por que se cumpla Scrum
  • Ser coach del equipo y del Product Owner 
    • o sea, que cada vez ambos sean mejor en sus roles, tanto en sus interacciones como en las técnicas que aplican
  • Ser líder servicial del equipo
  • Ser removedor de impedimentos
  • Responsable de la fluencia del equipo 
    • que el equipo no se detenga y cada vez tenga más velocidad
  • Agente de Cambio
  • y "Responsable de que se cumplan los procesos organizacionales"
y, ¡oh sorpresa!, todos dicen:

 - ¿como así?,  ¿este último punto también? ¿el scrum master no es como un lobo solitario, un rebelde sin causa en contra del sistema?

Y la respuesta es: - No


Lo cierto es que el SM, en primer lugar vela por que se haga Scrum pero luego no puede olvidarse del entorno en que esta inmerso y debe velar por que el equipo, realice:
  • seguimiento de estándares y procesos de desarrollo, 
  • procesos de infraestructura
  • procesos arquitectura
  • registro de formatos
  • y similares (Nexus, enumera esto como una  de las responsabilidades del "Equipo de Integración Nexus" ) (3)

sin ir en contra vía del manifiesto ágil

Personas y sus interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan (4)

y de el framework de Scrum.



Un buen Scrum Master identificará los impedimentos en esos procesos y herramientas a ser removidos de forma orgánica o paulatina en el tiempo, pero no empezará a decir:

- Como mi equipo trabaja con Scrum, no usamos los repositorios oficiales, ni generamos los registros requeridos, ni seguimos los estándares definidos por la organización, como somos ágiles no tenemos dichas resposabilidades

No, no, no, la agilidad no es anarquía, la agilidad promueve la excelencia desde la autoorganización ydesde la gestión empírica de proyectos basada en Inspeccion y adaptación.


Hasta acá esta corta reflexión.

Hasta la próxima

Saludos Ágiles
Jorge Abad






Aclaraciones y Referencias

jueves, febrero 04, 2016

Todos Terminarán Siendo Ágiles


Hace un tiempo he venido reflexionado junto con mi círculo de amigos de Ágiles Colombia, especialmente con Lucho Salazar (@luchosalazarc) y Leonardo Agudelo (@sweepnoise), sobre que pronto la industria en general, los monstruos de la tecnología, las certificaciones, etc, tenderán hacia el cambio Ágil (Agile) o incluirán en su estilo o títulos algo relacionado con esto (1).


Y el cambio será (esta siendo) relativamente natural y orgánico,  este cambio nace desde TI con:


y nuestro afán en dejar de fallar haciendo en software (pues desde TI, llevamos años y años fracasando y haciéndole perder dinero, tiempo y oportunidad a nuestros clientes, a nuestras empresas y tiempo valioso de familia o descanso a todos los que han (hemos) estado involucrados en proyectos de software) y comenzamos a enfocarnos diferente, a generar valor de forma distinta, a trabajar más en equipo y generar valor en periodos cortos, y este cambio ha hecho que alguien ajeno a TI, diga: "estos locos están haciendo las cosas distinto, por fin funcionan, que podemos aprender de ellos, yo quiero eso mismo para mí y mi equipo".

Pero ¿quién no desea ser exitoso en los proyectos que emprende y usar las técnicas y herramientas más apropiadas?

Y si yo desde otro enfoque, industria, mercado o empresa veo que otros lo están haciendo bien y les esta yendo bien, lo más obvio es que quiera copiar esa buena forma de trabajo y usarla en mi contexto (recordemos que la copia es una forma de innovación).

Ágil, no es sicorigido, es más emergente y orgánico (como lo expresaba arriba) y se va adaptando según se va comprendiendo y se va transformando la cultura.

Si observamos bien:

Entre muchos otros enfoques, vemos que esto no es una moda, que es un enfoque distinto para hacer las cosas y que llego para quedarse.

Yo doy la bienvenida a todos los que se quieran sumar a este esquema, más natural, humano, orgánico, adaptativo y retador de trabajo, enfocado en el trabajo de equipos autogestionados, dirigidos, con propósito, que transforman no solo a las empresas de TI, sino todos los nichos donde se encuentran.

Yo anhelo que hayan muchas empresas que se embarquen en este estilo de gestión y dar resultados más pronto que tarde, tanto por el beneficio de sus empleados como de esos mismos negocios (recordemos que en negocios quien no se adapta y evoluciona desaparece).

Pronto todos trabajaremos con porciones o la torta completa del enfoque ágil, y los beneficios totales o parciales que de este se deriven.

Yo por mi parte me sigo quedando con la parte DEL PRESENTE CONTINUO del Manifiesto Ágil, que reza:

Estamos descubriendo formas mejores de desarrollar
software generar Valor (2) tanto por nuestra propia experiencia como
ayudando a terceros.



Seguiré buscando formas mejores de generar valor, tanto para mi beneficio, los equipos de trabajo en los que participo, como para mis clientes.

Saludos ágiles

Jorge Abad.




Fuentes y aclaraciones:

  • (1) Acuérdense de mi, un día llegará que CMMi tendrá certificación AGILE
  • (2) Modificación que le observé Agustín Villena @agustinvillena
  • Management 3.0. Jurgen Appelo