[#VS2013] Productivity Power Tools 2013, Welcome to Syntactic Lines!

Hola!

Si eres como yo de poner el tamaño de la fuente en 8 puntos, para poder ver “más código” de un único vistazo, seguramente esta nueva funcionalidade de las Productivity Power Tools 2013 te gustará.

La misma se llama Syntactic Lines y lo que hace es reducir un 25% del tamaño de las líneas en las que no haya ni letras ni números. De esta manera, las líneas “simples” de nuestro código quedan más pequeñas y el código queda más legible. (o más apretado, a elegir)

Este es el ejemplo oficial que presentan

image 

Pinta interesante, veré después de usarlo un poco si es realmente útil :

Descarga: http://visualstudiogallery.msdn.microsoft.com/dbcb8670-889e-4a54-a226-a48a15e4cace?SRC=VSIDE

Saludos @ Barcelona

El Bruno

image image image Google

[#ALM] #SCRUM, the #Atleti and the Cholo

image

Hello!

If you don’t like soccer / football I recommend that you keep not reading this post. Although we must differentiate between people who don’t like football and people who are “anti-football”. The people of the 2nd group are characterized by trying to impose their vision in any place and with any group of people (against the football of course). To this group I’ll always choose the option “Live and Let Die“. If you are the first maybe the post can get to you, if you’re of the 2nd you know Winking smile

This weekend the club Atlético de Madrid was proclaimed champion of the Spain Football League. After 10 years of domain of Real Madrid and Barcelona, we get to a point where a “small club” to win the most long and complicated competition. When I say “small” I do not mean the number of followers, but rather the economic capacity that reinforces this club. The large ones can invest millions year to year, it is very likely that Atletico Madrid has to sell any of their good players to be able to start the new campaign. (Let us not forget that football tries to be a noble sport, governed by the amazing capitalism laws)

The last thing I want to say, to put a bit of context is that equipment which has today the Atleti, is almost the same as your technician found almost 2 years (January 2012). At that time the team was going through a hard time. They were about to go to a worst category, they were out of the Copa del Rey and the morale of the Team was on the floor. Until Diego Pablo Simeone, also known as “El Cholo” arrives to the club.

I’m not into the club and I do not know El Cholo, but from the outside what is appreciated is that beyond working on the structure of the club, and invest in new signings, new faces or new forms; El Cholo decided to invest in the team, invest on people. They adopted an attitude of improvement in the field defined by a very simple and yet very powerful phrase: “we play match-by-match“. Not asked their players anything weird, just play the best they know in every match. And this result you can see 16 months later. I don’t think that anyone can find a more dedicated team than the Atleti. Their players play every game like it is the last game of their live. This probable make other clubs who have invested hundreds of millions in signings rethink if the right way to have a team is based on €uromillons.

And what does this have to do with Scrum? Does El Cholo make Sprints? Does Mono Burgos perform TDD? Neither one thing nor the other (remember that Scrum does not mean TDD) although if you see clearly, that there are many things that draw attention. For example:

-The plan of El Cholo was never long-term, always has been based on “match to match“. If you like football, surely you’ve noticed how he has been getting the better of each player testing and testing in every game until you have a very balanced and very good staff.

- People are important, and the experience is what is most valued. See today how the Atleti stays by injury with some very important low, however it covers them with others coming back to give the best of themselves. With a defined focus and constant work has allowed that the team is homogeneous and that there are no dependencies of key figures (eye, having a couple of cracks that will be in the history books). This in Scrum is known as adaptation .

-My personal Feeling about El Cholo, when he speaks, is transparency. This is because it would have to be there to meet him. However compared to other clubs, it seems that the Cholo remembers ken Schawber and is based on one of the 3 pillars to carry his campaign forward.

If you see it in perspective, you’ll see that it is just football; and that behind this there is a team with one goal clear. Also if you like the metrics you’ll see that El Cholo numbers are good, but the sensations that gives this team are best. And that is essential in a team, the sense of security that gives the same when it works. Everyone has to have that level of confidence to know that you will arrive on time, with a finished product. The Atleti today makes it, and in a natural way.

It is not SCRUM as we know it, however today the Atleti has emerged champion of the League, and next weekend to play the final of the Champions League in Lisbon with Real Madrid. I believe that the results are sure that more than one will be putting together a model session of team building based on the work of El Cholo Winking smile

PD: El Cholo Simeone once said the following words which explains his results-oriented philosophy: “keep faith, must be conviction, must have courage, have to assume some challenges, because that assumes no risk, and that no risks, no wins”.

References: The SCRUM Guide, https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf#zoom=100 

Saludos @ Barcelona

El Bruno

image image image Google

[#ALM] #SCRUM, el #Atleti y el Cholo

image

Hola!

Si no te gusta el futbol te recomiendo que no sigas leyendo este post. Aunque hay que diferenciar a los que no les gusta el futbol y a los que son “anti-futbol”. Las personas del 2do grupo se caracterizan por intentar imponer su visión en cualquier sitio y con cualquier grupo de personas en contra del futbol. En mi caso, “Live and Let Die” como dice la canción. Si eres de los primeros tal vez el post te interese, si eres de los 2dos pues ya sabes Winking smile

Este fin de semana el Atlético de Madrid se ha proclamado campeón de la liga de futbol en España. Después de 10 años de dominio del Real Madrid y del Barcelona, ha aparecido un club “pequeño” para llevarse la competición a largo plazo más complicada. Y ojo, que cuando digo pequeño no me refiero al número de seguidores, sino más bien a la capacidad económica que refuerza este club. Así como los grandes pueden seguir invirtiendo millones campaña a campaña, es muy probable que el Atlético de Madrid, tenga que vender a alguno de sus jugadores para poder comenzar la nueva campaña. (No nos olvidemos que el futbol intenta ser un deporte noble, regido pora las fabulosas leyes del capitalismo)

Lo último que quiero comentar, para poner un poco de contexto es que el equipo que tiene hoy el Atleti, es casi el mismo que encontró su técnico hace casi 2 años (enero de 2012). En ese momento el equipo estaba pasando por un mal rato. Estaban a punto de descender, fuera de la copa del rey y con la moral sobre el piso. Hasta que llegó Diego Pablo Simeone, también conocido como “El Cholo”.

No estoy dentro del club y no conozco al Cholo, pero desde fuera lo que se aprecia es que más allá de trabajar sobre la estructura del club, e invertir en nuevos fichajes, nuevas caras o nuevas formas; el Cholo decidió invertir en el equipo. Adoptó una actitud de mejora en el campo definida por una frase muy simple y a la vez muy potente: “jugamos partido a partido”. A sus jugadores no les pidió nada extraño, solo que jueguen lo mejor que saben. Y ese resultado se puede apreciar 16 meses después. No creo que nadie pueda encontrar un equipo más dedicado que el Atleti. Lo que corren sus jugadores en cada partido, hace que otros clubes que han invertido cientos de millones en fichajes se replanteen si la forma correcta de tener un equipo es a base de €uromillones.

Ya, ¿y esto que tiene que ver con Scrum? El Cholo hace Sprints? El Mono Burgos hace TDD? Ni una cosa ni la otra (recuerda que Scrum no significa TDD) Aunque si lo ves con claridad, sí que hay muchas cosas que llaman la atención. Por ejemplo:

- El plan del Cholo nunca fue a largo plazo, siempre se ha basado en “partido a partido”. Si te gusta el futbol, seguro que te has dado cuenta de cómo ha ido sacando lo mejor de cada jugador probando y probando en cada partido hasta tener una plantilla muy equilibrada y muy buena.

- Las personas son lo importante, y la experiencia es lo que más se valora. Hoy vemos cómo el Atleti se queda por lesión con unas bajas muy importantes, sin embargo cubre las mismas con otras personas que vuelven a dar lo mejor de sí. El trabajo constante y con un foco definido ha permitido que el equipo sea homogéneo y que no haya dependencias de figuras claves (ojo, que tienen un par de cracks que quedarán en los libros de historia). Esto en Scrum se conoce como Adaptación.

- La sensación que da el Cholo, cuando habla, es de Transparencia. Esto es relativo porque habría que estar allí para conocerlo. Sin embargo comparándolo con otros clubes, parece que el Cholo se acuerda de ken Schawber y se basa en uno de los 3 pilares para llevar adelante su campaña.

Si lo ves con perspectiva, verás que es simplemente futbol; y que detrás de esto hay un equipo con un objetivo en claro. Además si te gustan las métricas verás que los números del Cholo son buenos, pero las sensaciones que da este equipo son mejores. Y eso es fundamental en un equipo, la sensación de seguridad que da el mismo cuando trabaja. Todos tienen que tener ese nivel de confianza para saber que se llegará a tiempo, con un producto terminado. El Atleti hoy lo hace, y de una forma natural.

No es SCRUM como lo conocemos, sin embargo hoy el Atleti ha salido campeón de la liga, y el próximo fin de semana juega la final de la Champions League en Lisboa con el Real Madrid. Creo que los resultados saltan a la vista y seguro que más de uno estará armando un modelo de sesión de team building basado en el trabajo del Cholo Winking smile

PD: El Cholo Simeone una vez dijo las siguientes palabras que dejan clarauna filosofía de trabajo orientada a resultados: “hay que tener fe, hay que tener convicción, hay que tener coraje, hay que asumir ciertos desafíos, porque el que no asume no arriesga, y el que no arriesga, no gana”.

Referencias: La Guía de SCRUM, https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf#zoom=100

Saludos @ La Finca

El Bruno

image image image Google

[#ALM] Agile Customers are a #MustHave (and of course this to use Microsoft Feedback Client)

Hello!

Yesterday I make a statement: if we want to have visible results, the first distinction that we have to do; is not to be oriented in the technology trend (or architecture or development roles) but instead try to create a context orientated to the business itself; in this team work you’ll fin customers and the agile team. And of course, very a important part of it are clients or customers.

Caution! we should not confuse these roles with the Product Owner we know of SCRUM. According to the Guide, PO is the main author of the User Stories, he manages the Product Backlog, he defines the priority of the stories, he defines the acceptance tests, and he approves the work carried out by the Agile Team. However, that is not a “real customer”; a true customer is involved in an early stage and he is the one who detects a problem or a need and which will use the final solution created by the team. In an Agile Team it is very important to involve a person with the knowledge of business from day one, but the question always remains: Is this person a real reflection of a client?

Note:My short experience has taught me that when more time working with these experts from business, more we begin to know the business and can improve our solution. The tradeoff is that these SMEs also begin to learn how an Agile Team and are adapting to the team practices. This is not bad, however it can be counter-productive if not is valid with the other “clients”.

My answer to this is: The solution to meet an end customer, does not go through involving all clients within the development team, but instead think to plan some type of activity to obtain feedback from them. The concept of Agile Customer implies that we work partially with an on-site Customer (that in the long run you end up making the Product Owner and if you have good luck this work is not in part but full time). As an addition to this concept I would like to add the following activities

  • In a Sprint Review, integrate not only the familiar faces of the project; It tries to involve new people. At a previous session or at the beginning of the meeting, you spend time to explain the purpose of the Sprint Review and the dynamics of work; and he tries to get his feedback during the same.
  • Remember the 2 fundamental premises related to dealing with customers
  • Do not implement anything that has not been approved by a client
  • Nobody can replace an end user of the application
  • Use tools such as “Request Feedback” from Team Foundation Server or Visual Studio Online to engage these people and have a frequent Feedback on the progress of the application.

    image

    Finally, remember that while change is a constant, a closed version depends on the capacity that we have to manage the expectations of our customers. Be honest and be solution a success.

    References: If you want to know more about Microsoft Feedback Client you can see my posts here.

  • Saludos @ La Finca

    El Bruno

    image image image Google

    [#ALM] Welcome to Agile Customers (y porque no, Microsoft Feedback Client)

    Hola!

    Ayer quedó claro que, si queremos tener resultados visibles, la primera distinción que debemos realizar no tiene que estar orientada hacia la tecnología (o arquitectura o roles de desarrollo) sino al contexto donde se creará la solucion; este contexto está formado por customers y por el equipo de trabajo. Una parte muy importante de la misma son los clientes o customers.

    Ojo, no debemos confundir a estos roles con el Product Owner que conocemos de SCRUM. Según la guía el PO es el principal autor de las User Stories, maneja el Product Backlog, define la prioridad de las historias, define los tests de aceptación y aprueba el trabajo realizado por el Agile Team. Sin embargo, ese no es el “cliente”; el verdadero cliente es el que en un estadio inicial detecta un problema o necesidad y es el que utilizará la solución final creada por el equipo. En un Agile Team es muy importante involucrar a una persona con los conocimientos de negocio desde el día cero, pero siempre queda la pregunta: ¿es esta persona un real reflejo de un cliente?

    Nota: Mi corta experiencia me ha enseñado que cuando más tiempo trabajamos con estos expertos de negocio, más comenzamos a conocer el negocio y podemos mejorar nuestra solución. La contrapartida es que estos SMEs también comienzan a conocer como funciona un Agile Team y se van adaptando a las prácticas del equipo. Esto no es malo, sin embargo puede resultar contraproducente si no se valida con los demas “clientes”.

    La solución para conocer a un cliente final, no pasa por involucrar a todos los clientes dentro del equipo de desarrollo, pero si planificar algún tipo de actividad para obtener feedback de los mismos. El concepto de Agile Customer implica que trabajemos de forma parcial con un On-Site Customer (que a la larga se termina convirtiendo en el Product Owner y si tienes mucha suerte este trabajo no es en forma parcial sino full time). Como un adicional a este concepto me gustaría agregar las siguientes actividades

    • En una Sprint Review, no solo incorpores las caras conocidas del proyecto; intenta involucrar a nuevas personas. En una reunión previa o al principio de la reunión, dedica un tiempo para explicarle el objetivo del Sprint Review y la dinámica de trabajo; e intenta obtener su feedback durante el mismo.
    • Recuerda las 2 premisas fundamentales relacionadas con el trato con los clientes
    • NO IMPLEMENTES NADA que no haya sido aprobado por un cliente
    • NADIE puede sustituir a un usuario final de la aplicación
  • Utiliza herramientas como “Request Feedback” de Team Foundation Server o Visual Studio Online para involucrar a estas personas y tener un Feedback frecuente sobre el avance de la aplicación.
  • image

    Para finalizar recuerda que si bien el cambio es una constante, una versión cerrada depende mucho de la capacidad que tengamos de manejar las expectativas de nuestros clientes. Se honesto y la solución seá un éxito.

    Referencias: Si quieres saber más sobre Microsoft Feedback Client puedes ver mis posts aquí.

    Saludos @ La FInca

    El Bruno

    image image image Google

    [#ALM] Do you really need roles in a team? (usually not)

    Hello!

    Today I’m going to avoid the intro and some context and I’ll go directly to the question:

    Are necessary roles in an Agile team ?

    The answer is simple: Yes. But they are not roles that usually people know, there are only 2 roles in a single Agile Team

    • Some people with a problem
    • An Agile Team with the ability to provide a solution to this problem

    And that’s all. The 1st role is usually known as a client or customer, and is defining the problems or needs that will work the 2nd team. The 2nd team is where lives the usual roles, best-known as front end developer, backend roles developer, analyst, etc.

    The important thing in an agile team is that members should be flexible enough to cover any position. Since the ZERO day, the team should be able to to add value. This does not remove the need for some specialist, in example: a tuning of a databases. This should be be dictated by the evolution of the solution, and if the architecture is emerging from the team, there will not be a problem. (remember discarded classical architects! ))

    And I’ll close with a tip: The next time that you start an agile team, don’t consider the specific capacities of the people in relation to what they can do, but rather keep in mind the capacity that they have to adapt to what comes up. Remember that the only constant in a team change and:

    Agile customers knows that a product can always improve, and also knows that they are responsible for the changes introduced in the product

    Analysts knows that a solution is never complete, the context and the problems tend to change and they must adapt the analysis models as these changes are discovered

    The developers know that we will never write perfect code, so that we refactor the code, we base our code on tests and change the code again and again to improve it

    Happy Teaming Open-mouthed smile !!!

    Saludos @ Home

    El Bruno

    image image image Google

    [#ALM] Son necesarios los roles en un equipo? (usualmente NO)

    Hola!

    Hoy voy a dejar de lado una intro para poner contexto en el post y voy directamente a la pregunta:

    ¿Son necesarios los roles en un equipo Agile?

    La respuesta es simple: SI. Pero no son los roles que usualmente la gente conoce, en un Agile Team solo existen 2 roles

    • Personas con un problema
    • Un equipo ágil con la capacidad de dar una solución a ese problema

    Y ya está. El 1er rol es usualmente conocido como cliente o customer, y es que define los problemas o necesidades sobre las que trabajará el 2do equipo. Dentro del 2do equipo es donde surgen los roles más conocidos como front-end developer, back-end developer, analyst, etc.

    En realidad lo importante en un equipo ágil es que los integrantes sean lo suficientemente flexibles como para poder cubrir cualquier posición. De esa manera, desde el día ZERO el equipo puede comenzar a aportar valor. Esto no quita que en determinados momento sea necesario acudir a un especialista, por ejemplo en una tarea de tunning de bases de datos. Esto suele ser dictado por la propia evolución de la solución, y si la arquitectura es flexible como para emerger a partir del equipo, no será un problema. (recuerda descarta los arquitectos clásicos!)

    Dicho esto, solo queda cerrar con un consejo. La próxima vez que armes un equipo ágil, no tengas en cuenta las capacidades específicas de las personas en relación a LO QUE PUEDEN HACER, sino más bien ten en cuenta la capacidad que poseen para ADAPTARSE A LO QUE SURJA. Recuerda que la única constante en un equipo es el cambio y:

    Los clientes ágiles saben que un producto siempre puede mejorar, y tambien saben que ellos son responsables de los cambios que introducen en el mismo

    Los analistas saben que un análisis nunca está completo, el contexto y los problemas tienden a cambiar y ellos deben adaptar los modelos de análisis a medida que se descubren estos cambios

    Los developers sabemos que nunca escribiremos el código perfecto, es por eso que refactorizamos, nos basamos en tests y cambiamos el código una y otra vez para mejorar el mismo

    Happy Teaming Open-mouthed smile !!!

     

    Saludos @ Home

    El Bruno

    image image image Google

    [#PEBBLE] #UX and Pebble (for simple people like me)

    Hi!

    Marta, a very good friend of mine, is an UX expert. A long time ago she told me a phrase kind of impossible for me. However, if you repeat this phrase to some people you’ll get their attention and some cult, and you’ll become a hipster with beard, Starbucks fun and crazy clothes.

    When you design an app you must try to make the color vibrate and controls breath

    Someone will probably get it, no me. That’s why, when I get my Pebble I know this world is for me. Let me explain

    - no colors, only black and white

    - small resolution = 144 x 168 px

    - a small set of fonts are supported

    - the official design guide suggest the creation of flat apps

    - it also suggest a minimalist approach in the Pebble app design

    So after this, I know Pebble apps are for me! let’s take a look at this one

    image

    This app is the sample app included in chapter 4 of the Pebble UX Design Guide)

    Download: https://developer.getpebble.com/2/design/

    Greetings @ Berlin

    El Bruno

    image image image Google

    [#PEBBLE] Un poco de #UX y Pebble (lo poco que entiendo yo de eso)

    Hola!

    Mi amiga Marta, que de esto de UX sabe y mucho, alguna vez me dijo una frase que no entendí muy bien. Eso sí, si repites esta frase en determinados círculos pareces un experto hipster aficionado a Starbucks, con barbaca y camisa leñadora

    En una app tienes que lograr que los controles respiren y los colores vibren

    Ahi lo dejo. Y es por eso, que en mis “yo interior” decidí mejor dedicarme a apps en Pebble. Los motivos son claros

    - el entorno es blanco y negro

    - la resolución de las apps es de 144 x 168 px

    - solo soporta un grupo reducido de fonts

    - la guía de diseño de apps te recomienda crear apps “planas” (flat apps)

    - un enfoque minimalista es lo que debería guiar el diseño de Pebble apps

    Con esto dicho, lo tuve muy claro > es para mi! Y claro, con algo tan simple como esto

    image

    No tengo margen de equivocarme (por cierto esta app es la ficha que se muestra de ejemplo en el capítulo 4 de la guía de diseño de Pebble)

    Download: https://developer.getpebble.com/2/design/

    Saludos @ Berlin

    El Bruno

    image image image Google

    [#ALM] Improving the way we work (all the time, even in Easter time)

    Hello!

    A few days ago, in Peru some crack hosted the DevDays and today while I was reviewing some materials, I found this slide of Ernesto and while I was runnig 11KMs I did a little thinking about it.

    image

    How long would it take your organization to deploy a change that involves just one single line of code?

    In my line of work, change is a constant. Once I’ve commented on the type of work with elastic equipment, where we are usually 3 people, and we can get bigger up to 20 with a specific objective and then back to 3. This makes the inspection and adjustment a little more complex than usual. However the basis is to give the best and perform a high quality job, this is something that we must never lose.

    So with this scenario in mind, I decided to go back a few steps (about 23 according to my graphics) and try to update 1 line of code in a project / demo that is in production since 2013 April and publish it again.

    The process was a little tricky  and didn’t take me more than 2 hours, and I want to share some highlights about this:

    -The code download was trivial, and the compilation had no problems.

    -I cannot say the same of the unit Tests, I started to have problems with a few tests. It seems that our kind friends of JSON decided to update since April of the year until now several versions.

    -That was solved with and update of a pair of NuGet packages, and this triggered a series of updates that forced me to wrtie some code. With packages like SignalR, and EOF.

    -A year ago, I had a discussion with a member of the team which had pigheadedness in use Azure Mobile Services. Luckily I decided to implement the services with WebApi layer and passing the benefits of Azure Mobile Services. I have open a test project that we started to work and I think that in one year can not update anything.

    -That was kudos for me, now I get some punishment about a bad decision I made. Last year I think we can use LightSwitch to a perform a few trivial maintenance in a couple of tables. Those trivial maintenance now have more functionality than a calculation of demographic application, and after migrating the same between versions of LightSwitch, we have reached a point of no return where … I leave this here. This is a bad point for me. And I know that at some point I must raise the priority of this PBI and put it in a Sprint to make the app again.

    There are a couple of more stories to tell, but the conclusion is that in my case later 2 hours in upgrading a line of stitching a project in production. And this in an app in which nobody works has between 11 and 12 months old. I don’t even think what it would cost “get back to life” code that is measured in years.

    Conclusion: Although it is not a current scenario to meet the need for modifications in code of this type, I will challenge this scenario with 3 participants of the team and see the best way to be prepared for this situation. 2 hours isn’t much when is code is familiar for me, however in a “hostile” environment these 2 hours can easily be 2 days or more… Open-mouthed smile

    Saludos @ Home

    El Bruno

    image image image Google