Sie sind auf Seite 1von 4

Agile Project Management, una nueva perspectiva

El Agile Project Management (APM) es un movimiento iconoclasta orientado a revolucionar el mundo de la administracin de proyectos y a dejar obsoletos los rgidos esquemas existentes en e mundo de las T !

Por Cuitlhuac Osorio Aylln" #Podemos seguir pensando que un proyecto result ser exitoso porque atendi a detalle todos los requerimientos originales planteados por el usuario $inal% adem&s de que se concluy en el tiempo y el presupuesto estimados' #(u) pasa entonces si despu)s de un mes de estar operando el nuevo sistema o la nueva propuesta tecnolgica% la percepcin de los usuarios es que no ganaron muc*o porque para ellos no resulta claro cmo es que la nueva propuesta gener valor' #(u) pasa si la mayora de los supuestos que sustentaron la inversin no resultaron verdaderos y el proyecto resulta ser todo un $iasco desde el punto de vista del negocio' Pensemos en supuestos como el n+mero de transacciones esperadas a trav)s de nternet% $actor clave para estimar el retorno de inversin o para la de$inicin de la arquitectura e in$raestructura de un nuevo sistema (inversin requerida)! ,abra que empe-ar por reconocer que los proyectos de Tecnologas de n$ormacin son cada ve- m&s complejos y que su )xito depende% adem&s de elementos t)cnicos de por si ya complejos% de $actores organi-acionales y de comunicacin dentro de organi-aciones vivas que se desenvuelven dentro de un entorno din&mico% vol&til y altamente competitivo! maginemos por ejemplo% la puesta en operacin de un sistema de in$ormacin para soportar un nuevo proceso de negocios% en donde simult&neamente estaremos cambiando de un plata$orma de ./0/1% 203 que $unciona sobre un sistema main$rame% *acia una arquitectura 4E0 de m+ltiples capas% bajo ambiente 5ava y /racle! #.ual podra ser el resultado' maginemos algunos escenarios6 7El proyecto $unciona pero los usuarios est&n insatis$ec*os7% 7 nvertimos seis meses en el dise8o del sistema del cual no se prevea un costo tan elevado para su implementacin7% 7el proyecto es un caos% los usuarios *an cambiado el 9: por ciento de los requerimientos7% o peor a+n% 7el sistema $unciona con$orme a los requerimientos iniciales pero di$icult la operacin del negocio% por lo que no se va a utili-ar7! Es altamente probable llegar a uno de los escenarios anteriores y la excepcin sera que% adem&s de cumplir con los requerimientos de$inidos y se completara en el tiempo y presupuesto planeado% dejara satis$ec*as a todas las partes involucradas (ejecutivos y patrocinadores% usuarios y &reas t)cnicas) y sobre todo generara valor para la organi-acin!

1a pregunta clave es #por qu) si todos reconocemos que la din&mica y rapide- con la que se suceden los cambios dentro de las organi-aciones% la complejidad y diversidad de tecnologas y arquitecturas existentes% adem&s del impacto operativo y por tanto $inanciero de las Tecnologas de n$ormacin% *an cambiado dram&ticamente durante los +ltimos ;< a8os% seguimos utili-ando en gran medida los mismos modelos de toma de decisiones% planeacin y desarrollo de proyectos de T ' #Por qu) seguimos utili-ando el viejo esquema que parte de la base de que al inicio contamos con la in$ormacin su$iciente para de$inir los requerimientos% que estos no van a cambiar% que podemos medir los riesgos y por tanto generar un plan de trabajo correcto' #Por qu) $ormamos e integramos unidades especiali-adas para ver si 7el avance del proyecto se est& ejecutando $rente a lo planeado (PM/)7% a+n cuando la realidad nos deja ver que los supuestos originales cambiaron y que el proyecto no va a generar el valor esperado' #(ui)n le dir& esto a los directivos y patrocinadores de proyecto' #(ui)n les in$ormar& que el proyecto costar& =: por ciento m&s de lo originalmente estimado% que la in$raestructura de cmputo es insu$iciente% que la tecnologa originalmente seleccionada no est& lo su$icientemente madura y que aunque en el broc*ure del proveedor parece $ant&stico% la realidad es que no existen t)cnicos disponibles para dar el soporte t)cnico necesario' #(ui)n ser& entonces el responsable de in$ormar esta situacin a los directivos% en el momento indicado% para tomar alguna decisin6 reencausar el proyecto o de$initivamente abortarlo' >e trata de proporcionar la in$ormacin necesaria en el tiempo correcto! ?o cuando el sistema @eb est& ya operando y pocos lo utili-an porque resulta poco pr&ctico para los usuarios% no cuando ya nos gastamos arriba del <: por ciento del presupuesto en documentar un an&lisis y dise8o que los usuarios rec*a-aron porque $inalmente aprendieron a lo largo de este proceso que requieren nuevas $uncionalidades% que cambiaron sus prioridadesA no cuando se tomaron decisiones erradas respecto a la arquitectura tecnolgica y *ay que dar marc*a atr&s porque resulta impr&ctica la implantacin! Agile Project Management (APM) es un movimiento que rompe muc*os de los paradigmas detr&s de los m)todos tradicionales de administracin de proyectos% como las establecidas por el Project Management nstitute (PM ) buscando dar mejores resultados y respuestas oportunas para los tomadores de decisin! 7>er &gil7 representa% como lo se8ala 5im ,ig*smit*% uno de los promotores de este movimiento% la *abilidad de crear y responder a los cambios! Preparar el ambiente organi-acional y las pr&cticas de administracin de proyectos *acia la innovacin% *acia la b+squeda de aquellos cambios que permitan di$erenciarnos y anticiparnos $rente a nuestros competidores o responder con prontitud $rente a ellos! 1a agilidad nos se8ala ,ig*smit*% es m&s una actitud que un proceso% m&s ambiente que metodologa! El 7Mani$iesto $or Agile Project Managemet7 (*ttp6BBagilemani$iesto!orgB) establece los siguientes valores como gua de esta nueva alternativa para la administracin de proyectos6

" ndividuos e interacciones sobre los procesos y *erramientas " Entrega de $uncionalidades sobre actividades regulatorias (2elivering $eatures over complience activities) ".olaboracin del cliente sobre negociacin de contratos! "Cesponder a los cambios sobre el seguimiento de un plan!

D no es que las *erramientas% los procesos% el cumplimiento de normas% los contratos% o los planes no sean importantes% simplemente es que los elementos del lado i-quierdo de cada uno de los enunciados anteriores% son m&s importantes desde la perspectiva 7&gil7! #Para que gastamos un da de una persona en documentar el diagrama que ayer dise8o el equipo de trabajo' >aqu)mosle una $otogra$a digital y avancemos m&s r&pido en generar resultados! Ese sera un planteamiento &gil! En el modelo de Agile Project Management% la ejecucin predomina sobre la planeacin y el control! En ve- de poner )n$asis en el desarrollo de planes y programas de trabajo y controlar el avance de los mismos% bajo la ptica de 7estamos con$orme al plan7 o en su de$ecto tratar de corregir las desviaciones $rente a )ste% utili-ando un esquema secuencial% bajo APM el administrador de proyectos debe crear la visin del producto y guiar al equipo de trabajo para trans$ormar esta visin en realidad! D bajo un m)todo interactivo% altamente colaborativo en el que los usuarios podr&n utili-ar y enriquecer los componentes del sistema ($uncionando)% que recibir&n en cada ciclo recorrido% no se valorar& el avance $rente al plan% sino en cambio el valor que el proyecto est& generado ya para los usuarios! >e trata pues de un modelo para generar resultados tangibles bajo ciclos muy cortos (dos a tres semanas)% en donde la realidad predomina $rente al plan y la meta y $actor de )xito del administrador de proyecto se convierte en generar el valor de negocios esperado! 1a evaluacin del avance del proyecto se medir& entonces no anali-ando una gr&$ica de gannt que nos ilustre el des$ase o cumplimiento de actividades% sino valorando el $uncionamiento de pie-as de so$t@are que ya est&n $uncionando! .omo en la mayora de los temas alrededor de las T no existen recetas m&gicas o caminos +nicos para el )xito de los proyectos! ?o en todos los casos los principios% conceptos y propuestas detr&s de APM nos garanti-ar&n el )xito o siempre resultar&n adecuados! >in embargo% resulta imperante valorar los resultados obtenidos bajo los sistemas tradicionales de administracin de proyectos% ser crticos% y considerar un cambio *acia pr&cticas que est& demostrado tener mejores resultados! ?o estamos diciendo que toda la teora y metodologas tradicionales de administracin de proyectos como las establecidas por el Project Management nstitute (PM ) est)n $uera de lugar y no deban ser utili-adas% de *ec*o en muc*os sentidos se complementan! 2iversas pr&cticas y *erramientas de APM y PM son las mismas% la di$erencia estriba en los supuestos en que se basan y las estrategias que utili-an% de a* que la instrumentacin de esas pr&cticas y *erramientas generar&n resultados di$erentes! Pero% entonces #.uando utili-ar APM' Todo depender& del tipo de proyecto y de organi-acin en la que se quiere desarrollar! 1a experiencia nos se8ala que bajo alguna o varias de las siguientes condiciones APM resultara una mejor alternativa $rente a las practicas del PM 6

" Proyectos con un alto grado de exploracin! Etili-acin de nuevas tecnologas% que respondan a nuevas iniciativas de negocios y en donde se prevea que los requerimientos ser&n muy vol&tiles! " Proyectos en donde la comunicacin con los usuariosB clientes es considerada como un $actor crtico! " Proyectos en donde las organi-aciones son $lexibles y prevalece una cultura de innovacin! /rgani-aciones que tienen la *abilidad de responder a cambios anticipados o inesperados% creados por sus clientes yBo competencia! 1os valores% principios y *erramientas propuestas por los de$ensores del PM/ y que originalmente se pensaron solo para el desarrollo de sistemas (agile so$t@are development)% son ya una realidad y est&n siendo instrumentados exitosamente y *an ido madurando *asta convertirse en una alternativa real para la administracin de proyectos! >in lugar a dudas estar abiertos y conocer los principios% m)todos% *erramientas y ventajas de la Administracin &gil de proyectos es *oy una obligacin que puede generar grandes bene$icios para los . /Fs y cuerpos de gobernabilidad de T dentro de las organi-aciones! .onsideremos un cambio! * El autor es directivo de Cutter Consortium Mxico (cuitla*uacGc*ein!com!mx)

Manifesto for Agile Software Development


We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and


tools

Working software over comprehensive Customer Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. documentation collaboration over contract negotiation

ent !eck "ike !eedle #rie van !ennekum #listair Cockburn Ward Cunningham "artin $owler

%ames &renning %im 'ighsmith #ndrew 'unt Ron %effries %on ern !rian "arick

Robert C. "artin (teve "ellor en (chwaber %eff (utherland )ave Thomas

Principles behind the Agile Manifesto


We follow these principles: *ur highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing re+uirements, even late in development. #gile processes harness change for the customer,s competitive advantage. )eliver working software fre+uently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. !usiness people and developers must work together daily throughout the pro-ect. !uild pro-ects around motivated individuals. &ive them the environment and support they need, and trust them to get the -ob done. The most efficient and effective method of conveying information to and within a development team is face.to.face conversation. Working software is the primary measure of progress. #gile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical e/cellence and good design enhances agility. (implicity..the art of ma/imi0ing the amount of work not done..is essential. The best architectures, re+uirements, and designs emerge from self.organi0ing teams. #t regular intervals, the team reflects on how to become more effective, then tunes and ad-usts its behavior accordingly.

Das könnte Ihnen auch gefallen