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

[#ALM] 3 Sprints, eso es lo que necesitas para poder comenzar a ser “serios” (y claro … vamos vamos Argentina !!!)

image

Hola!

Este año, he combinado eventos orientados a developers, con eventos de un calibre más orientado a negocios. La diferencia es grande, sin embargo es increíble como puedes hablar con “el jefe” de un hospital y que vea un framework como SCRUM, que entienda las bases y que en 15 minutos podamos comenzar a hablar sobre como la transparencia puede ayudarle en su día a día.

Nota: lo de “el jefe” es por su presentación personal, resulta que esta persona es el director de uno de los hospitales de más renombre en Europa y tanto CTO, CIO, CEO, CXXXXO la verdad que marea.

Pues eso, que hablando con esta persona me preguntó un clásico de la gestión de equipos,

¿Cuanto tarda un equipo en comenzar a “trabajar bien” bajo este marco?

La pregunta tiene historia. Por lo general, para que un marco como SCRUM funcione, el equipo que adopta este marco debe implementarlo correctamente. Sin embargo, es casi más importante que la organización / empresa o contexto dentro del que trabaja este equipo también crea y adoptelos valores de SCRUM. Alguna vez escribí sobre cómo en una organización es más difícil SCRUM para adentro que SCRUM para afuera.

image

Dicho esto, y teniendo un equipo que comprenda y adopte los valores y prácticas de SCRUM, la mayoría de los expertos coinciden que 3 sprints es la medida ideal a partir de la cual, un equipo y su contexto comienzan a ser productivos. Esto es idependiente de la duración del sprint, puede ser 1 semana o 4 semanas; lo importante es que las prácticas asociadas al mismo se cumplan y que se realicen bien las retrospetivas, que los POs comprendan su valor al momento de armar y priorizar el Product Backlog, etc. Si has podido trabajar en un equipo durante más de 3 Sprints, verás como la métrica de la velocidad realmente comienza a tener sentido y como el ritmo de trabajo del equipo comienza a ser más dinámico.

Volviendo a eventos de negocio, esta semana estuve en Niza en un evento orientado a empresas de Telecomunicaciones. Y una vez más, me sorprendí al ver como en el mundo de las TELCO, la medida de 3 semanas también se aplica para esos tipos de proyectos. Estuve comentando un tema similar con unas personas que se dedican a crear una capa de … ¿software? sobre unos “routers muy especiales”, y al momento de plantear la posibilidad de publicar sus APIs sobre AZURE API Management, coincidimos en cómo sería necesario un ciclo completo de varios Sprints para poder comenzar a tener una idea seria de un equipo coordinado de trabajo.

image

En este momento me tocaría “llorar un poco” por mi caso particular. Donde trabajo en proyectos muy rápidos, y donde un mismo objetivo llevado adelante por más de 3 Sprints es una utopía, y ni hablar de un mismo equipo trabajando más de 3 sprints seguidos (equipos elásticos les llamo yo).

Mi experiencia para este caso particular me baso en lo siguiente:

  • Si bien las personas cambian, es importante tener una o más personas que sean las que lleven adelante las buenas prácticas aprendidas del equipo. Nunca, repito NUNCA, deberías cambiar por completo los integrantes de tu equipo.
  • Las personas cambian, pero las lecciones quedan. Implementar una Wiki o un repo similar es importante. En nuestro caso, lo que tnemos es un OneNote compartido en OneDrive y la verdad es que da resultados muy buenos.
  • A menos que conozcas las consecuencias, no fuerces las buenas práctias. Por ejemplo, si decides no implementar un ciclo de CI, debes ser consciente de las consecuencias que ello trae. En mi caso he aprendido estas lecciones de mala manera y tirando muchas horas durante noches para sacar adelante errores personales. Hoy que conozco el contexto y sé a lo que me atengo, un Scrum Master me ayuda a llevarlos adelante.
  • Es fundamental que la defnición de hecho (Definition of Done, DOD) esté clara para todos, equipo, Product Owner, la señora de la limpieza e inclusive para tu madre. Los equipos cambian, las user stories evolucionan, pero la calidad de lo que se espera entregar NO PUEDE CAMBIAR.
  • Tampoco es una mala práctica cambiar el DOD. Eso sí, solo entre Sprints, nunca debes cambiar un DOD en medio de un Sprint.
  • La deuda técnica (Technical Debt) es algo con lo que todavía no me centro. Sé que hay partes de una solución donde estoy sacrificando hoy para pagarlo mañana, y también en determinados momentos nos obligo como equipo a no sacrificar nada. No lo tengo claro. (creo que lo expresé de la mejor forma hace 3 años en Pintando muros, cambiando Pañales, y la Deuda Técnica)
  • Por último y fundamental, impulsa la comunicación fluida dentro de tu equipo. Utiliza herramientas como Skype o Lync, intenta que sea en su mayoría face to face, etc. Salvo que estes programando SKYNET, seguramente estarás creando una app para personas, y trabajas con personas … todo dicho no?

Happy Sprinting !!!

Por cierto, empieza el mundial en unos días asi que VAMOS VAMOS ARGENTINA !!!

image

Saludos @ Home

El Bruno

image image image Google

[#ALMRANGERS] Version Control Guide V3 (antes conocida como Branching and Merging Guide)

Hola!

 

Después de darles bastantes vueltas al asunto, los rangers han liberado una nueva versión de la guía de Branching y Merginng, o con su nuevo nombre: “Version Control Guie V3”. Est guía en realidad es un paso adelante en el camino de una filosofía no basada en regla sino en recomendaciones y buenas prácticas, luego cada equipo es lo suficientemente maduro para elegir el mejor camino.

Por ejemplo, ¿recuerdas mi post sobre no usar ramas en tu equipo de desarrollo? Lamentablemente eso fue lo que muchos entendieron del post, cuando en realidad el objetivo del post era intentar simpliicar el trabajo de un equipo implementando solo aquello que de valor a la solución sobre la que se trabaja … que me enrollo. Pues mira como empieza esta guía.

image

Impresionante! la guía recomienda comenzar sin una estrategia de branching, a partir de allí la solución emergerá con el tiempo.

Joyas como estas tiene varias dentro, la verdad es que RECOMIENDO LEER LA GUÍA, ahora se ha convertido en un excelente ejercicio para saber si vamos por el buen camino.

Descarga: http://vsarbranchingguide.codeplex.com/

Saludos @ Camino a Niza

El Bruno

imageimageimageGoogle