Hay algunas preguntas que me hago recurrentemente cuando llevo un tiempo desarrollando o dirigiendo un nuevo proyecto. Lo he hecho recientemente, ahora que estamos a punto de lanzar Picly (web en pruebas aquí: http://stage.picly.io).
Uno de los elementos que caracterizan a un buen equipo frente a otro que no lo es tanto es la disciplina a la hora de mantener en el día a día las buenas prácticas y los procedimientos establecidos. Esta disciplina, por lo general, suele venir impuesta por el responsable del equipo, y no por sus propios miembros, que… bueno, no siempre están lo suficientemente motivados o interesados en generar un producto o proyecto mantenible y evolucionable.
En uno de los capítulos de El Libro Negro del Programador resumí, en forma de setenta y ocho preguntas, los indicadores más relevantes que tenemos que tener en cuenta para generar software de calidad. Son preguntas sencillas y directas que nos indican en qué punto flaqueamos o qué podemos mejorar, tanto en nuestro día a día como desarrolladores como en nuestro sector profesional.
Creo que en esas preguntas se resume lo más importante que debe tener en cuenta un equipo de desarrollo y su responsable, partiendo de la base de que no hay supergurús (aunque sí egos inflados, me temo) ni equipos perfectos, ni falta que hace. Lo único que importa es que el negocio para el que se trabaja pueda usar la funcionalidad que necesita, entregada a tiempo; que desarrollemos con calidad; y que además se puedan pedir más características sin acabar con una solución espagueti que haya que tirar a la basura.
Hay muchas razones por las que el software se pudre (software rots). El concepto suena fatal, pero lo que viene a decir es que es casi natural que una solución evolucione de una forma tan caótica que resulte imposible mejorarla o mantenerla; entonces, lo único que se puede hacer es tirarla a la basura. Hay razones para que esto ocurra que abordaré en otra entrada, aunque existen buenas referencias publicadas. Lo que sí quiero remarcar es que, si la mayoría de las siguientes setenta y ocho preguntas se responden afirmativamente, la probabilidad de tener que tirar un producto —o parte de él— a la basura con el tiempo se reducirá notablemente.
Ahora bien, si conocemos bien las razones por las que esto ocurre, entonces nos esforzaremos sin problemas para evitarlo, digo yo; aunque algunas de estas razones son bastante sutiles y tienen un efecto acumulativo difícil de apreciar a primera vista.
A continuación copio y pego este test, que viene incluido en el capítulo titulado «El test del desarrollador de software altamente productivo». Como se verá, muchas de estas preguntas no son de carácter técnico, sino que tratan del entorno, el ambiente y la forma de trabajar en los que nos desenvolvemos, pero afectan positiva o negativamente a nuestro trabajo:
- ¿Está el código que generamos suficientemente respaldado por pruebas?
- ¿Tiene el equipo en el que trabajamos una cultura suficientemente sólida de creación de pruebas?
- ¿Dedicamos conscientemente algún tiempo a refactorizar? Es decir, ¿nos planteamos con frecuencia si algo se puede mejorar o simplificar?
- ¿Vamos dejando en el código comentarios del tipo «TODO…» que finalmente nunca llegamos a completar?
- ¿Buscamos en nuestro día a día cómo aplicar principios S.O.L.I.D., KISS, etc.?
- ¿Trabaja el equipo de desarrollo con la suficiente tranquilidad, en un ambiente cordial y creativo?
- ¿Existe suficiente cordialidad entre los miembros del equipo para cooperar en el proyecto?
- ¿Tienen que estar terminados nuestros proyectos «para antes de ayer»? Es decir, ¿trabajamos siempre con prisas?
- ¿Buscamos trabajar de cerca con la gente que mejor sabe cooperar y trabajar en equipo?
- ¿Hay individualismos en el equipo, o personas a las que les resulta difícil trabajar en grupo?
- ¿Fomentan los managers o gestores un buen clima en el equipo de trabajo y ponen todos los medios para que este avance correctamente?
- ¿Aplicamos intencionadamente principios de diseño cuando programamos?
- ¿Tendemos habitualmente a simplificar algo que ya funciona?
- ¿Sentimos la necesidad de llenar de comentarios internos las piezas de código que escribimos?
- Cuando alguien retoma nuestro trabajo, ¿tiene que preguntarnos continuamente por detalles que no termina de entender?
- ¿Buscamos la maestría en aquellas tecnologías que creemos conocer suficientemente?
- ¿Aplicamos conscientemente las tácticas descritas en el libro de Martin Fowler sobre refactorización?
- ¿Evaluamos correctamente las librerías y los componentes externos que se usan en nuestro proyecto y tenemos en cuenta su grado de evolución, madurez, comunidad de usuarios, etc.?
- ¿Aislamos adecuadamente las librerías y los componentes externos en nuestra aplicación para no depender demasiado de ellos?
- ¿Somos suficientemente conscientes de que al proyecto en el que trabajamos se le pedirán más cambios y de que estos serán proporcionales a su éxito?
- ¿Tendemos a usar siempre lo último «porque sí», sin considerar si su uso es adecuado (y seguro) en nuestro proyecto?
- ¿Preferimos usar tecnologías muy maduras antes que tecnologías incipientes y de rápida evolución?
- ¿Consideramos el riesgo de usar módulos, librerías o componentes relativamente nuevos en nuestros proyectos?
- ¿Estamos dispuestos a modificar profundamente una pieza de código en la que hemos trabajado mucho tiempo?
- ¿Intentamos mantener a toda costa un trozo de código sabiendo que se puede mejorar?
- ¿Somos honestos con nosotros mismos cuando llegamos a la conclusión de que es mejor empezar algo desde cero que forzar de cualquier manera la incorporación de nuevas características?
- ¿Permitimos incorporar más gente al equipo en momentos de crisis, cuando se acercan las fechas de entrega y vemos que de ningún modo se va a completar el trabajo?
- ¿Advertimos a nuestros responsables de la falta de recursos para ejecutar con calidad y éxito el proyecto en el que trabajamos?
- Si somos responsables de equipos, ¿tenemos claro que cuando un equipo falla es responsabilidad nuestra?
- ¿Sufrimos demasiadas reuniones improvisadas?
- ¿Las reuniones terminan durando mucho más de lo previsto y se discuten más temas de los incluidos en la agenda?
- ¿Hacemos siempre un trabajo que previamente ha planificado el gestor del proyecto?
- ¿Se pasan por alto la metodología o las buenas prácticas en momentos de especial estrés o crisis para llegar a las fechas previstas?
- ¿Cambia continuamente de criterio el gestor del proyecto?
- ¿Tenemos todos los medios necesarios para hacer un buen trabajo?
- ¿Comenzamos un nuevo proyecto o una fase de desarrollo resolviendo las partes más complicadas o que más nos inquietan?
- ¿Aplicamos refactorizaciones continuamente al trabajo realizado, o solo cuando nos acordamos?
- ¿Trabajamos siempre con la calidad en mente, es decir, con la intención de hacer el mejor trabajo posible?
- ¿Dominamos suficientemente bien las tecnologías que se emplean en el proyecto?
- ¿Nos ceñimos fielmente a la metodología utilizada desde el principio hasta el final del proyecto?
- ¿Abandonamos las buenas prácticas metodológicas cuando sentimos presión?
- ¿Trabajamos en equipos con talentos descompensados, es decir, con algunas personas muy buenas y otras muy «malas»?
- ¿Se establece una arquitectura general rígida al principio del proyecto, cuando aún no están claros todos los requisitos?
- ¿Es la arquitectura general del proyecto lo bastante flexible como para poder modificarla durante el desarrollo, o es extraordinariamente rígida?
- ¿Está sólidamente establecida la metodología elegida o se ignora a las primeras de cambio?
- ¿Se percibe claramente la rentabilidad que se obtiene al seguir correctamente una metodología?
- ¿Se relegan siempre para el final las tareas más aburridas o rutinarias?
- ¿Nos preocupamos lo suficiente de que nuestro producto de software esté bien hecho y funcione, y de que además lo parezca?
- ¿Ponemos suficiente énfasis en diseñar interfaces de usuario ágiles, intuitivas, amigables y elegantes?
- ¿Nos ocurre a menudo que diseñamos interfaces de usuario pensando más en los desarrolladores que en los usuarios finales?
- ¿Conocemos muy superficialmente multitud de tecnologías, pero muy pocas en profundidad?
- ¿Nos centramos más en conocer un poco de muchas tecnologías que en resolver problemas reales con nuestro software?
- ¿Sentimos la necesidad de usar lo último de lo último en un nuevo desarrollo «porque sí»?
- ¿Indicamos en nuestro currículum los problemas que hemos resuelto con nuestro software, o una retahíla de tecnologías que conocemos superficialmente?
- ¿Tenemos el trabajo planificado con antelación?
- ¿Es habitual llegar a la oficina sin saber exactamente qué tenemos que hacer?
- ¿Nos asignan las tareas que debemos realizar sobre la marcha?
- ¿Sufrimos continuamente interrupciones durante el trabajo?
- ¿Contamos con los recursos y medios necesarios para realizar correctamente nuestro trabajo?
- ¿Se hacen horas extra con frecuencia para completar las tareas?
- ¿Percibimos que nuestro gestor o manager se preocupa lo suficiente para que trabajemos concentrados en nuestras tareas la mayor parte del tiempo?
- ¿Intentamos reutilizar frameworks y librerías suficientemente maduras en el desarrollo de nuestros proyectos?
- ¿Nos preocupamos de que las partes funcionales de la aplicación estén suficientemente desacopladas entre sí?
- ¿Nos gusta reinventar la rueda en lugar de usar librerías que ya hacen lo que necesitamos, porque creemos que lo haremos mejor?
- ¿Nos esforzamos siempre por escribir código que sea fácil de depurar y corregir?
- ¿Son nuestras soluciones imposibles de depurar y corregir una vez desplegadas en producción?
- ¿Pasamos muchísimo tiempo trabajando en el mismo proyecto y usando las mismas tecnologías que hace algunos años?
- ¿Rotamos periódicamente entre proyectos?
- ¿Detectamos en el equipo o departamento a personas que mantienen en secreto cierto conocimiento e información sobre alguna solución?
- ¿Somos altamente imprescindibles en una tarea muy específica y crítica que realizamos en la compañía?
- ¿Tenemos una actitud abierta a compartir con los demás todo lo que hacemos y aquello que conocemos mejor?
- ¿Revisamos proyectos de otros desarrolladores?
- ¿Leemos con frecuencia artículos de desarrollo sobre las tecnologías que usamos habitualmente?
- ¿Participamos en proyectos heterogéneos?
- ¿Ponemos en marcha algún tipo de gestión de la configuración antes de comenzar un nuevo proyecto?
- ¿Se sigue fielmente la gestión de la configuración definida durante todo el desarrollo del proyecto?
- ¿Practicamos integración continua en grupos de trabajo de más de dos desarrolladores?
- ¿Son conscientes todos los miembros del equipo de la importancia de trabajar fielmente con los procedimientos definidos de gestión de la configuración e integración continua?