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

How to select a business management software in 7 steps

Once we have decided the kind of enterprise software we are going to use in our organization, it is yet necessary to choose amongst many available alternatives. No matter if we are talking about ERPs, CRMs, Project Management software, … all these markets are quite fragmented and we must decide which provider better suits our needs. But how to do it? Is there a proceeding to reduce the risks of making a wrong decision?

There are no magic recipes but in this post I will explain you how we choosed the CRM in our organization. Previuously we had decided to use a Cloud based CRM but there were yet many options in the market.

1. Organize a team that represents the key affected areas

Any business management software is a tool that affects many areas of an organization. In fact, they are designed to work in processes instead of functional departments. So, it is important to involve in the selection process users of the main areas affected by the new tool.

For instance, in an ERP I would try to include at least, people from Operations, Sales, Finance, Production, Warehouse and IT. The team should be leaded by a Project Manager with experience and knowledge of the company and the industry. In a CRM I would like to have at least people from Marketing, IT, Sales and Operations.

In both cases the composition of the team would depend on the modules of the tool that we want to implement. These management tools usually include many modules and every organization must decide which ones are necessary in its case or simply which ones they want to implement in a first stage.

2. Decide what is important for you

It is important to consider your specific situation and decide what aspects of the new tool are more important to you. Everything does not have the same weight when taking decisions.  For instance, in the selection process we followed to choose the CRM of my company we analyzed:

  • Price
  • Strength of the manufacturer
  • Maturity level of the product
  • Backup offline (availability)
  • Data protection compliance (housing)
  • Processes automation
  • Activity audit
  • Workflows customization
  • Level of possible customization to our needs
  • Storage capacity
  • Possibility to implement the tool without external providers
  • Availability of external support (manufacturer or consultants) if needed.

Everyone of these criteria must have assigned a weight according to its relative importance. Indeed, maybe some of them can be mandatory.

3. Analyze the market to find posible candidates

This is a market research. Now that the team knows what is important for the organization, let them explore the market to find possible candidates.

In this phase it is important to read comments from current users of possible candidates on specialized web sites, talk to consultants, contact the manufacturers, contact to other companies who are using the soft, …

Let the team work

4. Let the team evaluate the candidates

After the research, the team should have some meetings to exchange views and to decide the final candidates that they will assess.

Once they have the group of candidates, one member of the team can present one candidate to the rest of the group, explaining the results of his research. After that, every member of the team should evaluate the candidate according to the criteria identified in point 2.

Finally, every candidate will have a final score based on the average points awarded by the team.

5. Make your proposal to the Direction

In this moment the team is ready to present its results to the managers of the company. The whole group or the members who are more skilled doing presentations should conduct one introduction to the performed study and its results. As a result the team will recommend the implementation of one of the applications studied or consider that there is nothing in the market that suits the needs of the organization.

In the second case, the requirements or the criteria of the organization should be reconsidered. Another possibility could be considering the development of  a customized software for the company. But this is out of the scope of this post.

The company management may accept the recommendation of the team or may consider that a further research must be done to be showed in another presentation.

Once the direction of the company accepts the proposal of the team, the ideal case would be to have a first (or preferred) option and a second option (or B plan).

6. Negotiate with the main candidate

It is important to keep a second option available until the end. This provides your organization some extra bargain power with the providers. They must know that if there is no agreement with them the company has other options.

I am not going to detail in this post how to negotiate with potential vendors. I would need a new post. But it is important to assign the role of main negotiator to a member of the team with experience in these situations.

If you do not achieve an agreement with the main candidate, start your B plan and give the opportunity to the second candidate.

7. Choose

Finally, if you consider that you have achieved a deal with the potential provider that satisfies your needs, propose the agreement to the Direction of your company with your reasons to choose this vendor. And let them decide.

How to select a business management software in 7 steps

¿Qué es la “Extensión de Software de la Quinta Edición de la Guía del PMBoK”?

Recientemente el PMI ha publicado una extensión de software de la quinta edición de la Guía del PMBOK® (en inglés).

La Guía del PMBOK®, es un conjunto de buenas prácticas internacionalmente reconocido para la dirección y gestión de proyectos. La quinta edición se ha convertido en un estándar reconocido por ANSI (y publicado como anexo en la propia guía).

Elaboración conjunta PMI-IEEE

La “Extensión de Software de La Guía del PMBOK®” ha sido elaborada conjuntamente por el PMI y por la IEEE Computer Society. Se basa en 5ª edición de La Guía del PMBOK®, manteniendo su estructura, procesos y coherencia en el discurso pero incorpora elementos propios de los proyectos de desarrollo de software para adaptarse a sus características específicas como los métodos de desarrollo adaptativo, que permiten aprovecharse de la naturaleza específica del producto de estos proyectos: las aplicaciones. En general, se trata de productos que permiten la fácil y rápida elaboración de prototipos y el desarrollo incremental.

Público objetivo: todo el involucrado en proyectos de TI

Esta “Extensión” está escrita pensando en organizaciones y equipos que se enfrentan tanto a proyectos de desarrollo como de modificación o de implantación de software y cubre tanto proyectos llevados a cabo internamente como la gestión de proyectos externalizados.

Dado que hay aspectos que no varían en un proyecto de software respecto de uno cuyo producto sea distinto, en todos los apartados en los que no hay especificidades en un proyecto de software se deriva al lector al punto concreto de “La Guía del PMBOK®”.

Por el contrario, cuando hay técnicas o situaciones concretas y específicas de los proyectos de software éstas se mencionan o referencian en la propia “Extensión”. Como ejemplo, uno de mis intereses personales es la Calidad en los Proyectos. En el capítulo 8 del libro se trata este tema y se hace referencia a técnicas de SQA (Software Quality Assurance) y SQC (Software Quality Control) junto con estándares del IEEE aplicables a cada caso, como el IEEE Standard 829 (Software and System Test Documentation) o el IEEE 1008 (Unit Testing).

Habrá que ampliar la librería

Habrá que ampliar la librería … (Fotografía de neoprolog bajo licencia CC BY 2.0)

¿Consideráis útil esta aproximación del PMI frente a los entornos ágiles alternativos?

¿Habéis tenido oportunidad de leer el libro? ¿Qué opináis? ¿Consideráis útil y acertada su publicación o bien pensáis que no tiene sentido adaptar “La Guía del PMBOK®” a proyectos de software disponiendo de entornos ágiles como Scrum o Kanban?

¿Qué es la “Extensión de Software de la Quinta Edición de la Guía del PMBoK”?

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