lunes, 11 de abril de 2022

¿Realmente damos mayor importancia a los individuos e interacciones sobre procesos y herramientas?

 Algo que me llama mucho la atención, es como algunas organizaciones que predican agilidad, y tratan de transmitir las mejores practicas de los marcos de trabajo ágiles que adoptan, les cuesta demasiado promover el bienestar de los equipos e individuos, sabemos que la comunicación, colaboración, buen trabajo en equipo y asegurar que cuenten con un ambiente propicio para llegar a ser equipos de alto desempeño es clave para asegurar el éxito de los proyectos.

Sin embargo, pude evidenciar según mi experiencia que muchas organizaciones incorporan estos puntos como valores en su cultura, lo cual motiva a las personas, creando un sentimiento de pertenencia y compromiso, generando lazos estrechos más allá de simplemente ser compañeros de trabajo sino creando verdaderas amistades con las cuales se puede contar tanto dentro como fuera de la oficina. Para esto algo que sirve bastante es recolectar continuamente el feedback entre pares, y no solamente buscar esto a la hora de medir el desempeño de las personas (el famoso feedback 360°).

Por otro lado, pude evidenciar muchas organizaciones donde la cultura se contrapone lamentablemente a tener a las personas en primer lugar, muchas de estas acostumbradas aun al mando y control, ojo que según el contexto no está mal, sin embargo, sin llegar a extremos como micromanagement, donde existe una total desconfianza del trabajo que realizan los miembros de equipo. Si bien los jefes de proyecto son llamados a seguir las practicas, principios y valores agiles, en el fondo seguimos realizando un fake agile (agile cosmético). Por mencionar algunos ejemplos, los gestores de proyectos siguen decidiendo por el equipo, realizan un push de las tareas en la planificación, cuestionan a cada momento la estimación que realizan los equipos, confrontan y cuestionan toda decisión de las actividades que realizan dentro de la iteración, ejerciendo mando y control en todo momento, lo que puedo inferir en estos casos es que temen perder el control de los equipos, tratando de realizar un seguimiento en todo momento del avance del equipo, con una visión tradicional de gestión de proyectos.

Muchas veces me paso que cuando incitas a los gestores a medir el nivel de satisfacción de los miembros de equipo, o realizar feedback continuo o incluso les sugieres realizar de forma eficiente las practicas agiles, la respuesta que obtuve alguna vez fue, no importa como hagan su trabajo solo quiero ver resultados, es lo único que al final interesa.

Esto mas que nada pude evidenciar cuando estos roles de gestores “agiles” son tomados por desarrolladores senior, que al pasar el tiempo fueron promovidos para dirigir al equipo, si bien es cierto que es un plus que el gestor tengo un fuerte perfil técnico (lo que muchas organizaciones buscan como requisito) no debería ser lo único a tomar en cuenta al momento de posicionar a las personas con ese rol, mi sugerencia es dejar estas personas que sobresalieron técnicamente como lideres técnicos de equipo, y asegurar que el verdadero líder en servicio al equipo tenga un balance en habilidades blandas como duras.

Les dejo la siguiente consulta para que según su experiencia la respondan.

¿En las organizaciones donde pudieron trabajar, existía o existe una cultura de People First?

¿Se realiza el feedback continuo entre pares dentro de la organización? Identificando oportunidades de mejora y realizando celebraciones por las personas que se destacan de alguna manera.

¿Se tiene confianza en los equipos? ¿Se permite la auto gestión? ¿Los miembros de equipo se tienen confianza? ¿Existe colaboración entre equipos y buena comunicación?

Espero que estas preguntas les permita reflexionar y promover en sus equipos los valores, principios y buenas prácticas agiles que tanto buscan las organizaciones, pero que muy pocas están dispuestas a permitir por muchos motivos circunstanciales.



sábado, 12 de junio de 2021

Release Roadmap en JIRA

Cuando tuve la oportunidad de acompañar a una de las organizaciones en su viaje hacia la transformación ágil, una experiencia que tuve con los C-Level fue el hecho de solicitar visualizar la ruta critica de los proyectos.

Nosotros como área de Agentes de cambio, mostrábamos en reuniones semanales de comité, los riesgos, el avance en general, y el roadmap que te daba la vista de donde estabas en cuanto al avance general del proyecto. Cabe mencionar que todo el desarrollo de los proyectos se realizaban con los marcos de trabajo agiles, haciendo uso de la herramienta mas popular hoy en día, Jira.

Por lo que comenzamos a investigar una forma de generar el reporte del release roadmap que te muestre la ruta critica. Encontramos un plugin de gantt para Jira donde precisamente te mostraba la ruta critica del proyecto.


Link: Jira Gantt

Las únicas consideraciones era que teníamos que incurrir en un costo adicional, por lo que habilitamos para la versión trial, para su evaluación, la encontramos útil en su momento.

Hace poco me entere que Jira en su plan Cloud premium, incluyo la vista de Release advanced roadmap, la cual básicamente te da la opción de manejar interdependencias entre diferentes equipos que trabajen bajo el mismo proyecto, así como la capacidad por equipo, pudiendo identificar cuando tu equipo se encuentra sobre cargado y excede su capacidad en un sprint en especifico, también te da la vista de tener la administración de tus equipos de trabajo, así como tener una vista del estado de tus releases, pudiendo identificar si alguno se encuentra muy retrasado en su salida.


Link: Jira Premium

Algo que me agrado mucho es los múltiples filtros, agrupadores, campos y el timeline donde se puede visualizar las fechas comprometidas a nivel de Epicas, Historias de Usuario y subtareas.

En lo personal me parece muy útil esta herramienta para los equipos que desean tener actualizado continuamente su release roadmap y poder ajustarlo de manera mas eficiente y sincronizada con las tareas de cada equipo dentro de los proyectos.




viernes, 28 de mayo de 2021

Discord como herramienta colaborativa

 Discord para equipos de desarrollo y cualquier equipo de diferentes industrias

Hace un tiempo atrás participe de un meetup donde el equipo organizador utilizo una plataforma diseñada para gamers, en el cual se comunican de forma síncrona, pudiendo compartir pantalla y en el cual se tienen salas, servidores, según grupos de intereses. Me llamo la atención cuando lo vi por primera vez, sin embargo lo vi mas como otra herramienta simple de IMs, ahora me doy cuenta lo equivocado que estaba en su momento.

Hace un par de años atrás cuando comenzamos una etapa bastante intensa saliendo a producción con una versión del producto, en el cual estábamos como 3 semanas realizando el desarrollo y soporte para incluir nuevos features y corregir los errores que van saliendo cada día.

El punto es que los mismos desarrolladores sugirieron utilizar esta herramienta para poder trabajar todos los días, emulando un trabajo semi presencial, pudiendo realizar pair programming, saltando de sala en sala, pudiendo comunicarse de forma instantánea, uniéndose a cualquier presentación de pantalla. Un tema importante es la de seguridad donde el administrador puede restringir el acceso a los servidores.

Ahora cuando uno necesita el feedback o simplemente conocer en que esta trabajando el equipo, simplemente a cualquier hora del día solo basta conectarse a la plataforma y unirte al servidor y sala de interés donde el equipo esta trabajando de forma colaborativa.

Desde mi rol de facilitador encontré invaluable esta plataforma, que a un comienzo no entendía su potencial, lo recomiendo altamente para equipos de desarrollo y cualquier otra industria, siendo muy útil en esta época de pandemia, donde el 90% de las empresas habilitaron la modalidad de home office, debido a las medidas de seguridad.

Acá les dejo la dirección para que puedan evaluarla en sus equipos.

https://discord.com/

Espero les sea de utilidad como lo es en estos momentos para mi.


jueves, 20 de mayo de 2021

Dual Track Agile: Ventajas y Desventajas

En muchas organizaciones actualmente estan adoptando esta forma de trabajo, ya había trabajado de esta manera en una anterior organización hace un par de años atrás, solo que ahora le pusieron el nombre de Dual Track mencionado por primera vez por la diseñadora Desiree Sy.

En esta modalidad los diseñadores trabajan de forma paralela al desarrollo de la solución, realizando un descubrimiento del producto a desarrollarse en futuros Sprints, lo cual lo encuentro bastante útil, con una sola salvedad, en la experiencia que tuve anteriormente, el mismo equipo de desarrollo realizaba el diseño de los prototipos para luego implementarlos. El hecho de separar a los diseñadores del equipo, en mi percepción dificulta el sentimiento de trabajo en conjunto como trabajo único del equipo como tal, dando la sensación de tener otro equipo separado solo de diseño del equipo de desarrollo, donde ellos se ocupan de prototipar y nada mas como única responsabilidad.

Otra desventaja que pude apreciar es en esta separación se crean PBIs diferentes a los que se toman luego para su desarrollo, estos se trabajan netamente como incidencias de diseño, para luego convertirlos en Historias de Usuario, tomando así mucho tiempo (Age) sin poder entregarlos al final de cada Sprint (DoD) en caso de trabajar con Kanban.

Además que en la ceremonia de Sprint Review el Product Owner muchas veces requiere ver solo como un incremento los avances de las tareas de Diseño a los stakeholders, debido a la extensión prolongada de la sesión. Esto también desmotiva al equipo de diseñadores, los cuales no pueden presentar el trabajo realizado durante el Sprint. 

Conclusión

Personalmente, no elegiría esta forma de trabajo (por lo menos en su totalidad) ya que pude evidenciar varias desventajas que a la larga impactan en la madurez de los equipos. Prefiero trabajar directamente sobre las Historias de Usuario únicas tanto en su diseño como en su desarrollo, en sesiones de discovery sin necesidad de diferenciar y separarlas por diseño y desarrollo. Me interesa bastante que las personas que realicen el prototipado se sientan parte del equipo y aporten y sientan que son parte de la co creación del producto para entregar incrementos potencialmente entregables al final de cada Sprint.





 

domingo, 15 de noviembre de 2020

¿Scrum deberia ser usado solamente en industria de software?

 Ultimamente escucho mucho sobre que Scrum fue concebido en foco al desarrollo de productos de software, pero para poder generar mas revenu, se tuvo que ampliar a otras industrias, por lo que esto provoco un daño colateral a la industria de TI propiamente.

Razones:

Lo que se evidencia es que si bien existe el potenciamiento a SoftwareCraftmanship, roles tan importantes como Scrum Master, no tienen el foco en el codigo que se escribe, por tanto la calidad y tiempo del producto se ve afectado.

Incluso escuche en algunas charlas de la comunidad agil que no deberiamos de desperdiciar el tiempo precioso de nuestros Product Owners en la escritura de las Historias de Usuario, ya que esto podria cubrirse perfectamente con las practicas de TDD y BDD, teniendo al equipo de desarrollo enfocado en escribir codigo de calidad y este solo validarlo de la mano con el Product Owner.

Otra justificación que escuche, fue que Scrum no incluye el concepto escritura de Historias de Usuario, con el formato que popularmente conocemos, COMO "Rol", NECESITO "Requisito", PARA "Beneficio", Criterios de Aceptación, etc. Esto solamente es una intención de una necesidad del cliente transmitida al equipo de desarrollo. Siendo que empresas grandes coorporaciones de plataformas de tracking de tareas fueron incluyendo para vender sus servicios. Nosotros solamente como Scrum Masters deberiamos de asegurar que el Product Owner transmita en lenguaje natural de ususario final estas intenciones a los equipos en un formato plano en documentos tan sencillos como Excel.

Estimasion no necesaria: Otra observacion que vi es que la estimación de esfuerzo a las Historias de Usuario tambien no son justificadas, ya que el equipo por lo menos al principio cuando estan en un estado de Forming no tienen idea de cuanto les tomaria desarrollar una caracteristica del producto, por lo que estarian solamente adivinando el esfuerzo requerido.

El Scrum Master debe poder hablar el lenguaje del equipo: Se habla muchas veces entre los desarrolladores que el SM debe tener conocimiento profundo de los frameworks, codigo y tecnologia que se utiliza para la construcción del producto, basicamente ellos piden que sea un Arquitecto de TI, esto para que pueda aportar al equipo e identificar cuando existen desvios o inflación en los tiempos estimados de entrega de cada miembro del equipo. Cabe mencionar que en mi experiencia si conoci varias empresas de desarrollo de Software que piden este requisito a la hora de evaluar a un Scrum Master.

Conclusión: En lo personal pienso que si se debe de realizar un balance entre las habilidades duras y las blandas que todo lider servicial debe poseer, sin embargo no veo como una condicional el ser experto en las habilidades tecnicas para poder liderar a equipos agiles, si habria que reforzar el hecho de dar mas foco en la escritura de codigo en el caso de empresas de desarrollo de Software, para poder mejorar la calidad de los productos.

Al mismo tiempo soy un creyente que Scrum si bien fue concebido para empresas de software, si se puede ampliar a otras industrias de forma satisfactoria. Se puede evidenciar muchos casos en la actualidad de empresas muy grandes que aplican Scrum o Less (marcos escalados) con mucho exito.


sábado, 11 de julio de 2020

Tamaño del Sprint - Cual es el ideal para un equipo Scrum

Se habla mucho sobre el tamaño fijo que debe de tener el Sprint, en la Guía Oficial de Scrum menciona de una duración máxima de 4 semanas.

Scrum Guide: "El corazón de Scrum es el Sprint, tiempo fijo de un mes o menos, durante el cual "Listo", usable y un incremento potencialmente puesto en producción es creado. Sprints tienen duración consistente a través del esfuerzo de desarrollo, un Sprint comienza inmediatamente despues de concluir el anterior.
Los Sprints están limitados a un mes calendario. Cuando el horizonte del Sprint es muy largo, la definición de lo que es construido puede cambiar, puede llegar la complejidad y pueden incrementar los riesgos. Los Sprints habilitan predictibilidad, asegurando la inspección y adaptación del progreso a través del Objetivo del Sprint, al menos cada mes calendario. Los Sprints limitan el riego, al costo de un mes calendario"

Sin embargo en el SBOK mencionan de 1 a 6 semanas como máximo, lo cual va en contradicción de la guía oficial de Scrum.

En cuanto al Sprint, contamos con dos reglas inquebrantables.

1. No se deben de aceptar cambios en el transcurso de la ejecución del Sprint, cuidando y respetando lo pactado y comprometido por el equipo (Cuidando el cumplimiento del objetivo del Sprint)
2. La duración del Sprint es inamovible

Claro que existen casos extremos donde se puede negociar con el Product Owner el romper estas reglas (aunque no es aconsejable)

Pude observar en alguna ocasión el negociar el modificar el Sprint ya sea a 1 semana donde se tenían que acortar las integraciones para poder salir mas rápido a producción, donde era el producto final un sitio Web donde se ofertaban cursos en linea, aunque el manejo de la información era muy sensible por lo que se tenia que tener sumo cuidado al momento de realizar la integración.

Así mismo trabaje en otra empresa donde se tenia el Sprint de 1 mes donde se requería bastante coordinación, la ventaja era que daba el tiempo necesario al equipo de control de calidad de realizar todas las pruebas necesarias antes de completar el Sprint. Esto ayudaba a mantener la calidad en los incrementos desarrollados.

En lineas generales la duración del Sprint debería ser lo mínimo que toma al equipo de desarrollo completar un User Story (Listo).

Hay que tomar en consideración el factor de poder trabajar en los cambios de requerimientos que llegan durante el Sprint,

Mi percepción personal es que deberíamos tomar en cuenta los factores clave, según el tamaño del equipo, cual es la capacidad que se tiene, nuestro equipo esta maduro, el producto a desarrollar permite entregas in iteraciones cortas, no nos olvidemos tambien que se debe realizar el grooming dentro del Sprint para asegurar el tener por lo menos User Stories "Listas" por lo menos para dos Sprints siguientes.


jueves, 9 de julio de 2020

Implementando Agilidad en ambientes tradicionales

Retomando el blog personal, después de una pausa larga debido a mis tiempos cortos libres, ahora es tiempo de escribir acerca de una experiencia que me toco vivir hace un tiempo atrás.

Tuve la oportunidad de ayudar a incluir la agilidad en la gestión tradicional de proyectos estratégicos de la PMO de una importante empresa, donde se realizo un ajuste a toda la metodología tradicional aprovechando mi conocimiento y experiencia en el mundo ágil de muchos años atrás dentro de varias empresas de desarrollo de Software.

A continuación algunos puntos a resaltar según este emocionante reto.

1. Es imprescindible trabajar en cambiar el mindset tradicional de los ejecutivos para poder recibir el soporte requerido.

Análisis: Es muy difícil poder romper los paradigmas y costumbres del personal de la organización, ya que muchas veces estos se encierran en poder continuar con lo tradicional (funciono hasta ahora por que cambiarlo o deseo ver lo mismos resultados que hasta hoy veo con los métodos tradicionales)
Es critico trabajar en primera instancia en poder cambiar el mindset para asegurar que el cambio no se truncara en el camino.

2. Resaltar los beneficios de incluir frameworks ágiles dentro del desarrollo de los  productos de la organización (mejorando el time to market)

Análisis:  Esta parte salio naturalmente como una necesidad del mercado, al tener cambios tan frecuentes en las necesidades de los clientes, se vuelve imperativo el poder adaptarnos a estas necesidades si queremos ser competitivos dentro del mercado en la época actual en la que vivimos.

3. Documentar la nueva metodología a aplicarse dentro la organización

Análisis: El trabajar en la nueva metodología híbrida, fue bastante retador, viniendo de un mundo ágil, pero habiéndome preparado también en algún momento en la metodología tradicional, lo mas interesante fue el adaptar toda la gestión de ejecución del proyecto con el marco de trabajo Scrum.
Esto conllevo al siguiente punto muy importante, el poder socializar dentro la empresa.

4. Capacitación del personal sobre la nueva metodología

Análisis: Realizamos capacitaciones tanto presenciales, como remotas (on demand). Tomo bastante tiempo debido a la cantidad de personas de la organización, pero acomodando los tiempos de todos, realizando material facil de digerir, se puede completar el objetivo de poder preparar a los colaboradores en poder entender y ejecutar de forma adecuada la nueva metodología.

5. Implementación

Análisis: La implementación a mi parecer resulto mas fácil de lo esperado, lo que mas costo fue el poder crear habito de los team members para poder utilizar herramientas colaborativas para realizar el control y seguimiento con tableros Scrum y Kanban.

Todo el comienzo de la incubación, pre factibilidad y constitución del proyecto se realiza con la metodología tradicional, la parte de la ejecución con el marco Scrum y el cierre con las gestiones tradicionales.

Conclusión: Escuche a muchas personas de la comunidad no creer en las metodologías híbridas, sin embargo puedo dar fe que si se pone empeño es posible poder implementarlas y obtener buenos resultados, siempre y cuando nos aseguremos de poder trabajar en el cambio de mindset de los ejecutivos para poder recibir el respaldo necesario.

Trabajar en evangelizar los beneficios principales de la Agilidad en cualquier ámbito de cualquier industria para poder tener la credibilidad, el compromiso y la predisposición de los colaboradores.

También me gustaría señalar que revisando el SBOK, me parece que estuvimos bastante alineados a las practicas y principios de esta Guía.






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:



Programa
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 http://scrumbolivia.com/

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 http://en.wikipedia.org/wiki/Test-driven_development.
 
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.
Referencias:
http://www.genbetadev.com/trabajar-como-desarrollador/lecciones-aprendidas-del-testing-de-aplicaciones-software

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: http://agileopenbolivia.eventbrite.es

martes, 15 de mayo de 2012

Lo que realmente necesitan los proyectos


Leí un interesante artículo titulado ‘Los proyectos requieren liderazgo no administración’ acerca de la necesidad de contar con líderes más que administradores dentro de los proyectos. En el artículo habla de una marcada diferencia entre el rol de un gerente funcional y un Project manager.

El gerente funcional se maneja más en un organigrama o matriz de roles que se encuentran subordinados a los gerentes funcionales donde cada gerente funcional solo trata directamente con sus pares en los otros departamentos. En mi experiencia personal vi este caso en más de una empresa dedicada a TI en Bolivia y me atrevo a asegurar que en el caso de un gerente funcional es mucho más fácil el manejo del proyecto, pero también el éxito del mismo se ve afectado en cuanto al alcance y tiempo de finalización. Al no contar con un contacto directo con todo el equipo (todos los interesados del proyecto: clientes, patrocinadores, sponsors, equipo de trabajo, etc.) no se tiene una visión clara del estado actual del proyecto, además que los equipos involucrados no cuentan con la confianza ni comunicación necesaria para poder manejar con mayor fluidez sus tareas cotidianas, se genera un cuello de botella donde los requerimientos se van escalando uno a la vez y en ese trayecto se va perdiendo información valiosa así como se va mal interpretando la mayor parte de la información.  

 Lo ideal es que el Project Manager pueda llegar a cada una de las personas participantes del proyecto sin ningún tipo de burocracia y también otra característica es que lidera personas mucho más allá de administrarlas.
También habla de que el Project Manager debe enseñar a los patrocinadores acerca de sus deficiencias, debe enseñarles (si es que el caso lo amerita) todo lo necesario que se necesita de parte de ellos para que el proyecto tenga el éxito esperado, tales como las aclaraciones de los requerimientos, delimitar el alcance del proyecto, adquirir expertos para el soporte del proyecto y el de aportar dinero extra en caso de que el proyecto lo amerite (casi la mayor parte del tiempo).

La parte final que me agrado es que define que el éxito es contagioso en los proyectos. Siendo un líder ayudaras a la organización entera, al final influyes en el cambio de cultura de dicha organización. Tres puntos en los cuales debemos concentrarnos principalmente para asegurar el éxito dentro el proyecto: Necesito que me ayudes en…, Necesito un maestro en…, Necesito que me aclares…

En cuanto más rápido encontremos la solución a algún problema dentro el proyecto, estaremos más cerca de cumplir con el objetivo dentro el cronograma establecido.
Los mejores líderes de proyectos son aquellos que más que dirigir, se identifican con el equipo entero, son moderadores a la hora de tomar decisiones y logran encontrar soluciones eficaces a todo riesgo que se presente (mejor prever antes que corregir).

Para los que deseen revisar el artículo: http://ecaminc.com/index.php/blog/59-generalblog/313-2012-05-14?goback=%2Egde_69301_member_115068587