¡¡Primera Visita!!
Bueno, según Google Analytics, esta web a recibido su primera visita :-). Muchas gracias limeño desconocido, espero que te haya sido de provecho.
No has sido premiado con ningún BMW ni nada por el estilo, pero aquí estoy por si te puedo ayudar en algo.
Release 1 operativa
Ya está en marcha la release 1, resultado del sprint 1.
El segundo sprint no ha ido tan bien
Estoy escribiendo esto el 20/08, cuatro días después del final previsto del sprint. ¡Me temo que he sido demasiado optimista con mi previsión de tiempo disponible para este proyecto.!
Además he incumplido una de las máximas de Scrum: las iteraciones son timeboxed ; deben terminar en la fecha prevista. Creo que lo que hay que hacer ahora es evaluar el estado de desarrollo, cerrar el sprint de manera ordenada y planificar el siguiente.
Cerrado el primer sprint
Bueno, tras una semana he cerrado el primer sprint con relativo éxito. La web está online desde el miercoles 3 y he podido actualizarla casi en tiempo real. Además considero que cumple el objetivo de registrar el avance del proyecto y servir de bitácora del mismo.
Ahora es el momento de revisar el product backlog y las prioridades de sus elementos, como paso previo al lanzamiento del siguiente sprint.
El objetivo de este nuevo sprint será permitir la edición de los PBIs a través de la web. Si bien en principio puede parecer que sería más últil (y por tanto más rentable) comenzar por la edición de los elementos del sprint backlog, ya que se actualizan con más frecuencia, las siguientes consideraciones me han llevado a habilitar primero la edición de los elementos del product backlog:
- Como he dicho, Scrum propone que cualquiera pueda añadir elementos al product backlog, mientras que el sprint backlog es "propiedad" del equipo de proyecto. Habilitando primero la edición del product backlog abro la puerta a que mis, todavía inexistentes, lectores puedan proponer funcionalidades.
- La edición de los elementos del sprint backlog tiene más complejidad en la lógica de negocio. Empezando por el product backlog me puedo centrar en las cuestiones de arquitectura del sistema.
Para poder empezar el nuevo sprint, lo primero que hay que hacer es detallar este requisito en el product backlog.
Hello World!
Esta web surge de mi aspiración a ganarme la vida gestionando proyectos de software y asesorando a otros en esta gestión.
Mi experiencia personal me ha enseñado que la forma más productiva y honesta de gestionar éstos proyectos es mediante metodologías ágiles; por tres razones fundamentales:
- Aceptan que un proyecto de desarrollo de software es muy suceptible al efecto mariposa . Un pequeño cambio en las condiciones iniciales (requisitos, entorno de negocio, equipo de proyecto, ...) puede tener grandes consecuencias en el resultado del proyecto.
- Aceptan que la misma ejecución de un proyecto provoca cambios en los requisitos. Según se avanza en el proyecto, los promotores del mismo obtienen una visión más clara del problema a soluciona.
- Utilizan la rentabilidad del proyecto pra el cliente como criterio básico para la priorización de tareas.
Creo que, sobre todo en estos tiempos de crisis, con este enfoque sobre la gestión de proyectos de software puedo hacerme un hueco en el negocio.
Desgraciadamente no cuento con la financiación necesaria para montar una reluciente factoría* de software, por lo que pretendo utilizar esta web para atraer a posibles clientes y colaboradores.
* De hecho, este término me parece especialmente desafortunado, ya que evoca la producción en cadena, paradigma del proceso repetible y predecible.
Planteamiento
En esta web pretende ser una bitácora del uso de la metodología ágil a un proyecto de software. Desafortunadamente en este punto de partida no dispongo ni de un cliente con un proyecto, ni de un equipo para llevarlo a cabo... (evidentemente consideraría cualquier de proyecto o colaboración)
... pero esa es una de las máximas del agilismo: avanza a pesar de las restricciones del entorno, y esta es la respuesta a esa voluntad de avanzar
Por lo tanto, lo primero que necesito para avanzar es un proyecto.
El proyecto: una herramienta AALM (Agile Application Lifecycle Management )
He escogido este proyecto porque, por un lado, me facilita el cambio de sombrero al que me obliga la inexistencia de un cliente y un equipo de proyecto (hay decisiones que deberán explicarse bajo la óptica del cliente, del jefe de proyecto o de los miembros del equipo). Por otro lado, siempre puede ser una herramienta útil para un futuro taller de software.
Poniéndome por primera vez el sombrero de cliente, os cuento cual es mi visión de esta herramienta.
Facilitará y agilizará la comunicación entre los clientes y
el equipo de proyecto,
proporcionará al jefe de proyecto y a
los clientes una idea precisa del estado de avance del mismo
y permitirá al cliente verificar frecuentemente la calidad del
producto resultante;
todo esto sin implicar una carga de
trabajo adicional para el equipo de proyecto.
La metodología: Scrum
Usare Scrum como guía metodológica para la gestión del proyecto, por una razón muy simple, es la que mejor conozco y con la que tengo más experiencia. Aunque no pretendo describir exhaustivamente Scrum, si tengo que señalar las características más importantes a efectos prácticos:
- Los requisitos del proyecto se registran en una lista: el Product Backlog. Cualquiera puede añadir nuevos elementos a esta lista, pero sólo el cliente (Product Owner) puede establecer las prioridades de implementación.
- El proyecto se divide en iteraciones o sprints, con una longitud temporal pre-establecida (timeboxed). Cada sprint implementa un conjunto de elementos del Product Backlog, y produce un incremento de producto completamente funcional.
- Las tareas de un sprint, necesarias para implementar la parte seleccionada del product backlog, son definidas en conjunto por todo el equipo, durante el Scrum planning metting (que también tiene una duración fija, previamente acordada).
- Esta lista de tareas se denomina Iteration Backlog, y cualquier miembro del equipo puede añadir elementos a esta lista. Para cada tarea de la lista sólo se registra el esfuerzo pendiente para finalizar la tarea (que puede aumentar si se encuentra alguna dificultad).
- Diariamente se mantiene una reunión de seguimiento, el Daily Scrum, donde los miembros del equipo se informan sobre el estado de sus tareas.
Lanzamiento
Bueno, pues basta de rollo, es momento de ponerse a trabajar. Mi punto de partida debe ser la visión del cliente. A partir de ésta he derivado los siguientes elementos del Product Backlog, o PBIs por sus siglas en inglés. La siguiente no es en absoluto una lista exahustiva, sólo suficiente para alimentar el sprint inicial, que tiene como objetivo establecer definir las líneas maestras de una web de proyecto (esta web es un caso especial de una web de proyecto):
- 1.- Implementar la estructura de una web de proyecto
-
Producir un esqueleto de la estructura de secciones y navegación de esta web. La siguiente es una lista tentativa:
- Daily Scrum, para difundir las decisiones tomadas durante el Daily Scrum
- Product Backlog, listado de PBIs, con prioridad, esfuerzo estimado y estado
- Sprint Backlog de la iteración en curso, listado de SBIs, con estado y esfuerzo restante
- Sprints anteriores, histórico de los sprints anteriores
- Sandbox del sistema en desarrollo, acceso al sistema en su estado actual de desarrollo.
- Código del proyecto
Esfuerzo estimado: 1 día
- 2.- Automatizar el proceso de actualización de la web
-
Implentar un proceso (proyecto ant o similar) para actualizar los contenidos de esta web en el proveedor de hosting.
Esfuerzo estimado: 2 días
- 3.- Implantar un sistema de gestión de versiones
-
Implantar un sistema de gestión de versiones (¿Git?) que permita conservar un histórico de esta web, y de su código asociado.
Esfuerzo estimado: 1,5 días
- 4.- Posibilitar comentarios en la Web
-
Implementar un sistema de comentarios que facilite feedback de aquellos que me honren con su lectura.
Esfuerzo estimado: 5 días
Esta lista está ordenada según el valor que aporta su realización e incluye una estimación muy burda del tiempo necesario para su implementación. Utilizaré estos dos datos para planificar el sprint: el objetivo es maximizar la rentabilidad, obtener el mayor valor en el mínimo tiempo posible.