Posts Tagged

Buenas Prácticas

PRINCE2 Agile

A la hora de llevar a cabo un proyecto software, nos podemos encontrar organizaciones que únicamente emplean los roles y técnicas propias de las metodologías Ágiles, otras que, en cambio, siguen un modelo clásico en cascada – con un Jefe de Proyecto como cabeza visible del mismo – y finalmente, aquellas que siguen un modelo híbrido en el cual combinan, o lo intentan, elementos de ambos mundos.

Una de las metodologías de gestión de proyectos más populares es PRINCE2, que ante la irrupción de la Agilidad en el mundo empresarial, ha decidido quitarse la etiqueta de «metodología para proyectos tradicionales en cascada», apostando por una combinación de los principios, comportamientos y técnicas Ágiles con los principios, temas (áreas de conocimiento), y procesos de PRINCE2. Es para ello que AXELOS, la organización que gestiona el cuerpo de conocimiento de PRINCE2,  ha elaborado PRINCE2 Agile.

¿Pero, por qué querría una organización que usa metodologías Ágiles incorporar PRINCE2 a su metodología de trabajo o viceversa? Según AXELOS, las metodologías Ágiles pueden ser muy efectivas en la construcción de un producto, pero son insuficientes para gestionar un proyecto, especialmente si este reviste cierta complejidad. Y es aquí donde entra en juego PRINCE2 Agile. Hay que aclarar que este no es un intento de crear una nueva metodología que intente sustituir a PRINCE2, sino que es una orientación o conjunto de buenas prácticas para combinar la Agilidad con la Gobernanza a la hora de llevar a cabo un proyecto software.

prince2agile.wiki

Un proyecto según PRINCE2 consta de tres niveles en la toma de decisiones: Dirección del Proyecto, Gestión del Proyecto y Entrega del Producto. Es en esta última capa donde mejor encajan las metodologías Ágiles como Scrum, Kanban etc. Si entendemos la Agilidad como una escala en la cual podemos movernos y no como algo binario, una empresa que aplique PRINCE2 Agile se encontrará en algún punto intermedio de la misma. Este grado de Agilidad vendrá determinado por el llamado Agilómetro, que no es más que un conjunto de indicadores – flexibilidad en las entregas, nivel de colaboración etc. – a los cuales debemos asignar una puntuación de 1 a 5 al inicio del proyecto, para saber de dónde partimos, cómo adaptar mejor PRINCE2 y qué acciones correctoras podemos tomar para mejorar estos indicadores.

Axelos

Sin embargo, por mucha Agilidad que quiera aplicarse, deben establecerse algunos límites si queremos seguir aplicando PRINCE2. Así por ejemplo, aunque los equipos de desarrollo puedan tener bastante autonomía a la hora de entregar las funcionalidades pedidas, esta auto-organización nunca será completa. Serán el Jefe de Proyecto o la Junta del Proyecto, los que tengan la última palabra en las decisiones de mayor calado que puedan afectar al proyecto en su conjunto. Otro ejemplo sería la combinación de roles: PRINCE2 Agile nos ofrece varias alternativas para conjugar los roles de Scrum Master y Product Owner, con los clásicos de Jefe de Proyecto o Jefe de Equipo. Cada una de estas combinaciones será adecuada según el grado de Agilidad que queramos imprimir al proyecto, pero en ningún caso desaparece la figura del Jefe de Proyecto.

En definitiva, aunque el manual de PRINCE2 Agile hace algunas afirmaciones polémicas tales como que Scrum, u otras metodologías Ágiles, de por sí no son suficientes para gestionar un proyecto y que están enfocadas primordialmente al mantenimiento de productos y servicios (Business As Usual), su aplicación puede ser útil para aquellas organizaciones que quieran empezar a aplicar un cierto grado de Agilidad a sus proyectos, sin tener que modificar excesivamente su manera de trabajar.

Certificación

Por último, señalar que hay un examen oficial de AXELOS que te certifica como PRINCE2 Agile Practicioner, en el cual es necesario aplicar los conceptos y recomendaciones del libro a un caso práctico. No obstante, antes de poder realizar este examen hay que poseer la certificación PRINCE2 Foundation.

Nombre: PRINCE2 Agile
Autor:  AXELOS
Editor:  AXELOS
Año: 2015
Idioma: Inglés
Páginas: 356

EL Libro Negro del Programador

En «El Libro Negro del Programador», su autor Rafael Gómez Blanes, partiendo de su dilatada experiencia profesional, nos hace reflexionar sobre los hábitos, factores y circunstancias que pueden llevar a buen puerto un proyecto software o, por el contrario, arruinarlo. ¿Pero qué es llevar a buen puerto un proyecto software? ¿Cuándo consideramos que un desarrollo ha sido un éxito? ¿Nos referimos únicamente a entregarlo dentro del plazo y presupuesto estipulado? No, eso ya no es suficiente. En este sentido hay una definición en el libro software que me ha gustado mucho . Un proyecto termina con éxito cuando su resultado es un software fácil, y por tanto barato, de evolucionar y mantener.

Porque, tal y como señala el autor, ¿te gustaría comprar un coche que fuera una odisea mantener o reparar? Obviamente no. Pues con el software tampoco debería suceder. Respaldar el software con pruebas, aplicar patrones de diseño, seguir los principios de desarrollo SOLID etc. son prácticas que nos ayudan a prevenir que, con el paso del tiempo, modificar un producto sea tan caro que directamente salga más barato «tirarlo a la basura» y comenzar de nuevo. O lo que es lo mismo, nos ayudan a evitar el tan habitual principio de Pareto en la construcción de software: 80% del tiempo empleado en tareas de mantenimiento y un 20% en desarrollar nuevas funcionalidades.

En mi propia experiencia profesional, he podido comprobar esta falta de cultura en la realización de pruebas que comenta el libro. Primero porque en la mayoría de las ocasiones no se exigen, y segundo, y puede que más importante, porque no tenemos el hábito de realizarlas antes  – TDD – o después de construir una nueva funcionalidad. Además también resulta difícil justificar a tu responsable que buena parte de tu tiempo de desarrollo – en el libro estima que puede llegar a ser hasta más de la mitad – se va a emplear en desarrollar pruebas que, aunque inicialmente sean un coste de tiempo y dinero, realmente es una inversión, ya que el software tendrá menos errores y por tanto habrá que dedicar menos tiempo a corregirlos.

Desde un punto de vista de gestión del equipo, hay ciertos hábitos que favorecerán el éxito de un proyecto, como por ejemplo intentar mantener un ambiente relajado y de compañerismo, evitar las interrupciones constantes, intentar prevenir una alta rotación de los miembros del equipo o  no asumir como costumbre hacer horas de más en nuestra jornada laboral. Es por ello que en la opinión del autor, y en la mía también, un responsable de de proyecto software, debería, no ya ser ingeniero informático o haber desempeñado labores técnicas, pero sí al menos conocer la naturaleza del desarrollo de software y las peculiaridades que conlleva. La buena gestión de un proyecto software, al igual que aprender una nueva tecnología o un nuevo lenguaje de programación, es una habilidad que se puede aprender y perfeccionar con práctica y esfuerzo.

En definitiva, El Libro Negro del Programador es un libro que resultará útil , y además ameno, para cualquier persona vinculada al desarrollo del software y que desee continuar por el camino de la mejora continua en su profesión. A mí personalmente me ha motivado a seguir profundizando en las buenas prácticas que recomienda.

Nombre: El Libro Negro del Programador
Autor: Rafael Gómez Blanes
Editor: CreateSpace
Año: 2017 – Segunda Edición
Idioma: Castellano
Páginas: 236