tests

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 un buen equipo de 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, los procedimientos establecidos. Esta disciplina, por lo general, suele venir impuesta por el responsable del equipo, y no por los mismos miembros de este que... bueno, no siempre todos 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, directas, que nos indican en qué punto flaqueamos o qué podemos mejorar tanto para nuestro día a día como desarrolladores así como para mejorar en nuestro sector como profesionales.

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 ni hay super gurú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 en tiempo y que desarrollemos con calidad y que además se puedan demandar más características sin que lleguemos a una solución espagueti que tengamos 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 sea imposible mejorarla o mantenerla, y entonces lo único que se puede hacer es tirarla a la basura. Hay razones para que esto ocurra y que abordaré en otra entrada aunque hay buenas referencias publicadas; lo que sí quiero remarcar es que si de las siguientes setenta y ocho preguntas la mayoría se responden afirmativamente, la probabilidad de que haya que tirar un producto o parte del mismo a la basura con el tiempo se reducirán notablemente.

Ahora bien, si conocemos bien las razones por las que esto ocurre, entonces nos esforzaremos sin problemas para evitar que ocurra, 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 de nombre "El test del desarrollador de software altamente productivo". Como se verá, muchas de estas preguntas no son de carácter técnico, sino acerca del entorno, del ambiente y de la forma de trabajar en el que nos desenvolvemos pero que afectan positiva o negativamente a nuestro trabajo:

1. ¿Está el código que generamos suficientemente respaldado por pruebas?

2. ¿Tiene el equipo en el que trabajamos una suficiente cultura de creación de pruebas?

3. ¿Dedicamos conscientemente algún tiempo a refactorizar?, esto es, ¿nos planteamos frecuentemente las preguntas de si algo se puede mejorar o simplificar?

4. ¿Vamos dejando en el código comentarios tipo «to do:…» que finalmente nunca se llegan a completar?

5. ¿Buscamos en nuestro día a día cómo aplicar principios S.O.L.I.D., KISS, etc.?

6. ¿Trabaja el equipo de desarrollo con la suficiente tranquilidad en un ambiente cordial y creativo?

7. ¿Existe suficiente cordialidad entre los miembros del equipo para cooperar en el proyecto?

8. ¿Tienen los proyectos en los que trabajamos que estar finalizados «para antes de ayer»?, es decir, ¿se trabaja siempre con prisas?

9. ¿Buscamos trabajar de cerca con la gente que mejor sabe cooperar y trabajar en equipo?

10. ¿Existen individualismos en el equipo o personas para las que les resulta difícil trabajar en grupo?

11. ¿Fomentan los managers o gestores el buen clima en el equipo de trabajo y ponen todos los medios para que este avance correctamente?

12. ¿Aplicamos intencionadamente principios de diseño cuando programamos?

13. ¿Tendemos a simplificar algo que ya funciona habitualmente?

14. ¿Sentimos la necesidad de llenar de comentarios internos las piezas de código que escribimos?

15. Cuando alguien retoma nuestro trabajo, ¿tiene que estar preguntándonos continuamente por detalles que no termina de entender?

16. ¿Buscamos la maestría en aquellas tecnologías que creemos que conocemos suficientemente?

17. ¿Aplicamos conscientemente las tácticas descritas en el libro de Martin Fowler sobre refactorings?

18. ¿Evaluamos correctamente las librerías y componentes externos que se usan en nuestro proyecto y tenemos en cuenta su grado de evolución, madurez, comunidad de usuarios, etc.?

19. ¿Aislamos adecuadamente las librerías y componentes externos en nuestra aplicación para no depender de ellos excesivamente?

20. ¿Somos suficientemente conscientes de que al proyecto en el que trabajamos se le pedirán más cambios y que estos estarán en proporción a su éxito?

21. ¿Tenemos la tendencia de usar siempre lo último «porque sí» sin considerar si su uso es adecuado (y seguro) en nuestro proyecto?

22. ¿Preferimos usar tecnologías muy maduras antes que tecnologías incipientes y de rápida evolución?

23. ¿Consideramos el riesgo de usar módulos, librerías o componentes relativamente nuevos en nuestros proyectos?

24. ¿Estamos dispuestos a modificar profundamente una pieza de código en la que estuvimos trabajando mucho tiempo?

25. ¿Intentamos mantener a toda cosa un trozo de código sabiendo que se puede mejorar?

26. ¿Somos honestos con nosotros mismos cuando llegamos a la conclusión de que es mejor comenzar algo desde cero que forzar de la manera que sea la incorporación de nuevas características?

27. ¿Permitimos incluir en el equipo más gente en momentos de crisis cuando se acercan las fechas de entrega y se ve que de ningún modo se va a completar el trabajo?

28. ¿Advertimos a nuestros responsables de la falta de recursos para ejecutar con calidad y éxito el proyecto en el que trabajamos?

29. Si somos responsables de equipos, ¿tenemos claro que cuando un equipo falla es nuestra responsabilidad?

30. ¿Sufrimos demasiadas reuniones improvisadas?

31. ¿Las reuniones terminan durando mucho más del tiempo establecido y se discuten más temas de los incluidos en la agenda?

32. ¿Hacemos siempre un trabajo que previamente ha sido planificado por el gestor del proyecto?

33. ¿Se pasa por alto la metodología o las buenas prácticas en momentos de especial estrés o crisis por llegar a las fechas previstas?

34. ¿Cambia el gestor de proyecto de criterio continuamente?

35. ¿Tenemos todos los medios necesarios para hacer un buen trabajo?

36. ¿Comenzamos un nuevo proyecto o fase de desarrollo resolviendo las partes más complicadas o que más nos inquietan?

37. ¿Aplicamos continuamente refactorings al trabajo realizado o sólo cuando nos acordamos?

38. ¿Trabajamos siempre con la idea de la calidad en mente, eso es, queriendo hacer siempre el mejor trabajo?

39. ¿Dominamos suficientemente bien las tecnologías que se emplean en el proyecto?

40. ¿Nos ceñimos fielmente a la metodología que se usa desde el principio hasta al final del proyecto?

41. ¿Abandonamos las buenas prácticas metodológicas cuando sentimos presión?

42. ¿Trabajamos en equipos con talentos descompensados, esto es, unos muy buenos y otros muy «malos»?

43. ¿Se trabaja estableciendo una arquitectura general rígida al principio del proyecto cuando aún no están claros todos los requisitos?

44. ¿Es la arquitectura general del proyecto suficientemente flexible para poder modificarla durante el desarrollo del mismo o es extraordinariamente rígida?

45. ¿Está sólidamente establecida la metodología que se ha decidido seguir o se ignora a primeras de cambio?

46. ¿Se percibe claramente la rentabilidad que se extrae de seguir correctamente una metodología?

47. ¿Se relegan siempre para el final las tareas más aburridas o rutinarias?

48. ¿Nos preocupamos lo suficiente en que nuestro producto software esté bien hecho y funcione y además que lo aparente?

49. ¿Ponemos suficiente énfasis en el diseño de interfaces de usuario ágiles, intuitivas, amigables y elegantes?

50. ¿Nos ocurre a menudo que diseñamos interfaces de usuario pensando más en los propios desarrolladores que en los usuarios finales?

51. ¿Conocemos muy superficialmente multitud de tecnologías pero muy pocas en verdadera profundidad?

52. ¿Nos centramos más en conocer algo de muchas tecnologías que en resolver problemas reales con nuestro software?

53. ¿Sentimos la necesidad de usar lo último de lo último en un nuevo desarrollo «porque sí»?

54. ¿Indicamos en nuestro currículum los problemas que hemos resuelto con nuestro software o bien una retahíla de tecnologías que conocemos superficialmente?

55. ¿Tenemos el trabajo planificado con tiempo de antelación?

56. ¿Es corriente llegar a la oficina sin saber exactamente qué tenemos que hacer?

57. ¿Nos marcan las tareas que debemos realizar sobre la marcha?

58. ¿Sufrimos continuamente interrupciones durante nuestro trabajo?