Inicio arrow Artículos - apuntes arrow Scrum Management: adopción flexible de la agilidad, que implica a toda la organización. Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Scrum Management: adopción flexible de la agilidad, que implica a toda la organización.
Valoración del artículo: / 16
MaloBueno 
08.07.2009

mapaEs frecuente apostar por un camino profesional: PMI, Scrum, Lean, CMMI... por ser el que las circunstancias nos han puesto delante como solución, y tirar así por él sin conocer cuál es su trayectoria en un mapa de situación general. De dónde viene y a dónde va; y sobre todo hacia dónde queremos ir por el tipo de empresa y proyectos  en los que trabajamos.

Hace un rato comentaba Angel: "... aún hay un gran desconocimiento sobre metodologías ágiles en entornos que podríamos llamar "tradicionales". Ocurre lo mismo con los que llevan años trabajando con Scrum u otras metodologías ágiles.."

Aunque las clases y los apuntes de introducción son menos amenos que los que entran directamente en harina mostrando cómo estimar un backlog, componer una pizarra kanban, etc.  he pasado a post los apuntes del que consideré curso necesario de introducción en la plataforma Scrum Manager, antes de tratar historias de usuario, reuniones, gráficos burn-down, etc. para partir desde el marco de situación de la agilidad, y desde la conveniencia de considerarla de forma global y flexible.
Para acostumbrarnos desde el principio a ser los artífices de nuestro marco de trabajo, y los que seleccionamos, adaptamos o diseñamos los procedimientos trabajamos.

Mapa de situación.

La Tesis: Ingeniería, gestión predictiva y procesos

Desde 1968 hasta la fecha han sido muchos los esfuerzos realizados por los departamentos de informática de las universidades, y por organismos de estandarización y asesoría para identificar las causas de los problemas habituales en los proyectos de software, y definir pautas estándares para su solución.
Los esfuerzos desarrollaron en las tres últimas décadas del siglo pasado tres áreas de conocimiento que se revelaron como estratégicas para hacer frente a la crisis del software:

  • Ingeniería del software
  • Gestión predictiva de proyectos
  • Producción basada en procesos.
Criterios de la tesis


 
INGENIERÍA DEL SOFTWARE
Término acuñado en la conferencia de la NATO de 1968, al definir la necesidad de una disciplina científica que, como ocurre en otras áreas, permita aplicar un enfoque sistemático, disciplinado y cuantificable al desarrollo operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software.

El proyecto más consensuado hasta la fecha para definir las áreas de conocimiento que comprenderían una ingeniería del software es el SWEBOK.

GESTIÓN DE PROYECTOS PREDICTIVA
La necesidad de profesionalizar la gestión de proyectos surgió en los 50, en el ámbito militar, para abordar el desarrollo de complejos sistemas militares que requería coordinar el trabajo conjunto de equipos y disciplinas diferentes, en la construcción de sistemas únicos.

La industria del automóvil siguió los pasos de la militar, aplicando técnicas de gestión de proyectos para la coordinación del trabajo entre áreas y equipos diferentes.

Comenzaron a surgir técnicas específicas, histogramas, cronogramas, los conceptos de ciclo de vida del proyecto o descomposición en tareas (WBS Work Breakdown Structure).

La gestión de proyectos predictiva o clásica es una disciplina formal de gestión, basada en la planificación, ejecución y seguimiento a través de procesos sistemáticos y repetibles.

En los 80 se definieron los objetivos que la gestión de proyectos debía cumplir para poder considerar que el trabajo concluye con éxito:

  • Se ejecuta en el tiempo planificado.
  • Sin desbordar el presupuesto estimado.
  • Satisfaciendo las necesidades del cliente
  • Realiza las funcionalidades que necesita.
  • Las realiza correctamente y sin errores.


En la actualidad, según el estudio periódico, que desde 1994 realiza Standish Group, escasamente uno de cada tres proyectos de desarrollo de software termina en éxito.

 
Standish Group


Características de la gestión de proyectos predictiva

  • Establece como criterios de éxito: obtener el producto definido, en el tiempo previsto y con el coste estimado.
  • Asume que el proyecto se desarrolla en un entorno estable y predecible.
  • El objetivo de su esfuerzo es mantener el cronograma, el presupuesto y los recursos.
  • Divide el desarrollo en fases a las que considera “ciclo de vida”, con una secuencia de tipo: concepto, requisitos, diseño, planificación, desarrollo, cierre.

PRODUCCIÓN BASADA EN PROCESOS
Sobre el principio de calidad de Jurán, empleado con buenos resultados en los procesos de producción industrial: "La calidad del resultado depende básicamente de la calidad de los procesos empleados en su producción", se desarrollaron también para la industria del software modelos de procesos (ISO 9003, CMMI, ISO 15504...) para que las empresas puedan alcanzar los cuatro beneficios clave de la producción basada en procesos:

  • Repetibilidad de resultados. Al conseguir que la calidad del resultado sea consecuencia del proceso, producir aplicando el mismo proceso garantiza la homogeneidad de los resultados.
  • Escalabilidad. Es una consecuencia de la repetibilidad. No sólo un equipo consigue resultados homogéneos en todos los proyectos, sino que los obtienen todos los equipos.
  • Mejora continua. Al aplicar meta-procesos que trabajan sobre los propios procesos de producción, midiendo y analizando los resultados se obtienen los criterios de gestión necesarios para aplicar medidas que mejoran de forma continua la eficiencia y calidad de los procesos base, y por tanto de los resultados.
  • Un know-how propio, consiguiendo finalmente una empresa que sabe hacer, porque su modelo de procesos termina conteniendo un activo valioso de la organización: el conocimiento clave para hacer las cosas bien, con eficiencia y de forma homogénea.

 

La Antítesis: Agilidad

¿El modelo predictivo es el único posible?

¿Los criterios para determinar el éxito sólo pueden ser el cumplimiento de fechas y costes?

¿Puede haber proyectos que no tengan como finalidad realizar un trabajo previamente planificado, con un presupuesto y en un tiempo previamente calculados?

¿Y si el cliente no estuviera interesado en saber si el sistema tendrá 20 ó 200 funcionalidades, si estará en beta 6 meses o 2 años?

¿Si su interés fuera poner en el mercado antes que nadie un producto valioso para los clientes, y estar continuamente desarrollando su valor y funcionalidad?

Quizá en algunos proyectos de software el empeño en aplicar prácticas de estimación, planificación, ingeniería de requisitos sea un empeño vano. Quizá la causa de los problemas no sea tanto por una mala aplicación de las prácticas, sino por la aplicación de prácticas inapropiadas.

Quizá se estén generando “fiascos” al exigir a los clientes criterios de adquisición, y al aplicar a los proyectos procesos de gestión predictivos, cuando se trata de proyectos que no necesitan tanto garantías de previsibilidad en la ejecución, como valor y flexibilidad para trabajar en un entorno cambiante.

 
Manifiesto Ágil


En marzo de 2001, 17 críticos de los modelos de mejora basados en procesos, convocados por Kent Beck, que había publicado un par de años antes el libro "Extreme Programming Explained" en el que exponía una nueva metodología denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre el desarrollo de software.

En la reunión se acuñó el término “Métodos Ágiles” para definir a los que estaban surgiendo como alternativa a las metodologías formales: CMM-SW (precursor del CMMI), PMI, SPICE (proyecto inicial de ISO 15504), etc. a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo.

Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado como “Manifiesto Ágil”, que son los principios sobre los que se basan estos métodos.

Hasta 2005, entre los defensores de los modelos de procesos y los de modelos ágiles han sido frecuentes las posturas radicales, quizá más ocupadas en descalificar al otro, que en estudiar sus métodos y conocerlos para mejorar los propios.
 

Valoramos más a los individuos y su interacción que a los procesos y las herramientas.


Este es posiblemente el principio más importante del manifiesto.

Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero en trabajos que requieren conocimiento tácito, sin personas con conocimiento técnico y actitud adecuada, no producen resultados.
Las empresas suelen predicar muy alto que sus empleados son lo más importante, pero la realidad es que en los años 90 la teoría de producción basada en procesos, la reingeniería de procesos ha dado a éstos más relevancia de la que pueden tener en tareas que deben gran parte de su valor al conocimiento y al talento de las personas que las realizan.

Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. La defensa a ultranza de los procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovación.

Valoramos más el software que funciona que la documentación exhaustiva.


Poder ver anticipadamente cómo se comportan las funcionalidades que se esperan sobre prototipos o sobre partes ya elaboradas del sistema final ofrece un "feedback" muy estimulante y enriquecedor que genera ideas y posibilidades imposibles de concebir en un primer momento, y difícilmente se podrían incluir al redactar un documento de requisitos detallados antes de comenzar el proyecto.

El manifiesto no afirma que no hagan falta. Los documentos son soporte de documentación, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascenden-tales para aportar valor al producto.

Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto.
Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción con el producto, se acaba derivando a emplear a los documentos como barricadas entre departamentos o entre personas.

Valoramos más la colaboración con el cliente que la negociación contractual.


Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle al principio del proyecto, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retroinformación continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio del cliente.

Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber sido implementado directamente sobre el producto.

Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias de responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor.
En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan.

Valoramos más la respuesta al cambio que el seguimiento de un plan


Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente el cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre-establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.

Conocimiento en evolución continua

Cuestionar lo conocido es el motor de la evolución del conocimiento.

No es nuevo. Ya lo formuló Platón, es la base de la teoría dialéctica , y como recuerdan Nonaka y Takeuchi, en Hitotsubashi on Knowledge Mana-gement (Takeuchi & Nonaka, 2004) este patrón dialéctico de tesis, antítesis y síntesis dirige la evolución del conocimiento: antítesis que cuestionan las tesis anteriores, y producen nuevas posturas de síntesis que a su vez harán el papel de tesis en el siguiente ciclo evolutivo; formando así una espiral de evolución y perfeccionamiento continuo.

La evolución del conocimiento sigue el patrón dialéctico de tesis – antítesis y síntesis.

evolución dialéctica del conocimiento

Los modelos basados en procesos han sido la "tesis" que inicia el conocimiento para desarrollar sistemas de software.
La agilidad es su antítesis, y estamos generando en estos años la síntesis: el resultado que se enriquece de ambos, y logra un conocimiento más completo y depurado

 

En los 80 y 90 comienza a cristalizar la primera base de conocimiento: la tesis.

  • Los modelos de procesos específicos: ISO9000-3 CMM’s, SPICE-ISO 15504 , Bootstrap, etc.
  • Aplicación del mismo patrón predictivo de gestión de proyectos, aplicado en otras ingenierías: PMI , IPMA .
  • Primer borrador de consenso sobre el cuerpo de conocimiento de la Ingeniería del Software: SWEBOK (IEEE Computer Society, 2000).


En los 90, llega la difusión y aplicación de este conocimiento. En algunos ámbitos da buenos resultados, y en otros genera la réplica "dialéctica": El Manifiesto Ágil, que cuestiona la validez de los modelos basados en procesos y la gestión predictiva para el desarrollo de software.
Se radicalizan las posturas entre ambas líneas y se genera (y se está generando) la tensión entre contrarios que mueve la evolución dialéctica del conocimiento.

Algunos ejemplos de esta tensión:

"La diferencia entre un atracador de bancos y un teórico de CMM es que con el atracador se puede negociar"…
"La evaluación en CMM depende más de una buena presentación en papel que da la calidad real del producto de software. Tiene que ver más con el seguimiento a ciegas de una metodología que con el desarrollo y puesta en producción de un sistema en el panorama tecnológico".

Ken Orr , CMM versus Agile Development: Religious wars and software development .


"Si uno pregunta a un ingeniero de software típico si cree que CMM se puede aplicar a los métodos ágiles, responderá o con una mirada de sorpresa o con una carcajada histérica".

Richard Turner y Apurva Jain, Agile meets CMMI: Culture Clash or Common Cause .


En los últimos años se apuntan ya las tendencias de la evolución hacia la síntesis:
En estos momentos autoridades de la Ingeniería del Software como Barry Boehm y Richard Turner hablan de balancear la agilidad y la disciplina (Boehm & Turner, 2004)

ISO comprueba y anuncia que los modelos desarrollados funcionan en unos entornos, pero no en otros, y ha creado ya comités para desarrollar versiones más ligeras (Laporte & April, 2005).

Surgen iniciativas de normalización como MoProSoft que buscan puntos intermedios entre ambos extremos.

Muchos profesionales plantean dudas sobre ambos extremos, y prueban mezclas y soluciones híbridas.

 síntesis


Estamos determinando la primera oposición en la espiral dialéctica del conocimiento de la Ingeniería del software. Es un momento confuso, en el que ya no está tan claro el norte y resulta difícil orientarse. Era más cómodo en 1995 por ejemplo. Con la tesis desarrollada, y sin haber despertado aún su antítesis ágil, sentíamos que habíamos alcanzado la verdad. Que ya sabíamos cómo desarrollar software. Que era cuestión aplicar pautas de ingeniería en fases secuenciales, con gestión predictiva...

Ahora estamos a mitad de resolución entre esa tesis y su antítesis ágil.

La contradicción produce desconcierto, pero además en nuestro caso, la velocidad de comunicación facilitada por Internet, y el apresuramiento general del entorno, hace que se solapen las tres tendencias del ciclo.

ISO 15504, CMMI, Scrum, DSDM, Extreme Programming, etc. son grandes aportaciones y es mucho lo que se puede aprender de ellos, pero es iluso pensar de cualquiera de ellas que es La Solución. El conocimiento siempre estará evolucionando, y no tardarán mucho en quedar mejorados. Los libros sobre CMMI o Scrum de hoy, cuando los leamos dentro de pocos años serán textos de conocimiento desfasado.

La empresa como sistema

La realidad sistémica de las organizaciones un principio de Scrum Manager.

Una empresa es un sistema de múltiples componentes y facetas y las acciones y estrategias en cualquier área tienen implicaciones y necesitan respuestas y alineación con el resto.

La empresa se debe gestionar como una realidad única, y no como un conjunto de departamentos más o menos independientes y comunicados.

Implantar agilidad en la empresa como sistema tiene muchas más implicaciones que implantar agilidad en el departamento de programación.

Desde la visión y cultura de la empresa, hasta las técnicas de programación, pasando por el área de recursos humanos, comercial, contabilidad, calidad, etc. porque implica, o debería implicar, a aspectos como la selección y gestión de las personas, la venta y formalización de contratos, los modelos, prácticas de trabajo, su institucionalización y formación...

Dos aspectos muy importantes antes de comenzar la implantación de un modelo ágil son:

En primer lugar realizar un análisis del perfil de producción y de la identidad de la empresa: cuál es la relevancia de los procesos y de las rutinas, del trabajo y del talento; cuáles las características de los proyectos en cuanto a innovación, estabilidad de requisitos, tamaño...

En segundo, un diseño y una estrategia de implantación, tomando el criterio de flexibilidad de Scrum Management: tomar, modificar o desarrollar las prácticas más adecuadas para usar los principios de la agilidad. En definitiva adaptar las prácticas a la organización, y no al contrario.

Cada empresa tiene su propia estructura organizativa, más o menos compleja y más o menos parecida a otras.
Para Scrum Manager, las áreas de la organización que deben gestionarse de forma sistémica en la implantación o mejora de modelos de producción son las polarizadas en estos tres grupos:

  • Management
  • Proyecto
  • Producto

Áreas Scrum Manager


Management: Áreas de responsabilidad sobre la visión, estrategia, táctica, valores y cultura de la organización.

Proyecto: Áreas de responsabilidad en la comunicación y gestión de los recursos y las personas implicadas en el desarrollo de los proyectos de la empresa.

Producto: Áreas de responsabilidad en la inge-niería y construcción de los productos o servicios desarrollados por la empresa.

 

Reconsiderando: Personas, Procesos y Tecnología

Scrum Manager reconsidera dos vértices del triángulo clásico de los factores de producción: Personas - Procesos y Tecnología.

 
Procesos:
No todo lo que etiquetamos como procesos son la misma cosa. En algunos las personas ayudan al "proceso", y en otros son los "procesos" los que ayudan a las personas.
En el primer caso el proceso es el protagonista, el que sabe cómo hacer el trabajo y la persona se integra en el sistema como instrumento, como operario de apoyo. En el segundo el artífice es la persona y el proceso una ayuda, una herramienta que simplifica aspectos rutinarios para que pueda lograr más eficiencia y no diluir el esfuerzo en rutinas mecánicas.

La principal diferencia entre unos y otros es el tipo de conocimiento con el que trabajan. La clasificación de Nonaka y Takeuchi entre explícito (contenido en los procesos y la tecnología), y tácito (contenido en la persona).

Scrum Manager abre una distinción, considerando que los "procedimientos" de trabajo pueden ser: "procesos" cuando tienen el conocimiento clave y por tanto operan en sistemas de conocimiento explícito, y "rutinas" ayudan a las personas, que son quienes tienen el conocimiento clave, y por tanto operan en sistemas de conocimiento tácito.

Procesos


Los modelos de gestión y mejora basados en procesos, centran el foco de la producción en los procesos y la tecnología, como los elementos más valiosos de la producción.

 

Procesos y tecnología  Personas

Su antítesis, las prácticas ágiles, focalizan el valor de la producción en las personas.


Desde el punto de vista de Scrum Manager, ambas opciones son posibles, pero cada una para un entorno diferente.
En entornos de producción industrial que centran el conocimiento en los procesos y tecnología empleada, las personas aportan trabajo para auxiliar a los procesos y la tecnología, y el valor del resultado depende principalmente de los primeros.

Sin embargo para las empresas del conocimiento que trabajan en escenarios rápidos e innovadores, el principal valor es el talento de las personas.


Personas
En este vértice Scrum Manager apunta que "personas" no es un factor único. Son dos: trabajo y conocimiento; y que el grado de valor de cada uno en el producto es determinante en decisiones de gestión y modelos de producción.
 

 Personas = trabajo / conocimiento

Mapa desde el escenario visto desde Scrum Manager

Desde los 80 son muchos los modelos y prácticas que desde organizaciones de investigación, estandarización, y la propia industria se han desarrollado como propuestas de solución a los problemas habituales de los proyectos de software.

Son tantos que su mera relación se antoja como una sopa de letras en la que resulta difícil identificar qué es cada uno: PMBOK, CMM, DSDM, Crystal, ISO 15504, RUP, XP, Scrum, ITIL, ASD, PRINCE 2, LEAN, TDD, etc.

Resulta que los "árboles" no nos dejan ver que el "bosque" tiene una estructura, o un "mapa" relativamente simple que nos permite comprender qué es cada uno, y hace más fácil tomar decisiones para apuntar al conocimiento de unos u otros según queramos trabajar más sobre procesos o rutinas; sobre predicción o agilidad.

Los criterios que dibujan el mapa son:

  • Hay Modelos y Prácticas. Los primeros dicen QUÉ hay que hacer, y los segundos cómo se deben hacer.
  • Unos trabajan con conocimiento explícito (PROCESOS) y otros con conocimiento tácito (RUTINAS).


y en ambos casos los hay:

  • Enfocados en una de las áreas clave iden-tificadas en Scrum Manager (gestión de proyecto, desarrollo de producto o gestión de la organización)
  • De ámbito global que cubren las tres áreas clave de la organización.

CRITERIO: MODELOS / PRÁCTICAS
No definen "CÓMO" hacer las cosas, sino "QUÉ" cosas se deben hacer para conseguir los mejores resultados. Relacionan, como por ejemplo CMMI, que se debe llevar a cabo: gestión de la configuración, gestión de proyecto, medición y análisis, desarrollo de requisitos, validación, etc. pero sin prescribir formas, modelos ni herra-mientas concretas.

Unos se centran sólo en un área de la organización (generalmente gestión de proyecto).

Modelos centrados en un área (gestión de proyecto)

  • Ágiles: Crystal, DSDM, Lean, Unified Process (RUP, Open UP, OUM, AUP, EssUP), MSF
  • Predictivos: PMBOK, PRINCE2


Y otros abarcan todas las áreas de la organización implicadas en el desarrollo de software

 
Modelos

Los modelos más conocidos de este tipo son CMMI e ISO 15504.

Tienen dos finalidades:
1.- Para mejorar: Como guión en los procesos de mejora, que indica cuáles son las áreas que se deben ir abordando.
2.- Para evaluar: Como criterio para medir a una organización cómo de bien lo hace, según cuántas de las cosas que dice el modelo, está cubriendo adecuadamente.

Relación de modelos con carácter glogal:

  • Basados en procesos: CMMI, ISO 15504
  • Ágiles: Scrum Manager (La necesidad de abordar la agilidad desde la visión de la empresa en su conjunto es una de las razones de evolución hacia Scrum Manager)
Modelos


 
Prácticas

Las prácticas dicen "CÓMO" hacer las cosas: cómo describir y gestionar los requisitos (historias de usuario, elementos de backlog...), cómo estimarlos, cómo realizar las reuniones para validar con el cliente, cómo realizar el mantenimiento del código, las pruebas, la integración...

  • Ágiles: eXtreme Programming, Scrum, FDD, CDT, EVO, TDD
  • Predictivas: ITIL
Prácticas


 
CRITERIO: PROCESO O RUTINA
Como se ha expuesto en el apartado anterior, Scrum Manager diferencia en los procedimientos de trabajo entre procesos y rutinas.
Cuando el procedimiento de trabajo contiene la mayor parte del conocimiento necesario para obtener el resultado (conocimiento explícito), se trata de un proceso.

Cuando son las personas las poseedoras del conocimiento clave para obtener el resultado (conocimiento tácito) entonces los procedimientos de trabajo son rutinas.

Procesos

 

Rutinas

 

Scrum Manager: agilidad flexible y sistémica
Scrum Manager es un modelo general de gestión de entornos de producción basados en rutinas, esto es, entornos en los que es más relevante el conocimiento tácito de las personas, que el explícito contenido en los procesos y la tecnología.


Scrum Manager se clasifica mejor como modelo que como conjunto de prácticas, porque a diferencia de éstas, no prescribe "CÓMO" deben hacerse las cosas, (backlogs, historias de usuario, reuniones...) ni que éstas deban hacerse de una determinada manera; sino "QUÉ" cosas deben hacerse. Se centra más en los principios de la agilidad y los procesos, que en prácticas concretas, y sobre los principios, y las características de la empresa y el proyecto, determina los procedimientos de trabajo.

Esta es su característica de flexibilidad: adaptar los procedimientos a la empresa, y no al contrario.

Y se trata además un modelo sistémico o global, porque la implantación de Scrum Manager implica no sólo al área de gestión de proyectos, o de solución técnica; sino a las dos, junto con el "management" de la empresa: su organización, estrategia y cultura.

 

Scrum Manager: Agilidad flexible y sistémica


Safe Creative #0907084101848

 

Trackback(0)
Comentarios (6)Add Comment
Excelente Post
escrito por Alvarezval, July 11, 2009
Sinceramente una de las mejores cosas que he leido sobre el tema.
Gracias
Gracias
escrito por Juan, July 12, 2009
Muchas gracias por el piropo, Jesús.

Un saludo!
Juan
muy buen post
escrito por naitsir, July 21, 2009
te pasaste con este pos... en verdad esta excelente!!
Excelente
escrito por Atorres, July 23, 2009
Mejor... imposible. Excelente post.
Gracias
escrito por Juan, July 23, 2009
Gracias de nuevo. smilies/smiley.gif


Si queréis conocer más las implicaciones de esta visión, este post está entresacado del material de este curso de introducción de Scrum Manager: MAPA DE SITUACIÓN (http://www.scrummanager.net/ok...w.php?id=5)
...
escrito por Carles, June 01, 2010
Excepcional la capacidad de sintesis que conlleva este artículo, es para enmarcarlo.
Felicidades Juan smilies/wink.gif y gracias por su divulgación

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement





Artículos relacionados

Registrado en Safe Creative