Qué Método de Estimación Utilizar para mi Sprint?

Este artículo surge de un comentario que hice al artículo Planear sprints en horas y no por puntos de Lucho Salazar.

Estimar, según la RAE es “Calcular o determinar el valor de algo” o “Creer o considerar algo a partir de los datos que se tienen”, y como todos, en nuestra poca o mucha experiencia, sabemos que estimar no es algo trivial y aún más cuando estamos empezando en este mundo; ahora, con el paso del tiempo mezclamos las dos definiciones, ya que, calculamos con base en datos obtenidos con el paso de cada sprint; o al menos ese es el deseo, o, a mi consideración, lo que se debería hacer.

¿Qué método de estimación utilizar para planear mi sprint?, es la pregunta que muy seguramente nos surge cuando vamos a empezar, y según a quién se la formules te dará una respuesta con la cual, probablemente, muchos coinciden, debido a que unos métodos son más populares que otros.

Para responder esta pregunta, yo diría que todo método de estimación puede llegar a ser válido para un equipo, siempre y cuando este adquiera la madurez y la destreza en su utilización. Esto se consigue inicialmente a prueba y error, pasando por el punto en que se aprecia el avance en la utilización del método escogido, hasta conseguir dominarlo; en caso de no conseguir ningún avance es mejor cambiar y experimentar con otro método.

Para justificar mi postura, partamos de un método cualquiera (sea por horas, por puntos o puntos que equivalen tiempo o esfuerzo, u otro que hayas escuchado) y mi consejo es que te documentes muy bien al respecto antes de empezar. Comenzamos planificando los primeros sprint, los cual tenderán a errores (sobre o bajo la línea del Burndown) debido a la incertidumbre que conlleva iniciar con algo que, aunque esté documentado, se desconoce su comportamiento en la práctica; es con el tiempo (sprint tras sprint) en que este margen de error baja a su mínima expresión. Hay que tener en cuenta que se pueden obtener estadísticas como la velocidad promedio y las que creamos necesarias, con las cuales se puede predecir la estimación con base en datos y cada vez ser más acertados al planear el sprint.

Por lo anterior, estoy de acuerdo con Lucho cuando en su artículo expresa que "igual que con los puntos, estimar con horas no nos eximirá del error inherente a las estimaciones", para acuñar esta frase a este artículo he realizado unos pequeños cambios, quedando de la siguiente forma:

"estimar, independientemente del método utilizado, no nos eximirá del error inherente a las estimaciones"

Independientemente del método, la experiencia en su utilización te ayudará a obtener buenos resultados. Experimentar es fundamental para esto, puede que un método de estimación te dé mejores resultados que otro, y por lo tanto, sea el momento de realizar un cambio, ya sea de puntos a horas o de horas a puntos, o quizás algún método distinto a los aquí mencionados.

Clean Code Capítulo 3 Funciones

Al crear software debemos proporcionar mecanismos para llevar a cabo diferentes acciones, por esto aparecen las Funciones. En Clean Code, se hace énfasis en lo importante que es crear cada función para hacer una cosa, que vayan contando una historia y que cada una lleve a la siguiente. Si observamos secciones en funciones (por ejemplo declaraciones, inicializaciones y filtros), es una clara señal que la función hace más de una cosa, otro caso es cuando una función hace lo que dice que hace en su nombre, pero hace algo extra (se está incumpliendo la regla de hacer una cosa) generando un efecto secundario inesperado, siempre recordemos que las funciones son sin efecto secundarios, por lo tanto, si es necesario, se debe pensar en refactorizar. Una función debe responder a algo o hacer algo, pero no las dos cosas, de ahí que surge la separación de consultas de comando, el autor lo expresa de la siguiente manera "Su función debe cambiar el estado de un objeto o devolver información sobre el mismo, pero ambas operaciones causan confusión".

Al darles nombre no olvidemos el capítulo nombres con consentido, por esto se debe usar nombre descriptivos, que revelen la verdadera intención o acción de la función, una recomendación es utilizar verbos y palabras claves como por ejemplo writeField(name). write (Verbo), Field (Palabra Clave).

Cada función debe ser de tamaño reducido, ¿Cuántas líneas? no sabría decirte con exactitud, pero si nos basamos en el libro, este nos recomienda que tengan una longitud aproximada de 20 líneas, en estas líneas hay que prestar mucha atención a los bloques y sangrados. Cuando hablo de bloques hago referencia a fragmentos de códigos dentro de if, else, for y similares, en este caso la recomendación es que su longitud sea de una sola línea (lo más probable es que se invoque a otra función); en cuanto al nivel de sangrado no debe ser mayor a dos, ayudando a que haya un nivel de abstracción por función haciendo más fácil de comprenderla, con lo anterior se puede leer el código de arriba a abajo (la regla descendente). Esta regla consiste en posicionar las funciones por nivel de abstracción, como lo explican en Clean Code "Queremos que tras todas las funciones aparezcan las del siguiente nivel de abstracción para poder leer el programa, descendiendo un nivel de abstracción por vez mientras leemos la lista de funciones".

Otra parte clave en las funciones son sus argumentos, cuyo número ideal es cero, posteriormente uno (mónadico) y dos (diádico); se debe evitar las funciones de tres argumentos (triádico), las de más de tres argumentos (poliádico) deben tener una motivo especial. Las formas monádicas habituales son tanto para preguntar sobre el argumento o para transformar el argumento en otra cosa, un caso poco habitual es para eventos, en este caso las funciones por lo general no devuelven nada. En este punto el autor desaconseja utilizar argumentos de indicador (Pasar un booleano a una función) ya que de una forma u otra está indicando que la función hace más de una cosa. Para las funciones diádicas se debe propender que los argumentos sigan y tengan un orden natural, cuando estos carecen de dicho orden debe el programador utilizar los mecanismos necesarios para evitarlas. Cuando una función requiere dos o más argumentos se suele utilizar Objetos Como argumentos, pero esto no es una trampa, pues suele suceder que las variables antes pasadas como argumentos pertenezcan a un concepto más grande. Los nombres de los argumentos deben ser claros y acordes al contexto.

Algunas funciones tienen argumentos de salida, es decir, ver argumentos que en vez de ser entrada son salidas, estos argumentos deben evitarse.

El manejo de errores en una función en muchos casos se hace por medio de códigos de error, que suelen estar en una clase o varias lo que va creando alto acoplamiento y cuando surge un nuevo tipo de error, es donde viene los dolores de cabeza, por esto es mejor emplear excepciones que devolver código de error. Al utilizar excepciones es inevitable utilizar Try/Catch esto empieza a generar estructuras anidadas por eso es una buena práctica extraer bloques Try/Catch, esto quiere decir que se debe crear una función donde se procesa el error (dónde está la estructura Try/Catch, el procesamiento de errores es una cosa), desde esta se invocará la función que realizará la acción.

Antes de terminar quiero mencionar las instrucciones Switch, donde el autor hace una mención específica diciendo "Mi regla general para las instrucciones Switch es que se pueden tolerar si solo aparecen una vez, se usan para crear objetos polimórficos y se ocultan tras una relación de herencia para que el resto del sistema no las pueda ver. Evidentemente, cada caso es diferente y en ocasiones se puede incumplir una o varias partes de esta regla".

Las funciones nos ayudan a realizar acciones concretas, es nuestro deber evitar el no repetir código, por eso se deben crear con la mayor responsabilidad y dedicación y sin miedo a reescribir cuantas veces se crea necesario hasta que el resultado satisfaga las necesidades.

Nota: Para más artículos relacionados ver Clean Code.

Agilismo: Una Historia de Otro Planeta

Qué mejor que explicarlo con una breve historia.

Había una vez, en una galaxia no muy lejana, un planeta llamado Software en donde sus habitantes practicaban una extraña magia de conjuros, códigos misteriosos y algoritmos, los cuales daban vida desde los más simples hasta los más locos, atrevidos e innovadores sueños. A la gente de este planeta se les llamaba programadores. Con el pasar de los años las prácticas y métodos utilizados por estos hechiceros y magos para construir aplicaciones (así se le llamaba al producto de la magia que ahí se practicaba) fueron generando descontento e infelicidad en algunas latitudes del planeta Software parcializando a su población, por un lado los que apoyaban las antiguas prácticas y por otro los que querían buscar nuevas formas de hacer las cosas. De este grupo de los que querían buscar nuevas formas de hacer las cosas a través de la experimentación de nuevos e innovadores métodos surge un grupo de grandes hechiceros que se reunieron para consolidar su legado en un manifiesto que proclamaron como el Manifiesto Ágil, escrito lleno de principios sabios que hablan de colaboración, flexibilidad, calidad y motivación, y resumido en cuatro valores que dieron vida  a una nueva magia, poderosa, envolvente y sobre toda llena de felicidad. Lo que desconocían estos grandes hechiceros es que eso que hicieron ese día, daría origen a una importante hermandad (Agilismo) conformada por nuevos y viejos hechiceros, programadores (Agilistas) motivados, con deseos de experimentar, de colaborar creando y utilizando métodos de nombres místicos como Scrum, Kanban, Lean y lean Startup, para construir aplicaciones. De esta manera en el planeta Software todos fueron felices, puesto que nació el agilismo como un nuevo estilo de vida, una filosofía, una actitud, un movimiento, una hermandad de hechiceros que adoptaron los principios y valores del Manifiesto Ágil que los ayuda a construir un software que aporte valor y competitividad, y sobre todo que los hace feliz. Para terminar esta historia espacial debo decir que fue tan poderosa esta filosofía que traspasó los límites del planeta Software llegando hasta otros planetas como el Financiero, donde nadie nunca pensó que llegaría, pero así fue y cada uno de estos planetas fueron dejándose envolver por su poder generador de un cambio orgánico desde su estructura hasta su visión y por su magia de cambiar a las personas haciéndolas más productivas, colaboradoras, flexibles, amables y felices.

Si después de esta historia te preguntas qué dicen esos cuatro valores y en general el Manifiesto Ágil te lo dejo a continuación: “aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.” Los valores son:

• Individuos e 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

Los doce principios del Manifiesto Ágil son los siguientes:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

El Agilismo es un camino que te invito a iniciar, es muy fácil de empezar, pues ya diste el primer paso al leer este post y conocer los valores y principios del Manifiesto Ágil, ahora da el siguiente investigando aún más sobre él, te darás cuenta que ya está en casi todas partes y cuando menos te des cuenta estarás caminando por sí solo hacia la adopción de sus valores y principios, que básicamente de eso se trata. Déjate atrapar por su magia que puede transformar a una persona en alguien mejor y lo mismo le ocurre a las organizaciones cuando se toma con seriedad, responsabilidad y compromiso el agilismos, haciéndolas más productivas, flexibles y competitivas. Lo mejor es que no importa de qué sector o industria sea, si en ella trabajan personas el agilismo es para ellas, la base del agilismo son las personas.

Para ir terminando debo decir que ya ha pasado cierto tiempo desde que el Manifiesto Ágil vio la luz del día por primera vez, las personas, las empresas y un par de cosas más han cambiado en especial el sector al que fue dirigido inicialmente el Manifiesto Ágil. No estoy intentando decir que ya es obsoleto o que no es aplicable en otros sectores, pues me contradiría, ya que, acabo de decir que el agilismo ha traspasado las fronteras del Software y que el conocimiento del mismo es el comienzo al agilismo. Lo que pretendo es hacer un preámbulo acerca de un nuevo enfoque que ha surgido a raíz de que el Manifiesto Ágil no fue elaborado pensando en las dimensiones que ha tomado hoy en día el agilismo.

Este nuevo enfoque que se ha denominado Agilidad Moderna. Este nuevo enfoque del agilismo cuyo padres es Joshua Kerievsky (@JoshuaKerievsky) y del cual escuche por primera vez en la primera Jornadas Nacionales de Metodologías Ágiles - Ágiles Colombia 2016 y que volví a escuchar en una excelente charla de Johnny Ordoñez (@JohnnyOrdonez) en Agiles 2016 en Quito Ecuador, no busca reemplazar el Manifiesto Ágil sino que busca potenciarlo y hacer las cosas más simples, según Joshua Kerievsky "Agilidad Moderna es una comunidad de personas interesadas en descubrir mejores maneras de conseguir resultados impresionantes. Se aprovecha la sabiduría de muchas industrias, es impulsado por principios y un marco de trabajo libre". Sus cuatro principios son:

Como ya me he extendido un poco en este post los invito a que profundicen más acerca de este tema en la página oficial de:

Manifiesto Ágil

Agilidad Moderna

Introducción a la Agilidad Moderna

NOTA: Si no sabes que es Ágiles 2016 te cuento que “son conferencias sin fines de lucro organizadas por representantes de todas las comunidades ágiles latinoamericanas”, el próximo año Agiles 2017 se realizará en Chile, desde ya te invito.

¡Me acabo de enterar del Agilismo! ¿A quien sigo?

Cuando uno empieza un camino, ya sea para aprender algún marco de trabajo, una metodología, un lenguaje de programación, nuevas recetas de cocina o sea lo que sea que se quiera aprender siempre es bueno empezar teniendo un punto de referencia, alguien a quien seguir para no perdernos en el camino, es por esto que en este documento que hace un poco empecé a elaborar y espero que ahora entre todos de forma colaborativa elaboremos, enriquezcamos y hagamos una fuente para aquellos que apenas empiezan, he agregado a usuarios de Twitter de algunos agilistas de Colombia, de latinoamérica y unas cuantas personas más del resto del mundo.

Es un buen comienzo para aquellos que empiezan a concocer el mundo del agilismo y que no saben a quién seguir, ya que, a partir de ahí pueden empezar a seguir a estos agilistas y a conocer a quienes siguen ellos con el fin de contactar a otros agilistas. También encontrarán links a documentos o páginas donde pueden empezar a leer sobre agilismo y sobre algunos framework como Scrum y por supuesto está el link de la página de Agiles Colombia así como la dirección de meetup de Ágiles Colombia y Ágiles Ocaña donde podrán encontrar personas dispuestas a colaborar. No olviden que una parte de la esencia del Manifiesto Ágil y por ende del agilismo es la Colaboración. Cabe recalcar que me pueden escribir y consultar o pedir cualquier ayuda que si yo directamente no les puedo ayudar me uniré a su causa en busca de aquella persona que pueda ayudarnos (recuerda me uní a tu causa).

Mira el Documento Acá
Ágiles Colombia
Meetup Ágiles Colombia
Meetup Ágiles Ocaña

No olviden que si quieren pueden hacer su aporte a este documento agregando la información que creas relevante para aquellos que empiezan el camino del agilismo. 

Guía para la Retrospectiva

Antes de iniciar con la guía par ala retrospectiva acá les dejo la referencia a otro Post donde mención una guía previa a la retrospectiva.  

https://cedaniel200.blogspot.com.co/2016/06/que-hacer-antes-de-una-retrospectiva.html

Ahora sí, manos a la obra.

La retrospectiva debe hacerse al final de cada sprint, en donde el Equipo scrum se reúne con el propósito de revisar el proceso, relaciones entre las personas y herramientas utilizadas. Identificando lo que ha salido bien y lo que no, con el fin de buscar soluciones. Al final se diseña un plan para mejorar las cosas a futuro. La duración recomendada de la Retrospectiva del Sprint es una hora por cada semana de duración del Sprint.

Material Necesario

• Marcadores, Lápices o bolígrafos.

• Post – its

• Product Backlog

• Sprint Backlog

• Graficas del proyecto

Actividades

Cada una de las actividades debe acotarse en el tiempo sin que la suma de las mismas supere el tiempo total de la duración de la retrospectiva.

1. Aspectos Generales: Se explica el fin de la retrospectiva, actividades y sus tiempos.

2. Identificando Problemas: Esta actividad consta de diferentes momentos los cuales son:

a. El facilitador hace un resumen de lo sucedido en el sprint apoyándose de los datos (Product Backlog, Sprint Backlog, graficas etc.). 

b. Los miembros del equipo mencionan los problemas que ellos crean y se anotan en los post-its ubicándolos en un lugar visible para todos.

c. Los post-its se deben agrupar según una afinidad o relación, cada uno de estos grupos de problemas deben tener un nombre representativo.

d. Cada miembro del equipo vota, para esto cuenta con cierto número de puntos (Se recomiendan 10 por miembro) que debe repartir entre los grupos que el considere que afectan más a los objetivos.

3. Descubriendo Causas: La entrada de esta actividad son los grupos generados de la actividad anterior, cabe mencionar que no se buscan culpables sino revisar cada uno de los engranajes (partes del proceso de trabajo, de interrelaciones y de colaboración) del proceso para identificar que está fallando. Se toman los grupos más votados y para cada uno de estos grupos se analiza su causa para ello se utiliza un diagrama de espina de pez o Ishikawa. 

Como se ve en la imagen el problema es el centro en este caso la espina dorsal y cada causa se va desplegando como espinas a partir de la dorsal o de otras causas, hasta encontrar las causas básicas.

4. Plan de Acción: En esta actividad surgen las propuestas de mejora para solucionar las causas que producen los problemas que ha afectado el sprint evaluado. Para esto cada miembro del equipo escribe sus soluciones en post-its, luego entre todos seleccionan las que se implementaran en los Sprint venideros. Lo anterior puede generar actividades o tareas necesarias para llevar a cabo las propuestas seleccionadas, esta lista de tareas son anotadas en post-its y puede ocurrir una o varias de las siguientes opciones:

a. Los miembros de quipo se autosignan la responsabilidad de ejecutar las tareas

b. Las tareas se agregan en el Product Backlog

c. Las tareas se agregan en el Sprint Backlog

5. Que ha salido bien: Cada miembro escribe en post-its lo que cree que ha salido bien, luego en grupo se analiza cada post-its, llegando a conclusión si en realidad ha salido bien y si es así cuál ha sido el motivo por el cual ha salido bien, para seguir haciéndolo así  o reforzarlos en caso de ser necesario.

6. Conclusiones: Se exponen las conclusiones a las que se ha llegado a medida que ha transcurrido la retrospectiva y si se ha cumplido o no con el objetivo de la misma.

7. Retrospectiva de la Retrospectiva: Brevemente se analiza si la reunión de retrospectiva ha salido bien. Que aspectos faltan por mejorar, que aspectos han estado bien y que aspectos se deben reforzar.

EJEMPLOS

A continuación se mencionan los tiempos para cada una de las actividades tomando como referencia un sprint de 15 días es decir dos semanas, lo cual nos da una retrospectiva de máximo dos horas de duración o 120 minutos.

1. Aspectos Generales: Duración de 8 minutos.

2. Identificando Problemas: Duración de 30 minutos.

3. Descubriendo Causas: Duración de 20 minutos.

4. Plan de Acción: Duración de 20 minutos.

5. Que ha salido bien: Duración de 25 minutos.

6. Conclusiones: Duración de 10 minutos.

7. Retrospectiva de la Retrospectiva: Duración de 7 minutos.

REFERENCIAS

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf

https://proyectosagiles.org/2008/10/21/retrospectiva-agil-scrum/

http://eventos.kleer.la/public_events/813/watch/17047

¿Que hacer antes de una retrospectiva?

Se acerca la hora de la retrospectiva y estas a cargo de ella y no sabes como prepararte ni prepararla.

Acá  te dejo una Guía que te servirá tanto para organizarla como para llevarla acabo. También les dejo un Vídeo que habla sobre la retrospectiva en general pero en la cual en los primeros 11 minutos explican la guía.

Espero les sirva y buena suerte con la retrospectiva.

Guía       http://guiasagiles.org/#SesionesDeMejora
Vídeo     http://eventos.kleer.la/public_events/813/watch/17047

Adicionalmente acá les dejo un Post sobre como llevar la retrospectiva.

https://cedaniel200.blogspot.com.co/2016/06/guia-para-la-retrospectiva.html

Lecturas Interesantes Sobre SCRUM

Quiero recomendarles varias lecturas muy interesantes sobre SCRUM que se encuentran en la pagina de Javier Garzás:

Usando Scrum para evitar malas implementaciones de CMMI

La historia de usuario no es el “requisito” de las metodologías ágiles

Claves para implantar el rol de Product Owner, uno de los roles clave en un desarrollo ágil

y tiene mucho más te invito a que la explores.

Para terminar si te interesa hacer algún curso virtual acá tienes uno.

SCRUM

Se enmarca dentro de las metodologías ágiles en el desarrollo de software. Se puede definir como un marco de trabajo o una metodología de gestión del trabajo, centrado especialmente en el factor humano más que a los procesos, es decir, da mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental con iteraciones muy cortas. Básicamente se compone como tal de un Equipo y sus Roles; Bloques de Tiempo y Artefactos. Dentro de los Roles encontramos: El Scrum Master, que es el encargado de hacer que el equipo Scrum siga las prácticas y normas de la metodología, El Propietario del Producto, representa la voz del cliente, se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio y es el responsable de gestionar el Product Backlog, escribiendo historias de usuario y priorizándolas; y El Equipo, que hace el trabajo y desarrolla el producto.

Los bloques de tiempo son: la Reunión de Planificación de la Entrega, la Reunión de Planificación del Sprint, el Sprint, el Scrum Diario, la Revisión del Sprint, y la Retrospectiva del Sprint. El corazón de Scrum es un Sprint, que es una iteración de un mes de duración o menos¹.

Los Artefactos de SRUM son: Product Backlog, Lista de funcionalidades requeridas para la aplicación ordenada de mayor a menor importancia, esta lista no necesariamente debe contener todas las funcionalidades, ya que pueden irse agregando a medida que avanza el proyecto. Sprint Backlog, Del product backlog se toma las primeras funcionalidades, cuya sumatoria del tiempo estimado de C/U no supere el tiempo estimado para todo el sprint, pueden ser descompuestas en tareas y esta lista de funcionalidades es el que se realizara durante el sprint. Carta Burndown o grafica de progreso, muestra la correlación entre el tiempo y el  trabajo realizado.

El texto anterior es extraído del Artículo  DESARROLLO E INTEGRACIÓN DE UNA ONTOLOGÍA Y SISTEMA DE INFORMACIÓN HERBARIO  PARA EL APOYO A LA CARACTERIZACIÓN FLORÍSTICA DE LA ZONA DEL CATATUMBO para ver artículo completo haga clic aquí.

Referencias:
Ken Schwaber y Jeff Sutherland (2008-2011) Scrum. http://www.scrum.org. Pag 5

SCRUM y sus lindas piernas.

En mi corta carrera como desarrollador me he encontrado cara a cara con diferentes metodologías de desarrollo de software tanto pesadas o tradicionales como ágiles pero ninguna llamo tanto mi atención como SCRUM.  Entonces surge aquella pregunta existencial que te eleva sensorialmente a otro lugar tan conocido y tan nuevo a la vez, ¿Porque?, porque llamo mi atención SCRUM? seria por sus lindas piernas o su cabello rubio?; como no quiero cortar tu imaginación tu la puedes o lo puedes imaginar como mejor te parezca. SCRUM es como esa bella chica que tu la miras y es sencilla; tanto que no lo puedes creer, obviamente tiene sus cosas pero que chica no las tiene, y con esto no quiero decir que otras metodología no sean bellas o no cautiven, entre gusto y gusto no hay disgusto dice un adagio popular, pero hablo del mio, del gusto por lo sencillo y lo flexible, por las buenas practicas y la poca documentación, a mi me gusta hacer mas y hablar menos (aunque en este caso seria mejor escribir menos). Definitivamente SCRUM se metió en mi corazón y no es una carta de amor, ella ya sabe que me gusta, es solo que te lo quería comentar quizás a ti también te guste; ella también se comporta como un buen amigo, al que le invitas una cerveza y estará ahí, ella esta aquí y te invito a que la conozcas, habla tu idioma y aquí la puedes conseguir.

Lo mas seguro es que no buscabas tanto dramatismo por eso dejo algo mas técnico aquí.