Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Gerente de Proyecto. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Gerente de Proyecto. Mostrar todas las entradas

viernes, septiembre 11, 2015

Gerencia de Proyectos Iterativos: de cómo el software se puede construir por incrementos

Divide et impera: ‘divide y vencerás’. Frase atribuida a Julio César.
FreeDigitalPhoto.Net
Los proyectos de construcción de software deben responder con prontitud a los cambios frecuentes e inesperados tanto en los requisitos del negocio como en la tecnología de implementación. Es habitual que en estos proyectos haya una gran incertidumbre en cuanto al alcance, a la fecha de entrega y al presupuesto requerido, lo que conlleva un alto número de riesgos que obstaculizan la consecución de los objetivos propuestos.
Por ejemplo, es un grave error con consecuencias atroces, asumir que los usuarios –generalmente personas de mandos medios y altos– son capaces de suministrar al equipo del proyecto información oportuna y precisa de todos los requisitos para un sistema de software. Además, uno de los problemas principales de la construcción de software tradicional recae en el hecho de que quienes han estado involucrados en ello hasta la fecha no están dispuestos a reconocer que esta actividad es, la mayoría de las veces, un asunto de planeación ocupacional y organizacional.
Corresponde precisamente al gerente del proyecto lidiar con todos estos factores que entorpecen la evolución normal de un proyecto de software. Es el gerente del proyecto quien sabe que los procedimientos tradicionales seguidos tienen un conjunto de riesgos tácitos “indetectables” dada la propia naturaleza del ciclo de vida de los proyectos. Los proyectos iterativos propician la detección temprana de los riesgos y facilitan su manejo anticipado por parte de los responsables. Pero ¿qué es realmente un proyecto iterativo? Para entenderlo, veamos lo fundamental.
¿Qué es una Iteración?
Una iteración es un mini-proyecto con una salida bien definida: una versión incrementada, estable, probada e integrada del producto de software, con su documentación asociada.
Esta definición lleva implícito un concepto muy importante: la versión o porción de software que se produce en una iteración tiene tales cualidades que se podría no solo mostrar al usuario sino poner en producción. De hecho, en fases avanzadas del proyecto, esto ocurre con regularidad; es decir, en un proyecto iterativo es posible tener versiones del software funcionando antes de terminar el proyecto.
Características de las Iteraciones
Ahora bien, como cualquier proyecto (de software), una iteración pasa por todas las etapas de un proyecto tradicional: inicio, planeación, ejecución y control, y cierre. En el caso particular de los proyectos de software, durante la etapa de ejecución y control de una iteración encontramos el ciclo tradicional del software: modelado de requisitos, análisis y diseño, implementación, pruebas, integración y, opcionalmente, despliegue, aunque una iteración no necesariamente cubre todas las etapas.
Pero la verdadera esencia de las iteraciones radica en otros aspectos que buscan disminuir la incertidumbre en los proyectos, aumentar el desempeño, mitigar los riesgos, sobre todo reducir los riesgos técnicos en las primeras iteraciones, y recibir retroalimentación continua y efectiva de los usuarios. El primero de estos aspectos es la duración de las iteraciones: de unos pocos días hasta unas pocas semanas es lo más eficaz, aunque también depende del tamaño del equipo y de la duración total estimada del proyecto.
Figura 1: esquema de una iteración típica. Cada iteración es un mini-proyecto con todo lo que ello implica.
Excepto quizás en proyectos grandes con más de 40 o 50 personas, la idea es no tener iteraciones de varios meses, ya que en ese tiempo puede ocurrir lo que sucede en los proyectos ejecutados en cascada: hay poca o ninguna mitigación de riesgos técnicos, puesto que no hay entregas “visibles” para los usuarios, recibimos poca retroalimentación de ellos y así no medimos eficientemente el progreso del proyecto, o no podemos reaccionar a tiempo ante una mala decisión técnica que conduzca a un retraso en el proyecto.
Duración de las iteraciones
Número de personas
Duración
2 a 15
2 a 4 semanas
15 a 30
4 a 6 semanas
30 a 50
6 a 8 semanas
Fuente: Bittner, K. Spence, I. Managing Iterative software Development Projects. Addison Wesley Professional. Junio 27, 2006.
Otro aspecto importante es que la duración de las iteraciones no tiene que ser la misma, pero la desviación debe ser pequeña. La idea es no tener iteraciones de dos semanas y otras de seis o más. Scrum, una metodología ágil ampliamente usada hoy día, por ejemplo, promulga iteraciones de 30 días, llamadas Sprint, con equipos de menos de 10 personas. Y ya que menciono Scrum, me parece importante aclarar que no todos los proyectos iterativos son ágiles, pero todos los proyectos ágiles son iterativos; la iteración es una propiedad intrínseca de las metodologías ágiles de construcción de software.
Gestión iterativa de proyectos
Otra de las características principales de este tipo de proyectos es que en las primeras iteraciones se construye la porción de producto que es significativa para la arquitectura del software. El gerente del proyecto se apoya en el arquitecto y en los ingenieros de requisitos para tomar la decisión de cuántas iteraciones “arquitectónicas” tendrá el proyecto, normalmente de 1 a 3, y qué funcionalidad será implementada, de tal manera que al final de esta fase (llamada de Elaboración, de Planeación o de Arquitectura, según la metodología que se use), no solo existe un documento de arquitectura o de diseño de alto nivel, sino que hay software funcionando cuyo propósito es demostrar que esa es la arquitectura correcta para el producto.
Figura 2: Perfil de los riesgos durante la gestión iterativa de proyectos. Los riesgos técnicos disminuyen en las primeras iteraciones. Contrario a lo que sucedía con el método en cascada, donde los riesgos disminuían al final del proyecto, durante las pruebas en el mejor de los casos.
La gestión iterativa de proyectos puede tomar muchas formas, dependiendo de las metas del proyecto: el desarrollo iterativo de prototipos puede ayudar a evolucionar una interfaz de usuario. El desarrollo ágil es una forma de involucrar muy de cerca un usuario en un proceso que podría repetirse diariamente. Entre tanto, el desarrollo incremental permite al equipo del proyecto a producir incrementos semanales o en cortos períodos de tiempo, mientras que un modelo en espiral puede ayudar al equipo a confrontar y a mitigar los riesgos de un producto en evolución.
En estos casos es el gerente del proyecto quien toma la decisión de la estrategia a seguir, teniendo en cuenta el valor de distintas variables: tamaño del proyecto, tamaño del equipo, experiencia del equipo y de los usuarios, criticidad y complejidad del proyecto, los riesgos técnicos y administrativos, el grado de volatilidad detectada de los requisitos y las herramientas de apoyo disponibles.
Foto de FreeDigitalPhoto.Net
La gestión iterativa ayuda a superar las barreras de especificación y de comunicación entre los usuarios y el equipo de trabajo con el único objetivo de alcanzar la más alta satisfacción de los primeros. El factor clave es precisamente que las personas del negocio entiendan los requisitos y retroalimenten a las personas de tecnología. En este apartado, el papel del gerente es de mediador, por lo que debería incluir elementos de comunicación efectiva, como la tolerancia –cuando no se confunde con la pasividad–, la imparcialidad y la empatía, para construir confianza y disciplina entre unos y otros.
Corresponde al Gerente del Proyecto integrar el equipo de trabajo con todos los involucrados tanto internos como externos y la gestión iterativa posibilita una integración paso a paso. Para lograrlo, el gerente del proyecto debe tener en cuenta algo que está fuera de su control: una infraestructura cambiante y un proceso de negocio inestable. También se debe vincular la estructura del proyecto (iterativo) con el éxito del proyecto, de esta forma, no habrá espacio para la ruina del proyecto.
Esto se logra mediante la motivación interna del equipo de trabajo, el desarrollo de competencias blandas (negociación, técnicas de comunicación –escrita, verbal y no verbal–, manejo eficaz del tiempo, creatividad, trabajo en equipo, entre otras) y la “implantación no invasiva de chips de alta efectividad”, como la proactividad y la sinergia.
Ahora bien, puede haber muchas desviaciones de un plan de proyecto de desarrollo de software. En estos casos, el gerente de proyecto decide cómo manejarlas, puesto que cada retraso requiere de una acción de su parte. Sin embargo, las opciones del gerente son muchas veces limitadas y una de las estrategias que puede seguir es esta de la agenda iterativa. Esto permite corregir o ajustar los planes de trabajo a medida que se desvían de las medidas iniciales.
Por ejemplo, si una iteración toma más tiempo del programado debido a un problema técnico que el equipo del proyecto tardó en responder o a la toma de una decisión por parte del usuario, el gerente puede reprogramar las iteraciones subsiguientes de tal forma que el plan original global del proyecto no se vea afectado.

En cualquier caso, todas las formas de gestión iterativa proporcionan una manera de:
  • Integrar y validar la evolución del producto continuamente
  • Demostrar progreso en cortos períodos de tiempo
  • Alertar pronto al equipo del proyecto de los problemas suscitados
  • Entregar funcionalidad de manera temprana
  • Incorporar sistemáticamente el re-trabajo inevitable que ocurre en el desarrollo de software

En resumen, la gestión Iterativa de proyectos facilita procedimientos para el desarrollo exitoso de aplicaciones y minimizan tanto los riesgos como los costos, combinando técnicas de administración bien estructuradas de métodos en cascada con técnicas de validación temprana del modelo evolutivo. Este proceso es más adaptable a situaciones diversas en proyectos de software y da al gerente la flexibilidad necesaria para acomodarse a un rango dinámico de alternativas técnicas.

Información
Este artículo fue publicado originalmente por la Revista de la Asociación Española de Profesionales en Dirección de Proyectos, en marzo de 2012. Para acceder al artículo original, pueden hacer clic aquí.

domingo, septiembre 01, 2013

Gerentes de Proyectos de software, ¿una especie en vías de extinción?


“En los próximos treinta años, sin hacer ningún  ruido, un día dejaremos de ser los seres más brillantes de la tierra”. James McAclear.
Gerentes de Proyectos de software, ¿una especie en vías de extinción?
Imagen de Mark Garlick/Science Photo Library
Hace poco, durante la sesión de preguntas y respuestas de una conferencia sobre transición al universo ágil y a Scrum que facilité con todas mis ganas, alguien del público censuró arduamente algunos de mis puntos de vista… Esta es su historia.
La pregunta
-         “Lucho, quiero referirme específicamente al asunto de la Gerencia del Proyecto en este mundo ágil que planteas” – comenzó diciendo con firmeza. “Afirmas que nosotros no necesitamos un Gerente de Proyectos si estamos empleando una metodología Ágil, específicamente si empleamos Scrum”
Aunque aun no sabía en qué iba a terminar aquello, no quería hacer parte de lo que venía a continuación. Empecé a pensar que el asunto podía convertirse en un ejercicio de semántica, en vez de uno de fondo, empezando con la definición de “nosotros” y la de “Gerente de Proyectos”.
-          Por ejemplo, – prosiguió ella, con un tono que rayaba en lo trascendental – dices que el Scrum Master es quien facilita las reuniones Diarias, la reunión de Planificación del Sprint, la Retrospectiva; es quien le da un empujoncito al Dueño del Producto para que sus historias estén a tiempo para la Planificación del Sprint; y es a quién acuden los miembros del Equipo cuando tienen problemas que no pueden resolver.
En un instante calculé muchas de las preguntas que podían resultar de aquel soliloquio y con preocupación noté que la referencia inicial al Scrum Master haría que entráramos a un terreno escabroso, a una discusión que podría exacerbar los ánimos de Ella y de algunos de los asistentes.
-          No tienes que llamar a esa persona un Gerente de Proyecto si no quieres – aseveró Ella con una modulación culminante, aunque con las mejillas rojizas, - y, en Scrum, esa persona es el Scrum Master.
Otra vez el Scrum Master. Sin duda, lo que venía era equipararlo con el Gerente de Proyectos tradicional.
-          Aun así, mucho de este trabajo se parece a la clase de cosas que hacen los Gerentes de Proyectos. – Ahí estuvo, no me equivoqué, pero antes de que pudiera pensar en algo más, siguió diciendo - El hecho de que un Gerente de Proyectos asociado con tipos diferentes de proyectos haga cosas que no son consistentes con Scrum no elimina la necesidad de que alguien haga esas cosas que parecen tan espantosas en los proyectos Scrum.
En cierto sentido tenía razón. Pero ¿y la pregunta?
-          Mi punto es, aunque no se llame Gerente de Proyectos, sí hay gerencia de proyectos en los proyectos Scrum. ¿Qué nos puedes decir al respecto? – Se sentó más tranquila que cuando se levantó para hacer el cuestionamiento. Es como si hubiese aliviado setenta y cinco minutos de ansiedad de un solo tirón, el mismo tiempo que tardó mi intervención.
La respuesta
Mi punto en cambio – pensé - es que embrollarse mucho con el vocabulario e insistir en que alguien que llena el rol de Scrum Master absoluta y positivamente no hace nada que se parezca al trabajo de gerencia de proyectos, no es un uso constructivo del tiempo. Es más lucrativo averiguar lo que se necesita hacer para que el proyecto sea exitoso… ¡Y hacerlo!
Sin embargo, quise iniciar mi respuesta dándole parcialmente la razón. Le dije que tal y como concebimos el proceso, un proyecto Scrum está inmerso dentro de un conjunto de actividades relacionadas que requieren habilidades más clásicas de un Gerente de Proyectos, como la negociación contractual, la puesta en marcha de la operación o la misma selección del equipo. En Scrum, el equipo se autoorganiza, pero no es capaz de autoseleccionarse, hay restricciones de disponibilidad de las personas, de habilidades necesarias y de motivación, entre otras, que deben tomarse en cuenta. Sí, es cierto que quien se pone en los zapatos del Scrum Master bien puede hacer estas cosas, en cuyo caso llamarlo Gerente de Proyectos (así como Scrum Master) tiene mucho sentido.
Mientras yo hablaba, miraba cómo la expresión de su rostro cambiaba; el tono rojizo que tenía durante su intervención se había disipado y sus mejillas volvieron a su color habitual. Incluso sonrió, asintió con la cabeza y le susurró algo que nunca sabremos a su compañero de la izquierda, aunque tuve la ligera desesperanza de que decía: – sí, ¡yo tenía razón! – En parte la tenía… pero solo si hubiésemos estado hablando de proyectos tratados con métodos tradicionales, no ágiles.
Mientras hacía la pausa para continuar, pensaba que esa pregunta ponía de manifiesto una vez más algo común en los procesos de transformación hacia lo ágil y era que, aun cuando creyeran que ya habían llegado al final del camino (¡somos ágiles, somos Scrum!), muchos todavía tenían un largo camino por recorrer antes de que realmente entendieran lo que significaba hacer Scrum y “ser ágil”. Imaginé a Ken Schwaber o a Jeff Sutherland interviniendo en la discusión, pero solo para argumentar que  ninguno de los roles en Scrum eran eufemismos para “Gerente de Proyectos”, y finalmente pensé que ninguno de ellos ni ninguno de los otros 15 personajes que firmaron el Manifiesto Ágil, entrarían alguna vez en una discusión como esta.
Pero – justo en este instante tuve la idea completa – quienes tratamos de aplicar Scrum adhiriéndonos a sus reglas tan íntimamente como podamos, sabemos que es el Equipo el que toma las decisiones y que el Dueño del Producto es el “familiar” más inmediato que los Equipos Scrum tienen a un(a) Gerente de Proyectos. – Ya estaba dicho, sentía que debía deshacer de raíz ese arraigo de las personas de quedarse en la mitad del proceso de renovación hacia la filosofía ágil.
La guía de Scrum dice textualmente: “El Dueño de Producto es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo.” Y más adelante, en el mismo apartado sobre el Dueño del Producto, complementa: “toda la organización debe respetar sus decisiones.” Les recomiendo además el artículo “Scrum: Cediendo el mando y control AL EQUIPO” de mi colega Jorge Abad y con quien he abordado estos asuntos en la Comunidad Ágiles Colombia. Bien dice él que el “rol de la gerencia de proyectos queda inoperante y se convierte en un reto profesional pasar de gerente de proyectos a Scrum Master” [1]. Jorge se refiere a los Proyectos/Equipos Scrum. Le decía precisamente sobre esta aseveración que, aunque estuviera claro que el gerente de proyectos de hoy puede ser un Scrum Master, el trámite de ir de un punto a otro no es algo lineal y mucho menos algo que se pueda lograr durante el sueño.
En este punto de mi parlamento, no solo la expresión corporal de mi interlocutora, sino la de muchos en el auditorio, era de desconcierto. Así que debía anticiparme a sus preguntas.
La pregunta entonces es – continué – ¿cómo lograr esa metamorfosis? ¿Cómo hacer que ese cambio no se quede en un mero “regateo”, que no se quede en una evolución trunca o, dicho de otra forma, en una mera mutación involutiva? No queremos que el resultado sea algo así como “gerenscrummaster de proyectos”… como lo que sucede en La Mosca, aquella película de 1986, dirigida por David Cronenberg, con Jeff Golblum y Geena Davis.
Y la respuesta a esa pregunta es: dejarse abrazar por los valores y principios del Manifiesto Ágil, por los pilares de Scrum de Transparencia, Inspección y Adaptación, ese trípode que se constituye precisamente en el soporte de los Equipos Scrum, autoorganizados, esos que según la misma Guía de Scrum “eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo.” Además, “tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo.
Me pareció que no había nada más que decir. Así que me propuse cerrar el tema diciéndoles que, de hecho, la conversión de los gerentes de proyecto actuales hacia otros roles era un factor de resistencia al cambio durante el proceso de renovación hacia “ser ágil” y esa resistencia normalmente redundaba en una crisis organizacional. Pero no había nada que hacer, buena parte, sino todas las responsabilidades del gerente se distribuyen en estos nuevos roles que hoy estamos jugando en Scrum. Por ejemplo, la visión y las guías del proyecto están a cargo del Dueño del Producto, el Equipo automaneja la organización diaria del flujo del proyecto, mientras que la facilitación y el entrenamiento son responsabilidad del Scrum Master.

Conclusión
Estoy seguro que a mi interpelante no le gustó esta respuesta, pero que le vamos a hacer. A algunos les sabe cruda la verdad. Lo que ocurre es que las organizaciones no se mueven rápida y fácilmente a Ágil/Scrum y tienen malos momentos consiguiendo velocidad y experiencia en los nuevos roles. El cambio es duro. Ágil no es una construcción de conveniencia; demanda un cambio radical del pensamiento tradicional acerca del desarrollo. Si una persona no puede verdaderamente adoptar los valores y principios del Manifiesto, entonces en mi opinión ellos son ADNS – Ágil De Nombre Solamente. ¿Eres tú un ADNS?
Lo otro que me inquieta son los certificados. Cuando escucho o leo a gente con CSM y CSPO, PSM o similares, y combinados con PMP o algo así, haciéndome preguntas o expresándose como lo hizo el personaje de esta historia, me pregunto si fueron al entrenamiento y obtuvieron las certificaciones simplemente para llenar sus Hojas de Vida. No parecen comprometidos con el pensamiento ágil o con los valores y principios del Manifiesto Ágil.
He tenido la colosal fortuna de trabajar con personas/colegas supremamente inteligentes, en proyectos de software extremadamente complejos; y ellos siempre me tienen en cuenta para resolver problemas comunes y no tan comunes pero peculiares en esta clase de proyectos; también quieren conocer mi opinión sobre ideas técnicas que los mantuvieran enfocados en los objetivos primordiales, es decir, los entregables del proyecto. Soy parte del equipo, no una figura de autoridad. Lo que hecho, en la práctica, es contribuir al éxito del proyecto y al triunfo del equipo, a la satisfacción del usuario. No importa nada más.
Con Ágil/Scrum simplemente lo estamos haciendo más frecuentemente, con mayor calidad y, sobre todo, con mayor entusiasmo y felicidad.
Referencias