jueves, 20 de septiembre de 2012

Nos gusta programar pero no documentar


La documentación debe estar al servicio del proyecto y no al revés
Efectivamente, no nos gusta documentar. Esta afirmación llevo muchos años oyéndola, diciéndola y sufriéndola.

¿Porqué no nos gusta documentar?
Pues porque no nos proporciona ningún beneficio aparente. ¿Me cambia en algo la vida si documento 1, 2 o 700 páginas? Probablemente no.
Pero claro, esto es porque lo afirmamos mientras documentamos. Documentar no da el mismo tipo de satisfacción a los programadores que tirar líneas de código. ¿Qué pasa si dejamos pasar los años y tratamos de mantener un sistema sin documentación? Pueden pasar dos cosas:
  • Yo mismo soy el autor del código, y dependeré de mi memoria. Esto apenas me ha pasado el 10% de las veces (el mantener mi propio código pasado mucho tiempo). Y mi memoria, sobre lo cual me considero una persona normalita, no es capaz de retener todas las decisiones funcionales y técnicas que dan lugar a cientos, miles de líneas de código en cada proyecto.
  • El autor del código no está. Bajo mi experiencia, esto me ha pasado alrededor del 90% de las veces. Bien porque he cambiado de empresa y tengo que lidiar con las perlas de otros, o bien porque la persona que lo hizo o empezó ya no está, y ahora yo tengo que mantener lo suyo. En este caso, dependeré de lo bien que el autor o autores lo hayan comentado. Pero como veremos a continuación, tampoco será de utilidad.
Documentar el propio código, no me resolverá nada. Con suficiente tiempo, es posible deducir lo que hace el código. Eso es como decir que si tuviéramos el código de Windows, nos arreglaríamos los problemas que encontrásemos (no tengo otra cosa que hacer si tengo un error, que ponerme a mirar millones y millones de instrucciones, probando a ver qué pasó y cómo arreglarlo). Pero es que estamos dando por sentado que solo tocamos código para corregir cosas, que en nada afectan al resto del código.

Ahí está la clave: no se comenta el código para tener documentación, sino para acelerar los cambios en el código siempre que el objetivo del mismo ni sus circunstancias cambien. Si las circunstancias, la interrelación entre componentes, los requisitos, etc cambian...de poco me sirve el código ni sus comentarios.

Me hace mucha gracia quien afirma que la mejor documentación es el código. Me preocupa y me hace dudar de si esa persona ha mantenido proyectos grandes y antiguos. Las realidades de la empresa cambian, los programas y módulos con los que interactuamos cambian...los sistemas físicos en la empresa cambian. Tener que tirar del hilo del código y sus comentarios para tratar de deducir decisiones antiguas es agotador...e inútil. Porque es el pasado.

Hay quien afirma y afirmará que el código documentado lo es todo gracias a las habituales "balas de plata": patrones de diseño y arquitectura, buenas prácticas, estándares de desarrollo...Eso está muy bien para pequeños cambios y proyectos no muy antiguos. Pero la realidad es que todo eso ha cambiado en el tiempo. Lo que hoy nos parece la piedra filosofal, mañana estará obsoleto y habrá otros patrones, estándares, etc. Mantener código antiguo nos suele llevar a criticar a su autor, simplemente porque no entendemos las "balas de plata" de aquel momento (bueno, de acuerdo, a veces también hay código antiguo realmente horrendo).

Otro problema está en la dispersión y el tamaño. Está muy bien mantener código con comentarios de módulos pequeños, o sistemas concentrados. ¿Qué ocurre si mi código tiene millones de líneas de código, miles de módulos distribuidos en docenas de aplicaciones? ¿Qué ocurre si no tengo siquiera visibilidad de parte del código o de las aplicaciones porque son de otras empresas?

Aquí de nuevo entran en juego la documentación y los estándares. El primer punto a documentar es siempre las APIs o interfaces. Tanto si son nuestras como si no. Un fallo en el código no sabremos si es porque está mal implantada una API, si está con una versión obsoleta...a no ser que tengamos la documentación actualizada de esa API o interfaz. Los comentarios y la documentación, han de satisfacer objetivos diferentes.

Otra razón ineludible de documentar es la esencia misma de la orientación a objetos: abstracción, encapsulación, etc. Una capa de la arquitectura no puede saber de otra. Lo mismo las funciones o módulos. ¿Entonces cómo rastreo las decisiones que abarcan varios elementos si están dispersos y no saben unos de otros? ¿O es que tengo que hacer un "meta-comentario" (comentario de comentarios)? En realidad, esto que acabo de decir, no es ni más ni menos que la documentación que queremos evitar.

La mejor documentación, es la que está orientada a complementar al código y sus comentarios. Habitualmente, se hace a través de los entregables típicos:
  • Requisitos. Recogen a alto nivel las necesidades del sistema desde el punto de vista de cliente/usuario. Son las necesidades básicas. Podemos de alguna forma asimilarlas a las historias de usuario a muy alto nivel. Deben aclarar el qué se espera.
  • Análisis funcional: Contienen el qué debe hacerse para lograr lo que espera el cliente. Es suficiente con definir lo que la parte de la documentación de diseño técnico ha de desarrollar.
  • Diseño técnico: Si se da trabajo a un programador, un diseño técnico puede contener la resolución a problemas técnicos que se han previsto (los comentarios en el código ya comentan los problemas imprevistos).

¿Estoy diciendo que estos entregables deben hacerse? No, para nada.
¿Tienen que ser 3? Pues tampoco. El hacer 1, 2 o 3 documentos dependerá del contexto. Incluso  un breve correo puede ser un análisis funcional de un pequeño cambio. Y no necesitas más. Dependerá de la metodología que se haya definido para el proyecto, el tamaño del mismo, la experiencia...

Lo que digo es que los anteriores son entregables típicos y satisfacen una necesidad. Pero una metodología que obliga de forma rígida (las que por desgracia se implantan en muchísimas empresas), son la causa de las críticas que hay hacia la documentación y hacia las propias metodologías. Si la metodología no se adapta a la realidad del proyecto, será un obstáculo, no un acelerador del trabajo.

¿Cuál es el límite? ¿Hasta dónde documentar? Eso, por desgracia, lo da la experiencia. Yo suelo dar en mis formaciones una máxima: si el analista técnico tiene dudas, es que el funcional necesita más. Si el programador no sabe qué hacer, seguramente el diseño técnico cojea.

Ojo: tampoco quiero decir que no contestemos a la persona que ha de continuar el trabajo. Yo por ejemplo, en un cliente, revisaba la documentación técnica con los programadores, y o bien modificaba el diseño técnico sobre la marcha, o directamente les indicaba cómo quería realizar las cosas, y ellos por un lado, y yo por el otro, seguíamos cada uno haciendo código/documentos. De hecho, algunos programadores terminaban llevando a cabo una solución ligeramente distinta: ellos después me explicaban el motivo, y yo adaptaba el documento a su realidad. Cuesta tiempo llegar a este nivel de colaboración, pero es un placer trabajar así. Das libertad a quien está a pie de teclado soltando código, y al final, lo importante, es que la documentación y el código no se descuadren, y que el equipo sienta que hay cierta libertad de hacer las cosas.

Y un apunte final: todo lo dicho aquí, sirve para cualquier ciclo de vida: cascada, iterativo, RUP, scrum, etc, etc. Siempre alguien tendrá que empezar a trabajar partiendo de algo que le habrán dado: un documento, una servilleta, un post-it en una pizarra...


 

jueves, 13 de septiembre de 2012

Documentación de Cierre de un Proyecto

Como respuesta a un lector que me presentaba unas dudas, voy a tratar de indicar qué es necesario al cierre de un proyecto y para qué sirve (o al revés: dadas las necesidades, ver qué documentos aplicarían en cada caso). Las metodologías suelen centrarse en el primer caso. Las guías, o las adaptaciones de una metodología, prefiero centrarlas en el segundo. Porque no se trata de hacer documentos (primer caso), sino de resolver necesidades (segundo caso).

En primer lugar, decir que esta documentación que voy a nombrar, trata de cubrir objetivos. Si los objetivos no aplican en el proyecto, o están cubiertos de alguna otra forma, se puede obviar cada documento. Además, el alcance de cada documento debe ser acorde al tamaño del proyecto, o de los riesgos asociados. Estoy harto de repetir por activa y por pasiva, una y otra vez, que las prácticas y los procesos, están al servicio del proyecto. Y no al revés. Y que si no aplica una práctica a un proyecto, y requiere de adaptación, pues se hace: se adapta, y se busca cómo cubrir los objetivos y la esencia del proceso.

Los documentos que harían falta serían:
  1. Informe de cierre. Este documento suele estar en realidad compuesto por una serie de apartados o subdocumentos como:
    • 1.1. Estado final del proyecto
    • 1.2. Buenas prácticas
    • 1.3. Lecciones aprendidas
  2. Aceptación del cliente
  3. Encuesta de satisfacción

 

1. Informe de Cierre.

1.1. Documento de Estado Final del Proyecto.


En respuesta a lo que el lector me preguntaba, este documento contendría la foto final:
  • dónde dejamos la documentación y qué documentación dejamos
  • qué objetivos se tenían, cuáles se han cumplido y cuáles no
  • cumplimiento de estimaciones (esfuerzo, fechas, costes), incluyendo razonamientos y demostraciones de porqué hubo alguna variación.
  • métricas de cierre: demostración de que los objetivos de calidad y de cierre se cumplen. Si es un desarrollo, podemos aquí demostrar cómo el número de defectos encontrados por período de tiempo ha disminuido drásticamente (esta podría ser una métrica válida). Estos criterios objetivos (métricas), podrían suponer el punto de arranque al equipo de soporte que recoja el testigo y arranque la fase de mantenimiento.
  • etc.

1.2. Documento de Buenas Prácticas.


Este documento o apartado recogería la experiencia del proyecto en cuanto a buenas prácticas que se han seguido, y que han tenido éxito demostrado en el proyecto.

 

1.3. Documento de Lecciones Aprendidas


En este apartado recopilaríamos todas las experiencias recopiladas durante el proyecto a todos los niveles:
  • Técnico
  • Funcional
  • Comunicaciones
  • Gestión de equipos
  • Gestión de riesgos
  • Organización de entregas
  • etc.

2. Aceptación del cliente.


Este documento, recopila una descripción del proyecto, nuestra labor y papel en el mismo, y en él el cliente reconoce que acepta los servicios prestados, que son adecuados en alcance y calidad. Es un documento que enviamos al cliente, y éste nos lo devolverá firmado, sirviendo como referencia y credencial para futuros proyectos.

 

3. Encuesta de satisfacción.


Sobre éste ya hablé en un anterior post "La eficacia de las encuestas de satisfacción".

Como me he extendido un poco, creo que habéis cogido la idea. Dejaremos para un post posterior el detallar estos documentos y el cómo adaptarlos a la situación real del proyecto.

Fuente: CMMi

viernes, 7 de septiembre de 2012

Darth Vader: el mejor Jefe de Proyecto

Programador, tu falta de fe en Scrum me resulta molesta
Esta entrada está inspirada en otra bastante antigua, y que nombro al final. Recientemente, he visto otro blog en el que salía  el tema, y me ha parecido gracioso, interesante...y espeluznantemente real. Veamos porqué repasando los 10 motivos principales:

Número 10: Darth Vader prioriza de la forma más brutal.

Cuántas veces vemos a los jefes de proyecto priorizar de forma que si bien nos acerca al éxito, también supone un brutal esfuerzo y sacrificio por parte de todos...incluido (aunque no siempre) el propio jefe de proyecto.

Número 9: Vader toma decisiones basadas en datos objetivos, no rumores.

Un jefe de proyecto como Vader no se preocupa de lo que dicen, él prefiere verlo por él mismo. No escucha, y su liderazgo se basa en la escasa confianza en su equipo.

Número 8: Vader adquiere compromisos, y trabaja duro para cumplirlos.

Así es, el problema es que muchas veces obliga a trabajar a todo el mundo para que los compromisos que ha adquirido, se cumplan. Por desgracia, no todo el mundo sabe tomar la medida de los compromisos que toma...y se mete en más de lo que puede abarcar (en realidad, en más de lo que SU EQUIPO es capaz de abarcar).

Número 7: Vader, cuando es necesario, se aleja para recuperar la perspectiva y descansar.

Ocurrió en las películas, y ocurre en tu proyecto. Tranquilo, si en el momento más crítico, no le ves el pelo a tu jefe de proyecto...es que está "recuperando la perspectiva".

Número 6: Vader gestiona riesgos y expectativas...¡de forma preventiva!

También vimos en la saga galáctica a Vader gestionando riesgos preventivamente. Los buenos jefes de proyecto piensan en sus proyectos a la defensiva, pero los protegen de forma agresiva.

Número 5: Es un tío persuasivo.

Darth Vader lo es. Para eso tiene el poder de la fuerza. Y muy mal genio. Esto también lo comparten muchos jefes de proyecto, que confunden la persuasión con la agresión, la amenaza y la extorsión.

Número 4: Vader elige una metodología, y se mantiene con ella...hasta que no funciona.

Esto es también un perfil de un buen gestor, ser consecuente con las decisiones tomadas, y cuando los métodos no sirven, reevaluar la situación y modificar la estrategia para afrontarlo de forma distinta, cambiando toda la metodología si es necesario. Eso sí, quedaos lejos porque alguien ha de tener la culpa de sus decisiones.

Número 3: Para Vader, no hay problema grande que no pueda enfrentar.

Bueno, y así ocurre con muchos jefes de proyecto. Que abordan problemas y proponen soluciones que dejan perplejos a sus equipos.

Número 2: Nunca es demasiado tarde para hacer lo correcto.

Igual que Darth Vader, que se arrepintió en el último momento, un jefe de proyecto puede decidir en el último instante cambiar y evitar el desastre total tomando la decisión correcta (a veces, precisamente la decisión que su equipo lleva todo el maldito proyecto diciéndole que tome). Por suerte, este cambio del jefe de proyecto en la estrategia, salvará el proyecto y le dará todo el mérito y la gloria.

Número 1: Vader nunca tiene miedo de ensuciarse las manos.


Y tampoco lo tienen muchos jefes de proyecto. Algunos, se las manchan picando código, o rellenando documentos de todo tipo para aliviar a su equipo. Otros, se las manchan de otra forma: culpando a quien no se puede defender, o alejando del proyecto a los que pueden hacerle quedar mal. Después de todo...¿para qué buscar soluciones si pueden encontrar culpables?

Y nada más. Bueno, creo que mis comentarios se han desviado bastante del artículo original, así que podéis leer los dos enlaces que os copio sin que se os repitan mucho los conceptos.

Fuentes:
http://www.geekwire.com/2011/top-10-reasons-darth-vader-amazing-project-manager/
http://www.genbetadev.com/trabajar-como-desarrollador/darth-vader-el-jefe-de-proyecto-definitivo

domingo, 2 de septiembre de 2012

Megathon Windows 8

¿Qué es el Megathon?


El Megathon de Windows 8 es un evento que tendrá lugar de forma simultánea en varias ciudades de España los días 7, 8 y 9 de Septiembre, y en el que se dará formación sobre desarrollo en Windows 8 y la nueva interfaz metro, y al mismo tiempo dará la oportunidad de desarrollar en equipos una aplicación metro para Windows 8, con la ayuda de mentores. Los mejores grupos por ciudad tendrán premio, y luego habrá una final entre los mejores de cada ciudad.

De esta forma, los participantes podrán medir sus aptitudes a la hora de desarrollar aplicaciones, recibiendo interesantes premios (incluso un Nokia Lumia 800) y además podrán participar en los Excellence Labs dónde un ingeniero de Microsoft les ayudará a que su aplicación cumpla con los requisitos de UX, rendimiento, seguridad y accesibilidad claves para publicar en la Windows Store.

Más información en el siguiente enlace.

¿Dónde tendrá lugar? ¿Hay alguno cerca de donde vivo?


Se celebrará en muchas ciudades. Todavía se están cerrando los detalles. La lista de ciudades donde se producirá, la podéis encontrar actualizada en el siguiente enlace.

¿Y puedo encontrar formación gratuita al respecto?


Pues claro. En el siguiente enlace, tenéis todo lo necesario para aprender a hacer aplicaciones con interfaz metro para Windows 8.

¿Estás interesado en participar?


Si es así, no te pierdas las bases del concurso y en el mismo enlace, la lista de jugosos premios: sí, sí, Nokia Lumia 800 para cada uno de los miembros participantes del equipo que gane en cada ciudad.

¿Y si quiero asistir y simplemente aprender a programar?

Pues también puedes asistir a las sesiones técnicas y recibir la formación. Mira en los enlaces que hay en este post, y podrás conocer todos los detalles.

OneNote para Android

Esta aplicación gratuita de Microsoft para Android, no es ninguna novedad, ya lleva algún tiempo en la Play Store de Google. Pero la verdad es que aún no la había probado y es una gozada. Además se integra con mis 25 Gb también gratuitos de almacenamiento en SkyDrive.

¿Qué es?

Pues algo tan simple como crear notas (sí, como un post-it), editarlas, incluir texto, imágenes y viñetas (casillas para marcar). Pero la ventaja está en poderlas editar sobre la marcha, y sincronizarlas en SkyDrive. Podemos crear notas de un viaje particular, con fotos y rutas de visitas, o notas de una reunión, o una simple lista de la compra (y marcar cada artículo comprado).

OneNote es muy simple

Principales Características:

  • Sincronización con SkyDrive
  • Texto, imágenes, viñetas, en una sola nota
  • Tareas pendientes y listas de comprobación
  • Captura rápida con la cámara
  • Acceso rápido a las notas recientes
  • Guarda varios blocs de notas y accede a ellos
Pues eso, que me la he instalado y para ser gratuita, no está nada mal. Se integra a la perfección con Android, me funciona sin problemas tanto en el móvil como en el  tablet, y se sincroniza con la cuenta de Hotmail (SkyDrive).

Para instalar, basta buscar "OneNote" o "Note" en el Market (ahora Play Store).

Que aproveche.

Más información y fuentes:

sábado, 1 de septiembre de 2012

Nueva aplicación SkyDrive para Android

Parece que Microsoft se está poniendo las pilas, y acaba de sacar una interesantísima aplicación para Android. Nada menos que SkyDrive para Android. Y es gratis!

Esta aplicación, a partir de la versión 2.3 de este sistema operativo, permite a los usuarios de dispositivos Android, la gestión de hasta 25 Gb gratuitos en la nube. Poder bajar ficheros al dispositivo, editar o leerlos, y poderlos subir de nuevo modificados a la nube, es una auténtica gozada.

Yo personalmente tengo la cuenta gratuita normal de Hotmail, y disfruto de mis 25 Gb gratis. Pero además, ahora puedo acceder a ellos con total libertad y de forma totalmente gratuita, desde mi tablet o teléfono móvil Android. Una pasada.

No es que sea a nivel de aplicación algo radicalmente diferente respecto a lo que puedan tener otros usuarios de iOs, WindowsPhone o Android. Lo que sí es cierto es que funciona bien (sin problemas ni en mi tablet ni en mi teléfono móvil), y es extremadamente simple de usar. Sin publicidad, sin pantallas de registro o de "compre la versión de pago".
¿Alguien da más?

Algunas fuentes:

Certificaciones Profesionales

Esta entrada la he creado a raíz de un comentario que he recibido en otra entrada anterior. Allí, un lector me preguntaba sobre las certificaciones de software. En concreto, me preguntaba además por la certificación ISQTB.

Un excelente estudio sobre las distintas certificaciones y su utilidad o necesidad, puede encontrarse en este post del blog de Javier Garzás.

He de decir que aunque este estudio me ha parecido un buen trabajo, los resultados desde mi punto de vista se desmerecen porque faltan datos. Es una buena idea tratar de obtener tendencias, pero con tan sólo dos valores es muy complejo tratar de analizar la verdadera situación del mercado en cuanto a estas certificaciones. Animo al autor a continuar con el estudio para ver la evolución de esas certificaciones a largo plazo.

Hay que considerar, que las certificaciones son muy específicas del perfil o rol del profesional. Por ejemplo, no son significativas las certificaciones en gestión para un tester o programador, lo mismo que la certificación ISQTB puede aportar escaso valor a un jefe de proyecto. Es por eso que las certificaciones están asociadas a los roles:
Otro punto a destacar es que las certificaciones no siempre terminan de cuajar. Por muy bueno que sea el nivel exigido, es más importante el prestigio o grado de aceptación en el mercado (número de empresas que los solicitan). Por desgracia, hay acreditaciones muy buenas como TMAP que no terminan de cuajar en su ámbito.

Esto me recuerda al típico problema del mercado: VHS vs BETAMAX; HD DVD vs BlueRay... y así unos cuantos. Al final, es posible que te gastes un dinero en una certificación, y que luego ésta no termine de tener el prestigio de otra cualquiera. Y se trata de una importante inversión en tiempo y dinero.

Hay otra consideración, y es que las certificaciones o bien "caducan", o bien son reemplazadas por otras versiones que las convierten en obsoletas. Es el caso de CMM, que se vio reemplazado por CMMi.

Para terminar de complicar la cosa, en algunos países se crean certificaciones o acreditaciones profesionales de ámbito local (como es el caso de CFCP en Mexico). Eso dificulta la decisión de las personas, que se encuentran entre la duda de certificarse en una cosa u otra. Además, las certificaciones que se presentan al mercado, no suelen cubrir de forma unívoca una acreditación existente, sino que suelen añadir o eliminar elementos de forma que una, no cubre el 100% de otra. Esto no quiere decir que las certificaciones estén mal pensadas o diseñadas, no quiero decir eso. Simplemente, no todas tienen el mismo marco de referencia (áreas de conocimiento o experiencia acreditadas), no tienen el mismo alcance (nacional, internacional), y tampoco tienen el mismo prestigio. Hasta aquí, ya tenemos 3 dimensiones a considerar.

Si a todo esto, añadimos lo que Javier Garzás trataba de identificar en su estudio (la evolución del prestigio o necesidad del mercado de esas acreditaciones a lo largo del tiempo), vemos que la decisión es complicada: ¡4 dimensiones!
  • Ámbito
  • Alcance
  • Prestigio
  • Evolución temporal

En concreto, y ya terminando de responder a mi lector en su comentario, diré que la ISQTB me parece una excelente certificación. Yo personalmente la veo solicitada en múltiples ofertas, y particularmente creo necesario que la gente dedicada al testing, tenga una formación específica. No por programar mejor o peor, se tienen porqué adquirir los skills relacionados con las pruebas. La de TMAP, apenas la veo en ofertas a día de hoy, por ejemplo (y quizás es tan exigente o más que la de ISQTB, lo ignoro).

En una entrada anterior ("¿Hace falta que un tester sepa programar?"), comentaba esto mismo.

Además, hemos de notar que nuestro lector se identifica como "Senior QA", de lo que deduzco que tiene experiencia más que suficiente en el ámbito de las pruebas. ¿Qué valor le puede aportar tener una acreditación en esa área para la que ya tiene experiencia? ¿Le aportaría más valor otra acreditación relacionada con el siguiente escalón en su carrera profesional? Este es otro punto a valorar, ya que me suelo encontrar con situaciones en las que tengo dos tipos de profesionales:
  • Amplísima experiencia, pero ninguna acreditación concreta para el área profesional.
  • Una o varias acreditaciones / certificaciones, pero escasa experiencia.
¿A quién contratarían ustedes? ¿En quién confiarían más? En concreto la ISQTB me parece estupenda, pero un señor con 3 o 4 años de experiencia en pruebas usando prestigiosas herramientas como HP Quality Center o cualquier otra marca, me merece también muchísima confianza (¿quizá más?).

Por hoy, creo que hemos dado suficientes vueltas a un tema, que veo que tiene muchas ramificaciones. Ya seguiremos otro día.