[#TFS2013] TFS 2013 Update 4 Release Candidate, los #Bugs en el #Kanban board y propone cambios que es gratis

Seychelles

Hola!

hace ya más de un año que escribí un post donde comenté como modificar la configuración por defecto en TFS2012 para poder usar los WI de tipo Bug en un tablero Kanban. Con el tiempo llegó TFS 2013 y claro al momento de actualizar había que retocar un poco el TP actualizado ya que los cambios se perdían en el camino, así que fue momento para escribir otro post.

Y ahora con la llegada del update 4 de Team Foundation Server 2013 (por ahora en Release Candidate) creo que podré dar por finalizados estos posts ya que la funcionalidad de trabajar con BUGs en los tableros viene de fábrica ;)

Hace un par de días lo explicó Brian Harry en su blog, junto con las demás novedades para Visual Studio y Team Foundation Server que incluye el Update 4. Lo interesante de esta feature es que tenía más de 100 votos en la sección de User Voice donde TODOS pueden proponer mejoras y ayudar con las herramientas de ALM de Microsoft.

Así que ahora no hay excusas:

¿A qué no sabías que entrando a este link podias proponer cambios y mejoras para Visual Studio y Team Foundation?

User Voice Visual Studio : http://visualstudio.uservoice.com/forums/121579-visual-studio

Saludos

/El Bruno

Fuente: http://blogs.msdn.com/b/bharry/archive/2014/10/16/visual-studio-and-tfs-2013-4-update-4-release-candidate.aspx

[#TFS2012] Problems when you update to TFS2013: use with boards #Kanban #Bug in the #CMMI template

image

Hello!

Almost a year ago I wrote a step by step with an option to have Bugs in the Team Foundation Server 2012 KanbanBoard. (here the post). As at the time of the partitioning powers did me not nor that of guapo, or guess the future; I could not foresee that this not be carried well with migration TFS2013.

Today, called me Gaby (@gabobing) from Málaga informing me that when you are migrating from 2012 to 2013, the vista board is lost. That Yes, if the changes are rolled back everything works.

We have also reviewed it with Gaby and Edu (@edudelpozo) and we have reached the following conclusions

  • Is undo the change to lose the customization?
  • Yes, and more obvious than the 2 table
  • If you do it again it works?
    • Have not but I bet a beer that would run ;-)
  • Do the historic loses with these changes?
    • Not lost since we do to customize the board doesn’t impact on the historical changes of the WIs…

    So now you know, as always if you play much a product you will suffer with the upgrade. In this case, not so much, since the bugs still ‘out there’, although it is necessary to undo and redo the steps to have them on board.

    post Original: [#TFS2012] HowTo: manage #Bugs with with #Kanban boards in the #CMMI template

  • Saludos @ La Finca

    El Bruno

    image image image Google

    [#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