Ir al contenido principal

Industrializando el proceso de construcción de software y su gestión



La satisfacción de nuestros clientes es uno de los objetivos cuando emprendemos un proyecto. Hasta tal punto que en ocasiones rechazamos proyectos en los que las expectativas de nuestros clientes no se pueden alcanzar (normalmente por restricciones presupuestarias, aunque no únicamente).

Los puntos que influyen en la satisfacción de los clientes son: 

  • Que entendamos sus necesidades y seamos capaces de definir un alcance.
  • Completar el alcance en los plazos acordados.
  • Que los entregables sean de calidad (esto es: que estén adecuados al uso, que objetivamente el código cumpla con los estándares y buenas prácticas, que sean seguros, usables, y que estén verificados funcionalmente, lo cuál, sin duda reducirá los errores y problemas en fase de explotación).
  • Que seamos capaces de comunicar de manera adecuada los puntos anteriores en cada momento.

A medida que el equipo que dirijo se ha ido haciendo más grande, además de acompañarme de un buen equipo de dirección, en aras a mantener la satisfacción de nuestros clientes hemos tenido que ir desarrollando e integrando metodologías de gestión y desarrollo, que hemos modelado con lo que llamamos Ecosistema de desarrollo software. Al principio era algo básico: un repositorio de código, una wiki, un sistema de tickets, un evaluador de código, una librería de artefactos, y un servidor de integración continua. Como decía, algo básico, pero tremendamente últil y la base de nuestro actual sistema. 

El tener más equipos, más proyectos, más clientes, más facturación, te hace tener la cabeza en demasiadas cosas, pero si no queríamos reducir nuestras prestaciones, en una división que no se gestiona con un horario, sino por objetivos, debíamos seguir mejorando en nuestra metodología y en las herramientas que automatizaran la obtención de la información que necesitábamos en cada momento.

La metodología Spice (ISO 15504) tenía carencias evidentes, por lo que una de las primeras decisiones fue optar por cambiar a la certificación CMMi (nivel 3). La decisión natural del 80% de las empresas es obtener el sello de certificación. La nuestra, en cambio, fue nutrirnos, aprender e integrar con otras metodologías que nos estaban dando excelentes resultados como PMP y Scrum, además de algunas buenas prácticas de ITIL. Como podéis imaginar el trabajo no fue fácil. Cada norma o metodología habla su propio lenguaje y aunque tienen procesos en común, el mapeo no es automático. 

A medida que describíamos nuestra nueva forma de trabajar, nos íbamos dando cuenta que nuestro ecosistema se nos había quedado pequeño. Era el momento de desarrollar un nuevo ecosistema que diera respuesta a nuestras nuevas necesidades. Obviamente íbamos a seguir usando herramientas que nos estaban dando un excelente resultado, a saber:
  • Subversion (respositorio de código)
  • Redmine (aquí reducimos toda la deuda técnica de nuestros proyectos, a través de su wiki, y modelamos nuestros Sprints de Scrum con milestones, tareas padres y tickets,... de tal manera que nuestros clientes tengan trazabilidad desde el requisito funcional que le proponemos en fase de oferta, hasta el código que lo implementa (gracias a la integración con Subversion), pasando por las historias de usuario que lo componen, desarrolladores que han intervenido, plazos…
  • Nexus (nuestro repositorio de artefactos).
  • Jenkins (nuestro servidor de integración continua que despliega automáticamente los desarrollos para que puedan ser probados funcionalmente, verificados, o validados por nuestros clientes. Además ejecuta las pruebas unitarias).
  • Sonar (nos proporciona métricas de calidad objetivas sobre nuestro código, cumplimientos de reglas, complejidad ciclomática, nivel de documentación, número de líneas repetidas…).
  • Testlink (nos proporciona evidencias de las pruebas funcionales realizadas).

¿Y cómo hemos mejorado el Ecosistema?

  • Ahora todas estas herramientas se integran con un sistema Single Sign On, y nos proporcionan todo tipo de trazabilidad.
  • Podemos definir la política de accesos, roles para cada proyecto, o de manera general.
  • Hemos implementado un sistema de mensajería de tal manera que haya ciertos informes que se generan automáticamente y se envían a las personas designadas (tanto del equipo, como del cliente).
  • El sistema indica al equipo las tareas que debe realizar cada uno en cada momento.
  • Se genera documentación y la custodia a través de un correo enviado a buzones específicos.
  • Indexa todo el contenido de la documentación, lo cuál facilita las búsquedas.
  • Los plazos de ejecución retroalimentan nuestros estimadores objetivos, de tal manera que nuestras estimaciones sean cada vez mejor.
  • Sistema de ayuda a la toma de decisiones. Implementamos un cuadro de mandos que nos indica el estado de los proyectos en tiempo real. Esto es: método del valor ganado, variación del coste, variación del cronograma. Así sabemos si estamos ganando o perdiendo dinero, y si vamos adelantados o retrasados. El mismo sistema crea informes y los envía.
  • El cuadro de mandos anterior se puede consultar también en una aplicación móvil, lo cuál nos facilita la vida de manera drástica a los que pasamos mucho tiempo viajando, o fuera de la oficina.
  • A través de toda esta información y de la trazabilidad que tenemos entre el trabajo y quién lo desarrolla podemos evaluar y desarrollar nuestros equipos de trabajo.
Con todo lo anterior, no solo garantizamos la satisfacción de nuestros clientes, sino que nos situamos en una posición que nos permite seguir creciendo manteniendo controlados nuestros proyectos y su rentabilidad en todo momento, además de conseguir una diferenciación y una ventaja competitiva con respecto a nuestra competencia. 

Este ecosistema se llama Zisde.

Comentarios

Entradas populares de este blog

Métrica v3 vs Metodologías Ágiles

Métrica v3: Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información que propone el Ministerio de Administraciones Públicas.

Cualquier defensor de la técnicas, metodologías y herramienta ágiles sostendrá que Métrica v3 es un sistema demasiado pesado, tanto en su implementación, como en sus procesos de mantenimiento. Yo lo corroboraría, pero sin demonizarla.

Estoy acostumbrado a que en este mundo de la informática se creen auténticos "dogmas de fe", que acarrean sus propias "guerras religiosas". Algunos ejemplos podrían ser: Software privativo vs Software libre, Windows vs Linux, Web Services vs Rest, Oracle vs MySQL, Explorer vs Firefox, Apache vs IIS, Eclipse vs Netbeans, y así podríamos seguir con un largo etcétera. En vez de buscar la mejor solución, o soluciones universales, yo propongo realizar un intenso análisis, y respondernos ciertas preguntas. Por regla general, no hay una solución que valga "para todo". La pregunta que …

Scrum para Dummies

Introducción
Scrum es un marco de referencia para desarrollo ágil de productos. Esta metodología se puede aplicar a procesos de producción de distintos sectores, yo me centraré en el de Desarrollo de Software.

Desarrollo tradicional vs Desarrollo Ágil

Especialización vs Equipo Multidisciplinar
Fases vs Solapamiento
Requisitos detallados vs Visión del producto
Seguimiento del plan vs Adaptación a los cambios

Las metodologías tradicionales se ven como una carrera de relevos, en el que cada miembro es responsable de una fase, y hasta que no se termina una fase, es imposible comenzar las siguientes.
En cambio, las metodologías ágiles son más como un partido de Rugby, en el que el empuje conjunto del equipo es importantísimo para el éxito. De hecho, Scrum significa melé.

Ya comparé en un post anterior estos dos tipos de metodologías.

¿Por qué Scrum?
El cliente puede ver resultados desde el primer momento.
Se ahorra el tiempo que en las metodologías tradicionales se dedica en con…

¿Por qué Yii Framework?

En Soltel presumimos de tener una actitud innovadora, que nos obliga a probar las distintas tecnologías que van llegando al mercado, y que ajustándose a nuestro stack, puedan mejorar en algo nuestros desarrollos.

Una vez analizado el framework o librería, lo probamos en proyectos internos que nos permitan conocer con más detalle sus características. En este trabajo de campo es donde realmente se decide si es interesante o no añadir el framework a nuestro stack, y con ello ofrecerlo en los desarrollos que realizamos para nuestros clientes.

En este proceso, llevábamos bastante tiempo buscando un framework PHP que realmente aportara valor y se adecuara en tiempos de desarrollo, rendimiento y arquitectura a lo que necesitamos ofrecer en nuestros proyectos. Ya habíamos descartado frameworks como Prado, por ser bastante pesado y tener una arquitectura demasiado compleja.

Con Yii, sin embargo, nos hemos llevado una agradable sorpresa. Yii es un framework PHP, libre (licencia BSD), basado en pr…