4 Reasons to prototype in mobile app projects

There are many situations when creating a prototype of the final product of a project is not possible, because of the costs, the timing or just because of the nature of the product. But if you have the chance I recommend you to do it.

Prototyping in software projects

Currently I manage projects whose goal is the creation of mobile apps for different kinds of clients. The product of our projects is a software and software by its nature allows prototyping and progressive development.

There are different kinds of prototype solutions for mobile apps. Frequently we use Marvel and Flinto. They both allow to create very high fidelity prototypes that can be tested in the intended devices as if they were the real app.

Why is this so interesting inside the project of creation of an app?

1. It is very frequent that the client (and/or the product owner) doesn’t know exactly how the final product should look like, exactly what kind of functionalities should it include and how should they be presented to the app user.
The prototype allows the client to rethink the product if necessary as the result of its interaction with the prototype.

2. It is a lot cheaper and faster to introduce changes in a prototype of this kind than in the final app (product).

3. Design is fundamental in a mobile app. This allows designers to go always at least 1 sprint ahead of developers during the project. If you can create a first project just for prototyping it will be even better.

4. As the designs are realistic, all the assets created for the prototype and approved by the client can be used by the developers during the following phases of the project without any additional work from the designers.

What is your opinion?

What do you think? Do you prototype in your projects? What kind of tools do you use? Do you know any more reasons in favor of prototyping? And against?
I would like to know your comments.

4 Reasons to prototype in mobile app projects

Funciones de una PMO en una organización ágil

Tradicionalmente se ha considerado una PMO (Project Management Office – Oficina de gestión de proyectos) como una entidad encargada de la centralización y coordinación de proyectos de la organización: coordinando recursos compartidos entre proyectos; identificando metodologías, buenas prácticas y estándares; formando y mentorizando a los Project Managers o coordinando la comunicación entre proyectos. Sin embargo, en una organización ágil este paradigma debe ser modificado en parte. En el “agilismo” hay una serie de principios que se tratan de respetar: personas sobre procesos, software que funciona sobre documentación, colaboración con el cliente sobre el contrato y respuesta al cambio sobre planificación.

Así pues, en una organización ágil, la PMO no es una entidad controladora y perseguidora de estándares. Más bien se debe convertir en una entidad facilitadora para los diferentes equipos de trabajo y que promueva el aprendizaje continuo.

Su rol se debe reorientar hacia otras funciones que aporten más valor y sean coherentes con la filosofía ágil:

  • Mentorizar y proporcionar servicios de coaching a los equipos de trabajo y a los scrum masters.
  • Desafiar continuamente a los equipos de trabajo para que apliquen la mejora continua en sus prácticas ágiles.
  • Ayudar con los informes de seguimiento: determinando qué métricas utilizar y ayudando a los equipos a concentrarse en la entrega continua de valor. Todo lo que no proporciona valor es desperdicio.
  • Gestionar el WIP (Work In Progress): Todas las organizaciones tienen un ratio de ‘trabajo en curso’ con el que trabajan de forma óptima. La PMO ágil debe vigilar que su organización se encuentre lo más cercana posible al valor óptimo. Se puede incorporar un nuevo proyecto a la cartera de proyectos en curso sólo cuando se ha finalizado un proyecto de esfuerzo similar que haya liberado recursos de la organización. En cuanto a las herramientas, podemos apoyarnos en aquellas que nos ayuden a planificar y hacer un seguimiento de los proyectos (herramientas visuales para definir y seguir los backlogs, controlar el WIP, etc.).
  • Reducir el desperdicio (muda en términos ‘lean’): ayudando a los equipos de trabajo a identificar y eliminar todas aquellas actividades y artefactos que no aportan valor.
  • Coordinar equipos: especialmente cuando tenemos miembros que trabajan de forma parcial para varios proyectos de forma simultánea.
  • Fomentar la comunicación entre equipos: favoreciendo que las buenas ideas y buenas prácticas identificadas por un equipo sean conocidas y aprovechadas por otros. En este ámbito, es útil el uso de herramientas para facilitar el rápido intercambio de información entre los miembros del equipo (que cada vez de forma más habitual trabajan distribuidos). Dicha información debe ser clasificable para su rápida recuperación posterior. Necesitamos herramientas de colaboración tanto síncronas (chats, teléfono, Skype, etc.), como asíncronas (correo electrónico).
  • Proteger a los equipos de proyecto: defendiendo y explicando sus necesidades a otros departamentos (personal, CEO, etc.) cuando deben tomarse decisiones que afecten a la ubicación de los miembros de un equipo en la oficina, la adquisición o eliminación de herramientas de trabajo, etc.

Y todo esto sin olvidar que estamos hablando de trabajos intensivos en conocimiento, en los que el principal activo son las personas, los profesionales que llevan a cabo el desarrollo. Por ello, es fundamental dedicar el tiempo necesario a hablar con el equipo y con los project managers; actuando en cada momento según lo requiera la situación: a veces sólo preguntando y ayudando a que el propio equipo encuentre las soluciones, a veces siendo más expeditivo y marcando el camino a seguir y en otras ocasiones sólo escuchando.

En resumen; en una organización que busca ser ágil el rol de la PMO debe ser, como siempre, apoyar la estrategia corporativa. Esto no cambia. Sin embargo, si la estrategia pasa por la agilidad, la PMO debe pasar a ser una entidad más orientada a aconsejar y orientar que a controlar. En lugar de focalizarse en garantizar el cumplimiento de los calendarios y presupuestos de proyectos, debe poner más énfasis en que los proyectos proporcionen el máximo valor posible al negocio o a los clientes finales (sin que esto signifique que calendarios y presupuestos dejen de tener que cumplirse).

En cualquier caso, no todo es blanco o negro; predictivo o ágil. Cada organización debe buscar su camino entre las metodologías predictivas de gestión de proyectos y los modelos más ágiles y muchas veces la opción más adecuada estará en el medio. La PMO deberá ser coherente con la opción escogida por su organización y apoyar al máximo la implementación de su estrategia.

Este post fue publicado primero en el blog de Slashmobility.

Funciones de una PMO en una organización ágil

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