En el Post platicamos del elemento más importante de un proyecto. La gente. Y platicamos de los diferentes niveles de participación y los roles que existen en un proyecto de desarrollo de software. Si no lo has leído y te interesa, te dejo la siguiente liga:
En este post veremos en el proceso utilizado para la ejecución del proyecto, es decir, los pasos a seguir. Un poco por encima el proceso PMI, y un mayor enfoque en el proceso de Scrum. En los posts siguientes iremos viendo más a detalle cuales son las actividades y resultados esperados de cada uno de estos pasos, con la intención de que al final, tengas el conocimiento completo de todo lo que representa un proyecto de desarrollo.
Pero antes veremos un poquito de historia, principalmente porque la mayoría de los programadores han escuchado la palabra Agile, pero no saben el origen de estas prácticas. Veremos entonces como empezó la administración de proyectos, los errores, el aprendizaje y finalmente porque como y porque nace Agile.
Historia de las Etapas del Proyecto
Comparado con otras industrias, el desarrollo de software es algo relativamente nuevo. Las primeras computadoras realmente útiles aparecieron a mediados del siglo pasado (1950s) aunque su verdadera popularización llego hasta los 70s, y la verdadera explosión, es aquí cuando verdaderamente se vuelve una industria, con muchas personas y empresas empezando a tener acceso a una computadora.
Al ser una industria nueva las primeras empresas empezaron a usar computadoras eran los grandes corporativos, gobiernos, o militares. Y es en la industria militar en Estados Unidos donde comienzan los primeros procesos de administración de proyectos, tomando como referencia los procesos utilizados en la construcción y creación de producto. Lo que se conoce como un proceso de Cascada.
Se llama de Cascada porque cada una de las etapas se ejecutan una detrás de otra. Es decir, el Diseño no se empieza hasta que se finaliza la etapa de Requerimientos. La Ejecución no se empieza, hasta que se finaliza el Diseño. Y así consecutivamente.
Es fácil ver el problema de proceso, aunque funciona muy bien para algo como la construcción, donde es necesario terminar una etapa antes de comenzar la otra, donde no hay tanta incertidumbre, donde todo se mide y se calcula al detalle, y donde los requerimientos no pueden cambian mucho. En cambio, los proyectos de software hay mucha incertidumbre, no todo se puede calcular hasta que se comienza a hacer, y principalmente, los requerimientos pueden cambiar en cualquier momento.
Después de muchos años, y ver a cantidad de proyectos fallidos siguiendo este proceso, se comenzaron a utilizar procesos iterativos, que eran más flexibles a los cambios. En estos momentos nació una de las practicas más popularizadas, el Unified Process o Proceso Unificado. Este proceso fue popularizado principalmente por la empresa Rational Software Corportacion, una división de IBM, que en ese entonces era la empresa número 1 en computación. Este proceso entiende la naturaleza cambiante de los proyectos, y la necesidad del software de adaptarse a dicho cambio, e implementa un proceso por medio de iteraciones.
En cada una de las iteraciones se pretende hacer todo el proceso planeación, implementación, pruebas y evaluación, para finalmente generar una versión, y comenzar el proceso de nuevo para generar otra nueva versión. Este introduce la idea de versiones, y de ir entregando funcionalidad poco a poco. Dejando que los usuarios puedan comenzar a usar lo más importante e irlo mejorando con el tiempo.
Sin embargo, hay algo que caracterizaba mucho a este proceso. Ceremonia. Con esto me refiero a la cantidad de procesos, documentación, negociaciones y planes que se tenían que seguir. Esto era de esperarse cuando estos procesos estaban enfocados en crear sistemas enormes, con proyectos que duraban muchos años. Pero este tipo de proceso en proyectos más chicos terminaban generando muchísima documentación, y software que el usuario no quería usar. Eran un proceso enfocado más en el proceso en sí, que en los resultados generados. Y eso no era suficiente para la creciente generación de programadores de los 90s.
Finalmente, en 2001 muchos de los desarrolladores más importantes deciden hacer el “Agile Manifesto”, y con esto el inicio de la cultura Agile, y este dice:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan. (anotación 1).
Y a partir de esto comienza una nueva para desarrollar software. Una generación que estaría más enfocada en generar resultados, que en seguir ceremonias y escribir libros de documentación. Al mismo tiempo el Internet se estaba volviendo accesible a todo el mundo.
Scrum nace como un proceso de administración de proyectos de software enfocado a adoptar la filosofía Agile. Incluso fue creado, y popularizado, por varias de las personas que crearon el Agile manifestó, específicamente Ken Schwaber y Jeff Sutherland.
Etapas del Proyecto PMI y SCRUM
Y entendiendo ya el contexto histórico vemos que etapas utilizamos actualmente en proyectos de Software. Aunque Scrum es el proceso verdaderamente Agile, me gusta irlo comparando con PMI por varias razones; Primero, PMI ha evolucionado, y ahora también considera iteraciones y adecuar los requerimientos de documentación. Segundo, es lo más utilizado en oficinas de proyectos en empresas grandes. Tercero, no soy de la gente que creo que uno esté peleado con el otro. PMI no es cascada. He trabajado muchos proyectos equilibrando PMI, por requerimiento del cliente, y Scrum que es lo que utilizamos en el equipo de desarrollo.
Otra cosa es que Agile, y Scrum, no significan que no hay ningún tipo de ceremonia, ni ningún tipo de documentación. Lo importante es que no se enfocan en esto, sin embargo, en cualquier tipo de desarrollo es importante tener un mínimo de documentación, especialmente si estás trabajando para un cliente. En post futuros vemos cual creo que es la documentación mínima que debe de tener un proyecto. Veamos las etapas de cada uno:
Etapas PMI:
- Iniciación
- Planeación
- Ejecución
- Monitoreo y Control
- Cierre
Etapas Scrum:
- Creación del Product Backlog
- Planeación del Sprint y Sprint Backlog
- Ejecución del Sprint
- Pruebas y Demostración
- Entrega y Retrospectiva
Ya en papel no se ven tan diferentes. La principal diferencia es la etapa de cierre. No es porque Scrum no la contemple, todo proyecto debe de tener un fin, la realidad es que el proceso de Scrum esta más enfocado en la ejecución y entrega y deja el Cierre como un tema secundario.
En PMI toda iteración considera 2 etapas, planeación y ejecución. En Scrum cada iteración, llamada un Srint, incluye 4, planeación, ejecución, pruebas y entrega. Esta diferencia es otra vez porque PMI es un proceso más genérico, mientras que Scrum esta enfocado en el desarrollo de Software. No es difícil conceptualizar que Pruebas y Entrega como partes del proceso de ejecución.
Finalmente, el Monitoreo y Control. PMI considera este proceso como un trabajo constante durante el proyecto. Es el proceso donde se revisa cual es el estatus actual, cuales son los avances, los retrasos, y que modificaciones se tienen que hacer para mejorar. Esto es exactamente lo que se hace durante una Retrospectiva en Scrum, revisamos que se salió bien, que salió mal, y que ajustes se deben de realizar para mejorar.
Con esto terminamos este Post. En los siguientes nos adentraremos ya en el detalle de cada uno, que procesos y actividades existen, que documentación se genera, que hay que comunicar al cliente, etc.
Resumen
En este post platicamos acerca de cómo evoluciono el proceso de los proyectos de desarrollo de software, desde sus inicios heredando los procesos de Cascada, comunes en la construcción y desarrollo de productos, los problemas que tenían, y como estos fueron evolucionando para convertirse en procesos más iterativos. Platicamos después del nacimiento del Unified Process (Proceso Unificado), promocionado por Racional (IBM), y como el exceso de ceremonia y proceso causaba problemas en proyectos más chicos.
Vimos después las etapas generales de un proyecto según el proceso de PMI y de Scrum. Como se comparan y como pueden convivir, principalmente cuando muchos clientes piden PMI, y pero los equipos de desarrollo utilizan Scrum.
Te dejo con el acordeón del post:
- Un proceso de Cascada es cuando hacemos toda una etapa, antes de comenzar otra, es común en las industrias de la construcción, pero procesos no sirven para el desarrollo de software.
- Un proceso de Iteraciones es en el que se hace un grupo de etapas durante cada iteración, generando un resultado parcial (versiones) después de cada iteración.
- PMI no significa Cascada. Actualmente PMI también considera iteraciones como una opción dentro de sus procesos.
- Scrum es un proceso con Iteraciones. Cada Iteración se llama Sprint y genera una nueva versión del producto que estamos trabajando.
- Memoriza el “Agile Manifesto”, debe ser un mantra para todo creador de software:
- Individuos e interacciones sobre procesos y herramientas
- Software funcionando sobre documentación extensiva
- Colaboración con el cliente sobre negociación contractual
- Respuesta ante el cambio sobre seguir un plan.
