Evaluación del modelo actual de trabajo de tu organización (realización de esquema + fallos
encontrados/oportunidades de m...
-

-

-

-

Se parte de unos requisitos generales que se negocian por la parte comercial estos
comprenden desde obra civil...
Adoptar una metodología ágil de desarrollo. Aportará además de la flexibilidad y adaptabilidad
un guion a seguir por todas...
Próxima SlideShare
Cargando en…5
×

Analisis y propuesta de metodos de trabajo

235 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
235
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
4
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Analisis y propuesta de metodos de trabajo

  1. 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. 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. 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.

×