El test de Joel para equipos de desarrollo

(Imagen: Sidney Nolan - The trial)

Hay muchas señales que nos indican que un equipo de desarrollo no está funcionando como debería: muchos bugs, programadores trasnochados y cronogramas incumplidos son algunos de los más importantes. Joel Spolsky -en su blog - intenta formalizar esto un poco más y propone un examen de 12 preguntas para saber que tan bien -o mal- se desempeña un equipo de desarrollo. Aquí se los presento (y pór favor, no se depriman si reprueban xD):

1. ¿Utilizan software de control de versiones?

Siempre las primeras preguntas son las más fáciles xD. Afortunadamente, no me ha tocado trabajar en un proyecto donde no se utilicen estas herramientas. La más primitiva -pero eficiente- que he utilizado es Microsoft Source Safe en una de sus versiones primeras (y no se integraba al IDE); ya más adelante me topé con el CVS y el SVN (que trabajan de maravilla con Eclipse). Las ventajas de estas herramientas son muchas -mi favorita es que te permite detectar quien malogró tu código xD- y los costos son mínimos: los más populares son software libre, y sólo necesitarías una PC que te sirva como servidor. No hay excusa para no usarlos.

2. ¿Pueden generar un ejecutable en un sólo paso?

En el caso de aplicaciones J2EE, implica qué es lo que tienes que hacer para tener el EAR listo para el despliegue el producción. Mientras menos se tenga que hacer, mejor (dado que se reducen las posibilidades que metas la pata xD). Aquí uno podría ayudarse en scripts de Ant, aunque ahora las IDE's ya ayudan bastante (i.e clic derecho-> Exportar a EAR. C'est fini)

3. ¿Integran el código diariamente?

He visto con frecuencia la mala costumbre de esperar hasta pocos días antes del pase a producción para integrar el código construido por los programadores del proyecto. Cuando esto sucede, se obtiene una versión bastante inconsistente de la aplicación (faltan clases, algunas clases son sobreescritas, otras se repiten, y muchas atrocidades más) que lleva días estabilizar. Para evitar esta pesadilla, es mejor realizar integraciones diarias y subsanar las inconsistencias al instante: de ese modo dividimos la molestia de integrar en porciones más digeribles xD.

4. ¿Cuéntan con una base de datos de incidencias (bugs)?

Después de un pase -a pruebas de usuario o a producción- lo natural es que empiezen a llegar correos con errores a subsanar. Si se trata de un usuario insistente, puede llegar a llamarte y si es un usuario con poder puedes tener al gerente esperando a tu costado hasta que se solucione el error (me ha pasado). Es importante que las incidencias que lleguen estén centralizadas para evitar 1. Que se reporten como incidencias temas que ya han sido resueltos 2. Que ningún error quede sin ser atendido. A los usuarios les gusta llevar bastante este control mediante hojas excel, lo malo es que estos documentos son tan manoseados que se llega a tener 5 versiones simultáneas del mismo documento (esto también me ha pasado). La solución ideal es una base de datos de bugs, que según Joel debe tener esta información:

• Secuencia de pasos para replicar el error
• Comportamiento esperado (lo que debería hacer y no está haciendo)
• Comportamiento actual (lo que el software hace y no debería hacer)
• Responsable (el que crucificaremos si esto no se soluciona)
• Estado (si el bug se eliminó no)

5.¿Se corrigen los errores antes de desarrollar nuevas funcionalidades?

Otra cuestión que he visto con frecuencia. La gente de control de calidad envía un voluminoso listado de incidencias, que es derivado al trainee mientras los desarrolladores siguen produciendo más código defectuoso. Como deben de haberles dicho muchas veces en la universidad -y Joel nos lo recuerda- mientras más te demores en corregir un bug más te va a costar hacerlo (en tiempo y en dinero).

6. ¿Se está al día con el cronograma?

Esta es difícil. La estimación en software es un arte oscuro, y me siento medio chamán cuando me piden que estime cuando me demoraría desarrollar la funcionalidad XYZ. A veces me liga, y a veces no. Sé que existen metodologías formales, pero por dejadez no he profundizado mucho en ellas y me remito a mi experiencia para estimar. Según RUP, si estimara en intervalos de tiempo más pequeños (iteraciones) en vez de intentar estimar el proyecto de porrazo la calidad del cronograma aumentaría. Suena bastante lógico, pero aún no lo he intentado xD.

7. ¿Redactan especificaciones?

Entiéndase especificaciones como documentos antes de programar (i.e especificaciones de casos de uso). No conozco desarrollador al que le guste documentar, y por ahora esa tarea penosa se la delegamos a los practicantes (trainees), y sabemos que eso está mal y nos sentimos culpables por eso xD. Joel plantea dos soluciones: 1. Mandar a los desarrolladores a cursos de redacción y 2. Centralizar la redacción de especificaciones en los jefes de proyecto. Me quedo con la segunda xD.

8. ¿Los programadores tienen la tranquilidad que necesitan?

Aquí Joel hace énfasis en la necesidad de silencio y de no ser interrumpido (por eso, el a sus programadores les asigna oficinas propias :S). Yo creo que depende bastante de la cultura de la organización. Por ejemplo, donde trabajo religiosamente a las dos de la tarde ponemos la radio para escuchar un programa humorístico radial; y todos trabajamos sin problemas y nadie se ha quejado. Ahora, cuando quiero programar en serio y no quiero ser molestado me pongo las audífinos para escuchar The Vines a todo volumen. Como dije, cuestión de estilos xD.

9. ¿Utilizan las mejores herramientas del mercado?

Empezando por el hardware. No se puede desarrollar software en la computadora que utiliza la secretaria para redactar en Word (y el Messenger xD). Si es que la PC se demora 5 minutos en compilar, lo que va a pasar es que el desarrollador se va a aburrir y va a bajar a comerse un aperitivo. Lo mismo con el software: puedes desarrollar procedimientos PL/SQL con el SQL Developer de Oracle (que es gratis) pero lo harías más rápido y mejor con el PL/SQL Developer (que te cuesta muchos dólares más). La idea es que el desarrollador esté feliz, para que el desarrollador sea productivo xD.

10. ¿Cuentan con personal de control de calidad?

A pesar de lo insistentes y quiquillosos que son, reconozco que son importantes. Ellos detectan errores que nuestro usuario final no verá, y nos hacen ver que a pesar de lo maravillosos que somos... los desarrolladores también nos equivocamos (en raras ocasiones xD). Según Joel, por cada tres programadores debe haber un tester. Creo que nos quedamos cortos xD

11. ¿Se requiere que los postulantes programen durante su entrevista?

De hecho que es la única manera de saber si es que el postulante sabe tanto como dice en su Curriculum, aunque siempre que yo he sido el entrevistado me han ocurrido percances. Varias veces me han hecho programar en IDE's que desconocía (lo que hacía que me demore más) y otra me hicieron usar clases que ni siquiera compilaban. Siempre debe procurarse que el postulente se encuentre en "condiciones ideales" xD.

12. ¿Utilizan el test de usabilidad del pasillo?

Esa es nueva xD. Consiste en hacer que cualquier individuo que encuentres en el pasillo (i.e el encargado de limpieza, la chica de la cafetería, etc) utilice la aplicación que estás desarrollando. Si no tienen la más mínima idea de qué hacer, vas por mal camino.

Ahora, a calificarse. Si tienes 12 (como Microsoft) vas bien, si tienes 11 es tolerable pero si tienes 10 o menos estás en serios problemas (Joel dixit). Por cuestiones de confidencialidad, no les puedo decir como quedó mi equipo, pero me gustaría que ustedes -visitantes anónimos- me digan como le fue al suyo. Hasta otra!