Nuevo curso de Certificación Scrum Master en Montevideo, Uruguay

Cursos, ,

Para los que se lo perdieron la primera vez, otra oportunidad. Del sitio de AQuA.it, organizadores del curso:

Estamos organizando el segundo curso en Uruguay con certificación internacional otorgada por la Scrum Alliance de la metodología ágil de gestión de proyectos llamada SCRUM.

La palabra SCRUM fue utilizada como nombre para esta metodología con el mismo significado que tiene ella en el Rugby. En este deporte se utiliza a la unión de todos los integrantes del equipo, como si fuera un solo hombre, para “cruzar” la cancha y poner la pelota en meta contraria. Para ello se basan en táctica y estrategia. De manera análoga un equipo de trabajo que utiliza SCRUM debe ir generando “puntos” durante el proyecto hasta finalizarlo. La metodología es un framework que describe el camino para poder lograrlo, es decir, la táctica y la estrategia.

Contenido del curso
Enseñar todos los fundamentos y conceptos de Scrum: Roles, Rituales y Artefactos.

Existen 3 roles en Scrum: Team, Product Owner y Scrum Master. Se explicará las funciones de cada rol y su interacción, dependencias, etc. Dedicando más tiempo al rol del Scrum Master.

Los Rituales se describirán detalladamente, respondiendo; ¿qué son?, ¿para qué sirven? ¿cómo se implementan? ¿cuál es la agenda de cada una? ¿y su frecuencia? ¿cuál es su input/output? ¿cuál es el objetivo concreto de cada una? Todas éstas respuestas determinarán el buen uso de la metodología y el éxito de su aplicación.

El ciclo de vida de Scrum está basado en Sprints, éstos permiten hacer entregas periódicas del producto en lapsos muy breves, en donde se parte de la base que el producto nunca está definido completamente, por el contrario, es entiende que su definición es evolutiva. Por tal razón será una parte fundamental del curso comprender y practicar el ciclo de vida que propone esta metodología.

Se mostrarán los documentos y gráficas que existen en Scrum para poder mostrar datos del proyecto que permitan tomar métricas de gestión.

Aunque no es parte de Scrum, también se explicará como combinar este framework con otras metodologías ágiles, por ejemplo XP, TDD, etc. Dentro de este marco se utilizaran las User Stories, ¿cómo aplicarlas?, ¿cuál es su formato?, etc.

Se expondrán las grandes diferencias, ventajas y desventajas de esta metodología y las tradicionales.

Dada la experiencia del entrenador internacional, responderá cualquier consulta que los participantes tengan y enriquezcan el curso.

Dinámica

Es un curso totalmente interactivo, en donde se forman equipos para ir aprendiendo Scrum para practicar los conceptos. Asimismo el entrenador utiliza novedosas técnicas para sugerir cómo abordar los cambios de paradigma que se necesitan.

No se pueden utilizar teléfonos celulares ni portables durante el dictado del curso.

Entrenador Oficial

El Sr. Alan Cyment estará encargado de dictar este curso. Tiene varios años de experiencia en Scrum, en varios proyectos desarrollados en diferentes países. Es un entrenador certificado por la ScrumAlliance quién es la entidad que evalúa y otorga las certificaciones en esta disciplina. Alan es un investigador graduado en Ciencias de la Computación, título otorgado por la Universidad de Buenos Aires. Actualmente está escribiendo un libro con uno de los practicantes más reconocidos en éstas metodologías, el Sr. Tobias Mayer. Además, Alan es el único entrenador oficial de Scrum de habla hispana, con cualquier otro el curso sería dictado en inglés.

Agenda

El curso se dictará en dos días consecutivos. Cada jornada comenzará a las 9am en punto y finalizará a las 6pm.
Fecha de comienzo: Lunes 2 de noviembre de 2009.
Fecha de finalización: Martes 3 de noviembre de 2009.

Mecanismo de evaluación

En esta ocasión el mecanismo de evaluación se realizará en el segundo día del curso, en donde cada equipo deberá practicar todo el ciclo de Scrum y entregar un producto concreto.
Este trabajo será evaluado por el entrenador y en base a su resultado se obtendrá la Certificación. Los certificados son emitidos digitalmente por la ScrumAlliance. Quienes hayan aprobado recibirán un mail para que bajen su certificado del sitio oficial de la ScrumAlliance.

Costos

El costo del curso son 625 dólares americanos + impuestos.
(No está incluído el almuerzo, solo coffee break)
Única forma de pago: Depósito en la cuenta dólares 8640416, Banco ITAU, Sucursal Aguada.

Quedamos a vuestra disposición y en breve estaremos publicando en nuestra página Web esta información. Por consultas puede enviarnos un correo a cursos@aquait.biz

SCM Gabriel Ledesma

Referencias
Información del curso en la página de Scrum Alliance
http://www.scrumalliance.org/courses/4388-certified-scrummaster

Nuevo evento Scrum en Uruguay

Eventos, ,

Para los interesados en certificarse como Scrum Master en Uruguay, un comunicado de la comunidad Scrum del Uruguay:

Estamos analizando la posibilidad de realizar un nuevo evento de SCRUM en Uruguay.
Agradecemos que difundan esta información.

2 y 3 de noviembre 2009 – Curso de Scrum Master Certified

Queda sujeta la confirmación al posible interés de los posibles  participantes.

Seguramente se pueda hacer también en el día 4 una jornada especial aparte del curso, pero es muy probable que de no haber curso no haya jornada especial, dependerá de Alan y Ariel.

Es el curso de certificación realizado por Alan Cyment y Ariel Ber del que comenté algo en como empecé con Scrum. Esperemos que mucha gente se prenda a ir, para que se vaya sumando gente a la comunidad de desarrollo ágil en Uruguay. De mi parte recomiendo el curso a todos aquellos interesados en aprender sobre Scrum, por más que no piensen implementarlo por ahora. Cuantos más interesados hayan, más posibilidades de que se realice.

Pueden comunicarse con Aqua.it si están interesados, su sitio web:
http://aquait.biz

Baraja de planning poker de Autentia

Recursos, , ,

El Planning Poker es una técnica para la estimación de trabajo o esfuerzo usada para cada tarea de una planificación en el desarrollo ágil de software. Prometo hablar más al respecto en otro post (tengo unos apuntes del curso CSM), pero ahora quería copiar y pegar un mail enviado a foro-agiles por Alejandro Pérez García, Socio fundador de Autentia:

Hola a todos.

Hemos hecho unas barajas de planning poker, con un toque de humor    😉

Si quereis os las podéis descargar en la zona de «Descargas» de nuestra web: www.autentia.com

Saludos a todos, y que las disfrutéis.

Están licenciadas bajo Creative Commons, y son bastante buenas realmente 😛

Un preview:

Autentia Planning Poker Cards
Autentia Planning Poker Cards

Rol y perfil del Product Owner

Product Owner, ,

A raíz de la entrada anterior: Sprint heroico – Planificación y Task Board me dejaron comentarios y enviaron un mail Victor y Ana:

Hola Fernando, en la empresa para la que trabajamos con Victor, estamos investigando sobre Scrum porque queremos implementar esta metodología.
Tenemos una duda respecto al rol de Product Owner, ese rol lo cubre un empleado del Cliente? y Cuál es el perfil de la persona que cumple este rol?
Desde ya agradecemos la infomación que nos puedas facilitar
Saludos

Primero que nada, veo que la empresa está muy interesada en implementar Scrum, ¡felicitaciones y bienvenidos al mundo ágil! Gracias por acudir al blog para despejar sus dudas, les recomiendo que acudan también a Foro agiles, la comunidad hispanohablante de metodologías ágiles de desarrollo.

Ya que me estaba extendiendo mucho en la respuesta en los comentarios, lo convertí en una entrada nueva, aprovechando que a alguien más le pueda servir. A continuación mi humilde aporte, espero lograr responder lo mejor posible desde mi conocimiento y experiencia personal:

El Product Owner

El rol del Product Owner, puede venir de parte del cliente o dentro de la empresa misma, depende. Generalmente no se aconseja que el Product Owner sea parte también del equipo de desarrollo, o el Scrum Master mismo, sus intereses se pueden ver enfrentados, pero esto puede variar según el caso. Por defecto, probablemente venga de parte del cliente.

Como Product Owner representa al cliente, y es el encargado de negociar con el equipo, con el Scrum Master por medio como facilitador, la prioridad del trabajo a realizar. Esto desde una perspectiva del retorno de inversión para el negocio.

Una de las analogías que nos comentaron durante el curso de CSM, es que el Product Owner sería como un embudo. En un extremo están los «stakeholders» o interesados: director de Marketing, de Finanzas, otros directivos, etc. El P.O. debe juntar y filtrar las necesidades de cada uno y hacérselas llegar al equipo, priorizando según el retorno de inversión.

En mi caso en particular, estoy en un desarrollo propio para la empresa donde trabajo. El rol de Product Owner es asumido por el jefe, ya que es quien tiene la visión general del producto.

Según la definición de la Scrum Alliance de los roles en Scrum, los roles del Product Owner son:

  • Definir las características del producto;
  • Decidir sobre las fechas de lanzamiento y contenido;
  • Ser responsable de la rentabilidad del producto (ROI);
  • Priorizar las características según el valor de mercado;
  • Ajustar las características y prioridades por iteración, según sea necesario; y
  • Aceptar o rechazar resultados del trabajo.

Debe estar presente entonces en las reuniones de planificación de Sprint, para priorizar las tareas del backlog. También es el encargado de llevar a cabo el review del producto, para aceptar o rechazar los resultados, según el concepto de listo. Viendo todos estos datos, espero estén en condiciones ya de responder qué perfil debe tener la persona a cumplir con este rol, y quién sería la más adecuada.

Se puede obtener entrenamiento para certificarse como Scrum Product Owner de la Scrum Alliance.

Espero haber aclarado el panorama, aunque agradezco cualquier aporte de lectores con más experiencia en el asunto. Desde ya les deseo mucha suerte con la implementación de Scrum, y espero compartan cualquier experiencia, duda y demás tanto con este blog, como la comunidad hispana de metodologías ágiles que pueden encontrar en: Foro agiles

Actualización:

Desde Foro ágiles justamente, tengo más material para comentar respecto al rol del Product Owner. Xavier Quesada Allue respondió sobre este post, y agregó la siguiente información:

Otra página similar para tener en cuenta es la del sitio Proyectos Agiles de Xavi Albaladejo:
http://www.proyectosagiles.org/cliente-product-owner

Recordemos que el Product Owner o bien es el Ciente, o bien representa al Cliente. En este ultimo caso a veces se lo llama ‘Proxy’ Product Owner para distinguirlo del Cliente real. Ser PO de un proyecto mediano/grande suele ser una dedicación full time, o como mínimo requiere tiempo de respuesta rápida durante el Sprint si el equipo te necesita. Muchas veces el Cliente o Senior Manager no está disponible cuando lo necesitamos y por eso hacen muy malos Product Owners.

Product Owner Anti-Patterns
Tenes un mal Product Owner si…

  • El PO no viene a la demo
  • El PO no viene al sprint planning
  • El PO no puede explicar bien las historias durante Sprint Planning
  • El PO no está disponible cuando el equipo lo necesita durante el Sprint
  • El PO no está manteniendo el Product Backlog actualizado y en perfecto estado
  • El PO no está autorizado a priorizar el backlog, y tiene que andar validando todo lo que hace con el cliente o un gerente a nivel micro-management
  • El PO no tiene autoridad suficiente como para negociar entre todos los stakeholders, en el caso de hacer de ‘embudo’

En cualquier caso en el que el PO no esté en total control del Product Backlog, o no lo esté manteniendo por falta de tiempo o ganas, o no pueda explicar lo que está pidiendo, o que el equipo sienta que está teniendo que tomar decisiones que debería tomar el PO… tenes un mal Product Owner.

¡Muchas gracias Xavier por la información!

Sprint heroico – Planificación y Task Board

Scrum, ,
Task Board Scrum
Task Board Scrum

Como comenté en una entrada anterior (Implementando Scrum: Cómo empezamos), nuestro Product Owner se encontraba hasta hace poco fuera del país. Recientemente volvió a trabajar desde nuestra oficina, lo que nos permitió realizar una primera planificación de Sprint con el Product Owner presente. Las ventajas de contar con su presencia saltaron a la vista, ya que la priorización y negociación de tareas se hizo de una forma muy fluída, así como también se despejaron algunas dudas instantáneamente durante la planificación misma.

Además de eso, este Sprint tuvo varias características que lo hicieron único respecto a los anteriores:

  • La planificación se realizó fuera de horario. Debido a complicaciones varias del lunes, nos juntamos en la tarde, mientras que los Sprints anteriores se hacían lo más temprano posible. Esto no cumple con el espíritu de Scrum en cuanto al enfoque de time-box, mantener el ritmo, la disciplina y compromiso. Sin embargo, hay que tomar lo que sirve, y en este caso nos sirvió hacerla tarde.
  • El equipo constaba de 7 programadores. Ahora se sumaron a la planificación los 2 diseñadores gráficos del proyecto. Estamos en etapa de maquetación e integración del código PHP con el diseño, por lo que volvimos a juntar a todos los responsables del desarrollo del proyecto. Además, el Scrum Master (yo) abandona temporalmente su puesto de director en el equipo, por razones planteadas en el siguiente punto, y se integra como un programador más.
  • Nos encontramos muy cerca a una fecha de entrega, dos semanas. Teníamos varias características del producto definidas para esta entrega, que veíamos difícil de implementar. Por esto, hicimos una planificación bastante profunda, para tratar de meter todas las tareas importantes en un Sprint que por primera vez contaría con dos semanas de duración. Esta era la idea inicial, pero al estar empezando con Scrum, decidimos que una semana permitiría estimaciones más precisas. Desde mi punto de vista, el equipo ya se encuentra en condiciones de planificar los Sprints a dos semanas. Además la presencia del Product Owner facilita las cosas.
  • Implementamos el Scrum Task Board. Como comenté, usábamos el pizarrón como Task Board. Ahora usamos un espejo que hay en la oficina de desarrollo. Ya lo habíamos usado en nuestra primer implementación fallida de Scrum. Usamos los post-it amarillos para mostrar las tareas que fueron estimadas y asignadas durante el planning del Sprint. Los post-it naranja son tareas nuevas que fueron surgiendo, y trataremos de mechar con otras, o realizar si da el tiempo. También agregamos post-it verdes, que son tareas opcionales, para tiempo que sobre. Todos los movimientos en el Task Board se realizan únicamente en el Daily Meeting, de manera que todo el equipo esté al tanto de lo que sucede, y por el compromiso que implica llevar una tarea a la columna de «finalizado»
  • En lo personal, es un Sprint más «feliz», ya que dejé mi puesto de Project Manager y Director, para meterme de lleno en el código. Así que ahora estoy cumpliendo el rol de Scrum Master así como de desarrollador del equipo.

Lo interesante de la planificación fueron las etapas . En un principio se sentía mucha tensión, presión, nervios, miedo, stress… Pero la presencia del Product Owner (también jefe del equipo), se hizo notar, y las cosas llegaron a una buena conclusión. Demoramos algunas horas en definirlo, pero llegamos a una planificación completa de las dos semanas siguientes de trabajo. Esto fue el lunes de la semana pasada, y a más de una semana, puedo decir que ha resultado. Hoy el Task Board tiene mucho más tareas naranjas agregadas, así como algunas amarillas más (mayor granulación de algunas tareas), pero la columna de «terminado» está colmada.

Un Sprint muy especial, por todo lo comentado. En teoría, tendríamos un review y reflexión de este «Sprint heróico» el día 3 de agosto, así que ya comentaré cómo estuvo eso. Mientras tanto, ¡a programar!