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


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.


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?


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


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


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.


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?


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