Recordemos también que comienza la cuenta atrás para la llegada de Zend Framework 2.0

Sin embargo, me inclino por utilizar un servidor de integración continua específico para PHP. Y es que estos aportan soporte específico para herramientas de PHP como phpUnit, phpDocumentor, etc… con lo que simplifica mucho la configuración y, sobre todo, la visualización de los resultados obtenidos (Front End). Como siempre, dentro del software libre, tenemos bastantes soluciones de calidad variable. Para mí destacan principalmente dos: Xinc y phpUnderControl.

phpUnderControl es una adaptación de Cruise Control a PHP. Cruise Control es el servidor de integración continua (originalmente para Java, pero ahora con versión para .NET, Ruby, etc.) con una comunidad de desarrolladores más grande y activa. Como consecuencia, tiene una enorme cantidad de documentación y de extensiones desarrolladas. Para funcionar, utiliza herramientas típicas de Java como Ant, etc. aunque a efectos prácticos, configurar un proyecto para utilizarlo con CruiseControl es escribir un XML.

Xinc significa Xinc is not CruiseControl. Como se puede ver por su propio nombre, nace como alternativa a phpUnderControl. Su idea es crear una herramienta más específica para el desarrollo en PHP, escrita en PHP y que, por ejemplo, utilice Phing (el Ant de PHP) en vez del propio Ant. A efectos prácticos, también supone escribir un XML. Una de sus ventajas es que no necesita Java, así que puede funcionar en un LAMP necesidad de instalar nada más. Su comunidad de desarrolladores es mucho menor que la de CruiseControl, pero también es más específica para PHP.

Finalmente, David y yo nos hemos inclinado por phpUnderControl, por varias razones:

• Más documentación y extensiones desarrolladas. He sufrido muchas veces la falta de documentación. Da igual lo potente que sea un framework, herramienta o servidor: si la documentación no es extensa y rica en detalles.. no sirve.
• Desde el momento en que nuestras pruebas funcionales van en Selenium,  ya necesitamos instalar Java… así que la posibilidad de utilizar un LAMP sin nada más desaparece.
• Aprendiendo Selenium y CruiseControl no solo aprendemos integración continua específica para PHP, sino que también obtenemos conocimientos aplicables a Java u otros lenguajes. Aprender Phing sólo es útil en PHP…

La razón por la que utilizamos Google Docs y no la clásica pizarra de SCRUM es porque el equipo no se encuentra físicamente en el mismo sitio. Quizá en el futuro utilicemos herramientas más específicas para la gestión de las user stories, iteration backlog e increment … pero a día de hoy éste sistema nos está funcionando por lo sencillo y visual que es.

El objetivo de la gestión es planificar, ejecutar y controlar. Veamos a continuación cómo planificamos, ejecutamos y controlamos el valor funcional de la aplicación.

Algunos apuntes sobre la ejecución:

• El documento recoge tanto el Iteration Backlog como el Increment. Pero es un documento que sólo ve el equipo. El cliente puede ver el Product Backlog (que está en un documento a parte) y se le envía una versión “más redactada” del Increment.
• Cada iteración está en una tabla. Las tablas se guardan todas en el mismo documento, de tal manera que si vamos bajando por el documento podremos ver el backlog de las anteriores iteraciones. Las iteraciones se nombran con el primer día que se ejecutan (Iteración 18-05-2009) . Suelen ser de dos semanas.
• Todos los proyectos son gestionados desde el mismo Iteration Backlog.
• Marcamos la prioridad de una funcionalidad dentro de una iteración con [1],[2] y [3].
• Se puede saber en qué estado está una Iteración porque:
  • Si está a la izquierda y sólo pone la prioridad([1]), es que está sin empezar.
  • Si está a la izquierda pero pone la prioridad  y un dueño ([1][Luis]), es que está empezada y la está haciendo Luis.
  • Si está a la derecha, es que está terminada.
• En el incremento, además de los items terminados en la iteración, se añaden los unplanned items ([U]), defectos ([D]) y cuestiones técnicas abordadas ([T]). Supongo que para los defectos sería mucho mejor utilizar un Issue Tracker, pero normalmente los clientes suelen querer comunicarse solo por teléfono, y bastante cuesta ya hacerles escribir un mail… como para intentar que se peguen con un Issue Tracker…
• Los defectos tienen siempre prioridad sobre el desarrollo de nuevas funcionalidades.
• La trazabilidad del proyecto es enorme, no sólo porque así tenemos un histórico de todas las iteraciones, sino porque el Google Docs guarda versiones de cada cambio que se hace.. así que podríamos retrotraernos a cualquier situación pasada del documento.

Forma de detectar cómo va la iteración (controlar):

• Si se están generando muchos Unplanned Items ([U]) es que algo se diseñó mal.
• Si se están generando muchos Defectos ([D]) es que la aplicación no está suficientemente probada.
• Si se están atacando funcionalidades de prioridad [2] sin haber terminado las de prioridad [1], o se están atacando funcionalidades sin haber corregido los Defectos, probablemente se esté programando en el orden incorrecto.
• Otras cuestiones muy relacionadas con las funcionalidades, las iteraciones, sería el control de costes y plazos: lo voy a dejar fuera del artículo por no extenderme.

Algunos apuntes sobre planificación de las funcionalidades que se incluyen en cada iteración. En cada iteración se meten una serie de funcionalidades de el/los Product Backlog. Esas funcionalides cumplen que:

• Es la mayor cantidad de funcionalidades que se pueden hacer en dos semanas.
• Son las funcionalidades que más valor añaden a la aplicación.
• Camino crítico: desarrollar esas funcionalidades ayudan a descubrir posibles nuevos requisitos de forma lo más temprana posible (aunque no sea la que más valor añade), eliminar incertidumbres y hacer pensar al cliente (feedback) en qué es lo que quiere realmente. Esto también puede incluir desarrollar funcionalidades que ayuden a descubrir el diseño técnico (orientación a objetos, patrones de diseño) de la aplicación.
• La que el cliente exija (a veces no hay más remedio: hay que implementar funcionalidades que el cliente exija aunque se le argumente que no son las que más valor añaden o las que más ayudan a descubrir la forma exacta de la aplicación).
• Se evita programar funcionalides que no puedan probarse o ponerse en producción cuanto antes. Ejemplo: “Informe anual de ventas”, implementar éste informe en la primera iteración del producto, cuando todavía la empresa no ha introducido ni una sola venta, hará que no pueda probarse correctamente y traerá problemas meses después.
• Resolver defectos tiene más prioridad que desarrollar nuevas funcionalidades, aunque dependerá de la gravedad del defecto. Los defectos son difíciles de planificar porque no sabes ni cuando ni cómo saldrán.
• Es importante saber dividir o juntar funcionalidades para poder adaptarlas al tamaño de la iteración. No sirve para nada hacer “Listar facturas”, si no tienes un “añadir facturas”. Deberán ir en la misma iteración. Quizá “buscar facturas” pueda ir en la siguiente iteración, pese a que todo ello fuera planificado originalmente como “gestionar facturas (listar, añadir, modificar, eliminar, buscar)”.

Un proyecto es:

• Gestión de la integración del proyecto.
• Gestión de costes.
• Gestión de la calidad.
• Gestión de tiempos y agendas.
• Gestión del alcance del proyecto.
• Gestión de la comunicación en el proyecto (incluido el cliente).
• Gestión de la transmisión del conocimiento (pair programming, empowerment).
• Gestión de los riesgos.
• Gestión de proveedores.

La madurez del proceso se mide por:

• repetitividad de resultados
• Escalabilidad
• Mejora contínua
• know-how propio

Los principales frameworks de pruebas unitarias en PHP:

• phpUnit.
• SimpleTest.
• phpt

Comparartivas:

• phpt versus phpUnit.
• SimpleTest versus phpunit.
• SimpleTest versuss phpunit 2.

Pruebas funcionales:

• Zend_Test, extensión e phpUnit para probar el MVC del Zend Framework.
• Acceptance test in php with Selenium.

Integración continua:

• phpUnderControl
• Bamboo
• Rephlux
• Xinc

Extra point:

• phpSpec: Behaviour Driven Development (BDD) en PHP.
• Mock Objects in phpUnit.
• Mockery: an independent Mock and Stub framework for PHP.
• Pruebas unitarias mutantes.
• Pruebas unitarias y base de datos.

Mi elección es phpUnit. Y es que pese a que es verdad que su mecanismo para Mock Objects es peor que el de SimpleTest, y que escribir pruebas es más pesado que en phpT, es el framework de pruebas unitarias en PHP que elige Zend Framework (y su Zend_Test) y su creador (Sebastian Bergmann) es el que más activamente está desarrollando extensiones para base de datos, etc… así que, si todavía tienen puntos débiles, con el tiempo será el aceptado por todo el mundo. Además,  Bergmann es el principal promotor de phpUnderControl, el framework de integración continua que hemos decidido utilizar David y yo (ya explicaremos más ampliamente en su momento el por qué).

En cada iteración, las fases de Análisis –> Diseño –> Implementación, se harán SOLO para las nuevas funcionalidades. Si las fases de Pruebas –> Despliegue se hacen también SOLO para las nuevas funcionalidades, se caerá inevitablemente en la vergüenza de la Ingeniería del Software. Así que, en cada iteración, todas las funcionalidades de la aplicación deben ser probadas antes del despliegue. Pero no sólo eso, antes del despliegue, también deberán aplicarse una serie de métricas, y realizar tareas como generar la documentación para controlar la calidad del software.

• minimizar el coste de desarrollo 1: evitar que el coste de las pruebas de las funcionalidades de la iteración 1 (f1) en la iteración N sea = f1*N.
• minimizar el coste de desarrollo 2: detección y solución temprana de problemas (colisiones entre lo desarrollado por dos programadores, colisión con funcionalidades anteriores, etc.), si se integra cada semana, un desarrollador puede pasarse una semana entera desarrollando algo que choca contra otra cosa codificada por otro desarrollador, haciendo inútil todas sus horas de trabajo.
• maximizar la calidad: evitando entregar versiones donde el código nuevo puede haber estropeado el que ya funcionaba.

1. establecer una serie de métricas (variables a maximizar o minimizar) sobre el código. Sólo nos sirve aquello que podamos medir.
2. montar un sistema automático que genere información sobre esas variables y su evolución a lo largo del desarrollo (integración continua).
3. aplicar medidas sobre el código y observar si se consigue maximizar o minimizar la variable objetivo

Muchas de las medidas que maximizan la calidad producen como efecto colateral una diminución en el coste, y viceversa. Tradicionalmente se piensa que aumentar la calidad es aumentar el coste en tiempo. Pero muchas veces el tiempo invertido en aumentar la calidad (robusto, flexible, mantenible, escalable) repercute en el futuro en un menor coste de desarrollo o mantenimiento.

Valores abstractos del software:

• Robusto: libre de errores.
• Flexible: permite reutilización y adaptación a nuevos requisitos.
• Mantenible: permite entender el código tiempo después de haber sido escrito y/o por personas que no lo escribieron (estándares de sintaxis y documentación).
• Escalabilidad y rendimiento: al aumentar el número de usuarios, el rendimiento no disminuye exponencialmente.
• Seguridad: existen herramientas que enfrentan a tu código a una base de datos de vulnerabilidades conocidas.

Las variables medibles (métricas) que pongo a continuación están centradas en el código, no en la gestión de proyectos (no se incluyen métricas como “esfuerzo del equipo”, etc…). Tampoco en temas propiamente web como la accesibilidad ni el diseño de interfaces (usabilidad).

• Número de lineas de código: tiene una utilidad limitada. Depende de la forma de escribir el código, la misma sentencia se puede escribir en una o varias lineas, en diferentes lenguajes la misma funcionalidad puede tener diferente cantidad de lineas, etc. Pero si se utiliza para comprar el número de lineas de código entre dos versiones del mismo software, se puede observar si el crecimiento en lineas de código es lineal o no. Si no lo es, puede valer la pena investigar por qué.
• Cyclomatic Complexity y Npath Complexity: se trata de analizar todos los caminos que llevan al mismo código y medir cuantos caminos hay. Da una medida de la reutilización que se hace del código. No se busca ni maximizarla ni minimizarla, sino mantenerla entorno a una cifra.
• Code coverage: porcentaje de código cubierto por las pruebas. Se aplica de forma práctica en las pruebas unitarias. Los principales frameworks xUnit dan datos de code coverage. Se busca maximizarla.
• Cohesion:  mide la relación entre las responsabilidades de las clases de un mismo módulo.  Se busca maximizarla.
• Acoplamiento: Si dos clases están poco acopladas, si se hace un cambio en una de las clases repercutirá poco o nada en la otra clase. Si están muy acopladas, un cambio en una clase supondrá cambios importantes en la otra. Se busca software con alta cohensión y  bajo acoplamiento. El acoplamiento se puede medir en función del número de imports (includes), extends, implements, que relaciona a unas clases y módulos con otras.

Un software cuyo código tiene una cohesión alta, un acoplamiento bajo, tiene un alto porcentaje de código cubierto por pruebas unitarias y/o funcionales, tiene código que se reutiliza desde diferentes partes y cuyas lineas crecen de manera controlada, es un código que permitirá añadir funcionalidades facilmente (reduciendo el coste de añadirlas) y permitirá mantener más fácilmente el código existente.

Algunas herramientas para aplicar métricas sobre el software:

• PHP Depend
• Project Mess Detection

.

• Tipo de cliente: no es lo mismo si es un profano del desarrollo de software que, además, no usa apenas internet ni ordenadores, o si es un usuario habitual de internet y ordenadores, o si es otro informático de otra empresa. No se habla en el mismo idioma, no se puede utilizar los mismos entregables (¿entenderá UML?) ni se puede utilizar el mismo proceso (a veces potenciar el feedback de alguien totalmente profano puede ser contraproducente).
• Tipo de solución: no es lo mismo instalar y configurar Magento (una solución e-commerce en PHP) y luego personalizarlo, que desarrollar “desde cero” un sistema de gestión de información. Para el primer caso no se me ocurriría utilizar pruebas unitarias o integració continua, mientras en el segundo caso es una buena idea.
• Tipo de presupuestado: coste fijo, coste por objetivos. Si se trata de un desarrollo dividido en objetivos, la mayoría de prácticas ágiles encajan a las mil maravillas. Sin embargo, en caso de ser un desarrollo a coste fijo, hay que tener mucho cuidado con “aceptar que los requisitos son siempre cambiantes” porque el coste del proyecto puede dispararse con facilidad.

Un par de preguntas y, como siempre, me quedo a la espera de lo que escribáis en los comentarios:

• ¿Qué factores os influyen más a la hora de configurar cómo será vuestro desarrollo?
• ¿Existe una matriz que relacione factores del escenario de desarrollo con metodologías o prácticas recomendadas? ¿Creéis que podría llegar a hacerse?

Centremonos en los tipos de pruebas:

• Pruebas unitarias: se encargan de probar una clase en concreto, testeando cada uno de sus métodos y viendo si dados unos parámetros de entrada, la salida es la esperada.
• Pruebas funcionales: como su propio nombre indican, prueban una funcionalidad completa, donde pueden estar implicadas una o varias clases, la propia interfaz de usuario y, en el caso del desarrollo web, llamadas AJAX.
• Pruebas de regresión: son aquellas pruebas cuyo objetivo es comprobar por qué ha dejado de funcionar algo que ya funcionaba. El objetivo de las pruebas de regresión es no tener que “volver atrás”.
• Pruebas de aceptación: son pruebas funcionales, pero vistas directamente desde el cliente. Digamos que son aquellas pruebas que demuestran al cliente que la funcionalidad está terminada y funciona correctamente.
• Pruebas de integración: conjunto de pruebas unitarias, funcionales, de regresión y/o de aceptación que se realizan las probar el software. Incluye también comprobar que lo programado por los diferentes desarrollados no “choca” entre sí y que funcionará en un entorno real.

Conceptos relacionados:

• TDD – Test Driven Development: son pruebas unitarias que siguen el principio “test-first”. Esto es, la prueba unitaria se crea ANTES de crear la propia clase. La idea es que, al pensar en cómo probarás la clase, estás pensando en la propia clase desde el punto de vista de su interfaz (qué métodos tendrá y con qué parámetros), ayudando a desarrollar antes un mejor diseño. De ésta manera, además, te aseguras de que no exista ninguna clase que no esté probada.
• BDD – Behaviour Driven Development: sus defensores la consideran una evolución de TDD, con una forma de escribir las pruebas más centrada en el comportamiento (behaviour) que debe tener la clase.
• Code Coverage: métrica que mide la cantidad de código que está probado unitariamente.

En un entorno de integración continua, las pruebas (unitarias, funcionales, etc.) y las métricas (code coverage, syntax check, etc.) se ejecutan de manera regular con el objetivo de probar que la evolución del software desarrollado funciona perfectamente, tanto para las funcionalidades nuevas como para aquellas que ya existían. Una de las claves es que las pruebas sean automatizadas, porque si se ejecutaran manualmente, el coste de hacerlo “continuamente” sería inabordable.

• Planning: user stories, release planning, small releases, project velocity, iterations, iteration planning, move people around, stand-up meetings
• Designing: simplificity, system metaphor, CRCcards, spike solutions, no funcionality added early and refactor.
• Testing: unit testing, acceptance test, etc.
• Coding: integración continua y TDD.

Cualquiera de las metodologías ágiles puede cumplir la parte de planning, designing y testing. Es más, por seguir esos principios generales podrás decir que estás siguiendo una metodología ágil, pero nadie podrá adivinar cual exactamente. Como se explica en el artículo más completo que yo he leído sobre todas los métodos ágiles que hay, programación extrema sería una metodología más centrada en la solución técnica que en la gestión de proyectos. Por eso es tan fácil combinarla con metodologías más enfocadas a la gestión de proyectos como SCRUM.

Respecto a la parte de coding, tenemos dos técnicas: Test Driven Development (TDD) e Integración continua.  Recordemos que hacer TDD es escribir las pruebas unitarias ANTES de escribir las clases que prueban. O sea que si utilizamos un servidor de integración continua y hacemos pruebas unitarias DESPUES de escribir las clases, no estaremos haciendo Programación Extrema.

El propio Ken Beck, en su libro Extreme Programming Explained, afirma que no hay en su metodología ninguna práctica revolucionaria, que sólo es la combinación de una serie de prácticas y su seguimiento de “manera extrema” (muy estricta).

Me queda la sensación de que “Programación extrema” fue una manera de llamar originariamente que a día de hoy está obsoleta y que se ha dividido en :

1. las “prácticas ágiles básicas” (iterativo, incremental, fortalecer la comunicación directa, pruebas unitarias, funcionales, etc.)
2. integración contínua
3. TDD

Si sigues los puntos 1 y 2, y haces pruebas unitarias después de escribir la clase, puedes estar siguiendo casi cualquier metodología ágil. Y si haces el punto 3, estarás haciendo Test Driven Development, que queda mucho más claro que decir “Programación extrema”.

¿Qué opináis vosotros? ¿Tiene cabida el término Programación Extrema?