Hubo un tiempo más tranquilo.
Hubo un tiempo en que los proyectos de tecnología en general, y de software en particular, se desarrollaban a otro ritmo e inmersos en otra cultura.
Hubo un tiempo en que los proyectos se planificaban.
Hubo un tiempo en que los proyectos eran complejos y, para gestionarlos, se idearon excelentes pero sofisticadas técnicas. Primero disponíamos de los diagramas de Gantt pero luego, con la construcción del misil balístico Polaris, apareció el PERT (Project Evaluation and Review Technique) que se acompañaría del método del camino crítico CPM (Critical Path Method). Los proyectos se descomponían mediante la técnica del WBS (Work Breakdown Structure) y se seguían con el método del valor ganado EVM (Earned Value Method).
Y en ese tiempo no tan remoto se desarrolló la disciplina de la ingeniería de software y se ideó el modelo en cascada. Se obtenían las necesidades de los clientes mediante un proceso de licitación que culminaba en el documento de especificación de requisitos; fase a la que seguía el análisis, el diseño y la codificación; y el resultado se verificaba y validaba mediante pruebas unitarias, de integración, de sistema y de usuario.
Y en ese tiempo, la admirable figura del jefe de proyecto ejercía su liderazgo mediante la autoridad, acompañada, eso sí, de la aplicación de sus conocimientos técnicos y de gestión y unas indudables habilidades personales.
Ese tiempo existió y mucho hemos aprendido de él. En realidad, no se ha ido del todo, y todas las técnicas anteriores gozan en general de validez, especialmente en ciertos ámbitos.
Pero ahora corren otros tiempos.
Y es precisamente de tiempo de lo que menos disponemos. Los cambios son constantes, los resultados deben ser rápidos, la gestión también… y por ello, especialmente en el mundo del software, gozan de creciente predicamento las metodologías agile.
En los nuevos tiempos 2.0 el cliente es el rey. El fenómeno de la "consumerización" ha puesto al consumidor, más allá del cliente, en el centro mismo de la actividad. En el mundo 2.0, además, nos hemos acostumbrado a interactuar, a comunicar en mensajes breves y en los que domina la narratividad, lo humano, las historias. Y quizá como reflejo de ambos fenómenos, en las metodologías agile no existe exactamente un largo documento de especificación de requisitos sino que lo que queremos de un sistema, lo que quieren los usuarios en realidad, se traduce en un conjunto de historias de usuario (user stories) que nos describen el sistema tal y como lo entienden y desean esos usuarios, bajo su perspectiva, en sus propias palabras. El conjunto de user stories constituye el backlog, algo así como la colección de deseos de los consumidores, las historias que quieren convertir en realidad.
En los nuevos tiempos somos impacientes, queremos interactuar y queremos feedback temprano. Y, quizá por ello, en las metodologías agile no se desarrollan grandes versiones, no se esperan largos tiempos para tener un resultado por brillante que éste pueda ser, sino que se trabaja en iteraciones cortas y frecuentes, iteraciones en cuyo alcance se incluyen unas pocas users stories y que se desarrollan en unos días, unas semanas a lo sumo. Es como un modelo en cascada pero muy acelerado. Se explicitan o seleccionan unas pocas historias de usuario, se desarrollan, se prueban, se obtiene feedback, se empieza de nuevo… rápido, rápido, rápido, ágil, ágil, ágil… y en permanente contacto con el usuario, con el cliente, con el consumidor… ingeniería de software a la velocidad de Internet.
Los jóvenes digitales, los nativos del mundo 2.0, están acostumbrados a la conversación, a la colaboración, al trabajo en equipo. Y por eso, en las metodologías agile la figura del jefe de proyecto se orienta más hacia un liderazgo 2.0 colaborativo, y actúa más como coach que como director o jefe. Se trabaja en equipo, en permanente interacción pero sin interminables reuniones. El trabajo del día se planifica en una reunión breve de unos 15 minutos (como las daily stand-up de la metodología Scrum) y la colaboración llega a extremos como los de la programación en parejas que propone eXtreme Programming (XP).
Scrum, eXtreme Programming, Lean Software Development, Kanban, Feature-Driven Development, Dynamic Systems Development Method, Crystal Clear… son distintas metodologías ágiles para una misma filosofía de hacer software y de gestionar proyectos.
Hubo un tiempo más tranquilo.
Hubo un tiempo en que los proyectos se planificaban.
Ese tiempo se ha ido.
Ha cambiado el consumidor, ha cambiado la cultura… y han cambiado los proyectos.
Ahora domina la velocidad.
Ahora los proyectos no se planifican sino que se conducen.
El mundo es dinámico y los proyectos adaptativos.
El mundo es ágil… y los proyectos… también…
Imagen: a2gemma
Soluciones y Sectores
Te puede interesar
-
Nodo IoT: el corazón de los edificios inteligentes en una smart city
Una ciudad se compone de edificios de todo tipo (residenciales, comerciales, industriales, públicos…) y para que se considere una ...
-
Una industria conectada es una industria sostenible
La industria manufacturera representa el 11,3% del PIB español pero es responsable del 24% del consumo energético y el ...
-
Radiografía de la experiencia de empleado en España
Las nuevas formas de trabajo suponen un cambio fundamental en la cultura de las organizaciones y una valiosa herramienta ...
