Común denominador entre los que mejor software desarrollan

El pasado 31 de enero se celebraba en Madrid una reunión del grupo de trabajo MadQA. En esta ocasión presentaba su charla Javier Garzas, con el título “Qué caracteriza (y qué no) a las organizaciones que mejor desarrollan software”.

Cuando me enteré del evento hice todo lo posible por asistir, pero el precio del AVE con pocas horas de antelación es prohibitivo para mi. Como el evento se celebraba en el espacio CAMON supuse que habría streaming, pero finalmente no lo hubo. He leído algunos comentarios que apuntan que la charla se grabó y que está previsto publicarla.

He leído comentarios, la crónica de Jesús Hernández Abeleira y a la espera de que se publiquen las transparencias. Como no pude asistir me gustaría aportar mis dos céntimos y compartir lo que yo he percibido entre los que mejor desarrollan software. Antes de nada me gustaría decir que desarrollar software orientado a producto (construir producto) y desarrollar software para terceros (llave en mano) son dos caminos muy diferentes y con ciclos de vida propios. Por lo tanto, seamos un poco flexibles porque de lo contrario muchas ideas se caerían sólo con argumentar productividad, eficiencia, rentabilidad, etc.

Algo que hacemos en klicap antes de comenzar una auditoría de software es una checklist que vamos completando con los primeros correos, llamadas de teléfono o videoconferencias y concluimos en la primera reunión. Lo que a continuación planteo procede en parte de esta checklist y el orden no sigue ningún criterio:

  1. Existe un Version Naming claro, estable y todas las personas que interviene saben qué significa
  2. Cada persona define su entorno de desarrollo según sus preferencias. No hay restricciones en el S.O., IDE, etc
  3. Existen los medios para poder trabajar desde cualquier lugar
  4. No hay puertas con “Departamento de sistemas” o “Departamento de desarrollo”
  5. Plantear un día de trabajo sin el sistema de control de versiones sería como intentar vivir sin oxígeno
  6. Hay una máxima presente en todas las decisiones, si se puede automatizar se automatiza ¡YA!
  7. Preguntar por los 3 bugs más críticos de la última release supone consultar una URL
  8. Cualquiera puede pintar en una pizarra el ciclo de vida de una release
  9. El stack tecnológico que se emplea viene determinado porque en el equipo hay personas que verdaderamente controlan
  10. Hay artefactos de código (librerías, toolkits, etc) que se reutilizan entre distintos proyectos
  11. Se llevan a cabo las prácticas: Continuous Inspection y Continuous Delivery.

La lista es corta, pero mejor extenderla en la próxima reunión de MadQA.

4 thoughts on “Común denominador entre los que mejor software desarrollan

  1. Hola Manu,

    Gracias por compartir vuestra checklist. En mi terreno yo también estoy trabajando en formalizar lo que normalmente hago “desde la intuición” al llegar a un cliente y vuestra lista es una excelente ayuda. Por cierto, sería una excelente serie de artículos el ir explicando el por qué de cada uno de esos puntos en la checklist.

    Un abrazo,
    JMB

  2. Hola José,

    Gracias a ti por leerlo y participar con tu comentario. Ahora que estoy retomando el blog es muy probable que caigan post en esta línea. Me guardaré algo para nosotros por aquello del factor sorpresa.

    ¿Interesado en algún punto concreto?

  3. Je, je. Estoy interesado en todos, pero si tengo que quedarme con uno: No hay puertas con “Departamento de sistemas” o “Departamento de desarrollo”. Especialmente en cómo ayudáis a convencer de la importancia de esto y cómo lo suelen resolver vuestros clientes.

    Un abrazo,
    JMB

  4. Hola José,

    Ese punto se atiende indirectamente según se introducen “buenas prácticas”.

    Cuando alguien que administra entornos es capaz de desplegar un artefacto (p.e. aplicación web) con los parámetros de entorno (pool, timeout, config. caché) que él estima oportunos para las pruebas que le permitan dimensionar la infraestructura, entonces comienzan a crearse puentes entre esas dos islas.

    La mejor forma de convencer es dando datos objetivos y haciendo el ejercicio de medir. Al principio te encuentras con que creen que saben medir, pero cuando se pone en la pizarra faltan muchos datos. En esa medición -obviamente- incluyo costes. Y ahí es donde aparecen las caras de sorpresa. Nos pasa constantemente con la implantación de ecosistemas de desarrollo software.

    Un saludo

Leave a Reply

Your email address will not be published. Required fields are marked *