1. Evaluación del modelo actual de trabajo de tu organización (realización de esquema + fallos
encontrados/oportunidades de mejora) y replanteamiento u optimización bajo la
introducción de los principios del pensamiento ágil.
Evaluación de modelo actual de trabajo.
A la hora de analizar el modo de trabajo me centrare en mi departamento ya que mi empresa
como organización es muy amplia y diversa. Su sector es el de transformados del metal
aunque yo trabajo en la parte que se dedica a Automatización de Sistemas de Almacenaje.
Para otro módulo de este postgrado escribí este artículo
http://comunidad.iebschool.com/pgmsmartagile/2013/11/12/como-las-metodologias-agilessurgen-de-manera-natural/
En el indicaba como partiendo de no tener una metodología definida de trabajo algunas de las
practicas que utilizamos se asemejaban mucho a los conceptos del desarrollo ágil.
Ya que estas prácticas lamentablemente no se aplican en todos los proyectos y casos me
centrare en una visión un poco más negativa a la hora de hacer este análisis de la organización.
La parte a la que pertenezco se dedica al desarrollo de un sistema WMS
http://en.wikipedia.org/wiki/Warehouse_management_system propio y también a la
realización de proyectos personalizados a partir de dicho sistema.
Desarrollo de productos internos.
-
-
Hay varios equipos de más o menos 10 integrantes. Cada uno se ocupa de una parte
de los productos que desarrollamos.
No hay una metodología definida de desarrollo es decir no hay ninguna mínima guía
de procesos a seguir estos se van decidiendo sobre la marcha.
Se parte un documento de requisitos para cada tarea principal con muy poco detalle
que se dividen en tareas más pequeñas. Dichas tareas suelen comprender a distintos
equipos (por ejemplo GUI y lógica de negocio).
La comunicación se hace a través de correo electrónico, documentos y verbalmente
pero se tiende a preferir las dos primeras a la hora de tomar decisiones.
Solo se genera la documentación estrictamente necesaria. Aunque a veces se tiende a
que sea menos de la que debería simplemente por el hecho de no “mojarse”.
Una vez establecido un plazo (normalmente absurdo para intentar presionar) se
modifica innumerables veces al ver que no se cumple.
No se hacen entregables intermedios. Ni tampoco iteraciones. Se añaden requisitos
según van apareciendo pero solo en las primeras fases.
En los equipos se suele sentar juntas a personas de poca experiencia con personas de
mucha para facilitar el aprendizaje.
Es fácil comunicarse e intercambiar información entre los integrantes de un equipo o
entre equipos pero solo para cuestiones técnicas. Las decisiones que atañen al
desarrollo (alcance, requisitos, plazos) deben decidirse entre los jefes de equipo.
Desarrollo de proyectos para cliente.

2. -
-
-
-
Se parte de unos requisitos generales que se negocian por la parte comercial estos
comprenden desde obra civil a robótica y software.
La parte de requisitos de software se refina con el cliente hasta tener un documento
consensuado por ambas partes.
No hay una metodología definida de desarrollo es decir no hay ninguna mínima guía
de procesos a seguir estos se van decidiendo sobre la marcha.
Durante el desarrollo como norma general no se muestran entregables al cliente. Lo
que si se hace es probar algunas partes criticas (reglas logísticas, comunicaciones entre
sistemas) utilizando herramientas de simulación colaborando con el cliente.
Hay proyectos grandes que se desarrollan en las instalaciones del cliente en estos
casos en normal que el cliente forme parte del equipo de desarrollo. En este tipo de
proyectos se cambian requisitos y funcionalidades en fases finales del proyecto,
principalmente durante la puesta en marcha. Sin embargo en proyectos pequeños se
intenta que los requisitos nunca se modifiquen y no hay apenas comunicación con el
cliente.
En los proyectos grandes en normal que se desarrolle y arranque por partes el sistema.
En los proyectos pequeños se desarrolla todo a la vez aunque también se suele
arrancar por partes.
Los equipos de desarrollo no suelen ser mayores de diez personas. Son personas de los
diversos equipos de desarrollo de productos internos.
Los plazos se fijan en la negociación y no son flexibles. Se renegocian si es necesario
pero de manera compleja y costosa y además siempre como último recurso.
Los integrantes de los equipos van rotando de proyectos internos a proyectos a cliente para
así favorecer el aprendizaje.
No hay un jefe de proyecto definido, a veces se ocupa el jefe de obra civil. Otras lo hacen
integrantes de los jefes de equipo o personas que integran estos equipos y que tienen
experiencia.
Como pequeño resumen creo que partiendo de una base desorganizada aunque basada en el
desarrollo tradicional (requisitos -> desarrollo -> puesta en marcha) si se han incorporado
algunas prácticas agiles aunque creo que el problema principal es que no se hace de manera
sistemática sino aleatoria.
Propuesta de aplicación de organización y metodología ágil.
En primer lugar y como indicaba en el anterior párrafo creo que la principal mejora en la
organización y en el proceso de desarrollo vendría de aplicar un enfoque sistemático aunque
soy partidario de un enfoque ágil, implemente teniendo una metodología, con sus procesos
etapas, documentación etc creo que mejoraría mucho el funcionamiento de mi departamento
ya que a mi parecer es una organización demasiado caótica.
Las acciones que tomaría para mejorar la organización y el desarrollo serian:

3. Adoptar una metodología ágil de desarrollo. Aportará además de la flexibilidad y adaptabilidad
un guion a seguir por todas las partes implicadas. Se aplicara tanto a proyectos internos como
externos.
Los requisitos (para ambos tipos tanto interno como externo) se definirán de manera general.
Pero se irán refinando de manera iterativa en todas las fases del desarrollo (junto con el
cliente si este interviene) intentando que en la puesta en marcha la necesidad de cambios sea
la mínima posible (y no al revés).
Aunque se establecerá un plazo de entrega total. Se acordara con el cliente plazos para
entregas intermedias en plazos no muy largos para favorecer el desarrollo iterativo y el
refinamiento de requisitos.
En el caso de proyectos internos se establecerán plazos flexibles y se también se harán
iteraciones sobre los productos a desarrollar.
En los proyectos para cliente se mantendrá comunicación fluida y continua (ayudado por la
iteración) y siempre que sea posible el cliente se integrara de alguna manera en los equipos de
desarrollo.
Para todos los proyectos se utilizaran herramientas de comunicación (wikis, rsc, ...) para
favorecer el trabajo en equipo.
Se creara una figura o varias para dedicarse (aunque no tiene por qué ser en exclusiva) a la
revisar la gestión de los proyectos. Aunque los equipos de desarrollo se auto gestionaran estas
personas realizaran la labor de coordinación y seguimiento.
Se incidirá en la formación y la mejora de las aptitudes de los integrantes de los equipos.
En resumen con una organización que abrace los principios agiles (o solo alguna) creo que se
mejoraría tanto la satisfacción del cliente (mejoraríamos los resultados) como refinaríamos los
métodos de trabajo y la manera de enfocar los proyectos.
Por supuesto esto requiere de un cambio de mentalidad en mi organización pero también los
clientes.