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!
Salidas profesionales de la ingeniería informática
Salidas profesionales de la ingeniería informática
En esta serie de artículos vamos a analizar las posibles salidas profesionales de la ingeniería informática.
Hemos incluido este tema en nuestro mentoring Novanotio Certified porque buena parte de los jóvenes consultores no tienen claro hacia dónde orientar su trayectoria. Quieren más responsabilidad y, por supuesto, quieren mas dinero. Pero no tienen claro a qué responsabilidad se refieren. Ni cuánto les va a costar ese dinero.
Cuando les preguntamos, la mayor parte responde que quieren llegar a ser ‘responsables de proyecto’ o ‘gurús tecnológicos’. Como veremos, hay varios tipos de ‘responsables de proyecto’. Y también algunos riesgos en la carrera de los ‘gurús tecnológicos’.
Estas son, a grandes rasgos, las cuatro posibles vías profesionales de los ingenieros informáticos.
La carrera tecnológica pura
Nunca te va a faltar trabajo.
Es la puerta de entrada. Todos empezamos programando, administrando sistemas o haciendo hacking ético.
Es también la trayectoria profesional más agradecida. Todos los años incrementas tus conocimientos y tu valor para el mercado. Cada vez eres capaz de asumir retos más complejos. Todas las semanas recibes docenas de ofertas laborales. Tengas la edad que tengas nunca te va a faltar trabajo. ¿No es genial?
Lo difícil de la carrera tecnológica es no salirse de ella. Frases como ‘Hazte cargo de estos becarios’ o ‘Acompáñame a visitar al cliente’ son resbaladizos toboganes por los que alejarte de la consola.
Con perseverancia, pasarás de Becario a Consultor Junior, Consultor Senior y, finalmente, Especialista Tecnológico. Hay algunos baches al final del camino, en este artículo te explicamos por qué tu salario como Especialista Tecnológico tiene un límite.
Los líderes técnicos
La carrera que se desvanece
El liderazgo tecnológico es una de las trayectorias preferidas por los jóvenes consultores. Diseñar los sistemas y ayudar a los equipos técnicos a construirlos.
Aquí se llega con poco de paciencia. Con la rotación de nuestro mercado, cuando llevas cuatro o cinco años desarrollando un módulo eres quien mejor lo conoce. Cuando se incorporan nuevos programadores, ¿quién mejor que tu para explicarles por dónde empezar?
¿Qué ocurre en el siguiente paso? Cuando te conviertes en el líder técnico de todo un gran proyecto, conoces muy bien tu módulo y desconoces todos los demás. Ya no puedes ayudar al resto del equipo en su labor técnica.
A partir de aquí, creces en el conocimiento funcional de los sistemas, pero desconoces los detalles de su implementación. Jefes de Programa, CIOs, CISOs y CTOs son líderes técnicos que cada vez saben menos de tecnología.
Por eso el liderazgo tecnológico es una carrera que se desvanece. En el proceso de desarrollo Scrum, la responsabilidad del diseño es de los squads de desarrollo. En buena parte de las empresas, los CIOs, CISOs y CTOs ya no reportan al CEO sino al director de operaciones.
Los gestores
A mayor responsabilidad, menor empleabilidad.
La carrera de gestión es la gran desconocida. En el imaginario colectivo, las funciones del Jefe de Proyecto se mezclan y confunden con las de los líderes técnicos. Buena parte de los gestores creen que su responsabilidad incluye el diseño funcional y la arquitectura del sistema. Error.
El Jefe de Proyecto es en realidad un firewall. Sus tres desconocidas funciones son:
- Cobrar al cliente cuando todavía queda muuucho por hacer.
- Proteger a los técnicos de la presión del cliente.
- Motivar a los consultores y mediar en sus conflictos.
Ya lo se. Si tenéis algo de experiencia, casi puedo escuchar vuestras risas según escribo estas palabras.
Como veis, son necesarias habilidades de psicología y negociación. Vuestros preciosos conocimientos técnicos no os van a servir de ayuda. Las únicas matemáticas que vais a usar son los tantos por ciento.
Por encima del Jefe de Proyecto aparecen las figuras del Gerente y finalmente el Director de Operaciones, también conocido como COO. Más capacidad de negociación, más tantos por ciento y menos ofertas de trabajo. En el área de gestión, a mayor responsabilidad, menor empleabilidad.
Las ventas
Aquí
En una empresa, no pasa nada hasta que alguien vende algo. La función de ventas es el motor de la empresa.
En este área son fundamentales las habilidades de comunicación y de influencia. Tu trabajo se resume en mirar a tu cliente a los ojos, señalar la línea de puntos y decir ‘aquí’. Si estampa su firma, te has ganado tu comisión y toda la empresa se pone en marcha.
Pero antes de esa firma sobre la línea de puntos tienes que superar algunos obstáculos.
- Debes convencerle de que tu organización posee los conocimientos para poder ayudarles. Te ayudará haber pasado unos años en el área técnica.
- Tendrás que mejorar los precios de la competencia. ¿Cómo pueden ir siempre por debajo de costes?
Llegará un momento en que, para conseguir tu comisión, aceptarás plazos imposibles y presupuestos ridículos. No vas a tener muchos amigos en el resto de la compañía.
Sobre Preventas, Business Analyst y Account Managers aparece el Director de Desarrollo de Negocio o CBDO. Su misión es consolidar los mercados ya conquistados y descubrir nuevos nichos de oportunidad. Todo un reto en un sector que está en permanente revolución tecnológica.
¿Qué carrera es mejor para mi?
Ahora ya conoces las cuatro salidas profesionales de la ingeniería informática. ¿Cómo decidir cual es la más adecuada para tí?
Los programadores estamos acostumbrados a la estrategia de prueba y error. Pruebas un área y, si no te gusta, vuelves a la programación.
No es tan sencillo. La responsabilidad es una droga que crea dependencia. Una vez que la has probado no es fácil dejarla. Conozco pocos casos en que, tras una mala experiencia, alguien haya solicitado un paso atrás.
En este artículo explicamos cómo descubrir qué carrera puede ser la mejor para ti, usando el test de fortalezas de Gallup. Quizás deberías leerlo antes de deslizarte por alguno de los toboganes.
¡Mucha suerte en tu aventura profesional!
Las cuatro leyes de la gestión de proyectos tecnológicos
Las cuatro leyes de la gestión de proyectos tecnológicos.
Estas cuatro sencillas reglas son la base de la gestión de proyectos tecnológicos.
Son solo 35 palabras, pero necesitarás algunos años para dominarlas y aplicarlas correctamente. Si deseas convertirte en un buen Jefe de Proyecto, serán tu credo. Apréndetelas de memoria y practícalas cada día.
1ª ley. Las especificaciones son inciertas, imprecisas e infinitas.
La primera ley es la responsable de que fracase el 80% de los grandes proyectos informáticos en todo el mundo. Esta cifra se mantiene estable desde los años 60 hasta hoy. Las nuevas herramientas de desarrollo y las diferentes metodologías no han conseguido mitigar este desastre.
Nos avisa de que el cliente no puede saber lo que quiere. Los sistemas informáticos son demasiado complejos. La especificación siempre estará incompleta. Por eso son inciertas.
Nos advierte de que no existe un lenguaje de alta precisión para comunicar las instrucciones técnicas. Los arquitectos disponen de los planos, un lenguaje de muy alta precisión. Los ingenieros informáticos sin embargo usamos el lenguaje natural, que es interpretable. Por eso son imprecisas.
Nos alerta de que un proyecto nunca termina. Siempre quedan errores que corregir y mejoras por implementar. ¿Alguna vez has puesto la última línea de código de un programa? Por eso son infinitos.
Cómo usar la primera ley:
- Especifica menos y haz más prototipos.
- Relaciónate más con tu cliente.
- No discutas el significado de un párrafo.
- ¡Haz que abone las facturas cuando todavía queda mucho por hacer!
2ª ley. One project, one team, one site.
Como el cliente no puede saber lo que quiere, y no disponemos de un lenguaje de alta precisión, las relaciones personales cobran especial relevancia.
La especificación se construye según avanzan los desarrollos, y los vínculos emocionales son la clave para distribuir ese conocimiento.
La segunda ley nos indica cómo construir esos vínculos. Los analistas funcionales, programadores, testers e incluso el cliente deben estar en la misma sala. Y mucho mejor si cada consultor trabaja en exclusiva para el proyecto.
Las software labs, las organizaciones matriciales y los equipos distribuidos son ineficientes.
Un apunte de Franz Hassmann, CTO de BBVA Next. Mejor si los equipos son pequeños, de entre 5 y 9 componentes.
3ª ley. Presión x Talento = Constante.
Durante miles de años hemos dirigido organizaciones gestionando la presión. Con el nacimiento de la informática necesitamos, por primera vez en la historia, gestionar el talento.
La tercera ley anticipa que si incrementas la presión de trabajo, disminuye el talento y los desarrollos se retrasan.
Así que olvídate de los bonus por objetivos y de exigir horas extras. Esas son herramientas de gestión de la presión.
Debes gestionar el talento. Ofréceles retos. Usa el feedback positivo. Bloquea la presión del cliente y deja que el equipo encuentre su ritmo de trabajo.
4ª ley. Alcance, Plazo y Calidad. Si fijas dos de ellas, la tercera se degrada porque es la variable de ajuste.
Recuerda, las especificaciones son infinitas.
Así que algo tienes que sacrificar. Puede elegir entre el alcance (entregar menos producto), el plazo (retrasar las entregas) o la calidad (entregar algo sin apenas pruebas).
La cuarta ley nos propone que alcance, plazo y calidad están interrelacionados. Si fijas dos de ellos, el tercero se degrada.
Nunca, nunca, nunca sacrifiques la calidad. Nunca fijes alcanzo y plazo.
SCRUM por ejemplo fija plazo y calidad, el alcance queda indeterminado. Se factura por cada sprint.
TIME & MATERIAL, los servicios profesionales de toda la vida, fijan alcance y calidad, y es el plazo el que queda indeterminado. Se factura mensualmente por el esfuerzo dedicado.
Si haces PROYECTOS CERRADOS, perderás dinero en el 80% de los contratos.
Enlaces de interés
Son solo cuatro reglas sencillas de aprender. Sin embargo, muchas organizaciones todavía preparan extensos documentos funcionales, deslocalizan parte de los equipos y trasladan la presión del cliente a sus desarrolladores.
Os dejo los enlaces a las fuentes de las cuatro leyes. Si comprendéis los fundamentos de cada una de ellas, os será más sencillo adaptarlas a vuestra organización.
La primera ley tiene su origen en ‘The mythical man-month’ de Brooks. Quizás el primer libro sobre ingeniería del software. Escrito a finales de los sesenta y una referencia obligada a día de hoy. Se complementa con ‘Introducción a la PNL’ de Seymour, un libro sobre psicología del lenguaje.
La segunda ley procede del fantástico libro ‘Peopleware’ de DeMarco. Posiblemente el primer ensayo sobre programación y productividad. Muy entretenido.
La tercera ley procede de un clásico sobre la motivación. ‘Drive’ de Daniel H. Pink. Igualmente divertido y ágil.
La cuarta ley procede tanto del libro de Brooks como de ‘Agile Software Requirements’ de Dean Leffingwell. No son fáciles ninguno de los dos, pero merece la pena el esfuerzo.
Te animo a compartir con todo nuestro sector tus experiencias en los proyectos en los que has participado. ¿Se han cumplido las cuatro leyes? ¿Añadirías alguna más?
¡Suerte en tu carrera de gestión de proyectos tecnológicos!
Cómo orientar tu carrera profesional usando el test de Gallup
Cómo orientar tu carrera profesional usando el test de Gallup
En el entorno tecnológico es fácil tener una primera promoción
Estás haciendo un gran trabajo como programador, y como premio te han propuesto cambiar de actividad. Quizás te han pedido que lideres a un grupo de consultores. O tal vez que asistas a una reunión de ventas.
En el entorno tecnológico es fácil tener una primera promoción. Descubrirás que hay roles que te son tan naturales cómo respirar y otros en los que, a pesar de tu esfuerzo, sólo recibes disgustos. ¿Cómo saber si la jugosa manzana que te ofrecen está envenenada?
El test de fortalezas de Gallup
Vamos a estudiar cómo orientar tu carrera profesional usando el test de fortalezas de Gallup. Si todavía no lo has hecho tienes el enlace aquí. Considera estos veinte dólares como una de las mejores inversiones de tu vida.
Este test te descubre tus principales fortalezas, es decir, los tipos de talento que has desarrollado de forma natural. Gallup distingue entre treinta y cuatro fortalezas que se agrupan en cuatro ámbitos:
- Fortalezas de ejecución. ¿Qué es lo siguiente que tengo que hacer? Si tu única recompensa es un trabajo bien hecho o no puedes dejar una tarea a medias, eres un auténtico ejecutor.
- Fortalezas de pensamiento. ¿Cuál es la mejor forma de hacer las cosas? Si no puedes dejar de estudiar o tienes una potente capacidad analítica eres todo un pensador.
- Fortalezas de relación ¿Cómo construyo relaciones? Si rápidamente sabes cómo son las personas, o para ti lo más importante es el ambiente de trabajo, tienes este tipo de fortalezas.
- Fortalezas de influencia. ¿Cómo consigo convencer a los demás? Si siempre tienes en la boca la palabra adecuada considérate un influencer.
¿Qué fortalezas ayudan a desempeñar los distintos roles tecnológicos?
No todos los roles tecnológicos precisan de las mismas fortalezas. Según el resultado de tu test de Gallup, te sentirás más cómodo en unos u otros puestos.
Si tus fortalezas son de pensamiento y relación
En los primeros test de Gallup que realizamos, descubrimos que los mejores programadores combinaban fortalezas de pensamiento y relación.
Pronto nos dimos cuenta que, para programar, los vínculos emocionales son muy importantes, porque facilitan la construcción de las especificaciones y la coordinación de las tareas.
En resumen, si tus principales fortalezas son de relación y pensamiento, la programación se te dará bien de forma natural.
Si tus fortalezas son de pensamiento
Sin embargo, si la mayoría son de pensamiento, estarás más cómodo en roles con más complejidad y menos relación, como la administración de sistemas o la ciberseguridad.
Si tus fortalezas son de relación
Si tus fortalezas son sobre todo de relación, busca trabajos donde tengas que estar en contacto con el cliente. Los roles de soporte combinan una parte de conocimiento técnico y mucha relación con los usuarios de las aplicaciones y sistemas.
Si tus fortalezas son de relación e influencia
Si a las fortalezas de relación se suman las de influencia, tu sitio está en el área de ventas. Aquí tu misión es crear un vínculo con el cliente y convencerle de que ponga una firma. ¡Como pueden pagar esas comisiones por un trabajo tan sencillo!
Si combinas fortalezas de pensamiento e influencia
La combinación de pensamiento e influencia es interesante para liderar equipos. Te sentirás cómodo en las posiciones de Líder Técnico, Jefe de Proyecto o Gerente.
Si tus fortalezas son sobre todo de influencia
Cuantas más fortalezas de influencia aparezcan en tu test de Gallup, más cómodo te sentirás con cada ascenso. Director de Operaciones, CIO, CTO… El cielo es el límite.
Si la mayoría de tus fortalezas son de influencia, tu sitio está en la alta dirección. Algunos te llamarán trepa o pisacuellos. Bueno, quizás no has sido el mejor técnico, pero siempre sabes lo que tienes que decir. Y esas fortalezas te empujarán a los roles que empiezan por C.
¿En qué organizaciones encajarás mejor?
Si tus fortalezas son sobre todo de pensamiento, estarás más cómodo en organizaciones con cultura Growth Mindset.
Por el contrario, si son de ejecución o influencia, busca empresas de tipo Fixed Mindset.
En este artículo de nuestro blog analizamos las diferencias entre ambos tipos de liderazgo.
Alinea tu trayectoria con tus fortalezas
Cuando tu trayectoria profesional está alineada con tus fortalezas, te pagan por hacer lo que se te da bien de forma natural. En el caso contrario también puedes hacer un trabajo brillante, aunque a costa de un mayor esfuerzo y desgaste personal.
¿Quieres saber que actividades son mas adecuadas para ti? Envíame el resultado de tu test de fortalezas y te daré algunas ideas para orientar tu carrera.
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.