[#TFS2012] Problemas cuando actualizas a TFS2013: Usar #Bug con tableros #Kanban en la plantilla de #CMMI

image

Hola!

Hace casi un año escribí un paso a paso con una opción para poder tener Bugs en el tablero Kanban de Team Foundation Server 2012. (aquí el post). Como al momento de repartir poderes no me dieron ni el de guapo, ni el de adivinar el futuro; no pude preveer que esto no se llevaría bien con la migración a TFS2013.

Hoy me llama Gaby (@gabobing)desde Málaga informándome que cuando se migra de 2012 a 2013, se pierde la vista board. Eso si, si se deshacen los cambios todo funciona.

Lo hemos revisado además con Gaby y con Edu (@edudelpozo) y hemos llegado a las siguientes conclusiones

  • Deshacer el cambio es perder la customización?
  • Sí, y más obvio que la tabla del 2
  • Si la haces de nuevo funciona?
    • No lo hemos hecho pero me apuesto una cerveza a que sí funcionaría ;-)
  • El histórico se pierde con estos cambios?
    • No se pierde dado que lo que hacemos al personalizar el board no impacta en el histórico de cambios de los WIs…

    Así que ya sabes, como siempre si tocas mucho un producto sufrirás con el upgrade. En este caso, no tanto, ya que los bugs siguen “allí”, aunque hay que deshacer y hacer de nuevo los pasos para poder tener los mismos en el tablero.

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

    Saludos @ Home

    El Bruno

    image image image Google

    [#TFS] Why my Visual Studio goes so slow? It may be because the workspace is in LOCAL mode

    Hello!

    Now it’s nostalgic moment and time for a bit of history with Team Foundation Version Control. Since the release of TFS2012 we have the possibility to create workspaces in two modes: local and server. Local mode, is a kind of “workaround” which allows us to work comfortably offline.

    Obviously you don’t have as much power as a Git repo, however is very useful if your Team Project uses TFVC. Now, the inner workings of a local Worspace relies on a Windows process that verifies the changes that exist in a directory.

    The problem usually occurs when these directories contain several thousands of files and the size is closer to 1GB. At that time, Visual Studio begins to “become a very slow app“. Simple actions such as adding or refreshing a NuGet package, may take several minutes.

    In reality, this is because the local workspaces were not designed to work with “many files”, the workspaces in server mode are recommended for this 2nd scenario.

    Note: here we have a loophole where is hard to know if”many files may be 1 or 500 or 500000 or…”

    Luckily, the solution is simple. In the edition of your workspace, you change it locally to server mode.

    image

    You’ll see how they disappear hidden files $tf and in addition your Visual Studio comes to life.

    image

    At this point also worth rethinking other options such as

    -I really need a unique mapping on the root of my Source Control, or I can create mappings for only the folders that I use?

    -It should be put into mode cloack some folders?

    I think that with this, I know already 4 that I have made them the d to.

    References:

    -Far reach the local workspaces? (link)

    Saludos @ La Finca

    El Bruno

    image image image Google

    [#TFS] Porque mi Visual Studio va tan lento? puede ser por el workspace en modo LOCAL

    Hola!

    Ahora toca momento nostálgico y un poco de historia con Team Foundation Version Control. Desde la versión de TFS2012 tenemos la posibilidad de crear workspaces en modo local y server. El modo local, es una especie de “ñapa” que nos permite trabajar de una forma cómoda sin conexión.

    Obviamente que no tiene tanta potencia como un repo de Git, sin embargo es bastante útil si tu Team Project utiliza TFVC. Ahora bien, el funcionamiento interno de un Worspace local se basa en un proceso de Windows que verifica los cambios que existen en un directorio.

    El problema suele darse cuando estos directorios contienen varios millares de archivos y llegan o pasan el 1GB de tamaño. En ese momento, Visual Studio comienza a “ponerse lento”. Acciones tan simples como agregar o refrescar un paquete NuGet, puede tardar varios minutos.

    En realidad esto es porque los workspaces locales no fueron pensado para trabajar con “muchos archivos”, para este 2do caso se recomiendan los workspaces en modo server.

    Nota: aquí tenemos un vacío legal donde “muchos archivos, puede ser 1 o 500 o 500000 o …

    Por suerte, la solución es más que simple. En la edición de tu workspace lo cambias de modo local a modo server.

    image

    Verás como desaparecen los archivos ocultos $tf y como además tu Visual Studio vuelve a la vida.

    image

    En este punto también vale la pena replantearse otras opciones como por ejemplo

    - Realmente necesito un único mapeo en la raíz de mi Source Control, o puedo crear mappings solo para los folders que utilizo?

    - Debería poner en modo cloack algunos folders?

    Creo que con esto, ya conozco a 4 a los que les he alegrado el día.

    Referencias:

    - Hasta donde llegan los workspaces locales? (link)

    Saludos @ Home

    El Bruno

    image image image Google

    [#SCRUM] Y el delicado camino a la incompetencia

    Hola!

    Todos sabemos que Scrum es la solución a todos los problemas. En la página 12 de la guía de Scrum hay una frase que dice lo siguiente:

    Scrum Hoch bIquv qay’ taS

    Que traducido del Klingon viene a significar

    Scrum es la solución para todo tipo de problemas

    Y listo! Ahora bien, si analizamos los 3 pilares de Scrum: Transparencia, Inspección y Adaptación; los mismos nos indican que un equipo a medida que utiliza Scrum, aprende a ser más eficiente. La base de esta teoría es que el equipo sea independiente y tenga capacidad de autogestión.

    Sin embargo, esto último también puede terminar con un efecto boomerang: Un equipo puede ir a peor ejecutando Scrum. Y es que, no todos las personas que trabajan en nuestro rubro cumplen con la premisa de “Scrum no es para aficionados”.

    Es normal que un equipo, cuando comienza a gestionarse, los resultados no sean los esperados. Es ese punto donde la inspección y adaptación ayudan a que el equipo pueda comenzar a mejorar. Sin embargo, también existe la posibilidad de que un equipo nunca mejore. Que siempre el listón este muy bajo y que no exista un análisis interno de inspección y adaptacion. (Aclaración: en estos casos la transparencia suele estar cercana al 95% de opacidad)

    ¿Y qué hacer en estos casos? Una opción es volver a dar soporte al equipo, que popularmente lo comparo con criar niños de 3 años. Ayudar en cada paso, ser el facilitador, etc. Un poco de Scrum Master con el rol de padre. Y hasta aquí debes llegar, luego de un par de Sprints es momento de volver a evaluar si el equipo es autosuficiente. En caso contrario … pues cambia el equipo.

    Es una pena, sin embargo la motivación con la que algunas personas llevan adelante su trabajo no es la misma que la que tienen otras. Y en el caso de los trabajos con tecnología esta motivación suele ser intrínseca, con lo que los “premios a corto plazo” son una tapadera muy poco productiva.

    Una forma de explicar esto es la práctica de “El que rompe la build pone 1€ en un frasco”. El objetivo de práctica no es asustar para que los developers se desangren poniendo miles de €uros (yo lo he hecho), ni tampoco es recaudar para las cervezas de los jueves (también lo he hecho). Esta práctica implica un trabajo de fondo, donde cada persona es suficientemente consciente de que la calidad no es opcional y de que romper la build es detener el equipo en marcha. Y esto es suficiente, muchas personas lo entienden, otras lo ven como una gracia.

    Asi que bien, Scrum puede servir para que los equipos aprendan a autogestionarse y a mejorar sprint a sprint; y también sirve para detectar equipos que no poseen ganas de mejorar y .. bueno que tal vez sea necesario cambiar.

     

    Scrum Guide: https://www.scrum.org/Scrum-Guide

    Scrum no es para aficionados: http://elbruno.com/2013/12/24/scrum-scrum-no-es-para-aficionados/

    Saludos @ Home

    El Bruno

    image image image Google

    [#ALM] Improve the way your team works, forget #emails; Welcome to #Yammer or #Beezy or whatever you want!

    image

    Hello!

    Today I will try to contribute my experience on improving my team collaboration by not using email at work. Communication experts will have much more to contribute to the subject, and sociologists for sure will address the issue of the current generation Y and how it works in a different way…

    For my is easy: “I don’t like reading emails“. Don’t get me wrong, the email is an excellent tool. However, in recent years it has become more and more useless tool. I can take from my OneNote notes more than 20 notes about this, let’s start with only 3.

    • Many people write emails with much content inside. I mean loooooong emails, if the person or persons who will be directed to this email address, have 100 emails or more per day, they most likely to pass it. This information is “lost” and for every single companies, this is the worst scenario that can happen.
    • The timing is also essential, remember emails are only in “output direction channel” for you. Many times an email inside contains too high a level of importance for an asynchronous channel.
    • Finally, Please email usually means a “that’s it for me”. I mean, when a person has a responsibility and must share it with someone else, a habitual behavior usually send an email. This is not bad, what is bad is that occasionally when adjusting work we have answers of the type “sent an email to Juan and not responded“. All of this said with the conviction that the act of sending an e-mail was just enough.

    In the previous examples the main problem tends to be the feeling of detachment that gives us the email. Those who know football, will know the term “pass the ball”. For a team this is very counterproductive, the opposite we want, we always try to promote team collaboration. Challenging a specific problem, a group of minds becomes a better solution than a single head.

    In addition there are behaviors associated with emails which tend to be quite harmful to a team.

    • The complex of “Zero Inbox“, which forces people to read everything in your INBOX. I know people who has become obsessed with this topic.
    • Another that is great is people living with the paranoia of “why I don’t get and answer?”. A classic in some cases tends to be, someone calls you and tells you: ‘ I just sent you an email, as I not get an answer I call for… ” and you get into verbal communication which is usually much more effective.

    Here part of everything “bad” that we associate with when we wrong use of our tools. Now, to make a change and improve we can use other tools.

    In a team Kanban boards usually are excellent for tracking and managing work. In a distributed team or where are handled different times, the natural choice has always been the mail. I for some time I have stopped using the mail (in the areas in which I can) and we use Yammer.

    image

    The truth is that the result is great and it has helped me to have an calmer Outlook. Here are some experiences that are worth sharing:

    • The first thing that strikes me is that no longer exist that feeling of “you’ve gone the problem”. When working on a shared wall, the general feeling is that everyone shares responsibility for what she speaks and shares in it. (Values of Scrum + 1)
    • In the same way, it does not need to “read everything that is on the wall”. When a team begins to work with a product type Yammer or Beezy, the same team is maturing to a point where the wall contains important information for the project.
    • If you want to work with a Wiki, I recommend any product of this type, or even OneNote. A wall of messages will not replace a Wiki, however it can become an excellent compilation of the type information: FAQ, Support Cases, etc.

    As a concrete example of the agility that provides this type of tools, today I have commented on a group of Yammer time to came it to Seattle within 2 days and I have companion of taxi to the hotel. Excellent opportunity for a bit of networking, and to… speak ill of emails!

    Saludos @ Home

    El Bruno

    image image image Google

    [#ALM] Si quieres que tu equipo mejore, deja de lado los #emails; welcome to #Yammer o #Beezy o lo que prefieras !!!

    image

    Hola!

    Hoy intentaré aportar mi experiencia sobre la mejora que supone no usar emails en el trabajo. Los expertos en comunicación tendrán mucho más que aportar al tema, y los sociólogos seguro que abordarán el tema hablando de la generación Y y sobre como la misma funciona de una forma diferente..

    En mi caso es más simple: “no me gusta leer emails”. No me malinterpreten, el correo electrónico es una excelente herramienta. Sin embargo, en los últimos años se ha pervertido y de que manera. Podría sacar los apuntes del OneNote y poner más de 20 puntos, lo limitaré a 3.

    • Muchas personas escriben emails con muchísimo contenido dentro. Si la persona o personas a las que va dirigido este email, tienen 100 emails o más por día, lo más probable es que pasen del mismo. Esta información “se pierde” y en empresas que gestionan información, esto es lo peor que puede pasar.
    • El timíng también es esencial, recuerda los email son solo de salida. Muchas veces un email contiene dentro un nivel de importancia demasiado alto para un canal asíncrono.
    • Finalmente, enviar un correo suele significar un “hasta aquí he llegado yo”. Me explico, cuando una persona tiene una responsabilidad y debe compartir la misma con alguien más, un comportamiento habitual suele ser enviar un email. Esto de por sí no está mal, lo que si está mal es que en ocasiones al momento de ajustar trabajo tenemos respuestas del tipo “envié un correo a Juan y el no ha respondido”. Todo esto dicho con el convencimiento de que la acción de enviar un correo era suficiente.

    En los ejemplos anteriores el principal problema suele ser la sensación de desapego que nos otorga el email. Los que conocen de futbol, conocerán el término “le pasó la pelota”. Esto en el trabajo de equipo es muy contraproducente, lo que casi siempre queremos impulsar en un equipo es la colaboración. Frente a un problema específico, un grupo de mentes llega a una mejor solución que una única cabeza.

    Además existen comportamientos asociados a los correos electrónicos que suelen ser bastante nocivos para un equipo.

    • El complejo de “Zero Inbox”, que obliga a las personas a leer TODO lo que tienen en su INBOX. Conozco a gente que ha llegado a estar obsesionada con este tema.
    • Otro que es buenísimo es las personas que viven con la paranoia de “¿porqué no me responden?”. Un clásico en algunos casos suele ser, ese compañero que te llama y te dice: “Te he enviado un email, como no me respondes te llamo para …” y claro, la vía oral suele ser mucho más efectiva.

    Hasta aquí parte de todo “lo malo” que podemos asociar cuando usamos mal nuestras herramientas. Ahora bien, para dar un cambio y mejorar podemos usar otras herramientas.

    En un equipo los tableros Kanban suelen ser un excelente medio de tracking y de gestión de trabajo. En un equipo distribuido o donde se manejen tiempos diferentes, la opción natural siempre ha sido el correo. Yo desde hace un tiempo he dejado de usar el correo (en los ámbitos en los que puedo) y utilizamos Yammer.

    image

    La verdad es que el resultado es genial y me ha ayudado a tener un Outlook más tranquilo. He aquí algunas experiencias que vale la pena compartir:

    • Lo primero que me llama la atención es que deja de existir ese sentimiento de “te he pasado el problema”. Al trabajar en un muro compartido, la sensación general es de que todo el mundo comparte la responsabilidad sobre lo que habla y comparte en el mismo. (Valores de Scrum +1)
    • De la misma manera, no hace falta que “leas todo lo que está en el muro”. Cuando un equipo comienza a trabajar con un producto tipo Yammer o Beezy, el mismo equipo va madurando hasta llegar a un punto donde el muro contiene información muy importante para el proyecto.
    • Si quieres trabajar con una Wiki, te recomiendo algún producto de este tipo o inclusive OneNote. Un muro de mensajes no reemplazará a una Wiki, sin embargo puede convertirse en un excelente recopilatorio de información del tipo: FAQ, Support Cases, etc.

    Como un ejemplo concreto de la agilidad que brinda este tipo de herramientas, hoy he comentado en un grupo de Yammer la hora a la llegaba a Seattle dentro de 2 días y ya tengo compañero de taxi hasta el hotel. Excelente oportunidad para un poco de networking, y para … hablar mal de los emails !!!!

    Saludos @ Home

    El Bruno

    image image image Google

    [#ALM] 3 Sprints, that’s what you need to get a team started seriously (and of course … let’s go Argentina!)

    image

    Hello!

    This year, I’ve combined events oriented to developers, with a more business-oriented events. The difference is large, but it is amazing when you start talking to “the boss” of a hospital and explains a framework like SCRUM. He understands the basis and, in 15 minutes later, we can begin to talk about how transparency can help him in his daily basis.

    Note: “the boss” is his personal presentation, this person is the director of a hospital and as has a title like CTO, CIO, CEO, CXXXXO the truth that tide.

    In the middle of the nice talk, he asked me a classic of team management,

    How long it takes a team to “start working well” under this framework?

    The question has history. In general, to run a framework like SCRUM , the team that adopts this framework must implement it correctly. However, it is almost more important than the organization / company or context within which the team works also creates and adopts the values of SCRUM. I ever wrote about in an organization is harder to SCRUM for that SCRUM out in.

    image

    Having said that, and having a team that understand and adopt the values and practices of SCRUM, most experts agree that 3 sprints is the ideal amount of time in which a team can measure their work and begin to be productive. This is separate from the duration of the sprint, it can be from 1 week to 4 weeks. The important thing is that the practices associated with it are met and that the retrospectives are carried out well, POs to understand its value at the moment of arming and prioritized Product Backlog, etc. If you’ve been able to work in a team during more than 3 Sprints, you’ll see how metrics like “velocity” really starts to make sense and as the pace of work of the team begins to be more dynamic.

    Returning to business events, this week I was in Nice at an event aimed at telecommunications companies. And once again, I was surprised to see as in the TELCO world, measurement of 3 weeks also applies to these types of projects. I was commenting on a similar theme with some people who are dedicated to create a layer of… software? on a “very special routers”, and at the time raised the possibility of posting their APIs on AZURE API Management, agree on how a complete cycle of several Sprints would need to start to have a serious idea of a co-ordinated team.

    image

    Now is time for me, so I can “cry a little” in my particular case. I work on very fast / short projects, and where the same objective carried out by more than 3 Sprints is an utopia. Another utopia is to think in the same team working more than 3 consecutive sprints (I call them elastic teams).

    My experience in this particular case is based on the following:

    • Even if people can change in a team, it is important to have one or more people who bring forward best practices learned during the history of the team. Never, I repeat never, you should completely change the members of your team.
    • People can change, but the lessons remain. Implement a Wiki or a similar repo is important. In our case, what works is a OneNote shared in OneDrive, for us this brings very good results.
    • Unless you know the consequences, do not force or twist best practices. For example, if you decide not to implement a CI cycle, you must be aware of the consequences that this brings. In my case I have learned these lessons badly and pulling long hours during nights out personal errors later. Now that I know the context and I know what I stand, a Scrum Master helps me to carry them out.
    • It is essential that the Definition of Done, DOD is very clear for all: team, Product Owner, cleaning lady and even your mother. The equipment change, the user stories evolve, but the quality of what is expected to deliver cannot be changed .
    • It is not a bad practice to change the DOD. You can only do this between Sprints, never should change a DOD in the midst of a Sprint.
    • Technical debt (Technical Debt) is something that I still don’t have a good advise to share. I know that there are parts of a solution where I’m sacrificing today to pay it tomorrow, and also at certain times forced us as a team to not sacrifice nothing. I have not clear. (I think I expressed it in the best way for 3 years in painting walls, changing diapers, and the technical debt)
    • Finally and fundamental, it drives the fluid inside your team communication. Using tools such as Skype or Lync, tries to be mostly face to face, etc. Unless you’re programming SKYNET, surely you’ll be creating an app for people, and work with people… all said no?

    Happy Sprinting!

    Incidentally, in a few days the WorldCup will start so VAMOS VAMOS ARGENTINA!

    image

     

    Saludos @ Home

    El Bruno

    image image image Google