Revisar discos duros «viejunos» es una práctica sana. Es como comer sano, hacer deporte, volver a ver pelis buenas, etc. Es bueno porque te encuentras con cosas que escribiste hace años, y vale para hacer una retrospectiva de cómo has evolucionado con el tiempo, que ha pasado, poner en perspectiva cosas, errores del pasado, aciertos, etc.
No tengo todo el tiempo que quisiera para ejercitar el sano arte de revisar mis discos duros «viejunos», pero hoy, que andaba buscando una cosa de hace años (que, por cierto, no encontré), de paso, me he encontrado con unos ficheros de hace casi 16 años (uf, es duro decir eso de hace «casi 16 años») con mis primeras notas y apuntes cuando empecé, ya trabajando en empresa, con esto ahora tan de moda que es la agilidad, son estos de abajo, los dejo con la fecha de última modificación del fichero (para que duela más el tiempo 🙂
Los anteriores son de la época de la ppt, la presentación, de mi primer proyecto Agil (ojo, del 2001), que en su día también recuperé en una revisión de discos duros y que también es de aquel año clave para mi, profesionalmente hablando, el 2001.
Te voy a pegar más abajo, tal y cómo lo dejé, sin tocar una coma, el contenido de uno de ellos, el de «GARZAS_BECK_Notas sobre Planning XP». Son las notas que aquel año tomé sobre uno de los frameworks clave en el movimiento ágil: eXtreme Programming (XP). Concretamente, son las notas sobre lo que en aquel momento más me debió llamar la atención de uno de los libros de referencia sobre XP, el de Planning Extreme Programming (The Xp Series)
Y te he querido dejar estas notas, tal y como están, ten en cuenta cuando las leas que jamás por aquellos tiempos pensé ni remotamente que tú ahora ibas a leerlas, principalmente por dos razones: una, porque en mi afán de que leas, si no te vas a leer, por tiempo o lo que sea, el anterior libro… al menos aquí tienes un pequeñó resumen y dos, está va más por mí, para evitar que se pierdan, creo que están mejor consevadas en un post que en un .doc de hace años en un disco duro viejo (y para mí tiene su valor sentimental)
Ahí va, copy – pego, sin formateo ni miedo…
“Planning Extreme Programming”
Beck K. and Fowler M.
1 Fear (Miedo)
¿Por qué necesitamos un proceso software? Por la misma razón que necesitamos leyes, gobiernos y tasas: por el miedo. Para no perder nuestros “derechos”, para preservar la seguridad
Miedos del Cliente | Miedos del Developer |
No conseguir lo que pidieron | Se les pedirá más de lo que saben hacer |
De pedir algo equivocado | Se les pedirán cosas sin sentido |
Pagar demasiado | De ser muy estúpidos |
Perder el control en técnicas que no controlan | Caer por la técnica |
Nunca ver un plan significativo | Tomar responsabilidad sin autoridad |
No saber que ocurre | Definiciones no claras |
De no poder rehacer sus primeras decisiones | Sacrificar calidad por plazos |
Solucionar problemas complejos sin ayuda | |
No saber la verdad | No tener tiempo para finalizar con éxito |
No reconocer el miedo es la fuente de TODOS los fracasos en proyectos software. Si los miedos no se ponen en una tabla y se tratan, desarrolladores y clientes lo afrontarán por separado, rechazando el compartir información crítica. Para conseguir el éxito debe instituirse un proceso de desarrollo entre clientes y desarrolladores que asegure ciertos derechos inviolables.
Derechos del Cliente:
- Derecho a un plan general, a saber qué puede realizarse, cuándo y a qué coste.
- Derecho a conseguir el mayor valor posible de cada semana de programación
- Derecho a ver la evolución en un sistema ejecutable, probando el trabajo mediante los test que especifique
- Derecho a cambiar de opinión, sustituir funcionalidad, y cambiar prioridades sin pagar un coste exagerado
- Derecho a ser informado de cambios en la agenda, en tiempo para escoger como reducir el alcance para retornar a la fecha original. Puede cancelar en cualquier momento y quedarse con un sistema que trabaje de form útil que refleje la inversión hasta la fecha.
Derechos del programador:
- Derecho a saber lo que es necesario, con claras declaraciones de prioridad
- Derecho a producir trabajo de calidad en todo momento.
- Derecho a pedir para y recibir ayuda de iguales, managers y clientes.
- Derecho a hacer y modificar sus propias estimaciones.
- Derecho a aprobar sus responsabilidades en vez de que sean asignadas.
Si queremos desarrollar bien, programadores y clientes deben reconocer sus miedos y aceptar sus derechos y responsabilidades mutuamente.
2 Balancing Power
La clave en la gestión de proyectos es balancear el poder entre business people y technical people.
El personal de negocios toma decisiones de negocio, esto es obvio…¿seguro?:
- Este sistema se desarrollará en seis meses.
- Tienes tres meses.
Estimar el tamaño del software es una decisión puramente técnica. Muchas veces las estimaciones las hacen personas de negocio por razones de negocios.
El personal técnico toma decisiones de negocio, esto es obvio…¿seguro?:
- Tengo 10 cosas que hacer, sólo tendré tiempo para 5, comenzare con la infraestructura CORBA.
Elegir la prioridad entre tareas es una decisión de negocio, depende de las necesidades del mercado.
Business Decisions | Technicals Decisions |
Fechas | Estimaciones |
Alcance | |
Prioridad |
El Cliente
El cliente es una persona que hace decisiones de negocio. Generalmente no habrá literalmente un cliente. Habrá usuarios, gestores de negocio, etc. Pero siempre debe haber una sola voz. En XP se asume que el cliente forma parte del equipo de desarrollo. Un buen cliente:
- Comprende el dominio y sabe como funciona.
- Comprende como el software puede dar valor a su dominio.
- Puede tomar decisiones sobre que se necesita ahora y qué después.
- Aceptará su responsabilidad en el éxito o caída del proyecto.
Mantener la responsabilidad en el éxito o caída del proyecto es el punto más difícil. Existe un cierto confort por parte del cliente por mantener cierta distancia del equipo.
Si el cliente no quiere trabajar de esta manera… no debería probarse XP en el proyecto.
3 Las Cuatro variables
Hay cuatro variables para controlar un proyecto: Coste, Calidad, Tiempo y Alcance. Si se varía alguna el resto se ve afectada. Si se bloquean 3 no se puede modificar la 4ª. El efecto de mover una variable es retardado y No Lineal, no podemos poner el doble de coste y obtener directamente la mitad de tiempo. Cada variación tiene s propio”manual de instrucciones”.
Coste.
Es muy independiente . Al variar cualquiera de las otras tres variables podremos variar el coste, pero las variables en el coste afectan de distinta manera al resto de variables. La variación más potente es la gente:
- No lineal, aumentarán los niveles de comunicación. Doblando el equipo no iremos dos veces más rápido, la comunicación incrementará. Habrá que esperar para ver el efecto. El efecto inmediato es que nada cambiará o que el proyecto se frenará. “Añadir gente a un proyecto retrasado hace retrasado al proyecto” (Ley de Brooks).
- Otras formas de gastar dinero son las herramientas, pero también provocan perdida de tiempo al tener que aprenderlas.
- Nunca debe temerse el gastar dinero en motivación, hará al equipo mucho más productivo.
Las horas extra no ayudan. Si bien a corto plazo aceleran el proyecto si esta práctica se aplica durante mucho tiempo los efectos serán muy perniciosos. El primer problema es la motivación, es mejor tener un programador motivado trabajando 7 horas que un cansado y distraído programador trabajando 10. Incluso si los programadores quieren trabajar muchas horas no es buena idea, la gente cansada provoca errores y los errores gastan tiempo a la hora se ser solucionados.
Calidad.
Dos tipos de calidad:
- Externa: calidad percibida por el cliente. Bugs y requisitos no funcionales como la apariencia de la GUI y la velocidad.
4 Yesterday’s Weather
Aspecto básico en la planificación: “Se hará tanto o más esta semana como se hizo la última”. Si se pretende hacer demasiado: el proceso de desarrollo se nublará y la comunicación descenderá.
5 Alcance del proyecto (Scoping a Project)
6 El comienzo de la planificación
Se debe sincronizar el proyecto con el negocio. Dos aspectos a sincronizar: Fechas y Alcance. Con frecuencia las fechas importantes se imponen desde fuera de la compañía: contratos, fechas en que se necesita el cobro, etc.
En el lanzamiento del plan se asignan historias de usuario a releases y iteraciones. ¿En que debe comenzarse a trabajar? ¿Con que ha de continuarse?
El proyecto lo lanzan clientes y programadores. Los programadores ayudan al cliene a la hora de seleccionar historias y de priorizar:
Cliente | Programador |
Definir historias | Estima cuanto llevará cada historia |
Define el valor de cada historia | Alerta al cliente sobre riesgos técnicos |
Decide que historias construir en esta release | Presupuesta |
El plan es simplemente una foto de la actual visión sobre las cosas que deberán hacerse, pero el cliente cambiará el plan, cambiará los requisitos y el programador conocerá más el sistema y cambiará los requisitos. El plan sólo vale para hacerse una idea, deberá revisarse constantemente y desarrolladores, clientes y gestores deben aceptarlo.
El plan debería enfocar una o dos iteraciones (pag. 41).
No podemos gastar mucho tiempo decidiendo las infraestructuras del proyecto (Base de Datos, objetos distribuidos, etc.), se gastarían varios meses antes de entregar cualquier funcionalidad, esto ha matado a más de un proyecto. La infraestructura debe desarrollarse mientras se construye la funcionalidad, sin construir infraestructuras que no se necesitan.
7 Historias
Una historia es un pedazo de funcionalidad (o característica) valiosa para el usuario. Debe enfatizarse la palabra simple.
(pag. 45) La clave para gestionar un proyecto es equilibrar las fuerzas entre la gente de negocios y los programadores.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024