7 Fallos habituales en una sprint review

Una sprint review parece sencilla. Pero como siempre, podemos caer en la dejadez, dejar de trabajar con rigor, cayendo en una serie de fallos habituales que os comento. Al final del post os dejo un vídeo que satiriza una sprint review. Pero empecemos con los 7 fallos habituales en una sprint review:

1.Expectativas de trabajo completado fuera del plan original.

Es muy típico esperar que se lleven a cabo tareas “extra”. Después de todo ¿no es eso ser ágil? Entonces, ¿porqué no incluir pequeños cambios o tareas adicionales, durante el sprint? Creo que todos ya sabemos que un sprint precisamente está pensado para acometer de la mejor manera posible, las historias de usuario planificadas. Nada menos, pero tampoco nada más.

2.Confundir estimaciones con compromisos.

Esto es también muy habitual. Una estimación no es más que eso. A veces las estimaciones son erróneas, y un sprint trata de acometer todo el trabajo planificado, pero a veces simplemente no es posible. Deja la historia de usuario sin completar para el próximo sprint, no sin antes asegurarte de ver porqué te equivocaste al estimar, no sea que en realidad haya más trabajo oculto del que creías.

3.Expectativas no realistas

Podemos tener expectativas no realistas de ausencia de errores, corrección de errores existentes, funcionalidades pretenciosas, hitos inalcanzables, etc.

4.El product owner que no actúa como tal.

El product owner puede que vea la funcionalidad por primera vez en la propia sprint review. Eso significa que no ha dado feedback durante su desarrollo, y que su labor de product owner no ha sido tal.

5.No mantener informado al equipo.

La comunicación y la información son claves. El equipo debe estar puntualmente informado de todo, pero especialmente de revisiones hechas sobre los objetivos del sprint.

6.Ver la review como una oportunidad para buscar culpables, en lugar de aprender y educar.

Esto es también muy típico en proyectos que se inician por primera vez en SCRUM u otras metodologías ágiles. Cuando algo falla, debemos investigar los motivos y buscar soluciones…no culpables.

7.Confundirlo con una retrospectiva.

Efectivamente, los conceptos de sprint review y sprint retrospective son bastante diferentes. Mejor dejaremos el detalle de su comparativa en un post dedicado a ellos y a sus diferencias.

Estimación basada en tallas de ropa

Hoy voy a hablar de una forma de estimar el tamaño del software, que en realidad no es más que una variante de un viejo conocido: el uso de las cartas en el planning poker. Estas cartas, suelen estar numeradas utilizando la conocida serie de Fibonacci:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100…

Sin embargo, hay más. Y aunque quizás no se usen tanto, la estimación basada en tallas de ropa (o “t-shirt estimation”), también existe. En concreto, es popular por ejemplo entre grupos de trabajo de Microsoft, entre otros.

Ventajas

Por supuesto, esta forma de estimación presenta varias ventajas:

  • Más fácil de imaginar incrementos de forma cualitativa.
  • Más fácil de comunicar las estimaciones al product owner. Los usuarios finales pueden más fácilmente asimilar que las estimaciones y por tanto los desarrollos, son de magnitud diferente.
  • Facilita la estimación ágil en grupos menos experimentados.

Inconvenientes

Y ahora, pasemos a ver los inconvenientes:

  • Más difícil de mapear los incrementos de forma cuantitativa. El paso entre tallas pequeñas parece ser similar al paso entre tallas grandes. Sin embargo, la estimación ágil basada en la serie de Fibonacci se parece más a la realidad, ya que las diferencias entre estimaciones pequeñas son mucho menores que el salto entre las estimaciones más grandes. Es decir, la estimación en tallas de ropa sugiere erróneamente que los escalones son iguales, cuando no es así.
  • Conforme los grupos de trabajo son más experimentados, es mejor pasar a otros tipos de estimación ágil.
  • Es complejo intercambiar estimaciones con otros grupos ágiles, ya que su uso no está tan extendido.

Mi consejo es usar las tallas de ropa como una referencia de trabajo, y mapear, como indican varios autores, cada talla con un número de la tradicional serie de cartas de póker (o Fibonacci). De esta forma, se pueden aprovechar las ventajas y evitar los inconvenientes antes mencionados. Con el tiempo, de todas formas, lo ideal es que los equipos de trabajo acaben estimando directamente con los números y acaben abandonando las tallas de ropa.

Fuentes:
http://qeworks.com/t-shirt-estimation-in-agile/
http://tech.mindcandy.com/2011/06/t-shirt-sizes-in-story-estimation/
http://www.mountaingoatsoftware.com/blog/estimating-with-tee-shirt-sizes

ITIL – Cómo aprobar el examen Foundations

Hola, hoy me apetece hablar del examen ITIL Foundations, y algunas recomendaciones para facilitar el superarlo y dar una guía y seguridad a los que se presentan a este reto.
Podéis leer en este mismo blog un post con una introducción sobre ITIL.

En primer lugar debo decir que escribo esto desde el punto de vista de mi experiencia personal. A mí me sirvió (superé con un 95% el examen oficial ITIL Foundations). Empecemos:

Y todo esto…¿para qué?

Al superar el examen ITIL Foundations, recibes una certificación que te acredita profesionalmente a tí, como conocedor del marco de servicios y buenas prácticas ITIL.
Profesionalmente, la acreditación ITIL Foundations está entre las más solicitadas. Este enlace, lo presenta en el 9º puesto, al mismo nivel que otras certificaciones mucho más costosas de conseguir desde mi punto de vista.

El examen.

El examen ITIL Foundations, para la edición 2011, está basado en 40 preguntas para las cuales se exige un 65% de acierto (es decir, acertar al menos 26 de esas 40 preguntas).
Para ello, los exámenes se realizan desde centros autorizados, y cualquier búsqueda en Google os dará centros para hacer cursos, normalmente acompañados de un examen final.
Para el examen, nos darán 60 minutos. Yo no fui el primero en entregar mis resultados, y me costó apenas 20 minutos responder a las preguntas. Mi consejo es que hay tiempo más que suficiente. Marcarse un ritmo, no más allá de un minuto por pregunta, de forma que nos quede margen para revisar las respuestas, preguntas que nos hayan quedado sin contestar, etc.
El examen se hace mediante ordenador, que conectado al centro evaluador, te permite hacer las preguntas, revisarlas, controla qué preguntas han sido contestadas, cuáles no…etc.
El idioma del examen: se puede elegir hacerlo en inglés o en castellano. Mi experiencia es que no notarás mucha diferencia. Cuidado con las traducciones de los exámenes que encontrarás por internet, porque muchos conceptos estamos acostumbrados a escucharlos en inglés, y la traducción se nos puede hacer extraña. Los de habla hispana encontrarán muy diferentes traducciones en función de la nacionalidad, así que cuidado. En mi caso, he llegado a dudar en preguntas solamente por leerlas en español (la traducción no era del todo afortunada).

Las preguntas.

Las preguntas son de tipo test, y son realmente sencillas si has estudiado. No tiene mucho misterio. Yo recomiendo hacer el curso de preparación que suele anteceder a los exámenes en los centros oficiales. Yo en mi grupo de estudio, detecté que simplemente atendiendo al curso y estudiando un poco en los 4 días de curso, era suficiente para superar todos los test de prueba que hicimos el último día.

El material de preparación.

Recomiendo hacerse con:

  • Un buen libro o material de estudio, normalmente facilitado en el curso oficial. Sólo si no tienes el anterior, me plantearía comprarme un libro. Para el que ya tenga el material de presentación del curso, le será de rara utilidad comprar un libro aparte.
  • Un buen paquete de test de exámenes. Intenta que no estén marcadas las respuestas. Normalmente los harás N veces antes de presentarte al examen final.

Dónde prepararse.

Buscando en google, encontrarás centros formativos. Yo estuve bastante contento de la formación que recibí durante 4 días, a unas 5 horas al día.
Si prefieres la autoformación, hay muy buenos libros en el mercado.
También, encontrarás en internet gran cantidad de exámenes en inglés y español. Luego os hablaré de ellos.
Yo lo digo por activa y por pasiva en este blog: yo no vendo, así que no esperéis que os venda un libro o una empresa certificadora. Yo tampoco me dedico a esto, no estoy en este blog para vender. Usad internet, basta poner ITIL en el buscador, Empresa Certificadora, etc.

Cómo prepararse.

Mi plan de trabajo fue el siguiente:

  1. Asistir a un curso oficial
  2. Hacer test de certificación
  3. Recopilar las preguntas en que había fallado, y estudiarlas/razonarlas revisando de nuevo todo el material, de forma que me quedara claro la respuesta buena, y no la que yo erróneamente había escogido.
  4. Repaso de teoría. Usar un resumen/esquema.
  5. Volver al punto 3 hasta que la puntuación obtenida en los test mejorara sustancialmente hasta el 80% al menos.
  6. El día antes del examen, hice un buen repaso de todas las preguntas en las que en algún momento había fallado (y que luego había razonado/estudiado la respuesta).

Que no se le ocurra a nadie ponerse a hacer tests sin haber estudiado a conciencia, o haber recibido un curso intensivo y completo. Ese es uno de los peores errores, porque aunque no hay preguntas trampa, sí lo pueden parecer al neófito.

Si el examen se hace al terminar un curso, mi consejo es estudiar todos los días al menos 2h aparte del tiempo dedicado al curso.

Si como me ocurrió a mí, pasa mucho tiempo desde el curso hasta el examen, tómate al menos una (o mejor dos) semana(s) dedicando entre 1 y 2 horas al día. Habrá quien le baste con menos…tú mismo.

Consejos.

Aquí van algunos consejos, obtenidos tanto de mi experiencia personal, como de otras personas que hicieron el examen y tuvieron a bien compartir esto conmigo:

  • No es nada complicado. Es más importante calidad que cantidad al estudiar.
  • Concentración. Es bastante teórico, por lo que merece la pena un ambiente silencioso y estar centrado. Los conceptos pueden parecer liosos a quien está fuera del ámbito de la prestación de Servicios IT.
  • Una o dos tilas antes del examen, vienen bien 😉
  • No te fies de los exámenes de test que verás por internet. Revisa toda las preguntas contrastando el material teórico que tengas (libros).
  • Cuidado con la versión de los exámenes. Internet tiene mucha información (demasiada), y está mal clasificada, y mal presentada.
  • Piensa que todo el material anterior a 2011 (y gran parte del de 2011), es anterior sí o sí a la última versión de ITIL. Además, por mi experiencia, mucho material presentado como de 2012 también está obsoleto. Los tests de versiones anteriores de ITIL no es que contradigan el ITIL 2011, sino que simplemente no están en el temario o pueden enfocarse de forma ligeramente distinta. Te harán perder tiempo.
  • Mientras se estudia el temario, e incluso durante el mismo curso, hazte un esquema. Algo que parece imposible al principio (como identificar a qué área de procesos ITIL pertenece cada proceso individual), acaba siendo natural tras N repasos del esquema.
  • No te agobies con descargar libros y libros de internet. Utiliza un solo material, preferiblemente en el mismo idioma en que te vayas a examinar (inglés o español). Es decir, que si ya te dieron material en el curso, céntrate en él y no pierdas tiempo en N libros que sólo te van a distraer.

Mucha suerte, si te animas a certificarte.

ITIL – Introducción

Tenía bastante abandonado el blog. Es lo que tiene estar en plena certificación CMMI nivel 3 y alguna cosa más. Es lo que tiene, que no te aburres.

Como tenía pocas cosas en marcha, me he certificado recientemente en ITIL Foundations, y ya tengo el certificado en mi poder.

Aprovecho un momento de no-descanso, y haré una breve introducción a ITIL. Me sorprende ver cómo hay mucha confusión en estos marcos de trabajo. Empecemos.

¿Qué es ITIL?

Es un conjunto de buenas prácticas para la gestión de los servicios que prestan las tecnologías de la información. Es decir, ITIL no es una metodología, como mucha gente tiende a llamar.

ITIL son las siglas de “Information Technology Infrastructure Library”, una biblioteca de infraestructura para las tecnologías de la información.
Está pensada para ayudar a definir cómo trabajar en una empresa que preste servicios TI: software, hardware, consultoría…servicios IT en general.

ITIL se creó en los años 80, y a día de hoy es uno de los estándares más conocidos para la gestión de servicios IT.

La última versión de ITIL, no es la v3, aunque es la versión más popular. La última versión es la Edición 2011, que es una revisión de la v3 (no debía parecer interesante llamarla v3.1, ni v4).

¿Qué contiene ITIL?

ITIL no es una novela, y sin embargo consiste en 5 libros. Estos 5 libros definen la infraestructura de ITIL. Los títulos de esos 5 libros:

  • Estrategia del Servicio.
  • Diseño del Servicio.
  • Transición del servicio.
  • Operación del Servicio.
  • Mejora continua del Servicio.

¿Qué es la certificación ITIL?

Hay una serie de certificaciones relacionadas con ITIL. Son certificaciones a nivel personal. Es decir, se supera un examen y se obtiene una acreditación. Pero no existe una acreditación ITIL para empresas. Para ello, existe un equivalente en la ISO 20000, que acredita empresas en un marco similar a ITIL (y que por contra, no tiene una acreditación para personas que pueda obtenerse con un examen).

Hay varios niveles. El nivel “Foundations” es el nivel más básico, y puede obtenerse mediante un examen de 40 preguntas tipo test en alguno de los centros oficiales acreditados. Existen niveles intermedios, y un nivel avanzado. Los distintos niveles, por encima del “Foundations”, se logran aprobando exámenes que proporcionan créditos o puntos, distintos según el tipo de examen. Con suficientes puntos, se obtienen las distintas acreditaciones de forma incremental. En realidad, lograr las acreditaciones superiores es algo más complicado, pero no entraremos hoy en ello.

La certificación ITIL Foundations no es cara (de hecho, me parece uno de los certificados más baratos, para el nivel de demanda que tiene).

Para aprobar la certificación ITIL Foundations, es suficiente con estudiar por tu cuenta, aunque recomiendo los cursos de 3 o 4 días que suelen ir acompañados del derecho a realizar un examen. Si quieres trucos, recomendaciones, o un mayor detalle de ITIL, o cómo aplicarlo en tu empresa…lo dejaremos para un próximo post.

Otras entradas relacionadas en este Blog:

ITIL – Cómo aprobar el examen Foundations

–Update 19/02/2014: corregida una errata. Aclarar que ITIL NO certifica empresas sino personas. Para empresas está la ISO 20000. Disculpad el gazapo.

Los derechos de los programadores

Para que un proyecto tenga éxito, el primer paso a tomar es hacer que cada una de las partes tenga respeto por los derechos de los demás. En la última entrada vimos los derechos del cliente. Hoy vamos a ver los derechos de los programadores.

#1 Conocer los objetivos del proyecto y tener unas prioridades claras.

Efectivamente, nuestra vida sería mucho más fácil si nos proporcionaran al principio (o lo antes posible), los objetivos priorizados.

#2 Conocer en detalle el producto a construir y aclarar y definir sus detalles si es necesario.

Por supuesto, los detalles del producto han de conocerse de forma suficientemente anticipada (podéis ver cómo lograr esto en mi serie de entradas sobre cómo hacer una toma de requisitos).

#3 Tener acceso al cliente, gerente, comercial o cualquier otra persona que tenga responsabilidades sobre la funcionalidad del producto.

Cuántas veces, las personas que toman decisiones funcionales están totalmente alejadas del equipo de desarrollo. Suele ocurrir que dicho equipo se ve bombardeado por cambios, funcionalidades, y se siente completamente alejado de la toma de decisiones. No es tanto tomar decisiones de forma activa (aunque tampoco estaría mal), sino simplemente poder participar en las decisiones y tener acceso directo a las personas que han definido las funcionalidades o son sus responsables, para aclarar dudas, conceptos y poder corregir definiciones incoherentes.

#4 Poder trabajar en cada fase del ciclo de vida de una forma técnicamente responsable (y especialmente no ser forzado a picar código desde el minuto cero).

¿Cuántas veces nos habremos visto obligados a escribir código desde el primer minuto? Esto, que es tan frecuente, es a la vez tan absurdo como una de mis frases favoritas:
– “Tú ves corriendo, que cuando sepamos hacia adónde hay que ir, te lo diremos”

Esta frase, tan frustrante como poco ilusionadora, es el pan de cada día en el desarrollo de software durante los últimos…¿50 años?

#5 Aprobar estimaciones de esfuerzo y entrega para cualquier trabajo que se le asigne. Esto incluye el derecho de tener el tiempo necesario para hacer estas estimaciones, y poder revisar dichas estimaciones si se producen cambios durante el proyecto.

Pues sí, es necesario cada vez más involucrar a los programadores en estimar o en aprobar y asimilar las estimaciones realizadas. Es estúpido hacer que los analistas o responsables estimen, y se aparte de esta tarea a los programadores, porque llega el día en que un programador es ascendido a analista…y tenemos un nuevo problema: no es capaz de estimar porque nunca se le ha dejado, y encima hemos quitado de programar a una persona que estaba muy preparada (¿porque le hemos ascendido al ser  bueno, verdad?)

Aunque se está volviendo al paradigma de tener equipos de desarrolladores de alto nivel, que toman también decisiones funcionales, ha habido una época en que se prefería una segmentación diferenciada entre programadores, analistas técnicos y analistas funcionales (u orgánicos). Por encima de ellos, los arquitectos tomaban decisiones de alto nivel, estructural (y cuántos arquitectos de boquilla aprovechaban para limitarse a decisiones obvias que aportaban poco a los problemas existentes, y eran totalmente inoperativos cuando tenían que enfrentarse a problemas reales…sobre esto creo que también tenemos para escribir otro día).

#6 Reportar el estado de mi trabajo de forma detallada a mis responsables y clientes.

Ya que somos responsables de nuestro trabajo, permitidnos informar y transmitir clara y detalladamente la situación. No hace falta hablar directamente con el cliente, pero al menos sí elaborar los correos o informes de estado, que además, nos prepararán para el siguiente nivel de nuestra carrera profesional.

#7 Trabajar en un entorno productivo, libre de interrupciones frecuentes y distracciones, especialmente durante las fases más críticas del proyecto.

Mmm esto, que también sería digno de otra entrada, es una causa frecuente del fracaso de los proyectos. ¿Acaso no recordamos la típica situación cuando vamos en el coche con nuestros hijos?:
– “Papá, hemos llegado ya?”
– “No, cariño, pero falta poco”
– (a los 2 minutos) “Papá, hemos llegado ya?”
– “Que no, cariño, que falta poco”
– (a los 2 minutos o menos) “Ya? Papá, ya?”
– “¡Que no, que te he dicho que no!”
– (a los 30 segundos…) “¿Papá, hemos llegado ya, ahora si verdad?”
– (Aquí el padre, ya está a punto de estampar el coche, asesinar a su hijo, vamos, le da todo igual)

Pues esta misma situación, pero cambiando al padre por el programador, y al hijo por el responsable/gerente/cliente, es el pan de cada día. Las empresas tienen comunicados internos, los proyectos tienen reuniones, informes, comités…Pero hay que definir períodos y horarios claros para ser productivos y sin interrupciones. Hagamos las reuniones, y comunicaciones internas (correos, preguntas, etc) en unos horarios establecidos (y mejor al final o al principio del día).

¿Y tú, estás de acuerdo con estos 7 derechos fundamentales de los programadores?

Los derechos del cliente

Hoy vamos con algo ligero y no por ello menos importante: los derechos del cliente. Y no penséis que vamos a revisar leyes y decretos, ni mucho menos.

Hablamos de fomentar una relación profesional de respeto y confianza, basada en unas normas conocidas y simples que permitan a nuestros clientes seguir trabajando recursivamente con nosotros en proyecto tras proyecto. Empecemos.

#1: Fijar los objetivos del proyecto, y que éstos se sigan.

Desde luego, el cliente tiene derecho a establecer qué hay que hacer (requisitos), pero no sólo eso. También tiene el derecho de establecer los objetivos generales del proyecto, la visión del mismo que hay que cumplir y que debe terminar no sólo con un software que funciona, sino además, con unos objetivos corporativos satisfechos.

#2: Conocer cuánto tiempo va a costar hacer el software, y cuánto dinero me va a costar.

Aquí ya lo siento por los talibanes del agilismo. Pero es uno de los puntos que hay que respetar del cliente: tiene este derecho inalienable.
Por supuesto, si el cliente nos permite hacer el desarrollo mediante sprints, usando métodos ágiles, y  está dispuesto a no saber cuándo estará terminado ni el precio final…estupendo. La gente se entiende hablando.
También hay que decir, que ser ágiles o usar metodologías ágiles, no tiene que estar forzosamente relacionado con una fecha de entrega fija y precio fijo.

#3: Decidir qué funcionalidades se incluyen, y cuáles se quedan fuera del software.

Aquí las técnicas ágiles pueden ayudar: entregas frecuentes, identificación de funcionalidades prioritarias…etc. Lo que hay que tener claro, es que la última palabra, la tiene el cliente. Es nuestro problema si nosotros hubiéramos preferido dejar esa otra funcionalidad fuera de esta versión…

#4: Poder hacer razonables cambios en el software durante su construcción, y conocer sus costes antes de llevarlos a cabo.

De nuevo, las metodologías ágiles nos pueden permitir asumir los cambios de forma práctica. Pero un buen procedimiento de control de cambios no está de más. No sólo eso, sino que al cliente hay que aclararle cuánto le va a costar de más (o de menos, no seamos ladrones, que también existe esa posibilidad) el añadir o quitar cosas, el hacer cambios durante la construcción. Por supuesto, también hay que aclararle al cliente el impacto en la fecha de entrega (que puede adelantarse o retrasarse).

#5: Conocer el estado del desarrollo de forma clara y concisa.

El cliente tiene derecho a estar informado claramente del estado: funcionalidades en cartera (backlog en terminología ágil), en desarrollo, desarrolladas, etc.

#6: Ser avisado regularmente de los riesgos que afecten al coste, la calidad o la fecha de entrega, y ser informado de qué opciones hay para evitar o resolver los problemas anticipadamente.

Esta es una de las partes más flojas que he observado durante mis muchos años en el mundo del desarrollo de software. Se suele hacer una gestión pésima de riesgos y problemas. En muchas ocasiones limitada a mostrar obstáculos obvios e inmediatos, y cuando hay problemas o riesgos inminentes, las opciones y planes de contingencia son desproporcionadamente pobres y carentes de credibilidad.

#7: Tener acceso a los entregables durante todo el proyecto.

Para terminar, el cliente debe tener acceso a los entregables. Y sí, me refiero a la documentación, a esos documentos que tanto nos cuesta realizar y que para el cliente son la prueba de que sabemos trabajar, y de que el estado de nuestro trabajo da credibilidad de que somos capaces de terminar.
Además, esa documentación deberá ser altamente práctica y muy ágil, para facilitar el cambio y servir a otros grupos de trabajo: proveedores que se integran con nosotros y que han de ver en esos documentos una información mínima pero suficiente, personal de mantenimiento, de sistemas (que deberán tener claro cómo instalar, desinstalar, etc.).

¿Y tú, estás de acuerdo con estos puntos? ¿Añadirías alguno o quitarías alguno? Gracias por vuestros comentarios.

¡Ah! y en el próximo artículo, veremos los derechos del equipo de desarrollo (aquí hay pan para todos). Un cordial saludo.

Fuente: Adaptación libre de: Software Project Survival Guide (Steve McConnell, Microsoft Press)

La doctrina del comentario

Hoy voy a hablar del comentar o no comentar el código, que parece que se está convirtiendo en una doctrina.

¿Qué es lo que ocurre? Vengo observando un tiempo la tradicional defensa del comentario como algo necesario, pero que hay que controlar en tamaño (nº de comentarios respecto al código), forma (estándares), etc.

Por otro lado, está la defensa a ultranza de la total ausencia de comentarios. Ojo, porque aquí sí que se suelen excluir los comentarios JavaDoc o NDoc que suele haber al principio de las clases y que se utilizan principalmente para documentar el código. Esto, menos mal, parece que nadie lo pone en duda (o al menos, no he identificado un grupo que esté por la labor de eliminarlo).

A continuación, veremos algunos argumentos o doctrinas que la gente utiliza en sus blogs en internet, y que me parecen interesantes. No los copio aquí para ensalzar ni tampoco ridiculizar a sus autores, sino sólo para intentar entender este tipo de argumentos y poder entender de qué hablamos. El objetivo no es tanto quitar la razón a los que están en contra de los comentarios, sino más bien entender el porqué de su postura, y tratar de ir un poco más allá. Yo de momento, sí me declaro abiertamente defensor de comentar el código, aunque luego hablaremos de con qué matices (mmm veo que de aquí tengo material para otro artículo de enfermedades del software: la “comentaritis”). Siempre creo que “menos es más”.

Frases en contra o a favor de los comentarios que podemos encontrar por la web:

  • Usar comentarios va en contra de mis principios.
  • los comentarios son siempre “el patito feo” del código fuente, cuando en realidad son tan importantes como el resto
  • comentar antes de programar, es lo que todo programador debe hacer. No puedes lanzarte a programar sin saber lo que quieres lograr.
  • al desarrollador por lo general no nos gusta “perder el tiempo” comentando y mucho menos documentando
  • si lo he hecho yo, ya sabré porqué lo he hecho
  • los comentarios en el código son algo completamente inútil que no hacen más que entorpecer y causar problemas
  • Cuando el código es modificado, tenemos que modificar también los comentarios, pues corremos el riesgo a explicar algo que no es lo que estamos haciendo. Ya bastante trabajo resulta mantener un código para también tener que mantener un paquete de oraciones.
  • Provocan problemas culturales, ya que muchas veces los comentarios están en un idioma diferente al que es capaz de leer el desarrollador actual, o en la mejor intención de hacerse entender, el “escritor” dejó una lista de oraciones sin concordancia, sentido, y con cientos de faltas de ortografía y errores gramaticales.
  • El que un comentario parezca necesario es signo de que el código no es lo suficientemente claro. Un buen código debe siempre explicarse por sí mismo sin necesidad de un “bastón” (o comentario).
  • Reducen la claridad en el código. ¿Alguna vez han visto un método con 50 líneas de las cuales menos de 10 son de código y lo otro es todo un tratado científico? Yo sí, y resulta un verdadero dolor de espalda descubrir las líneas reales ejecutables entre tantas palabras
  • Esta técnica de crear métodos para aislar secciones de código y dejar bien clara su función es extremadamente útil para aumentar la claridad. En vez de tener un módulo con 500 líneas ejecutables, podemos dividirlo en varios métodos cuya responsabilidad esté bien delimitada. El resultado final será mucho más claro y flexible.
  • los comentarios son la prostitución de las incapacidades de un programador.

¿Qué radicales son algunos de los comentarios, verdad? Y no es para menos. Por desgracia, es frecuente encontrarse programadores poco experimentados en los equipos que acaban sufriendo de “comentitis”: lo llenan todo de comentarios por su inseguridad y falta de método. Aquí os recomendaría los que a mi modo de ver son dos libros indispensables tanto para programadores que se creen experimentados, como para los que empiezan. (Creedme, nunca seremos suficientemente experimentados, y lo que es peor, el paso del tiempo, la destreza se pierde). Los libros son:

  • Code Complete, de Steve McConnell
  • Clean Code, de Robert C. Martin

Dejaremos para otro día unas recomendaciones sobre qué y cómo comentar, y porqué. Ahora vamos a dar un breve repaso a algunos consejos para evitar que nos afecte:

  • No podemos controlar todo lo que hacen los demás. No podemos exigir que respeten nuestra forma de trabajar si no respetamos la de los demás. No todo el mundo tenemos el mismo nivel técnico.
  • Si algo te molesta, dilo. Pero ten respeto por las personas y su trabajo. Además, te encontrarás con que quizás a ese programador le obligaron a hacerlo así, o quizás era su primer trabajo (todos hemos tenido un primer trabajo, y un segundo trabajo).
  • Controla tu ego. No puedes imponer a todo el mundo trabajar como te gusta. Porque se trata de eso: tu gusto.
  • No confundir lo anterior con normas de codificación. Si el proyecto o la empresa (o el cliente), tiene unas normas de codificación, hay que seguirlas. Peor que ver código mal hecho, es ver código hecho de dos formas distintas en función de miembros del equipo disciplinados, y los “libres y ajenos a toda norma”.
  • las normas de codificación, y sobre todo, las relativas a los comentarios, han de ser muy simples. Un comentario no es tan importante como para perder tiempo con 200 páginas de normas y un curso intensivo de 3 días.
  • El comentario no nos va a dar de comer: el código sí. Dicho esto, no significa que debamos ignorar y eliminar los comentarios. Si cada palabra clave o sintaxis del lenguaje que no nos gusta o “nos parece” poco útil se eliminara, os aseguro que entre unos y otros, sólo dejaríamos en el código líneas en blanco.
  • Todos dejamos código basura. (unos más que otros,es cierto). Pues también hay comentarios basura. Y contra ambos hay que luchar.
  • En tu empresa, en tu proyecto, adopta una forma de comentar simple y efectiva, minimalista. Usa sólo lo imprescindible y haz que todos lo adopten. Si trabajas solo, ten en cuenta que tu código o lo pueden usar en otros proyectos, o ya se está integrando en otros proyectos. Recuerda: hazte respetar respetando tú antes la forma de trabajo de los demás.

¿Estáis de acuerdo? ¿O sois defensores de los comentarios? ¿O abogáis por su más absoluta erradicación?
Por cierto, habrá que acuñar el término “Genocida de Comentarios”, si esto llegara a ocurrir 😉
Y bueno, creo que ya vale para una entrada un tanto improvisada.
Un saludo a todos.