2. Gestionando un proyecto tecnológico en una Startup. Francisco Javier Cervigon Ruckauer

2. Gestionando un proyecto tecnológico en una Startup:


Lecciones aprendidas de la creación de una startup de manera ágil

Para comenzar este tema, queremos presentaros el caso de Dropbox, una empresa que seguro que la mayoría conocéis, y cuya historia ilustra muy bien algunos de los conceptos que queremos trabajar en este tema. Para ello, os animamos a echar un ojo a la siguiente presentación de Drew Houston, el creador de Dropbox (cuenta la leyenda que la idea se le ocurrió un día en que olvido en casa su memoria USB).
En ella resume sus experiencias y lecciones aprendidas durante la creación de la compañía, para la que siguió el popular modelo lean startup: la máxima y más frecuente interacción con los potenciales usuarios del producto o servicio, liberando rápidamente pequeños prototipos, y validándolos con usuarios reales (iterativo, incremental, ágil).
Algunas de las ideas más importantes que podemos extraer de la presentación son:
    • Aprende pronto, aprende con frecuencia.
    • Es una gran riesgo hacer algo que nadie quiere.
    • Pon rápido algo en las manos del usuario y aprende de su opinión: un feedback real.
    • Contratamos a la gente más lista que conocíamos, destacando la contratación de no-ingenieros.
    • No te fíes, las mejores prácticas no son siempre las mejores.
    • Conoce tu mercado y como encajar tu producto en la vida del usuario.
    • Obtén feedback de tus usuarios y utilízalo para el desarrollo de futuras versiones.
Os recomendamos ver la presentación, ya que además habla de los fallos que cometieron, la presión que recibían para crear la empresa según el método tradicional (plan de negocio a años vista, etc.), su mala experiencia con (Google) AdWords y la publicidad en la web, y otras lecciones interesantes para cualquier emprendedor.

ENTREVISTA GOOGLE CAMPUS MADRID



























Ciclos de vida del software

En esta sección hemos querido tocar el tema de los procesos de desarrollo del software, es decir, las formas estructuradas y más o menos aceptadas, que existen de abordar el desarrollo de software, que, en general, definen una serie de pasos o recomendaciones a seguir cuando nos enfrentamos a la construcción de software. A estos modelos se les conoce como ciclos de vida (del software).
Nos parece un tema fundamental y sobre el que aún hay muchas dudas al respecto. Vamos a abordar sólo la presentación de algunos conceptos y definiciones, sobre las que parece haber más consenso, aún sabiendo que hay autores que se refieren a estos conceptos utilizando otros nombres o acepciones.
Pero pese a la falta de consenso, queremos introducir el tema, y aclararlo en la medida de los posible, dando unas pinceladas de cada ciclo de vida (o manera de abordar el desarrollo de software).

Cascada

El software se aborda en una serie de fases aisladas y sucesivas (requisitos o requerimientos, análisis, diseño, etc.) tal y como muestra la figura. Estas fases se completan (en teoría) de manera lineal, una única vez, y el inicio de una fase coincide con el fin de la fase anterior.
Esta naturaleza lineal es típica de la construcción de productos físicos (dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas), y su principal problema viene de que no deja claro cómo responder cuando el resultado de una fase no es el esperado.



emp_f2111
A este ciclo de vida se le ha identificado erróneamente con el término “proceso”, como comentamos en mitos del Desarrollo Software: Proceso es sinónimo de ciclo de vida en cascada.

Espiral

Para resolver los problemas del ciclo de vida en cascada, en 1984 Barry Boehm presenta el ciclo de vida en espiral, en el que propone que cada una de las fases identificadas por el ciclo de vida en cascada termine con una evaluación de riesgos y un prototipo.



emp_f2112
Los prototipos permiten a los usuarios determinar si el proyecto continua, debe volver a fases anteriores, o debe terminar. Sin embargo, las fases son todavía lineales: una fase no empieza hasta que acaba la anterior, los requisitos se realizan en la fase de requisitos, el diseño en la fase de diseño, y así sucesivamente.

El ciclo de vida incremental

Cada iteración (una iteración es un periodo de tiempo, no confundir con el ciclo de vida iterativo, que veremos luego, siendo este uno de los principales malentendidos que dan lugar a definiciones confusas) contiene las fases identificadas por el cascada estándar, pero en cada iteración se trabaja sobre un subconjunto de la funcionalidad que debe proporcionar el producto. La entrega total del proyecto se divide en subsistemas priorizados.
En otras palabras, se desarrolla el producto software por partes, para después integrarlas a medida que se completan, agregando cada vez más funcionalidad al sistema. 

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 (te dejamos un post de introducción a la refactorización), en el que cada ciclo mejora más la calidad del producto.
Es importante señalar que este ciclo no implica añadir nuevas funcionalidades en el producto, si no simplemente revisarlo y la mejorarlo.

El cliclo de vida iterativo e incremental

El ciclo de vida iterativo e incremental es una de las buenas prácticas de ingeniería del software más antiguas, su primer uso en el software data de los 50 y probablemente la visión más intuitiva corresponde a Alistair Cockburn, uno de sus impulsores: Incremental = añadir, Iterativo = retrabajo.
La idea es ir liberando partes del producto (prototipos) periódicamente, en cada iteración, de forma que cada nueva versión aumenta la funcionalidad y mejora la calidad respecto a la anterior. 
Además, el ciclo de vida iterativo e incremental es una de las bases de un proyecto ágil, más concretamente, con iteraciones cortas en tiempo, de pocas semanas, normalmente un mes y raramente más de dos.

Ciclos de vida de las metodologías ágiles

A la hora de analizar cuál es el ciclo de vida adoptado por las metodologías ágiles, podríamos decir que éste sería un ciclo de vida iterativo e incremental, con iteraciones cortas (semanas) y sin que dentro de cada iteración deba haber fases lineales (tipo cascada).
A partir de esta definición de mínimos, caben infinitas matizaciones, adaptaciones, etc., una por cada metodología ágil que existe e incluso una por cada organización que la aplica y adapta a sus necesidades.
Quizá la metodlogía ágil más popular sea Scrum. Hace ya sus años, en el año 85, y en la primera presentación oficial de Scrum, Ken Schwaber, uno de sus creadores, hablaba sobre el ciclo de vida de Scrum, y de sus diferencias con los anteriores ciclos de vida
Según comenta Schwaber, el ciclo de vida en Cascada y el Espiral cierran el contexto y la entrega al inicio de un proyecto. La principal diferencia entre cascada, espiral e iterativo y los ciclos de vida ágiles, concretamente el que adopta Scrum, es que estos últimos asumen que el análisis, diseño, etc., de cada iteración (o Sprint) son impredecibles. 
Para concluir esta sección os dejamos una imagen que compara los diferentes ciclos de vida, y que en cierto modo resume las ideas expresadas por Cockburn en este otro artículo especialmente aclaratorio sobre las similitudes y diferencias entre el ciclo de vida Iterativo y el Incremental.



emp_f2113

Referencias



Los pilares de Scrum 

Si ya conoces Scrum, y trabajas regularmente con dicha “metodología”, lo de metodología entre comillas, ya que es un error el propio nombre, porque las metodologías ágiles no existen, ahórrate esta pantalla.
Esta pantalla está pensada para aquellos que no van a trabajar directamente con Scrum, pero quieren dejar de poner caras raras y mirar para otro lado cada vez que escuchan el nombre de la metodología de moda. Para gente de dirección, interesados en la tecnología, comerciales, inversores en empresas tecnológicas, etc., que en 10 min quieran quedarse con la idea principal. Y también para aquellos que si que puede que algún día trabajen con Scrum y quieren empezar aquí el muy duro camino que les queda por recorrer para conocer realmente la metodología.
Scrum (que no se escribe en mayúsculas, porque no es un acrónimo) es una “metodología” ágil para, importante, la gestión de proyectos; por lo que queda fuera de su ámbito el tratamiento explícito de, por ejemplo, el testing, el control de versiones, el diseño, arquitectura, etc. Su principal objetivo es obtener resultados (normalmente prototipos) cuanto antes y adaptarse a los cambios (normalmente, los cambios en los requisitos).
De manera sintetizada, los pilares de Scrum son, principalmente, dos: el ciclo de vida iterativo e incremental 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 incrementa. 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 (menor a 4 semanas, el equipo decide) que debe finalizar con un prototipo operativo o producto potencialmente entregable.
Lo que se va a implementar en el Sprint, la funcionalidad del prototipo, proviene de la Pila del Producto (Product Backlog), que contiene un conjunto de items, normalmente, requisitos funcionales o historias de usuario.
En Scrum, la figura del Propietario del Producto (Product Owner), es el responsable de gestionar el Product Backlog, priorizarlo, mantenerlo y de crear las historias de usuario (o items en general).
Una vez seleccionadas las historias de usuario que se van a desarrollar en el Sprint, el equipo técnico las descompone  en tareas, las cuales forman la Pila del Sprint (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 que hizo ayer, que 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é 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 antes de continuar con el curso: 
  • 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, como lo llaman algunos, 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 implantación está la clave del éxito y lo que supone un verdadero esfuerzo.

Visión clásica de los requisitos vs visión contemporánea

Los requisitos han sido, en el mundo del software, una de las mayores fuentes de dolores de cabeza: “los clientes no saben lo que quieren”, “nos han cambiado los requisitos”, etc. En esta concepción clásica, que se corresponde con el ciclo de vida en cascada que os hemos presentado, debía disponerse de una descripción correcta, completa y, sobre todo,cerrada, de los requisitos, antes de abordar la construcción del sistema. 
Frente a la visión clásica, la visión moderna o contemporánea, asume que los requisitos no pueden cerrarse de antemano demasiado a menudo. En primer lugar, porque es casi imposible disponer de todas las ideas de los usuarios sobre cómo debería ser o qué debería hacer un sistemas antes de construirlo. En segundo lugar, porque aunque pudiéramos hacerlo, para cuando hubiésemos sido capaces de construirlo , el mundo habrá cambiado y las necesidades de nuestros usuarios también. Recuerda aquello de: hoy lo más determinante es la velocidad de desarrollo. ¿Eres rápido? Tu empresa lo tiene todo.
A continuación tratamos de sintetizar las 3 diferencias principales entre la visión clásica del trabajo con requisitos y la visión contemporánea (llámala ágil si quieres):
  • 1. Antes, la investigación en ingeniería software se centraba en extraer todas y cada una de las ideas de lo que el usuario quería/necesitaba antes de continuar. Ahora asumimos que la mejor manera de saberlo es creando un prototipo real, con parte de esas ideas, y enseñárselo a los usuarios para que sobre ese prototipo ellos sean capaces de ir profundizando en lo que quieren o necesitan.
  • 2. Antes, una vez cerrado un gran listado (o "especificación") de requisitos, los cambios eran un problema. Los ciclos de vida como el cascada no estaban preparados para ello. Ahora por el contrario asumimos que el cambio controlado no es malo y es incluso bienvenido.
  • 3. Antes, la documentación era voluminosa y se producían grandes “especificaciones de requisitos”. Eran populares estándares como la IEEE 830, documentación completa y previa a la construcción. Ahora en cambio, documentos sobre cosas que no se van a implementar, o se implementan y son luego identificadas como prescindibles o inútiles, son igualmente desechados. Se les considera “desperdicio” y por ello tratamos de minimizar la cantidad de documentación que elaboramos antes de empezar a construir software. Si es preciso documentar en detalle, porque el cliente exige o necesita mucha documentación del producto que hemos fabricado, se tiende a elaborar esa documentación a posteriori, después de implementarlo y comprobar que eso era lo que realmente quería el cliente.

Las historias de usuario

Frente a la concepción tradicional de los requisitos software, donde trabajábamos con listados de necesidades, peticiones o restricciones del usuario con respecto a lo que debe hacer y cómo debe comportarse un sistema, en el contexto de las metodologías ágiles se ha optado por recoger esta información utilizando lo que se conocen como Historias de Usuario. 
Una historia de usuario describe una funcionalidad que será útil para el usuario, o comprador, de un sistema software. Así, frente a mostrar un cómo, las historias de usuario cuentan un qué: describen una funcionalidad que deberá ser desarrollada, pero no cómo se desarrollará.
Pero además, Ron Jeffries comentaba que una historia de usuario no es sólo una descripción de una funcionalidad, normalmente en un post-it, si no que una historia de usuario incluirá otros dos componentes:
  • La conversación que conllevan, ya que son una herramienta para facilitar la interacción entre usuarios y desarrolladores.
  • La forma de confirmar que se ha implementado correctamente, es decir, de comprobar que el sistema entrega la funcionalidad a la que hace referencia esa historia.

Historias de usuario vs Requisitos

Aunque popularmente se ha asociado el concepto de historia de usuario con el de requisito funcional, una historia de usuario no es la especificación de un requisito software: detrás del concepto de historia de usuario hay muchos aspectos particulares que la hacen sustancialmente diferente de lo que es un requisito.
Por definición, las historias de usuario no suelen, ni deben, tener el nivel de detalle que suele tener la especificación de un requisito. Por ello se recomienda que las historias de usuario se escriban en un espacio reducido, y que el soporte físico donde se recogen, habitualmente un post-it o tarjeta, incluya apenas una frase. Así, una historia de usuario debería ser pequeña, memorizable, y debería poder ser desarrollada por un par de programadores en una semana. Pero claro, al tener una única frase, es imposible que una historia de usuario contenga toda la información necesaria para desarrollar la funcionalidad que describe.
Para resolver el anterior problema hay que entender que las historias de usuario son lo que son porque su objetivo es, entre otros, lograr la interacción entre el equipo de desarrolladores y el usuario. Ambos deberán interactuar para completar la información que no incluye la historia de usuario para poder desarrollar la funcionalidad descrita.

Referencias

  • Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional

La importancia de la priorización y las diferentes técnicas para priorizar

Históricamente, la priorización de los requisitos (software) siempre ah sido un tema crucial, ya fuera en la visión tradicional de los requisitos, o en su visión más ágil, donde lidiamos con historias de usuario y demás.
En el contexto de las metodologías ágiles, y más concretamente de Scrum, sabemos que el Product Backlog representa una lista de requisitos u objetivos priorizada, de acuerdo al valor que cada ítem de la lista aporta al cliente. Es el product owner, que hace las veces de cliente, el responsable de asignar (o averiguar) dicho valor y por tanto es él quien se encarga de priorizar el Product Backlog.
Pero, aunque tenemos claro que no debemos priorizar atendiendo al esfuerzo o la complejidad de desarrollar ese ítem no es lo adecuado, seguimos teniendo dudas en cuanto a cómo priorizar el Product Backlog. Por ello, en los últimos años han ido apareciendo diferentes técnicas de priorización de requisitos, ítems, historias de usuario, etc., en el contexto del mundo ágil, 
A continuación te dejamos una introducción a una selección de técnicas de priorización para el Product Backlog, las que nosotros más utilizamos, pero nos encantaría conocer otras, para ello tienes a tu disposición el foro.



emp_f2311

Filtro de priorización

En 2008, Corey Ladas (el autor de “Scrumban”) difundió el filtro de priorización. 
En su filtro de priorización, las columnas se etiquetan de izquierda a derecha como prioridad 3, prioridad 2 y prioridad 1. A su vez, cada columna tiene un WIP (te dejo aquí más información sobre el WIP, por si no conoces esto del WIP), es decir, un límite máximo de historias que puede haber en cada columna. Típicamente, la columna de prioridad 1 tiene un límite de 1, es decir, sólo puede contener un requisito, ítem o historia de usuario.
Si quieres saber más sobre el tema, puedes leer una explicación más detallada aquí.

Pirámide de Priorización

Es un derivado del anterior, de un tal Tomas Rybing, que aplicaba las mismas ideas pero proponía dibujar el product backlog en forma de pirámide en lugar de usar columnas.
De nuevo, puedes encontrar información detallada sobre esta forma de priorización aquí.



emp_f2312

MoSCoW y Kano

El modelo Kano, de los años 80, se utiliza para clasificar y priorizar requisitos en función de lo que satisfarán al usuario. Y para ello los divide en cuatro tipos: Requisitos obligatorios (básicos); Necesidades (esperado, lineal); No esperados (inesperado, excitante); e Indiferentes (el cliente no está interesado en ellos).
Por otro lado, el método MoSCoW hace algo similar, identificando otros cuatro tipos de requisitos: Must (obligatorios), Should (deberían estar), Could (podrían) y Won’t (por ahora los dejamos).
Tanto el modelo Kano, como el MosSCoW se explican con más detalle en el libro “Gestión de Proyectos Ágiles …y las experiencias de más de 12 años de proyectos ágiles”

Referencias

Te dejamos las URLs de las referencias que mencionábamos en el texto:


Técnica MoSCoW

Te dejamos a continuación un vídeo explicativo sobre uno los conceptos introducidos en la pantalla anterior: la técnica MoSCoW.


























La estimación en proyectos ágiles

Prácticamente todo método de estimación, ágil o no, se basa en tener una unidad de medida del tamaño del trabajo a realizar (en agilidad lo más común es usar los puntos historia) y un mecanismo para ir calibrando las estimaciones (en agilidad se suele hacer uso de la “velocidad” y si hay menos experiencia del “yesterday’s weather” o estimar en función de qué pasó en el último sprint.
Para profundizar en los conceptos relacionados con lo que acabamos de contarte, debes leer los siguientes posts:
Además, para saber más sobre estimación podéis descargar la Guía de supervivencia ágil Estimación con puntos historia aquí y echar un ojo a las siguientes entradas del blog:


¿Hay que estimar o no? (#noEstimates)

En los últimos tiempos, hay un movimiento impulsado fundamentalmente por Woody Zuill y Neil Killick, que recomienda y defiende que las estimaciones en el mundo del desarrollo software no tienen sentido (e incluso son perjudiciales). Esta idea ha crecido con relativa fuerza en general, y muy especialmente en el mundo ágil, y las iniciativas y mensajes sobre el tema se encuentran agrupadas bajo la etiqueta #NoEstimates (para los no familiarizados con el mundo Twitter, la '#' al principio proviene de que éste es un hasghtag de twitter, bajo el que se recopilan opiniones sobre el tema).
A continuación vamos a tratar de contarte cuáles son las bases del movimiento #NoEstimates. Luego saca tus propias conclusiones y si las compartes en los foros mucho mejor.

Realmente, por la naturaleza del software, es imposible obtener una estimación precisa

Como expone en un artículo Neil Killick, que como te decíamos es uno de los precursores del movimiento #noEstimates, el germen de la idea está en el pensamiento “¿Cómo podemos estimar cuando todavía no sabemos o entendemos la solución?"
El desarrollo software es, por su propia naturaleza, impredecible y no repetitivo. A diferencia de la producción de otros bienes industriales, como los automóviles (te recomiendo aquí aquel post Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas), no conocemos por completo el producto que estamos construyendo hasta que terminamos de construirlo.
Fijar el alcance exacto (en tiempo/esfuerzo) de los proyectos software es por tanto poco menos que imposible. Incluso si lo fuera, no es deseable, ya que un enfoque de este tipo limita la posibilidad de introducir cambios durante el proyecto, impide un diseño emergente, descarta requisitos cambiantes y en general, pone fronteras a la innovación.
Si aceptamos que el alcance de aplicación a desarrollar es siempre variable, también debemos aceptar que la fecha de entrega puede ser variable.

Si no es posible cerrar los requisitos de manera precisa antes de comenzar, ¿cómo vamos a obtener una estimación precisa?

Obtener una estimación se basa en satisfacer un conjunto fijo de requisitos, si los requisitos no son precisos, las estimaciones no pueden serlo.
Y tener unos requisitos precisos, completos, cerrados ... antes de comenzar la construcción del producto software, es algo que como ya hemos dicho antes, muy pocos proyectos se pueden permitir. Disponer de esos requisitos cerrados fue el objetivo casi utópico del ciclo de vida en cascada, y ha sido (y es) una constante fuente de proyectos en los que todas las partes acaban insatisfechas, descontentas, etc. Si quieres profundizar en estas ideas, puedes leer estos dos post:
Como argumentan los defensores de #noEstimates, para construir software necesitamos sólo una visión clara de qué queremos conseguir y un propósito compartido. Dicho de otro modo, objetivos de alto nivel, y no el detalle de cómo vamos a alcanzarlos. ¿Qué sentido tiene entonces buscar una estimación precisa y condicionar todo el proyecto a ella, aún cuando sabemos desde el principio que esa estimación es inexacta por naturaleza?

Bueno, y en Scrum … ¿no se estimaba con la velocidad? ¿no es entonces la estimación en base a la velocidad algo ágil?

Una de las bases que normalmente se utilizan en Scrum para hacer estimaciones o previsiones, es la velocidad o cantidad de trabajo completada en un tiempo (normalmente un Sprint o Iteración). Si aún no estás familiarizado con el concepto de velocidad consulta los posts: 
Bueno, pues en este sentido, los defensores del #noEstimates no se cortan y llegan a decir que estimar con velocidad no es ágil. Argumentan para ello que en lugar de hacer pronósticos cada Sprint sobre cuántos puntos o historias de usuario se pueden hacer, los equipos deben comprometerse desde el principio a ofrecer el mejor producto posible en una fecha determinada.
Y que la planificación en base a la velocidad es contraria a un enfoque iterativo (mejora evolutiva holística del producto), siendo más acorde con un enfoque puramente incremental (en el que se va añadiendo valor al producto). Y algo más: el Product Owner no debería priorizar una historia sobre otra porque aquella exija menos trabajo o tiempo. En estas condiciones, ¿qué utilidad tiene estimar? el Product Owner debe priorizar las historias por valor. Si damos más importancia a las estimaciones que al valor que aportan las diferentes historias de usuario, acabaremos produciendo mal software.

Algunas conclusiones, remakes y peros…

Si los escépticos de la agilidad ya ponían peros al ciclo de vida iterativo (constantemente decían que El problema de la agilidad es que no vamos a saber cuándo se termina el proyecto (y la típica solución al anterior problema), extender el #noEstimates en ciertos sectores “tradicionales” es todo un reto. 
Para terminar, nos gustaría apuntar que la justificación y parte de los argumentos que se utilizan para defender el #noEstimates, pueden verse como un remake avanzado de las ya múltiples y antiguas ideas que había desde hace muchos años alrededor del mundo de la estimación, con mención especial al cono de incertidumbre.

Estimación del Product Backlog

El siguiente video explicativo ilustra el proceso de estimación del Product Backlog.


























Reuniones de seguimiento 

Una vez puesto en marcha el proyecto, conviene seguir algunas normas básicas para su seguimiento. Una forma habitual de hacerlo es mediante las reuniones de seguimiento. El que más y el que menos ha pasado y pasa por unas cuantas (muchas) de estas reuniones que, salvo en proyectos pequeños, son un clásico. De nuestras experiencias en todos los proyectos eh que hemos participado, a continuación os dejamos un pequeño listado de lo que más solemos echar en falta en una reunión de seguimiento.
No nos alargaremos mucho, pero si durante no más de una hora, cada Viernes (el día habitual para las reuniones de seguimiento ...), revisas los siguientes puntos, minimizarás la posibilidad de llevarte un susto y de que existan cosas que estén bajo tu control.

1. Riesgos y su estado

No nos referimos a unos riesgos genéricos, obsoletos, y puestos por cumplir con la tarea de identificarlos. Nos referimos a unos riesgos reales, con su probabilidad de materializarse y un plan de mitigación e impacto.

2. Avance del proyecto

Esto puede parecer una obviedad, pero falla en la mayoría de los proyectos: conocer el avance del proyecto con un mínimo grado de realismo. Lo cual excluye completamente la consideración de porcentajes tentativos a partir de diagramas de Gantt: Diagramas Gantt cómo arma de destrucción masiva de proyectos. Por favor, no los utilicéis. 
Hasta ahora la manera más fiable que ha descubierto la humanidad de calcular el avance (real) de un proyecto es fijándose en la funcionalidad entregada (programada, probada y lista para pasar a producción).

3. Estado de la calidad del software

Rara vez un informe de seguimiento de proyecto tienen en cuenta cuál es la calidad del producto desarrollado hasta el momento. Y la mejor forma de saberlo es disponer de un informe cuantitativo, extraído directamente de la información que hay en los ficheros que contienen el código fuente del proyecto. Es decir, utilizar cualquiera de las herramientas existentes para obtener de forma automática métricas del código fuente. Lo demás olvidadlo: la verdadera calidad software la tienes que ver en los fuentes, en el código. No te fíes de nada más.
Bueno, estamos dando por hecho (y en ocasiones esto es mucho suponer), que quien lleva el seguimiento del proyecto sabe dónde están los fuentes y accede a ellos con cierta frecuencia (cosa que no siempre ocurre), no sólo los ve al final de proyecto. Bueno, pues dando por sentado que efectivamente esto fuera posible, para controlar la calidad bastará con seleccionar un par de métricas clave, y registrar su evolución en el tiempo con una simple gráfica.

4. Una demo de la funcionalidad real implementada

Nada de presentaciones de PowerPoint o similares. Ni siquiera videos. Hablamos de demos reales en pre-producción (o producción si fuera posible) que se muestran en cada reunión de seguimiento.

Gráficos Burn–down vs Burn-up para el seguimiento de un proyecto ágil

Como ya mencionamos antes, los gráficos Burn–down y Burn-up son herramientas habituales para la gestión de proyectos ágiles (normalmente con Scrum), que permiten controlar el avance del proyecto, facilitando su seguimiento.

El gráfico Burn–down

En el gráfico Burn–down se marca el trabajo pendiente de hacer (los puntos historia) para una Release (te recordamos aquello del Roadmap ágil: Usando un “roadmap” en un proyecto ágil). Por ejemplo, 45 puntos historia. Habitualmente al final del Sprint se actualiza el gráfico con el trabajo completado. Así la gráfica va bajando. El objetivo es llegar al eje de las X. La pendiente de la curva ayuda a ver la velocidad del equipo y permite al Product Owner hacer previsiones con respecto a próximas iteraciones.



emp_f2521

Gráfico Burn-up

El gráfico Burn-up es muy similar, pero en este caso se parte de cero y se va marcando la cantidad de trabajo completado al final del Sprint, por ello la curva es creciente. En la figura de abajo, la línea naranja es el objetivo.



emp_f2522

La diferencia entre el Burn–down y Burn-up

Bueno, teniendo en cuenta que son muy similares, más allá de lo obvio, ¿cuál es la diferencia?
Principalmente se observa cuando el alcance del proyecto cambia (o el alcance de una reléase cambia), es decir, se aumenta el número de historias de usuario, aumenta el número de puntos historia (o baja, pero eso es raro).
En un burn-down sos cambios de alcance son más difíciles de gestionar y recordemos que esos cambios son perfectamente aceptables en un proyecto ágil. Si tratamos de reflejar un cambio de este tipo en un burn-down el resultado sería algo parecido a la siguiente figura y resulta difícil de interpretar: ¿más trabajo añadido? ¿trabajo “deshecho”? ¿qué ha pasado ahí?.



emp_f2523
Sin embargo, con un gráfico burn-up este tipo de cambios resultan visualmente más claros. En el siguiente gráfico burn-up la línea naranja identifica los cambios de alcance.



emp_f2524


Lean Software Development: la estrategia de fabricación japonesa aplicada al desarrollo software ágil

Lean IT es la aplicación de los principios del Lean Manufacturing y el Lean Services al desarrollo de productos y servicios de tecnologías de la información (IT). Aunque históricamente se ha identificado a Lean con la filosofía de Toyota a la hora de producir coches, realmente el término “Lean” (y “JIT” - just in time) no fue popularizado por los Japoneses, si no por los estadounidenses. Concretamente por el “best-seller” del MIT La máquina que cambió el mundo (1990).
Fueron los autores de aquel libro los que usaron el término “Lean” para describir cualquier práctica eficiente de gestión que minimice el desperdicio (waste). Lo que incluía a las técnicas de desarrollo de productos japonesas, con las que los fabricantes de automóviles japoneses habían logrado recortar mucho los tiempos (alrededor de un tercio) y las horas de ingeniería (aproximadamente a la mitad), en comparación con Estados Unidos y Europa. Hasta tal punto llega este paralelismo que, como os decíamos, hoy Lean se identifica con el método de fabricación de Toyota.
En el mundo del software, fue el libro Microsoft Secrets el primero que habló de la similitud de la estrategia de "daily builds" que usaba Microsoft (similar a la integración continua pero planificada, en la que diariamente se compila el software y se pasan algunas pruebas unitarias automatizadas, o el “smoke test”), donde los ingenieros software tenían que parar y corregir errores diariamente, y la filosofía de producción de Toyota – JIT, donde los trabajadores paraban las líneas de montaje cuando detectaban problemas, solucionándolos inmediatamente.
El libro Microsoft Secrets no utilizó el término “Lean”, ni Lean Software development, aunque ya hablaba de la aplicación de JIT, del control de calidad, y la reducción de la burocracia en Microsoft.
Hay claramente muchos elementos comunes entre el estilo de producción de Toyota, el estilo iterativo de Microsoft y el desarrollo ágil. Siempre teniendo en cuenta que en Microsoft no siempre se desarrolló así: a finales de 1990 y principios de 2000 trabajaban con equipos de desarrollo exageradamente grandes.
La popularización del término “Lean” aplicado al software, el Lean Software development, y su asociación a lo “ágil” surge principalmente de la aparición del libro Lean Software Development de Mary y Tom Poppendieck. Ellos también hacen hincapié en la eliminación de desperdicios, la eliminación de la burocracia en el desarrollo de productos, el aprendizaje por ciclos cortos y frecuentes, las iteraciones rápidas, etc., obteniendo una rápida retroalimentación que “tire” (pull) del producto, en lugar de documentos de requisitos y planes rígidos que “empujen” (push) el trabajo de desarrollo. Y hacen hincapié también en la diferenciación de esta aproximación con respecto a los métodos antiguos y más basados en la utilización de mano de obra, burocráticos, “pushstyle”, inicialmente asociados con el negocio de las computadoras mainframe.
En ese libro, Mary y Tom destacan los siete principios del Lean Software development (que más tarde modificaron):
  • 1. Optimizar el todo
  • 2. Eliminar desperdicios
  • 3. Calidad en la construcción
  • 4. Aprender constantemente
  • 5. Entregar rápido
  • 6. Involucrar a todo el mundo
  • 7. Seguir mejorando
El Lean, y el Lean Software development, no es una metodología de ingeniería de software en el sentido convencional. Es más una síntesis de principios y una filosofía para construir sistemas de software. Esta concepción de Lean como un conjunto de principios más que de prácticas, permite que la aplicación de los principios Lean al desarrollo y la ingeniería del software tengan más sentido y pueda ayudar a mejorar la calidad.

Referencias

  • Cusumano, M. A., & Selby, R.W. (1998). Microsoft Secrets:How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People. Simon and Schuster.
  • Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit: An Agile Toolkit. Addison-Wesley.
  • Poppendieck, M., & Cusumano, M. A. (2012). Lean Software Development: A Tutorial. IEEE Software, 29(5), 26-32 doi:10.1109/MS.2012.107
  • Womack, J. P., Jones, D. T., & Roos, D. (1992). La máquina que cambió el mundo. McGraw-Hill.



Lean no es sólo eliminar desperdicios. Muda, Mura y Muri

Mucha gente asocia el Lean, o el Lean Manufacturing, a aquello de “eliminar desperdicios”. Pero la eliminación de desperdicios, o Muda, como se conoce, no es la única ‘M’ del sistema de producción 3M o 3MU de Toyota. Hay dos M's más: la Mura (Variación) y el Muri (Sobrecarga, cuellos de botella). Las tres M's, Muda Mura y Muri, influyen la una en la otra. La eliminación de desperdicios, Muda, se basa en gestionar el Muri y el Mura. Estos tres conceptos son la base de la mejora continua que propone Lean , a la que en japonés se refieren como Kaizen (te animo a leer el post Kaizen: o mejoras poco a poco o mueres poco a poco).

Mura (tiempos muertos, irregularidad)

Mura es un término que hace referencia a las irregularidades, los tiempos muertos, los imprevistos, etc. Cuando el Mura no se controla, se aumenta el Muri (que veremos a continuación) y por lo tanto, aumenta el Muda (los desperdicios).
Dejar todo para el final, los picos de trabajo no controlados, el no aplicar buenas prácticas, los requisitos imprevistos, las solicitudes de última hora, etc., son ejemplos de Mura.

Muri (sobrecargas, exceso, cuellos de botella)

El término Muri hace referencia a todo aquello que provoca cuellos de botella. En nuestro mundo, el Muri, por ejemplo, es la sobrecarga que provoca la presión innecesaria sobre las personas. Es la sobrecarga de tener un Rambo o Héroe en el equipo, que es capaz de hacer tantas cosas tan bien, que acaba asumiendo demasiadas tareas y responsabilidades (sobrecargado). Es depender de una única persona para todo. Es trabajar hasta mucho más allá del horario de trabajo. 
El WIP de Kanban (echa un ojo al post sobre Kanban) es un ejemplo de variable importante para ajustar los cuellos de botella (Muri). 
Mura y Muri generan … Mudas.

Mudas (Desperdicios)

Originalmente, el método de producción de Toyota identificaba siete tipos de desperdicios típicos en la industria. Libros como el mencionado Lean Software Development adaptaron esa clasificación al mundo del software, dando como resultado la siguiente tipificación de desperdicios para proyectos software:
  • Trabajo realizado parcialmente
  • Características extra
  • Reaprendizaje
  • De mano en mano”
  • Las pausas
  • Cambio de Tarea
  • Defectos
Si quieres profundizar sobre la naturaleza de estos desperdicios te animamos a leer los posts  Lean de la vida misma de un proyecto: los desperdicios del lean software (1/2). 


La filosofía Lean Startup

La filosofía Lean Startup se basa en enfocar la creación de la empresa en la máxima y más frecuente interacción con los posibles clientes: Esta forma de afrontar la creación un negocio se ha convertido en una tendencia que cada vez adoptan más empresas. Más aún si cabe cuando son empresas con cierta base tecnológica, por su cercanía con otros términos de los que venimos hablando, como la Agilidad o el Lean Software development.
Pero el hecho de que sea una idea que goza de cierta popularidad, no implica que goce de cierta comprensión. En particular, hay un concepto en torno al Lean Startup que merece especial atención: el Producto Mínimo Viable(MVP, Minimum Viable Product).
La idea de Lean Startup es crear productos que son puestos a disposición de los usuarios lo más rápido posible, para obtener su feedback y producir nuevas versiones lo más rápido posible. Es decir, que en vez de hacer un gran plan de negocio a varios años vista que culmina con un producto lanzado al mercado mucho tiempo después de su concepción (algo así como un ciclo de vida en cascada en el mundo software), con el consiguiente riesgo de gastar tiempo y dinero en algo que podría no valer ya para nada, preferimos centrarnos en lanzar rápidamente pequeños prototipos, aunque no estén totalmente terminados, y en ir validándolos con usuarios reales. El resultado es un ciclo de vida iterativo, incremental, ágil, en el que cada iteración debe terminar con un Producto Mínimo Viable.
El Producto Mínimo Viable recuerda mucho al prototipo de un ciclo de vida de desarrollo software iterativo y/o ágil. Es un producto parcial orientado a aprender rápidamente qué quiere el cliente, generando el mínimo desperdicio (gastar esfuerzo en cosas que no van a servir).

Algunas características de un Producto Mínimo Viable:

  • El producto mínimo viable es una versión de un nuevo producto que permite recoger la máxima cantidad de información al ser validado por los usuarios y elaborado con el menor esfuerzo posible.
  • A pesar del nombre, no se trata de crear productos mínimos. No hablamos de construir algo rápido, de cualquier manera. Sólo vale si sirve para aprender sobre lo que realmente necesita el usuario
  • Gestionar un producto mínimo viable requiere esfuerzo, hablar con clientes y obtener métricas y datos analíticos.
  • Hay quien define un producto mínimo viable como lo mínimo por lo que estaría dispuesto a pagar un cliente.

Referencias





Una checklist  para identificar un MVP 

Como decíamos en la sección anterior, hay mucha controversia respecto a qué es un MVP. La mayoría de las veces se confunde MVP con prototipo a medio terminar, sobre todo en términos de calidad. En el otro extremo, muy habitualmente, los MVP son casi productos finales, ya que muchos no entienden poner a disposición de los usuarios algo que no incluye todas y cada una de las funcionalidades deseadas. Esta suele ser la idea más difícil de romper.
Como comenta Henrik Kniberg, los problemas de entender qué es un MVP vienen ya del propio nombre: ¿qué es Mínimo y qué es Viable?. Para complementar la información al respecto que os dejábamos en la sección anterior, queremos dejaros aquí una checklist o lista de comprobación, para intentar facilitar vuestro trabajo a la hora de saber si estáis ante un MVP. 
  • 1. Reemplaza la palabra “mínimo” por “lo más pronto posible”. La idea del producto mínimo viable es una versión de un nuevo producto que permite recoger la máxima cantidad de aprendizaje validado por los clientes con el menor esfuerzo.
  • 2. Por ello, no es un producto con el 100% de la funcionalidad. Si tiene el 100% de la funcionalidad, no estás ante un MVP. Has implementado más de lo mínimamente necesario.
  • 3. Continuando con lo de “mínimo”, a pesar del nombre, no se trata de construir algo rápido, de cualquier manera, que se caiga a trozos.
  • 4. Sólo vale si sirve para aprender sobre lo que necesita el usuario, y que esta información sea la entrada a siguientes iteraciones.
  • 5. El usuario debe poder enamorarse del Producto Mínimo Viable, y que esto le lleve a pedir y desear disponer de nuevas versiones cuanto antes. Hay quien dice que es el producto para los “early adopters”.
  • 6. Hay también quien define un producto mínimo viable como lo mínimo por lo que estaría dispuesto a pagar un cliente.
  • 7. Por viable, entendemos “Testeable” y/o “Usable”. Un MVP permite al usuario hacer algo útil con él. Resuelve problemas al usuario, no todos, pero alguno, para poder obtener feedback sobre cómo lo hace y qué queremos que haga.

.
Etiquetas:

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)