[#ALM] Visual Studio ALM leader in Gartner Magic Quadrant

image

Hola !!

como bien comenta Brian Harry en su post, un año más Visual Studio ALM está entre los líderes en el Magic Quadrant de Gartnet para herramientas de gestión de ciclo de vida de desarrollo de software.

image

El documento oficial se puede descargar desde aquí; y lo más interesante es que esta evaluación se realizó teniendo en cuenta la version 2012 de Visual Studio ALM. Seguramente cuando se tengan en cuenta las new features que posee VS2013, el resultado será mejor.

Download: http://www.gartner.com/technology/reprints.do?id=1-1N99LF3&ct=131120&st=sb 

Fuente: http://blogs.msdn.com/b/bharry/archive/2013/12/04/gartner-magic-quadrant-for-application-development-lifecycle-management.aspx

Saludos @ Home

El Bruno

image image image Google

[#ALM] Cual es mejor #KANBAN o #SCRUM?

ALM 03

Hola,

hoy voy a tocar un tema que es complicado: intentar definir si

SCRUM es mejor que KANBAN

o si

KANBAN es mejor que SCRUM

Y ahora que he cumplido con las formalidades para aquellos que leen el resumen del post vamos con la respuesta correcta:

¿Realmente piensas que una forma de trabajo es mejor que otra?

Si eres de los que piensan que se puede hacer una comparativa entre ambas y sacar la “MEJOR”, es que realmente no has comprendido como funciona un equipo.

En mi caso, hay cosas de KANBAN que me gustan mucho, como por ejemplo el concepto de Work in Progress (WIP). Y como contrapartida de SCRUM hay cosas que me repatean las nalgas como las predicciones en base a las métricas que nos brinda velocity. Pero ambas tienen muchos conocimientos y buenas prácticas que puedes aplicar en tu equipo para lograr un mejor rendimiento.

Y para finalizar, solo comentar que si eres de esas personas que no tienen miedo en afirmar que “X es mejor que Y”, pues da gracias que todavía no se ha inventado el modo de dar golpes a través de internet … Angry smile

 

Saludos @ Home

El Bruno

image image image Google

[#ALM] Trabajando con equipos elasticos (IMHO)

ALM 03

Hola.

AGILE, SCRUM y casi todas las metodologías (o guías de trabajo, o como esté de moda llamarlas hoy) suelen intentar ser predictivas de una forma bastante coherente.

Aclaración: las próximas líneas intentarán definir lo que los grandes expertos han analizado hasta los huesos durante los últimos años. Yo lo haré en 4 líneas y de la forma en la que se lo explico al Valentino.

Estimando o Adivinado que son gerundios

La forma de poder ser predictivos en relación al trabajo a realizar se basa en la experiencia sobre trabajos realizados! Así de simple! Si por ejemplo, te dedicas a la pastelería y tardas unos 30 minutos en hacer 6 muffins (denominación hispter para una magdalena), es probable que tardes 60 minutos para hacer 12, 90 minutos para hacer 18, y así sucesivamente.

Cuando tienes un poco de experiencia en el mundo de la pastelería, seguramente agregarás unos 15 minutos entre tanda y tanda para tareas triviales como la preparacion de los materiales. Luego también agregas unos 60 minutos al día para poder preparar los materiales, limpiar la cocina, etc. Al final todo suele reducirse a una fórmula muy simple para estimar el trabajo.

Cuidado! en este punto suele aparecer un iluminado que piensa que si una persona hace 6 muffins en 30 minutos, pues 2 personas harán 6 muffins en 15 minutos! Aquí toca armarse de paciencia, explicarle al iluminado que SOLO HAY 1 HORNO, que el tiempo de horneado ES FIJO y que por poner más manos no se hará el trabajo más rápido. Pero si es cierto, que estás dos personas pueden comenzar a trabajar en forma paralela y tal vez puedan rebajar los 15 minutos de espera entre tanda y tanda. Si además compramos un 2do horno y ponemos a una persona más a ayudar, ya tenemos un equipo “complejo” que nos puede dar sorpresas (de las buenas) cuando comiencen a trabajar.

Luego de un tiempo trabajando juntas, ES EL EQUIPO EL QUE MEJOR PUEDE ESTIMAR UNA TAREA. Aquí nos pasamos un poco al mundo AGILE, donde las estimaciones las hacemos en base a la experiencia y al equipo. Como además incorporamos el concepto de iteraciones o sprints, es más fácil poder adivinar o estimar cuantos muffins podremos hacer en una semana.

Estoy completamente seguro que en este escenario de trabajo con 3 personas y 2 hornos, luego de un par de meses, si alguno dice “hoy haremos 176 muffins”, es el resultado final que harán. Los Sprint Burndowncharts serán de libro !!!

Equipos elásticos

Sin embargo, ¿qué podemos hacer cuando trabajamos con equipos elásticos? Con equipos donde hay un flujo constante de personas entrando y saliendo del equipo. La cosa se complica bastante si queremos ser predictivos.

Supongamos que traemos al mejor pastelero del mercado junto a un par de personas más y un par de hornos más. Basados en los resultados de semanas anteriores podremos estimar la capacidad de creación de muffins de nuestra pastelería. Sin embargo, en el camino nos damos cuenta de que el pastelero major utiliza una harina especial que no poseemos; hay que comprarla. Luego tenemos que tener en cuenta que uno de los hornos es “especial” hay que tratarlo con cariño, porque sino hace unas subidas de temperatura un poco extrañas … casuísticas como éstas pueden hacer que se nos vaya las estimación inicial para la semana al garete.

Eso sí, luego de 2 semanas cocinando muffins, seguro que la pastelería ya se atreve a dar un número de muffins por semana con los que podrían comprometerse. Sin embargo, si una semana salen personas del equipo, entran nuevas y tienen una rotación alta, lo tienen complicado al respecto.

Aclaración: estoy simplificando bastante al pensar en una pastelería que solo haga muffins. Si además de muffins, esta pastelería tuviese que encargase de pedidos con productos que no conoce … pues ya te imaginas.

Retomando, ¿qué puede hacer la pastelería para ser coherente con su capacidad en este escenario?

Una recomendación es dejar de pensar en la pastelería como “un todo”, y crear equipos pequeños, casi autónomos. Cada equipo será responsable de definir su capacidad. Ojo! no estoy hablando de crear equipos Rangers de 1 persona, sino más bien equilibrar las personas de manera tal que sea posible tener un objetivo predecible.

Otra recomendación, es olvidarse de la duración de los sprints, dejar de trabajar orientados a sprints fijos y trabajar orientado a objetivos. ¿Para qué necesito saber cuantos muffins puedo entregar cada semana, si lo que me han pedido es tener 200 muffins para el jueves? Frente a este escenario, toda la pastelería debe tomar una decisión: SI y se afronta el desafío; o NO y se pasa página.

Y por último, intenta crear un escenario de colaboración que no dependa de las personas. Volvemos al escenario del horno que debe recibir un tratado especial. Si cada 15 días cuando hay cambio de personas en la pastelería, los “nuevos” pierden tiempo hasta que se dan cuenta de cómo funciona el horno; pues esto es tiempo de producción que ha perdido (menos muffins son menos €uros). Imagina que cada persona que aprende una lección de este tipo, la comparte en una pizarra con PostIts, o que deja un super PostIt al lado del horno con el detalle de su funcionamiento. Pues esta colaboración seguro que ahorra muchos dolores de cabeza a las nuevas generaciones de pasteleros.

Aclaración: lo de super post-it no es por el tamaño … solo piensa que que pasa si pegas un PostIt a un elemento que se calienta y se calienta y se calienta y se calienta y ….

Seguro que hay muchas otras consideraciones y consejos que tener en cuenta; yo desde mi pasteleria me he apuntado estos 3 durante estos últimos 6 meses. A ver si me animo a bajar a papel algunos relacionados con trabajos remotos, imaginad que una pastelería en un sitio se prepara la masa, en otro se hornea y en un 3ro se decora y se prepara para la venta … fácil no es Winking smile

Saludos @ Home

El Bruno

image image image Google

[#ALM] Lecciones aprendidas

image

Buenas,

ayer por la tarde me tocó inaugurar las sesiones internas de Avanade comentando mi experiencia en el Showcase durante el último año. Si no conoces el trabajo del Showcase, simplemente comentar que es una alianza entre Accenture, Avanade y Microsoft con el objetivo de mostrar escenarios de negocio reales, basados en tecnologías Microsoft.

Pues bien, inicialmente iba a comentar como tenemos organizado nuestro TFS, como cambiamos de chip con cada nueva aplicación que creamos y cada nuevo cliente que tenemos, como nos enfrentamos a nuevas tecnologías, etc. Pero luego me dí cuenta que tal vez en 20 minutos lo mejor es compartir algunas lecciones que hemos aprendido al trabajar en este tipo de proyectos. No pondré todos los puntos pero sí dejaré un par de ellos.

Debemos ajustar periódicamente nuestro proceso de ALM para servir el proposito del projecto

En mi caso, yo no mido la velocidad de mi equipo, no estimo con story points y si alguien le da un vistazo a mis BurnDown charts, seguro que tiene un infarto. Sin embargo, yo tengo un equipo elástico, en un mes podemos ser sólo 4 personas en 4 proyectos diferentes y luego subir hasta 40 en un mismo proyecto. Con estas métricas en mente medir la velocidad de un equipo es muy dificil, y ni hablar de estimar.

Como además los integrantes de los equipos van cambiando, los skills con los que contamos también son elásticos. Cuidado, se muy bien que en un equipo homogéneo TODOS deben ser capaces de realizar CUALQUIER TAREA. Sin embargo la realidad dice que una persona que tenga experiencia en una tarea X la realizará más rápidamente que una que no; eso sí para la 2da persona es una oportunidad para aprender un poco.

Sobre estas bases, y luego de pensarlo y darle vueltas, decidí empezar a adaptar las buenas prácticas de Scrum y Agile al “equipo”. Y claro, siempre probando cosas nuevas para ver cual nos da un mejor resultado. Por ejemplo, ahora estamos bajo la teoría de la estimación sin horas del Edu, veremos como nos va.

Done is DONE (DoD, Definition of Done)

Este punto si que es muy importante y aplica a todos los equipos y proyectos. Antes de comenzar a trabajar, definir tácitamente o por escrito que es DONE para el equipo. En mi caso, el concepto ha ido cambiando y creo que todavía no lo tenemos muy afinado, aunque vamos en buen camino. Mis stakeholders (que no Product Owners, largo de explicar aunque muy intersante) tienen mucho que decir al respecto.

La calidad de los materiales que salen del equipo está también muy relacionado con este punto. Siempre tenemos que trabajar con la mente puesta en mantener unos niveles de calidad muy altos. Estas 2 líneas anteriores son las típicas líneas que parecen un horóscopo, le sirven a cualquiera. Sin embargo, aplicar buenas prácticas, tener un mínimo de métricas de calidad para controlar, sirven como un punto de referencia para asegurar un trabajo bien hecho. Además en nuestro caso no solo es que compile, pase las prueba y funcione en producción; tenemos que tener además unas aprobaciones posteriores que asustarían hasta a los vampiros de Crepúsculo. Aquí entran los UATs, equipos distribuidos, sesiones funcionales, etc.

Trabaja con HPT (High Performance Teams)

Intenta siempre trabajar con lo mejor en tu equipo. Ojo, que aquí donde me ves yo soy el peor del mío, pero mantener la moral alta e incentivar para trabajar con las mejores personas es algo que he aprendido que es fundamental. Haz la prueba, junta a un crack con una persona “normal” y puedes tener 2 resultados posibles

1. La persona normal, no se sentirá motivada y seguirá siendo “normal”

2. La persona normal despertará de su letargo y tienes a un futuro crack en potencia

En ambos casos no pierdes nada, con lo que probar no cuesta. (si este fuera un blog de desahogo también podría contar las malas experiencias …)

Colabora y hazlo divertido

Lo comenté anteriormente el equipo es un equipo elástico que cambia de integrantes cada 2 por 3, estamos en Madrid, Barcelona, Londres, Seattle, etc. Vamos que si no intentamos pasarlo bien y colaborar entre todos, nos enfrentamos a un problema muy grave. Tenemos la suerte de tener Lync en la empresa con lo que todos nuestros contactos no presenciales pasan por allí. Sin embargo OneNote + SkyDrive y tfs.visualstudio.com han sido las mejores novedades para la colaboración que hemos descubierto este año.

Y bien, listo el post de reflexión. A ver que puedo decir al respecto en diciembre Winking smile

 

Saludos @ Home

El Bruno

image image image

[ALM] Daily Scrum meetings donde lo importante está en el código (seguro? otra vez con los extremistas)

Buenas.

lo he buscado y rebuscado pero no termino de encontrarlo, hace unos días leí un artículo de una persona que proponía cambiar radicalmente la forma de realizar daily scrums, para que los mismos solo durasen 30 segundos. Su teoría era cambiar las 3 preguntas recomendadas

  • ¿Qué has hecho ayer?
  • ¿Qué tienes pensado hacer hoy?
  • ¿Qué problemas tienes?

por solamente una: ¿Qué problemas tienes?. Detrás de esta estúpida idea estaba la premisa de que a la 1ra pregunta se podía responder viendo el histórico de GIT y a la 2da viendo el tablero Kanban con las tareas asignadas a cada persona. Eso nos dejaba solamente el compartir los impedimentos en el daily meeting. Increíblemente esto puede parecerle acertado a alguna persona, y tampoco veo imposible que en algún sitio donde críen unicornios esta forma de trabajo sea válida.

En estos casos extremos hay que tomarse un respiro e intentar darle un poco de contexto a nuestro trabajo, sin olvidar lo principal: TRABAJAMOS CON PERSONAS. Nuestros clientes, nuestros compañeros, etc. En mi caso, por ejemplo, tenemos a una persona exclusivamente dedicada a dar soporte a eventos, demos, etc. Es parte del equipo (y de que forma!) y con este esquema queda fuera todo el contexto de su día a dia, que es uno de los principales feedbacks para el resto del equipo para tener una noción real de como funcionan las cosas.

Y para cerrar, si lo que quieres es mejorar sus Daily Scrum, este video te dar 3 consejos realmente interesantes

 

Saludos @ Home

El Bruno

image image image

[#EVENT] WebCast sobre #AGILE con Visual Studio 2012 y Team Foundation Server 2012 #VS2012 #ALM

image

Buenas,

después de un par de días de oscurismo, por fin me puedo sacar las ganas y comentar como podemos trabajar de manera ÁGIL con Visual Studio 2012 y Team Foundation Server 2012. Los amigos de MSDN Latam me han dado un espacio de 60 minutos para comentar como es posible llevar adelante un equipo utilizando las herramientas de Visual Studio ALM. (como siempre muchas gracias!)

Si bien 60 minutos es poco tiempo, intentaré pasar por los temas básicos

  • organización del trabajo
  • planificación del trabajo
  • ejecución del trabajo
  • gestión de cambios

A qué ahora lo ves más claro, ¿no?

image

Registro: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032551090&Culture=es-AR&community=0

Saludos @ Home

El Bruno

image image image

[#ALM] Alguna vez te has preguntado porqué utilizamos metodologías? (y de nuevo el Dolor es la solución)

ALM 03

Buenas,

cuidado que no voy a entrar en si AGILE, SCRUM o la muerte del modelo Waterfall. Hoy voy a algo más básico:

¿Porqué utilizamos metodologías durante el proceso de desarrollo de software?

¿Qué no te gusta la frase? pues a ver si esta te parece más adecuada

¿Porqué es recomendable aplicar buenas prácticas durante el proceso de desarrollo de software?

¿Sigue sin gustarte? me juego con la última

Te dedicas a hacer software y trabajas en modo Ninja, siguiendo solo tu instinto y reaccionando a los cambios a medida que surgen: Pues … ¡¡¡ morirás entre terribles sufrimientos !!!

Espero que después de esta introducción haya podido explicar el concepto: los llamemos metodologías, buenas prácticas o de alguna otra manera; todos seguimos una serie de normas cuando desarrollamos software. La pregunta inicial es porqué hacemos esto, y la respuesta es más que obvia

Para reducir el riesgo en nuestros proyectos

o si te gusta más

Para tener resultados más predictivos sobre los que trabajar

¿Parece simple no? Pues que sepas que han pasado más de 50 años desde que uno se dio cuenta de esto y lo formalizó. En primer lugar se crearon los procesos, que se encargaban de definir la forma en la que se debía trabajar. Lo bueno de los procesos es que eran 100% mesurables. Era muy fácil decir que como a esta tarea la hemos definido sobre estas bases, pues la misma debería tardar 6 meses. Si todas las personas respetaban esos procesos pues los resultados eran altamente predecibles.

Pero claro, las personas somos unos seres bastante impredecibles; y tanto desde el lado del cliente como del los programadores los cambios se sucedían constantemente. Es por esto, que un par de cracks se juntaron y crearon el manifiesto ágil; personas sobre procesos, respuesta al cambio sobre el seguimiento, etc. Vamos que ya lo conoces …

Y de nuevo, detrás de todo esto había un motivo más que simple: poder predecir los resultados y ser coherentes con lo que una persona o un equipo puede hacer. Así que ya sabes, si alguna vez te preguntas porqué un equipo trabaja con una serie de reglas, con una metodología, best practices o el nombre de moda, pues es probable que sea para mejorar el output del equipo y para ser más predecibles (entre otras cosas)

Aclaración: cuidado! que eso no quita que un equipo trabaje bajo unas premisas que no sirven absolutamente para nada, esos casos ya sabes la forma de arreglarlo: DOLOR !!!!

Y para cerrar una de Dilbert de regalo

image

Saludos @ Home

El Bruno

image image image

[#ALM] ALM para Microsoft Dynamics CRM

ALM 03

Buenas,

los amigos de la edición avanzada de Outlook, es decir Microsoft CRM estarán más que contentos, ahora ya tienen un punto de partida para gestionar el ciclo de vida cuando se desarrollen aplicaciones para esta plataforma. Se ha liberado un whitepaper que describe como trabajar con los proyectos de CRM dentro de Visual Studio y como colaborar con los mismos utilizando Team Foundation Server.

Si bien el inicio de este post puede tener un tono de ironía, he de reconocer que MS CRM es un producto muy bueno. Olvidándonos del CRM propiamente dicho, la plataforma XRM provee una base robusta y completa para desarrollar aplicaciones sobre la misma. En días como los actuales, donde el TTM de las aplicaciones es fundamental, contar con una plataforma que nos de un quick start muy rápido es fundamental, y CRM lo hace.

Espero durante los siguientes días, poder contactar con la gente de CRM de Avanade para que me den su opinión al respecto. 😉

Fuente: http://blogs.msdn.com/b/aymerics_blog/archive/2013/05/17/new-microsoft-release-alm-for-microsoft-dynamics-crm-2011-crm-solution-lifecycle-management.aspx?utm_source=feedly

Saludos @ Home

El Bruno

image image image

[#ALM] Sobre #House, la navaja de Occam y como al final todos la cagamos

ALM 03

Buenas.

El post de hoy empieza con una afirmación:

HOUSE es un crack

Alguno me podrá refutar que todos los capítulos son iguales, algo así:

  1. Paciente X tiene enfermedad desconocida
  2. Se lo dan a House que no lo quiere ver y lo acepta de mala gana
  3. Paciente X crea un vínculo con uno de los asistentes de House
  4. House se salta las normas para ver que tipo de enfermedad tiene el paciente
  5. El equipo la caga, casi se cargan al paciente
  6. A House le cae una buena de sus jefes
  7. En un momento de inspiración, House da con la enfermedad

… y siempre, o casi siempre, por el camino se descarta el Lupus o alguna enfermedad autoinmune.

Con este resumen te he ahorrado ver las 8 temporadas de House. Sin embargo lo mejor que tiene House, es que a lo largo de toda la serie, el protagonista tiene una mala leche / hostia que tiene hace que suelte unas frases que son sabiduría pura. Un excelente ejemplo y de las que más me gusta es:

Las mujeres nunca se equivocan, incluso cuando se equivocan, llega un momento dela discusión en la que sorprendentemente vuelven a tener razón.

Pues eso, el 3er capítulo de la primera temporada se titula “Occam’s Razor”, que traducido al spanglish es algo así como la navaja de Ockham. La navaja de Ockham es un principio de hace una pila de años (del siglo XIV) que dice algo similar a esto:

En igualdad de condiciones, la explicación más sencilla suele ser la correcta.

Esto es sabiduría pura, y sentido común al cuadrado. Cuando trabajas en informática y te enfrentas a problemas diariamente, te terminas dando cuenta de que esta es una verdad para enmarcar. Pero claro, como en toda verdad para enmarcar, hay que tener en cuenta el contexto de cada afirmación.

Hoy estoy muy grafico, así que veamos un ejemplo más claro:

image

¿Queda claro no?, espero que sí, las afirmaciones más simples tampoco suelen ser las correctas.

Y ahora si, ya podemos volver a House. En el capítulo que inspira este post, House da una vuelta más a la frase de Ockham, reformulando algo así como:

La explicación más sencilla es que casi siempre alguien metió la pata

Esto también es 100% aplicable al día a día de nuestro trabajo en informática. Muchas veces nos podemos a buscar problemas de redes, problemas de despliegues, actualizaciones, etc.; cuando lo 1ro que deberíamos hacer es hablar con la gente para ver que o quien ha tocado algo. Es increíble como una pequeña sesión de 5 minutos con las personas afectadas por un problema puede ayudar más que horas y horas de prueba y error frente a un problema.

Y para cerrar, el consejo de siempre: fomenta una cultura de comunicación en tu equipo de trabajo, esto es fundamental para el correcto funcionamiento del mismo.

Saludos @ Home

El Bruno

image image image

[#TFS2012] HowTo: Planear un deploy de Team Foundation Server 2012 (casi tan complicado como reflotar al Barza ;)

image

Buenas,

cuando tienes que instalar un entorno de colaboración con Team Foundation Server, siempre surgen dudas como

  • ¿Qué versión de TFS debo instalar?
  • ¿Me alcanza con una instalación Single Server, o debo separar servidor de datos y capa de aplicación?
  • ¿Necesito Sharepoint?, ¿o Reporting Services?
  • ¿Cómo debo dimensionar el hardware en cada capa?
  • ¿Creo uno o varios servidores dedicados de Build?

Además de estas preguntas, llega el momento de comenzar a definir una estrategia para la organización de Team Projects, aquí las preguntas son del estilo

  • ¿Creo un único Team Project Collection para toda la organización?
  • ¿Creo diferentes TPCs? separando por ejemplo, en áreas funcionales
  • Si separo los TPCs, ¿cómo organizo los módulos comunes a todas las áreas?
  • Si dejo un único TPC, ¿cómo aseguro el aislamiento del código entre diferentes Team Projects?

Comenzar con estos planteos puede ser algo que te consuma tiempo y que no tenga una respuesta simple. Es mas o menos como preguntarse qué debe hacer ahora el Barcelona para poder recuperar la calidad de años anteriores (ya más de un club quisiera tener “la crisis” del Barza, terminando entre uno de los 4 mejores clubes de Europa y con la liga de España en el bolsillo)

Pues bien, lo del Barza se lo podemos preguntar a Pep; y lo de Team Foundation Server lo podemos ver en la guía Visual Studio Team Foundation Server Planning Guide en CodePlex. Esta guía contiene una serie de recomendaciones para la instalación y organización de un entorno basado en TFS2012, que van desde los requerimientos de Hardware hasta la organización sugerida para entornos de test, training, etc. Como siempre una imagen vale más que 1001 palabras.

image

Download: http://vsarplanningguide.codeplex.com/

Saludos @ Home

El Bruno

image image image