El peor escenario para un proyecto informático es la lluvia ácida
El peor escenario para un proyecto informático es la lluvia ácida
El peor escenario para un proyecto informático no es que vaya con mucho retraso. O que multiplique por tres el coste presupuestado. O que el cliente esté muy enfadado.
Eso ocurre en el 80% de los proyectos, tal como anticipa Pareto y nos confirma The Standish Group en sus informes 'Chaos Report'
El peor escenario para un proyecto informático es la lluvia ácida. Y el Jefe de Proyecto es el único responsable.
Bienvenido a una sesión de méntoring de novanotio.
La lluvia ácida
Pero, ¿Qué es la lluvia ácida? Es la situación en que la resolución de incidencias interrumpe continuamente los trabajos de desarrollo.
Por supuesto, siempre hay incidencias en los entornos de producción. Por eso hay equipos de operaciones encargados de monitorizar los procesos, levantar las aplicaciones o corregir entradas inconsistentes en las bases de datos.
Cuando el equipo de operaciones no es capaz de restablecer el servicio, se produce una incidencia crítica que el equipo de desarrollo debe atender de manera urgente.
De la atención de incidencias a la lluvia ácida
Todos los desarrolladores hemos tenido que atender incidencias de producción en algún momento.
El problema aparece cuando esas incidencias son tan frecuentes que fagocitan el tiempo del equipo de desarrollo. He visto grupos dedicar mas del 70% de su jornada a solucionar incidencias.
Cómo se origina la lluvia ácida
La lluvia ácida tiene la misma dinámica que la bola de nieve que rueda ladera abajo. Crece y crece hasta convertirse en un monstruo ingobernable.
Es sencillo entender el hilo de pensamientos del Jefe de Proyecto que desemboca en esta situación:
- Quiero que mi cliente esté satisfecho.
- Y necesito que el proyecto no se retrase todavía mas.
- Así que, tenemos que solucionar rápidamente esta incidencia de producción.
- Y, además, hay que cumplir la planificación que hemos acordado.
Es una línea argumental con la que todos estaríamos de acuerdo, salvo por dos importantes detalles:
- Hagas lo que hagas, el 80% de los proyectos multiplicarán por tres su plazo y su coste. Lo predice Pareto. Lo confirman año tras año las estadísticas de nuestro sector. No puedes escapar del principio de Pareto como no puedes escapar de la ley de la gravedad.
- La cuarta ley nos advierte que alcance, plazo y calidad están interrelacionados, de forma que si fijas dos de ellos el tercero se degrada. Si mantienes el plazo y amplías el alcance (todo lo planificado más la resolución de las incidencias), la calidad se degrada.
La lluvia ácida aparece cuando sacrificas la calidad
El origen de la lluvia ácida es un Jefe de Proyecto que, presionado por su cliente, sacrifica la calidad.
Ese código desarrollado a toda prisa y que se pone en producción sin apenas pruebas, va a generar nuevas incidencias en producción, que poco a poco, van a consumir el tiempo disponible para el desarrollo.
Por eso, introduciendo presión en el equipo de desarrollo, no aceleramos los trabajos, sino todo lo contrario.
Por no hablar del incremento de la rotación, que aparecerá como un nueva causa de retrasos del proyecto.
Cómo soluciona Scrum el problema de la lluvia ácida
Scrum soluciona el problema de la lluvia ácida mediante dos mecanismos.
- El primero consiste en planificar dentro de cada sprint un cierto tiempo para atender incidencias en producción.
- El segundo es obligar a que sólo se entreguen al cliente los desarrollos que superen las pruebas funcionales.
Scrum asume que hay que atender incidencias y que no se van a completar todos los trabajos planificados para el sprint. Pero se asegura que aquello que se entregue esté convenientemente probado.
Scrum evita la aparición de la lluvia ácida asegurando la calidad.
Y para asegurar la calidad sacrifica el alcance . Es decir, aplica la cuarta ley de gestión de proyectos informáticos.
Resumen
La posición de Jefe de Proyecto no es sencilla. Con independencia de tu experiencia o la de tus desarrolladores, el 80% de tus proyectos van a sufrir importantes retrasos y sobrecostes.
Si intentas acelerar los proyectos metiendo presión a tus equipos, vas a empeorar la situación.
No solo ralentizarás los desarrollos porque los programadores están cansados. Aparecerán efectos de segunda ronda como la lluvia ácida y la rotación, que dilatarán todavía más tu planificación.
Si has seguido las sesiones de méntoring de novanotio, ya sabes cómo evitar la aparición de la lluvia ácida:
- Garantiza la calidad, sacrifica el alcance (4ª ley de gestión de proyectos informáticos).
Y además:
- Quita presión a tus equipos de trabajo (3ª ley de gestión de proyectos informáticos).
- Prioriza los desarrollos que mas valor aportan (Principio de Pareto).
- Y gestiona las expectativas de tu cliente (1ª ley de gestión de proyectos informáticos).
La metodología Scrum puede ayudarte a conseguir todos estos objetivos.
Gracias por compartir el artículo si te ha parecido interesante y nos vemos en la próxima sesión de méntoring de novanotio.
Scrum y el principio de Pareto
Scrum y el principio de Pareto.
El principio de Pareto
El principio de Pareto, también conocido como la regla del 20 - 80, describe el fenómeno estadístico por el cual, el 20% de la población posee el 80% de las tierras de una región.
Esta regla fue enunciada en 1.896 por el matemático italiano Wilfredo Pareto. Desde entonces se ha aplicado a múltiples áreas de las ciencias, la economía y la organización empresarial.
- El 20% de tu ropa la usas el 80% de las veces.
- Con el 20% de tiempo de estudio, consigues el 80% de la calificación.
- El 20% de tus clientes aportan el 80% de tu facturación.
- El 20% de tus productos suponen el 80% de tus ventas.
En resumen, con el 20% del esfuerzo, consigues el 80% del rendimiento.
Este principio es, como veremos, muy importante para el desarrollo de sistemas informáticos. Aunque no lo encontrarás en el Manifiesto Agile, es uno de los pilares fundamentales de Scrum.
Bienvenido a una sesión de formación de novanotio.
Porcentaje de éxito en el desarrollo de sistemas informáticos
Ésta es la primera pregunta que hacemos a todos nuestros consultores en su primera sesión de méntoring. ¿Cuál es el porcentaje de éxito en el desarrollo de los sistemas informáticos?
La respuesta la obtenemos de los análisis que año tras año realiza The Standish Group en su informe 'Chaos Report'. Aproximadamente un 20%.
A pesar de todos los esfuerzos del sector para construir nuevas herramientas y desarrollar nuevas metodologías, el 80% de los proyectos tienen importantes problemas o se cancelan.
Es una aplicación más del principio de Pareto. El 20% de los proyectos aportan el 80% del valor. Organizaciones y estados han invertido miles de millones para escapar a esta regla sin conseguirlo.
No es posible tener éxito en los proyectos
La definición tradicional de éxito es: 'Completar el alcance que se ha acordado en la especificación, en el plazo establecido, con el coste presupuestado y con una buena calidad'
La cuarta ley de la gestión de proyectos informáticos nos avisa de que es imposible conseguir el éxito así definido. Alcance, plazo y calidad son tres parámetros que están interrelacionados, de forma que si fijas dos de ellos, el tercero se degrada.
No es posible alcanzar el éxito según la definición tradicional porque fija alcance, plazo y calidad. Obligatoriamente uno de esos parámetros debe degradarse.
El 80% de los proyectos quedan atrapados por la gravedad de la cuarta ley. Los pocos que consiguen el éxito suelen ser proyectos pequeños sin un alcance demasiado preciso.
Scrum no cambia el porcentaje de éxito, cambia la definición de éxito
Scrum no cambia el porcentaje de éxito de los proyectos. La cuarta ley no desaparece solo por dividir el desarrollo en sprints de cuatro semanas.
Scrum cambia la definición de éxito.
Y es que buena parte del software desarrollado nunca se utiliza. En concreto, aplicando la regla de Pareto, el 20% de la funcionalidad se utiliza el 80% de las veces.
Si conseguimos desarrollar ese 20% que más valor aporta, podemos construir casi todo el sistema con una fracción del esfuerzo.
Así que esta es la nueva definición de éxito que Scrum nos proporciona: 'Usar el presupuesto para construir la mayor cantidad posible de funcionalidad, empezando por aquella que se utiliza con más frecuencia y aporta más valor, con una buena calidad'
Ahora si es posible conseguir el éxito y escapar de la cuarta ley, porque en esta definición se fijan plazo y calidad, pero el alcance queda indeterminado.
Conclusión
El desarrollo de software seguirá siendo complejo a pesar de las nuevas herramientas y metodologías. Los proyectos seguirán retrasándose y fracasando, especialmente aquellos más grandes y complejos.
Afortunadamente Pareto nos indica el camino a seguir. ¡Busca junto con tu cliente ese 20% de la funcionalidad que aporta el 80% del valor!
SCRUM es más productivo que los proyectos a precio cerrado
SCRUM es más productivo que los proyectos a precio cerrado
Un poco de historia
Desarrollar un sistema a partir de unas especificaciones es igual que caminar sobre las aguas. Solo hay que congelarlas.
Leí esta frase a mediados de los años noventa. Eran mis primeras experiencias profesionales y devoraba cada libro de gestión que caía a mi alcance. Me pareció una receta graciosa que escondía algo de verdad. Como todo buen programador junior, me dolía cada vez que teníamos que rehacer buena parte del código por una nueva ocurrencia del cliente.
Encontré también el caso de un jefe de proyecto que se hizo famoso por un cartel en su escritorio que rezaba "He dicho que NO". Así dejaba claro que, una vez firmado el contrato, no estaba dispuesto a cambiar una coma. Era la aplicación práctica de la congelación de especificaciones. Lamentablemente el artículo no mencionaba la reacción de los clientes cuando les entregaban lo que habían firmado y no lo que necesitaban.
Pasaron años hasta que entendí, de la mano de Brooks, DeMarco y Putnam, qué se escondía tras todos esos artículos. El cliente no puede saber lo que quiere. No existe un lenguaje para describir de forma precisa los sistemas informáticos. El desarrollo es un proceso iterativo de prueba y error. En general, al tercer intento, construyes lo que el cliente en realidad necesita.
De manera inexplicable, las principales teorías de gestión de proyectos informáticos eran desconocidas para el sector cincuenta años después de publicadas. Para que os hagáis una idea de lo perdidos que estábamos, hacia el año 2.000 la metodología de moda era CMM, basada en más y mas y mas documentación. Absurdo.
Entonces apareció SCRUM
Afortunadamente, en EEUU un grupo de líderes técnicos empezó a desarrollar, a partir de las ideas de Brooks, una nueva forma de organizar los desarrollos, más centrada en las personas y menos en la especificación. El 12 de febrero de 2001 se presentó el manifiesto ágil, un nuevo paradigma para construir sistemas informáticos que ha ido ganando impulso desde entonces.
Curiosamente, se parecía mucho a la forma de trabajar de Ceselsa (ahora Indra) en los años 90. Sus clientes la definían como una organización 'perfectamente desorganizada', lo que da una idea de su metodología, informal y centrada en las personas. Y funcionaba muy bien. Durante años consiguieron una productividad espectacular y una rotación mínima, a pesar de que los salarios no eran brillantes.
Pero una cosa es el manifiesto Agile y otra muy distinta llevarlo a la práctica. Cincuenta años de gestión de proyectos a precio cerrado producen unas inercias que dificultan su implantación.
Hay, por ejemplo, dificultades de tipo organizativo. Estamos acostumbrados a la figura del jefe de proyecto, que negocia con el cliente y prioriza las actividades de desarrollo. Las organizaciones son reacias a delegar la priorización de tareas en el cliente. En buena parte de los proyectos presuntamente SCRUM, o sigue existiendo el jefe de proyecto, o el Product Owner pertenece a la empresa desarrolladora.
Otra barrera, quizás la más determinante, es de tipo comercial. En SCRUM no se pacta un alcance entre cliente y consultora. No es que el precio no esté cerrado, es que no se define cual será el resultado del proyecto. El contrato es un acto de fe, donde el proveedor se compromete a entregar 'lo mejor que se pueda construir con ese presupuesto'. Eso dificulta cualquier tipo de control. ¿Cómo saber si la empresa desarrolladora ha hecho un gran trabajo o me está engañando?
SCRUM es más productivo que los proyectos a precio cerrado
Aunque no sea posible medirlo, Scrum es más productivo que los proyectos a precio cerrado porque genera importantes ahorros, tanto para el cliente como para el proveedor.
El primero es, sin duda, el ahorro de costes de seguimiento. Según el Chaos Report que elabora la consultora The Standish Group, el 30% de los grandes proyectos se cancela, el 50% multiplica por tres coste y plazo y de media solo se entrega el 50% de la funcionalidad acordada... En resumen, el resultado -si lo hay- no se parece en nada a lo firmado.
Si cada uno de esos cambios implica una compleja negociación entre cliente y proveedor, ¿Cuál es el coste de gestión necesario para unas modificaciones tan dramáticas? Estamos hablando de miles de horas de trabajo de ambas organizaciones, para identificar desviaciones, proponer modificaciones y justificar cambios de precios y plazos. Por no hablar de las horas perdidas por los equipos de desarrollo, que no pueden proseguir su actividad hasta que se alcance un nuevo acuerdo.
Otro de los motivos por los que Scrum es más productivo es porque se ahorra buena parte de la fase de diseño. ¿Para que emplear cientos de horas de analistas para construir una especificación que, de todas formas, va a sufrir importantes alteraciones?
Tampoco podemos olvidar el ahorro de los desarrollos que no se hacen por ser los menos usados. Si el Product Owner conoce bien su negocio, en los primeros sprints se desarrollarán y se pondrán en funcionamiento los módulos más utilizados. Recordad la regla de Pareto, con el 20% de los desarrollos consigues el 80% de la funcionalidad del sistema. ¿De verdad es productivo desarrollar el resto?
Desde precio cerrado y Scrum hacia Time & Material
Time & Material es el modelo de trabajo en el que el cliente lidera el proyecto y solo necesita programadores, testers, y administradores de sistemas, pagando un fee mensual por cada uno de estos profesionales.
De forma natural, los proyectos largos y complejos suelen evolucionar hacia Time & Material, con independencia de que hayan comenzado en la modalidad de precio cerrado o de Scrum.
El proceso es simple, el cliente identifica y contrata a los consultores clave, aquellos con mayor conocimiento funcional y técnico. De esta forma les fideliza y se asegura de que trabajen a su favor.
Y una vez que tiene en su plantilla a los líderes del proyecto, ya no necesita una empresa consultora, solo buenos programadores.
Con Time & Material obtienes eficiencias similares a las de Scrum, con la ventaja de que puedes pedir los programadores a varias empresas. Así el proceso de reclutamiento de consultores es más rápido, una ventaja importante en un entorno donde cada vez es mas difícil encontrar programadores.
Como conclusión, Time & Material es posiblemente el modelo más eficiente para construir sistemas informáticos, por delante de Scrum y a años luz de los proyectos a precio cerrado. Por eso es todavía uno de los modelos más empleados a nivel mundial.
7 motivos por los que es difícil reinventarse
Reinventarse es difícil
Hay conceptos que están de moda; reinventarse, transformación digital, pivotar, emprendimiento… Parece que si no te estás reinventando, estás poniendo en peligro tu vida profesional.
Cientos de libros y miles de artículos de internet te explican cómo liderar con éxito esta transformación. Pero pocos analizan por qué es difícil reinventarse, sobre todo cuando tienes muchos años de experiencia.
Creo que es necesario llenar ese vacío para que, llegado el momento, comprendas esas fuerzas que bloquearán tu transformación.
Escribo este texto en nuestro 26 aniversario. Nuestros consultores están encantados con su experiencia novanotio, somos la consultora de referencia de nuestros clientes y buscamos más ingenieros de los que conseguimos encontrar. Sin embargo, es cuestión de tiempo que una disrupción digital arrase nuestro sector.
Una situación perfecta para reinventarse, pivotar y hacer una transformación digital, ¿verdad?
7 motivos por los que es difícil reinventarse.
1. La pereza de la sabiduría.
Gracias a nuestra experiencia, somos conscientes de las enormes dificultades de realizar una nueva actividad empresarial. No es que creamos que va a haber problemas, es que conocemos con detalle cada uno de los obstáculos que vamos a encontrar.
Siempre digo que creamos novanotio porque no sabíamos que era imposible.
2. El conocimiento estadístico.
Solo un pequeño porcentaje de las start-up consigue alcanzar el éxito, -si entendemos como éxito colocar tus acciones a una multinacional-. El porcentaje de emprendedores que consigue beneficios es todavía menor.
Cuando estás acostumbrado a dar resultados, embarcarse en una aventura con probabilidad de éxito inferior al 1% es poco motivador.
3. El cambio del foco de actividad.
No tiene sentido quemar tu dinero si el porcentaje de éxito es inferior al 1%.
Así que, cuando emprendes o te transformas o pivotas, tu foco pasa de resolver el problema de tu cliente a levantar dinero en rondas de financiación.
Y creo que somos solventes creando soluciones tecnológicas, pero muy torpes pidiendo dinero. ¿De verdad queremos dedicarnos a algo que se nos da francamente mal?
4. El coste de oportunidad.
Cuando tienes una empresa optimizada para realizar una función, pues eso, está optimizada. Si dedicas tiempo a otras actividades es a costa de la atención a tus clientes actuales.
¿Vas a sacrificar la calidad de tu trabajo persiguiendo unos beneficios que no llegarán en el 99% de los casos?
5. El Retorno de Inversión o ROI
Da igual si el dinero es tuyo o de inversores, todos queremos que el retorno de inversión sea rápido.
Y en nuevas actividades empresariales, el retorno de inversión típico está en torno a los cuatro o cinco años. Es sencillamente demasiado tiempo.
Sentirás la presión de tus inversores o, peor incluso, la tuya propia. No es una sensación agradable.
6. El peso de tus errores
Acabo de superar la barrera de los 50. En este tiempo he tenido -como todo el mundo- éxitos y fracasos.
Sin embargo, nuestro cerebro está diseñado para recordarte tus fallos, para que no los olvides, para que aprendas de ellos. Un impresionante avance evolutivo que nos ha colocado en la cúspide de la pirámide alimenticia, a costa de nuestra felicidad.
Con el paso de los años, el peso de nuestros errores se vuelve abrumador. Te sientes como Sísifo empujando una piedra que crece con cada iniciativa estéril.
Como medida de autoprotección, te centras en conseguir éxitos, en hacer lo que sabes que sabes hacer bien. ¿Quién quiere arrastrar una piedra cada vez mas pesada?
Lo llaman zona de confort.
7. La falta de pasión
Si vas a enfrentarte a tu sabiduría, luchar contra la probabilidad y quizás arrastrar el peso de otro fracaso, necesitas encontrar un desafío que te apasione. Y no es fácil encontrar un problema tan seductor que te empuje fuera de tu zona de confort.
Reinventarse es cambiar pájaro en mano por ciento volando. Si la principal cualidad de un emprendedor es la resiliencia, la pasión es el combustible que alimenta su energía.
Por eso es más fácil reinventarse cuando eres joven. No es que tu piedra de Sísifo sea más liviana, es que es más fácil enamorarse.
Marc Andreeseen, uno de los pensadores más influyentes de Silicon Valley, da este consejo a los jóvenes: «No sigas tu pasión. En serio, ¡no sigas tu pasión! Es probable que tu pasión sea más tonta e inútil que cualquier otra cosa. Tu pasión debe ser tu pasatiempo, no tu trabajo. Dedícate a ella en tu tiempo libre.»
Marc sabe que cuando tienes experiencia, no te hacen falta advertencias sobre la pasión.
Funciones del líder técnico en la era SCRUM
El líder técnico en la era SCRUM. Las funciones de un rol condenado a desaparecer
El rol de líder técnico es la carrera profesional más deseada por los jóvenes ingenieros informáticos. En este artículo vamos a estudiar su historia, sus vías de crecimiento profesional y cómo se transforman sus funciones con la llegada de SCRUM.
Un poco de historia
El líder técnico es el primer rol de liderazgo que surge en las empresas tecnológicas, junto con el de analista/programador. En los albores de la informática, era el responsable del diseño y la construcción de los sistemas.
Su misión original era extensa; entender las necesidades del cliente, hacer un primer diseño de alto nivel, preparar el diseño de bajo nivel, controlar los costes, determinar el alcance del sistema y, por supuesto, motivar y dirigir al equipo técnico.
Nuestro líder técnico terminó apoyándose en su ayudante, el gestor del proyecto. Un personaje gris al que delegó las aburridas tareas de control económico, interlocución con el cliente y motivación del equipo. Durante los años 80 del pasado siglo, el gestor del proyecto arrebató progresivamente el protagonismo y el reconocimiento al líder técnico y se transformó en el Jefe de Proyecto.
Funciones del líder técnico
El líder técnico mantiene dos de sus funciones originales, el diseño de bajo nivel y la supervisión del trabajo técnico.
El diseño de bajo nivel es su actividad preferida. Recibe del Business Analyst una especificación de alto nivel y la transforma en un conjunto de actividades más simples y detalladas que asigna a los diferentes equipos técnicos.
Brooks, en su clásico ‘The mythical man month’, nos advierte no existe un lenguaje de alta precisión para comunicar esas especificaciones de bajo nivel. Por eso es tan importante la segunda de sus funciones, el seguimiento de la actividad del equipo técnico. Sin esta supervisión, los analistas y programadores desarrollarían funciones diferentes a las especificadas.
El seguimiento del equipo técnico puede ocupar hasta el ochenta por ciento de su tiempo.
¿Cómo se llega a líder técnico?
Para ser un buen líder técnico necesitas un profundo conocimiento funcional del sistema y de su arquitectura, es decir, qué problema resuelve y cómo están construidos sus módulos. La única forma de adquirir estos conocimientos es participando en la construcción, por lo que el Líder Técnico suele ser uno de los programadores más veteranos.
A este rol se accede con paciencia. Como la permanencia media de un consultor en un proyecto es de 24 meses, en tres o cuatro años serás analista/programador y en otros tres o cuatro probablemente serás el líder técnico.
Crecimiento profesional del líder técnico
Ya eres líder técnico y tu equipo ha desarrollado con éxito varios proyectos. ¿Cuál es el siguiente paso de tu carrera profesional?
La evolución natural es hacia CIO/CTO, el responsable de los sistemas informáticos de la empresa, por tus conocimientos funcionales y tecnológicos.
Si has estado desarrollando un producto, lo mas probable es que acabes siendo el Product Manager. Tu misión será definir el roadmap de los futuros desarrollos.
Siempre puedes crecer hacia posiciones de Business Analyst, por tus conocimiento de las necesidades de los clientes.
Por último puedes crecer hacia Jefe de Proyecto, pero entonces toda tu experiencia anterior será inútil. Necesitarás desarrollar habilidades de motivación y negociación.
La desaparición del Líder Técnico en la era Scrum
La transición a las metodologías ágiles es un proceso complejo.
No basta con agrupar los equipos técnicos en squads y desarrollar en sprints de tres semanas. Es necesario que el cliente se involucre y participe de forma activa en el desarrollo, aportando un product owner al squad.
Y sobre todo es necesario que el cliente entienda que el alcance de los trabajos está abierto. La gran aportación de Scrum es cambiar la definición de éxito de un proyecto. ‘Desarrollar la mejor funcionalidad posible dentro de un plazo y con un presupuesto’.
Con la llegada de las metodologías ágiles, desaparece paulatinamente la figura del Líder Técnico.
No pueden ser el Product Owner, porque sólo el cliente conoce el retorno de inversión de cada desarrollo. Y los squads no necesitan un líder técnico, son los programadores los que deciden la arquitectura de sus módulos.
Con la llegada de SCRUM, el rol de líder técnico está llamado a desaparecer.
Fundamentos de SCRUM
Fundamentos de SCRUM
Es importante que domines los fundamentos de SCRUM si quieres implementar con éxito esta metodología.
Seguramente ya has leído libros y blogs que explican los diferentes procesos de SCRUM. El desarrollo en sucesivas iteraciones o sprints, el daily, el Sprint Planning, la retrospective, etc.
Si no conoces los fundamentos de SCRUM, lo mas probable es que cometas los mismos errores que la mayor parte de las organizaciones. Acabarás por implementar SCRUM como si fuera una religión y apenas conseguirás mejorar la productividad.
En novanotio defendemos que hay cuatro sencillas reglas que ayudan a gestionar con éxito los proyectos tecnológicos. Es una buena idea que revises nuestro artículo sobre las cuatro leyes antes de continuar con esta lectura.
En esta entrada vamos a analizar las relaciones entre las cuatro reglas básicas y los procesos de la metodología. Una vez que comprendas los fundamentos de SCRUM, estarás mejor preparado para implementarla en tu organización.
Relación entre SCRUM y la 1ª ley.
Las especificaciones son inciertas, imprecisas e infinitas.
La primera ley nos advierte tres cosas:
– Que el cliente no puede saber lo que quiere. El tiempo invertido en especificar suele ser tiempo perdido.
– Que una especificación redactada en lenguaje natural (castellano, inglés, alemán, etc.) es interpretable.
– Que no es posible finalizar los trabajos. Siempre queda algo por hacer.
¿Cómo responde Scrum a estos tres desafíos?
– El diseño es muy liviano; los requisitos se capturan en Epics, Features e Historias de Usuario, cuya extensión es de un párrafo.
– Para interpretar la especificación, se incorpora al squad un representante del cliente, el Product Owner,
– El Product Owner prioriza los trabajos para que el Retorno de Inversión sea el mayor posible, dentro del presupuesto.
Relación entre SCRUM y la 2ª ley.
One Project, One Team, One Site.
La segunda ley dice que para mejorar la productividad, todo el equipo de trabajo, incluido el cliente, debe estar en una única oficina y dedicarse en exclusiva al proyecto. La convivencia construye vínculos emocionales y relaciones de confianza que son imprescindibles.
¿Cómo construye Scrum los equipos?
En Scrum, los squads de desarrollo están formados por entre cinco y nueve consultores, cuyos puestos de trabajo están próximos entre sí. El Product Owner, que es el representante del cliente, es un miembro más del equipo.
Relación entre SCRUM y la 3ª ley.
Presión x Talento = Constante.
Talento y presión son antagónicos. Cuando uno crece, el otro disminuye.
La tercera ley nos recuerda que en el desarrollo de software debemos priorizar el talento sobre la presión. La velocidad de desarrollo depende del número de buenas ideas, no del número de horas de la jornada.
¿Cómo fomenta Scrum el talento?
Para eliminar la presión, en Scrum no es obligatorio completar todas las Historias planificadas para el sprint. Algunos desarrollos no superan los test y vuelven al backlog.
Relación entre SCRUM y la 4º ley.
El triángulo de Acero.
La cuarta ley nos enseña que Alcance, Plazo y Calidad están relacionados de tal forma que, si fijas dos de ellos, el tercero se degrada.
Tradicionalmente un contrato fija el alcance y el plazo. ¿El resultado? El 80% de los grandes proyectos son un fiasco.
Así que, como cliente, debes elegir entre:
– Sacrificar el Alcance. Ciertas funcionalidades no se construirán.
– Sacrificar el Plazo (y multiplicar el coste). El sistema se entregará muuucho mas tarde de lo planificado.
– Sacrificar la Calidad. El sistema tendrá errores en producción y será complejo de operar.
¿Qué variable sacrificamos en SCRUM?
La metodología SCRUM determina que la variable sacrificada es el Alcance.
La gran aportación de SCRUM es modificar la definición de éxito de un proyecto. Ya no tenemos que cumplir un alcance dentro de un plazo y con una buena calidad. Cosa que, por cierto, es imposible.
Éxito es conseguir el mayor retorno de inversión posible, dentro del presupuesto y en un plazo acotado.
¿Puedo mejorar la eficiencia sin usar Scrum?
Si conoces los fundamentos de Scrum, puedes utilizar los principios básicos de gestión de proyectos y mejorar el rendimiento de tus proyectos sin necesidad de implementar la metodología.
Pero SCRUM es la palabra de moda. ¡Aprende a implementar esta metodología y tu valor para el mercado se multiplicará!
Scrum no es una religión
Scrum no es una religión
SCRUM no es una religión. SCRUM es una forma de aplicar las Cuatro Leyes Básicas de la gestión de proyectos. El proceso de desarrollo Scrum es eficiente porque cumple estas cuatro reglas.
Si entiendes los fundamentos de la gestión de proyectos informáticos, puedes adaptar SCRUM, o cualquier otra metodología, a tu empresa.
Pero si no conoces estos fundamentos, corres el riesgo de implantar SCRUM en tu organización como si fuera una poderosa religión.
Y no encontrarás la tierra prometida.
Si adoptas SCRUM como si fuera una religión…
SCRUM es la religión de los elegidos
Scrum es todopoderoso porque es la religión de los elegidos. Si quieres llegar a la tierra prometida de la tecnología, ese lugar idílico donde todos los proyectos finalizan en plazo, debes seguir puntualmente cada uno de sus ritos.
Ya en los tiempos olvidados de las tarjetas perforadas, los profetas Brooks y DeMarco nos advirtieron que los proyectos son tan complejos que podemos trabajar en ellos por los siglos de los siglos. Imbuidos por el espíritu, propusieron abordar la solución en sucesivas iteraciones, meditando junto al cliente tras cada una de ellas qué se ha conseguido y qué se debe hacer a continuación.
El ritual SCRUM que inspiraron es como sigue:
La Sagrada Firma
El Sumo Account Manager descubre una necesidad del cliente y prepara una oferta que tiene plazo y presupuesto definidos pero cuyo alcance queda indeterminado. Realiza sacrificios a Poseidón y ofrendas a Baco para que el cliente realice la Sagrada Firma.
La Sagrada Firma es el ritual más complejo y al que menos atención se presta en los Textos Sagrados. Los clientes no iniciados se resisten a comprometer presupuestos determinados a cambio de servicios indeterminados. No intentes explicarles que en los proyectos realizados según los heréticos ritos de Waterfall, donde el alcance si estaba definido, en media sólo se entregaba el 50% de lo especificado.
El Product Backlog y el Team Backlog
Tras la Sagrada Firma, el cliente unge a uno de sus acólitos con la pesada responsabilidad del éxito de la empresa. A partir de ahora todos le conocerán como el venerable Product Owner.
En un concilio entre cliente, Account Manager y Product Owner, describen el sistema en una docena de tarjetas sagradas de una extensión de algunos párrafos llamadas Epics y Features. Las sagradas tarjetas se exponen a los acólitos en un altar de corcho llamado Product Backlog para que sean para ellos fuente de inspiración.
En sucesivos aquelarres, el Product Owner y los programadores, descomponen Epics y Features en nuevas tarjetas llamadas Historias de Usuario, que tienen la forma ‘Como usuario <perfil de usuario> soy capaz de hacer <tarea> y así consigo <valor para el negocio> ’. Exponen su trabajo en un nuevo altar de corcho, el Team Backlog.
La implementación
Es el momento de comenzar los ritos de implementación.
El primero es formar la escuadra de desarrollo, con el Product Owner, un Scrum Master y entre cinco y siete consultores. Sus puestos de trabajo deben estar próximos entre sí y se encargarán de implementar de extremo a extremo las Historias de Usuario. Su sagrado apostolado incluye definir la arquitectura, hacer el diseño, codificar, probar, integrar y documentar.
Cada iteración comienzan con la ceremonia del Sprint Planning. El squad se reúne para decidir qué Historias de Usuario intentarán implementar durante el Sprint, que durará entre tres y cuatro semanas. El Product Owner sabe qué historias de usuario son prioritarias. La escuadra intuye su velocidad de ejecución.
Cada mañana, antes de la salida del sol, la escuadra se reúne para maitines, rito también conocido como daily. Durante el resto del día, diseñan las Historias de Usuario, las codifican, desarrollan las pruebas unitarias y prueban el software construido. Sólo si el código supera las pruebas se considera apto para depositar a los pies del cliente e implorar su aceptación.
El Product Owner ayuda a los programadores a interpretar las sagradas Historias de Usuario. El Scrum Master vela por la pureza de los rituales.
El Sprint Review
Finalizado el Sprint, el squad celebra el Sprint Review, ceremonia en la que el código desarrollado se ofrece al cliente y las Historias de Usuario que no se han completado se devuelven al team backlog.
El Sprint Retrospective
El acto final es el Sprint Retrospective. Aquí Product Owner, programadores y testers reconocen sus faltas y hacen propósito de enmienda, con el fin de ser más productivos en próximas iteraciones.
Que los Dioses te sean propicios
Sigue religiosamente este ritual y alcanzarás la tierra prometida con la bendición de los Dioses.
Los peligros de imponer SCRUM a tu organización como si fuera una religión
Los ritos de SCRUM son folclore, comportamientos llamativos que emplean otras organizaciones. Desconocemos su significado, pero hay cientos de artículos describiendo su éxito y son tentadores de imitar.
Un ejemplo de imitación del folclore. Una organización que compró una mesa de billar, pero despidió a un consultor por ir al médico. ¿Veis a lo que me refiero? Si te despiden porque estás enfermo y vas al centro de salud, ¿cuál será el castigo si estás sano y dejas de trabajar para hacer carambolas?
Si no conoces las reglas básicas de la gestión de proyectos, corres el riesgo de implantar SCRUM como si fuera una religión, y cometer los mismos errores que buena parte de las organizaciones.
Y entonces no llegarás a la tierra prometida.
Errores más frecuentes al implantar Scrum
Errores más frecuente al implantar Scrum
Vamos a repasar en este artículo los errores más frecuentes al implantar Scrum y sus consecuencias.
Muchos de los proyectos en los que participamos han comenzado su transición a las metodologías ágiles. El resultado más visible es que hacen ‘sprints‘ de tres o cuatro semanas, pero los incrementos de productividad siguen siendo una promesa. Los proyectos continúan con sus dinámicas previas.
Y tiene sentido. ¿Por qué hacer el mismo trabajo en bloques de tres semanas va a mejorar la productividad? Scrum es mucho mas que sprints o tableros con post-it.
Estos son los errores más habituales al implantar Scrum:
1. No subir los desarrollos a producción después de cada sprint.
Quizás el error más frecuente y también el más importante. Asume que tu cliente no puede saber lo que quiere y que tendrás que modificar el trabajo realizado. Cuanto antes descubras lo que en realidad necesita, más productivo será el proyecto.
Además, como la inversión económica de un sprint es pequeña y tu cliente utiliza las nuevas funcionalidades en tres semanas, su retorno de inversión -ROI- es mucho más rápido. Música celestial para cualquier CFO.
En las metodologías tradicionales los desarrollos se entregan al final del proyecto. Esto no solo retrasa el ROI. Comienzas las modificaciones cuando ya no queda presupuesto.
La única forma de comprobar que has acertado es poner el software en manos de sus usuarios finales.
2. Obligar a que se finalicen todos los trabajos planificados para el sprint.
El segundo error clásico. Si te has equivocado en el sprint planning y no es viable finalizar los trabajos, ¿cuáles son las posibles opciones?
a) Puedes pedir al equipo que haga un sobreesfuerzo y trabaje más horas.
b) Puedes rebajar la calidad y no hacer las pruebas de regresión.
c) Puedes rebajar el alcance y entregar menos desarrollos.
Por inercia cultural, la mayor parte de los proyectos comienzan por la opción a) y terminan por añadir la opción b). Scrum establece que la respuesta mas apropiada es la c).
Buena parte de los incrementos de productividad asociados a Scrum proceden de eliminar la presión de trabajo de los consultores.
3. No tener un Product Owner integrado en el equipo.
El Product Owner es una figura esencial en Scrum, y es otra de las vías del incremento de productividad.
Los programadores trabajan sin una especificación detallada, así que constantemente tienen dudas sobre la funcionalidad a desarrollar. Es necesario que alguien procedente del cliente les explique las Historias de Usuario.
El Product Owner es también el guardián del ROI. No sabe programar, pero entiende el valor que aporta cada Historia al negocio. Si prioriza adecuadamente los desarrollos, conseguirá un mayor retorno de inversión en cada iteración.
Si el Product Owner no está con su squad, los programadores no interpretan bien las Historias, las modificaciones son más frecuentes y el valor para el negocio de cada sprint es menor.
¿Hay más errores típicos?
Aunque estos sean los tres errores más frecuentes al implantar Scrum, hay otros muchos que puedes cometer. Sin ánimo de ser exhaustivos:
Hacer una especificación pesada.
En Scrum se pasa de una idea de alto nivel al desarrollo que hacen los programadores. ¿Para que emplear meses en una especificación detallada si damos por sentado que el cliente no puede saber lo que quiere?
Solicitar que el cliente valide la especificación.
Aunque el cliente firme la especificación, sigue sin ser lo que necesita. Y lo sabe. Tu equipo puede estar valiosas semanas esperando a que el cliente dé su consentimiento. ¿No es mejor emplearlas en desarrollar un prototipo?
Mantener las jerarquías dentro de los equipos.
Ni el Jefe de Proyecto se transforma en Product Owner ni el Líder Técnico en Scrum Master. La figura del Líder Técnico desaparece. Los programadores colaboran desde un plano de igualdad y ninguno impone su criterio a los demás.
El Jefe de Proyecto también se difumina porque ya no es necesario negociar alcance y plazo de cada desarrollo.
No automatizar las pruebas a la vez que se hacen los desarrollos.
Si no automatizas las pruebas, ¿cómo piensas hacer DevOps? No podrás hacer pruebas de regresión y con cada sprint tus desarrollos tendrán menor calidad.
Tener a los equipos separados geográficamente.
No es solo que no puedan hacer el daily. Recuerda que los equipos están creando la especificación a la vez que hacen el desarrollo. Si están separados ¿cómo van a construir ese conocimiento?
No hacer retrospective.
Celebrar los éxitos del sprint y analizar los puntos de mejora aporta cohesión y les permite crecer como equipo. Potencia estos momentos de reflexión para que crezcan en la aplicación de la metodología.
Algunas reflexiones finales
Si has llegado hasta aquí, es porque te interesa la ingeniería del software. Te dejo algunas reflexiones y enlaces para que prosigas tu crecimiento.
Lo primero que debes entender es que el software es diferente al resto de disciplinas de la ingeniería por muchos motivos. Quizás los dos más importantes son:
- Es mucho más complejo describir el comportamiento de un sistema software que de cualquier otro sistema ideado por ingenieros, ya sea un vehículo eléctrico, un puente, un edificio o un compuesto químico. Por eso decimos que el cliente no puede saber lo que quiere.
- No tenemos un lenguaje de alta precisión para describir el software. Por contra, el resto de ramas de la ingeniería disponen de los planos, las matemáticas y la física. Por eso decimos que el cliente no puede decirnos lo que quiere.
No es de extrañar que la tasa de fracaso de los grandes proyectos de software sea del 80%. Esta cifra se mantiene estable desde los años 70. Y es el motivo de la aparición de Scrum.
Así que olvídate de gestionar los desarrollos informáticos como si fueras un ingeniero. Quema tu apuntes de ITIL. Necesitas un enfoque que incluya la psicología. Tu punto de partida es Peopleware, de Tom de Marco. Puedes acceder a su ficha en la wikipedia haciendo click sobre estas palabras verdes.
En novanotio explicamos a nuestros consultores estos conceptos que necesitarán a lo largo de su carrera profesional. Si la gestión de proyectos o el liderazgo de equipos despiertan tu curiosidad, quizás quieras descubrir nuestro proceso de mentoring Novanotio Certified.
Tal vez sea un buen momento para incorporarte a uno de nuestros proyectos y establecer los cimientos de tu carrera con nuestro proceso de mentoring. Este enlace te lleva a algunas de nuestras ofertas de trabajo, espero que encuentres una perfecta para ti.