Metodología XP - Los 15 principios

Hace tiempo que quería escribir algo sobre XP (eXtreme Programming). Y es que todo el mundo está emocionado con las metodologías ágiles, principalmente Scrum. Pero para entender los problemas de Scrum y sus ventajas en función del tipo de proyecto (ya he comentado esto otras veces), hay que entender la historia de las metodologías ágiles.

Y qué mejor forma de empezar, que recordando los principios básicos de XP (hablo de eXtreme Programming, la metodología ágil antecesora de las actuales).

La metodología XP comenzó oficialmente con el libro de Kent Beck de 1999, aunque ya llevaba al menos uno o dos años oyéndose por la red. Ya existía un brote ágil que terminaría de catalizar a partir del año 2000.

El propio Martin Fowler, en su blog nos habla en un artículo de los 15 principios de XP. Vamos a revisarlos.

Tenemos los 5 principios fundamentales:

• Rapid Feedback
• Assume Simplicity
• Incremental Change
• Embracing Change
• Quality Work

Aunque existen otros 10 principios adicionales, hasta conformar los 15 principios ágiles:

• Teach Learning
• Small Initial Investment
• Play to Win
• Concrete Experiments
• Open, honest Communication
• Work with people's instincts - not against them
• Accepted Responsibility
• Local Adaptation
• Travel Light
• Honest Measurement

Si os fijáis, estos principios serían anteriores incluso al manifiesto ágil, surgido a raíz de la reunión que convocó Kent Beck y que dio origen a dicho manifiesto. Kent Beck fue el autor, 2 años antes del manifiesto ágil del libro "Extreme Programming Explained".

El resto, como se suele decir, es historia.

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

24h - El complejo de Jack Bauer

Ocurre en muchas ocasiones: más de las que nos gustaría y más de las que queremos admitir. En esta profesión de desarrollo de software, en la que tenemos metodologías, métricas, procesos, calidad, más de una vez nos habremos encontrado sufriendo el complejo de Jack Bauer.

Ocurre de forma progresiva: primero tenemos todo planificado y bajo control, todo parece ir sobre la seda, y cuando menos te lo esperas, salta un problema para el cual no tenías un plan de contingencia. La cuestión no es tanto si sabemos o no planificar, sino más bien cómo afrontar los problemas. Esos problemas que se suelen manejar en un comité y que en más ocasiones de las que nos gusta admitir, tememos escalarlos a ese comité por no asumir responsabilidades.

¿La consecuencia? Pues que trasladamos a nuestros equipos esa responsabilidad, enmascaramos la culpa con una falsa urgencia (o no tan falsa), y movilizamos nuestros ejércitos para afrontar lo que parece ser un capítulo de la serie de televisión "24". Con un plazo imposible de cumplir, nos embarcamos en una tarea sobrehumana, y sustituimos la culpa, la gestión y las metodologías por un compromiso y resolución que nos lleva a ser protagonistas de esa serie, donde hay que salvar el mundo, hacer tareas imposibles, recorrer varias veces toda la ciudad y todo ello en 24 horas.

¿Os suena? Pues sí, esto es el complejo de Jack Bauer, personaje protagonista de esa serie de televisión, y que representa muy bien las situaciones de "bombero" o "apagafuegos" en las que nos vemos inmersos.

Esta forma de afrontar los problemas, la podéis encontrar en la red con otros nombres. Uno que me ha gustado es el antipatrón "apagafuegos". Os recomiendo leer esa web de antipatrones.

Hay que tener mucho cuidado con esta forma de actuar, porque lleva a ser estimulante. Nos podemos sentir héroes salvando el mundo, apagando fuegos constantemente, en ese complejo de Jack Bauer. En lugar de afrontar los problemas como lo que son, no podemos tratar de resolverlos todos a la primera de cambio, en ese ciclo de subida (esfuerzo heroíco de resolver el problema) y de bajada (bajón inevitable que tenemos cuando la situación ya es estable y la adrenalina se agota...hasta el siguiente fuego).

Hay quien ve esta forma de actuar como una adaptación al cambio. Pero adaptarse al cambio no significa afrontar los problemas con sesiones a lo Jack Bauer (es decir 24 horas sin dormir y con esfuerzos histéricos para resolver las cosas). Hay que atajar los problemas de base, porque distraer al equipo de esa forma significa alejarlo del objetivo del proyecto. Esa distracción no supone 24 horas, sino mucho más: el coste de recuperar el ritmo, y también de recuperarse de ese esfuerzo.

Los cambios los gestionamos nosotros, no al revés.

Cuidado con las estimaciones ágiles

Hoy os voy a traer un caso real. En estos tiempos en las que las metodologías ágiles están en todas partes, es el momento de reflexionar el qué queremos, pero sobre todo, qué necesitan nuestros clientes.

En concreto, mucho cuidado con las estimaciones ágiles porque los clientes siguen necesitando saber en muchas ocasiones cuándo van a estar disponibles sus aplicaciones, y a qué precio. Os adjunto una conversación que podría ocurrir a pocos metros de donde estáis:

- [Cliente] ¿Cuánto va a costar esto? ¿Y cuánto tiempo tardaremos en tenerlo? La verdad es que tenemos unas fechas límite muy definidas, y el presupuesto no nos da para muchos cohetes.
- [Vendedor/Técnico ágil] Pues es que nosotros no estimamos en horas, sino en StoryPoints. Pero no se preocupe, porque esto es un marco de trabajo Scrum altamente reconocido.
- [Cliente] ¿Ah, sí? Pues que sepas que mientras tanto, te pagaré en BarPoints (tickets del bar). Pero no te preocupes, porque esto en nuestra cafetería de empresa es una forma de pago altamente reconocida.

En fin. Creo que ha quedado claro. Mucho cuidado con las obsesiones y sobre todo actitudes talibanes respecto al agilismo. De nuevo tenemos las balas de plata de nuestra generación. Y de nuevo, hemos de usarlas como lo que son: tan sólo una herramienta más, que hemos de adaptar a cada situación y necesidad.

¿Y tú ...qué les das a tus clientes? ¿Lo que ellos necesitan, o lo que tú les quieres dar?

Libro gratuito: Casos de Uso 2.0 de Ivar Jacobson

Hola a todos. Ya podéis descargaros de forma totalmente gratuita, el interesantísimo libro de Ivar Jacobson "Casos de uso 2.0", a través del siguiente enlace:

http://www.ivarjacobson.com/resources/resources/white_paper/

El autor, Ivar Jacobson, es más conocido por su participación en la creación de UML, RUP y la programación orientada a aspectos.

Feliz lectura.

No borres tus huellas, vaquero

Esta entrada en mi blog la dedico a todos aquellos que borran sus huellas en el trabajo. Los que sólo guardan los ficheros en su última versión. Los que no versionan los documentos. Los que cuando tienen un fichero incompleto lo destruyen al comenzar uno nuevo.

Son los amigos de lo imperfecto. Tal vez sea la obsesión de aparentar perfección, o no mostrar debilidad, tan habitual en algunas empresas.

No se trata de guardar un registro de todo lo que hacemos, sino más bien de protegernos de nosotros mismos. Después de todo, la mayoría de herramientas de versionado de código nos protegen de nuestras ganas de cambiar el código en exceso, permitiéndonos recuperar una versión previa que funcionaba o que simplemente queremos revisar. Si estamos de acuerdo en el caso del código fuente...¿qué pasa con la documentación?

La documentación es parte del proyecto.

Debemos cuidar la documentación, tal y como hacemos con el código. De nada servirá esto a los que entienden que la documentación se hace "después del código".
Cómo me duele ver en los diseños técnicos o funcionales, código fuente o pantallas que se han obtenido de la versión final.
Los documentos  hay que versionarlos y cuidarlos como cualquier otro resultado de nuestro trabajo.

La necesidad del versionado.

Algunas ventajas de tener la documentación versionada en un repositorio:

• Documentación alineada con cada versión del código.
• Es fácil identificar los cambios en los objetivos, del mismo modo que el versionado del código permite identificar los cambios en los resultados.
• Acceso centralizado. Al estar la documentación versionada y centralizada, todo el mundo accede a la última versión.
• Notificaciones de versionado. Muchos repositorios de documentos avisan de nuevas versiones. Esto es útil porque el equipo de desarrollo puede estar informado de cualquier cambio en una Historia de Usuario, un Requisito (o como lo queráis llamar).
• Permite escalar proyectos. Es muy sencillo trabajar con post-its para documentar requisitos, pero escalarlo a un equipo de 50 personas en 10 países, no es sencillo. En un repositorio documental, incorporar a un nuevo equipo en otro país es tan simple como darles acceso.
• Utilizar un repositorio permite ahorrar reuniones: todo el mundo puede estar al tanto de que se está cociendo una nueva versión de los requisitos, o de que se han modificado 5 de las 10 historias de usuario de nuestro producto. Esto no significa que no sean útiles las reuniones. Simplemente se trata de que las herramientas hagan el trabajo más simple.

¿Y qué hacemos en un proyecto pequeño?

Si tu proyecto es muy pequeño, puedes hacer el versionado de forma manual. Guarda el archivo como "requisitos_v02" y ya está. También puedes integrar la documentación como parte del código, y que tu herramienta (Subversion, Git, etc), se encargue del resto.
De todas formas, es útil seguir con la documentación, las mismas técnicas que un repositorio de código:

• Check-out: Avisa de que el documento lo vas a modificar. Que la gente tenga claro que hay una nueva versión en curso. Eso les hará organizarse mejor y centrarse en las áreas que menos cambios vayan a tener. Pocas cosas molestan más que ver cómo llega un gran cambio sobre algo en lo que hemos dedicado varias semanas con sus larguísimas jornadas. Y más cuando hay otras tareas que podríamos haber avanzado en su lugar. Avisa de la fecha prevista para terminar la nueva versión.
• Check-in: Avisa de cada nueva versión. Que la herramienta (o tú mismo mediante un correo), notifique al equipo de una nueva versión de lo que sea (requisitos, análisis, etc). Hazlo ágil y simple. Tanto para el que lo lee, como para tí que lo escribes y que lo vas a tener que actualizar.

Actitud y respeto, fuentes del problema.

Al final, es una cuestión de respeto profesional, de velar por que nuestras acciones ayuden en lugar de interferir al resto del equipo. De intentar prever las consecuencias de nuestros actos, no limitarnos a soltar nuestro (llámalo código, documento o lo que sea), y darnos la vuelta para no ver los resultados.

Muchas veces oigo a la gente quejarse de lo mismo repetidas veces: "para qué documentar si nunca voy a tener la documentación actualizada". Es deprimente, ya que muestra un grave problema de actitud. Hazlo o no lo hagas, pero no lo intentes. Deja ya esa actitud derrotista, por favor. ¿Somos ágiles y por tanto capaces de abrazar los cambios en el código? ¿Y sin embargo no somos capaces de hacer lo propio con la documentación? Claro que van a llegar cambios, es algo inherente en el software. El problema está en que no documentamos, sino que escribimos novelas.

Yo no sé si hay falta de programadores, pero de lo que estoy seguro de que sobran novelistas, y faltan buenos analistas o arquitectos que documenten los objetivos técnicos y funcionales. Menos verborrea, y más UML, casos de uso, historias de usuario.

PMO IV - Inconvenientes de una PMO

Este es el cuarto de una serie de artículos sobre PMO:

PMO I - Introducción
PMO II - Descripción
PMO III - Ventajas de una PMO
PMO IV - Inconvenientes de una PMO

Hoy repasaremos brevemente los principales inconvenientes que ofrece una PMO. Veremos que más que inconvenientes, se trata de riesgos que podemos controlar mediante las adecuadas técnicas de mitigación y contingencia.

Burocracia adicional.

Una PMO introduce procesos, metodología, y un nivel de control y supervisión de los proyectos que puede aportar mucho a la dirección. Sin embargo, desde muchos estamentos, puede considerarse que la PMO añade burocracia. El añadir flujos de trabajo, la necesidad de aprobar las cosas antes de hacerlas...hace pensar a muchos que las cosas son más lentas, que requieren de más burocracia.

Territorialismo

La PMO se ve como un órgano impuesto, y la reacción es defender el departamento/territorio del nuevo intruso.
Esta reacción lleva a muchos a comportarse a la defensiva, o incluso de forma agresiva frente a las peticiones de una PMO, rente a sus flujos  y metodologías de trabajo.
Cuanto menor control y supervisión tienen los equipos de trabajo, más fácil es que la reacción sea la que aquí comentamos.
Después de todo, muchos se sienten "reyes del mambo", auténticos caciques que hacen y deshacen a su antojo...hasta que llega la PMO.

Lastre

La PMO puede ser considerada como un servicio no productivo, un lastre innecesario o de beneficios discutibles.
El aumento de costes derivado de los sistemas soporte, formación, y otros servicios adicionales, puede verse como crítico frente a los beneficios potenciales, que por supuesto, siempre encuentra gente dispuesta a minimizarlos frente a los costes mencionados.

Obstáculo profesional

Riesgo de considerar a la PMO como un obstáculo en la carrera profesional de los equipos de desarrollo.
Normal, en muchas empresas, determinadas personas se ven con carrera por el hecho de disponer de oportunidad, de estar estratégicamente posicionados, tener cierto poder o control...Y entonces llega la PMO, y establece un flujo y metodología estándar, que coarta la libertad de los que hasta ahora se veían con un futuro prometedor.

Torre de Marfil

Riesgo de que la PMO se considere una torre de marfil, no alineada con las necesidades organizativas.
Puede ser por la actitud de los integrantes de la PMO, por envidias, o por una falta de efectividad en el funcionamiento de la PMO, por lo que este departamento se considere una "torre de marfil", inalcanzable, con demasiado poder, sin escuchar ni atender las demandas de los proyectos o la organización.

Falta de soporte

Riesgo de falta de soporte de la alta dirección, principalmente.
Sin el adecuado soporte de la dirección, la PMO no tiene poder efectivo, y puede considerarse "un bonito florero", sin utilidad ni capacidad real de llevar a cabo su función.

¿Y vosotros? ¿Os habéis encontrado con estos problemas u otros similares? Saludos
 

PMO III - Ventajas de una PMO

Este es el tercero de una serie de artículos sobre PMO:

PMO I - Introducción
PMO II - Descripción
PMO III - Ventajas de una PMO
PMO IV - Inconvenientes de una PMO

El de hoy va a ser un artículo que espero sea interesante y a la vez breve. Repasaremos brevemente las principales ventajas que ofrece una PMO, y también veremos en un próximo artículo, sus posibles inconvenientes. Vamos allá.

Definición y estandarización de procesos.

• Una PMO ayuda a definir los procesos de la organización. Básicamente no es inventar nada nuevo. Basta con dejar por escrito todo lo que ya se hace, obtenido de quienes saben hacerlo.
• La ventaja, es que esto ayuda a que no se pierda el conocimiento, se estandaricen las formas de trabajar, se aproveche la ventaja de la experiencia adquirida.

Aumento de la eficiencia.

• De una correcta definición de procesos, del aprovechamiento del conocimiento y la experiencia, se obtiene como resultado natural un aumento de la eficiencia.

Reducción del trabajo duplicado.

• Como resultado de la experiencia y eficiencia, se facilita el reducir el trabajo duplicado.
• Si se han detectado duplicidades en ocasiones anteriores, ese conocimiento se aprovecha.

Menores costes de desarrollo.

• Como resultado de los anteriores, los costes disminuyen.
• Esta disminución no tiene porqué ser radical. Todo depende de lo optimizados que estuvieran los procesos y la organización antes de implantarse la PMO.

Mejora de las comunicaciones internas y externas.

• Una PMO ejerce principalmente como órgano gestor de las comunicaciones.
• Se estandarizan no sólo los canales, sino los formatos y los contenidos. Se identifican responsables de realizar la comunicación, el escalado, los distintos interlocutores, etc.

Alineamiento organizativo orientado a unos objetivos comunes.

• El principal objetivo de la PMO es asegurar que los procesos, las tareas que se realicen, estén alineadas con los objetivos de la empresa.
• Estos objetivos comunes, bien establecidos por la PMO, permiten que todo el mundo trabaje para un fin común. Se aprovechan sinergias.

Mejora en la planificación estratégica.

• Ya no sólo hablamos de planificar proyectos, y hacer el seguimiento. Estamos hablando de una planificación a nivel estratégico, totalmente alineada con los objetivos organizativos.

Mejora en la madurez y profesionalización de la gestión a nivel organizativo.

• La gestión se profesionaliza. Aumenta la madurez, apoyada por el conocimiento y unos procesos bien definidos, y una experiencia aprovechada.

Mejor formación a nivel organizativo.

• La formación se alimenta de la experiencia de los proyectos, de las necesidades organizativas, y de las lecciones aprendidas.
• Como resultado, la formación mejora a su vez el rendimiento en los proyectos, satisface las necesidades de la organización, y permite mejorar las lecciones aprendidas. El ciclo se cierra.

Mejora continua: el uso de lecciones aprendidas evita volver a caer en errores anteriores.

• Los errores cometidos, permiten mejorar los procesos.
• La gestión de riesgos mejora, permitiendo sucesivamente el prevenir errores y problemas anteriores.
• La experiencia permite solventar problemas y prevenirlos de forma cada vez más eficiente.

Hasta aquí todo parece de color de rosa. Pero una PMO no es tan sencillo, y puede tropezar con un alto número de obstáculos, que terminen como inconvenientes para la organización que trató de mejorar su gestión. Esto lo veremos en el próximo artículo de esta serie.

Ser ágil no es ser rápido

Hoy vamos a hablar de la diferencia entre agilidad y rapidez. Y porqué las metodologías ágiles, no tienen que ver con hacer un proyecto más rápidamente, y por tanto, con acabar antes. Cuánta confusión veo constantemente, generada precisamente por los desconocedores y los interesados en las metodologías ágiles. Los primeros, porque asocian automaticamente ágil=rápido, ya que la semántica nos induce a ello. Y los segundos, porque siembran la red de confusión en este sentido ya que tienen intereses profesionales y económicos al respecto. No hay mejor argumento de venta que el decir: ágil=rápido=barato.

Sinceramente, creo que hemos llegado a un nivel de información en la red en el que tenemos que empezar a dudar en la credibilidad de todo lo que vemos escrito, y darle un poco de trabajo a nuestro sentido común (que en ocasiones parece el menos común de los sentidos), y a nuestro sentido crítico.

Este artículo, viene inspirado en diversas entradas que estoy leyendo en las redes y que insisten consistentemente en sembrar la confusión entre estos conceptos. Y señores, no son iguales.

Podemos encontrar multitud de artículos en la web en que incluso defensores del agilismo, admiten la confusión entre estos dos términos. Pero vamos a tratar aquí de usar un poco de sentido común para entender un poco más el problema.

El concepto de rapidez en los proyectos ágiles.

En los proyectos ágiles, la medida del avance es la rapidez. Otra contradicción, por otro lado necesaria, ya que la única forma de saber cómo vamos y cuándo vamos a acabar, es utilizar esta métrica.

Al contrario que los proyectos que no usan metodologías ágiles, el estar abiertos al cambio hace que los requisitos estén permanentemente sujetos al cambio. La única forma de anticipar cuándo acabaremos, no está por tanto en medir el avance por requisitos, sino basarnos en la velocidad. La velocidad o rapidez, es por tanto, lo único cierto y medible. El resto: dependerá de cuántos cambios asumamos. Puede que ahora tengamos 20 historias de usuario. Pero pueden cambiar, y ser mañana 30, o 15...

Notemos aquí lo curioso del tema. Al hacer proyectos con metodologías ágiles, también necesitamos predecir y controlar cuándo va a finalizar el proyecto. La diferencia es la que estamos comentando, que no se basa en el cuánto (nº de requisitos), sino en el cómo (rapidez). Es por eso que los diagramas burndown chart son los principales referentes a la hora de conocer el avance y tratar de predecir cuándo tendremos el producto.

La rapidez en estos proyectos con metodologías ágiles será el número de puntos de historia de usuario (u otra métrica relativa) que realizamos por unidad de tiempo. De esta forma, si hemos estimado bien, podremos predecir el futuro.

El concepto de agilidad en los proyectos ágiles.

En las metodologías ágiles, el término agilidad o ágil está relacionado con la capacidad de adaptación al cambio. Pero no tiene nada que ver, e insisto en el NADA, con la velocidad del proyecto.

Agilidad, es la capacidad para adaptar el curso del desarrollo a la evolución de los requisitos y a las circunstancias del entorno (fuente: Navegapolis.Net, "Gestión de proyectos ágil: conceptos básicos").

Es decir, que la palabra "ágiles" en metodologías ágiles, no tiene nada que ver con rapidez del proyecto, sino con la adaptabilidad al cambio: la disponibilidad y facilidad para asumir cambios en el alcance (nuevos requisitos, o requisitos existentes).

¿Confusión interesada?

Llegados a este punto, empiezo a preguntarme si la confusión de términos no es interesada. A ver, no tengo nada en contra de los defensores del agilismo. Yo también defiendo el agilismo. Pero si lees este blog, sabrás que la cuestión no es defenderlo, sino defenderlo si aplica. No defenderlo porque sí. Todo dependerá del proyecto, equipo de trabajo, cliente, y metodologías actualmente en uso.

¿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.

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)

Mantenimiento software: ¿qué modelo de procesos usar?

Si te dedicas al mantenimiento del software y te interesa saber más sobre qué estándares o modelos de referencia de procesos hay en el mercado, puedes consultar el siguiente enlace:

http://www.berriprocess.com/es/todas-las-categorias/item/30-cmmi-svc_proyectos_mantenimiento

En él, Teodora Bozheva da un rápido vistazo al modelo más adecuado, identificando las diferencias principales entre los proyectos de mantenimiento y desarrollo.

Tanto si eres experto, como si estás empezando, creo que ese artículo está muy bien enfocado a ambos perfiles. No te pierdas, al final del  artículo, el apartado "Referencias".

Saludos.

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.