Responsabilidad sobre el código
Repasando el último podcast de JavaHispano me viene a la mente el concepto de la excelencia técnica en nuestra profesión.
En dicho podcast se habla de metodologías ágiles de desarrollo que, en contraposición con las tradicionales o predictivas, profesan la cercana relación con el cliente y el constante cambio. Este último requiere sin duda, además de la eliminación de la burocracia de los funcionales y el papeleo innecesario, de la excelencia en nuestro trabajo.
Una de las características que más me llaman la atención en muchos de los proyectos en los que he participado es la ausencia de la responsabilidad consciente sobre el código. Característica que a mi parecer es básica para garantizar la excelencia técnica.
Normalmente el código lo escribe una persona y lo modifica otra y otra y otra sin que ninguna de ellas se responsabilice del resultado final. Esto lleva a tener sistemas ilegibles, con diferentes metodologías para nombrar variables, diferentes metodologías para tabular el código y diferentes patrones y estructuras aplicadas mezcladas en el mismo módulo, archivo o función. Existen muchas formas de garantizar que esto no pase, pero todas ellas pasan por introducir el concepto de responsabilidad.
Entendemos como “responsable sobre el código” a la persona conocedora del código y que es capaz de garantizar su correcto funcionamiento.
Existen diferentes atributos que debemos dejar claro respecto a este tema antes de empezar un proyecto:
- El tiempo de asignación: dependiendo de la metodología de desarrollo del proyecto, la asignación de responsabilidades se hará en tiempo de análisis o en tiempo de desarrollo. El primer caso para las metodologías predictivas y el segundo para las ágiles
- Dependiendo de el tamaño de el proyecto se deberá determinar la granularidad de la responsabilidad: si será a nivel de módulo, de clase, de función,…. Esta característica no es global para todo el proyecto, sino que variará dependiendo de cada persona, modulo o clase. En un proyecto pueden coexistir módulos de tamaños tan dispares que obliguen a seguir diferentes políticas para cada uno de ellos. En los desarrollos ágiles se tomaran estas decisiones en tiempo de desarrollo.
- La fuerza de la responsabilidad: existen diferentes formas de entender el concepto de responsabilidad del código: una persona responsable puede ser quien escribe todo el código o quien lo supervisa y refactoriza para normalizarlo. El segundo caso es más ágil, pues desarrolladores no responsables pueden incorporar nuevas características a un módulo.
Siendo conscientes de la responsabilidad de cada uno de los miembros del equipo y realizando asignaciones teniendo en cuenta la experiencia de cada uno de ellos será posible mantener los niveles de calidad exigidos invirtiendo los recursos mínimos.
March 25th, 2008 at 4:47 pm
Hello,
muy buen post, es importante tener una responsabilidad sobre el código, y que la gente sea responsable de lo que hace, pero siempre en el sentido constructivo y teniendo en cuenta que somos un equipo, no hay un responsable de un bug, sino que es nuestro proyecto el que tiene un bug.
En los desarrollos ágiles, se intenta evitar este estilo de : el culpable es “Manolito”, pues es realmente destructivo. Para ello, todos los miembros del equipo trabajan conjuntamente y se “implican” conjuntamente … pasan a ser cerdos (símil del cerdo y la gallina)
Ya sé que parece difícil de conseguir que todo el grupo se responsable, pero ahí está la clave de conseguir que el proyecto lleve a buen puerto.
saludos, r
March 25th, 2008 at 5:57 pm
Hola robert,
Gracias por comentar!
Estoy totalmente de acuerdo con tu comentario.
Es trabajo del jefe de proyectos hacer comprender a todo el equipo que los errores son responsabilidad de todos, igual que de todos son los logros.
Diría más, forma parte del jefe de proyectos hacer ver a sus programadores que encontrar bugs en su código es lo mejor que puede pasar. Todos, absolutamente todos, cometemos errores y encontrarlos es el primer paso para solucionarlos.
Saludos,
Luis
March 25th, 2008 at 6:05 pm
Yo creo que a nivel general no se suelen ni colgar medallas ni dar grandes broncas.. y eso al final lo que crea es la desmotivación, tan común en el mundo de la informática.
Por otro lado se ha de ser muy competente para poder implicar a tu equipo en tu proyecto. Creo que esa es una de las cualidades más importantes que puede tener un jefe de proyecto.
March 25th, 2008 at 7:26 pm
Pues yo soy muy excéptico. Veo la responsabilidad como la prioridad, si todo tiene prioridad muy alta, ¿entonces para qué sirve la prioridad?. Con la repsonsabilidad lo mismo, si todos son responsables entonces yo no me preocupo que ya lo hará otro. En la práctica no hay no hay nadie responsable.
Y parece que la disyuntiva es todos o ninguno, no hay un término medio porque si empezamos a señalar a gente con el dedo se pierde la posesión compartida de código. Por ejemplo, si yo soy elr esponsable de un código, no lo va a cambiar nadie más que yo.
Feliz semana.
March 25th, 2008 at 8:17 pm
Hola Rincew,
La clave es saber seleccionar el tipo de responsabilidad y que todo el equipo de desarrollo conozca quien es responsable de cada cosa.
Si se elige una responsabilidad debil, el responsable actua más como un supervisor de esa parte del código, lo prueba y garantiza que funcione. No será él el responsable directo de los errores y al conocer el código los solucionará en menor tiempo y le será más fácil mantener y gararantizar el funcionamiento correcto.
Un saludo,
Luis
March 27th, 2008 at 8:04 pm
Muy interesante el post.
Hablando del tema de prioridad, por muy altas que esten todas, uno comko desarrollador debe pedirle al cliente que le asigne una prioridad, sin repetir tareas, se esa manera te asuguro que saldra una lista de prioridades.
Con respecto a las responsabilidades, estoy de acuerdo con el autor, ya que de esa manera tendriamos solo una persona responsable de realizar los cambios, eso implica que tenga un conocimieto de los efectos posibles al momento de una modificación.
Saludes.
March 27th, 2008 at 9:15 pm
Rafael, el problema es que la mayoría de veces los llamados responsables no tienen ni idea del código de sus desarrolladores. Incluso me atrevería a decir que la mayoría de veces no saben ni siquiera de lo que están hablando. Se aprenden unas siglas y las repiten como si fuera un dogma (os suena la frase “porque no usas ajax?” XD), pero si les preguntas un poco mas en profundidad.. ves que no tienen ni idea! Entonces.. como pedimos responsabilidades sobre el código a esta gente?