[#TFS2012] HowTo: Usar #Bug con tableros #Kanban en la plantilla de #CMMI

image

Hola!

Después de más de un año de trabajar con Team Foundation Service, la verdad es que me había olvidado lo que es trabajar con TFS on Premise. A eso le sumo que hace años que toco la plantilla de CMMI, y claro la siguiente pregunta del Edu me dejo con una cara de bobo de aquellas:

¿Cómo puedo hacer para poder gestionar mis BUGS con un tablero Kanban si trabajo con la plantilla CMMI en Team Foundation Server 2012?

Si bien, la pregunta de deja todo explicado, mejor aclaro el escenario:

Yo no sabía que en la plantilla de CMMI, en el board de trabajo sólo se ven los requerimientos (los workitems de tipo requeriment). La siguiente imagen muestra un ejemplo del board con una plantilla CMMI, donde vemos que el único tipo de elemento que podemos crear es un REQUIREMENT.

image

Nota: Pensándolo un poco, esto tiene sentido por la jerarquía de trabajo de CMMI. Aunque después de trabajar con tableros, es dificil dejar de usar los mismos.

Así que la challenge estaba sobre la mesa: ¿Cómo lo hago? !!! Y tampoco es que haya mucha información en la webs sobre esto. Lo más cercano es esta entrada de la MSDN, en la sección “Types of work items that are considered backlog items”.

La misma describe los pasos a tener en cuenta para agregar nuevos tipos de WorkItems que sean tratados como Backlog Items. Traducido a CMMI, esto sería tratados como Requerimientos. Pues bien, como la ayuda no dice todos los pasos, estos son los que hemos seguido nosotros y (por ahora) funcionan.

1. Exportamos el listado de categorías desde TFS con el comando

witadmin exportcategories /collection:CollectionURL /p:ProjectName /f:"DirectoryPathcategories.xml"

Manos de Lagarto: Antes de modificar el archivo recuerda hacer backup del mismo!

2. Editamos el mismo y agergamos el workitem type BUG como un requerimiento

  <CATEGORY refname="Microsoft.RequirementCategory" name="Requirement Category">
    <DEFAULTWORKITEMTYPE name="Requirement" />
    <WORKITEMTYPE name="Bug" />
  </CATEGORY>

3. Actualizamos la configuracion del Team Project con este cambio, con el comando

witadmin importcategories /collection:CollectionURL /p:ProjectName /f:"DirectoryPathCategories.xml"

4. Este punto es muy importante: Aquí te has cargado el TFS, la vista WEB te mostrará unos errores de lo más simpáticos. Si bien la guía de MSDN te recomienda en este punto definir también el mapeo entre los estados de los WorkItems y las columnas del tablero Kanban, hay un detalle que no te comenta.

El WorkItem Type REQUERIMENT tiene un campo SIZE que se utiliza para el cálculo en algunos gráficos de WebAccess y además en la vista por defecto se utiliza esta columna. Puedes cambiar toda esta configuración y definir que valor se utilizará de un BUG o … agregar el campo Size al WorkItem Type Bug.

5. Para agregar este campo, utilizando las Team Foundation Server 2012 Power Tools editamos la definición del Bug. Menú “Tools // Process Editor // Work Item Types // Open WIT from Server”

image

6. En la lista de tipos, seleccionamos el BUG

image

7. Agregamos un nuevo campo con los sigiuentes datos:

image

8. Listo !!! Ahora ya nuestro tablero principal nos permitirá utilizar REQUERIMENTS o BUGS … con todas las features que ello implica: tableros Kanban, gráficos, etc.

image

 

Referencias:

Saludos @ La Finca

El Bruno

image image image Google

[#ALM] Cual es mejor #KANBAN o #SCRUM?

ALM 03

Hola,

hoy voy a tocar un tema que es complicado: intentar definir si

SCRUM es mejor que KANBAN

o si

KANBAN es mejor que SCRUM

Y ahora que he cumplido con las formalidades para aquellos que leen el resumen del post vamos con la respuesta correcta:

¿Realmente piensas que una forma de trabajo es mejor que otra?

Si eres de los que piensan que se puede hacer una comparativa entre ambas y sacar la “MEJOR”, es que realmente no has comprendido como funciona un equipo.

En mi caso, hay cosas de KANBAN que me gustan mucho, como por ejemplo el concepto de Work in Progress (WIP). Y como contrapartida de SCRUM hay cosas que me repatean las nalgas como las predicciones en base a las métricas que nos brinda velocity. Pero ambas tienen muchos conocimientos y buenas prácticas que puedes aplicar en tu equipo para lograr un mejor rendimiento.

Y para finalizar, solo comentar que si eres de esas personas que no tienen miedo en afirmar que “X es mejor que Y”, pues da gracias que todavía no se ha inventado el modo de dar golpes a través de internet … Angry smile

 

Saludos @ Home

El Bruno

image image image Google

[#TFS2012] Ahora ya puedes personalizar los tableros #Kanban a tu gusto !!! (pero sin pasarse ehh?)

image

Buenas,

después del anuncio de Brian Harry de ayer con los updates aplicados a Team Foundation Service y a Team Foundation Server 2012, una de las cosas que más esperábamos era poder personalizar las columnas en nuestros tableros Kanban. Aquí tienes un post del gran Tarun Arora que te lo explica de forma más PRO, yo lo haré más de andar por casa.

Ayer ya me di un golpe en la frente cuando intenté personalizar las columnas de un tablero, principalmente por una cuestión de cache del IE; sin embargo después de esto todo comenzó a funcionar de perlas.

Cuando creas un proyecto basado en la plantilla de SCRUM, dentro del Product Backlog ya puedes acceder al tablero (board) y dentro del mismo ver las columnas con las que puedes trabajar con los PBIs. En la siguiente imagen hay 8 PBIs en los 4 estados posibles

image

En este caso el flujo es bastante lineal y pasa por los siguientes estados

image

Esta forma de trabajo cubre muchos escenarios, sin embargo es posible que dentro del mismo haya casos en los que se desee trabajar con un poco más de refinamiento, por ejemplo agregando estados para identificar el test integrado pasado y el control de QA realizado.

image

Como vemos en la figura superior hemos cambiado algunos estados y ahora veremos como hacer lo mismo en el tablero Kanban de Team Foundation Service. Cuando accedemos a la opción Customize Columns, vemos que tenemos los 4 estados iniciales. Además podemos ver que tenemos la posibilidad de definir el tamaño máximo del WIP para cada columna y podemos definir el estado de cada tipo de WorkItem en cada columna.

image

Aplicando los cambios del nuevo proceso, veremos que si bien no cambiamos el estado del WorkItem, si podemos cambiar la posición del mismo en las columnas del tablero. En este caso he renombrado una columna por Build y agregado 2 nuevas: Integration Test y QA.

image

Cuando aplicamos esto cambios vemos que los WI existentes se acomodan a las nuevas columnas y no se pierde información.

image

Ya tenemos un tablero 100% funcional en el que podemos mover los PBIs a nuestro antojo dentro de la definición de columnas que tenemos. Un ejemplo de ello puede ser la siguiente imagen

image

Ahora bien, dentro del histórico de cambios de un WorkItem, los valores que definen como se asocia al mismo a las columnas se almacenan en el campo Kanban Column. Si vemos el histórico de un WI podremos ver como este valor cambia a medida que movemos el WI entre columnas,

image

Si además arrastramos el WI a una columna que cambia su estado, el campo State también se actualiza.

Impresionante feature … !!!

Saludos @ La Finca

El Bruno

image image image

[#TFS2012] Otra novedad: Kanban is here !!!

image

Buenas,

despues del anuncio de GitTF, hoy toca ver rápidamente otra novedad incorporada a Team Foundation Server 2012. Se trata de la posibilidad de trabajar con un modelo Kanban en nuestros proyectos. Las bases de Kanban son bastantes simples y una vez que las comprendes, si tu modelo de trabajo se puede adaptar a las mismas pues ya tienes un buen punto de trabajo.

El concepto de WIP y de estados en un tablero, nos permite tener una representación real del trabajo que estamos realizando, de los cuellos de botella, etc. Lo mejor de todo esto, es que si tienes una cuenta en TFS Preview, pues ya puedes comenzar a utilizar tu tablero Kanban. El video de Channel9 explica en 10 minutos como comenzar a trabajar con el mismo.

Como ahora estoy en el medio de un proyecto gestionado con iteraciones, y otros conceptos que “chocan” con la herramienta, pues lo dejaré para el próximo Open-mouthed smile

Video: http://channel9.msdn.com/Blogs/VisualStudio/Announcing-Kanban-for-Team-Foundation-Service

Saludos @ Home

El Bruno

image image image

[#TFS2010] Practical Kanban Guidance

image

Buenas,

el equipo de ALM Rangers está cada vez más activo. A través de este post, me entero de los proyectos que están en fase Beta (por más que ahora no se lleve más eso de Beta, RC, RTM, etc.) de un proyecto para la implantación de Kanban para Team Foundation Server.

Si no conoces Kanban, el video que comento en este post es una excelente introducción al tema y obviamente, sino las 20 páginas que le dedico en mi libro “Trabajando en equipo con Visual Studio ALM” también dan un acercamiento de Kanban para TFS.

Pero bueno, a lo que iba. El equipo de ALM Rangers está cerrando un proyecto llamado “Practical Kanban Guidance” que pretende ilustrar el uso de esta metodología en TFS con los siguientes contenidos (fusilados de codePlex)

  • Guidance contains scenario based practical guidance, frequently asked questions and quick reference posters
  • Hands-on Lab contains the HOL that provides a walkthrough of the planning, based on the guidance
  • HOL Package includes a setup part which prepares and configures your environment for this lab
  • HOL Videos which showcase the hands-on labs and guidance in quick 5-10min videos

Ya lo tengo en modo “follow” y seguiré de cerca los avances de este proyecto.

Saludos @ Home

El Bruno

image image image

Fuente: http://blogs.msdn.com/b/visualstudioalm/archive/2012/02/29/welcome-to-visual-studio-11-alm-rangers-readiness-beta-wave.aspx

[ALM] Opinion: ¿Hasta donde debo seguir las reglas de una metodología de trabajo?

Buenas,

ayer entre tanta salida de Windows 8, hubo una serie de tweets entre @lfraile@javierholguera, @r_corral y el que firma el post (que tal vez no sea el que escribe), donde discuíamos el tema de seguir o no seguir las guías que nos proponen ciertas metodologías de trabajo como por ejemplo SCRUM.

Hasta donde tengo entendido el contexto, Javier se está preguntando si SCRUM es la forma de trabajo que mejor se adapta a su escenario de trabajo, ya que entiende que tiene que terminar una iteración para poder liberar el resultado de la implementacion de las users stories que se han definido para la misma. Supongo que es por eso que se está planteando probar un poco KANBAN para gestionar su trabajo, ya que de esta manera. Por ejemplo, en el siguiente tablero vemos que si el WIP del equipo es 5, las tareas que están a punto de cerrarse son las D, E, G, y H; y que las features liberadas en A y B ya se pueden probar.

image

Pues bien, eso ayuda en KANBAN tener un elemento cerrado cuando “está cerrado” y no tener que esperar a que se finalice una iteración para liberar el mismo.

Pero ¿porqué no cambiar el alcance de un Sprint? (vale ya he hablado de iteraciones, cambio a modo SCRUM) … pues porque el gran Ken Schwaber en su libro “AGILE PROJECT MANAGEMENT WITH SCRUM”, además de cerrar en 30 días el período fijo para un SPRINT, dice lo siguiente:

No one can provide advise, instructions, commentary or direction to the Team during the sprint. The Team is utterly self-managing.

(página 136)

Leyendo esto al pie de la letra y siendo muy radical en la implementación de SCRUM, si durante un sprint yo tengo estimado cerrar 3 elementos, tengo que esperar al final del sprint para poder liberar estos 3 elementos.

Pero, es muy común que surjan las siguientes preguntas:

  • ¿qué sucede si trabajo en un equipo que crea elementos comunes para otros equpos, y el primer elemento es crucial para que otro equipo pueda seguir trabajando?
  • ¿que debo hacer si mi equipo es capaz de entregar este elemento en 15 días, pero el sprint está cerrado en 30 días?
  • KenS propone sprints de 30 días, ¿puedo cambiar el tamaño de un sprint?

Vale, llegamos al punto interesante:

¿Puedo saltarme las reglas/obligaciones que trae cada metodología de trabajo?

Pues no hay respuesta correcta para esto. Desde mi experiencia siempre recomiendo conocer a fondo una forma de trabajo y de la misma, aprender a utilizar lo que realmente se necesite. 

Un ejemplo, hace un tiempo participé en un proyecto con un compañero donde nos guíamos por las recomendaciones de SCRUM (basados en TFS2010 y MSF for AGILE 5.0). Pero … ¡¡¡no hacíamos daily scrum meetings!!! si si si, ya lo sé, los gurúes de SCRUM me crujen. Soy un sacrílego, no soy digno, etc. Si fuese por KS, ambos deberíamos cerca de €100 a la hucha, deberíamos tener siempre la reunión en el mismo sitio, etc.; vamos que KS nos mata.

Pero mi pregunta era, ¿para qué vamos a hacer un Daily Scrum Meeting si ambos estamos sentados uno al lado del otro, compartimos 15 minutos de cafe donde hablamos de futbol, gadgets y el proyecto; y además compatirmos horas de cervezas donde también hablamso de lo mismo?. Vamos que no nos hace falta.

Cuando lo pienso un poco, veo que esto es parte de mi forma de ser. Como soy una persona que vivo al límite, en el proyecto anterior que compartí con este compañero tampoco hacíamos “Stand-up meetings” (ahora cambio a AGILE), después de trabajar un tiempo con una persona pues la conoces y eso puede ayudar bastante a la dinámica de trabajo de un equipo.

Aclaración: Esto no quita que la práctica de las SUM sea muy recomendable, es más existe un artículo en el site de Martin Fowler donde se describen algunas recomendaciones para llevar este tipo de reuniones.

Personalmente, yo creo que sin realizar las DSM no dejabamos de trabajar en modo SCRUM. Pero nos saltábamos las reglas basados en nuestra experiencia y porque sabíamos que esa era la mejor forma de trabajo.

Ahora es momento de preguntarse, lo que trato de hacer que todo el mundo se pregunte:

¿Puedo cambiar la forma en la que trabajo para ser más efectivo, sin perder la calidad?

Pues ahí te lo dejo.

 

Saludos @ Home

El Bruno

   

PD: el chart de Kanban es del nuevo librako en el que estoy terminando, a ver si hago un post/concurso para ver que título le pongo al book.

PD2: sé que alguno después de leer esto dejará de leer mi blog … pues más alivio para internet Open-mouthed smile

[#TFS2010] Un excelente ejemplo de #KANBAN con Team Foundation

image47dd1de4

Buenas,

hace poco tiempo Adam Gilmore (@adamgilmore) hizo una presentación en los TechDays donde habló un poco sobre cómo implementar un modelo de trabajo de Kanban basado en Team Foundation Server. Lo interesante de su propuesta es que además de contar el ABC de Kanban, mostró una implementación de una plantilla de procesos para Team Foundation Server 2010 para trabajar con un modelo Kanban.

Esta plantilla se puede descargar desde CodePlex desde aquí, y tiene varias cosas interesantes para comentar:

  • Se ha modificado la definición de los estados del WIT User Story para que den soporte a un flujo de trabajo Kanban.
  • Ha creado una aplicación ASP.Net para mostrar un tablero gráfico de estados
  • Ha implementado un sistema de informes en una hoja Excel

La siguiente imagen muestra la implementación del tablero, que es bastante interesante además de ser abierta a modificaciones y mejoras

image

Finalmente, si quieres ver los 90 minutos de la charla, la misma se puede ver completa desde http://channel9.msdn.com/Events/TechDays/TechDays-2011-Belgium/TD035

 

Saludos @ Home

El Bruno

   

Descarga: http://techdayskanban.codeplex.com/