Reflexión después de los cursos de certificación para PSM I y PSPO I


Luego de haber participado en los cursos “Professional Scrum Master I” y “Professional Scrum Product Owner I” de Scrum.Org en 3Dev Business & Consulting. decidí hacer una reflexión en referencia a los mismos.

  1. Siempre creí que Scrum era una metodología de gestión de proyectos, y aun que estaba errado, trataba de convencerme o hallar una explicación lógica, y es que definitivamente Scrum no da una forma de llevar el proceso, por el contrario, provee las herramientas necesarias para administrar el desarrollo de un producto. ¿ Acaso esto no es un proyecto?, en definitiva, no lo es. Un proyecto esta amarrado a fechas, mientras que un producto esta orientado a si mismo como tal, por tanto, Scrum no se orienta a cumplir fechas, si no, a maximizar el valor de un producto.
  2. Estaba seguro que el Scrum Master era un Jefe de Proyectos, y estaba completamente equivocado, y es que no analizaba tampoco el nombre de este rol por si mismo, es decir, el “Scrum Master” es el “Maestro de Scrum” o experto en Scrum, responsable de de asegurarse que Scrum se cumpla, facilitando el camino y brindando el soporte necesario al equipo para el éxito de Scrum, mas no de dirigir al equipo, ni menos asegurarse del éxito del producto.
  3. Asumía que el Product Owner era el cliente, esto por el nombre del rol, entendía que el dueño del producto era el cliente si mismo, ahora entiendo que esto no es del todo cierto, el Dueño del Producto es en si el responsable de que el producto consiga su éxito, si puedo hacer una analogía, diría que es el gestor del proyecto, pero sin gestionar el equipo, pero si gestionando las prioridades del producto y maximizando el valor del producto.
  4. Estaba convencido que los miembros del Equipo de Desarrollo pueden trabajar cada uno en su especialidad, lo cual no ayuda en la cohesión del equipo como tal, ya que se busca que el equipo sea cross funcional y que no haya un propietario del código. Es importante la comunicación, coordinación e interacción de cada uno de los miembros del Equipo de Desarrollo, además de su compromiso y coraje para enfrentar los retos en el camino a conseguir el mayor valor del producto.

Conclusiones

  1. Scrum es una conjunto de herramientas que nos permite desarrollar productos complejos.
  2. Cada uno de los roles de Scrum son insustituibles, y su éxito radica en el empoderamiento del equipo hacia el producto por parte de la organización.
  3. Poner en práctica lo aprendido tan pronto como sea posible.

Agradecimientos

No puedo concluir este texto sin antes agradecer a Jose Peñarrieta y César López de Inka Labs, quienes me apoyaron para concretar mi participación en estos cursos.

Anuncios

El mejor equipo


Habia ya empezado mi primier scrum, con un equipo de desarrollo, según yo optimo, aun creo en ello, el dia planificado para el demo de sprint fue el día viernes 21 de noviembre, y llegó pues el día, y no habiamos culminado. Mi equipo solicitó entre otras cosas, trabajar de noche, horas extras, retrazar la fecha, todo con tal de poder completar nuestras metas y poder finalizar el sprint.
No tuve el valor de decirles: no chicos, el sprint terminó y terminó, simplemente espere la llegada del lunes siguiente para el sprint diario, creyendo que el sprint se aplazaría, los sente al rededor de la mesa de reuniones y les expliqué el por que no podiamos extender el sprint, y debió ser asi, simplemente no culminamos lo trazado, la pregunta fue ¿Que hicimnos mal?, Scrum no sirve para nada, desechemos Scrum!!
Luego de asimilar que el sprint terminó analizamos que pasó. Conluimos que Scrum si sirvio, no fracasamos, nuestro primer Sprint, simplemente estuvo mal planificado y con muchas fallas. Nuestros roles estuvieron terribles, mal concepto de responsabilidades a nivel de roles y funciones, la falta de un arquitecto especialista, entre otras tantas fallas, leí un poco más, al menos eso hice, y junto a mi equipo analizamos todo aquello que salió mal y que retardo el proyecto. Fue una gran lección que nos trajo muchas ideas claras al final del día sobre como habíamos trabajado y como debemos intentar trabajar, a mi me sirvió para entender que encontré al equipo ideal.
Hoy planificaremos un nuevo Sprint!!.

Scrum y UML


Siempre he sido un creyente de la importancia de UML, pero hablkar de UML me lleva a pensar en metodologías predictivas, que ademas de ser pesadas y aburridas, no daan muchos resultados del todo óptimos. Pero UML, según entiendo, UML es tan solo un lenguaje de modelamiento, independiente de la metodlogía de desarrollo, entonces debe adaptarse a cualquier metodología.
Moddelar bases de datos relacionales en metodlogías orientadas a objetos, ya es un reto, pero es importante que todo el equipo sepa lo que debe hace, como y sobre que arquitectura trabajar, bueno apostaremos por ello y veré que sucede al final de este sprint.
Hoy dia tendremos nuestro segundo sprint, en el cual incluiremos el modelado de sistema y el modelado de la arquitectura de base de datos, sin descuidar la documentacion. Vaya que suena a metodología predictiva, pero si se mantiene una adecuada documentación y modelos de trabajo, pienso que no estaremos lejos de realizar algo con calidad.

Que es scrum?


Un amigo mio me habló de scrum, qué es, para qué sirve y con qué se come. Me habló sobre los beneficios y, pricipalmente, de como aplicar scrum, pero una conversación de una hora, no era suficiente para entenderlo. Revisé en internet y encontré una pagina, mejor dicho aún, un blog muy interesante:
Enseñando scrum a mi abuela
ademas un libro que lo recomiendo, lo descargue en su version gratuita, e insto a comprarlo, lo lei y esta excelente
Pagina del libro
Versión Inglés
Versión español