El uso correcto de las plantillas...está en el contenido

Hola, de nuevo colaboro en el arranque de un proyecto, desde mi área de calidad. Y de nuevo, ayudo en la adaptación de las plantillas y procesos para que el proyecto se adapte a lo que el cliente necesita, cumpliendo al mismo tiempo los más altos estándares de calidad.

Acabo de recibir una felicitación porque el conjunto de plantillas y documentación para el proyecto, ha sido percibido por el cliente como excelente. Y sí, para no mentir, son las cosas que te llevas a casa tras un día de duro trabajo que te animan. Las cosas que te animan a seguir luchando por mejorar, por buscar la excelencia, por no apoltronarse sentados en la autocomplacencia.

Pero claro, como buen culo inquieto, quiero más. Y me pongo a pensar que efectivamente, las plantillas, con sus guías, ejemplos y bien pensada estructura, cubren todas las necesidades...¿o no? Pero...¿qué pasa con el contenido?

En algún momento,  todas esas plantillas se convertirán en documentación real, en contenidos que reflejen la realidad del proyecto en un cierto momento y sus objetivos, suposiciones y carencias. Y sin embargo, aquí es donde realmente empieza el valor aportado al cliente. Es como si al cliente le hubiéramos dado un puente. Y sí, el puente está bien. Pero el cliente no quiere un puente. Quiere cruzar el río. Del mismo modo, lo que necesita el cliente no es las plantillas. De hecho, no quiere ni la documentación. Sino el seguro, la garantía que proporciona el tener un adecuado control del proyecto.

La documentación me recuerda al seguro de la vivienda o del coche. Los programadores no quieren oir hablar de la documentación. Esto ya lo comentaba en mi artículo "Nos gusta programar, pero no documentar". Tampoco nadie quiere un seguro de coche o vivienda. Pero es algo necesario, ya que no podemos circular por ahí, sin convertirnos en "bombas en potencia". Del mismo modo, un proyecto sin adecuada documentación se convierte en una bomba en potencia, ya que ante el más mínimo problema, empezamos todos a correr como pollos sin cabeza, apagando el fuego como si fuéramos bomberos.

Y es importante recordar, que podemos ser muy buenos creando código super-optimizado, clases y estructuras de información super-funcionales y cumpliendo los más modernos estándares...Pero sin una adecuada documentación, no sirve. Eso me recuerda a los ofuscadores de código. Conozco  gente que no lo necesitaba: su código era auto-ofuscado.

En fin, espero que el equipo de los proyectos sigan trabajando bien, y sobre todo, documentando adecuadamente (evitando la "documentitis", por supuesto).

Windows 10 y la gestión de pruebas beta

Hola a todos,
Supongo que muchos ya conoceréis el concepto de Alfa y Beta en el mundo del software. Pero es importante destacar, y en ello ISTQB lo diferencia claramente:

• Pruebas Beta es un software que se da a probar al cliente en su casa. Vamos, que se lo lleva a su casa, o su oficina, y lo prueba.
• Pruebas Alfa es un software por el contrario, que se prueba en un entorno controlado por el equipo fabricante, en las instalaciones del fabricante.

Y digo esto porque es muy típico confundir con el concepto de pruebas Alfa y Beta con la versión Beta y la versión Alfa (o pre-Beta) de un software.

Me acabo de acordar porque precisamente estos días, me he instalado Windows 10 en versión Beta, a través del Microsoft Insider Program.

Desde el punto de vista de la gestión de proyectos software, es muy interesante este concepto, ya que permitiría, bien llevado, a llevar el agilismo a extremos insospechados. Un cliente puede usar una aplicación (o en este caso, el sistema operativo), y a través del análisis de su uso del software, se podrían detectar funcionalidades mejorables, funcionalidades más usadas, etc. Por supuesto, en el caso de Windows 10, tenemos el caso del feedback tipo "esta aplicación no me ha funcionado", o "esta página web no se ha visto bien".

No digo que Microsoft esté haciendo Windows 10 añadiendo funcionalidades ad-hoc a nuestros gustos. Simplemente, que estamos cada vez más, ante una forma de trabajar adaptativa (ágil), permitiendo a posibles usuarios/clientes el ver prototipos tempranos, más o menos terminados.

Otro caso, también de Microsoft, es Windows 10 para móviles. Todos los usuarios de algunos modelos seleccionados, pueden instalarse una versión bastante avanzada (pero aún no terminada), para obtener feedback del uso, pulir defectos, detectar incompatibilidades, etc.

Por supuesto que todo esto ya existe, y tenemos aplicaciones web (recordemos que GMail ha sido una gran parte de su historia una versión Beta: más exactamente algo más de 5 años entre 2004 y 2009) que se ofrecen a los usuarios de manera muy temprana. Sin embargo, la aproximación que ha tomado este fabricante me parece valiente, y a la vez arriesgada, ya que una mala gestión del modelo de betas podría afectar gravemente a su imagen, si por ejemplo todos los ordenadores o todos los móviles dejasen de funcionar, o si los móviles comenzasen a hacer llamadas de forma autónoma y arbitraria.

Aquí desde el punto de vista de las pruebas y de la ingeniería del software, vemos como se presenta una disyuntiva, y hay que buscar un equilibrio entre la estabilidad del producto (por muy beta que sea), y la necesidad de hacerlo probar a un público lo mayor posible para obtener feedback. Desde luego, es necesario tener un gran control de las pruebas realizadas, y obtener métricas que nos permitan estimar (de forma aproximada, claro), el número de defectos y su gravedad en caso de liberar nuestro producto inacabado.

¿Y vosotros? ¿Os atreveríais a hacer público un software inacabado siguiendo un modelo de pruebas Beta? ¿Cómo gestionaríais los riesgos de hacer público un producto sin terminar?

La oportunidad de los becarios

La oportunidad de los becarios.

Se supone que los becarios se quedan a solas en verano: al frente del trabajo, ya que el resto de trabajadores (no becarios), han cogido todos vacaciones. Y claro, a los únicos que no les dejan coger vacaciones son a "los últimos en llegar".
Esto es un mito, y en cualquier cao no siempre es así. Los becarios exigen tiempo y esfuerzo para desarrollar sus capacidades, pero...¿realmente les estamos dando lo que necesitan para brillar?

La presión.

La presión suele ser el primer escollo. Siente que le vigilan, que le están evaluando de forma constante. El truco está en verlo como una motivación, una oportunidad.
Es una fuente de aprendizaje. La beca es así, y con ello, hemos de verlo en positivo. Salvo que estemos en una de esas empresas en las que los becarios se limitan a llevar cafés (por suerte, en mi empresa jamás he visto eso a un becario).
La presión hay que volverla en nuestro favor, que nos motive y nos dirija, no que nos bloquee y nos impida llegar a nuestros objetivos.
Otra forma de aliviar la presión es mediante  un tutor. En mi empresa existe la figura del counsellor, que viene a ser lo mismo. Y si bien es una gran idea, el problema viene dado cuando el tutor no se toma su trabajo en serio.

Cuando el tutor no dedica el necesario tiempo al becario.

El tutor no está para decir al becario lo que tiene que hacer. O al menos no de una forma paternalista. Debe guiar al becario impidiendo que cometa errores demasiado graves. Pero el aprendizaje incluye equivocarse. Cometer pequeños errores controlados. Aquí es donde el tutor entra en acción en su doble objetivo: que el becario aprenda, pero que la empresa no corra peligro.
La libertad del becario ha de ser proporcional a su responsabilidad: es decir, limitada. Pero no tan limitada que no pueda explorar su espacio y cometer esos pequeños errores controlados por su tutor.

Comportamientos a evitar

A continuación, revisamos algunos comportamientos a evitar por parte del becario:

• Individualismo. El excesivo individualismo, y el hambre de prosperar en la empresa, son explotadas por algunas empresas. Por desgracia, a medio y largo plazo los resultados suelen ser nefastos para la empresa. A veces, incluso a corto plazo.
• Impuntualidad. Aunque es complicado, es bueno combinar respeto y disciplina. Entrar a trabajar cinco minutos antes. Nunca después. Y nunca salir de trabajar antes de la hora, pero tampoco es necesario quedarse a trabajar  porque sí. Algún día revisaremos este punto en profundidad.
• Pereza. La pereza es terrible. El no empezar las tareas inmediatamente, el postergar lo importante por lo urgente.
• Problemático. Es una buena práctica el evitar problemas y confrontaciones. La energía generada en situaciones de conflicto está para ser utilizada a nuestro favor, no para embarcarse en disputas nimias que no van a resolver nada.
• Competitivo. La competitividad es buena, pero ha de ser una cualidad secundaria. No es bueno en general presentarse cada mañana pensando en "superar a éste" o "ser más que aquél". Sí es bueno marcarse metas, pero no es bueno dichas metas pasen por ser más que otros. Porque al final, el camino fácil se presenta: si no puedo ser mejor que los demás...quizás sea hora de hacer que los demás sean peor que yo (y aquí es donde la zancadilla fácil, el extender falsas afirmaciones, etc., hacen que el competitivo haga su agosto).
• Pelota. El pelota prefiere halagar en todo momento a sus superiores, o a cualquiera de quien pueda sacar provecho. Suele estar relacionado con un espíritu individualista y competitivo.
• Arrogancia. La arrogancia es uno de los peores males. A pesar de parecer menos agresiva que la competitividad o el individualismo, la arrogancia es difícil de erradicar. Está basada en una creencia profunda en las propias capacidades, y por desgracia, no suele estar alineada con la realidad. Cuántos recién titulados me he encontrado que se creían los reyes del mundo, dueños de la absoluta verdad, e incapaces de dialogar y llegar al mínimo consenso. Su título universitario les convierte en Dioses, o ellos así lo creen. Y por desgracia, yo hace muchos años que aprendí que mi título no está para esgrimirlo en absurdas disputas. El título está para dar soporte a la curiosidad, al esfuerzo, y a la capacidad de ir más allá de las apariencias. Capacidad de aprender, porque más que nos pese, no llegamos el primer día de trabajo con  todo aprendido.

Comportamientos a seguir.

• Aprender
• Jugar en equipo.
• Respeto.
• Atrevimiento.
• Planificación.
• Organización.
• Socialización: conseguir contactos y establecer relaciones.
• Disfrutar.

Sí: disfrutar. Disfruta, suéltate y siéntete cómodo. Que no parezca que estés ahí cada día por un sueldo miserable. Madruga. Llega pronto. Haz las cosas con ilusión. Contagia esa ilusión. Yo personalmente prefiero a gente ilusionada, antes que a un crack, al típico fenómeno tecnológico en cualquier tema pero que lo hace con desgana. Y la desgana se contagia. Y esa desgana se ve en la documentación, en el código...

Y tú, ¿cómo prefieres llevar tu beca?

Fuente: este artículo está inspirado en un artículo que leí hace un tiempo en el periódico dominical de La Vanguardia.

Trucos para un buen informe de seguimiento

Leía hace poco un artículo en el excelente blog de Javier Garzás, sobre lo que nunca debería faltar en un informe de seguimiento. Y me he quedado con una sensación de que me faltaba algo. En primer lugar, los informes de seguimiento no son algo estándar y cerrado válido para cualquier proyecto. Empezaremos por pensar en los objetivos del informe.

Objetivos del informe de seguimiento.

Este tipo de informes, se realizan periódicamente con el cliente en un proyecto (de software o de cualquier tipo). El informe de seguimiento software pretende:

• Identificar brevemente el proyecto. Un par de frases, un resumen del plan o del proyecto en cuestión. Esto es útil en clientes para los que trabajan múltiples proveedores. Hay que tener en cuenta que estas reuniones las sufren constantemente, y el cliente necesita que "les hagamos una introducción". No podemos llegar y empezar a soltar nuestro rollo. Recordad: adaptar el mensaje a lo que necesita el cliente, no a lo que queremos contar nosotros.
• Mostrar los objetivos del proyecto. ¿Qué se quería hacer? ¿Cuáles son los objetivos?
• Mostrar de forma resumida el estado del proyecto (precisamente respecto a esos objetivos). El estado incluye cosas como revisión de posibles desviaciones en la fecha de fin, esfuerzos dedicados, o costes. Seguimiento de hitos y entregables. Cumplimiento del contrato, y los distintos acuerdos alcanzados. El estado supone comparar la situación actual respecto al global del proyecto: el coste total, el esfuerzo total en horas estimado, y la fecha final de entrega (entre otros). Presupone una planificación y un seguimiento respecto a la misma.
• Mostrar los riesgos y su estado. Siempre hay riesgos. No gestionarlos, no dedicar tiempo de gestión, planificación y seguimiento no hace que desaparezcan.
• Mostrar los problemas y su estado. Los problemas, se refieren aquí a problemas de gestión. No a incidentes o fallos del software. Los problemas surgen en cualquier momento (un entorno no disponible, una tecnología que no funciona, un profesional que se va de la empresa...). Los problemas han podido ser detectados previamente (como riesgos), o surgir de imprevisto.
• Hitos clave y su estado. En todo proyecto suele haber fechas clave, que incluso pueden determinar el poder facturar o no todo o parte del proyecto.
• Entregables clave y su estado. Los proyectos no son solo código. Suelen llevar otros entregables (documentos, hardware,...), y que estarán recogidos en el contrato u objetivos iniciales.

Otros posibles contenidos el informe de seguimiento.

Vamos a ver otras cosas que pueden incluirse en un informe de seguimiento, pero que hay que pensarse bien si encajan en el tipo de seguimiento que pretendemos presentar:

• Avance del proyecto. No es lo mismo avance que estado. Al hablar de avance, nos referimos a lo incorporado desde la reunión de seguimiento anterior. Este tipo de reunión sería incremental, y trata de mostrar la diferencia respecto a lo anterior. De nuevo, este tipo de información suele darse en proyectos ágiles. Cuidado con esto, porque estamos mostrando la situación relativa respecto a un estado anterior, pero no respecto al proyecto total (eso sería un estado del proyecto). En proyectos ágiles, habría que dar también un estado, es decir, informar de cómo nos encontramos respecto al total del proyecto, informando de un coste estimado, fecha estimada de finalización, etc, etc.
• Estado de la calidad. Soy defensor de la calidad, y creo que hay que planificarla, establecerla muy al principio, y utilizar para ello indicadores lo más objetivos posibles. Sin embargo, en el tipo de clientes que he visto en mis bastantes años de vida profesional, no metería gráficas ni un análisis semanal de métricas (pocos clientes los entenderían). Eso sí, esos análisis los haría "de puertas para adentro", y lo convertiría en un semáforo donde se indicara si dichos indicadores están bien, o si por el contrario alguno de ellos no se está cumpliendo. Este tipo de indicadores, por ejemplo, lo trataría en un informe de seguimiento técnico, no en un comité ejecutivo. Por desgracia, los indicadores de calidad no son entendibles, y pueden dar lugar a falsos equívocos, preocupaciones innecesarias. Lo que hay que hacer es evidenciar que se trabaja con calidad dentro de un margen, y que se trata no de dar un producto perfecto, sino un producto con un buen balance entre coste y calidad. Por supuesto, siempre es posible que un sistema automatizado, u otra empresa certificadora, sea quien presente el estado de la calidad.
• Demo del software. Una demo del software, no siempre podrá realizarse con los clientes en todas las reuniones del seguimiento. Básicamente, porque una reunión de seguimiento ha de ser algo muy concreto, muy enfocado, y una revisión funcional del software puede llevarnos mucho tiempo. Por otro lado, una demo no se hace cada 1, 2, o 3 semanas. Tal vez sí en proyectos ágiles que lleven asociado un cliente deseoso de ver ese software avanzar. Pero no siempre. Una última cosa. Las demos son caras. Se dedica tiempo y recursos en preparar una demo. Y no sólo por el software: están las personas que asisten (cuyo tiempo es caro, y hay que respetar), están los datos, que han de estar listos para presentar el software (la gente no quiere ver el software, quiere ver las cosas que es capaz de hacer, y eso requiere de una preparación de datos previa).

Al final, no existe un informe perfecto. El informe debe servir al cliente y a los propósitos del proyecto. Todo lo aquí comentado suele incluir se en informes, pero hemos de recordar que no todas las reuniones de seguimiento son iguales.

Antes de presentarnos a una reunión, deberemos: establecer qué necesita el cliente, cuál es el ámbito del proyecto... De todas formas, yo recomendaría siempre al principio del proyecto establecer claramente:

• Modelo de relación: tipos de reunión, quiénes asistirán, decisiones a revisar, periodicidad...
• En cada tipo reunión, definir qué informe se revisará, contenido, roles (quién lo presenta, quién lo aprueba, etc).

¿Porqué a los usuarios no les gusta el desarrollo ágil?

Parece que los de ITWorld se han dado cuenta de algo que hace tiempo que vengo diciendo y que por otro lado, no es más que lo que muchos venimos observando: que las metodologías ágiles están en un punto muerto, están en crisis. Y no porque estén mal, sino porque el excesivo bombo y platillo que se ha hecho en los últimos tiempos, han hecho que se usen para todo. Sólo falta que sirvan para lavar la ropa.

Hace poco, leía un artículo de ITWorld con un título similar a este que amigo lector, estás leyendo. Y es que el problema es que por un lado, hay que entender que las metodologías ágiles han subido como la espuma sobre todo por un motivo fundamental: gustan a los programadores. Pero al final, quienes han de pagar las facturas son los usuarios y los usuarios no ven con buenos ojos unas metodologías que presentan para ellos varios problemas:

 

Los usuarios no entienden las metodologías ágiles

Se usan metáforas complejas, conceptos muy novedosos y alejados del mundo de los clientes. El tener que participar para la revisión del producto final en cada iteración, puede ser demasiado para un cliente ocupado que por otro lado, ya ha gastado demasiado en un producto que nunca termina de estar.
El término ágil en en sí mismo contradictorio, ya que no siempre implica rapidez. En muchos proyectos, se prefiere abandonar términos y palabras de moda como "ágil" o "scrum", para centrarse en conceptos más simples y cercanos al cliente.

Los usuarios quieren saber cuánto les va a costar el software.

Claro, desde el punto de vista de los programadores, es distinto. Los programadores quieren hacer un software perfecto, que requiera el mínimo mantenimiento, y que acierte al 100% con la funcionalidad deseada. Y si esto es a costa de entregar las cosas más tarde (obviamente, el tiempo se invierte en realizar iteraciones que nos permitan hacer software cada vez más cercano a lo que querían los usuarios), no pasa nada. Pero el tiempo es dinero. Y el precio final, hay que conocerlo. Los clientes suelen funcionar con presupuestos. No tienen el dinero en un cajón y tampoco lo tienen detenido. Cuesta mucho esfuerzo para un cliente presupuestar el dinero requerido para ciertos proyectos, por lo que ahora no sirve volver al consejo de dirección y decirles: "oye, necesitamos más dinero pero no os preocupéis, porque quedan pocas iteraciones y creemos que terminaremos pronto".

Los usuarios gustan de lo predecible.

A los usuarios les gusta saber no sólo lo que les va a costar el software. Además quieren saber cuándo va a estar disponible, y mucha más información del producto y proyecto final. Que sea difícil de predecir, no deja de ser algo que es problema de los informáticos, no de los usuarios.

Al hablar de iteraciones, los usuarios ven desorganización

En ocasiones, la sensación del usuario es que los informáticos se han rendido a los caprichos de los clientes. "Nos adaptamos a los cambios", decimos. Pero los clientes ven desorganización y falta de control. Y ojo, no nos obsesionemos con que esto no es así. Yo no digo que sea así. Lo importante es que el cliente sí que lo ve así. Y con esto tenemos un problema (unos cuantos ya en este artículo).

Los usuarios quieren ver el final

La sensación que percibe el cliente es que las metodologías ágiles llevan a proyectos sin final. Al no existir una fecha cerrada de entrega, sólo tienen claro que se les va a entregar un producto que sigue los requisitos (al menos, eso les hemos vendido durante muchas iteraciones). Pero no saben cuándo. Y necesitan ver el final. Porque muchas veces, cuando tenemos una fecha planificada y nos retrasamos, el cliente se puede poner nervioso. Pero si estamos iterando, aunque nosotros como informáticos entendemos que nos estamos "acercando progresivamente" al producto final...resulta que el cliente no lo ve así. Es posible, muy posible que lo que el cliente vea es un "retraso iterativo", es decir, se están haciendo cambios, y más cambios, pero la fecha se sigue escapando de las manos.
"¿No eran esto metodologías ágiles? ¿No se supone que tendría que haber terminado esto ya?"

Los usuarios quieren control

Las metodologías ágiles son buenas en entregar cosas, pero el usuario quiere el control, no dejárselo a los programadores. La percepción del cliente es que por mucho que se le involucre en la revisión de historias de usuario que entran en cada iteración, y en la revisión del producto final de dicha iteración...su control es escaso. Y lo que es peor, hay una falsa sensación de control que se confunde con exceso de poder. El usuario tiene el poder de moldear el producto final...aunque esto le lleve a dar bandazos funcionales que en el fondo, no son el control. Porque el cliente no entiende como control añadir y quitar funciones.

¿Estamos ante el fin de las metodologías ágiles? Pues no lo creo. Yo llevo usando y conviviendo con ellas desde 1999. El problema es que han pasado de grandes promesas a grandes decepciones. Se puso demasiado énfasis y demasiadas esperanzas en las que prometían ser las grandes balas de plata del siglo 21. Y no han resuelto nada de lo que prometieron. Por supuesto, en los proyectos y clientes que encajan, las metodologías ágiles suponen una ventaja.

¿Qué podemos hacer con los usuarios? Pues como hemos visto en este artículo, los usuarios, el cliente, pueden no entender o incluso ser poco receptivos a las metodologías ágiles. Y es nuestra obligación RESPETARLOS. Sí, no podemos pedir respeto para nuestra profesión, y luego tratar de imponer cosas al cliente, faltándole al respeto. Tenemos que solventar estos problemas con el usuario a base de:

• Disciplina
• Uso consistente y coherente de buenas prácticas
• Educación
• No agobiar al cliente con conceptos ágiles. Usar terminología adaptada al cliente. Somos nosotros los que debemos esforzarnos en hablar su lenguaje, NO AL REVES.
• Formación
• Introducción progresiva de las técnicas ágiles, aun cuando los proyectos no usen metodologías 100% ágiles.
• Flexibilidad. Si el cliente no encaja técnicas ágiles, buscar sustitutos adecuados (sin obsesionarnos con si son ágiles o no, solamente en que sean adecuados al proyecto/cliente).

Sólo así lograremos credibilidad con nuestros clientes y éxito en nuestros proyectos.

¿Todavía quieres ser programador?

Hace cosa de un mes, estaba leyendo uno de mis blogs favoritos. Jeff Atwood es todo un elemento, una figura reconocida en la red. Y sin embargo, consiguió sorprenderme (otra vez). Y no es porque no sea un tema conocido y de candente actualidad. Me gustó su enfoque. Y es que como tantas otras ocasiones, Jeff daba en el clavo.

Yo, personalmente, me ocupo de recibir y guiar en su inicio a las nuevas incorporaciones que suelen llegar a mi oficina. Es algo esporádico, y que no suele gustar a mis compañeros. Bueno, en nuestro entorno, es difícil encontrar a gente que en general les guste hablar en público. Pero sigamos. A esas nuevas incorporaciones, les trato de contar brevemente lo que pueden necesitar, sobre la empresa y nuestro sector. Pero también me encuentro muchas veces (y no sólo en mi empresa actual, sino más bien en todas), programadores que no tienen claro cuál es su futuro.

Normalmente, todos tienen claro que quieren más en su futuro laboral: más dinero, más categoría profesional...Pero no tienen claro cómo es el negocio del desarrollo de software y la programación, y por tanto, tienen dudas. El mundo del cine, prensa y televisión nos vende como un negocio lleno de oportunidades, con gran cantidad de puestos de trabajo, y porqué no...¡guay!

Pero los jóvenes que llegan a trabajar recién licenciados, empiezan una carrera como informática, o incluso otras diferentes como matemáticas o físicas. Y me da la sensación de que no tienen claro en qué se han metido. Y no me refiero a que sea malo. Simplemente, que al ser una profesión nueva y en constante evolución, creo que no hay información realista disponible sobre el sector, enfocada a los pre-universitarios. O incluso a los universitarios.

Normalmente, en este sector, los recién titulados empiezan programando. Simplemente porque hay mucha más oferta en programación en por ejemplo ... administración de sistemas o diseño de circuitos.

El problema, es que la programación no tiene porqué gustar a dichos recién titulados. Y se nota en las preguntas que hago del tipo:

• ¿Sabes qué es un ciclo de vida?
• ¿Has oido hablar de la ingeniería del software?
• ¿Cuántos tipos de pruebas conoces?
• ¿Has automatizado pruebas funcionales?
• ¿Has programado en algún lenguaje?

Y por desgracia, las respuestas son decepcionantes. Y seguid sentados los que defendéis que tan sólo deben programar informáticos, y que el intrusismo por aquí, y que el resto no saben programar, y bla bla bla. Digo seguid sentados, porque las respuestas son igualmente decepcionantes para los que vienen de carreras como informática (técnica o superior). No digo que la universidad no sirva para nada. Digo simplemente, que hay una brecha significativa entre lo que prepara la universidad, y la realidad de las empresas y el mercado.

Y aquí es donde viene la pregunta. ¿De verdad te gusta programar? ¿Quieres ser programador? Porque te tiene que gustar. Porque lo tienes que disfrutar. Y porque de esa manera es como puedes mantenerte actualizado, y sobrevivir a proyecto tras proyecto (y empresa tras empresa).

Jeff Atwood va un poco más allá en su blog, y plantea una pregunta con trampa: "¿Todavía quieres ser programador?". Y es que Jeff plantea que por desgracia, hay que tener en cuenta que esta profesión, no todo el mundo es capaz de aguantarla toda su vida. ¿Quieres seguir siendo programador a los 30...40...50...60? Alguno comentará que no hay problema, que a los 2 o 3 años te hacen analista, y en otros tantos, jefe de proyecto. Sí...claro. Y yo soy Mickey Mouse.

En esta profesión, como en muchas otras, no todo el mundo puede ascender para siempre de forma continuada. La carrera profesional está ahí, pero cada 100 nuevos recién titulados no pueden ser mañana 100 jefes de proyecto. No es posible. Así que hay que prepararse en nuestro sector para una pregunta clave, que Jeff sabe plantear en su blog con acierto: "¿Todavía quieres ser programador?". Porque a cierta edad (no hablo de 40 o 50 años, sino mucho antes), la ganancia en productividad de la experiencia, se ve contrarrestada por otros factores. Y no nos engañemos, hay gente que simplemente, no tiene esa pasión y esas ganas de investigar y estar al día: volver de trabajar tras una jornada agotadora y ponerse a leer lo último (lenguaje, herramienta, metodología, etc.), probarlo, etc, etc.

Hay muchas posibilidades en nuestro sector, pero hay que saber moverse. Hay muchas posibilidades en las que aplicar nuestro conocimiento adquirido tras años y años programando, y disfrutando (o sufriendo) en múltiples proyectos y en múltiples empresas y clientes. Tanto si en el fondo no te gusta tanto programar como pensabas (o como decías), tanto como si llevas tanto programando que empiezas a estar ya saturado, existen opciones como:

• Gestión.
• Testing.
• Calidad.
• Analista
• Analista funcional
• Escritor técnico/documentación
• Implantador de software.
• Ventas

En muchos de estos roles, encontrar gente realmente conocedora de los entresijos de hacer software, es muy difícil. Así que ¿porqué no aprovechar tu experiencia y conocimientos adquiridos en algo más? ¿No es eso mejor que quedarse estancado en tu carrera, siguiendo con una programación que realmente nunca te gustó, o dejó de hacerlo hace mucho?

Y tú...¿todavía quieres ser programador?

El tamaño importa

He leído recientemente en algún blog, sobre la forma adecuada de medir el tamaño del software, y que ésta, debe ser contraria a la que se usa en construcción de casas.

Vaya con la maldita manía de que como se supone que el software y las casas son distintos (según algunos, radicalmente opuestos), pues las formas de trabajar, medir, etc, deben serlo también. Esto ya es incluso un caldo de cultivo para los defensores del "agilismo porque sí", ya que como una casa se hace por fases, y esto se asimila a un método de desarrollo en cascada, está claro que eso es algo obsoleto y por tanto, la forma de trabajar en el software ha de ser distinta. Interesante, pero absurda conclusión.

Para medir el tamaño del software, podremos usar Puntos Función (PF), o cualquier otra medida. En la construcción de casas, esa medida no es válida, claro está.

Tambien se suele afirmar que en la construcción de software, la unidad de medida habitual sigue siendo en esfuerzo: se paga por la cantidad de esfuerzo empleado en lugar de por lo efectivamente producido (valor). Aquí sí que tienen ventaja las metodologías ágiles, ya que se centran en el valor incorporado en cada iteración.

Creo que tenemos un problema. Somos nosotros, los desarrolladores, los que pretendemos que nos paguen por esfuerzo. No es que sea la medida habitual: es lo que habitualmente pretendemos. Los clientes no quieren saber si nos costó 1000 ó 1050 horas hacer su programa de facturación, o su sistema de control de fábrica. El cliente quiere saber lo que realmente necesita para su negocio que es:

• Fecha: ¿Cuándo estará el software disponible? ¿Cuándo podrá integrarlo con otros productos? ¿Cuándo tendrá que tener lista la formación para su personal? ¿Cuándo tienen que estar disponibles los responsables de sistemas para su puesta en marcha? ¿Llegará el producto a tiempo para hacer lo que tiene comprometido por contrato en una fecha concreta?
• Coste: ¿Cuánto dinero va a costar? ¿Se puede pagar a plazos? Los clientes no tienen un baúl como en los dibujos animados lleno de dinero. El dinero en las empresas, no suele estar disponible en todo momento. Depende de la facturación, de si toca o no pagar impuestos, etc. Muchas empresas necesitan pedir un préstamo para acometer pagos, incluso los previstos.
• Calidad: ¿se cumplirán las necesidades y requisitos establecidos? ¿estarán todas las normas obligatorias recogidas? ¿Hay criterios de calidad adicionales que aporten valor (usabilidad, etc)?

Si os fijáis, estos factores son significativos. El negocio del cliente es directamente dependiente de estos factores. Un pequeño cambio en cualquiera de los tres, y podemos hacer que la empresa del cliente se arruine, y sus trabajadores acaben en la calle. Y esto sirve para todo, no solo para el software.

El coste, por otro lado, estará marcado por el mercado. Habrá productos, que si no sabemos desarrollarlos por un coste inferior al precio de mercado, tendremos un problema. Aquí está la clave: ser competitivos.

¿Entonces porqué esa manía de medir el software en esfuerzo? Pues porque es lo único que nos importa, en un entorno todavía inmaduro que parece no querer ver más allá y no involucrarse en satisfacer al cliente.

Se está huyendo de dos premisas, muy integradas culturalmente en otros sectores, pero que parece que en el software nos negamos a asimilar:

• Compromiso. Los acuerdos se hacen mediante contratos. Y los contratos están para cumplirlos.
• Disciplina/Ingeniería: debemos tener las herramientas y procesos adecuados para estimar y reestimar progresivamente si vamos a terminar en fecha y con el coste pactado. Y por supuesto, con la calidad pactada como mínimo.

Se oye hablar de que las casas se venden por metro cuadrado, y que esto no es válido para el software, ya que las casas siguen un método industrial (supuestamente radicalmente diferente del desarrollo software). De nuevo, otra falacia interesada.

Las casas, si se fabrican iguales, costarán un precio similar. El problema no es el método, sino que los materiales, mano de obra, etc., están muy estandarizados en la construcción de casas. Pero siempre existirán casas hechas a medida, con piezas no estándar, y que costarán un ojo de la cara (es decir, su precio por metro cuadrado, se dispara). De todas formas, si nos fijamos en las casas estándar normales...¿habéis comprado alguna casa? ¿Os habéis fijado que en mismo edificio de casas, donde dos de ellas supuestamente deberían ser iguales...no han salido igual? ¿Verdad que todas las casas no salen con los mismos fallos? ¿Verdad que si medís los metros cuadrados de todas las viviendas...ninguna cumple exactamente con lo que dicen los planos?

Por tanto, llegamos a la conclusión de que las casas no son iguales, no se construyen iguales (sencillamente porque es imposible), y se requiere una ingeniería detrás para poder conocer cuándo podrán estar terminadas, y cuánto dinero van a costar. Eso se hace con planificación y gestión. ¿Por qué no hacemos lo mismo con el software? ¿Porqué seguimos renegando de los métodos de ingeniería, pero no estamos dispuestos a que dejen de llamarnos ingenieros?

Plantillas...¿para qué sirven?

Escribo esta entrada tras observar una interesante actitud en nuestra profesión, aunque por otro lado no es nueva, sino que es tan antigua como dicha profesión. La verdad es que la tenía medio escrita hace ya días, y como llevo un buen lapso sin tener un minuto libre, creo que ya es el momento de sacar esta entrada a la luz.

Por un lado, desde el área de calidad yo preparo con cariño la metodología para cada proyecto:
- Adapto los procesos y herramientas.
- Adapto las plantillas al entorno, cliente, tecnología...
- Adapto el número de plantillas y procesos a cubrir al tamaño del proyecto y sus requerimientos de rigor, etc.
- Finalmente, intento detectar gaps que me indiquen que se trabaja más de la cuenta, y no se aporta valor al proyecto o a la empresa. El objetivo es hacer lo mínimo indispensable, y buscando siempre que nada se haga dos veces en dos sitios distintos.
- Luego con el día a día, compruebo si los proyectos necesitan algo (de más, o de menos).

Dicho esto, puedo encontrarme con la siguiente situación: para comunicar algo, alguien del proyecto manda un correo al cliente usando como adjunto un word en blanco (y unas frases escritas en él, sin ningún formato, logo ni orden prefijado).

Cuando lo reviso, realmente me pregunto porqué no se usó la plantilla que yo con tanto esfuerzo había preparado. Y no es porque me haya costado tiempo. En esta profesión, desde que se es programador, hay que aprender a que el trabajo (código o lo que sea) no es nuestro. No hay que tener el apego que se tiene a una obra de arte o a un hijo nuestro. Si hay que rehacerlo, o si hay que aplicar un cambio, se acepta. Eso no significa que lo hagamos con desgana ni sin cariño. Significa que hay que aceptar esos cambios igual que se acepta que un hijo tomará su propio rumbo lejos de nosotros algún día.

Volviendo al tema, a que si recibiéramos un documento de una empresa o del gobierno, nos gustaría que dicho documento no estuviera en blanco...sino que tuviera un formato...un logo identificando al organismo o empresa que nos lo envía...Sin embargo, cuando se trata de mandar al cliente un documento...¿porqué no usar una plantilla si ésta se encuentra ya disponible? ¿No da su uso una imagen de profesionalidad, coherencia y buen hacer?

¿No tiene el código su estilo, tabulaciones, estructura y formato? ¿Porqué no hacer lo mismo en lo único que va a ver el cliente (los documentos)? ¿No es cada día más común el usar patrones y estructuras de código estándares y que de esta forma nos aceleren el desarrollo?

Yo creo que el problema está en nuestra percepción de la diferencia entre el código y los documentos. El código lo vemos como algo que es para nosotros, y por eso le dedicamos más tiempo y atención. Sin embargo, la documentación nos es ajena: es algo para el jefe, o para el cliente.

Y aquí, en mi opinión, es cuando pecamos de no aplicarnos lo que exigimos a los demás. El código que nos pasan los compañeros nos gusta que esté estructurado y cumpla un estándar, si es posible, coherente y común en todo el proyecto. Pero no sentimos la misma obligación de seguir un estándar a la hora de por ejemplo usar un documento de cara al cliente.

Hay otro problema añadido con los documentos, y es que tienen la habilidad pasmosa de salirse de contexto. Un word adjunto a un correo, tiene sentido. Pero cuando alguien lo copia y pega en otro correo...o lo guarda en una carpeta de red...ya hemos perdido el contexto. Perdemos el autor, la fecha, la empresa...(oh, claro, tenemos las propiedades del documento, que ni son obvias ni fáciles de ver, aparte de que no demuestran un autor, sino la máquina desde la que se creó).

¿Y tú? ¿Eres de los que prefieres usar un documento en blanco aún cuando existan plantillas para algo? ¿O prefieres inventar la rueda una y otra vez excusándote en la creatividad?

La gestión por falsa presión

Hola, tras el éxito del último post sobre los gurupollas, vamos a retomar la temática del desarrollo de software y la calidad.

Hoy el tema versa sobre la metodología de gestión basada en crear una falsa presión en el equipo. Hay varias formas de hacerlo. Repasaremos algunas, y creo que así me entenderéis mejor:

1. Falsa fecha de finalización.

Esta técnica, consiste en trasladar al equipo de desarrollo una falsa fecha de fin de proyecto. Es decir, si por ejemplo sabemos que el proyecto ha de estar entregado el 15 de Junio, podríamos decir al equipo que debemos entregar el 15 de Mayo. Con esto, conseguiremos trasladar una falsa presión, pedir más compromiso, bla bla bla.

¿Y qué ocurre si se llega con éxito a la falsa fecha? Pues tendríamos casi un mes para añadir funcionalidad o corregir errores y preparar documentación.

¿Y si no llegamos a la fecha de fin? Pues no hay problema, porque contaríamos con un mes de margen. Y siempre les podemos decir al equipo que somos nosotros, gracias a nuestra maravillosa gestión, quienes hemos conseguido un mes más de plazo.

Así matamos dos pájaros de un tiro: conseguimos que el equipo se esfuerce desde el minuto cero como si fuésemos retrasados antes de empezar. Y además, podremos defender que gracias a nuestra maravillosa gestión (¿qué gestión?), hemos conseguido un mes más de tiempo para que se pueda terminar con éxito.

En resumen: (a) esfuerzo desde el principio, y gratis. (b) Logramos quedar como los salvadores del proyecto gracias a nuestra gestión. (c) El cliente, consigue tener algo funcional y operativo mucho antes, y hay tiempo asegurado para cambios de última hora, documentación, etc. Eso sí, luego hablaremos del coste humano que tiene.

2. Falsa fecha de entrega parcial.

Este caso es una variante del anterior. Basta que le digamos al equipo que el cliente quiere tener una entrega funcional parcial de la solución final.

Si alguno de nuestros programadores conoce la fecha de fin de proyecto, será el truco que tendremos que usar, ya que no podremos mentirles con una "falsa fecha de finalización".

Los resultados son los mismos, pero por desgracia, los costes (más adelante hablaremos de ellos), también.

3. Funcionalidades falsas por exceso.

Hay ocasiones en que hay funcionalidades extras, que o bien interesan al jefe de proyecto, o bien estaban en el contrato como "extras" o "valor añadido".

También es posible que sean funcionalidades que detectemos que pueden venir bien de cara a la imagen del producto final, aunque realmente no estuvieran identificadas como requisitos.

Si en lugar de tratarlas como requisitos, nos limitamos a decir que son "obligatorias" y estaban "pactadas" desde el principio, tendremos una variante de los casos 1) y 2): logramos trasladar presión al equipo para empezar a esforzarnos al límite desde el principio pero no por una fecha falsa, sino por unas funcionalidades falsas.

4. Funcionalidades falsas por defecto.

Esta es una variante de la anterior (nº3), en la que el jefe de proyecto decide trasladar a su equipo sólo un subconjunto de los requisitos, pero normalmente se combina con las técnicas 1) y 2) para de nuevo, lograr una falsa presión en el desarrollo, y de esa forma, lograr con sobreesfuerzo y sacrificios lo que no somos capaces de hacer mediante nuestra capacidad de gestión.

¿Beneficios?

A continuación, veamos qué hemos logrado con todo esto:

• Esfuerzo del 120% del equipo, desde el minuto 0
• Trasladar un sentido de culpa al equipo de desarrollo, trasladándoles la culpa y la presión. Después de todo, el jefe de proyecto no es que no gestione porque no sepa, sino porque la falsa presión creada hay que justificarla también con una locura organizativa, falta de planes, calendarios y objetivos. Se trata de correr a toda costa para lograr los falsos objetivos parciales.
• El jefe de proyecto consigue reconocimiento, pues es más fácil lograr el éxito, a costa del equipo y su salud.
• El jefe de proyecto consigue quedar bien, pues aparenta que las nuevas fechas y funcionalidades son gracias a su gestión con el cliente y sus enérgicas habilidades negociadoras, y no por haber ocultado y tergiversado los objetivos en fechas y funcionalidades.
• El cliente observa avance, esfuerzo y tiene una falsa percepción de compromiso.

Costes de esta mala praxis

¿Y esto sale gratis? ¿Tiene alguna consecuencia?
Pues claro. Veamos algunos de los costes derivados:

• El equipo se quema muy pronto. Es fácil perder empleados que se van a otras empresas, bajas por depresión o enfermedad, etc.
• El producto conseguido necesita corregirse, bien en el tiempo "extra" conseguido, o bien en una fase de mantenimiento. El producto suele funcionar más o menos, pero suele ser insostenible, del tipo "mírame pero no me toques". La calidad se ve penalizada, y creedme que lo lamentará el pobre mortal que se atreva a mantener este inmundo código.
• El esfuerzo necesario para hacer la aplicación es mucho mayor, ya que la falta de documentación y la tensión necesaria lograr los falsos objetivos hacen que luego haya que retocar todo para que realmente funcione.

¿Te ha pasado alguna vez algo parecido? ¿Has observado en tus proyectos o en proyectos de conocidos alguna de éstas técnicas y/o sus consecuencias?

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.

5 puntos que te salvarán de los cambios (y 3 que te hundirán si no los evitas)

En todo proyecto software, hay cambios. El cambio, hay que aceptarlo como lo que es, y entender su motivación y circunstancias. Hoy nos vamos a centrar en estar preparados para el cambio en el desarrollo de software, mediante 5 puntos clave que hay que conseguir. Además, otros 3 puntos clave que hay que evitar, para que no nos "hundan el chiringuito". Vamos Allá.

1. Puntos Clave a cumplir

1.1. El proyecto tiene designado un equipo/comité responsable de los cambios.

No hace falta que sea un comité sofisticado, ni pensemos en un comité como 20 personas serias y  estiradas reunidas en una sala gigante durante horas. Un comité simplemente es una reunión formal o informal, en la que se revisan temas (cambios en este caso), y donde todas las partes están representadas. Una persona puede representar a varias partes. Por ejemplo, sería interesante que al menos hubiera participantes por parte de:

• Cliente (responsable que defiende los intereses del cliente).
• Equipo de desarrollo (responsable funcional/técnico)
• Dirección del proyecto (responsable económico/planificación)

Puede ser suficiente un foro, un blog, o una lista de correo (ni siquiera se tienen que reunir físicamente esas personas).

1.2. El proyecto tiene un plan o procedimiento escrito y aceptado de gestión de cambios.

Aquí, de nuevo, menos es más. Me  hace gracia cuando en una reunión planteo cómo se van a gestionar los cambios. Todo el mundo asume que los cambios se van a hacer. Ese no es el tema. La gestión del cambio está para decidir qué/cuándo/cómo. De eso hablaremos en detalle otro día.
Como siempre, lo importante es aclarar el funcionamiento y acatar las decisiones tomadas en consecuencia.

1.3. Las peticiones de cambio se evalúan por todas las partes implicadas en el proyecto, antes de resolverse.

Esto es importante, si nos dejamos a alguien fuera al resolver un cambio, tenemos todas las probabilidades de que esa parte decisoria será la que nos haga echar el cambio atrás. De hecho, hay gente que lo hace por el mero placer de ejercer el poder de hacerlo.

1.4. El equipo/comité responsable de cambios, se asegura de que todas las partes implicadas están adecuadamente informadas de cómo se resuelven los cambios.

Otra vez un punto crítico: no nos dejemos a nadie fuera. ¿Te gusta que tu pareja tome una decisión o haga algo sin decírtelo? (no, ya sé que tu pareja lo hace, te estoy preguntando si te gusta!).

1.5. El equipo/comité responsable de cambios evalúa los cambios por paquetes, evitando distraer al equipo de desarrollo de forma constante.

Bastante tienen/tenemos los desarrolladores con lidiar con las complejidades técnicas, las dificultades de las distintas arquitecturas, la definición funcional, etc, etc....como para que encima nos interrumpan cada poco tiempo con cosas nuevas. Hay quien dice que es mejor interrumpir con los cambios, ya que éstos pueden afectar al trabajo en curso. MENTIRA. Déjame acabar lo que estaba haciendo, y luego ya veré cómo aplico el cambio. ¿A alguien se le pasa por la cabeza reformar su casa mientras los albañiles están levantando los pisos y poniendo ladrillos?.

2. Puntos clave a evitar.

2.1. Las decisiones del comité de cambios pueden contradecirse por la dirección, marketing o el cliente.

A ver, hay que ser serios. Respetemos los acuerdos alcanzados.

2.2. El equipo de desarrollo no tiene tiempo suficiente para seguir el plan.

De nada sirve montar un comité ni toda esta fiesta, si el equipo de trabajo está con sobreesfuerzo. Si no hay tiempo, y el plan no se puede seguir, menos aún podremos abordar cambios. Hay técnicas para eso, pero mejor lo dejamos para otro día.

2.3. Los productos del trabajo no siguen el control de cambios.

Esto que dicho así suena muy sofisticado, no es más que hacer el maldito check-in, anotar los cambios, y asociarlos a alguna tarea. Lo mismo cuando estemos preparando una versión al final de un sprint. Etiquetemos adecuadamente las versiones, su estabilidad, etc. Pocas cosas hay más divertidas que después de que nuestro equipo de sufridos testers pierda días y días probando la versión N, ahora vamos nosotros y entregamos al cliente la versión N+1. Manda huevos.

Toma de Requisitos - Paso 9: Requisitos no funcionales

Toma de Requisitos - Paso 9: Requisitos no funcionales

Hoy vamos a  finalizar esta serie de artículos sobre la toma de requisitos (algunos suspiraréis de alivio), explicando el último paso: la documentación de requisitos no funcionales.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Una vez tenemos cerrado el prototipo, es importante cerrar la documentación de usuario (que representa sobre todo los requisitos de interfaz), pero también, es vital complementarlo con los requisitos no funcionales.

Las tareas realizadas en los Pasos 1 a 8 nos han permitido solventar proyectos basados principalmente en interfaz, proyectos más bien pequeños.

Sin embargo, siempre tendremos funcionalidades necesarias pero difíciles de plasmar en un prototipo o en un manual de usuario: los requisitos no funcionales. Aquí podemos encontrar entre otros:

• Velocidad de acceso a la aplicación, o tiempos de respuesta.
• Uso de memoria.
• Interfaz con el sistema operativo o con otros sistemas (tanto hardware como software).
• Algoritmos detallados con reglas internas de comportamiento (reglas de negocio).

¿Hay que hacer un documento con todo esto? Pues no del todo. Lo que hay que hacer es recopilar esta información para que no se pierda, y esto puede hacerse en varios sitios (seamos ágiles):

• Como un anexo del manual de usuario
• Como notas en una pizarra o post-its en la pared (que alguien se acuerde de hacerle una foto, antes de que se los lleve el viento!!)
• Etc.

Finalmente, viene la parte más dura: hay que revisar, establecer una línea base, y poner bajo control de cambios este documento/foto/pizarra.

• Revisar: siempre viene bien, 4 ojos ven más que 2. Si programar entre pares produce buen código...¿porqué no revisar más de una persona los documentos?
• Línea base: hay que dejar claro un punto de partida. Difícilmente sabremos llegar a ningún sitio si no tenemos claro cuál era nuestro punto de origen.
• Control de cambios. No pongáis la cara que suelen poner la gente en mis proyectos cuando les cuento esto. Control de cambios podría ser hacer una foto nueva a la pizarra cada vez que cambiamos los post-it, o guardar el documento en subversion y guardar una nueva versión cada vez que lo modificamos.

Y esto ha sido todo. Para finalizar, decir que estos 9 puntos no indican COMO ha de ser una toma de requisitos. Es tan sólo una aproximación para hacerlo, orientada a proyectos en los que sea primordial contar con un prototipo, exista un cliente involcurado, predominen los requisitos funcionales sobre otros, etc.

Como ya creo haber comentado en algún otro post anterior, estaría relacionado con la metodología UIDD (o User Interface Driven Development), donde lo primero que se hace es la interfaz, y se va propagando el desarrollo a otras capas o partes del sistema. Ojo, no significa esto que la interfaz esté cerrada. Recordad que la realidad siempre estará en contra nuestra, y lo más probable que cambie...sea lo más estable y asentado que tengamos. Gracias Sr. Murphy por tu ley.

Toma de Requisitos - Paso 8: Escribir documentacion de usuario

Toma de Requisitos - Paso 8: Escribir documentación de usuario

Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 8: escribiendo una documentación de usuario detallada, basada en el prototipo que completamos enel paso 6 y que establecimos en el paso 7 como línea base de los requisitos.

Esta entrada forma parte de una serie:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Una vez tenemos cerrado el prototipo, es importante cerrar también, lo antes posible, una documentación de usuario (requisitos, manual de usuario, etc).

Muchos pensaréis: "venga ya. ¿ahora vamos a documentar? ¿No basta con el código?". De esto ya hemos hablado en otros posts: "Nos gusta programar pero no documentar". Hay varios motivos para hacerlo:

• Porque lo pide el cliente (sí, en multitud de pliegos, concursos públicos, etc., se exige documentación).
• Porque lo necesita el cliente (sí, de nuevo, los manuales se necesitan, como se necesita una rueda de repuesto. Y eso es así, aunque la rueda de repuesto, al igual que el manual, quizá no se lleguen a usar).
• Porque el cliente no se va a leer tu código cuando tenga que hacer algo y no sepa cómo, o cuando algo no funcione como el usuario cree que debe hacerlo.
• Porque cada vez que el cliente quiere negociar o revisar el avance del proyecto, no se va a leer tu código para ver cómo va a funcionar todo cuando esté: lo que se revisa son los requisitos o un manual provisional.

Bueno. Sigamos. Aunque normalmente se documenta al final, en nuestra aproximación, lo haremos al principio. ¿Porqué? Pues porque estamos haciendo una toma de requisitos, y la mejor forma de hacerlo es dejando los documentos por adelantado.

Es más fácil para el equipo de desarrollo consultar el manual a la hora de hacer unas pruebas, o de avanzar el desarrollo, que cualquier otra cosa. Quizá el usuario no se lea el manual, pero al menos los programadores y los testers sí deberían estar hartos de leerlo. Probablemente el usuario no se lo lee porque los manuales que solemos hacer son siempre "fuera de hora": los hacemos en ese tiempo que hay al final del proyecto, y porque nos obligan, y siempre es en horas muertas, o cuando ya estamos reventados de intentar sacar adelante una funcionalidad que ya va retrasada. Por cierto, esa funcionalidad tal vez no estaría retrasada si no hubiéramos tenido que rehacer 20 veces el producto...y eso ocurría (tal vez), si nos hubiéramos molestado en hacer un manual de usuario al principio (como aquí planteo).

Otra ventaja de hacer la documentación y manuales al principio, evita tener que hacer una especificación técnica detallada. Ya se indica cómo debe funcionar todo, ya están los requisitos...¡pues a programar!

El cliente y usuarios finales entenderán mucho mejor un manual, y seguro que si es el mismo que usan (y revisan y corrigen) los programadores en el día a día, será un manual útil, y no el típico ladrillo que se suele hacer y que nadie lee.

El tener una documentación completa tan temprano, pule aún más posibles inconsistencias y puntos "oscuros" que pudieran haber quedado en nuestro prototipo. Se evitan muchas veces el tener documentos demasiado técnicos. En su lugar, se está haciendo una documentación basada en el uso, en la funcionalidad, no en la tecnología.

Este tipo de documentación, se va a mantener y a actualizar, mucho mejor que cualquier otro tipo de documento. Puesto que es algo que todo el mundo usa y necesita tenerlo al día: los usuarios finales, los programadores, los analistas, los testers...es como el anillo de la película del señor de los anillos: "un documento para unirlos a todos...".

Este tipo de documento es práctico, sin rollos que pretendan artificialmente hacerlo ameno, o inteligente, o complejo. Dice lo que el usuario necesita que el software haga. Y punto.

En este documento, como hemos dicho, se especifica (como si fuera un documento funcional), el QUE, pero no el COMO.

Pero además, este tipo de documentación da a los programadores libertad y creatividad para resolver técnicamente las cosas como mejor les parezca. Y de esta forma, es mucho más fácil que acabe creando software que cumpla lo QUE necesita el usuario.

Un saludo.

Toma de Requisitos - Paso 7: Prototipo como Requisitos 1.0

Toma de Requisitos - Paso 7: Prototipo como Requisitos 1.0

Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 7: establecer el prototipo como la primera versión de los requisitos.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Una vez llegados a este punto, tendremos un prototipo bastante completo. Pero...¿No se trataba de tomar los requisitos? ¡Pero si ya los tenemos! Basta con considerar el prototipo como la primera versión de los requisitos.

Para ello, el prototipo debe cumplir una serie de características:

• Debe ser estable.
• Debe haber un compromiso por parte del equipo de desarrollo de hacer el software realmente a imagen y semejanza del prototipo.
• El cliente, o al menos los usuarios clave, han de validarlo.
• Debe ponerse al prototipo bajo control de cambios. No podemos modificarlo a la ligera. Un cambio en el estilo, en el flujo, en la funcionalidad...nos puede provocar una tormenta imparable de cambios.

A partir de aquí, basaremos todo en el prototipo, de forma que sirva de base para crear:

• Las estimaciones.
• Los planes.
• La estructura y organización del equipo.
• Los diseños.
• EL desglose del trabajo que permita construirlo.

Y aquí da igual la metodología que usemos. Sea ágil o no, hay que aceptar los cambios en el prototipo, como parte de los cambios que se requieren para el producto final.

El control de cambios no significa "ya está", "ya lo tenemos y no hay que tocarlo". Pero sí significa que tenemos que estar atentos a cada cambio, y realizar el adecuado seguimiento antes de aceptarlo, rechazarlo, o ponerlo "en espera". Ya dedicaremos un día algún artículo más detallado al control de cambios, y algunos trucos al respecto que espero os sean útiles.

Por desgracia, la manera más común de tratar los cambios es aceptar todo sí o sí, desbaratando cualquier plan existente, y evitando realizar nuevos planes, que al final, pudieran habernos llevado al éxito. Por desgracia, es así en demasiadas ocasiones. Y es que nos ciega el éxito, nos da miedo involucrar al cliente y realmente llevar un buen control de cambios. En fin.

Una vez tenemos la primera línea base del prototipo, la primera versión por tanto de los requisitos, tendremos una serie de logros adicionales:

• Posibilidad de empezar con la documentación de usuario (manuales, etc).
• Preparar los planes de pruebas, con todo detalle.
• En paralelo, también pueden comenzar la arquitectura, diseño y algunas tareas de implementación.

En el siguiente post de esta serie, veremos ya la creación de documentación, y la toma de requisitos no funcionales.

Un saludo.