j.a.estevan

En la anterior entrada de esta serie, vimos al detalle cómo instalar y realizar la configuración básica de un servidor Team Foundation Server 2010, y suponíamos también la instalación de un Visual Studio 2008 o 2010 configurado con las actualizaciones suficientes para conectar a este servidor. Nuestro servidor quedó instalado y configurado con una o varias colecciones de proyectos, pero ningún proyecto creado.

En esta entrada vamos a comprobar cómo un servidor de Team Foundation Server 2010 puede ayudarnos a la gestión del ciclo de vida de la aplicación a nivel funcional, sin entrar en detalles técnicos, y cómo esta funcionalidad nos ayudará desde las primeras fases del proyecto en la toma de requisitos, hasta las últimas con la gestión de incidencias o la gestión del cambio.

Lo primero que necesitamos para la gestión de nuestro proyecto es, como cabe suponer, un proyecto. La creación de un proyecto no se puede realizar desde el acceso web de TFS2010 por lo que necesitaremos conectarnos al servidor mediante Visual Studio. En este capítulo trabajaremos con Visual Studio 2010 que casi seguro tendremos instalado en nuestra máquina de desarrollo de Microsoft Dynamics AX 2012.

En la página de inicio de Visual Studio 2010 vamos a elegir la opción Connect To Team Foundation Server:

Si nunca hemos conectado a nuestro servidor (o a ninguno) no aparecerá en la lista de servidores, para añadirlo pulsamos Add y escribimos el nombre del servidor donde trabajamos en el capítulo anterior. El asistente se ocupará de completar la URL:

El 24 de marzo de 2012 en la Escuela Universitaria de Informática de la UPM se celebrará el evento tecnológico
que reunirá por primera vez en Madrid, después de 5 años de éxito en Italia, a técnicos, desarrolladores y estudiantes de todas las comunidades y lenguajes.

Codemotion es un evento multilenguaje y multiplataforma organizado por las comunidades para las comunidades y
representa una oportunidad única para mezclar en un mismo recinto y un solo día comunidades como Java, Rails,
JavaScript o Agile.

Internacional no sólo en charlas, donde traeremos speakers internacionales, sino el propio evento que se ejecutará
en paralelo con Codemotion Italia celebrado en Roma el mismo día y con el cual estaremos conectados en
streaming directo.

Además, toda la semana anterior al evento será dedicada a la organización, por parte de las comunidades, de
muchas actividades como calientamiento al big day.

La entrada cuesta sólo 10 euros e incluye cafés, comida y los gadgets del evento.

Para más informaciones escríbe a info@codemotion.es o visita www.codemotion.es y @codemotion_es

Este año 2011 que acabamos de cerrar he aprendido muchas cosas. No esas cosas normales que uno aprende con la vida y la experiencia sino cosas serias, de las que te hacen pensar y replantearte certezas, de las que consiguen cambiar viejos hábitos.

Una de esas cosas es que para ver donde estás es necesario detenerse a mirar atrás. Pisar el balón, parar de correr, levantar la cabeza y observar el juego desde arriba antes de seguir hacia un objetivo que puede no estar ya ahí. Es importante tener objetivos claros y medibles y de vez en cuando pararte a pensar si se están cumpliendo y qué puedes hacer para asegurarte de que se cumplan.

Trust, but verify

El año pasado hice una de esas listas de objetivos aunque no la publiqué, algunos de esos objetivos se han cumplido y otros no, este año la compartiré por otro de esos principios importantes que he adquirido este año:

If you want to go fast, walk alone. If you want to go far, walk together

• Cambio de ambiente laboral: Hace mucho que me lo planteaba pero no un cambio de empresa porque sí. No necesariamente necesitaba un cambio de empresa sino un cambio de valores, de principios, de filosofía. Un cambio donde hacer las cosas bien no sea un extra sino una consecuencia lógica. En unos días se hará efectivo ese cambio así que este es un done de los buenos, mejorado con un cambio de residencia a Madrid, lo que a su vez contribuirá con el siguiente punto:

• Mejorar mi networking 1.0: Es relativamente fácil mantener una red de contactos 2.0, redes sociales, etc. Pero los contactos no valen mucho si no son contactos reales y este año me propuse hacer algo al respecto. Lo cumplí bajo mínimos asistiendo a la Conferencia Agile Spain 2011.

Otra de las cosas importantes que he aprendido este año es la gran importancia que tiene perseguir una mejora continua. Da igual donde estés (o donde creas que estés), siempre se puede hacer algo para seguir mejorando y si te olvidas de esto, estas perdido. Estas son las mejoras que me planteo este año:

If you can’t measure it, you can’t manage it

• Seguir intentando ser bueno en lo que se me da bien, y mejorar en todo lo demás. Ponerme las pilas en serio con AX 2012 y afrontar todo lo que venga en esta nueva etapa laboral que empieza. Motivación total a este respecto.

• Ponerme las pilas de una vez con el inglés. Clases, reuniones, cualquier cosa. Y la consecuencia lógica de esto sería publicar los artículos del blog también en inglés. Este es uno de los puntos pendientes de 2011 y no puede quedar otro año en el tintero.

• Para continuar con el networking 1.0 comentado antes, tengo ya en agenda unos cuantos eventos del mundo agile (CAS y AOS 2012) y desarrollo (Codemotion) y me gustaría encontrar alguno donde ampliar el circulo del mundo Dynamics AX en España. La experiencia del año pasado fue tan positiva que este año tengo que ampliar el objetivo a como mínimo 4 eventos.

• Lanzar Open BOE: Llevo unos mese trabajando en mi tiempo libre en este proyecto y está casi a punto para lanzar una primera beta. No es ninguna virguería técnica pero es mi aportación al mundillo de los datos abiertos, transparencia y gobierno electrónico en el que creo con firmeza. Para quien le interese, hay una cuenta de twitter dedicada a este proyecto: @openboe

Y creo que con todo esto y algunos asuntos personales que he empezado con mucha ilusión tendré más que de sobra para conseguir un año productivo.

• Necesito precio para unos accesorios de baño para mañana {contrato a precio fijo, alcance fijo, plazo fijo}
• Sin problema, le cuestan 50€ cada uno {confirmación del contrato}
• Perfecto, pero los quiero colocados en la pared {ampliación de alcance no prevista}
• OK, se los doy colocados en la pared {aceptación ¿? de la ampliación} :
  

Obviamente esta situación es ficticia, pero el resultado es real. Esa “instalación” lleva así desde hace más de un mes en un baño público y nada indica que la situación vaya a mejorar en a corto plazo. Alguien ha dado esa instalación por “hecho” pero esa no es la impresión que da cuando necesitas secarte las manos.

Me gustaría analizar cómo se ha llegado aquí porque es algo que vemos todos los días cuando hablamos de software, que es a lo que vamos:

• Necesito precio para unos accesorios de baño para mañana {contrato a precio fijo, alcance fijo, plazo fijo}
• Sin problema, le cuestan 50€ cada uno {confirmación del contrato}
• Perfecto, pero los quiero colocados en la pared {ampliación de alcance no prevista}
• OK, se los doy colocados en la pared {aceptación ¿? de la ampliación} :
  

Obviamente esta situación es ficticia, pero el resultado es real. Esa “instalación” lleva así desde hace más de un mes en un baño público y nada indica que la situación vaya a mejorar en a corto plazo.

Me gustaría analizar cómo se ha llegado aquí porque es algo que vemos todos los días cuando hablamos de software, que es a lo que vamos:

Definition of Done (DoD)

El término Definition of Done está asociado normalmente a Scrum, pero no por eso tenemos que limitarlo a Scrum, ágile, o a ninguna metodología en concreto. Es un término que en cualquier caso se tiene que tener en cuenta y sobre el que vale la pena negociar en cada proyecto, ya que de ésta definicion va a ser la culpa del éxito o el fracaso de muchas entregas (me da igual que sean entregables waterfall, sprints de scrum o como queramos llamarlo).

En un mundo ideal, un análisis -o la definicion de una tarea- esta perfectamente definida y quién lo solicita (consultor, analista, product owner, … quién sea) especifica detalladamente qué quiere, cuándo, dónde y cómo lo quiere. Pero nosotros no vivimos en un mundo ideal y eso rara vez ocurre. Uno o varios de esos interrogantes los vamos a tener que preguntar o suponer y de nuestro acierto va a depender que el resultado sea el esperado o no.

Esta duda (este riesgo) se puede mitigar destallando por ejemplo pruebas de aceptación o similares. Donde se especifique un juego de pruebas que el producto tendrá que cumplir para que se de por valido (para que se considere “hecho”). Pero aun así hay detalles que no entrarán en las pruebas de aceptación, por ejemplo la integración con otros sitemas, la existencia de dependencias externas, hardware, etc. … siempre habrá dudas sobre cuándo podemos dar un trabajo por “hecho”.

Supongo que la comunidad ágil tendrá para discutir largo y tendido acerca de lo que debe ser DoD, lo que se debe detallar en una tarea o en la definición de un sprint. Pero visto desde un punto de vista mas general (o mas waterfall en particular), la definición exacta y pactada de qué requisitos concretos debe cumplir un desarrollo para validarse es algo a lo que se le da poca importancia en el mejor caso, o se ignora por completo en el resto, y que a mi entender es causa de muchos desacuerdos entre las partes y constantes peleas a la hora de finalizar las entregas.

Sobre este tema se habló en la pasada Conferencia Agile Spain y por eso os remito a los videos de las sesiones sobre Contratos Agiles (de Xavier Albaladejo) y a la keynote de Xavier Quesada, donde explicarán mejor qué yo por qué vale la pena reflexionar sobre este tema.

Voy a procurar no extenderme mucho para contar lo sucedido en estos dos días de conferencias que hemos podido disfrutar en la Universidad Jaime I de Castellón, empezando como no podía ser de otra manera felicitando la impecable organización por parte de los organizadores de Agile Spain. Un 10 para ellos y mi agradecimiento.

Después comentar que es mi primer evento “masivo” en la comunidad Agile Spain así que no tengo la oportunidad de hacer una valoración comparativa como otros compañeros están haciendo. Como es obvio, sólo voy a comentar las charlas a las que asistí. Ha quedado un poco largo, si te aburre puedes bajar directamente a las conclusiones

Voy a procurar no extenderme mucho para contar lo sucedido en estos dos días de conferencias que hemos podido disfrutar en la Universidad Jaime I de Castellón, empezando como no podía ser de otra manera felicitando la impecable organización por parte de los organizadores de Agile Spain. Un 10 para ellos y mi agradecimiento.

Después comentar que es mi primer evento “masivo” en la comunidad Agile Spain así que no tengo la oportunidad de hacer una valoración comparativa como otros compañeros están haciendo. Como es obvio, sólo voy a comentar las charlas a las que asistí. Ha quedado un poco largo, si te aburre puedes bajar directamente a las conclusiones

Leer el resto del artículo →

Insanity: doing the same thing over and over again and expecting different results.- Albert Einstein

(Locura es hacer lo mismo una y otra vez y esperar resultados diferentes)

Como expuse en mi anterior post: ¿Sure Step vs Agile? Condenados a entendernos, estoy convencido de que un cambio de filosofía hacia el mundo ágil no sólo es positivo sino que es totalmente posible dentro del mundo de los grandes ERP en general, y del canal Dynamics en particular.

Como exponía en ese artículo, hay varios handicap que superar como la resistencia al cambio (hay que cambiar la mentalidad de muchas personas involucradas), la falta de confianza en el sistema para proyectos de largo alcance o incluso la falta de colaboración del cliente. Sin embargo hay ciertos trabajos muy típicos de esta industria que son ideales para empezar a experimentar con este cambio, a pesar de que el proyecto, en general, se gestione con Sure Step:

• Migraciones (cambios de versión): Una migración es un proceso totalmente acotado con tareas claramente definidas y planificables, pero lo importante es que en este proceso no es tan importante la documentación (a menudo no es para nada importante) como la implicación del cliente en el proceso tanto para la realización de diversas pruebas al finalizar cada tarea, como para solucionar consultas sobre la marcha en caso de imprevistos (en las migraciones siempre hay imprevistos). Lo de “ágil” se vuelve literal ya que cuando el proceso de migración termina se tiene que implantar en tiempos de parada del cliente, casi siempre en un fin de semana.

• Soporte post-arranque: Cuando se da por finalizada una implantación nueva y el cliente empieza a utilizar el sistema, a menudo se dará cuenta de que hay pequeños (o grandes) detalles que quiere modificar porque no se habían previsto durante las fases previas. La buena gestión de estas modificaciones puede diferenciar el éxito o el fracaso de una implantación ya que una cosa es que el proyecto finalice, y otra que el cliente de por cubiertas sus necesidades (o las que cree que lo son). Hacerle participe del coste y el esfuerzo de esos “extra” puede ser determinante para cerrar la implantación con todas las partes satisfechas.

• Actualciones de mantenimiento: De la misma manera que en el punto anterior, trabajar con un sistema programable como lo son todos los grandes ERP’s hace que siempre haya pequeños o grandes cambios a realizar para optimizar el trabajo diario. La buena gestión de las necesidades, el desarrollo y la implantación de los cambios sin interferir el trabajo de los usuarios es determinante para que los mantenimientos se finalicen con éxito y sin fricciones.

Si alguien ya ha empezado o esta interesado en estos cambios me encantaría recibir opiniones en los comentarios. Y si alguien quiere comentar o debatir en persona estaré en la próxima Conferencia Agile-Spain 2011 (#cas_2011)

Hace unos días tuve una conversación muy interesante con un compañero de trabajo a raíz de mi anterior post El ratoncito ágil y La ruta de los elefantes. Este compañero defendía con bastante convicción la metodología de gestión de proyectos tradicional y me proponía diferentes motivos por los que en nuestro negocio no podían funcionar otras como Scrum o en general metodologías de filosofía ágil o lean (método, sin embargo, ámpliamente reconocida en el mundo de la fabricación industrial) seguro que os suenan:

1. Scrum (o la gestión ágil en general) no es apropiada para proyectos grandes (en tiempos, equipos, costes, …) con diferentes equipos en diferentes roles (comerciales, analistas, consultores, programadores, jefes de proyecto, …) y a menudo en diferentes ubicaciones.
2. Para aplicar estos métodos hay que cambiar la forma de trabajar de muchas personas integrantes de la empresa, y del equipo en particular, desde el comercial hasta el programador pasando por todos los roles intermedios, y esto tiene un coste y un riesgo a menudo inasumible.
3. A menudo ni siquiera el cliente está preparado para trabajar de manera ágil. No entiende las implicaciones o simplemente no está dispuesto o preparado para implicarse tanto durante toda la duración del proyecto. Espera pedir lo que necesita, y que se lo den todo hecho.

Hace unos días tuve una conversación muy interesante con un compañero de trabajo a raíz de mi anterior post El ratoncito ágil y La ruta de los elefantes. Este compañero defendía con bastante convicción la metodología de gestión de proyectos tradicional y me proponía diferentes motivos por los que en nuestro negocio no podían funcionar otras como Scrum o en general metodologías de filosofía ágil o lean, seguro que os suenan:

1. Scrum (o la gestión ágil en general) no es apropiada para proyectos grandes (en tiempos, equipos, costes, …) con diferentes equipos en diferentes roles (comerciales, analistas, consultores, programadores, jefes de proyecto, …) y a menudo en diferentes ubicaciones.
2. Para aplicar estos métodos hay que cambiar la forma de trabajar de muchas personas integrantes de la empresa, y del equipo en particular, desde el comercial hasta el programador pasando por todos los roles intermedios, y esto tiene un coste y un riesgo a menudo inasumible.
3. A menudo ni siquiera el cliente está preparado para trabajar de manera ágil. No entiende las implicaciones o simplemente no está dispuesto o preparado para implicarse tanto durante toda la duración del proyecto. Espera pedir lo que necesita, y que se lo den todo hecho.

Los motivos son tan apropiados y recurrentes en cualquier discusión que casi tendrían que formar parte del manifiesto ágil, ya que bien argumentadas son difícilmente discutibles. Lo voy a intentar:

Partimos de la base de que como Partners de Microsoft Dynamics, trabajamos siguiendo la metodología Sure Step, que es una adaptación a diferentes tipos y tamaños de proyecto de la ya conocida Waterfall (Metodología “en cascada”) tradicional, basada en fases secuenciales (con equipos diferenciados por fase), documentación y contratos, y “entregables” (deliverables). Mientras que las filosofías ágiles se basan en el manifiesto ágil:

• Individuos e interacciones, sobre procesos y herramientas
• Software funcionando, sobre documentación extensiva
• Colaboración con el cliente, sobre negociación contractual
• Respuesta ante el cambio, sobre seguir un plan

(Esto es, aunque se valoran los elementos de la derecha, se valoran más los de la izquierda)

También existen diferencias (o eso parece) entre los diferentes roles que intervienen en ambas filosofías. En Sure Step existen muchos roles que no siempre se aplican todos, resumiendo más o menos:

• Equipo de Ventas (ante-proyecto)
  • Comercial, Gestor de cuentas, Consultor pre-venta, …
  • Equipo de Consultoría (ejecución del proyecto)
    • Gestor de proyectos
    • Consultor de negocio, Consultor de integración, Consultor funcional, Consultor técnico
    • Programador, Consultor de desarrollo, Técnico de soporte
    • Equipo del Cliente
      • Gestor de proyectos, Responsable de proyecto, usuarios clave, usuario final, responsable de área

Mientras que, por ejemplo, en Scrum, los roles son menos y más específicos (me extenderé sobre esto en futuros artículos), orientados más al producto que al proyecto:

• Product Owner (propietario del producto, representa al cliente)
• Scrum Master (facilitador del Scrum Team)
• Scrum Team (equipo que hace posible el producto)
• Usuarios (quien utilizará el producto)

Expuesto todo esto, es fácil comprobar por qué mi compañero está tan seguro de su argumento nº 2, expuesto al principio. Intentar cambiar una organización entera y todas las personas implicadas para cambiar la filosofía y el método de trabajo sería un suicidio. Pero estamos hablando de filosofías ágiles, donde prima el proceso incremental, ¿por qué se debería cambiar todo a la vez? Es cierto que en muchos casos no se podrá utilizar una u otra metodología para gestionar todo el proyecto, pero ¿por qué no puede aplicarse sólo en un equipo, o en un área, o en una fase?

Precisamente el trabajar con metodologías Waterfall durante tantos años nos ha llevado a tener equipos muy bien diferenciados por roles y a menudo incluso por ubicación.

¿Acaso dentro de Sure Step un equipo de consultores o de desarrollo no puede auto-gestionar su propia fase de una manera ágil? Mejoraría el resultado final, probablemente los plazos, y mantendría informado de manera frecuente a su director de proyecto y al cliente (quizás a través de un product owner interno, un consultor).

¿Acaso no se puede gestionar una fase de desarrollo (Waterfall) de una manera ágil, priorizando el “core” del desarrollo (lo que el cliente considera imprescindible para su funcionamiento) y haciendo entregas parciales del mismo? Se detectarían errores en el análisis con más antelación que haciendo una única entrega final, se detectaría trabajo que ya no se debe hacer, el cliente vería progresos antes y se haría una idea de lo que va a ser su producto, antes de verlo terminado.

¿Acaso en Sure Step no tenemos ya los roles de Scrum definidos en cada fase? En análisis el Scrum Team son los analistas, existe un jefe de proyecto (Scrum Master) y se realiza directamente en el cliente (product owner). La fase de desarrollo la realizan programadores y consultores técnicos (Scrum Team), el desarrollo se entrega normalmente al equipo de consultoría para sus pruebas (product owner) y existe un director de desarrollo o de proyecto (Scrum Master). Simplemente en cada fase, el que realiza el trabajo es el equipo (Scrum Team), y el que lo espera en la fase siguiente de la “cascada” es el “cliente” (product owner) para el equipo actual.

Creo que con esto queda clara mi postura frente a los problemas nº 1 y 2 expuestos más arriba. Efectivamente hace falta un cambio, pero no creo que sea tan radical ni que necesariamente se deba hacer de manera brusca para nadie. ¿Qué no se puede o sabe gestionar un gran proyecto con gestión ágil? Tampoco es necesario hacerlo para empezar a experimentar y descubrir que hay otras formas de hacer lo de siempre.

¿Y si el cliente no entiende, no es capaz de comprometerse o de comprender un contrato ágil, sin fechas de entrega o costes grabados en piedra? Estoy convencido de que cuando el equipo de la empresa vea los resultados de una forma de trabajar más eficiente, el propio equipo comercial comprenderá la forma de explicar al cliente las ventajas de este cambio. Cuando estás en la situación de firmar un contrato de cantidades notables de dinero es normal que no quieras arriesgarte, pero ya hay mucha gente que se ha caído “cascada abajo” y que estaría dispuesta a probar métodos alternativos, es una cuestión de confianza en sí mismo, de probar, de investigar, de perder el miedo al cambio por parte de todos.

Cerca de donde vivo hay una carretera conocida como “la ruta de los elefantes“. Es una carretera corta pero con muchas curvas, poca visibilidad y frecuentada por muchísimos camiones, por lo que la circulación resulta lenta y pesada, de ahí el “apodo” que se ha ganado.

Este apodo parece aplicable, por los mismos motivos, al mundo de la implantación de los grandes ERP’s. Gran parte de ese pastel se lo reparten entre unas cuantas grandes empresas, a menudo multinacionales, que acaparan a la mayoría de grandes clientes. Entre la vertical e interminable jerarquía de una buena parte de ellas -como por la ruta de los elefantes- circulan managers más centrados en la cuentas de resultados financieros que en la satisfacción de los clientes, más centrados en la facturación que en la calidad del producto, más centrados en contentar a la parte superior de la jerarquía que en motivar a los de abajo.

De la misma manera que por la carretera, por estas empresas también circulan un numero enorme de trabajadores que como los coches de la carretera quedan atrapados entre varios “camiones pesados”, frenando su avance, retrasando sus objetivos, disminuyendo su visibilidad y haciéndoles imposible adelantar para continuar su camino a su propio ritmo. Muchas veces no es culpa del camión retrasar a los coches, los camiones son grandes, lentos y pesados per-sé, el problema de esa carretera es la cantidad increíble de ellos que se suelen encontrar en el camino y la poca colaboración de éstos para permitir ser adelantados.Cerca de donde vivo hay una carretera conocida como “la ruta de los elefantes“. Es una carretera corta pero con muchas curvas, poca visibilidad y frecuentada por muchísimos camiones, por lo que la circulación resulta lenta y pesada, de ahí el “apodo” que se ha ganado.

Este apodo parece aplicable, por los mismos motivos, al mundo de la implantación de los grandes ERP’s. Gran parte de ese pastel se lo reparten entre unas cuantas grandes empresas, a menudo multinacionales, que acaparan a la mayoría de grandes clientes. Entre la vertical e interminable jerarquía de una buena parte de ellas -como por la ruta de los elefantes- circulan managers más centrados en la cuentas de resultados financieros que en la satisfacción de los clientes, más centrados en la facturación que en la calidad del producto, más centrados en contentar a la parte superior de la jerarquía que en motivar a los de abajo.

De la misma manera que por la carretera, por estas empresas también circulan un numero enorme de trabajadores que como los coches de la carretera quedan atrapados entre varios “camiones pesados”, frenando su avance, retrasando sus objetivos, disminuyendo su visibilidad y haciéndoles imposible adelantar para continuar su camino a su propio ritmo. Muchas veces no es culpa del camión retrasar a los coches, los camiones son grandes, lentos y pesados per-sé, el problema de esa carretera es la cantidad increíble de ellos que se suelen encontrar en el camino y la poca colaboración de éstos para permitir ser adelantados.