Category: Agile

[#EVENT] WebCast on #AGILE with Visual Studio and Team Foundation Server 2012 #VS2012 #ALM

image

Buenas,

after a couple of days of oscurismo, finally I can remove the desire to and comment as we work Agile with Visual Studio 2012 and Team Foundation Server 2012. MSDN Latam friends have given me a space of 60 minutes for comment as it is possible to carry out a team using the tools of Visual Studio Alm (as always many thanks!)

60 Minutes is a little time, I will try to go through the basic themes

  • Organization of work
  • work planning
  • execution of the work
  • change management

To what you now see it clearer, isn’t it?

image

Registration: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032551090&Culture=en-AR&community=0

Saludos @ Home

El Bruno

image image image

[#EVENT] WebCast sobre #AGILE con Visual Studio 2012 y Team Foundation Server 2012 #VS2012 #ALM

image

Buenas,

después de un par de días de oscurismo, por fin me puedo sacar las ganas y comentar como podemos trabajar de manera ÁGIL con Visual Studio 2012 y Team Foundation Server 2012. Los amigos de MSDN Latam me han dado un espacio de 60 minutos para comentar como es posible llevar adelante un equipo utilizando las herramientas de Visual Studio ALM. (como siempre muchas gracias!)

Si bien 60 minutos es poco tiempo, intentaré pasar por los temas básicos

  • organización del trabajo
  • planificación del trabajo
  • ejecución del trabajo
  • gestión de cambios

A qué ahora lo ves más claro, ¿no?

image

 

Registro: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032551090&Culture=es-AR&community=0

Saludos @ Home

El Bruno

image image image

[# ALM] 1. ALM in 2012, refactorizando our way of working.

Hi,

in these days when the thing is quite complicated, one of the tools we have to move ahead is to improve the way in which we work. Those who work in computer science we know that for quite some time the stereotype of repetitive work from 0900 to 1700, for 30 years on the same site, it is impossible. Jose Manuel Alarcon has written a very good post in this connection, called the "Artisans of knowledge", and one of the points that most highlights in this post is the constant need to improve that we have in our profession.

But beware, many people have misunderstood the message. They think that what we have to do is keep abreast of all new technologies that appear, know all the new products coming out and worship any new trend that promises a bright and peaceful future. When is this only 10% of our new responsibility. 90% Is a little more complicated, it requires that we apply that very often we use which is one meter above our ass (a metro approximately, though there are many cases that the ass is connected to the brain). In the remaining 90% is required to think, is required to learn from the experiences that we propose changes to improve the way in which we work and knowledge we possess.

For example, is very simple to be subscribed to the 10 most influential blogs in the the blogosphere, and follow the 10 cracks think more on different topics of computer science. With spend 60 minutes a day to read these blogs and give you a quick look at twitter every, we can be aware of the news. We changed the form of craftsmanship of our fathers, where you aprendías a profession for life; and we will implement a new premise which is that of constant training. We can have a more advanced social status, where our colleagues we will look at and you may wonder how things: "from where it takes time to keep abreast of everything?"; and we even have a fan club in the best style of Justin Bieber.

However if all this information we read not we process correctly, this way of working is useless. We not only have to read, we have to learn to learn. In the management of software projects is essential to explore new forms of work, new tools and new trends; but it is much more important to understand how we can apply them to a particular scenario to get good results. We need to know, that there are no magic formulas that solve all problems; and also a technique as old as the "refactoring" not only is applicable to developments but also to the way of work and management.

In many cases, there are people/organizations that care to define "a process" which would be useful both for 2-month development projects, to projects of 2 years. That also serves also for teams of 5 people and teams of 200 people; and finally, that it can be used for teams that work all in the same place, as for distributed work teams. When we find ourselves in these cases, it is not uncommon to create this process will be invested in a two-year project. Where, obviously, are the premises on January 1, 2010 not the same that the premises to January 1, 2012, etc. etc. etc.

In the previous case, surely the extreme agilistas will have more than one ulcer and begin to evangelize with the ABC’s ofKent Beck on AGILE and trends of the past 10 years. On the other hand, the lovers of the processes, will be dedicated to destroying the Amazon creating manuals of processes covering 1000 situations will never in any process, and that will then be a book died in some closet organization. Surely there will be a 3rd line of work, which will try to meet the real needs of the person/organization and on the basis thereof; It will create a proposal with a solution. In each case, does not help the proposed solution, but we consider that each a period of time we have to look at the way in which we are working and see if we can improve it.

Worldwide AGILE this is known as a retrospective, and all the agilistas I know are lovers of creating retrospective meetings. However, these badly conducted meetings, only represent a waste of time that little brings to a project and much less to an organization. As I am not going to write about this in this post, will leave the reference to a book that I loved about this item > Agile Retrospectives: Making Good Team Great (http://pragprog.com/book/dlret/agile-retrospectives). In CMMI is also taken into account this model, something the "I" is for Improvement and the "M" Model. For (understood) CMMI, processes, people and tools have the same value in the values triangle. Mind you, that you may like or not, but is a way of organizing and managing it is also valid in many cases. If you want to invest money in a book that will explain you the same as CMMI guides, but with a more human touch, therefore CMMI for Development ®: Guidelines for Process Integration and Product Improvement (http://www.amazon.com/CMMI-Development-Integration-Improvement-Engineering/dp/0321711505/ref=cm_cr_pr_product_top )).

In short, the constant improvement of the way in which we work is as important as the technologies with which we work.What is more, explore new forms of work will help us to improve the guidelines with which we are working and will also not help a broader perspective on how we can work.

But before concluding, I must point out 2 big problems we have in this aspect. On the one hand, be aware of "all the latest" leads to situations like that says Rodrigo Corral in this tweet.

We have failed with Scrum is not a reason to adopt Kanban. The reason must be that Kanban is what best fits your needs.

image

The mere fact that something fails, and there is an alternative solution does not mean that we should adopt her as soon as possible. How many times I’ve seen what says Rodrigo, I could not resist to respond with a somewhat annoying analogy:

@r_corral do can also be applied > > "I’ve had an accident in car, I now switch to the motorbike;" better learn to drive not?

image

Finally, the 2nd problem is as follows:

How is that the problems in computer science remain equal today than those we had 20 years ago it possible?

It seems a contradiction, since methodologies such as SCRUM are born by the 1993 beyond, but even today we still have the same problems. I wrote my opinion on this in my book, and I see that the post is a little long, I leave it to pending for another post.

Greetings @ Home

The Bruno

Links

[#ALM] 1. ALM en 2012, refactorizando nuestra forma de trabajo.

Buenas,

en estos días cuando la cosa está bastante complicada, una de las herramientas que tenemos para salir adelante es mejorar la forma en la que trabajamos. Los que trabajamos en informática sabemos que desde hace bastante tiempo el estereotipo de trabajo repetitivo de 0900 a 1700, durante 30 años en el mismo sitio, es un imposible. Jose Manuel Alarcon ha escrito un post muy bueno al respecto, llamado “Artesanos del Conocimiento”, y uno de los puntos que más resalta en este post es la necesidad constante de mejorar que tenemos en nuestra profesión.

Pero cuidado, muchas personas han entendido mal el mensaje. Piensan que lo que tenemos que hacer es estar al día de todas las nuevas tecnologías que van apareciendo, conocer todos los nuevos productos que salen y adorar a cualquier nueva tendencia que prometa un futuro más brillante y pacífico. Cuando esto es solo un 10% de nuestra nueva responsabilidad. El otro 90% es un poco más complicado, ya que requiere que apliquemos eso que pocas veces utilizamos que se encuentra un metro por encima de nuestro culo (un metro aproximadamente, aunque existen muchos casos que el culo está conectado directamente con el cerebro). En este 90% restante se requiere pensar, se requiere aprender de los conocimientos que poseemos y a partir de las experiencias que tenemos, proponer cambios para mejorar la forma en la que trabajamos.

Por ejemplo, es muy simple estar suscrito a los 10 blogs más influyentes del la blogosfera y seguir a los 10 cracks que más opinan sobre diferentes temas de informática. Con dedicar 60 minutos al día a leer estos blogs, y darle un rápido vistazo al twitter cada tanto, ya podremos estar al tanto de todas las novedades. Habremos cambiado la forma de trabajo artesanal de nuestros padres, donde aprendías una profesión para toda la vida; y aplicaremos una nueva premisa que es la de la formación constante. Podremos tener un status social más avanzado, donde nuestros compañeros nos mirarán y se preguntarán cosas cómo: “¿De dónde saca tiempo para estar al día de todo?”; e incluso podremos llegar a tener un club de fan al mejor estilo de Justin Bieber.

Sin embargo si a toda esta información que leemos no la procesamos correctamente, esta forma de trabajo no sirve para nada. No sólo tenemos que leer, tenemos que aprender a aprender. En la gestión de proyectos informáticos es imprescindible conocer nuevas formas de trabajo, nuevas herramientas y nuevas tendencias; pero es mucho más importante entender como podemos aplicar las mismas a un escenario concreto para obtener buenos resultados. Tenemos que saber, que no hay fórmulas mágicas que solucionen todos los problemas; y que además una técnica tan vieja como el “refactoring” no solo es aplicable a los desarrollos sino también a la forma de trabajo y de gestión.

En muchos casos, existen personas/organizaciones que se esmeran por definir “un proceso” que sea útil tanto para proyectos de desarrollo de 2 meses de duración, como para proyectos de 2 años. Que además también sirva para equipos de trabajo de 5 personas y para equipos de 200 personas; y finalmente, que se pueda utilizar para equipos de trabajo que trabajen todos en el mismo sitio, como para equipos de trabajo distribuidos. Cuando nos encontramos en estos casos, no es raro que para crear este proceso se esté invirtiendo en un proyecto de 2 años de duración. Donde, obviamente, las premisas al día 1 de enero de 2010 no son las mismas que las premisas al 1 de enero de 2012, etc. etc. etc.

En el caso anterior, seguramente los agilistas extremos tendrán más de una úlcera y comenzarán a evangelizar con el ABC de Kent Beck sobre AGILE y las tendencias de los últimos 10 años. Por otra parte, los amantes de los procesos, se dedicarán a destruir el Amazonas creando manuales de procesos que contemplan 1000 situaciones que nunca se darán en ningún proceso, y que luego serán un libro muerto en algún armario de una organización. Seguramente existirá una 3ra línea de trabajo, que intentará conocer las necesidades reales de esta persona/organización y a partir de las mismas; creará una propuesta con una solución. En todos los casos, no sirve de nada la solución propuesta, sino tenemos en cuenta que cada un período determinado tenemos que analizar la forma en la que estamos trabajando y ver si podemos mejorar la misma.

En el mundo AGILE esto se conoce como una retrospectiva, y TODOS los agilistas que conozco son amantes de crear reuniones de retrospectiva. Sin embargo, estas reuniones mal llevadas, solo suponen una pérdida de tiempo que poco aporta a un proyecto y mucho menos a una organización. Como no voy a escribir de esto en este post, dejaré la referencia a un libro que me ha encantado sobre este tema > Agile Retrospectives: Making Good Team Great (http://pragprog.com/book/dlret/agile-retrospectives).  En CMMI también se toma en cuenta este modelo, por algo la “I” es de Improvement y la de “M” de Model. Para CMMI (bien entendido), los procesos, las personas y las herramientas tienen el mismo valor en el triángulo de valores. Cuidado, esto te puede gustar o no, pero es una forma de organizar y de gestionar que también es válida en muchos casos. Si quieres invertir dinero en un libro que te explicará lo mismo que las guías de CMMI, pero con un toque más humano, pues CMMI for Development®: Guidelines for Process Integration and Product Improvement (http://www.amazon.com/CMMI-Development-Integration-Improvement-Engineering/dp/0321711505/ref=cm_cr_pr_product_top).

En resumen, la mejora constante de la forma en la que trabajamos es igual de importante que las tecnologías con las que trabajamos. Es más, conocer nuevas formas de trabajo nos ayudará a mejorar las guías con las que estamos trabajando y además no ayudará a tener una perspectiva más amplia sobre cómo podemos trabajar.

Pero antes de terminar, tengo que señalar 2 problemas grandes que tenemos en este aspecto. Por un lado, el estar al tanto de “todo lo último” nos lleva a situaciones como la que comenta Rodrigo Corral en este tweet.

Hemos fallado con Scrum no es un motivo para adoptar Kanban. El motivo debe ser que Kanban es lo que mejor se adapta a tus necesidades.

image

El solo hecho de que algo falle, y que exista una solución alternativa no significa que la debamos adoptar lo antes posible. Como muchas veces he visto lo que comenta Rodrigo, no he podido resistirme a responder con una analogía un tanto molesta:

@r_corral también se puede aplicar >> "he tenido un accidente en coche, ahora me cambio a la moto"; mejor aprender a conducir no?

image

Finalmente, el 2do problema es el siguiente:

¿Cómo es posible que los problemas en la informática sigan siendo iguales hoy que los que teníamos hace 20 años?

Parece una contradicción, ya que metodologías como SCRUM nacen allá por el 1993, pero todavía hoy seguimos teniendo los mismos problemas. Yo escribí mi opinión al respecto en mi libro, y como veo que el post es un poco largo, lo dejo como pendiente para otro post.

 

Saludos @ Home

El Bruno

   

Links

[BOOK] I have read: The # Agile Samurai

Cover Image For The Agile Samurai

Good,

While I read it on vacation, I have pending for quite some time to do a review of this excellent book by Jonathan Rasmusson (take a stroll through your blog is already a pleasure):

THE AGILE SAMURAI

Few, very few pages, JR gives an overview to the basic principles of the management of development projects with Agile; management requirements (user stories if you’re very retailer), the day to day development, and many conclusions on work in general. The interesting thing about the book, is that it raises all the concepts that you already know (but maybe don’t use) so naturally that you get to work with their councils as soon as possible.

Another point that I liked is that the book is riddled with images, which are fairly representative. It is not the classic chart created to explain a concept or idea, but rather a kind comic that with 2 trace lets you clear a concept drawing. For example, see the following image for the exercise of allocation of Points to US

Basatante clear not? read the full post at http://agilewarrior.wordpress.com/2011/11/13/self-inflicted-scope-creep/ and you’ll see that the theme of the management of scope and expectations is very sensitive in a project. It is like a return to the origins > > it tells you what you already know but give you wanted to work this way. Since the beginning of a project, where you have to be very clear to all participants of the project, then it > will participate; everyone should have the ideas, clear, etc. He speaks a bit of refactoring, continuous integration, etc.; We are going is an everything a bit very, very interesting.

Finally, this book is not code, but rather the correct selection of the practices of AGILE to work in software development projects. It can be so useful for a person to develop in single developer mode, and a development team that wants to start with AGILE or improve practices that have been implemented.

Can find you it here > > http://pragprog.com/book/jtrap/the-agile-samurai

Greetings @ Here

The Bruno

[BOOK] He Leído: The #Agile Samurai

Cover Image For The Agile Samurai

Buenas,

Si bien lo leí en vacaciones, tengo pendiente desde hace bastante tiempo el hacer un review de este excelente libro de Jonathan Rasmusson (dar una vuelta por su  blog ya es un placer):

THE AGILE SAMURAI

En pocas, muy poca páginas, JR da un repaso a los principios básicos de la gestión de proyectos de desarrollo con Agile; la gestión de requerimientos (user stories si sos muy detallista), el día a día de desarrollo, y muchas conclusiones sobre el trabajo en general. Lo más interesante del libro, es que plantea todos los conceptos que ya conoces (pero tal vez no utilizas) de una forma tan natural que te dan ganas de trabajar con sus concejos lo antes posible.

Otro punto que me ha gustado mucho es que el libro viene plagado de imágenes, que son bastante representativas. No se trata del clásico chart creado para explicar un concepto o idea, sino más bien un dibujo tipo comic que con 2 trazas te deja claro un concepto. Por ejemplo, mira la siguiente imagen para el ejercicio de asignación de Points a US

¿Basatante claro no? pues lee el post completo en http://agilewarrior.wordpress.com/2011/11/13/self-inflicted-scope-creep/ y verás que el tema de la gestión de alcances y expectativas es muy delicado en un proyecto. Es como una vuelta a los orígenes >> te cuenta lo que ya sabes pero te dan ganas de trabajar de esta forma. Desde el comienzo de un proyecto, donde tienes que tener muy en claro que TODOS los participantes del proyecto, pues eso mismo > van a participar; todo el mundo tiene que tener las ideas, claras, etc. Habla un poco de refactoring, de integración continua, etc.; vamos que es un de todo un poco muy pero muy interesante.

Finalmente, este libro no se trata de código, sino más bien de la correcta selección de las prácticas de AGILE para trabajar en proyectos de desarrollo de software. Puede ser tan útil para una persona que desarrolle en single developer mode, como para un equipo de desarrollo que quiera comenzar con AGILE o mejorar las prácticas que vienen aplicando.

Lo puedes encontrar aquí >> http://pragprog.com/book/jtrap/the-agile-samurai

Saludos @ Here

El Bruno

   

[ALM] Do I have to follow all the rules of a work methodology?

Hi,

yesterday between such exit Windows 8, there was a series of tweets between @ lfraile, @ javierholguera, @ r_corral and signing the post (which perhaps not that writes), where discuíamos the subject follow or not follow those guides that they propose us certain work as e.g. SCRUM methodologies.

So where have understood the context, Javier is asking if SCRUM is the form of work that best fits his scenario work, that he understands that he has to finish an iteration to release the result of the implementation of the users stories that have been defined for the same. I guess that it is why is being a little try KANBAN to manage its work, since in this way. For example, in the following table we see that if the WIP team is 5, the tasks that are about to close are the D, E, G and H;and that the released features in A and B can already prove.

image

As well, that helps in KANBAN have a closed element when”closed” and not having to wait for end of an iteration to release it.

But why not change the scope of a Sprint? (vale have already spoken of iterations, change to SCRUM mode)… then because the great Ken Schwaber in his book “AGILE PROJECT MANAGEMENT WITH SCRUM”, in addition to closing within 30 days the fixed period for a SPRINT, reads as follows:

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

(page 136)

Reading this at the bottom of the letter and being very hard in the SCRUM  implementation; if during a sprint I have in estimated close 3 elements, I have to wait until the end of the sprint to unlock these 3 elements.

But it is very common to arise the following questions:

  • What happens if I work in a team that creates common elements for other teams, and the first element is crucial so that another computer can continue working?
  • should I do if my computer is able to deliver this item within 15 days, but the sprint is closed in 30 days?
  • KenS proposes 30 days sprints, I change the size of a sprint?

Okay, we get to the interesting point:

I jump I rules/obligations that brings each methodology?

Because there is no correct answer for this. From my experience I always recommend a way of working with the same in-depth knowledge, learn to use what you really need.

An example, a while ago I participated in a project with a partner where we advise by SCRUM recommendations (based onTFS2010 and MSF for AGILE 5.0). But… not used to do daily scrum meetings! !!! If if if I already know it, the gurus of SCRUM creaking me. I am a sacrilegious, I’m not worthy, etc. If for KS, both should be close to €100 to the piggy bank, should always have the meeting in the same place, etc.; Let KS us kills.

But my question was, what we will do a Daily Scrum Meeting if both sitting side by side, we share 15 minutes from cafe where we talk about football, gadgets and the project;? do and also compatirmos hours of beers where also hablamso of the same?. Let that not need us.

When I think a bit, I see that this is part of my way of being. As I am a person who live on the edge, in the earlier draft which I shared with the partner nor did “stand-up meetings” (now changed to AGILE), after working briefly with a person you know and that can help quite a teamwork dynamics.

Clarification: This does not mean that the practice of the SUM is highly recommended, moreover there is an article on the site of Martin Fowler describing some recommendations to bring this type of meeting.

Personally, I think that without making the DSM not complicit work mode SCRUM. But we saltábamos the rules based on our experience and because we knew that this was the best way to work.

Now is time to ask, what I try to make everyone to ask:

Can I change the way in which I work to be more effective, without losing quality?

Because there you you have.

Greetings @ Home

The Bruno

   

PS: the Kanban chart is the new librako that I am just finishing, to see if I make a post/contest to see that title I put book.

PD2: I know that one after reading this will fail to read my blog… therefore more relief for the internet Open-mouthed smile

[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 radica en la implmentación de SCRUM, si durante un sprint yo tengo en 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