Extreme Programming

Etiquetas de Technorati: Extreme Programming,Programacion Extrema,Agilismo,Agil,Agile,Kent Beck,Agilism,Software Development,Metodologia,Methodology

Este post es un intento de acercar a ustedes los lineamientos principales que Kent Beck desarrolla en su texto “Kent Beck, Extreme Programming Explained, Embrace Change” con el firme interés de que se animen a completar su lectura desde la fuente misma. Así, expongo una breve descripción de los elementos que juegan en este marco, conformando la metodología: Valores, Principios y Prácticas, cerrando con los Roles que el autor identifica.

Valores

Son conceptos universales, idealmente se aplican en todos los ámbitos. Es el camino para conducir el propósito a la práctica.

Communication

Es un factor importante para crear sentido de equipo y lograr cooperación efectiva. Cuando surgen problemas sorpresivos puede ayudar a resolverlos.

La mayor parte de los problemas son causados por carencia de conocimiento o por carencia de comunicación.

Si el problema tiene origen en la falta de conocimiento, no hay nada que pueda hacerse de antemano.

Cuando nos encontremos con un problema, preguntémonos si puede ser causado por una carencia de comunicación. Si es así, analicemos ¿Qué tipo de comunicación necesitamos para abordar el problema? ¿Qué comunicación necesitamos para mantenernos fuera de esta situación en el futuro?

Simplicity

Es el valor más intensamente intelectual. Se trata de pensar las cosas de forma de eliminar toda complejidad innecesaria.

Feedback

Los cambios son inevitables y crean la necesidad del Feedback.

Personalmente entiendo que es común el escenario en el cual la coyuntura nos condiciona a implementar funcionalidad de forma imperfecta en uno o varios aspectos. Esta situación crea una fuerte necesidad de Feedback, de otra forma se asume el riesgo de perpetuar esa imperfección y quizá ya nadie recuerde su existencia.

Existen fundamentalmente tres motivos que dificultan hacer las cosas bien al primer intento:

· Al resolver un problema por primera vez, puede haber más de una solución que funcione o que la solución no sea totalmente clara,

· Lo que es bueno hoy puede no serlo mañana,

· Hacer algo con absoluta corrección podría insumir tanto tiempo que las circunstancias cambiantes futuras invaliden la solución de hoy, antes que se finalice.

Lograr satisfacción en un esquema de mejoras a cambio de, esperar la perfección al instante, es posible sólo acudiendo al Feedback, que puede producirse de varias formas:

· Escuchar distintas opiniones sobre una idea,

· Como se ve el código una vez implementada la idea,

· Si los tests fueron fáciles de escribir,

· Si los tests ejecutaron,

· Cómo la idea funciona una vez que se hizo el deploy.

Un equipo debe esforzarse en generar tanto Feedback como pueda, tan rápidamente como le sea posible. Tan pronto como se conoce la situación, tan pronto podremos adaptarnos.

Courage

Es la acción efectiva de enfrentar el temor.

A veces el coraje se manifiesta en forma de paciencia. Cuando uno sabe que existe un problema pero no lo conoce, se requiere coraje para esperar que se manifieste distintivamente.

Hay que tener en cuenta que el coraje como valor principal, sin valores que contrabalanceen, puede ser peligroso, incluso puede jugar contra el espíritu del equipo. Pero cuando el coraje juega en confluencia con los otros valores es una herramienta poderosa.

Respect

Este es el valor que subyace a los otros cuatro. XP funciona en un marco dónde cada integrante del equipo considera a cada otro y lo que está haciendo. La contribución de cada persona necesita respeto.

Others

Safety

Security

Predictability

Quality of Life

Principios

Existe gran distancia entre los Valores y las Prácticas, los Principios son la herramienta para sortear esa distancia y nos permitirán aplicar las Prácticas en armonía con los Valores.

Humanity

¿Qué es lo que necesita, en términos humanísticos, una persona para ser un buen desarrollador?

· Satisfacer necesidades básicas,

· Alcanzar logros, sentir que se contribuye en la sociedad,

· Sentido de pertenencia, identificación con el grupo, contribuir para alcanzar metas compartidas,

· Crecimiento personal y profesional, expansión de habilidades y perspectivas,

· Intimidad

Entonces parte del desafío es balancear las necesidades individuales con las del equipo.

Economics

Existen dos aspectos económicos que afectan al desarrollo de software,

· Time Value of Money. El desarrollo de software es más valorado cuando ahorra dinero más tempranamente y cuando comienza a gastarlo tan tarde como sea posible.

· Option Value of Systems and Teams. Las prácticas están destinadas a mejorar el valor tanto del software como del equipo, teniendo en cuenta el Time Value of Money, por ejemplo, para invertir o no en flexibilidad especulativa.

Mutual Benefit

Toda actividad debe beneficiar a todos los involucrados. Este es un principio muy difícil de adherir.

Siempre existen soluciones para cualquier problema que implica un costo para una persona mientras que otra se beneficia. Cuando la situación es desesperante estas soluciones se vuelven atractivas. Estos escenarios deterioran las relaciones.

Existen vías de beneficio mutuo que resuelven problemas a futuro:

· Escribir test automáticos. Ayudan a diseñar, integrar e implementar en el presente. Se mantienen los test para futuros programadores garantizando la escalabilidad del producto.

· Refactoring cuidadoso que remueva complejidad accidental. Satisface al autor, mejora su producto y deja el código más entendible para quien lo tome en un futuro.

· Seleccionar nombres partiendo de un coherente y explícito conjunto de metáforas que agilice el desarrollo y haga al código más claro para nuevos programadores.

Beneficio mutuo en XP es beneficiarme hoy, más tarde y también a mi cliente.

Self-Similarity

Cuando la naturaleza encuentra una forma que funciona, la usará siempre que pueda. Esto mismo se debe aplicar al desarrollo de software. Se debe tender a copiar la estructura exitosa de una solución a otro contexto, aún en diferentes escalas.

Improvement

El punto en XP es que la excelencia en software se alcanza a través de mejoras. El ciclo es hacer lo mejor posible hoy, esforzándose en conocer y entender para hacerlo mejor en el futuro.

La historia de la tecnología del desarrollo de software nos muestra una eliminación gradual del malgasto de esfuerzos.

Diversity

Los equipos necesitan reunir una variedad de habilidades, actitudes y perspectivas, para detectar problemas y trampas, recorrer múltiples caminos, resolver un problema, seleccionar e implementar la solución.

Inevitablemente surgen conflictos de la diversidad, conflictos del tipo “tengo varios caminos para resolver esto”, entonces el principio de la diversidad se nos debe presentar como una oportunidad y no un problema.

El desafío acá es cómo el equipo transita el conflicto y como suaviza su comunicación en momentos de stress.

Reflection

Los buenos equipos no sólo hacen su trabajo, también piensan cómo están trabajando y porqué están trabajando. Analizan porqué son exitosos o porqué fallaron.

Los ciclos del equipo, deben incluir tiempos de reflexión. Además deben generarse espacios informales de reflexión incluso aún con personas ajenas al ámbito del desarrollo de software. Esto permite alcanzar distintos enfoques para reflexionar acerca del porqué estamos trabajando en la forma en que lo hacemos.

Para maximizar el Feedback, la reflexión, en equipos XP, está en conjunto con el hacer.

Flow

Las prácticas de XP tienden hacia un flujo continuo de actividades, más que hacia fases discretas.

El desarrollo de software por mucho tiempo entregó valor en grandes módulos. Hay equipos que empeoran todo tendiendo a responder bajo stress haciendo estos módulos de valor cada vez más grandes, haciendo implementaciones cada vez menos frecuentes e integrando menos a menudo. En estas circunstancias es común que decaiga el Feedback con la consecuente toma de riesgo.

En oposición el principio Flow sugiere implementar pequeños incrementos de valor cada vez más frecuentemente.

Opportunity

Hay que aprender a ver los problemas como oportunidades para cambiar.

Esto no significa que no existan problemas en este ámbito. Parte de ser extremo es transformar el problema en una oportunidad de crecimiento personal, para profundizar relaciones y mejorar el software.

Redundancy

Los problemas críticos y difíciles en el desarrollo de software deberían ser resueltos de diversas formas. Entonces si una solución falla completamente, otra solución prevendrá el desastre.

Los defectos son un problema crítico y difícil y son abordados en XP por distintas prácticas, algunas de ellas podrían ser redundantes y este costo se asume porque la experiencia indica que no se resuelven los defectos con una simple práctica.

Failure

Cuando no sepamos, en cual de varias formas disponibles, implementar una Story, intentémoslo de todas estas formas simultáneamente. Aún cuando todas fallen, habremos aprendido algo valorable.

Una falla ¿es un malgasto?… No, si imparte conocimiento.

Suele suceder que al exponerse un conflicto se pierda demasiado tiempo discutiendo acerca de las características de cada implementación propuesta. Es recomendable que se limite el tiempo de discusión y si este se agota, el equipo deberá organizarse para implementar algo con cada una de las alternativas que queden en condiciones de competir después de la discusión, que podría durar entre quince minutos y media hora.

Quality

La calidad no debe ser una variable de control. Un proyecto no avanza más rápido al aceptar disminuir su calidad. Ni se avanza más lentamente demandando más alta calidad.

Elevar el estándar de calidad, a menudo resulta en entregas más rápidas. Mientras que una disminución de la calidad deriva en entregas tardías cada vez menos predecibles.

Baby Steps

Los cambios deben darse en pequeños pasos.

Siempre es tentador hacer grandes cambios en grandes pasos. Entonces la pregunta que Beck nos recomienda es “Cuál es el mínimo cambio que podrías hacer, que sea reconocible, en la dirección correcta”.

Accepted Responsibility

La responsabilidad no sólo puede ser asignada, también debe ser aceptada. La práctica de la responsabilidad aceptada nos sugiere que:

· Si una persona toma una tarea, es esa misma persona quien debería estimarla,

· La persona responsable de implementar una Story también es responsable de su diseño y testing.

Practices

Cómo aplicar las Prácticas en su contexto puede no ser obvio. Las Prácticas son dependientes de la situación. Las podemos ver como un vector desde donde estamos hasta donde podemos estar con XP.

Su aplicación es una elección. Las Prácticas Primarias son útiles independientemente de que se esté haciendo. Las Prácticas Corolarias son difíciles de aplicar sin antes tener una buena experiencia en las Prácticas Primarias.

Primary Practices

Sit Together

Se recomienda desarrollar en un espacio abierto lo suficientemente grande como para contener al equipo completo, donde cada integrante posea su espacio de privacidad.

Es importante que quienes conformen el equipo se sienten juntos y puedan establecer contacto visual con facilidad.

Esto no siempre es posible, entonces se debe recurrir a otros espacios que puedan frecuentarse regularmente. Hay que tener en cuenta que si el equipo está disperso y se presentan problemas es importante reunirse más a menudo, en la forma en que se pueda.

Whole Team

Hay que reunir en el equipo todas las habilidades y perspectivas necesarias para que el desarrollo sea exitoso.

Lo que consituye un Whole Team es dinámico, a mi criterio, de acuerdo fundamentalmente a, como se desarrolle la vida del producto, la evolución de la tecnología, el crecimiento del equipo y el desarrollo individual de los integrantes del mismo.

Informative Workspace

Armar un Workspace sobre nuestro trabajo. Un observador interesado que se mueva en el espacio del equipo debería, en quince segundos, tener una idea aproximada de cómo marchan las cosas.

Muchos equipos implementan esta práctica usando Story Cards.

Energized Work

Hay que trabajar solo las horas que se pueda ser productivo.

El desarrollo de software es un juego de insight y el este se produce en mentes preparadas, descansadas y relajadas.

Cuando se está muy cansado es muy fácil disipar valor en un proyecto de software.

Pair Programming

Escribir todos los programas de producción con dos personas sentadas en una misma máquina. Estas personas que programan juntas, también van a analizar, diseñar, testear en Pair Programming, intentando programar mejor.

Pair Programming permite:

· Mantener mutuamente en su tarea,

· Aclarar ideas,

· Tomar la iniciativa cuando el partner queda estancado, esto disminuye la frustración,

· Establecer responsabilidades mutuas acerca de las Prácticas del equipo.

La mayoría de los programadores no puede practicar pairing más que cinco o seis horas diarias. Es una buena idea establecer pausas y rotar los pares frecuentemente, por ejemplo, cada dos horas. Hay equipos que rotan cada hora valiéndose de un timer y algunos llegan a rotar cada treinta minutos cuando tiene que resolver algún problema difícil.

Stories

Planificar Stories usando unidades funcionales visibles para el cliente. Tan pronto como la historia se escribe hay que estimar el esfuerzo de desarrollo que representará implementarlo.

Las Stories deben tener un título corto y una pequeña descripción.

Una característica de XP es que las Stories se escriben temprano, esto da al equipo tiempo para pensar en cómo obtener el mejor resultado con la menor inversión.

Weekly Cycle

Planear el trabajo una vez a la semana. Al comenzar la semana se debe celebrar una reunión donde:

· Se revisan los progresos realizados a la fecha,

· Lograr que el cliente escoja Stories que insuman una semana,

· Descomponer las Stories en Tasks.

La semana comienza escribiendo los tests automáticos que deberían correr una vez que se implementen las Stories. El resto de la semana transcurre completando las Stories y haciendo correr los tests. El trabajo verdaderamente termina con la implementación de las Stories, no se queda en los tests.

Las Stories se deben dividir en Tasks de modo tal que haya un responsable por ellas y sea él mismo quien la estime.

Quarterly Cycle

Planificar el trabajo de a trimestres, como ritmo de observación de avance del proyecto y su alineación con metas de largo alcance.

En estos trimestres:

· Se identifican cuellos de botella, especialmente aquellos que están fuera del alcance del equipo,

· Iniciar reparaciones,

· Planificar el Theme o Themes del Quarter,

· Seleccionar para el Quarter aquellas Stories que se encaminen al Theme o Themes,

· Focalizar en la gran foto, donde el proyecto se adecúa a la organización.

Las estaciones del año son una escala de tiempo natural y ampliamente aceptada.

El tratamiento en términos de Theme y Story es para contener la tendencia de los equipos en focalizar en los detalles de lo que están haciendo sin considerar cómo estas Stories se adaptan a la organización en la gran foto.

Slack

Siempre se pueden agregar Stories y entregar más de lo que se prometió. Cuando sea posible, es recomendable comprometerse con objetivos modestos. Esto tiende a bajar la tasa de generación de bugs.

Ten Minute Build

El objetivo es que en diez minutos se ejecute el Build del sistema completo y se ejecuten todos los tests. Si este proceso lleva más de diez minutos, debe hacerse de todos modos, quizá menos a menudo.

Cuando este proceso es automático, hay riesgos que se eliminan. Si el proceso es manual hay que ser muy estricto en practicar un Build de todo el sistema y la ejecución de todos los tests. Cuando se compila sólo lo que se modificó y se ejecutan sólo los tests necesarios para cubrir estos cambios, se introduce el riesgo de cometer errores impredecibles.

Los Builds y Tests automáticos son más valorables que aquellos que requieran alguna intervención manual

Continuous Integration

Integrar y ejecutar tests como máximo cada dos horas. Programar en equipo no es el problema de dividir y conquistar, es más bien el problema de dividir, conquistar e integrar.

La integración es un paso impredecible y puede fácilmente tomar más tiempo que la misma programación de lo que se integra.

El estilo de Integración Contínua más común es el asíncrono, en el cual se envían los cambios al servidor, el sistema de Build se notifica acerca de estos cambios y ejecuta el Build completo y todos los Tests. Si hay algún problema se notifica por eMail, mensaje de texto o, recomienda el autor como most cooly, con una brillante lámpara roja.

Es preferible un modelo sincrónico, donde después de un episodio de Pair-Programming, de no más de dos horas, se envían los cambios y se espera el resultado del Build completo y la ejecución de todos los tests.

En un modelo sincrónico, esperar la compilación y los resultados del testing, es un tiempo natural dónde hablar y reflexionar en cómo mejorar lo hecho.

Los builds sincrónicos crean una presión positiva a favor de la definición clara de ciclos de Feedback cortos.

Hay que integrar y ejecutar el build de un producto completo. Si hay que quemar un CD, se quema un CD; si hay que implementar un sitio web, se implementa un sitio web.

Test-First Programming

Escribir un test automático que falle antes de modificar algo de código. Test-First Programming encara varios problemas a la vez.

· Scope Creep, Alcance Cambiante: Al declarar explícita y objetivamente que es lo que se espera que el programa haga, se logra enfocar más definidamente el trabajo. Y si realmente se quiere agregar algo, entonces hay que escribir otro test después de lograr que el primero funcione.

· Acoplamiento y Cohesión: Si es difícil escribir un test, es señal de un problema de diseño más que un problema del test. El código levemente acoplado y altamente cohesivo es fácil de testear.

· Confianza: Es difícil confiar en el autor de código que no funciona. Escribir código claro que funcione y demostrar las intenciones escribiendo tests automáticos logra establecer confianza entre los integrantes de un equipo.

· Ritmo: No es extraño perderse mucho tiempo mientras se está programando. Cuando se practica Test-First Programming queda claro qué es lo próximo que hay que hacer, o escribir otro test, o hacer que el test que falló funcione. Esto desarrolla un ritmo natural y eficiente, test, code, refactor, test, code, refactor…

Los tests que se escriben mientras se produce el código tienen la desventaja de tener una micro visión del sistema, cabe preguntarse, por ejemplo, si dos de estos objetos podrán trabajar bien juntos. A medida que se adquiera experiencia en el tema se estará en capacidad de acumular mayor seguridad con estos tests.

Incremental Design

Invertir en el diseño del sistema cada dia.

La estrategia opuesta, poner todo el diseño antes de implementar, produce software rígido frente a la necesidad de cambios, esto desencadena un crecimiento exponencial de los costos por cambios.

Los equipos XP trabajan para crear condiciones bajo las cuales el costo de modificar software no despegue catastróficamente.

La más económica estrategia de diseño es tomar las grandes decisiones de diseño tempranamente y diferir todas las decisiones de pequeña escala para más adelante.

El diseño incremental sugiere que el tiempo más efectivo para diseñar es a la luz de la experiencia.

Corollary Practices

El autor ve las siguientes Prácticas como difíciles o riesgosas de llevar a cabo sin implementar exitosamente las previas.

Real Customer Involvement

Hay que lograr que la gente cuyas vidas o negocios estén involucrados en el sistema a desarrollar sea parte del equipo. Clientes con buena visión del sistema pueden formar parte de la planificación trimestral y semanal.

La objeción que se escucha a esta Práctica es que si se hace todo lo que el cliente quiera el sistema no resultará adecuado para otros. Pero es más fácil generalizar un sistema exitoso que especializar un sistema que no resuelve el problema de nadie.

Incremental Deployment

Cuando se reemplace un sistema es recomendable tomar el control gradualmente empezando muy temprano en el proyecto. Los grandes Deployments involucran riesgos y altos costos humanos y económicos.

Team Continuity

Mantener efectivamente al equipo junto.

En grandes organizaciones existe la tendencia de administrar la gente como unidades de programación. El valor en software no sólo se construye por lo que la gente sabe y hace, sino también por sus relaciones y lo que logran juntos. Ignorar las relaciones y confianza sólo por simplificar un problema de agenda es una falsa economía.

En las pequeñas organizaciones este problema no existe ya que sólo se cuenta con un equipo.

Shrinking Teams

Cuando un equipo crece en capacidades hay que mantener su carga de trabajo y gradualmente reducir su tamaño. Con la gente liberada se forman nuevos equipos. Si algún equipo quedó muy pequeño se puede fusionar con otro pequeño equipo.

Root-Cause Analysis

Siempre que un defecto es encontrado después de un desarrollo, se debe eliminar el defecto y sus causas. El objetivo no sólo es que este defecto particular no se vuelva a repetir, sino que el equipo no vuelva a caer en este tipo de error otra vez.

En XP este es el proceso para responder frente a un defecto:

1. Escribir un test automático que reproduzca el error,

2. Escribir un Unit Test que reproduzca el error con el alcance más reducido posible,

3. Corregir el sistema hasta que el Unit Test funcione.

4. Una vez que el defecto esté resuelto, pensar en qué originó el defecto. Iniciar los cambios necesarios para evitar este tipo de defectos en el futuro.

Muchos equipos tienen demasiados bugs como para poner esta Práctica en uso.

Shared Code

Cualquiera en el equipo puede mejorar cualquier parte del sistema en cualquier momento.

Code and Tests

Mantener solo el código y los tests como artefactos permanentes.

Single Code Base

Tiene que haber un único código. Se puede trabajar con un branch temporario pero por no más de unas pocas horas.

Si se cuenta con múltiples versiones de código base, rápidamente hay que ponerse en plan de reducción gradual.

Daily Deployment

Poner en producción nuevas versiones de software cada fin del día. Esta práctica requiere que haya Builds automáticos. Las herramientas de Deploy también deben ser automáticas incluyendo la habilidad de hacer roll outs incrementales y roll backs en caso de fallas.

La tendencia a hacer deploys más frecuentes es clara. Los grandes sitios web cambian diariamente en forma imperceptible.

Negotiated Scope Contract

Los riesgos se reducen firmando una secuencia de contratos cortos en lugar de uno largo. Tendremos mejor margen para negociar alcances.

Pay-Per Use

En la modalidad Pay-Per Use se factura cada vez que el sistema es usado. Aun cuando no se pueda implementar Pay-Per Use se puede pensar en un sistema que permita un modelo de suscripción en el cual el software es comprado mensualmente o trimestralmente.

The Whole XP Team

Testers

Eligen, escriben tests y entrenan a los programadores en técnicas de testing. Colaboran en la definición de lo que constituirá un aceptable funcionamiento antes de la implementación.

Interactions Designers

Seleccionan metáforas que expresen el sistema, escriben Stories y evalúan el uso del sistema implementado. Los Interactions Designers trabajan con los clientes, ayudan a clarificar las Stories, deciden qué es lo próximo que el sistema hará y refinan la interfaz de usuario durante el ciclo de vida del producto.

Architects

Deciden y ejecutan refactorings de larga escala, escriben tests de stress de arquitectura, implementan Stories y particionan sistemas para su mejor desarrollo.

Project Managers

Facilitan la comunicación interna del equipo y coordina la comunicación con clientes, proveedores y con el resto de la organización. Es responsable de recordar los progresos al equipo.

Planeamiento en XP es una actividad, no una fase, los Project Managers se responsabilizan de mantener lo planeado en sincronismo con la realidad.

Product Managers

Escriben y seleccionan Stories y Themes en el Quarterly Cycle, responden ante implementaciones no cubiertas o sobre areas de Stories sub especificadas.

Cuando el equipo está desbordado, el Product Manager ayuda al equipo a fijar prioridades analizando la diferencia entre la situación actual y lo asumido anteriormente. Luego adapta la Storie o Theme a lo que realmente sucede.

Executives

Articular y mantener metas de largo alcance es la responsabilidad de los ejecutivos, sean sponsors o supervisores. También deben monitorear, animar y facilitar mejoras. Los ejecutivos cuentan con dos métricas para conocer el estado de salud de su equipo XP, una es la cantidad de errores encontrados después de la instalación, la segunda es el tiempo que transcurre desde que la organización comienza a invertir en una idea hasta que la idea produzca su primer ingreso.

Technical Writers

El rol de las publicaciones técnicas en un equipo XP es proveer un temprano Feedback sobre las características y crear relaciones cercanas con los usuarios.

Explicar un sistema en prosa e imágenes es una fuente de Feedback para el equipo.

Las publicaciones pueden tener cualquier forma, tutoriales, manuales de referencia, manuales técnicos, videos, audios, blogs, wikis, etc.

Los equipos XP deberían tener algún Feedback acerca del uso. Si se tiene la documentación en línea se puede monitorear su uso. Si los usuarios nunca visitan cierto tipo de documentación, se debe suspender su producción. Si la documentación está integrada al producto y el producto cuenta con un sistema de seguimiento de usabilidad, agregar a este seguimiento el uso de la documentación.

Users

En XP los usuarios escriben y seleccionan Stories y toman decisiones de dominio durante el desarrollo. Los usuarios son más valiosos cuando tienen amplios conocimientos y experiencia en sistemas similares, más aún si forman parte de alguna importante comunidad de usuarios.

Programmers

Los programadores estiman Stories y Tasks, descomponen Stories en Tasks, escriben tests y código, automatizan procesos de desarrollo y gradualmente mejoran el diseño del sistema.

Como los programadores necesitan trabajar en un esquema de cercana colaboración técnica, es importante que desarrollen habilidades sociales y comunicacionales.