j.a.estevan

Si no eres parte de la solución, eres parte del problema

Artículos con la etiqueta ‘programacion’

¿Sure Step vs Agile? Condenados a entendernos

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:

Project Management

  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.

19-09-2011 | hay 1 comentario

Nuevo blog, nuevos retos

Este es el primer mensaje publicado desde la nueva version del blog, publicada de nuevo en WordPress, con un lavado de cara importante y muchas mejoras técnicas, por ejemplo:

  • Nuevo diseño: mas limpio, mas accesible, “mobile friendly”, minimalista y práctico, o al menos con esa intención ha sido diseñado.
  • Enlaces mas concretos y accesibles a mis otros perfiles en twitter y linkedIn, para quien quiera saber mas o mantenerse informado al minuto de las novedades del blog.
  • Nuevas opciones: motor de búsqueda para poder buscar en post antiguos, botón de twitter mejorado que junto a los comentarios recomiendo utilizar para mantenernos en contacto, archivo desplegable en la barra, y archivo completo con nube de tags para que no se pierda ningún post, y espero que mejoras de accesibilidad con el nuevo diseño.
  • Nuevo código QR que aparece en todas las páginas en el menú lateral derecho (→) para poder seguir leyendo los artículos en el móvil rápidamente.

Pero estos cambios no son lo mas importante. El lavado de cara es renovador pero espero, además, poder cumplir varios objetivos extra, principalmente los siguientes:

  • Empezar a publicar post también en inglés

Lo dicho, espero que este sea el comienzo de un cambio a mejor de aquí en adelante y que los nuevos medios técnicos me permitan compartir todo lo que me gustaría. Cualquier sugerencia será bien recibida en los comentarios o en twitter :)

31-03-2011 | hay 1 comentario

AX 2009 EP Development CookBook

Ayer, el equipo del Enterprise Portal Blog publicó un resumen-guía de desarrollo en Enterprise Portal. que han llamado AX 2009 EP Development CookBook Un completo artículo en formato imprimible de casi 40 páginas muy interesante y gratuíto para su descarga desde aquí:

06-01-2010 | deja un comentario

Microsoft Dynamics AX, ¿Por dónde empiezo?


Introducción

La documentación existente en la red sobre desarrollo en Microsoft Dynamics AX es abundante, aunque a menudo mal estructurada, lo que puede ser un problema al principio, si alguien decide aprender a programar AX por su cuenta.

Como introducción se puede consultar el artículo correspondiente de Wikipedia, donde se encuentra una breve historia del producto (antes llamado Axapta), un resumen de los módulos funcionales mas importantes, versiones, arquitectura, y una introducción a su IDE de desarrollo: MorphX y su lenguaje de programación: X++

Libros

El libro Morph IT es probablemente el primer libro sobre desarrollo en AX, escrito bajo la version AX 3.0 SP4 prácticamente todo el contenido sigue siendo válido en AX 4 y 2009, al menos en cuanto a las ideas y la manera de desarrollar. Es, en mi opinión, el mejor para empezar, y es gratis.

La serie “Inside Microsoft Dynamics AX” está escrita directamente por los desarrolladores de AX, tiene un nivel mas alto que el primero y es un libro ideal para consolidar los conocimientos de cualquier desarrollador AX, son muy recomendables. El primero se puede descargar gratuítamente en PDF, el segundo sólo existe en versión papel y es prácticamente imposible encontrarlo en librerías españolas. Se puede comprar en Amazon. Este libro es de los que he leído el mejor sin duda para adquirir el mejor conocimiento sobre desarrollo AX, son muy técnicos pero escritos de manera que se puedan comprender fácilmente.

Recursos Web

Comunidades, Blogs, Foros, …

  • Microsoft Dynamics Comunity (comunidad oficial de Microsoft, foros, blogs, …, la mas completa)
  • El Rincón Dynamics (comunidad española sobre Dynamics con un amplio nucleo de especialistas en AX, muy activa tanto en foros como en contenido)
  • Trucos AX (primera comunidad AX de españa, la web está casi inactiva pero es medianamente activa en sus foros)
  • Mibuso.com – Dynamics AX (comunidad basada principalmente en NAV, con un foro medianamente activo de AX)

PartnerSource, CustomerSource y Certificación

El acceso a PartnerSource o CustomerSource da acceso a la descarga de materiales de los cursos oficiales de certificación de Microsoft que es, probablemente, la mejor documentación disponible para el aprendizaje de AX junto a los dos libros que indico mas arriba, así como el acceso a toda la documentación que Microsoft publica sobre el producto (White Papers, Manuales, herramientas, etc, …).

El acceso a estos portales depende del contrato de licencia del que se disponga con Microsoft tanto si se es Cliente, como Partner.

03-01-2010 | hay 12 comentarios

Futuros cambios en X++

Desde un blog publicado por el personal de desarrollo de Microsoft, publican una serie de cambios (no necesariamente los únicos cambios) que se van a realizar en el lenguaje X++ (el lenguaje de Microsoft Dynamics AX) en la próxima versión del producto (de momento, Dynamics AX 6)


Se puede ver el artículo aquí: Forhcoming changes to the X++ language


La mayoría son cambios orientados a mejorar la seguridad del código, dejando ver el esmero con el que mejoran la calidad tanto del compilador como de los desarrollos que pueden salir de él.

30-06-2009 | deja un comentario

AX6: los .aod pasan a SQL

Novedades sobre Axapta 6, para variar desde mfp’s two cents. Esta vez algo transparente para el usuario final pero que promete mejorar la vida de los desarrolladores.


A partir de la nueva version de AX, los ficheros .aod que antes contenian los objetos de las diferentes capas de desarrollo de la aplicación (los objetos del AOT) se eliminan y su contenido pasa a la base de datos, lo cual no supondrá ningún cambio a nivel funcional pero mejorará la velocidad de acceso a estos datos, lo cual es motivo de tiempos de respuesta demasiado altos actualmente, por ejemplo, al hacer búsquedas en los objetos del AOT o en otras opciones de MorphX.


Además de esto el hecho de cambiar del rígido modelo de datos en ficheros a un nuevo modelo basado en bases de datos permitira mayor flexibilidad y escalabilidad, por ejemplo, para evitar los problemas de element-ID.


Descripción mas ténica y concreta en el enlace de abajo.

07-05-2009 | deja un comentario