Using a Blog to support your Project Management Information System

Last summer I started reading “Social Media for Project Managers”, from Elizabeth Harrin. There were many concepts I already knew and some tools I was already using but the book gave me some ideas to use those tools for new purposes. One of them was using a Blog as a part of the PMIS (Project Management Information System) as a project log.

Blog image from http://www.sxc.hu/profile/svilen001
Blog image from http://www.sxc.hu/profile/svilen001

How we use a blog in our project

We started using a blog in a software development project I am managing. The team is young and they are used to these kind of tools so it was not difficult to convince them to start blogging everyday their project activities.

As we all are not working at the same office and also some team members have different working hours, we thought that this tool would help us with its universal accessibility (well, in fact we have limited the access to the blog to the project stakeholders).

These have been the results

After some months of work we have:

  • A project log, explaining what we have done and why we have done it that way. A knowledge repository.
  • A tool useful to train new team members is they are needed in the future.
  • A tool to collaborate. We can receive feedback from the community of project stakeholders through their comments at the blog posts.
  • A tool to build relationships between the team members, as not all of them are collocated.

Some difficulties and risks

But not everything has been easy. We have had establish some ground rules about what to post and how. As every stakeholder may read a post it is not easy to decide the kind of information to include as not all of them have the same needs.

There are some posts that are for internal use (just for the team members), some others are for everybody involved in the project and we are working now in the weekly project status reports, for the project sponsor and the final product users.

As everybody can read every post, the tool we use to filter are tags. If you want to read a project status report you must look for “status” tags in the blog. When a team member looks for some information about the data base he must use some of the tags we have previously agreed to use for these issues, and so on.

What’s your opinion?

What about you, are you using any social media tool to support your projects? What has been the most difficult challenge you have faced to deploy it? What have been the benefits for the project? Any negative result?

Using a Blog to support your Project Management Information System

Validación y pruebas de servicio. Tests unitarios.

Nuestro equipo de desarrollo de aplicaciones es joven, con ganas de probar y aprender pero también con limitada experiencia en algunos temas. Uno de los que me preocupa últimamente es el control de los cambios de las aplicaciones que tenemos en producción pero que seguimos desarrollando y evolucionando.

No es lo mismo ir cambiando versiones de una aplicación mientras está en desarrollo que hacerlo una vez ha pasado a producción, con las repercusiones que puede tener un corte de servicio o un fallo en una funcionalidad.

Una de las aplicaciones que hemos desarrollado controla una línea de producción de equipos en nuestra planta. Desde que la pusimos en marcha el departamento de Producción ha podido ir incrementando considerablemente su ritmo de fabricación semanal, de forma que cualquier corte en el servicio, por pequeño que sea, ahora tiene gran repercusión.

En otra entrada ya explicaré cómo tenemos implementada la gestión de cambios en la aplicación pero ahora lo que me interesa es lo que en ITIL se denomina Validación y Pruebas del Servicio, dentro del proceso de Transición del Servicio.

Tras haber aprobado un cambio es preciso, por este orden y a grandes trazos, definir los requisitos que debe cumplir la solución, diseñar la solución y las pruebas que deberá pasar antes de entrar en producción y, lógicamente, desarrollarla.

Modelo de desarrollo y test "en V"
Modelo de desarrollo y test “en V”

Siguiendo el Modelo V, empezaríamos las validaciones con pruebas unitarias, seguidas de pruebas de sistema y acabando por las pruebas de integración.  También será preciso hacer tests de regresión, para verificar no sólo que la entrega cubre los objetivos del cambio planificado sino que todo lo que nuestra aplicación hacía bien antes de la entrega lo siga haciendo después.

Cuando las aplicaciones se hacen grandes verificar la cobertura de las pruebas respecto a los requerimientos y/o las líneas de código no es trivial.

Según se desprende del modelo en V, una buena base desde la que construir la aplicación deben ser los test unitarios. En el BCNDevCon12 tuve oportunidad de asistir a un par de master sessions en las que se explicaba de forma práctica la metodología TDD (Test Design Driven). Este método de desarrollo nos asegura que nuestro código va a cumplir con los requerimientos.

En pocas palabras se trata de diseñar los tests que deberá pasar nuestro código antes incluso de desarrollarlo, en base a cada uno de los requerimientos que nuestro cliente nos haya planteado. Una vez diseñado el test hacemos el mínimo código para cumplir con el requerimiento y lo probamos contra nuestro test.

Si el resultado es positivo pasamos al siguiente requerimiento y su test asociado. Si es negativo rehacemos el código y volvemos a testear hasta que lo pase.

Según vamos incorporando requerimientos deberemos ir refactorizando nuestro código y volviéndolo a probar contra la batería de tests. Todo el proceso está muy bien explicado aquí.

En otro post hablaremos de los tests de sistema y los de integración. Me interesa mucho encontrar herramientas para automatizarlos en el marco de desarrollo de aplicaciones web. Pero, como decía,  eso será en otra entrada. ¿Qué métodos y/o herramientas utilizáis en vuestras pruebas unitarias? ¿usáis TDD? ¿con qué resultados?

Validación y pruebas de servicio. Tests unitarios.

El proceso de test en el desarrollo de software

La calidad del software que generamos para nuestras organizaciones es muy dependiente del esfuerzo y tiempo dedicados a su testeo.

No obstante, ese esfuerzo debe ser objeto de un análisis crítico que asegure que los resultados obtenidos compensan el coste dedicado. Por otra parte se debe ser consciente de los riesgos asumidos al limitar el esfuerzo de test. Como en muchas otras situaciones de la vida, se trata de buscar el equilibrio.

De acuerdo con el ISTQB el proceso de test debe seguir las siguientes fases:

  • Planificación y control
  • Análisis y diseño
  • Implementación y ejecución
  • Evaluación y reporte
  • Cierre

 

Estas fases se suceden secuencialmente, si bien el control debe seguirse durante todas las fases del proceso, no sólo en la planificación inicial.

1. Planificación y control

Debe iniciarse, idealmente, lo antes posible dentro del ciclo de desarrollo del software. Es preciso completar un plan de test que incluya:

  • recursos necesarios,
  • tiempo estimado,
  • servicios, medios adicionales,
  • herramientas, …

El testeo exhaustivo es, por lo general, imposible. Es preciso, por tanto, definir prioridades y analizar los riesgos de omitir determinados tests o de limitar su intensidad o alcance.

2. Análisis y diseño

En esta fase se determinan las técnicas de test a seguir, alineadas con la estrategia definida en el paso anterior, se definen los casos de test y el calendario o secuencia. En paralelo se deberá poner en marcha la infraestructura necesaria para realizar los tests.

3. Implementación y ejecución

A partir de los casos de test definidos de forma lógica en la fase anterior se derivarán y ejecutarán casos de test concretos.

En esta fase es preciso seguir un protocolo de test que incluya las partes a testear, las personas asignadas, los tiempos y calendarios, la extensión de cada test a realizar y los resultados esperados.

Además, es fundamental realizar un registro de los resultados.  Éstos nos pueden llevar a plantearnos si los posibles errores encontrados están dentro o fuera del objeto del test y, consecuentemente, a replantearnos el protocolo diseñado y seguido.

Al mismo tiempo, los errores encontrados deben ser documentados, priorizados y asignados a los desarrolladores para solucionarlos.

En otra entrada entraré en mayor detalle pero aquí quiero comentar la importancia de agrupar los casos de test en secuencias y/o escenarios y de realizar primero los llamados “smoke tests” que permitan verificar la bondad de las funciones principales antes de entrar en  casos más detallados y completos (que no tienen sentido si los tests básicos no han sido superados).

4. Evaluación y reporte

En esta fase empezaremos por evaluar si los criterios de finalización de los tests han sido alcanzados.

En caso negativo será preciso analizar si se ha debido a que algunos casos de tests han tenido que ser bloqueados o si es preciso añadir más casos de test.

Para tomar una decisión razonada, como siempre, habrá que tener en cuenta tanto los riesgos asociados con no añadir más casos de test como los costes (dinero y tiempo) de hacerlo.

En cualquier caso, finalizaremos esta fase con un informe que incluya todos los resultados y las conclusiones y decisiones tomadas.

5. Cierre

Esta fase, desgraciadamente, suele ser olvidada en, muchos proyectos.

La experiencia obtenida durante el proceso de test debe ser analizada y puesta a disposición de otros proyectos. En otro post de este mismo blog ya he hablado sobre ello dentro del contexto de la gestión de proyectos en general.

La documentación y aplicación de los resultados de una evaluación crítica de las actividades realizadas durante el proceso de test, considerando esfuerzo en relación a resultados, nos llevará a la mejora continua.

Para acabar, otro punto a tener en cuenta en esta fase final es la necesaria conservación del “testware” (casos de test, protocolos, infraestructura, herramientas) para su uso posterior cuando nuestro cliente nos pida cambios o cuando encontremos nuevos errores ocultos en nuestra aplicación.

El proceso de test en el desarrollo de software