martes, 15 de septiembre de 2015

I cleared my PMP exam yesterday!!!

I am so glad to announce that i passed my PMP exam yesterday on my first try, a good gift for myself in my local city anniversary.I wouldn't success without the feedback received in this forum, all lesson learned inputs helped me a lot, so i will leave my personal experience here. 
1. I read the PMBOK twice 
2. I read in deep Rita prep book three times. 
3. Answered hundred of online free tests (Most of them mentioned in his group, Thank you all..) 
4. I took a preparation course some time ago with two excellent teachers, I want to special thank to Rocio Zelada and Cecilia Boggi for the classes. 
5. I participated in one PMP prep experience session with my colleague Alvaro Pozo that help me to have the initial guide in how to prepare for this moment, Thank you Alvaro... 
6. I prepared my self every day by two hours during 5 months, focusing in understanding all PMIs and trying not to memorize all basic concepts. 
7. I reviewed Saket Bansal's videos very helpful for most of the concepts. 
8. I reviewed as well Linda Fiorenzano's videos very direct concepts for PMP 
9. I was selected by the audit which i know the majority had been selected last months, i just prepared and sent the required support docs and they approved it in the following 5 days, I want to special thanks to Lucia Argandona for helping me in this approach. 

I want to advice to the people that are going to take the test not to stress to much, i couldn't sleep too much the day before the test so i arrived little sleepy to the test center and couldn't have the chance to bring with me coffee or candies (so take your previsions), the personal didn't have them in the center, and another thing was that they used to enter to the room every 15 min that distracted to me a little, the time i think was just enough to answer all questions with just 5 min left to review marked questions, the real exam was not so quite different from the tests i found, but most of them need to understand how to handled the scenarios more than answer general concepts. 

martes, 25 de noviembre de 2014

Daily standup meeting tips

I want to share some tips for improving the daily meeting ceremony. I will start defining the three basic rules.
  • Every team member report what have being done yesterday
  • What are you plan to during the day
  • What is blocking your task progress
First my advice is to place the daily meeting at the first hours of the work day, since we share our progress and problems so all team can support and assist any team member. Every team member should be at least 5 minutes before meeting starts, so we avoid interrupting any member report. We have a 15 min time box for this meeting as maximum if some specific issue is raised we should discuss it offline with only the persons involved (time is gold and we don't want to waste the rest of the team). 

We also must follow an order for the reports we can use the table place order starting from the right, when someone starts should say his name and briefly the working progress (percentage of the task) and when he/she expects to complete it, we must avoid being too general or detailed, when he/she finish should say something like "That's it" , "That's me" or "That would be my day" so remote people can be aware that is his turn to continue.

One good practice is to review during this meeting the task board, so we can have a clear picture of the current work progress, we can display the burn down chart and review the remaining sprint resources hours, then we can identify the people that needs more help or if it would be necessary to notify some risk in order to complete the committed user stories to stakeholders.

In my experience I think would be great to include the PO in this meeting if it is possible so he/she is committed as well with the team and known the current progress.

Hope this will be helpful for your teams. Please don't hesitate to leave your comments/questions.

jueves, 6 de noviembre de 2014

Struggling with our Product Owner

I have been working for many years in many software companies and I could realized that most of them had the same issue with the Product Owners, I will list a few of them.

·  Providing not much more than a high level, ordered Backlog and availability to the team for      questions or clarification was extremely limited. 
·  User Stories were developed, but were inconsistent and refined too late—often in the middle     of the Sprint. 
·  Backlog grooming (maintenance) was inconsistently practiced, if practiced at all. 
·  The Backlogs themselves were inconsistent across teams—making organizational strategic         planning and overall progress measurement very difficult. 
·  Forward-looking release planning was nearly avoided. 
·  Little time was spent ‘connecting’ external stakeholders to the performance, efforts, and            dynamics of their teams.

Is all of the above points seems familiar in your organization?. I will give some tips for improving that issues so we can deliver a high product in schedule and budged.
I think one of the more appreciated value that PO should has is the commitment with the team itself, I know that many times PO has a lot of limited time since they have all day meetings, but when the team needs him, he always should be available to respond to it. One good practice I found for that approach was to set daily meetings that we called collaboration meetings, in that slot of time we use to take all possible advantage from our PO, like grooming the US, clarifying the acceptance criteria, demo the feature progress (Dev & QA) so in that way we receive the necessary feedback in time, so we don´t need to wait at the sprint review every end of the sprint. If this is not possible for time availability reason, we can set a different time for a couple of minutes with the PO for at least demoing and review the team´s progress, for all the rest we can send him the questions or clarifications requirement through email or im. If this really is not possible we should escalate the problem with the PO´s chief.

So the key for having a good communication and collaboration is to have our PO committed with the team, as everyone knows that at final release all team (Scrum Master, Product Owner and team members) is in play, everyone wins or everyone lose. 

Hope this can help a little in your current organization.

viernes, 24 de mayo de 2013

Diferencias entre Product Owner y/o Scrum Master y Project Manager

En realidad el rol como tal de Project Manager no está considerado dentro de Scrum. Lo que reemplazaría al rol de Project Manager seria en todo caso el Scrum Master y el Product Owner, por su parte el scrum master tiene como principal función el de identificar y mitigar los impedimentos del trabajo del equipo, en vez de tener un perfil directivo mantiene un perfil colaborativo, se asegura que todo el equipo siga de forma adecuada todas las ceremonias y directrices que conlleva Scrum y por ultimo asegura que todos tengan buena comunicación y los entregables se terminen a tiempo. Por su parte el Product owner se encarga de crear el product backlog con todos los requerimientos ordenados y priorizados, trabaja al lado de los stakeholders para poder aceptar y aprobar los entregables de cada sprint. El Project Manager por su esencia abarca más áreas donde controla todo el tiempo riesgos, alcance, costos, adjudicaciones, etc. Recuerden que en Project Management se enfoca más en la planificación mientras que en Scrum se tiene más en cuenta la respuesta al cambio constante donde se trabaja de cerca con el cliente para poder acelerar la entrega final del producto (en mi opinión una gran ventaja en especial en el área de desarrollo de software).

Mi consejo para las personas de desempeñan el rol de Scrum Master es que traten de hacer un mix en sus proyectos, teniendo en cuenta la buena planificación así como implementar Scrum para tener una respuesta al cambio eficiente, con personas comprometidas en su trabajo (Autogestionados).
Si alguien tiene un aporte no dude en escribirme o dejar sus comentarios, todos serán bienvenidos para así poder enriquecer el conocimiento conjunto con experiencias rescatadas en el mundo real.

miércoles, 6 de marzo de 2013

Scrum Bolivia Day 2013 Coming Soon

Segunda versión del Bolivia Scrum Day a llevarse a cabo el 30 de Marzo, en el Hotel Camino Real en la ciudad de Santa Cruz de la Sierra. Acá les dejo el contenido de las presentaciones y los nombres de los expositores:

Sábado 30 de marzo de 2013

8:00-8:30 Acreditación
8:30-9:30 Desafíos del manager en la era ágil - Federico Zuppa
9:30-10:30 Los 10 mandamientos de TDD – Hernan Wilkinson

10:30-11:00 Break
11:00-12:00 Good Practices in Software Test Automation – Camilo Ribeiro

 12:00-14:30 Break
14:30-15:30 Craftsmanship – Desarrolladores ágiles, profesionales y responsables - Carlos Peix
15:30-16:30 Why do we use Scrum? – Juliano Ribeiro

16:30-17:00  Break
17:00-18:00 Disfunctions of Scrum: how to avoid them and extract the most from Scrum – Samuel Crescêncio
18:00-19:00 ¡No estimarás!  – Thomas Wallet

A todas las personas que puedan asistir les recomiendo que sean puntuales. Solo un día al año podemos contar con la experiencia de profesionales con vasta experiencia en empresas de software en el exterior.

Para mayor información dirigirse al link

viernes, 1 de junio de 2012

Consejos sobre testing de aplicaciones

Cuando se desarrolla un proyecto de software nunca se debe subestimar el plan de pruebas. Este apartado es crucial, tanto para ofrecer la calidad que espera el cliente bajo los criterios que se acordaron en la definición del proyecto como para ofrecer un software robusto libre de errores. Como desarrolladores tenemos que procurar que nuestro código esté libre de bugs y cumpla los requisitos funcionales.

Cuando definamos un plan de testing o QA es importante recordar algunas de la lecciones que prácticamente todos los desarrolladores que hemos participado en un plan de pruebas hemos aprendido de forma práctica incluyendo algún quebradero de cabeza en su momento.

Un punto clave que también debe tener muy presente es el de hacer pruebas de TDD (Test driven development) para la creación de unit tests; para más información visitar el siguiente enlace
Otro punto muy importante es el manejo de subversión , el cual ayuda a tener todo el código sincronizado; la posibilidad de que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas maquinas fomenta la colaboración. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay motivo para temer por que la calidad se vea afectada, si se hizo un cambio incorrecto, simplemente deshaga el cambio, una muy buena interfaz es la de TortoiseSVN.

A continuación unos puntos claves que todo desarrollador debería tener en cuenta al momento de implementar una aplicación:

  • Aunque el proyecto vaya mal en tiempo o en costes, nunca hay que recortar el tiempo de pruebas. Nos tenemos que asegurar siempre que el proyecto que entreguemos esté libre de errores, si recortamos en pruebas y además vamos apurados estaremos cometiendo muchos más errores de los habituales.
  • Lo más importante que tenemos que probar son los requisitos funcionales que definen el alcance del proyecto. En definitiva, esto es lo que conforma la parte del negocio que fijamos con el cliente y los usuarios como entregable y tiene que satisface sus necesidades.
  • Hay que probar el desempeño de la aplicación sea el esperado por el cliente un punto a medir son las pruebas de carga, es la única forma de que probemos al 100% que toda la parte técnica funciona correctamente.
  • También es muy importante antes de lanzar el producto realizar la fase de pruebas de regresión donde se revise que cada componente funcione correctamente (después de haber corregido todos los errores encontrados previamente) 
  • La gestión de configuraciones y versiones es un apartado fundamental del alcance y la gestión de cambios. No debemos descuidar este apartado ya que nos podrá acarrear problemas a corto/medio plazo.
  • Siempre que corrijamos un error debemos volver a testear todo. Es fundamental asegurarnos que no se haya roto nada por otro lado.
  • Aunque parezca obvio, nunca hagas pruebas en el entorno de producción. Invierte lo que haga falta en un entorno de pre-producción sólido y lo más parecido posible. Es una inversión que te salvará de muchos apuros y te permitirá asegurar que no habrá diferencias entre las pruebas y cuando se suba definitivamente a producción.
  • Es recomendable tener especialistas en testing o un equipo dedicado al QA en tu empresa. Testear no se debe tomar a la ligera ni ser un mero tramite burocrático para declarar la tarea como finalizada. Es fundamental que se haga un trabajo completo probando cada funcionalidad. Si no es posible tener un equipo sólo dedicado a eso, es conveniente que los encargados en ese momento de testear sólo se dediquen a probar y reportar errores.
  • Es muy recomendable involucrar a los usuarios claves que han participado en la definición de los requisitos de la aplicación. Mientras se prueba pueden obtenerse un importante feedback de usabilidad. Para lo cual uno debe presentar entregables a los clientes para recibir el Ok y poder seguir avanzando en el desarrollo, es una práctica muy importante que aconseja la metodología ágil.
  • Es recomendable tener herramientas que nos aporten a la comunicación de desarrolladores con gente de calidad. Para agilizar la corrección y que no se nos pase ningún bug. Ej. Xplanner, V1, etc. Ya que cuando solo usamos el envió de mails corremos el riesgo de omitir información muy importante para la corrección de errores.

lunes, 21 de mayo de 2012

Agile Open Bolivia

Para los que tengan la oportunidad de asistir a este gran evento a realizarse el día Sábado 2 de Junio a hrs. 08:00 AM en nuestra querida ciudad Cochabamba. El lugar es la Universidad Católica Boliviana ‘San Pablo’.
Es bueno estar en contacto con la comunidad Ágil de Bolivia, les recomiendo que asistan para poder compartir experiencias y seguir aportando a nuestra comunidad.

Para más información referirse a la siguiente página: