No construyas equipos!

22:22 0 Comments

Desde el año 2005 en el que empezaron David y Pablo como únicos integrantes del equipo de Plastic SCM, al que se unieron Borja y Dani en seguida, ninguna persona que se ha incorporado al equipo de desarrollo lo ha dejado. Ni lo han hecho por voluntad propia, ni se la pedido que lo hagan.

Estamos en el año 2012, y el equipo de desarrollo de Plastic SCM está formado por 12 personas!!

¿Cual es el secreto?

¿Cual es el secreto? ¿Tienen la receta de la poción mágica de Panoramix?

Pues la receta es que hacen lo que les gusta.

El vivir experiencias de trabajo previas en otras empresas antes de arrancar Plastic SCM fue determinante a la hora de crear el equipo. Simplemente ayudaron a decidir todo lo que no querían para la persona que entrara en el equipo de desarrollo.

David y Pablo tuvieron la suerte de trabajar junto a un equipo de mucho nivel en Sony (Bélgica). Vivieron de primera mano todos los valores que han tratado de fomentar en Plastic SCM.

La lectura de libros como Peopleware, también han influido a la hora de como construir equipo, como encontrar a la gente adecuada.

Trabajo variado, desafios constantes (Web, software de sistema, GUI, seguridad..), libertad para lanzar propuestas, confianza. Todo puede sonar a cuento, a sueño no posible, pero cuando hablas con cada uno de ellos lo que te transmiten es: Orgullo y Felicidad

• Orgullo porque saben lo que hacen como desarrolladores, un producto que ayuda a su gente, desarrolladores.
• Felicidad, porque crean con calidad y reconocen la influencia que genera lo que están creando.

Uno de los 7 principios de Lean Software Development es: "Empower the team" No hay recursos, hay personas. No hay un líder que enarbola la bandera y al que se sigue.

Hay pequeñas celulas que se van creando de modo que comparten su forma de trabajo: libertad con responsabilidad, confianza, esfuerzo, aprendizaje. Cada vez que hay una persona nueva, se va integrando en el equipo, de modo natural, como la pieza perfecta que se necesita en el puzzle.

La mezcla de experiencia con la inexperiencia no es ningún problema. El equipo se encarga de arropar con paciencia y disciplina a las personas con menos experiencia. Así de manera natural se van creando esa espiral de trabajo: desarrollo, puesta en común del trabajo, proposición de ideas, responsabilidad de las tareas realizadas, seguimiento del producto, libertad,...

Plastic SCM no han construido un equipo de desarrollo. Han permitido que todos sus valores sean los artifices de crear ese fantástico grupo que cada día lanza una nueva release del producto.

"Pull" Mentoring

8:45 internals 0 Comments

Recientemente se han producido tres nuevas incorporaciones en Plastic SCM. El equipo está creciendo con savia nueva. Para alguno de ellos no es su primer trabajo, pero para otros sí.

Al incorporarte a un nuevo equipo lo que sobran son las ganas de trabajar. La primera semana, utilizando simil de montañeros, podríamos decir que estás en el campo base aclimatandote. Se imparte un training en el que te familiarizas con la que será tu arma de trabajo: Plastic SCM. A partir de ese momento, comienza tu escalada hacia la cima de la montaña.

Mentor es un consejero o guía. Persona que da consejos, que dirige o encamina, como un sherpa en la montaña. En Codice Software no se nombra un sherpa por cada persona que entra, porque no tienes uno específico, tienes tantos sherpas como personas componen el equipo. Es verdad, que en esta escala hay un punto final, cómo una última referencia, pero en ningún momento hay que pensar que es más importante que el resto.

El equipo de Plastic SCM apoya, aconseja, ayuda, responde pero en ningún momento está buscando Robocop's . El “mentoring” lo hace realmente la persona que entra. Cada uno de manera personal se marca si quiere subir a un K2 o simplemente se conforma con el Mulhacen. Es “pull” mentoring. Básicamente todas “las operaciones” que realizas ocurren así. Cada instante en el que preguntas, muestras tu trabajo, compartes las ideas … estás haciendo “pull”.

Y cuando esto sucede:

• Cada uno aprende las lineas base para realizar su trabajo
• No necesitas que nadie te asigne las tareas
• Las habilidades de las persona se van perfeccionando cada día de modo que dan más calidad tanto a su trabajo como al del equipo entero

Aunque ya no seas un novato, sigues haciendo “pulling” cada día?

Ciclo de Trabajo de Codice Software VI: Últimos pasos

0:05 noticias 0 Comments

Y llegamos al final de la serie. He intentado cubrir con una visión general todo el ciclo de trabajo que realiza el equipo de Plastic SCM, para sacar adelante el producto: herramientas, test, documentación.
¿Qué me falta por contar? Pues cómo sacamos una nueva versión de nuestro producto.

Nueva Release

Una vez que hay un número de tareas terminadas, probadas por Bamboo, revisadas y validadas… se crea una nueva release. Durante años se hacía una release nueva a la semana, muchas veces interna, otras veces la publicaban en la web. Con esto se pretendía tener:

• Visibilidad de todo el proceso de trabajo (medible en releases) 
• Solución de respaldo (frente a imprevistos) 

 Desde hace más de medio año dejaron de hacer releases semanales y pasaron a realizar una nueva release cada 24 horas. Sí, una cada día y no, no están locos al final de cada sprint. Cada día integran las tareas que se han sido revisadas, validadas y han pasado los tests.
Uno de los desarrolladores es el encargado de las releases o “integrador”.("The IntegraTHOR") En muchos equipos “top-agile” esto parece que no encaja, pero se trata de la base del proceso de integración controlada por el que primas versiones estables ante todo.

Test de Release

Es una de la tareas del integrador y tiene su sitio de honor porque es donde se dispara toda la artillería de testing.
Se pasan todos los tests automáticos en todas las combinaciones soportadas.

• Smoke tests: en todas las plataformas y backends (bases de datos) soportados. 
• Windows: desde W2k (que todavía soportan porque son unos nostálgicos), XP, W2003 server, 2008, Vista, 7 y ahora W8. 
• Mac OS X 
• Un montón de “sabores” de Linux: openSuSE, ReadHat, Ubuntu.

Combinando arquitecturas 32 y 64 bits (y en ocasiones SPARC 64 aunque hace tiempo que no están incluyendo este juego de pruebas).

Se usan los mismos juegos que usamos para “Bamboo” más otros como tests de instalación en línea de comandos, tests de “restart”, es decir , reinician el servidor a mitad de cada test para comprobar que no hay problemas de cachés y juegos especiales de merge y localización. 

• GUI tests: ahora lanzamos el mismo juego que usamos durante las pruebas de “Bamboo” sobre todas las plataformas soportadas (no sólo una) para asegurar la compatibilidad. Han lanzado juegos especiales para la Shell Extension, plugins para Eclipse, Visual Studio, etc.
• Performance tests: usan Amazon EC2 para esto, tests especialmente diseñados para asegurar que no se rompe el rendimiento de ciertas operaciones básicas con gran carga de datos. Miden también memoria y uso de CPU. 

En total los Tests de Release necesitan más de 24h para ejecutarse, pero con 7 servidores y un buen número de máquinas virtuales se pueden reducir a aproximadamente 6 horas.
El siguiente objetivo es usar mucho más las máquinas en cloud y reducir el tiempo a menos de 1h antes de que acabe el año, lo que les dará mucha más flexibilidad en la creación de las releases. Utilizan herramientas como FxCop para mantener la limpieza del código. NCover para medir la cobertura de sus tests y medir la complejidad ciclomática del código.

Tareas del Integrador

Las ventajas son muchas, pero la más importante es que tienen un responsable encargado de avisar de lo bien (o menos bien) que ha ido la release.

El trabajo del integrador es, en esencia es como un guardia de tráfico:

• Coger cada tarea, integrar su rama. Sólo coge ramas que hayan pasado todo el proceso de test, revisión y validación. Vigila que las tareas pasen por cada uno de sus estados: de Open a Resolved, Reviewed y Validated. Y además que estén correctamente introducidas en el control de tareas para posteriormente obtener estadísticas útiles.
• Encargarse de que los conflictos de merge se resuelvan bien y hacer saltar las alarmas ante cualquier problema (es una fase más de revisión). 
• Pasar un juego inicial de tests: todos los unitarios y smoke lo más rápido posible (usa unas 6 máquinas para esto, reduciendo el tiempo de “smoke” a menos de 20 minutos). 
• Pasar y monitorizar todos los Tests de Release. 
• Crear las Release Notes. 
• Generar los binarios de release. 
• Actualizar los servidores internos. 
• Lanzar la subida de la nueva release a la web.
• Dirigir el test manual, supervisión y control de bugs detectados

El integrador es el último responsable de que la release vaya bien, de que se cumplan los criterios de calidad, de hacer saltar las alarmas si algo no va bien, de mantener siempre funcionando el juego de tests de release (ya sea haciendo el tareas de mantenimiento o asignando a miembros del equipo dichas tareas). Dada la posición privilegiada del integrador, tiene unan visión global del proyecto, por lo que es capaz de detectar puntos de mejora en el proceso y de sugerir nuevas funcionalidades, mayor cobertura en los tests, etc.

Conclusión

Como habeis podido leer, en el proceso de trabajo tiene un peso muy importante toda la parte de pruebas, con un número bastante alto de tests automáticos que completan con tests exploratorios. Soportamos muchas plataformas y cómo ya hemos dicho la calidad es una constante en nuestro trabajo. Nuestro proceso tiene que seguir mejorando mucho porque Plastic SCM compite codo con codo con productos como Perforce, ClearCase, TFS, Subversion o Git.
El equipo de desarrollo es el más pequeño que el de ninguno de ellos, pero Plastic SCM cuenta con una lista de características de control de versiones más amplia.
No es un trabajo sencillo, pero se ve que les encanta su trabajo y se esfuerzan  cada día por ser los mejores.
 ¿Te gustaría venir a conocernos?

Ciclo de Trabajo de Codice Software V - Documentación

22:44 0 Comments

En los capítulos anteriores hemos hablado de herramientas, procesos de test... y hoy voy a enseñaros donde se guarda toda la sabiduría de este proceso.

Doc Snippets

El equipo de Plastic SCM quería salvaguardar todo el trabajo realizado por cada tarea. pero en formato texto (Texto, sí, has leido bien. Esto aumenta los puntos dentro del programa de hackers!).
Desde hace 8 meses, crean un fichero donde puedes encontrar:

• Qué hace cada tarea
• Por qué es importante esa tarea
• Enlaces con otras tareas
• Imágenes de la funcionalidad añadida

El repositorio donde se almacena recibe el nombre de Task Documentation.

Items en el repositorio de TaskDocumentation

Hubo un planteamiento de adjuntarlo todo en el issue tracker, pero les daba rabia no meterlo en un repositorio de Plastic SCM.
El idioma oficial dentro de Plastic SCM es el inglés así que excepto las tareas primitivas, todo lo que te vas a encontrar está escrito en inglés.

¿Cuál es el sentido de los doc snippets?

Cuando alguien del equipo está realizando una tarea, escribir un pequeño texto de no más de 10 líneas no lleva mucho tiempo, unos minutos.
Gracias a ese pequeño esfuerzo estás generando material muy valioso para:

• Blog posts: con el texto que cuenta la explicación de la tarea, el por qué, capturas de pantalla, tienes el inicio para poder escribir un post.
• Actualización de manuales: ayudamos a la "technical writer" de Estados Unidos, para que no tenga que buscar las mil y una diferencias entre versiones ella sola. Dejar la documentación coherente, sin faltas ortográficas, es su trabajo... pero explicar el sentido de la nueva característica, o la mejora en el rendimiento es labor de cada miembro del equipo.

Imagenes de una tarea en el TaskDocumentation

Ciclo de Trabajo de Codice Software IV - DoD

8:07 noticias 0 Comments

En el anterior post el tema fueron los test, en este será el DoD (Definition Of Done ) dentro del ciclo de trabajo de Codice Software.
En el proceso de mejora continua de Plastic SCM han incorporado dos nuevas actividades:

Revisión de Código de cada Tarea

Todas las tareas, independientemente del tipo que sean, se revisan. Al escribir una nueva tarea en su propio issue tracker, TTS, le asignan el revisor de la misma y dentro de su planificación le reservan el tiempo correspondiente a la revisión.

El code review de cada tarea se puede hace con el sistema incluido en Plastic SCM, o con simples notas añadidas desde la vista de WebUI, cómo se puede ver en la siguiente imagen.

Code reviews on WebUI (Plastic SCM)

Validación de cada Tarea

Una vez revisada la tarea, otro miembro del equipo que tiene asignada la validación, coge la tarea y verifica que hace efectivamente lo que tiene que hacer.
Busca errores típicos que un test no encontraría:

• un label mal puesto en un formulario
• errores ortográficos
• tab orders rotos
• código que no tenga ningún sentido

Si el resultado es un bug se intenta reproducir de nuevo y se verifica que no vuelve a suceder. Todo el equipo está metido en las actividades de verificación y validación.

¿Que obtienen?

Pues sobre todo implicación en el proceso de calidad. Todo el equipo está concienciado y sabe que no hay labores de “tester”. La calidad es indiscutible en Plastic SCM

Al implantar el proceso completo con la validación/revisión de las tareas se ha ralentizado mucho el proceso completo de desarrollo. Hay que hacer estimaciones teniendo en cuenta estas dos nuevas fases para cada una de las tareas.

Han sido un par de semanas a ritmo más lento, y sin duda han sufrido un impacto en el número de tareas cerradas, pero la idea es evitar regresiones, bugs, …

Ahora están muy contentos porque notan que vuelven a coger velocidad de nuevo. Revisión y Validación están completamente incorporados a su flujo de trabajo.

Y seguimos desgranando el ciclo de trabajo de Plastic SCM!!! Aún hay más!!!

Ciclo de Trabajo de Codice Software III: Test

9:18 0 Comments

En el capítulo anterior, os he mostrado las herramientas de trabajo.
En esta ocasión os voy a enseñar la parte del ciclo de trabajo de cada uno de los desarrolladores de Plastic SCM, correspondiente a los test.

Testear cada rama

Durante el desarrollo de una tarea, la persona del equipo encargada de llevarla a cabo pasaba una serie de test en su rama. Esto lo puede hacer al finalizar el desarrollo de la tarea o las veces que quiera mientras la está haciendo.
Hay tres tipos de test, que se mantienen entre todo el equipo:

• Test Unitarios: realizados en NUNIT, son rápidos y efectivos.
• Test de Línea de Comandos: permiten probar la parte Interfaz de Línea de Comandos (CLI ) de Plastic SCM. Hay cerca de 400 tests, y cada uno tarda un mínimo de 5 segundos por test. Prueban el sistema end-to-end. Desde hace más de un año, están intentando rebajar el número de tests de este tipo y aumentar los tests unitarios, pero durante mucho tiempo han sido el centro del sistema de pruebas y un salvavidas. El mayor inconveniente es el tiempo de ejecución: un juego completo puede tardar casi 50 minutos o 1 hora en una máquina "normal".
• Test GUI (Graphical User Interface): en esta parte utilizan test complete. Hay más de 250 tests para la parte de interfaz gráfica. Estos test, se ejecutan por cada tarea, pero lo hacen en una máquina virtual, porque hacerlo en tu propia máquina significa quedarte sin control: se apoderan de ratón y teclado.

Al realizar esta parte, lanzar los test en la máquina de cada desarrollador, se han encontrado con que:

• Ralentizan el trabajo: ya he comentado que los tests de GUI, pueden llegar a bloquear la máquina.
• Saltar esta fase: es fácil hacerlo, pensando esto no falla seguro.
• No hay log de registro: cada uno tiene la responsabilidad de hacerlo. Saben que las pruebas que no hagan se las pasan a la persona responsable de los merges, porque nada se queda sin probar.

Conclusión

Tenían que lograr pasar los test sobre cada tarea de forma controlada.

Esto lo han conseguido con Bamboo (Atlassian) empleando, a qué no lo adivinas?... pues sí "Rama por Tarea".

 El proceso de trabajo es el siguiente:

1. Bamboo escucha con los scripts de Plastic SCM hasta que encuentra una rama con el atributo "status" colocado a "finish"
2. Cambia el estado a "testing"
3. Utilizando el update de Plastic SCM, optimizado para bajar sólo lo que ha cambiado desde el punto anterior que tuviera Bamboo, baja el código de la rama.
4. Compila, si falla lanzará un error.
5. Pasa FXCop buscando nuevos fallos.
6. Pasa tests unitarios.
7. Pasa Smoke Test, los test para la parte de Interfaz de Linea de Comandos (CLI)
8. Pasa los test GUI, para la parte gráfica.

Si todos los tests han ido bien y no han lanzado error, la rama se pasa a estado "tested" y se va a por la siguiente rama.
Ahora el proceso es fantástico, se pasan los test de Bamboo en Windows y en Linux en paralelo.