Este libro lo puedes adquirir en: http://www.javiergarzas.com/recursos-descargas/supervivencia-planificacion-agil
A todos aquellos aquell os que en algún momento conseguimos planific pl anificar ar con éxito un proyecto software soft ware usando prácticas ágiles y que sobrevivimos sobrevi vimos para contar cómo… e inspirar este libro l ibro
De la edición: 233gradosdeTI MARCAS COMERCIALES: las marcas de los productos citados en el contenido de este libro (sean o no marcas registradas) pertenecen a sus respectivos propietarios. wwww.javiergarzas.com y 233gradosdeTI no están asociadas a ningún producto o fabricante mencionado en la obra, los datos y los ejemplos utilizados son ficticios salvo que se indique lo contrario. Se ha puesto el máximo empeño en ofrecer al lector una información completa y precisa. Sin embargo, 233gradosdeTI no asume ninguna responsabilidad derivada de su uso, ni tampoco por cualquier violación de patentes ni otros derechos de terceras partes que pudieran ocurrir. Esta publicación tiene como objeto proporcionar unos conocimientos precisos y acreditados sobre el tema tratado. Su venta no supone para el editor ninguna forma de asistencia legal, administrativa ni de ningún otro tipo. En caso de precisarse asesoría legal u otra forma de ayuda experta, deben buscarse los servicios de un profesional competente. Reservados todos los derechos de publicación en cualquier idioma. Según lo dispuesto en el Código Penal vigente ninguna parte de este libro puede ser reproducida, grabada en sistema de almacenamiento o transmitida en forma alguna ni por cualquier procedimiento, ya sea electrónico, mecánico, reprográfico, magnético o cualquier otro, sin autorización previa y por escrito de 233gradosdeTI: su contenido está protegido por la Ley vigente que establece penas de prisión y/o multas a quienes intencionadamente reprodujeren o plagiaren, en todo o en parte, una obra literaria, artística o científica. Fotolia (www.fotolia.com) o a quién esta se los haya otorgado,tiene los derechos de autor de la foto publicada como portada de la obra. ISBN: 978-84-616-5733-9 Versión: 1.0
Sobre el autor JAVIER GARZÁS PARRA
[email protected] twitter: @jgarzas web: www.javiergarzas.com
Cursó estudios postdoctorales y fue investigador invitado en la Universidad Carnegie Mellon (Pittsburgh, EE.UU). Doctor (Ph.D.) (cum laude por unanimidad) e Ingeniero en Informática (premio extraordinario). Actualmente trabaja como consultor y CIO en la empresa KybeleConsulting S.L. (empresa spin off del grupo de investigación de la Universidad Rey Juan Carlos)y es profesor en la Universidad Rey Juan Carlos. Edita el blog www.javiergarzas.com. Cuenta con certificaciones de Auditor Jefe de TICs (Calificado por AENOR) para ISO 15504 SPICE – ISO 12207, Auditor ISO 20000 por ITSMF, especialización en Enterprise Application Integration (premiado por Pricewaterhousecopers), CISA (Certified Information Systems Auditor), CGEIT (Certified in the Governance of Enterprise IT) y CRISC (Certified in Risk and Information Systems Control) por la ISACA, CSQE (Software Quality Engineer Certification) por la ASQ (American Society for Quality), Introduction CMMI-Dev y Acquisition Supplement for CMMI v1.2 (CMMIACQ) e ITIL V3 Foundation. Ha trabajado para más de 70 organizaciones como INFORMÁTICA DE LA COMUNIDAD DE MADRID (ICM), RENFE, DIRECCIÓN GENERAL DE TRÁFICO (DGT), MINISTERIO DE ADMINISTRACIONES PÚBLICAS (MAP), SISTEMAS TÉCNICOS DE LOTERÍAS (STL), AENOR, etc. Comenzó su carrera profesional como consultor senior y responsable del centro de competencias en ingeniería del software de ALTRAN, desde donde participa en proyectos para TELEFÓNICA MÓVILES CORPORACIÓN, INDRA tráfico aéreo o en la automatización de la simulación de la rotativa de EL MUNDO. Más tarde fue responsable de calidad software y de proyectos de mCENTRIC. Posteriormente, DIRECTOR EJECUTIVO Y DE INFORMÁTICA de la empresa de desarrollo de ERPs para la gestión universitaria con mayor número de clientes en España. Experto en gestión y dirección de departamentos y fábricas software (realizando implantaciones de fábricas y mejoras en España, Colombia, Chile y Venezuela), con una amplia experiencia en ingeniería del software, calidad y mejora de procesos (participación en la mejora, evaluación o auditoría de procesos CMMI o ISO 15504 en más de 40 empresas).
Ha participado en numerosos proyectos de I+D nacionales e internacionales, ponencias, editado varios libros (destacando el primer libro en castellano sobre fábricas software) y publicado más de 100 trabajos de investigación. Evaluador de la ANEP (Agencia Nacional de Evaluación y Prospectiva) y experto certificado por AENOR y EQA para la valoración de proyectos I+D.
Prefacio "No serán las especies más fuertes las que sobrevivirán, ni las más inteligentes, sino aquellas que mejor se adaptan al cambio."
-- Charles Darwin
Sobrevivir, anteponerse a duras adversidades usando lo imprescindible, m anteniendo las condiciones físicas y psíquicas. En ocasiones, la complejidad de planificar y gestionar un proyecto software se asemeja a una situación de supervivencia, nos hace enfrentarnos a una situación tremendamente adversa. Frente a una situación de supervivencia, conocer lo imprescindible, técnicas probadas, concretas y prácticas que nos ayuden… esa será la clave de nuestro éxito. Y eso es lo que encontrarás en este libro, una ayuda para sobrevivir, para seguir adelante, para hacert e con la planificación de un proyecto utilizando lo imprescindible y utilizando la agilidad. Aunque hay multitud de libros sobre planificación de proyectos, en este libro encontrarás sintetizadas las técnicas ágiles más prácticas y necesarias para prepararte rápidamente y sobrevivir. Por ello este libro nació con el propósito de no superar las 100 páginas en su versión ebook (150 en papel). El objetivo de este libro es ayudarte a estar preparado lo más rápido posible. Los negocios se mueven hoy a tal velocidad que la necesidad de planificar un proyecto software en ocasiones llega casi sin avisar, dejándonos el tiempo justo para prepararnos, y para ello necesitarás tener localizadas técnicas prácticas y probadas, aquellas que son fruto de la experiencia, aquello que realmente puede salvarte. Y por si fuera poco, junto a la velocidad cada vez mayor de los negocios de base tecnológica, cuando ya muchas empresas empezaban a conocer la planificación software de proyectos tradicionales, en los últimos años irrumpe, fuertemente en las empresas, una manera diferente y más eficiente de gestionar proyectos: la agilidad. Seguramente habrás oído palabras como Scrum, ciclos de vida iterativos, puntos historia, historias de usuario, etc., ¿Pero cómo encaja todo para planificar mi proyecto? ¿Cómo ordenar todo? ¿Cómo todo ello me puede ayudar? ¿Qué es realmente práctico y qué no? La respuesta, es uno de los objetivos de este libro. Por último, antes de empezar, recuerda que lo más importante frente a una situación de adversidad son dos cosas: tu actitud frente a los problemas y tu preparación previa. Este libro será tu herramienta imprescindible para la segunda. El resto depende de ti.
CONTENIDO La presente obra ofrece una visión amplia sobre diferentes factores que se deben tener en consideración para la planificación, estimación y seguimiento de un proyecto usando técnicas y métodos ágiles. Y este libro persigue cubrir los siguientes puntos: Cuál es el proceso de planificación ágil y el “roadmap”. Qué papel juega la parte cliente, o el usuario, también llamado “product owner”, en la gestión de un proyecto ágil. Cuánto tiempo debe durar una iteración. Cómo planificar las iteraciones. Cómo estimar un proyecto ágil. Las claves del seguimiento. La selección de los temas incluidos en esta obra se ha basado sobre todo en la experiencia prácti ca del autor, después de haber trabajado en multitud de proyectos ágiles, y a la que se añade el rigor científico, proporcionando una panorámica actual y completa sobre problemáticas y soluciones asociadas a la planificación ágil. La obra consta de 9 capítulos y dos anexos: El primer capítulo introduce el proceso de planificación en un proyecto ágil. En el capítulo 2 analizamos qué es un roadmap y su papel en la planificación. En el capítulo 3 veremos una figura clave y fundamental en un proyecto ágil: el “product owner”; y analizaremos también qué son las historias de usuario. En el capítulo 4aprenderemos a estimar un proyecto con distintos métodos relacionados con la agilidad. En el capítulo 5 veremos cómo planificar las releases. En el capítulo 6 veremos el plan de cada iteración, con ejemplos de cómo dividir historias de usuario en tareas. En el capítulo 7 veremos qué medios usar para poder seguir el avance y la evolución de nuestro proyecto. En el capítulo 8 veremos cómo poder subcontratar nuestro proyecto, que tipos de contratos hay para ello y qué riesgos suponen cada uno. En el capítulo 9 haremos un resumen de conceptos que no podemos olvidar ni confundir. Por último, en los Anexos I y II, puedes encontrar un resumen de Scrum y de FDD, dos metodologías que se mencionan a lo largo del texto, y en los que puedes apoyarte si tienes dudas.
ORIENTACIÓN A LOS LECTORES Nuestro propósito al presentar este libro ha sido dirigirnos a una audiencia amplia que comprende: Desarrolladores, líderes de proyecto, jefes de proyecto, consultores, o auditores. Participantes en seminarios o cursos monográficos sobre agilidad.
Directivos que tengan entre sus responsabilidades el desarrollo y mantenimiento de sistemas así como la subcontratación de este tipo de proyectos. Usuarios avanzados, que tengan interés en adquirir unos conocimientos sobre las técnicas y metodologías más probadas para planificar proyectos. Analistas o consultores que, aun teniendo conocimientos de la materia, quieran abordarla de forma más sistemática.
SOBRE LA TERMINOLOGÍA Desde siempre, la falta de una terminología unificada ha sido un problema en ingeniería del software. El mundo de la gestión de proyectos y el de la agilidad no son ajenos a este problema. Es por ello que esta breve sección pretende aclarar algunas posibles dudas que pudieran generar la terminología usada en este libro. Iteración y sprint. Los ciclos de vida ágiles se basan, principalmente, en iteraciones de cortos periodos de tiempo (semanas). Sprint es el nombre que se le da al concepto iteración en aquellos entornos que usan la metodología Scrum. Otras metodologías ágiles usan de manera general el concepto iteración. En muchos entornos se utiliza sprint como sinónimo de iteración, pero no lo son, ya que el sprint es siempre ágil y la iteración puede o no serlo. Metodología. Es bastante común usar el término metodología a la hora de referirse a las metodologías ágiles. Y, por facilidad de lectura y familiaridad con el mundo real y profesional, durante el texto también se usará principalmente la palabra metodología. Pero siendo rigurosos las metodologías ágiles son más bien meta-metodologías o catálogos de buenas prácticas que deben ajustarse dentro de unas guías a la realidad de cada proyecto. Requisito, especificación de requisitos e historia de usuario. Un requisito es algo que el usuario necesita que se incorpore a un sistema software para resolver un problema o lograr un objetivo. No hay que confundir “requisito” con la especificación de requisitos, que es su descripción, para lo cual hay varias maneras de hacerlo, desde numerosas plantillas, a casos de uso llegando hasta lo más usado en el mundo ágil: las historias de usuario.
OTRAS OBRAS RELACIONADAS Gestión ágil de proyectos software.
Garzás Parra, Javier / De Salamanca, Juan Enríquez / Irrazábal, Emanuel Si no está familiarizado con la agilidad, le recomendamos leer primero este libro, ya que ofrece una visión general e introductoria de qué es la agilidad. Esta obra ofrece una visión amplia sobre diferentes factores que se deben tener en consideración decidir la implantación de métodos ágiles. Y persigue los siguientes objetivos: Presentar de forma clara los conceptos fundamentales relacionados con la agilidad. Dar a conocer las principales metodologías y técnicas.
Esta obra podrás encontrarla en:
http://www.kybeleconsulting.com/libros/
AGRADECIMIENTOS Mi agradecimiento a aquellos con los que he compartido proyectos profesionales, a los asistentes a los diferentes “webinars”, seminarios y conferencias que hemos organizado sobre diferentes aspectos de la calidad software y proyectos ágiles, por habernos transmitido en qué temas debería incidir el libro. Con sus inquietudes han ayudado a clarificarnos qué debíamos dejar claro y qué debíamos enfatizar en esta obra. Por otro lado, me resultaría imposible citar a todas las personas que con sus sugerencias y comentarios han contribuido a que sea posible la realización de este libro (destacando a los lectores del blog www.javiergarzas.com , y sus comentarios de incalculable valor para motivar este libro). Aún así, queríamos destacar la labor de revisión, las sugerencias y los comentarios realizados por: Ana María del Carmen García Oterino y David García, quienes han ayudado en la siempr e complicada tarea de la maquetación, corrección de textos y figuras. A Mariano Minoli y Veronica Bollati, que desinteresadamente han contribuido a que este libro sea lo que es con sus valiosas revisiones de los borradores previos.
Javier Garzás Parra
Móstoles, julio de 2013
Capítulo 1 1. Hoja de ruta del superviviente a una planificación software usando técnicas ágiles
En el año 304 a.C., los habitantes de la isla griega de Rodas, para celebrar su victoria sobre Demetrio, y después de haber logrado repeler el fuerte asedio al que éste sometió a su ciudad, decidieron construir una colosal estatua del dios Helios, estatua que eternamente recordase su victoria. Para la construcción de tal obra, conocida hasta nuestros días como el coloso de Rodas, eligieron a Cares de Lindos, al que los rodios pidieron una propuesta con el coste de construir una estatua de 50 pies (15 metros) de altura. Dado que el precio pedido por Cares para construir la estatua de 50 pies era suficientemente asequible para la ciudad de Rodas, estos le pidieron una segunda oferta, esta vez para un coloso del doble de altura. Cares estimó entonces que una estatua del doble de altura costaría el doble de precio. Y los rodios, rápidamente, aceptaron la propuesta de Cares. No fue hasta el comienzo de la construcción cuando Cares cayó en el error de su estimación: doblar la altura le conllevó ocho veces más materiales, y aquella mala estimación, aquella mala planificación, en aquel “contrato cerrado llave en mano”, le llevó a la bancarrota… y al suicidio.
Los problemas en la planificación han acompañado a la humanidad desde hace muchos años. Antes, principalmente, en la construcción de grandes obras arquitectónicas y, actualmente, en las grandes “obras” de hoy en día… las tecnológicas. Y a esto se une la cantidad de estudios que ya han señalado como los problemas de planifi cación y estimación son los problemas más frecuentes, y con mayor impacto, en proyectos de desarrollo software (McConnell, 2007). Como primera medida para enfrentarnos a una planificación ágil, debemos tener claro las “herramientas” que hay disponibles para ayudarnos con ello, el orden a la hora de hacer uso de ellas y que, dependiendo de la magnitud del software a crear, de su tamaño, del tiempo de proyecto, etc., debemos hacer uso de diferentes niveles de abstracción a la hora de planificar. Veamos todo ello a continuación.
EL ROADMAP Y LOS NIVELES DE ABSTRACCI N A LA HORA DE PLANIFICAR Si el proyecto es grande, lo más normal es que utilicemos hasta incluso tres niveles de planificación, que típicamente en proyectos ágiles son los siguientes: planificación del “roadmap”1, planificación de la creación de una “release”1 y la planificación de cada iteración. Los tres anteriores tienen, cada uno de ellos, diferente nivel de abstracción. El roadmap, que veremos con detalle en el capítulo 2, tiene un objetivo más estratégico; el plan de creación de una release o la planificación de las diferentes iteraciones necesarias para ello, que trataremos en el en el capítulo 5, un objetivo táctico y, finalmente, el plan de la iteración es más operativo, y lo veremos en el capítulo 6. Lógicamente, no siempre haremos uso de un roadmap, y como se comentaba previament e, la necesidad de usarlo vendrá dada por el tamaño del proyecto. En proyectos pequeños bastará con hacer una planificación de la iteración, en proyectos medianos, además de la anterior, añadiremos el plan de release y ya en proyectos grandes aplicaremos un roadmap. La Figura 1 muestra la relación entre estos tres niveles de planificación.
Figura 1. Los tres niveles de planificación en un proyecto ágil Por otro lado, aunque en sí la mayoría de técnicas y buenas prácticas de planificación y estimación aplicables a proyectos ágiles son en esencia similares a las de un proyecto tradicional, incluso más antiguas a la aparición del concepto agilidad, su modo de aplicación difiere, por la propia naturaleza de un proyecto ágil, y por el ciclo de vida iterativo en que se basa. Pero, en cualquier caso, y como en un proyecto tradicional, la mayoría de las decisiones de planificación, la estimación y el ajuste del ciclo de vida, de las iteraciones, etc., vendrá dado, y condicionado, por los requisitos…
LOS REQUISITOS Y EL “PRODUCT OWNER” Es por ello, que en un proyecto ágil el cómo se gestionan los requisitos, las llamadas historias de usuario, y quién es responsable de su elaboración, validación y priorización, el conocido como
“product owner” o representante de los usuarios, juegan un papel crítico en la planificación de un proyecto ágil. Y todo ello lo vamos a ver detenidamente en el en el capítulo3. El papel que juega el product owner es tal que de esta figura depende gran parte la planif icación del proyecto, el plan de iteraciones, su duración, etc... Y, por supuesto… mucha parte del éxito del proyecto depende de él. Entre otros, el product owner es el responsable de los requisitos, normalmente escritos en las llamadas “historias de usuario”, las cuales, una vez disponibles, son estimadas…
LA ESTIMACIÓN En un proyecto ágil no es raro comenzar una iteración con requisitos poco especificados y, sin embargo, necesitamos una estimación para cada requisito…y para el proyecto. Habiendo recogido las necesidades podremos estimar, si bien cómo hacer la estimación va a diferir para cada uno de los niveles de abstracción que vimos anteriormente, los de la Figura 1. En la Tabla 1 podemos ver el horizonte temporal que nos ofrece cada planificación, cómo especificamos requisitos en cada una de ellas, el nivel de abstracción y cómo se estima. Cómo Horizonte Nivel de Método de especificamos temporal abstracción estimación requisitos Semestres Roadmap o incluso Temas años
Release Meses
Epopeyas e historias de usuario
Iteración Semanas Tareas
Estratégico T-Shirt
Táctico
Puntos historia u horas
Horas o Operativo días ideales
Tabla 1. Comparativa de los tres tipos de planificaciones ágiles
Quizás la parte más delicada es la estimación de las historias de usuario, ya que gran parte del éxito
del proyecto dependerá de ello, todo ello lo veremos en el capítulo 4, destacando como para dicha estimación su suele hacer uso de los puntos historia. Teniendo claros los requisitos, las historias de usuario, su priorización y su estimación podremos hacer el plan de las iteraciones…
PLANIFICANDO LAS ITERACIONES El corazón de un proyecto ágil es el ciclo de vida iterativo e incremental con iteraciones cortas, de apenas unas semanas. Pero más allá de esto son múltiples las decisiones que tendremos que tomar y responder a cuestiones como ¿qué temporalidad exacta deberían tener las iteraciones? ¿Un par de semanas? ¿Un mes? ¿Deberían todas tener la misma temporalidad? El capítulo 5 profundiza en todos estos interrogantes. Y una vez resueltos lo anteriores, planificaremos una por una cada iteración, justo antes de que cada una de ellas comience…
EL PLAN DE UNA ITERACIÓN La iteración es ese periodo de tiempo, de apenas unas semanas, que se repite, reiterativamente, en un proyecto ágil, y que cada vez que concluye lo debe hacer dejando listo un producto software “entregable” o “potencialmente entregable” (si es que en nuestro “roadmap” definimos que no se hará un paso a producción al final de todas y cada una de las iteraci ones). Durante la iteración, el equipo de proyecto realizará tareas, comprueba tiempos, etc., en el capítulo 6 hablaremos de ello, que previamente debemos planificar y estimar. Y en ocasiones hará desviaciones, por lo que tenemos que llevar un seguimiento…
EL SEGUIMIENTO Todo proyecto, y los ágiles no iban a ser menos, requiere de un seguimiento, desde que comienza hasta su fin. Un seguimiento correcto nos ayudará a detectar desviaciones y a tomar las decisiones correctas. Y nos anticipará con tiempo si cumpliremos nuestro objetivo de entregar un producto de cierta funcionalidad en la fecha establecida, el capítulo 7 trata sobre ello.
Capítulo 2 2. El Roadmap de un proyecto ágil “En la preparación para la batalla siempre he encontrado que los planes son inútiles, pero la planificación es indispensable”. --Dwight D.Eisenhower “No dejes que los árboles te impidan ver el bosque” -- Refrán español
Usaremos un roadmap (cuya traducción sería hoja de ruta) si gestionamos un producto grande, un producto que va a evolucionar durante muchos años y si los prototipos soft ware que se irán desarrollando no pasarán muy frecuentemente a producción. Una release es una versión más del software, con la particularidad de que es una versión que va pasar a producción, es decir, va a ser usada por los usuarios reales del producto software. Toda versión que desarrollamos no necesariamente es una release, porque no toda versión, ni todo prototi po operativo, se libera o pasa a producción. La Figura 2 muestra varias releases en el tiempo, y varias iteraciones. Nótese como las releases no siempre tienen la misma temporalidad y como, normalmente, las iteraciones si la tienen. Al final de cada iteración de desarrollo se obtiene un prototipo con funcionalidad, y solo algunos de estos prototipos se convierten en release.
Figura 2. Releases e iteraciones en el tiempo
En el roadmap reflejaríamos el conjunto de releases (pasos a producción) que prevemos que se van a realizar de nuestro producto. Estas previsiones pueden tener un alcance de semestres o años (Pichler, 2012).
El roadmap ocupa un nivel estratégico y su objetivo es coordinar a las diferentes áreas de la empresa: ventas, marketing, desarrollo, etc.
El roadmap es un plan de alto nivel que describe cómo el producto va a ir evolucionando en el futuro. Normalmente, como mínimo, un roadmap ágil (o no ágil) contiene versiones de producto, Utiliza un roadmap si fechas previstas de lanzamiento y funcionalidad - Quieres tener una visión a largo alcance de las a alto nivel. Por ejemplo: versiones, estratégica, y de la funcionalidad que se va a ir pasando a producción (se va a poner a disposición de los usuarios reales). v 2.5, prevista para el último trimestre de 2012, implementará la firma electrónica. - Si tu negocio / tipo de software / organización no posibilita pasos a producción frecuentes. v 3.0, prevista para el segundo trimestre de 2013, implementará la integración con SAP. Un roadmap tiene varios beneficios, pero principalmente permite comunicar, mostrar y reflexionar sobre el futuro del producto. 2.1. Los temas
Para definir los objetivos de las release, usamos los denominados “temas”. Por ejemplo, decir que en la release 3 afrontaremos “la afiliación de usuarios a nuestro portal” es un tema. Así que los temas se usan para recoger necesidades a nivel de roadmap. En la Tabla 2 se pueden ver ejemplos de temas en un roadmap. Los usuarios podrán hacer compras online Los usuarios podrán descargar videos Los jugadores podrán jugar una partida básica Tabla 2. Ejemplos de temas en un roadmap Un tema no deja de ser una frase que marca el objetivo de la release. ¿Qué razones pueden llevarnos a decidir qué los pasos a producción no deban ser al final de cada iteración?
Algunos ejemplos: - Mi software depende o se integra con el software
de un tercero, y antes de pasar a producción es necesaria una fase de integración. - Razones estratégicas o comerciales, en ocasiones no interesa que los competidores vean las nuevas funcionalidades. - Entornos en los que sólo puedo hacer un paso a producción, p.e., sistemas empotrados, embebidos, firmware, el software del ABS de un choche, etc. - Software crítico, sanitario, militar, etc., que requiere de muchas y exhaustivas pruebas, para las que incluso se puede destinar un tiempo mayor al de una iteración de desarrollo
2.2.¿Cuánto tiempo debe transcurrir entre releases?
Dos factores suelen determinar el tiempo que transcurre entre una release y otra: Razones de negocio. Limitaciones organizativas y técnicas. Aunque normalmente el roadmap planifica releases a meses, hay empresas que optimizan su ciclo de trabajo para hacer pasos a producción incluso diarios. Hay casos de estudio populares, como por ejemplo los de Flickr o Quora. Según comentan en Quora, en un día normal, realizan 46 pasos a producción, necesitando de media tan solo de seis a siete minutos para pasar un cambio a producción (Quora, 2013). Otras organizaciones necesitan semanas para hacer un paso a producción de un pequeño cambio el software, y cuando esto sucede puede deberse a que el proceso es demasiado burocrático, o poco automatizado, o que negocio, sistemas y desarrollo están poco compenetrados.
Si tu organización tarda semanas en pasar a producción un cambio en solo una línea de código… puede que se esté haciendo demasiado lenta y burocrática, perdiendo oportunidad de negocio
El problema viene cuando la organización pierde por ello competitividad, ya que alarga mucho el tiempo en validar versiones del producto con el usuario real, y con ello en adaptar futuras versiones a las necesidades reales del usuario. La disciplina que trata con el objetivo de hacer mínimo el tiempo desde que se decide pasar a producción hasta que el software está listo es el “continuous delivery”. 2.3.“Continuous delivery” y “DevOps”
La entrega continua o “continuous delivery” es el proceso de poder liberar soft ware rápidamente (con la seguridad de que no va a producir problemas en producción), lo cual se basa en tener gran parte del proceso automatizado, disponer de buenas pruebas, y de que los departamentos de desarrollo, sistemas y negocio trabajen como uno. Las ideas de continuous delivery aparecen con fuerza en 2010, cuando apareció el libro Continuous Delivery, de Jez Humbley y David Farley(Humble & Farley, 2010), que trat a las técnicas para poder crear un flujo continuo de versiones software listas para pasar al entorno de producción de manera segura, sin defectos ni sustos. La entrega continua, el continuous delivery, es la evolución natural de la “integración continua”, que se basa en integrar el software (compilarlo y probarlo) automáticamente lo más frecuentemente posible, y así poder detectar fallos cuanto antes. El proceso de integración continua se basa en obtener los fuentes desde el gestor de versiones
(Subversion, Git, Plastic u otros) compilarlo y lanzar las pruebas. Todo este proceso suele automatizarse con herramientas de integración continua como Jenkinso similares que, a su vez, se basan en que la secuencia de compilación, despliegue, etc., esté “escri ta” y se lance con motores como Maven, Ant, Msbuild, Mkfile u otros similares. La entrega continua no implica necesariamente que tengas que hacer muchos pasos a producción. “continuous delivery” no es “continuous deployment”. El continuous delivery pretende que podamos pasar a producción cuando queramos, rápidamente, que cuando decidamos pasar a producción sea en poco tiempo. El momento y frecuencia en pasar a producción lo decide el negocio, pero cuando se decide pasar… la puesta en producción debe ser lo más rápida posible. La entrega continua consiste en olvidar que el software se construye como una actividad separada de explotación, producción, operaciones, o similares, y que el software esté siempre listo para el lanzamiento. En relación a esto, en los últimos años aparece el término DevOps (development + operations, es decir, desarrollo + operaciones) para reflejar la máxima colaboración e integración entre desarrollo software y operaciones (producción, explotación, sistemas, etc., según la terminología). El objetivo de DevOps, romper la típica separación entre estas dos áreas. Por ejemplo, un caso de estudio de DevOps es lo que en su momento logró Flickr: tal integración entre desarrollo y operaciones que hacían… ¡diez pasos a producción por día! Aunque la idea es antigua, el término “DevOps” como tal se popularizó en 2009, debido a los “DevOpsDays” de Bélgica, que luego se han repetido en varios países. DevOps y la “entrega continua” son la extensión de la agilidad y el Lean al área de Operaciones. Con todo, y como citaba Mary Poppendieck (Poppendieck & Poppendieck, 2006): “How long would it take your organization to deploy a change that involves just one single line of code?” Pregúntate si ese tiempo es razonable y si te está haciendo ser cada vez menos competitivo. 2.3.Estimación con T-SHIRT
Algunos equipos utilizan la unidad de estimación llamada T-shirt (la traducción al castellano sería camiseta), cuyos valores van, asemejando tallas de camisetas, desde “pequeña”, “mediana”, “grande” o “súper grande”, o S, M, L, XL y XXL. Esta unidad suele usarse en estimaciones muy tempranas y para medir grandes requerimientos, con poco nivel de detalle, por ello suele usarse para estimar el tamaño de los “temas” que definen una release. Como podemos ver el ejemplo de la Tabla 3 , a los diferentes temas del proyecto se les asigna un tamaño que se mide en T-Shirt. Su principal objetivo es que rápidamente se realice una estimación, que puede dar una idea a clientes,
usuarios, del esfuerzo que requerirá cierta funcionalidad. Pero tiene el problema de ser un método con alta probabilidad de error.
Temas
T-SHIRT
Los usuarios podrán hacer compras online
XXL
Los usuarios podrán descargar videos
XL
Los jugadores podrán jugar una partida básica L
Tabla 3. Ejemplos T-SHIRT
Capítulo 3 3. "Product owner” y las historias de usuario “El rol del product owner es una función nueva y disruptiva para la mayoría de las organizaciones, y por ello no es fácil de cubrir con otros roles y estructuras existentes.”
-- Roman Pichler El “product owner”2(o propietario del producto) es aquella persona con una visión muy clara del producto que se quiere desarrollar, que es capaz de transmitir esa visión al equipo de desarrollo y, además, está altamente disponible para transmitirla. El product owner también es el responsable de la comunicación entre equipo y usuarios, y de gestionar qué trabajo se tiene que desarrollar, en qué orden y qué valor se va entregando. Normalmente, y según lo anterior, el product owner suele ser uno de los futuros usuari os del sistema, o a veces, alguien de marketing o cualquier persona que entienda lo que quieren los usuari os, el mercado del producto, la competencia, y el futuro del sistema en desarrollo. La figura del product owner es clave en un proyecto ágil, en su planificación y seguimi ento. Es una figura que cuando no realiza correctamente su función el proyecto tiene un serio riesgo, y problema, llegando incluso a dejar de ser ágil, o incluso dejando de ser proyecto. Desgraciadamente, es frecuente encontrar implantaciones erróneas alrededor de este rol. En unas ocasiones sus tareas se minimizan, en otras suelen pasarse por alto muchas de sus importantes responsabilidades, etc. El product owner es responsable de la mayor parte de la planificación de un proyecto ágil. No es un ente pasivo que se limita a decir qué hay que hacer. Debe ser consciente de ello y estar preparado… si queremos terminar con éxito un proyecto ágil.
Quizás el papel más importante del product owner en la gestión de un proyecto ágil es gestionar qué historias de usuario se desarrollarán, en qué orden y cuáles no. La mayoría de las ocasiones, el negocio, los usuarios, etc., van proporcionando una cantidad de ideas a
implementar, que se van convirtiendo en historias de usuario, muy superiores en número (ver capítulos de velocidad ( 4.7 ) y de historias de usuario ( 3.5 ) ) a las que el equipo es capaz de desarrollar en una iteración. La función del product owner aquí es vital, ya que conociendo la velocidad del equipo (que veremos en el punto 4.7 , ) debe ser quien decida que historias de usuario entran en el product backlog, cuáles no, y además la prioridad de las historias del product backlog. Habitualmente, en un proyecto ágil, para la gestión y priorización de lo que se espera que haga el product owner se usa el “product backlog” (en terminología Scrum), que es un repositorio priorizado de funcionalidades (normalmente en formato de historia de usuario) a ser implementadas por el equipo de desarrollo, que veremos con más detalle en el Capítulo 3.5. 3.1.Los tipos de Product Owner
No hay dos empresas software que utilicen igual el rol del product owner. Existen múltiples maneras de implantar la figura del product owner. Esto varía enormemente en función de si el equipo está desarrollando un software comercial, software para uso interno, software empotrado, el equipo es interno o externo, o algún otro tipo de producto. La clave es que la persona que ejerce el rol del product owner tiene que tener una visión clara de lo que se va a construir y las prioridades. Pero, aun así, hay dos tendencias principales en lo que refiere a tipos de product owners: aquellos en los que el usuario o el cliente toma el rol de product owner o aquellos en los que una persona que representa al cliente es la que toma el rol de product owner.
3.1.1.Cuando el cliente es e l product owner
En esta situación, el cliente o el usuario final, toma el rol de product owner; dirige y controla el desarrollo del software directamente. Esto acelera la toma de decisiones y aumenta la posibilidad de crear un producto que responde a sus necesidades. El problema, muchas veces, viene de que el cliente debe estar altamente disponible, cualificado para esta tarea y con ganas de que se desarrolle un producto de éxito. Cliente y equipo deben desarrollar una relación estrecha y de confianza. Pero muchas veces, en esta situación, sobre todo cuando el proveedor es externo, no es tan fácil, ya que suelen aparecer diferentes intereses. En proyectos tipo “llave en mano” o cerrados, muchas veces el proveedor de desarrollo quiere terminar cuanto antes y el cliente obtener la máxima funcionalidad.
3.1.2.Cuando un representante del cliente toma el ro l
Esta es una de las estrategias más comunes, que sea un representante del cliente el que tome el rol de product owner. Así trabajan normalmente las empresas que desarrollan software a medida o “llave en mano”, y con proveedores externos (y métodos ágiles, claro). Uno de los problemas de los product owners es la dedicación que requiere este rol, ya que en los proyectos ágiles la figura del product owner debe estar altamente disponible para el equipo, y esto no es siempre posible. Para ello, si el cliente no tiene mucha disponibilidad, muchas veces asigna una persona totalmente dedicada a representarle. Otras veces también ocurre que el software es para varios clientes, y un único product owner suele actuar como representante de los mismos, escuchando ideas y necesidades de varios clientes y usuarios, y decidiendo cuándo estas debieran implementarse. En esta situación, en la que un product owner representa al cliente, son gerentes, comerciales, o analistas de negocio los que suelen tomar este rol. Lo que no quita que muchas veces, junto con el product owner, los clientes y usuarios participen en reuniones puntuales con el equipo de desarrollo, como, por ejemplo, aquellas para revisar las entregas. El reto en esta estrategia es lograr tener un product owner con conocimiento funcional y la confianza y apoyo de clientes, usuarios o directivos, así como la capacidad de poder tomar decisiones. Por problemas como los anteriores, este tipo de implementación del product owner es criticada en ciertos foros más puristas, pero el mundo real es el mundo real, y esta segunda tipología se observa cada vez más.
3.1.3.El product owner y el product manager
Muchas empresas eligen a la figura del “product manager” como “product owner”. Aunque existe cierto debate sobre si son lo mismo, si son compatibles, etc., en nuestra experiencia, esto es frecuente, válido, y suele funcionar, siempre y cuando se tenga en cuenta que el product manager suele hacer más cosas que el product owner, como definir estrategias de mercado, marketing, estrategias de precios, análisis de competitividad, etc. Si se da el caso de equiparar el rol del product manager con el rol del product owner, hay que tener en cuenta que en esta situación dicho product manager debe realizar sus funciones de manager, además de las funciones de product owner, es decir, lleva a cabo más actividades que un product owner convencional. Por ello, estas tareas “adicionales” que realiza en este caso esta figura, frente a un product owner convencional, no deben ser un obstáculo para sus responsabilidades como product owner con el equipo de desarrollo ágil, donde debe definir funcionalidades del sistema futuro, priorizar, validar, etc.
3.2.Responsabilidades de un product owner
A modo de conclusión, hemos sintetizado en 7 puntos las responsabilidades más destacadas de un product owner y que se puede ver en la Tabla 4. Responsabilidades del product owner 1. Escribir buenas historias de usuario. 2. Decidir qué construir… ¡y qué no! 3. Fijar criterios de aceptación para cada historia de usuario. Validar entregas. 4. Definir “productos mínimos viables”. 5. Priorizar historias de usuario, y para ello tener claro el valor de las mismas y el valor que necesita el producto en cada momento (que diferirá a lo largo de la vida del producto). 6. Estar accesible, y disponible, para explicar al equipo técnico dudas funcionales. 7. Definir el plan de releases (o la visión estratégica). Tabla 4. Responsabilidades del product owner
3.3.Historias de usuario
La historia de usuario es la manera más común de tomar requisitos en un proyecto ágil. Normalmente las historias de usuario siguen el siguiente formato: “Como [rol o tipo de usuario], [quiero | podré | seré capaz | necesitaré |…] con el beneficio de…” Muchas veces las historias de usuario suelen escribirse en “post-it” o tarjetas, aunque son mucho más que eso. Una historia no es sólo una descripción de una funcionalidad en un post-it, una historia de usuario además está formada por otras dos partes no físicas (Jeffries, 2001): La conversación que conllevan, ya que son una herramienta para interactuar. El cómo se confirma su implementación, las pruebas y verificación de la misma. Las historias de usuario muestran la funcionalidad que será desarrollada, pero no cómo se desarrollará. Por ello, cosas como que “el software se escribirá en C++” no es una buena historia de usuario. Además de las historias de usuario, podemos hacer uso de las epopeyas. Una epopeya es una historia de usuario más grande, de
Sin buenos requisitos, sin buenas historias de usuario,
mayor funcionalidad que sigue el mismo formato que una historia de usuario pero su alcance es mayor. Las epopeyas recogen objetivos de alto nivel, objetivos de carácter más estratégico.
la planificación de tu proyecto tendrá más riesgo, y será menos exacta.
Normalmente las epopeyas se dividirán en historias de usuario, que son más manejables y más pequeñas, ya que realizar una epopeya nos podría llevar más de una iteración o sprint (Tabla 5).
Epopeya
Como usuario, quiero comprar artículos.
Historia de Usuario
Tareas para implementar una historia de usuario
Como usuario, quiero seleccionar el artículo a comprar
Diseño de la historia Implementación Pruebas Aceptación Demo Refactorización
Como usuario, quiero seleccionar las … unidades Como usuario, quiero seleccionar la ... forma de pago Como usuario, quiero seleccionar la … forma de envío Tabla 5. Epopeyas, historias de usuario y tareas Otra manera de comprender la división anterior es ordenándolas por incertidumbre, de mayor a menor (Tabla 6).
Requisitos
Grado de incertidumbre
Tema
++++
Epopeya
+++
Historia de usuario
++
Tareas
+
Tabla 6. Requisitos por orden de incertidumbre
3.3.1.Cre ando buenas historias de usuario
Como habrás podido apreciar en la sección anterior, las historias de usuario son un elemento fundamental en un proyecto ágil y, obviamente, van a ser claves para su planificación y estimación. Y es por ello que esta sección recoge algunas claves y buenas prácticas a la hora de crear hist orias de usuario. Una historia de usuario recoge una funcionalidad mínima. Por ejemplo, según la metodología ágil “extreme programming”(Beck & Andres, 2004), una historia de usuario es “la unidad más pequeña posible de valor para el negocio”. Las historias están pensadas para conversar, por ello son concisas y mínimas, para recordarnos sólo lo que hay que añadir al software. No son especificaciones de requisitos software. Si el texto no cabe en la tarjeta en la que se escribe la historia de usuario es porque hay que dividirla en varias, o porque tiene información no relevante. En este sentido, las historias deberían completarse en una iteración, no necesitar más de una para ello. Existe cierto debate sobre si una historia de usuario puede o debe tener un enlace, trazabilidad, a otros documentos de soporte donde se amplía información sobre cómo implementarla: por ejemplo una norma de seguridad, políticas internas, las reglas corporativas en interfaces de usuario, etc. A pesar del debate, este es un recurso muy utilizado por muchos equipos para mantener información de respaldo sin agrandar las historias de usuario. Para lograr esta trazabilidad, suelen añadirse a la historia identificadores de otros documentos de soporte. Esto puede hacerse a mano o utilizar herramientas.
Las historias de usuario (ejemplo en la Figura 3) deberían ser escritas por el usuario o por el product owner (ver epígrafe 3), ya que es el usuario realmente quien sabe lo que necesita.
Figura 3. Ejemplo de historia de usuario Por último, cada historia de usuario debería tener una prueba de aceptación, que debería realizarse durante la iteración (evitando hacer una fase final, separada, sólo para pruebas).
3.3.2.El valor de una historia de usuario
Claramente, uno de los principales objetivos de un product owner es que se entregue el mayor valor al cliente o usuarios. Y esto en ocasiones es un gran reto. El concepto “valor” de una historia de usuario no tiene una única definici ón, sino que depende del producto, del momento etc. El product owner debe definir el valor de cada historia de usuario. El valor que cada historia aportará al usuario final depende de cada producto, organización e incluso cambia según avanza la vida del proyecto – producto software
Un buen product owner debe manejar eficientemente cómo aportar el mayor valor posible. Y para ello debe manejar el orden de las historias que deben ser implementadas, ordenando su implementación de mayor a menor valor. Como se muestra en la Figura 4, normalmente, al comienzo del proyecto, por desconocimiento de lo que realmente el usuario necesita, los product owners pueden pedir al equipo técnico que implemente historias de usuario que pueden no aportar mucho valor, pero que son necesarias para explorar lo que los usuarios realmente quieren.
Posteriormente, con las cosas más claras, vendrá la fase en la que el producto irá aportando cada vez más valor a los usuarios. Finalmente, habiendo cumplido las mayores necesidades, el producto entrará en mantenimiento, o en la incorporación de pequeñas funcionalidades o ajustes (Kniberg, 2012).
Figura 4. El valor que el product owner quiere entregar al cliente Por otro lado, la principal responsabilidad del product owner es que se construyan las cosas correctas, será responsabilidad del equipo técnico construirlas correctamente. Para saber qué valor tiene una historia de usuario, la manera más simple es poner un número a cada historia de usuario. A número mayor, mayor será el valor también. Hay técnicas que ayudan a ello. Como las que veremos a continuación.
3.4.Técnicas para priorizar y dar valor a las historias de usuario
Normalmente, la priorización de requisitos, historias de usuario, etc., viene dada por el valor que estas aportan al cliente o al negocio. A mayor valor, mayor prioridad. Aunque dicho así, el concepto “valor aportado” queda bastante ambiguo y se puede dar a cientos de interpretaciones. Es por ello deseable acotar y formalizar cómo se hace la priorización y en base a qué factores. Como es lógico, no existe un criterio universal para dar valor, priorizar historias de usuario o requisitos, depende de cada negocio. Si bien es importante que cada equipo fije l os criterios por los cuales hará la priorización. En cualquier caso, es bastante frecuente observar tres parámetros principales a la hora de determinar el valor de cada requisito (Cohn, 2005): - Rentabilidad de incorporar el requisito. - Coste de incorporar el requisito.
- Cantidad de riesgos que minimizará la incorporación del requisito. En muchas ocasiones, los anteriores suelen combinarse con algunas técnicas para determinar la necesidad de incorporar al producto un nuevo requisito. Las dos técnicas más populares en este sentido son el modelo Kano y la técnica MoSCoW.
3.4.1.Modelo Kano
El modelo Kano, de los 80, se utiliza para clasificar y priorizar requisitos en función de lo que satisfarán al usuario. En el caso de los proyectos ágiles, el modelo Kano suele usarse para priorizar la lista de funcionalidades o de historias de usuario. Según el modelo Kano, hay cuatro tipos de atributos del producto: - Requisitos obligatorios (básicos). Necesidades básicas. Atributos que esperan los clientes y conducen a la insatisfacción extrema si están ausentes o mal satisfechos. Por ejemplo, “que pases a un bar, pidas una caña, o una coca cola, y te la pongan. Que pidas una caña y te la pongan no hace mejor al bar, pero que la pidas y no te la pongan te enfadaría”. - Necesidades (esperado,lineal). Atributos que bien realizados conducen al incremento lineal de la
satisfacción del cliente. Fuente de satisfacción, y necesarios de priorizar a la hora de implementarlos. Por ejemplo, “que te pongan la caña, o coca cola, rápido, con una sonrisa y una tapa”. - No esperados (inesperado, excitante). Atributos atractivos, generalmente inesperados por los
clientes y que puede resultar en una gran satisfacción si están disponibles. No suelen ser una prioridad. Son innovación. Por ejemplo, que “el bar tenga wi-fi”, etc. Pregúntate si no se estará quedando tu producto sólo en cumplir necesidades y aspectos básicos y est ará tu competencia trabajando en requisitos inesperados. - Indiferentes. El cliente no está interesado en ellos.
El uso del modelo Kano se basa en clasificar los requisitos según los anteriores tipos y así priorizarlos, en función de la etapa en que se encuentre tu producto.
3.4.2.Técnica MoSCoW
La priorización o análisis MoSCoW es otra técnica usada para comprender la importancia que tiene para los usuarios la implementación de un requisito o funcionalidad. La técnica MoSCoW recibe su nombre de las cuatro categorías en que puede clasificarse un requisito.
Estas cuatro categorías son, en inglés: M, Must (obligatorio), S, de Should (debería), C, de Could (podría), y W, de won’t (no necesario). Las letras “o” en el nombre se añaden simplemente para mejorar la pronunciación y que además el nombre de la técnica coincida con “Moscú” en inglés. MoSCoW fue creada por Dai Clegg de Oracle UK, en el 94, y ha sido muy popularizada por el grupo Dynamic Systems Development Method (DSDM). Concretamente, los cuatro tipos en que se clasifican los requisitos son los siguientes: M - Must (Debe incluirse). Requisitos de prioridad alta, que deben ser satisfechos para que el
desarrollo pueda considerarse un éxito o incluso lanzar el producto. S - Should (Debería incluirse). La funcionalidad no es crítica, pero si importante y deseable. C - Could (Podrá incluirse).Requisitos deseables pero no estrictamente necesarios. W - Won’t (No incluir). Requisitos de los que se tiene claro no implementar, aunque en un futuro podrían reconsiderarse.
3.5.El product backlog y los mapas de historias
La colección de historias a incorporar en un producto de software se conoce como product backlog o pila de producto. El product backlog contiene historias priorizadas, normalmente, las que están en un lugar más alto son las que tienen mayor prioridad. Esto lo podemos ver en la Figura 5. El término product backlog es originario de la metodología Scrum, aunque su uso se ha a generalizado a otras metodologías ágiles o solo iterativas. Hay que tener en cuenta que el nombre de “pila” de producto puede inducir a error, ya que las pilas de producto no siguen una estructura típica del concepto pila en informática, es decir, LIFO o Last In First Out, (último en salir primero en entrar).
Figura 5. Product Backlog Un mapa de historias de usuario es una manera complementaria de priorizar y complementar un product backlog (Patton, 2008). Hay muchas maneras de organizar un mapa de historias de usuario, aunque generalmente, se suele hacer como se muestra en la Figura 6.
Figura 6. Mapa de historias de usuario En el nivel superior se colocan las epopeyas. Debajo de cada una de ellas las historias de usuario en que estas se descomponen. Las epopeyas se colocan de izquierda a derecha en función del orden de uso del sistema, o de cómo explican mejor qué debe hacer el sistema. A su vez, las historias de usuario en que se descompone cada epopeya se ordenan de arriba abajo en función de su prioridad. Finalmente, se pueden agrupar historias de usuario en releases usando líneas horizontales. Hay muchas maneras de hacer un mapa de historias de usuario, e incluso algunos usan terminología diferente (en ocasiones en vez de usar la palabra epopeya se usa la palabra actividad, si bien en esencia la idea es la misma). Para concluir, las ventajas de un mapa de historias frente a un product backlog son que: Deja más clara la cadena de valor. Muestra la relación entre historias de usuario grandes y pequeñas. Aporta un contexto.
3.5.1.Relación entre el Roadmap y el Product Backlog
Si se aplica correctamente, el roadmap y el product backlog se complementan muy bien. Aunque antes de crear un roadmap ágil, debes saber si puedes predecir cómo evolucionará en el futuro el producto, con cierto grado de certeza. Y vas a necesitar roadmap si gestionas un producto grande. El roadmap ágil contiene la planificación estratégica del producto y el producto backlog el trabajo más táctico. El roadmap debería capturar las principales funcionalidades de cada release, mientras que el product backlog se centra en la creación de la siguiente release(Pichler, 2012). El roadmap contextualiza el product backlog. Por ejemplo, se usa para decidir si una nueva característica se debe añadir, o si debe ser incluida en una versión futura. En consecuencia, el uso del roadmap, hace que el product backlog se vuelva más conciso y que contenga menos elementos, siendo más transparente, y más fácil de manejar. Contar con una persona a cargo del roadmap ágil y el product backlog une objetivos estratégicos y tácticos del producto, y establece una clara autoridad y responsabilidad sobre los mismos. Normalmente los roadmaps se crean para productos medianos o grandes, aquellos en los que puedo hacer una previsión de su situación en meses, en 6 o 12 meses por ej emplo. Y cuando normalmente ya hay algunas primeras versiones del producto. Mientras que un product backlog (el típico que se usa en Scrum) es bueno para saber lo que debe estar terminado para lanzar una release concreta, un roadmap permite mirar más hacia el futuro y captar la estrategia de producto, lo que probablemente se implementará en el tiempo. Permite proyectar en el tiempo donde quieres que esté tu producto en el futuro. Como resumen de las diferencias entre la hoja de ruta del producto (roadmap) y el product backlog: - Roadmap ágil: contiene varias releases, su objetivo es planificar el producto, su horizonte suele ser
años, se actualiza cada varios meses, etc. - Product backlog: contiene historias de usuario, su objetivo es el desarrollo de una release, su
horizonte suele ser meses, se actualiza cada iteración, etc.
Capítulo 4 4. Estimando un proyecto ágil “Hacer predicciones es muy difícil… sobre todo si se trata acerca del futuro”
-- Neils Bohr ¿Cuánto tiempo tardarías en ver la serie de televisión “The Big Bang Theory3”? ¿Difícil pregunta? Si yo tuviese que responder a la anterior cuestión, intentaría concretar primero los “requisitos” de la tarea solicitada. Concretamente, qué capítulos o qué temporadas debería ver. Dependiendo de lo claro que tengas los requisitos, la estimación será más o menos exacta. En el mundo de los proyectos software, las estimaciones arrancan de la misma manera: teniendo claros los requisitos. Si no hay requisitos… difícilmente se podrá estimar. Con la particularidad de que en un proyecto ágil, en el que el producto se va construyendo “poco a poco”, los requisitos existen, pero menos especificados que en un proyecto tradicional (abordaremos esta problemática en el punto 4.1). Una vez resuelto el anterior punto, para estimar cuánto tiempo me llevaría ver la serie, sabiendo ya el requisito solicitado, sabiendo los capítulos que me piden ver, intentaría averiguar el “tamaño” de la tarea que tenemos que realizar. Y para ello necesitaré una unidad de tamaño. Supongamos que un cliente me dice que lo que necesita, el “requisito”, es que vea los capítulos 1, 5 y 9 de “The Big Bang Theory”. Ahora puedo empezar a calcular el tamaño, midiéndolo en alguna unidad. En este caso la unidad de tamaño puede ser el “número de capítulos”, en el ej emplo, el tamaño de mi tarea es de 3 capítulos. En software, seguiremos un proceso similar, teniendo claros los requisitos mediremos el tamaño del trabajo a realizar. Claro que en software utilizaremos otras medidas de tamaño y, concretamente, en proyectos ágiles es usual utilizar la unidad denominada “punto historia”, que mide la complejidad, tamaño de cada requisito o historia de usuario. Seguidamente, parece lógico poder calcular el tiempo que nos llevará la tarea. El tiempo de duración de cada capítulo es de 25 minutos. Por lo que ahora puedo aplicar una función de cálculo sencilla, y multiplicar 3 capítulos * 25 minutos, con el resultado de 75 minutos. Y, de nuevo, en el mundo de los proyectos software, el proceso será similar: desde el tamaño obtendremos el tiempo estimado. Si bien, lógicamente, en el mundo del software no será tan fácil como en el de las series, ya que no todos los “capítulos”, requisitos, tienen la misma duración.
En este punto, ¿podría ya decirle al cliente que la tarea encomendada de ver 3 capítulos de la serie me llevaría 75 min.? El ávido lector, seguramente, ya se habrá percatado de lo poco probable que es cumplir con dicho tiempo estimado. Salvo excepciones, que las hay, muy pocos seríamos capaces de estar 75 minutos seguidos, sin parar, viendo una serie. La vida real difiere de las estimaciones. Seguramente iremos al baño, pararemos para descansar, ir a comer algo, nos llamarán por teléfono, etc. Y es por ello que nuestros 75 minutos de “tiempo ideal” tendremos que transformarlos en “tiempo real”, que normalmente será superior. De nuevo, y por último, en software sucede algo similar. El tiempo ideal varía por muchas razones, que van desde el equipo de desarrollo, su experiencia, productividad, preparación, etc., hasta el calendario, las festividades, etc.
4.1.La definición de los requisitos afecta a la estimación
Una regla básica en estimación software es que según avanza el proyecto la estimación contiene menor error, por ello, sería conveniente reestimar periódicamente, según avanza el proyecto, para reajustar la estimación. El porqué de este comportamiento lo explica de manera bastante ilustrativa el llamado cono de incertidumbre (Little, 2006; McConnell, 2006), que refleja (ver Figura 7) cómo las estimaciones son cada vez más precisas, según progresa un proyecto.
Figura 7. Cono de incertidumbre En el cono de incertidumbre, el eje horizontal representa el paso del tiempo, desde la concepción inicial del proyecto, a la especificación de requisitos, diseño, etc. Y el eje vertical contiene el grado del error de las estimaciones en varios momentos en el proyecto. Al principio del proyecto, cuando sólo se tienen requisit os poco especificados, debemos asumir, y ser conscientes, de que el error con el que se trabaja es mayor que cuando se estima teniendo requisitos
detallados, o teniendo ya un diseño o, aplicando todo ello a un proyecto ágil, cuando se llevan ya varias iteraciones. En un proyecto que tiene un ciclo iterativo e incremental (ver capítulo 5), tendremos un mini cono de incertidumbre en cada iteración (Construx Software Builders, 2013), pudiéndose plantear dos situaciones.
Sin requisitos, sin historias de usuario, o con requisitos muy vagos... el error de la estimación será muy alto
La primera, en la que los requisitos, que como vimos en la sección 3.3 se basan en historias de usuario, se detallan en cada iteración, y la segunda, en la que primero se detalla una gran cantidad de requisitos y luego se itera. Las empresas deben priorizar entre la flexibilidad de la primera opción o preferir la mayor previsibilidad de la segunda, para algunos…menos “ágil”. Veamos ambas opciones con mayor detalle.
4.1.1.Definir las historias de usuario sólo al comienzo de cada iteración
Debido a lo ambiguo de los requisitos, nos moveríamos, en cada iteración, al principio, en la parte de mayor error del cono de incertidumbre tal y como se puede ver en la Figura 8.
Figura 8. Cono de incertidumbre en proyectos sin fase previa de requisitos Esto, claramente, penaliza la previsibilidad a largo alcance, nos movemos en cada iteración en un cono de incertidumbre con alto error, aumentando el posible error en costes, calendario, y la funcionalidad. Pero crea proyectos más flexibles, proyectos que no invierten tiempo en especificar detalladamente grandes cantidades de requisitos, quizás porque no se conocen, no se sabe su viabilidad, si el cl iente los requerirá, etc. Metodologías como Scrum proponen ciclos de vida más cercanos a este tipo de planificación.
4.1.2.Detallar primero todos los requisitos y luego itera r
Otros proyectos definen la mayoría de los requisitos al principio, y una vez definido el total, o la mayoría de los requisitos, las iteraciones cubren las fases de diseño, construcción, y pruebas (Figura 9).
Figura 9. Cono de incertidumbre en proyectos con fase previa de requisitos En otras palabras, el proyecto se mueve secuencialmente, en cascada, en la definición de requisitos, y luego cambia a un enfoque iterativo a partir de ahí. Esta segunda opción soporta mayor previsibilidad a largo alcance, de costo y temporalidad, así como una cantidad moderada de flexibilidad de requisitos. Metodologías como FDD (ver ANEXO II. FDD) utilizan este enfoque. En ocasiones, los equipos que usan Scrum añaden el mencionado sprint cero (ver punto 5.4) para relajar la agilidad y utilizar esta estrategia.
4.2.Los puntos historia
Históricamente, la unidad clásica de estimación del “tamaño” de un requisito ha sido el Punto Función. Pero, en los últimos años, los puntos historia se han convertido en una unidad de tamaño muy usada, principalmente en proyectos ágiles. Cualquier medida del tamaño, bien sean puntos historia, puntos función, puntos casos de uso, o cualquier otra, parte de los requisitos para calcular el tamaño del software. Estos requisitos pueden
venir dados en diferentes formatos, más o menos detallados o especificados. Formatos que pueden ir desde un documento, a un pliego pliego de descripciones técnicas, técni cas, casos de uso o, como suele ser habitual en proyectos ágiles, historias de usuario. La Tabla 7 recoge una una síntesis de métodos de estimación, estim ación, la unidad de tamaño que usan y en qué están basados estos métodos.
Método Mét odo de d e estimación estimación Unidad típica típica de tamaño Cara Caracter cteríst ísticas icas
Ju icio Exp erto
Cualqu iera
Exp eriencia in div idu al
Pun to Fun ció n Lite
Pu nto Función
Paramétrico
Pun to Caso d e Uso
Pu nto Caso de Uso
Paramétrico
Plan nin g Pok er
Pu nto Historia
Exp eriencia colectiv a
Analo gía
Cualqu iera
Exp eriencia do cumen tada
Tabla 7. Métodos de estimación, unidad y base
También podríamos ordenar los l os métodos como el T-SHIRT T-SHIRT que ya vimos ( punto punto 2.4) o los que veremos a continuación en función de la precisión precisi ón que presentan como se ve en la Tabla 8.
Método de estimación
Precisión que busca…
Estimación en h oras
+++
Esti Estimaci mación ón en en puntos puntos his histor toria ia ++
Estimación Estimación según tallas T-Shir T-Shirtt +
Tabla 8. Técnicas de estimación ordenadas por precisión
Los puntos historia son una unidad usada, normalmente, para medir el tamaño de una historia histori a de usuario. El número de puntos historia asociados a una historia de usuario representa el tamaño global
de la historia. Más concretamente un punto historia histori a es una fusión de la cantidad de esfuerzo que supone desarrollar la historia de usuario, la complejidad de su desarrollo y el riesgo inherente(Cohn, 2005). A diferencia del punto función, no existe una fórmula para calcular los puntos historia de una historia de usuario. A la hora de asignar puntos historia a cada hist oria de usuario lo que importa im porta son los valores relativos de una historia frente al resto: una historia a la que se le asignan dos puntos historia debe requerir el doble de esfuerzo, complejidad complej idad o tamaño que una historia a la l a que se le asigna un único punto. Y normalmente hay dos formas de hacer esta est a asignación: Seleccionar una historia de las más pequeñas y asignarle 1 punto historia. Esta historia de usuario con 1 punto historia hará de unidad, y al resto se le l e asignarán puntos historia histori a en función de su complejidad respecto a ésta. Seleccionar una historia de tamaño tam año medio y asignarle un número en la mitad m itad del rango de puntos historia a utilizar. Normalmente, se usan rangos de puntos historia entre 1-10. Según esto, buscaríamos una historia de tamaño medio y le asignaríamos cinco puntos historia. Cada historia adicional se calcula comparándola con la primera historia. En cualquier caso, recomendamos el primer método por ser más fácil de aplicar.
4.3.La escala de puntos historia
Varios estudios han demostrado que es mejor estimar est imar usando rangos o escalas de posibles valores valor es que se pueden asignar(Miranda, 2001) a la estimación, estim ación, es decir, fijando fij ando un tope máximo de puntos historia. Según lo anterior, normalmente iremos agrupando historias en puntos historia, como muestra la Tabla 9. 1 punto historia Historia Historia D, Historia Historia B
2 punto historia Historia Historia C, Historia Historia L
3 punto pu nto historia Historia Historia E, Historia G, Historia Historia I, Historia Historia J
5 punto histori h istoriaa Historia Historia F, Historia Historia H
8 punto historia historia Histori Historiaa A
Tabla 9. Ejemplo de asignación de Puntos Historia a historias de usuario
Normalmente, hay dos escalas de puntos historia histori a que suelen tener buenos resultados: 1, 2, 3, 5, 8, etc. 1, 2, 4, 8, etc. La primera escala es la secuencia de Fibonacci, útil porque la separación entre los números de la secuencia se hace más grande a medida que los números aumentan. En la segunda, cada número es dos veces el número que le precede. Estas secuencias no lineales funcionan bien porque reflejan mayor incertidumbre asociada a estimaciones de grandes unidades de trabajo. Además, normalmente, deberíamos limitar los valores de la escala, por ejemplo, a 10 valores.
4.4.La Técnica de estimación “Planning Poker”
El Planning Poker (Cohn, 2005; 2005; Haugen, 2006) 2006) es una técnica que se utiliza utili za para asignar los l os puntos historia a las historias de usuario (ver Tabla 9). Esta técnica recibe el nombre de Planning Poker ya que cada una de las personas implicadas en el proceso de estimación esti mación toma un mazo de cartas cart as que suelen estar numeradas con alguna de las secuencias que vimos vim os antes. Normalmente se siguen los siguientes pasos: 1. Se presentan las historias de usuario a estimar, haciendo una descripción de las mismas y se procede a discutir aquellos aquell os detalles más m ás relevantes o que no hayan quedado quedado claros. Suele darse un tiempo máximo de discusión para mejorar la productividad. 2. Tras este período de discusión, cada una de las personas implicadas impli cadas en el proceso de estimación estimaci ón toma su mazo de cartas y escoge la carta que representa su estimación (el número de puntos historia). 3. Se publican todas las estimaciones, es decir, cada integrante del equipo muestra a la vez la carta seleccionada (esto es así para evitar que las estimaciones de unos modifiquen las de otros). Si existe una gran dispersión entre las estimaciones (unos dicen 2, otros 20) se vuelve al discutir la historia de usuario y se vuelve a realizar el proceso de estimación. 4. Por último, si no existe una gran dispersión, se llega ll ega por consenso a un acuerdo acuerdo en la estimación estim ación de la historia de usuario. Generalmente, la dispersión en las estimaciones es síntoma de que la información que maneja parte de los involucrados en el proceso de estimación esti mación no es completa o exacta. La segunda ronda de discusión permite aclarar aquellos puntos poco claros, diferencias de criterio y desvelar información que pueda no ser obvia sobre la historia para que en la siguiente ronda de estimación, la dispersión de las
estimaciones sea mucho menor y se pueda llegar fácilmente a un consenso.
4.5.¿Puntos historia o estimación en horas?
En el mundo de la estimación y planificación ágil, este es uno de los grandes debates, si usar puntos historia u horas directamente a la hora de planificar (debate que también es de aplicación a cualquier otra medida del tamaño, como los puntos función o los puntos caso de uso). Y al respecto, podemos encontrar opiniones de todo tipo, aunque lo normal es usar “puntos historia” para estimar historias de usuario y horas para estimar tareas (recordemos que las historias de usuario se dividen en tareas). Los puntos historia son útiles a la hora de hacer estimaciones a largo plazo, pero no funcionan muy bien a corto plazo. Como vimos, los puntos historia se usan para asignar "tamaño relativo". Se utilizan series cerradas, por ejemplo la de Fibonacci (1, 2, 3, 5, 8, etc.), porque el objetivo es agrupar cosas de tamaño simi lar en lugar de lograr una estimación muy precisa. Cuando se estima en horas buscamos responder a la pregunta "¿Cuánto tiempo puede llevarnos?". Cuando se estiman en puntos historia buscamos tamaños relativos o la complejidad "¿Cómo es de grande en relación otras?" En la Tabla 10 podemos ver un ejemplo. Historias de Usuario Tareas
“Puntos historia” >
“Horas o días ideales”
Como usuario, … Programar [10 horas] [8 puntos historia]
Escribir Test [5 horas]
Actualizar documentos [2 horas]
Suma = 17 horas
Tabla 10. Ejemplo de relación entre puntos historia y horas
La Tabla 11 muestra una comparativa entre la estimación con puntos historia y la estimación en horas.
Puntos Historia
Horas ideales
Ideal para estimar a medio – largo plazo
Ideal a corto plazo
Se suele aplicar en el product backlog
Se suele aplicar en el sprint backlog
Mide tamaño / complejidad relativa
Mide tiempo de duración
Busca relativizar el tamaño complejidad de una cosa frente a otra Busca exactitud
Tabla 11. Comparativa sobre el uso de puntos historia y horas
Como comentábamos, lo más usual y utilizado es hacer uso de los puntos historia para estimar historias de usuario. Pero siempre queda abierta la opción de estimar historias de usuario directamente en horas. Autores como Kent Beck(Beck & Andres, 2004)recomiendan que una vez que el equipo se ha familiarizado con los puntos historia le será fácil hacer saber a cuánto tiempo equivale cada punto historia, y en ese momento “es preferible trabajar con tiempo real para hacer la comunicación más clara, directa y transparente”. Las principales razones de usar puntos historia frente a horas son: El punto historia es una unidad de mayor error, pero más rápida, lo que posibilita al product owner priorizar el product backlog. Los puntos historia son independientes del equipo de desarrollo, es decir, para el mismo número de puntos historia, dos equipos pueden implementarlos en diferente tiempo. Esto es útil cuando no se sabe quién implementará las historias, o en procesos de subcontratación o licitación de un proyecto ágil.
4.6.¿A cuántas horas equivale un punto historia?
Aunque, como vimos antes, las historias de usuario se suelen estimar en puntos historia, en la mayoría de equipos siempre suele surgir la siguiente cuestión: "entonces, un punto historia equivale 9 horas ¿no?" (cámbiese el 9 por lo que corresponda). Normalmente no hay una relación lineal entre puntos historia – horas (digo relación lineal, no que no exista relación). Es decir, podemos tener dos historias de usuario con los mismos puntos historia pero que su tiempo de realización sea diferente.
Por ejemplo, imaginemos que en nuestro equipo, las historias de 5 puntos historia están en un rango de entre 15 y 30 horas. Por otro lado, el rango de horas en que se mueven las historias de 1 punto historia va a ser diferente al de las historias de 8 puntos historia. Esto significa que la distribución de las estimaciones pequeñas será más exacta que las grandes. Estimar el tamaño de una historia que requiere modificar un texto en una Web debe ser mucho más fácil que calcular el esfuerzo de una historia que requiere cambiar varias tablas de la BBDD. En su blog (Treadway, 2011)hizo un pequeño estudio con los datos de su equipo, recopilando datos de 6 iteraciones y obteniendo el siguiente gráfico de horas estimadas/puntos función. image.033
Figura 10. Distribución de horas estimadas/puntos historia De dicho gráfico se obtienen las conclusiones que ya se comentaron en los párrafos anter iores: no hay una relación o correspondencia exacta entre la estimación en puntos historia de las historias de usuario y su equivalencia a horas, sino que dicha correspondencia se encuentra en un rango de valores. Por ejemplo, si nos fijamos en la gráfica de la estimación de 1 Punto Historia de la Figura 10, nos damos cuenta de que dicho punto historia equivale a un rango de entre 1 y 19 horas aproximadamente, no hay un valor de hora exacto. Por otra parte, también se observa en la gráfica que la estimación de la historia de usuario más pequeña (con un valor de puntos historia menor) es más precisa que la de un valor de más puntos historia, ya que el rango de equivalencia en horas es menor. Como ya se ha comentado, es más sencillo estimar con precisión una historia de usuario pequeña que una grande, la Figura 10 muestra como a un 1 punto historia l e corresponde un valor en un horas que se mueve entre 1 y 19, frente al rango en que se mueven los 8 puntos historia, a los que les corresponden un valor en horas que se mueve entre 11 y 57 horas.
4.7.Refinando la estimación con la Velocidad del equipo
Para entender cómo estimar y planificar un proyecto con puntos historia es útil y necesario conocer el concepto de velocidad, una medida del ratio de avance del proyecto(Cohn, 2005). La velocidad se calcula sumando el número de puntos historia La velocidad media del equipo, de cada historia de usuario terminada durante una iteración del obtenida de datos históricos, es un proyecto (o sprint en terminología de la metodología Scrum). dato de incalculable valor a la hora Ejemplos: de planificar Si el equipo completó tres historias en la iteración, cada una de cinco puntos historia, entonces su velocidad en esta iteración fue quince. Si el equipo completó dos historias de cinco puntos su velocidad fue diez. Si sumamos los puntos historia de todas las historias de usuario a desarrollar tendremos una estimación del tamaño total del proyecto. Y si conocemos la velocidad del equipo, por datos históricos, podremos dividir el tamaño entre la velocidad para llegar a una estimación del número de iteraciones necesarias. En la Tabla 12 podemos ver un ejemplo. Velocidad Iteración o Sprint
(puntos historia completados)
1
45
2
21
3
35
4
44
5
29
Tabla 12. Ejemplo de cálculo de la velocidad media de un equipo
Por ejemplo, supongamos que todas las historias de usuario se han estimado y que la suma de esas estimaciones es de 100 puntos historia. En base a la experiencia previa sabemos que la velocidad media del equipo es de 11 puntos historia por iteración de dos semanas. Ya que 100/11 = 9,1 se puede estimar que el proyecto necesita 9,1 iteraciones, con un enfoque conservador redondeando a 10 iteraciones. Dado que cada iteración es de dos semanas, nuestra estimación de la duración es de veinte semanas. Podemos contar hacia adelante veinte semanas en el calendario y hacer el plan de
proyecto(Cohn, 2005). En cualquier caso, no olvides que cuando hablamos de velocidad hacemos r eferencia a una media. Si necesitas hacer estudios más profundos sobre la velocidad de un equipo, o comparar más fielmente a dos equipos según su velocidad, etc., deberías acompañar la velocidad media de otros valores, por ejemplo, la desviación típica. La Tabla 13 muestra un ejemplo de dos equipos con la misma velocidad media pero en los que la desviación muestra que uno de ellos, el A, es mucho más regular que el otro. Equipo A
Equipo B
10, 11, 9, 10
10,14,9,7
Media: 10
Media: 10
Desviación:0.7 Desviación:2.5
Tabla 13.Ejemplo de dos equipos con la misma velocidad media pero distinta desviación
Capítulo 5 5. Planificando las iteraciones "No seas de una única forma, adáptate y construye la tuya propia, y déjala crecer, sé como el agua. Si pones agua en una taza se convierte en la taza. Si pones agua en una botella se convierte en la botella. Sé agua amigo mío".
--Bruce lee Cuando creamos un “plan de release” nuestro objetivo era planificar y prever qué iba a suceder durante las diferentes iteraciones que se irían sucediendo hasta concluir con una release. Si los roadmap se hacían a semestres o años (planificando varias releases), normalmente el plan de una release se crea para unos pocos meses o semanas. Cada uno de estos planes de release estará formado por el número de iteraciones que consideremos adecuado. Aún así el plan de release no tiene que describir el detalle de cómo se va a trabajar dentro de cada una de las iteraciones que abarcan dicha release, eso lo dejaremos para el plan de la iteración. A la hora de planificar las releases haremos uso, para recoger necesidades y requisitos, de las historias de usuario. Las historias de usuario, que ya vimos con detalle, recogen de una manera particular aquello que el negocio o el usuario desea que se implemente. La Figura 11 muestra un ejemplo de planificación de la release. Obtenidas varias historias de usuario (requisitos) que debieran implementarse en la misma, las funcionalidades que debe tener el producto, estas se dividen en varias iteraciones.
Figura 11. Planificación de la reléase con 2 iteraciones Para seleccionar qué historias de usuario, y en qué orden se van a implementar, será necesario estimar el valor que aporta cada una al usuario (ver epígrafe 3.3.2) y el tamaño/complejidad de las historias de usuario de la release (ver epígrafe 3.3), algo necesario para poder decidir qué historias se desarrollarán en cada iteración. Un punto a destacar del plan de la release es identificar las condiciones de satisfacción de cada prototipo y de la release, es decir, bajo qué condiciones la release estará lo suficientemente terminada como para pasar a producción. Y este punto involucra a los usuarios, clientes, o figura que los representa, el product owner. No olvides determinar las condiciones de satisfacción o validación de prototipos y releases
Otro aspecto que no debe pasarse por alto es que durante el tiempo que transcurre hasta que se obtiene la release iremos iterando, es decir, el ciclo de vida de trabajo será iterativo, más concretamente, iterativo e incremental, ya que este ciclo de vida es el corazón de un proyecto ágil.
5.1.Ciclo de vida ágil: iterativo, incremental y de iteraciones cortas
Frente a realizar cada fase del proyecto una única vez, una fase tras otra sin, en teoría, vuelta atrás, o en cascada, una alternativa es el “ciclo de vida incremental” en el que el software se va creando poco a poco, por partes. En vez de una única fase monolítica de requisitos, otra única de diseño y una final de codificación, el software final se construye después de varias fases de requisitos, diseño y codificación, cada una creando parte del software final. Se van desarrollando partes del software, para después integrarlas a medida que se completan. A este ciclo de vida se le conoce como iterativo
incremental. Pero no sólo el ciclo de vida incremental es el que propone una manera alternativa al desarrollo en cascada. Hay muchas otras propuestas (como el ciclo de vida en espiral), donde una de las más destacadas es el “ciclo de vida iterativo”. El desarrollo iterativo se centra en mejorar y revisar reiterativamente el producto ya creado. En cada ciclo se revisa y mejora el trabajo. Por ejemplo, cuando se desarrolla rápidamente un producto, muchas veces no se hace con todos los detalles ni la máxima calidad, pero se hace con la idea de que el usuario vea cuanto antes un prototipo, para que en sucesivas iteraciones dicho producto se vaya mejorando y afianzando. De la unión de los dos anteriores, iterativo + incremental, nace el “ciclo de vida iterativo e incremental”, que es una de las buenas prácticas de ingeniería del software más antiguas (su primer uso en el software se data en los 50 con la construcción del avión cohete X-15) y es caracterí stico de los proyectos ágiles. En este tipo de ciclo de vida, al final de cada iteración se consigue una versión operativa del software, que añade nuevas funcionalidades y mejoras sobre la versión anterior. El ciclo de vida de un proyecto ágil es iterativo e incremental, con iteraciones cortas, normalmente, de no más de un mes
Al ir desarrollando prototipos, se obtiene un “feedback” continuo por parte del usuario sobre un producto operativo. Es importarte recordar que el ciclo de vida iterativo e incremental está compuesto por dos “partes”, por lo que no hay que olvidar “la parte iterativa”, ya que en la práctica, muchas veces nos encontramos con que los equipos olvidan la parte iterativa, olvidan que cada prototipo debe mejorar en calidad al anterior, y se centran solo en añadir funcionalidad. El problema de esto es que pasadas unas cuantas iteraciones, el producto se hace difícilmente mantenible, por su baja calidad, y por ello es muy difícil añadir nuevas funcionalidades, alargándose las iteraciones, los ciclos, y muriendo la esencia de todo esto.
5.2.Cuánto tiempo debe durar una iteración
Un punto clave a la hora de planificar un proyecto iterativo es decidir la duración de las iteraciones (o de los sprint en terminología Scrum). En la Figura 12, se puede ver un ejemplo con iteraciones de 3 semanas de duración.
Figura 12. Ejemplo de planificación de un proyecto iterativo con iteraciones de 3 semanas. Para seleccionar la duración de una iteración, podemos encontrar recomendaciones de todo tipo. Por ejemplo, metodologías como XP (Beck & Andres, 2004) recomiendan iteraciones de un par de semanas, mientras que lo habitual en Scrum es que sean de un mes de duración. Y lo normal que nos solemos encontrar en proyectos son iteraciones que están entre una semana y un mes. ¿Qué debería determinar la duración más recomendable para una iteración? Sin que exista una norma exacta, los siguientes factores pueden servirnos de ayuda: La frecuencia con la que hay que mostrar el software a los usuarios. Normalmente, el software se puede mostrar al final de una iteración (demos de prototipos), por lo que a mayor frecuencia requerida para mostrar demos y avance, menor debiera ser la duración de la iteración. En línea con el anterior, debiéramos pensar con qué frecuencia hay que medir, o mostrar, el progreso del proyecto. En teoría sólo al final de una iteración podemos medir con precisión la cantidad de trabajo que realmente ha sido completado. La frecuencia con la que se pueden re-ajustar objetivos del proyecto. No debiéramos hacer cambios de objetivo, funcionalidad, o alcance, una vez que ha comenzado una iteración. Los ajustes y cambios deben esperar hasta el momento en que una iteración termina. Por ello, si se requiere mayor ratio de cambio de alcance, menor debiera ser la duración de la iteración. Por lo tanto, el tiempo que se puede aguantar sin cambios de prioridad es un factor determinante a la hora de fijar la temporalidad de una iteración. Ten cuidado, que en este punto la terminología puede ser confusa… Una iteración, es un periodo de tiempo, no confundir con el ciclo de vida iterativo. El ciclo de vida incremental, contiene las fases del cascada estándar, pero cada iteración trabaja sobre un sub conjunto de funcionalidad. Desarrollar por partes el software, después integrarlas a medida que se completan. En el ciclo de vida iterativo, en cada ciclo, iteración, se revisa y mejora el producto. Un ejemplo de desarrollo iterativo es aquel basado en refactorizaciones, en el que cada ciclo mejora más la calidad del producto. Es importante señalar que este ciclo no implica añadir funcionalidades, pero si revisión y la mejora. Ciclo de vida ágil, Iterativo e incremental,
Incremental = añadir iterativo = re-trabajo iteraciones = cortas, semanas. iteraciones no son (o a priori no tienen porqué) lineales y son flexibles
Con todo, por ejemplo, si tenemos cuatro meses de proyecto, y nuestras iteraciones son de un mes de duración, tendremos tres momentos (al final de la iteración 1, 2 y 3) para tomar “feedback”, medir progreso y re-ajustar prioridades. Otra consideración clave es el tiempo que tarda una idea (un requisito funcional, una historia de usuario) en transformarse en software. Por ejemplo, consideremos de nuevo iteraciones de cuatro semanas. Suponiendo que una nueva idea aparece en el medio de una iteración, esa idea solo puede introducirse en la próxima versión, que comenzará en dos semanas. Dos semanas que quedan de la iteración en que aparece el nuevo requisito, más cuatro de la siguiente, hacen que la nueva idea esté implementada en 6 semanas, y si 6 semanas es mucho para nuestro negocio... habrá que considerar iteraciones menores. Una última consideración. No olvides que a menor tiempo de iteración mayor nivel y sofisticación debe tener el equipo de desarrollo, por lo que la madurez, compenetración, experiencia, cualidades técnicas, etc., juegan un papel importante.
5.3.Deberían las iteraciones durar el mismo tiempo?
En nuestra experiencia, hemos visto equipos trabajar muy bien A iteraciones más cortas, harás más con iteraciones, o sprint, de duración variable, es decir, que entregas, con mayor frecuencia, y justo antes de comenzar el mismo, en su planificación, se menor será la desviación respecto a decidía la duración que tendría la iteración. lo que el usuario espera. Pero conviene decir que han sido más los equipos que trabajan bien con iteraci ones de la misma duración. Es más, en equipos poco experimentados, variar la temporalidad de la iteración suele conducir a problemas. Comentaban (Kniberg & Skarin, 2010) que una vez establecida la duración idónea para los sprint… “mantenedla durante un buen periodo de tiempo, porque manteniendo la misma duración se logra un “latido corporativo” al que todo el mundo se acostumbra”.
Es recomendable que todas las iteraciones duren lo mismo, esto sincroniza a la organización, permite hacer cálculos de velocidad más exactos y detectar problemas en el proyecto
Las principales ventajas de tener sprint todos ellos de tiempo fijo viene de que: Sincroniza calendarios, todo el mundo sabe cuando comienza y cuando acaba un sprint. Se evitan discusiones sobre las fechas de entrega, ya que con el tiempo toda la organización se acostumbra a que “aquí cada dos semanas se entrega”. Facilita el cálculo de la velocidad del equipo, una métrica muy importante a la hora de planificar un proyecto ágil (que veremos con más detalle en la sección 4.7 ). La velocidad es el trabajo completado al final del sprint, e interesa ir disponiendo de la media histórica de la velocidad del equipo. Si los sprint son cada uno de una temporalidad diferente el trabajo entregado se verá afectado por ello, será mayor o menor, y será difícil tener una media, y detectar caídas de velocidad, desviaciones de la media, por problemas. No obstante, que los sprints regularmente sean de la misma temporalidad no significa que eternamente tengan que tener la misma temporalidad. La duración pueden variar de un proyecto a otro, o tras una retrospectiva, el equipo puede detectar que le conviene otra temporalidad, y comenzar así una serie amplia de sprints todos ellos con la misma temporalidad pero diferente temporalidad a los de la serie anterior. En cualquier caso, el cambio de temporalidad no es algo frecuente.
5.4.El “Sprint cero”
En algunos equipos es frecuente el uso del llamado sprint o iteración cero, cuyo objetivo son los preparativos previos a comenzar el desarrollo. Así, normalmente, durante el sprint cero se realizan las tareas como las siguientes: Se dejan listos los entornos de desarrollo. Se trabaja en el product backlog, principalmente en dejar listas las historias de usuario, priorizadas y estimadas. Se hace una previsión del reparto de historias de usuario por iteración. Se hace un estudio de la arquitectura. Autores como (Ambler, 2008), comentan que el sprint cero es aquel en que se organiza el t rabajo, se estudian requisitos iniciales, conceptualizaciones arquitectónicas iniciales, se dejan listos los puestos de trabajo, la planificación inicial, y todo lo que se necesita para iniciar el proyecto. Aunque para Ken Schawber(Schawber, 2008), coautor de Scrum, el sprint cero no deja de ser una errónea forma de llamar a la planificación previa al primer sprint.
5.5.El “Sprint de release”
En las metodologías ágiles, y en Scrum especialmente, cada iteración, cada sprint, debiera concluir con un incremento funcional sobre el producto, que además sea potencialm ente entregable. Aunque, no todo lo “potencialmente entregable” es realmente “entregable”. El sprint de release es aquel que implementa aquellas tareas necesarias para poner el sistema en producción. Aquel que muchos proyectos requieren al final de un ciclo de release, es decir, después de un número de iteraciones o sprint previos a un paso a producción. Un último sprint dedicado a preparar el paso a producción. En este sprint se realizan tareas como el despliegue, generación de “scripts” de recuperación del sistema en caso de problemas al pasar a producción, tareas relacionadas con las bases de datos en producción, documentación, pruebas de carga, integraciones, etc. Sobre el sprint de release hay comentarios a favor y en contra, hay quien dice que es necesario, y quien dice que debería evitarse, ya que el equipo debería dejar lo suficientemente listas las cosas al final de un sprint regular como para que los pasos a producción no requieran de ese tiempo dedicado exclusivamente al paso a producción. En proyectos que implementan el “continuous delivery” este sprint carece de sentido, ya que el paso a producción es prácticamente inmediato.
5.6.¿Y mis Diagramas Gantt? ¿volveré a utilizarlos?
En planificaciones software tradicionales, muchas veces hay reuniones de proyecto en las que los participantes muestran decenas de diagramas Gantt (como podemos ver en la Figura 13), con decenas de barras azules horizontales, flechas de dependencias, porcentajes de avance dentro de las barras, porcentajes de uso de recursos, columnas de fechas de inicio, fin, real, etc.
Figura 13. Ejemplo de diagrama Gantt En muchas ocasiones cuando en una reunión salen estos diagramas, diagramas que, algunos, por su
tamaño, son impresos en varios folios, se corre el riesgo de que la única preocupación del equipo sea cuadrar barras, flechas y recursos, en un espacio temporal… Pienso que, en parte, la razón de su gran uso en el mundo del desarrollo soft ware viene de la formación que casi todos los ingenieros en informática o carreras técnicas han recibido en gestión de proyectos, aún hoy en un alto porcentaje, basada en aprender Gantt, Perts, rutas críticas, etc. Es decir, planificación tradicional, aquella heredada de la gestión y construcción de productos físicos cómo barcos, casas o coches. Si tienes que usar Gantt, intenta evitar malas prácticas que suelen asociarse a los mismos
Y esa “visión Gantt” de que fabricar software debe hacerse como se construyen cosas físicas está tremendamente arraigada en la cultura de ciertas organizaciones, incrementada aún más en los últimos años por el uso de macro marcos de gestión de proyectos (no específicos para software) como PMP. Por supuesto, no siempre es un error aplicar y estudiar este tipo de gestión de proyectos, pero hay proyectos en los que la planificación Gantt es una buena manera de gestionar… pero en otros no lo es. En una planificación ágil el Gantt se sustituye por los planes de release, los ciclos de vida iterativos y los seguimientos con técnicas como los “burndown chart” (que veremos en el capítulo 7 ). No es incompatible usar un Gantt, que acompañe a la planificación de la release aunque en un ciclo de vida ágil, la predicción dentro de cada iteración es menor, y ello dificulta el uso de estos diagramas. En cualquier caso, te dejamos un recopilatorio de errores típicos al planificar un proyecto software con Gantt, con el ánimo de que seas consciente de ellos y los evites.
5.6.1.Malas prác ticas relacionadas co n el uso de Gantts planificando software
El uso de diagramas Gantt no tiene porque conllevar necesariamente problemas en la planificación y seguimiento de proyectos, aunque, en la práctica, he podido observar numerosas malas prácticas relacionadas con el uso de diagramas de Gantt. He aquí dos de las más frecuentes. Barras Gantt que muestran porcentajes de avance del proyecto… asignados sin ningún criterio.
En innumerables ocasiones he visto como los jefes de proyecto actualizan las barras porcentuales de avance de un Gantt según el tiempo transcurrido (que no el trabajo terminado) o sólo preguntando a la gente “cómo va el proyecto”. Y, por razones como estas, muchos de los diagramas Gantt están al 90% de avance durante el 90% de la vida del proyecto. En una planificación ágil, la medida de avance es escalonada, no porcentual, y la única medida de avance es el número de trabajo completado al finalizar una iteración. Veremos cómo se hace este seguimiento en el capítulo 7 .
Planificar un Gantt de proyecto en función del tiempo disponible y no en función del tamaño del software a desarrollar.
O “estimar” de adelante hacia atrás. Es decir, fijada una fecha de finalización del proyecto, normalmente impuesta por motivos comerciales, construir un Gantt cuyas barras y recursos encajen de cualquier forma entre la fecha actual y la de fin. Un recurso muy usado en estos casos es tener que abusar de las tareas que, supuestamente, se pueden hacer en paralelo. En una planificación ágil, se asume que hay incertidumbre al comienzo del proyecto y se está abierto a ajustar la planificación.
Capítulo 6 6. El Plan de una iteración “Sólo cuando conoces cada detalle de l a condición del terreno puedes maniobrar y guerrear.”
-- Sun Tzu El objetivo del plan de una iteración es describir y estimar las tareas que se van a abordar en las semanas que dura una iteración. Las historias de usuario, los requisitos, se dividen en tareas. Las tareas ya son algo muy concreto a realizar durante una iteración, con el objetivo de completar una o varias historias de usuario. A la hora de descomponer historias de usuario en tareas, se intenta que el tamaño de las tareas sea de entre medio día hasta un máximo de 3 o 4 días de trabajo de un solo miembro del equipo. En cualquier caso, nunca deben exceder al tiempo de una iteración. La Tabla 14 muestra varios ejemplos de tareas típicas en las que se podría haber dividido una historia de usuario.
Ejemplo de tarea
Descripción
Diseño de la historia de usuario
Realizamos especialmente esta tarea para generar discusión sobre cómo se va a implementar la historia de usuario.
Esta tarea puede incluir la definición de las interfaces y los Implementación métodos necesarios para cubrir la de una historia necesidad expresada en la historia. Pueden existir múltiples tareas de este tipo.
Pruebas Esta tarea debiera ser obligatoria unitarias para cada historia. asociadas a la historia (TDD)
Pruebas de aceptación asociadas a la historia
Tarea definida para desarrollar las pruebas de aceptación automáticas que facilitarán la validación de la historia por parte del cliente y/o usuario.
Requisitos no funcionales
Para cada historia, se deben tener en cuenta requisitos de seguridad, rendimiento, escalabilidad, etc. Estos atributos de calidad pueden dar lugar a nuevas tareas.
Revisiones de código
El código siempre debe haber sido revisado, convirtiéndose la revisión en otra tarea.
Esta tarea se debe incluir para Refactorización cada historia con el fin de evitar del código una complejidad excesiva del código.
Emular interfaces
En el caso de que se demore en exceso la implementación de una interfaz, éstas se deben emular con el fin de comenzar a trabajar.
Pruebas exploratorias
Pruebas ad-hoc para una historia.
Dependiendo de la historia, se Corrección de debe reservar tiempo para la errores resolución de errores o incidencias. Dependiendo de la historia, se
Verificación de debe reservar tiempo para errores verificar la corrección de los errores.
Demo
Actualizar la wiki o el repositorio de documentos
Demostración interna al equipo de la historia. Esta pequeña demostración se suele realizar una vez finalizada la historia en la reunión diaria. Con el diseño y los resultados de la historia.
Generación de los manuales de Documentación usuario, instalación, etc., también de usuario puede estar ubicada en alguna tarea. Tabla 14. Ejemplos de tareas
6.1.Tiempo Ideal y tiempo Real
Como ya se comentó, normalmente estimamos historias de usuario en puntos historia y tareas en horas, lo que no quita que ciertos equipos, normalmente experimentados, usen las horas para estimar también historias de usuario. Los “días u horas ideales” serían los días que “idealmente” tardaría una tarea en completarse. Le llamamos tiempo ideal porque considera que no hay interrupciones, dispones de todo lo necesario para terminar tu trabajo, etc.
Tiempo ideal: “¿Cuánto dura un partido de futbol? Idealmente 90 min. Pero, con faltas, interrupciones, tiempo añadido… no sabría decirte el tiempo real”
Para las primeras estimaciones e iteraciones tendremos que hacer una aproximación al tiempo real,
pero para las siguientes sería aconsejable ir tomando datos de qué ha ido sucediendo en iteraciones previas. Así, sería interesante registrar las horas de trabajo que cada miembro del equipo realmente ha dedicado a la iteración. Una sencilla tabla que tenga en filas a las personas y una columna de tiempo real dedicado nos puede ayudar a hacer previsiones más exactas en el futuro. En la Tabla 15 se puede ver el tiempo real de trabajo.
Ideal
Real 1 hora de reuniones 1 hora de email
1 hora de teléfono Una jornada de 8 horas de trabajo Realmente cada día quedan 5 horas para el proyecto Tabla 15. Tiempo ideal frente a tiempo real
Capítulo 7 7. El seguimiento del proyecto “Aceptar nuestra vulnerabilidad en lugar de tratar de ocultarla es la mejor manera de adaptarse a la realidad.”
-- David Viscott Los “BurnDown” son una representación del trabajo que queda por hacer y a su vez, permiten comparar el progreso del proyecto o dela iteración, con la planificación inicial. Normalmente el trabajo pendiente de realizar, en puntos historia o en número de historias de usuario, se muestra en el eje vertical, y el tiempo, en los días, semanas o iteraciones, compone el eje horizontal. El gráfico BurnDown proporciona información muy útil para predecir las desviaciones y ver el avance. La Figura 14 representa un ejemplo de esa gestión. La línea verde representa el caso más optimista de trabajo que se puede entregar en el tiempo, la línea roja representa la pesimista. Ambos rangos deben ser conocidos por el product owner en función de la velocidad del equipo (ver epígrafe 4.7 ).
Figura 14. Gestión de expectativas del proyecto Conocer lo anterior es de vital importancia para ir gestionando en el tiempo las expectativas que “stakeholders” y usuarios tienen del producto que se les va a ir entregando. Por ejemplo, imaginemos que se espera cierta funcionalidad del producto en una fecha dada, como se representa en la Figura 15. Según todo lo anterior, el product owner debe exponer a los usuarios el caso más optimista y el más desfavorable, para que tengan en consideración que puede haber mayor o
menor funcionalidad entregada, o que valoren ampliar el tiempo de proyecto.
Figura 15. Gestión de expectativas en una fecha dada
Capítulo 8 8. La subcontratación del proyecto "Customer collaboration over contract negotiation"
-- Manifiesto Ágil A la hora de subcontratar un proyecto ágil podemos encontrar diferentes tipos de contratos. Autores como(Cockburn, 2006), (Beamount, 2008) o (Sutherland, 2008)recopilan las diferentes variantes, si bien estas se pueden agrupar en tres: pago por tiempo o por iteración, pago por punto historia y contrato fijo. Sólo las dos primeras podemos considerarlas “ágiles”. Si bien estos tres grupos se mezclan muchas veces a la hora de elaborar un contrato para subcontratar un proyecto ágil.
8.1. Pago por tiempo o por iteración
La manera más natural de formalizar un contrato para un proyecto ágil es la de pago por tiempo de trabajo (o por número de sprint o iteraciones), también conocido como “por servicio” o “por bolsa de horas”. En su forma más básica, el proyecto duraría hasta que la versión final del producto software esté terminada. Y los pagos se harían normalmente por el tiempo que ha durado el proyecto, por iteración o por número de sprint. Si el tiempo estimado de proyecto es muy largo también se puede facturar al finalizar cada sprint. El problema de esta modalidad es que la mayoría del riesgo lo tiene el cliente que subcontrata. El miedo de muchos clientes es que el proveedor podría relajarse, dando lugar a más iteraciones de las necesarias y mayores costes. Para ello, en este tipo de contratos se suelen introducir cláusulas que reducen el riesgo del cliente. Lo normal es cerrar de antemano un tiempo máximo de proyecto, dando la opción al cliente de cancelar el proyecto o renegociar una continuación. O de manera similar, introducir hitos de chequeo cada cierto tiempo. Por ejemplo, en un proyecto se podría determinar que cada cuatro meses el cliente podrá decidir si continúa o cancela el proyecto.
8.2. Pago por punto historia
Este es uno de los esquemas más recomendados. En algunos sectores del desarrollo software, como por ejemplo la banca, se ha introducido con fuerza un modelo en el que el proveedor factura por la cantidad de funcionalidad desarrollada. Y para cuantificar la funcionalidad entregada se mide con diferentes técnicas, como por ejemplo, la técnica de puntos función para medir el tamaño de la funcionalidad. Cabe destacar que el cliente paga por puntos función entregados, no por los que se estimaron, por lo que suele ser un esquema bastante eficiente para ambas partes. Asimismo se puede replicar este modelo cambiando puntos función por puntos de historia de usuario o similar. El cliente estima los puntos historia, los revisa con el proveedor y se factura en función de puntos historia entregados.
8.3. El contrato cerrado
El contrato cerrado, también conocido como “llave en mano”, consiste, básicamente, en que el cliente redacta, siempre antes de comenzar el proyecto, un documento llamado “pliego de condiciones” que, principalmente, contiene los requisitos que debe implementar el software, o el sistema de información. Redactado el “pliego de condiciones”, con sus requisitos, este se expone a las empresas candidatas a llevarse el proyecto, las cuales, tomando como base esos requisitos, dicen al cliente por cuánto dinero están dispuestas a hacer el proyecto y en cuánto tiempo. Por último, el cliente selecciona una empresa de desarrollo, normalmente basándose en la que menor precio oferta y menor tiempo dice y, normalmente, añade al contrato las llamadas penalizaciones: si la empresa se retrasa en tiempo se le paga menos, y a más retraso menos se le paga.
8.3.1.El contrato cerrado y los proyectos ágiles
El cliente, redacta unos requisitos en un momento, tan temprano, que muchas veces escribe sólo ideas poco concretas e incompletas de lo que se supone necesita que haga el software, y que normalment e,
cuando avanza el proyecto, difieren de lo que realmente necesitaba, lo cual acaba sabiendo cuando recibe la primera entrega. Esto sucede porque muchas veces hasta que no se ve un primer prototipo no se sabe bien lo que se necesita, o sucede porque se toman mal los requisitos, o sencillamente porque las necesidades cambian con el tiempo y lo que se creía necesario hoy mañana puede no serlo. El proveedor, en base a esos requisitos (como dijimos, la mayoría de las veces poco concretos, o que difieren de lo que realmente se necesitará) hace una estimación del tiempo de desarrollo. Bajo estas premisas, el objetivo del proveedor, será terminar en plazo… como sea, para evitar la penalización típica que llevan estos contratos por retrasos. Al proveedor le preocupa entregar sólo lo que dicen los requisitos del pliego y no entregar un software que cumpla las necesidades de los usuarios (que no siempre es lo mismo). Si a lo largo del proyecto alguien piensa (el cliente, por ejemplo) que han cambiado, o eran erróneos, etc., da igual. Esos requisitos están firmados y hay penalización por incumplimiento. No hay cambio de requisitos. El software se entregará en fechas a toda costa (suele haber penalización por retraso). Lo cual suele ser en detrimento de dejar tiempo para calidad software, metodologías, prototipos con usuarios, etc. Normalmente, este tipo de contrato persiste por el temor del cliente a caer en manos del proveedor, y este pudiera alargar y alargar, meses y meses, el desarrollo software (y con ello el presupuesto).
Capítulo 9 9. Consejos finales para el superviviente
Conociendo y aplicando todo lo anterior, es más que seguro que podrás sobrevivir a la planificación de un proyecto ágil. Además, la práctica con cada uno de los anteriores consejos y t écnicas te llevará con el tiempo a una supervivencia cada vez más cómoda. No obstante, permíteme sólo unas páginas finales para trasmitirte algunos últimos consejos que todo buen superviviente a un proyecto software acaba teniendo claro con el tiempo…
9.1. Consejo 1: no estimes sólo el desarrollo software
Recuerda que, en un proyecto no sólo hay desarrollo software, también hay proveedores de hardware, diseñadores gráficos, entornos de producción, etc. Y no olvides otras tareas comunes, como vacaciones, reuniones, informes, et c.
9.2. Consejo 2: encuentra tu propio método de estimación
Recuerda que, aún utilizando el mismo método para calcular los puntos historia, dos empresas equipos pueden obtener estimaciones diferentes… ¿por qué? Porque una, por ejemplo, puede desarrollar en una tecnología, y la otra empresa en otra, una puede tener personal más cualificado, otra utilizar una arquitectura diferente, etc. Por ello, no olvides que el punto historia hay que ajustarlo a la realidad de la empresa y a los requerimientos tecnológicos concretos de cada proyecto.
9.3. Consejo 3: Estima usando rangos
Recuerda que, los métodos tienen siempre un error y nunca son exactos. Es decir, que ningún método de estimación nos dirá cosas del tipo “el proyecto terminará el día miércoles 12 de noviembre a las 12:33”. Eso es imposible en proyectos medianos o grandes. Por ello, cuando trabajamos con métodos de estimación el resultado debe ser rangos del tipo “el proyecto terminará la primera quincena de noviembre”, “la última semana de noviembre”, etc. El rango temporal depende de la exactitud de nuestro método, del momento en el que estimo (la exactitud no es la misma el primer día de proyecto que el penúltimo mes) y de la magnitud del proyecto (proyectos mayores implican rangos mayores, p.e. semanas vs. quincenas).
9.4. Consejo 4: Siempre acompáñate de la estimación por analogía
Recuerda que, la experiencia y el conocimiento es tesoro más valioso que irás adquiriendo con el tiempo. Así que… guárdalo. La analogía se basa en que guardes decisiones de otros proyectos, cómo estimaste, cuánto estimaste, cómo definiste las iteraciones, que guardes cómo te fue al final de proyecto, y que utilices ese conocimiento para futuras planificaciones.
ANEXO I.Scrum
Scrum es una metodología ágil para la gestión de proyectos; por lo que queda fuera de su ámbito el tratamiento explicito de, por ejemplo, el testing, el control de versiones, el diseño, arquitectura, etc. Su principal objetivo es obtener resultados (normalmente prototipos) pronto y adaptarse a los cambios (normalmente, los cambios en los requisitos). Por otro lado, es un “framework”, por lo que es necesaria su adaptación en cada organización, o incluso a cada equipo (Sutherland & Schwaber, 2011). De manera sintetizada, los pilares de Scrum son, principalmente, dos: el ciclo de vida iterativo e incremental (en iteraciones cortas) y diversas reuniones a lo largo del proyecto.
Ciclo de vida iterativo e incremental. Los Sprints
Una de las bases de las metodologías ágiles es el ciclo de vida iterativo e incremental. El ciclo de vida iterativo e incremental es aquel en que se va liberando el producto por partes, periódicamente, iterativamente, poco a poco, y además cada entrega es un incremento de funcionalidad respecto a la anterior. Esto difiere del ciclo de vida en cascada, en el que las fases del ciclo de vida (requisitos, análisis, diseño, etc.) se realizan (en teoría) una única vez, y el inicio de una fase no comienza hasta que termina la fase que le precede. En Scrum a cada iteración se le llama sprint. Un sprint es un periodo de corta duración (entre 2 y 4 semanas, el equipo decide) que debe finalizar con un prototipo operativo. Lo que se va a implementar en el sprint, la funcionalidad del prototipo, proviene del Product Backlog, que contiene requisitos funcionales o historias de usuario En Scrum, la figura del product owner, que vendría a ser el usuario o el cliente, es el responsable de gestionar el product backlog y de crear las historias de usuario. Una vez seleccionadas las historias de usuario que se van a desarroll ar en el sprint, el equipo técnico las descompone en tareas, las cuales forman el Sprint Backlog, que será inamovible durante el sprint.
Las Reuniones
El segundo pilar más importante de Scrum son las reuniones. Su importancia reside en que las reuniones son la base para lograr transparencia y comunicación, y posibilitan algo característico en un equipo ágil: que sea auto-gestionado y multifuncional. Las reuniones se realizan a lo largo de todo el proyecto, según las siguientes tipologías:
- Reunión de Planificación del sprint (Sprint Planning Meeting). Al principio de cada sprint, para
decidir que se va a realizar en ese sprint. - Reunión diaria (Daily Scrum). Máximo 15 minutos, en la que se trata qué se hizo ayer, que se va a
hacer hoy y que problemas se han encontrado. - Reunión de Revisión del sprint (Sprint Review Meeting). Al final de cada sprint, y se trata qué se
ha completado y qué no. También se muestra el trabajo al Product Owner. - Retrospectiva del sprint (Sprint Retrospective). También al final del sprint, y sirve para que los
implicados den sus impresiones sobre el sprint, y se utiliza para la mejora del proceso.
Consideraciones importantes y cosas que deberías tener muy claras
- Cada proyecto, empresa, producto, línea de negocio, etc., requiere una adaptación de Scrum a su caso. Scrum es un marco de trabajo, o meta-metodología, por lo que tiene que adaptarse. - Scrum, aunque nace en el mundo del desarrollo software, es una metodología lo suficientemente genérica como para poder aplicarse a la gestión de otro tipo de proyectos. De ahí que se esté
extendiendo su uso a otros ámbitos. - Normalmente Scrum no se utiliza sola, ya que no cubre todo lo que se necesita para abordar un proyecto software. En software es muy típico acompañar Scrum con la metodología XP, que aporta
cuestiones más cercanas a la programación, y con Kanban, que ayuda mucho en la gestión de las tareas en las que se descomponen las historias de usuario. - Scrum no es la única metodología ágil que existe. No es la solución a todos los males. Hay
empresas en las que, por su negocio, no encaja bien Scrum. Y en lograr, si aplica, su im plantación está la clave del éxito y lo que supone un verdadero esfuerzo.
ANEXO II. FDD
Aunque aquí hablamos de la “metodología FDD”, siendo rigurosos, al igual que sucede en Scrum, FDD es, concretamente, un “framework” o una meta-metodología, es decir, que necesita ser adaptado al caso concreto. El padre de la metodología es Jeff De Luca. El libro que mejor describe la metodología es el “A Practical Guide to Feature-Driven Development” (Palmer & Felsing, 2002) y la web de referencia es la del creador(De Luca, 2012).
Los procesos de la metodología ágil FDD
FDD es una metodología dirigida por modelos, y de iteraciones cortas. FDD define 5 procesos: Proceso 1 – Desarrollar el modelo global (Developover all model). Proceso 2 – Construir una lista de características (Build feature list). Proceso 3 – Planificar (Plan by feature). Proceso 4 – Diseñar (Design by feature). Proceso 5 – Construir (Build by feature). Los 3 primeros pueden considerarse la “iteración o sprint cero”, aunque en FDD no le llaman así, y los consideran “procesos iniciales”. En la práctica los equipos de desarrollo necesitan un tiempo previo para arrancar, montar entornos, planificar, e incluso hacer un estudio previo de la arquitectura. Esto normalmente se suele hacer en lo que comúnmente se llama iteración cero (o sprint cero para quienes siguen Scrum). Pero, por ejemplo, en Scrum no se dice mucho de esta iteración cero, sin embargo FDD la detalla mucho más. Los dos primeros procesos son secuenciales y definen el modelo global. Los tres finales se iteran para cada “feature” (que vienen a ser los requisitos). Proceso 1: Desarrollar el modelo global (Developover all model)
Una de las cosas más polémicas de los proyectos ágiles es cómo y cuándo se crea el diseño y la arquitectura. En el mundo ágil, hay incluso quienes, erróneamente, asocian la palabra diseño con el ciclo de vida en cascada, tan denostado por el agilísimo extremo. En la metodología ágil FDD si se recomienda, y deja claro, que hay que tener un diseño previo. No un diseño documentado y detallado al máximo, pero si un borrador de la arquitectura. Y que además éste se construya de manera iterativa. El diseño es más en anchura que en profundidad. La profundidad (los
detalles) van saliendo iterativamente a lo largo del proyecto. El diseño es un artefacto vivo. A diferencia de otras metodologías como Scrum, la metodología ágil FDD contempla una fase de diseño y el rol del “Chief Architect”, o diseñador experimentado. También recomienda el uso de UML (el lenguaje unificado) en colores, la metodología de modelado de Coad(Coad et al., 1999). Proceso 2: Construir una lista de características (Build feature list)
En la metodología ágil FDD a los requisitos se les llama “features”. FDD define una feature como una pequeña función orientada al cliente. Por pequeño se entiende que suele durar de 1 a 3 días de desarrollo. FDD organiza sus “features” en una jerarquía de tres niveles. Proyectos o equipos más grandes agradecen esta jerarquía. Jerarquizar los requisitos ayuda a manejar un mayor número de requisitos. “Lead developers” (desarrolladores líder) o “chief programmer” (programadores Jefe) organizan la lista de “features” con los conocimientos adquiridos durante el modelado (FDD utiliza los términos “lead developers” y “chief programmer”). Proceso 3: Planificar (Plan by feature)
Tercer y último proceso de los que conformarían la “iteración cero”. Su objetivo, crear una planificación inicial y asignar responsabilidades. La metodología ágil FDD también se aleja de conceptos muy arraigados en el mundo ágil, como el de la propiedad colectiva del código. En lugar de que “todo el código sea de todo el mundo”, en FDD se asignan como responsables de partes del código a desarrolladores concretos. Esta asignación de responsables tiene lugar durante el proceso de planificación. Y ojo, que en FDD hablamos de responsabilidad del código no de exclusividad. Esto es otra muestra más de cómo FDD está pensada para proyectos grandes. Proceso 4: Diseñar (Design by feature)
En esta parte se realiza un diseño para cada feature. El programador responsable (chief programmer) elige un grupo de features a desarrollar durante las próximas dos semanas. En la metodología ágil FDD se realizan diagramas de secuencia para cada feature, y se refina el diseño o modelo global. Proceso 5: Construir (Build by feature)
Después de una inspección diseño exitosa, los propietarios de cada clase, o partes del código, desarrollan el software. La metodología ágil FDD contempla el uso de las pruebas unitarias e inspecciones de código, tras las cuales la feature se sube a la línea principal de desarrollo. Para acabar, la metodología ágil FDD podríamos considerarla orientada a equipos más grandes, con más personas que aquellos a los que normalmente se aplican otras metodologías ágiles como Scrum.
La metodología ágil FDD contempla la figura del jefe de proyecto y una fase de arquitectura. Scrum y XP suelen usarse, y recomendarse, para equipos pequeños y auto-organizados y en estas metodologías no queda tan claro la fase de diseño.
Referencias Ambler, S. (2008). Acceleration: An agile productivity measure. Fecha de consulta: 17 mayo 2012. Disponible en: https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/ entry/metric_acceleration?lang=e n Beamount, S. (2008). Agile & contracts. scrum gathering stockholm. Disponible en: http://www.scrumalliance.org/resources/442 Beck, K., & Andres, C. (2004). Extreme programming explained: Embrace change Addison-Wesley Professional. Coad, P., De Luca, J., & Lefebvre, E. (1999). Java modeling in color with UML: Enterprise components and process Cockburn, A. (2006). Agile contracts. Fecha de consulta: 17 mayo 2012. Disponible en: http://alistair.cockburn.us/Agile+contracts/v/multi Cohn, M. (2005). Agile estimating and planning. Upper Saddle River, NJ, USA. Prentice Hall PTR. Construx Software Builders. (2013). 2013. Disponible en: http://www.construx.com/Page.aspx? cid=1653 De Luca, J. (2012). Jeff de Luca's website. 2013. Disponible en: http://www.nebulon.com/ Haugen, N. C. (2006). An empirical study of using planning poker for user story estimation. Artículo presentado en Agile Conference, 2006, pp. 9. Humble, J., & Farley, D. (2010). Continuous delivery: Reliable software releases through build, test, and deployment automation Addison-Wesley. Jeffries, R. (2001). Essential XP: Card, conversation, confirmation. Fecha de consulta: 17 mayo 2012. Disponible en: http://xprogramming.com/articles/expcardconversationconfirmation/ Kniberg, H. (2012). Agile product ownership in a nutshell. 2013. Disponible en: http://www.youtube.com/watch?v=502ILHjX9EE Kniberg, H., & Skarin, M. (2010). Kanban and scrum - making the most of both Lulu Enterprises Inc. Little, T. (2006). Schedule estimation and uncertainty surrounding the cone of uncertainty. IEEE Software, 23(3), 48-54. McConnell, S. (2007). Classic mistakes update. 2013. Disponible en: http://www.construx.com/10x_Software_Development/Classic_Mistakes_Updated/
McConnell, S. (2006). Software estimation: Demystifying the black art . Redmond, WA, USA. Microsoft Press. Miranda, E. (2001). Improving subjective estimates using paired comparisons. IEEE Software, 18(1), 87-91. Palmer, S., & Felsing, J. (2002). A practical guide to feature driven development. A Practical Guide to Feature Driven Development, Patton, J. (2008). User story mapping. 2013. Disponible en: http://www.agileproductdesign. com/presentations/user_story_mapping/index.html Pichler, R. (2012). Working with an agile product roadmap. 2013. Disponible en: http://www.romanpichler.com/blog/product-planning/agile-product-roadmap/ Poppendieck, M., & Poppendieck, T. (2006). Implementing lean software development: From concept to cash Addison-Wesley Professional. Quora. (2013). Continuous deployment at quora. 2013. Disponible en: http://engineering.quora.com/Continuous-Deployment-at-Quora Schawber, K. (2008). Sprint zero. 2013. Disponible en: http://tech.groups.yahoo.com/ group/scrumdevelopment/message/32488 Sutherland, J. (2008). Money for nothing and your change for free. agile 2008 presentation. Fecha de consulta: 17 mayo 2012. Disponible en: http://jeffsutherland.com/ Agile2008MoneyforNothing.pdf Sutherland, J., & Schwaber, K. (2011). The scrum papers: Nut, bolts, and origins of an agile framework. Fecha de consulta: 17 mayo 2012. Disponible en: http://jeffsutherland.com/ ScrumPapers.pdf Treadway, M. (2011). throw new NerdOverflowException();. 2013. Disponible en: http://thetread-way.blogspot.com.es/2011/04/how-many-hours-are-in-story-point.html
1. Durante el texto se hará uso de las palabras “roadmap” y “release” en inglés, por ser de uso más común que los equivalentes en castellano. 2. En el texto utilizaremos las palabras en inglés, product owner, por ser de mayor uso en castellano. 3. Para este ejercicio, puedes pensar en la serie “The Big Bang Theory” o cualquier otra. Aunque si no conocías esta serie aprovecho para recomendártela.
