Ciclo de Trabajo de Codice Software II - Herramientas

21:25 1 Comments

Ya conocemos los inicios de Plastic SCM, ahora veamos cómo trabajan.

Las armas del equipo de Plastic SCM son muchas y variadas. Son guerreros preparados para cualquier batalla :P. Pero hay tres que destacan por encima de todas, son las que utilizan a diario:


TTS

TTS es su propio issue tracker con el que manejan todas las tareas. TTS son las siglas de Task Tracking System.  La primera versión de TTS data de 2001!!. La desarrollaron David y Pablo.



TTS, no es un producto comercial, aunque muchas veces han pensado en que sería un buen complemento para Plastic SCM. Puede que una de las razones para no hacerlo, es que saben el trabajo que hay detrás del lanzamiento y el mantenimiento de un producto.
 Dicho esto, TTS está en el ciclo de mejora continua. El equipo propone ideas que se valoran y se van implementando.
 ¿Pero qué contiene el TTS? Pues todas las descripciones de:
  • Información de Bugs: priorizados usando el cálculo del user pain. Basado en este artículo de Jonathan decidieron utilizar estas reglas para pensar de manera más estructurada, y no simplemente aventurarse en la calificación de las incidencias con un muy alto o muy bajo. 
  • Nuevas tareas: suelen llevar un análisis y/o un diseño asociados, normalmente bastante visuales, ya sea en un documento o en la wiki, dependiendo del ánimo de quien escriba. 
  • Rendimiento:horas estimadas vs horas trabajadas. Las trabajadas (un poco anti-Scrum) les sirven para tener una base de datos de estimaciones propias muy buena, muy Steve McConnell

Wiki Interna

En al wiki se guarda y actualiza información acerca de documentación del proyecto, artículos técnicos,  infraestructura, y un divertidísimo apartado con frases míticas del equipo:
"No he pasado los test, pero este cambio no puede romper nada...

fatal error
 "Es un fallo muy raro que no le va a salir a nadie..."

El arma secreta

 Dentro de las herramientas ocultas existe una poderosa hoja de cálculo. Es su particular gurú que les ayuda a hacer el cross-check del plan, la estimación de las tareas en horas (con PERT) y alguna que otra banal tarea. Creo que la erradicarán cuando terminen Plastic SCM version 9.

En el siguiente capítulo hablaremos de la parte de test dentro del ciclo de trabajo de desarrollo.

1 comentarios:

Ciclo de Trabajo de Codice Software I - Historia

0:09 0 Comments

Hace tiempo que el equipo de Codice Software tenía ganas de ganas de contar cómo es su ciclo de trabajo para crear Plastic SCM. Pero son tímidos, así que voy a aprovechar que acabo de unirme a ellos para desvelaros los detalles más secretos.

Un poco de historia

El desarrollo de Plastic SCM empezó allá por Agosto de 2005. Comenzaron siendo tan sólo dos desarrolladores, los fundadores insensatos de esta locura. Para crear el núcleo del equipo, se unieron dos intrépidos más. Y ahora, Plastic SCM se elabora cada día gracias a este fantástico y ya numeroso grupo.

Desde el principio se tenía claro el modo de trabajo, “Rama por Tarea”. ¿Por qué? Porque era lo que querían que Plastic SCM soportara desde el principio y que mejor forma de ponerlo a prueba que usándolo ellos mismos. 


La metodología de trabajo adoptada fue Scrum, porque simplemente encajaba a la perfección. Un backlog lleno de historias, con sus tareas correspondientes, cada una realizada en una rama. Iteraciones y entregas incrementales de producto. Era lo que necesitaban. Comenzaron realizando sprint de 30 días (4 semanas).  

En el año 2007 fueron la primera PYME en conseguir CMMi2, y trabajando con el modelo Scrum.
Fue un periodo bastante duro, puesto que a finales de 2006, Noviembre exactamente, ya habían lanzado Plastic SCM 1.0 y en esos momentos estában trabajando en la version 1.5.   El equipo se fue afinando en todos los ámbitos: en las estimaciones, en el desarrollo... La consecuencia fue comenzar a realizar mejoras en el modelo de trabajo.
Manejan un “product backlog” bastante dinámico, en el que congelan todo lo que pueden cada dos semanas. Es decir, ahora el Sprint se ha reducido a dos semanas.

La estimación de las tareas la realizan en horas. Llegan a ser tan precisos en las estimaciones como un reloj suizo. El máximo de tiempo que puede alcanzar una tarea es de 16 horas. Todas las tareas están bajo control y manejadas por todos desde su propio issue tracker, sean del tipo que sean: bugs, nuevas funcionalidades, performance, refactor, tests,.... Y a partir de aquí comienza la parte más divertida: el desarrollo
Regla de oro: no hay código sin tarea asociada, aunque sea tan sólo una línea

Trabajan sobre tres pilares fundamentales e indiscutibles: testing, control de versiones y control de tareas. Los tres forman el core para el desarrollo de software.

El tiempo pasa y PlasticSCM ha ido creciendo. Unos datos muy simples para que os hagais una idea de su evolución:
  • Julio 2007: 180.000 líneas de código
  • Julio 2012: 845.000 líneas de código, de las cuales 250.000 son de test. (casi un 30% de test)

No os perdais nuestra siguiente entrega... las armas con las que desarrollamos Plastic SCM

0 comentarios: