Es interesante observar como Occidente, a lo largo de los años, ha intentado explicarse el aplastante éxito de las empresas japonesas: Algunos autores han argumentado que fue la aplicación de las técnicas de control estadístico enseñadas en los cincuentas por Deming y Juran; otros, sostienen que en realidad el éxito reside en el uso de TQM y Lean, junto a otros viejos conocidos tales como JIT, QFD, Kaizen, etc., etc.
Algunos observadores (entre ellos David Hutchins) aclaran que estas herramientas no deberían ser aplicadas aisladamente. Según ellos, el éxito de las empresas japonesas reside en el proceso de gestión estratégica que las integra, llamado Hoshin-Kanri.
Este método es una adaptación del ciclo PDCA popularizado por Deming en Japón. En pocas palabras, consiste en definir la estrategia en forma colaborativa y "bajarla" a acciones concretas para el día a día. Para la fase D del ciclo, Hoshin Kanri confía en las herramientas de TQM/Lean.
A través de este método, las organizaciones consiguen alinear sus esfuerzos detrás de unos pocos objetivos a mediano/largo plazo, los que se traducen en acciones concretas para el corto.
En este contexto, TQM/Lean se transforman en el cómo, mientras que Hoshin Kanri es el qué.
En próximos posts trataré de ir profundizando este muy interesante enfoque.
lunes, 14 de septiembre de 2009
miércoles, 19 de agosto de 2009
Lo más importante es saber cambiar...
En un post anterior comentaba lo cansado que estaba de escuchar hablar del movimiento ágil. Cuidado, no es que esté en contra o no me guste, todo lo contrario. Lo que ocurre es que llega un momento en que la misma etiqueta se usa para todo y entonces pierde un poco de sentido (los últimos quince años están repletos de ejemplos: reingeniería, gestión del conocimiento, orientación a objetos, componentización, etc., etc.)
Personalmente, creo que SCRUM y FDD son lo mejor que ha surgido en los últimos años. Su visión de cómo organizar el trabajo es una verdadera bocanada de aire fresco en medio de tanta obsesión por el control (ver post acerca de Tom DeMarco).
Sin embargo, implementarlas no es tarea fácil. Si bien casi todas resultan "simpáticas", conseguir que se adopten masivamente es todo un desafío.
Caminando un poco el mercado, lo que se puede observar es la marcada incapacidad de muchas organizaciones de poner en marcha cualquier tipo de práctica que altere el status-quo.
Esa tendencia a mantener viejas costumbres está en la misma naturaleza del ser humano. Nuestro cerebro consume menos energía cuando dirige automáticamente actividades rutinarias. En cambio, cuando aprendemos algo nuevo usamos la corteza prefrontal, una zona que devora recursos.
El cerebro intentará usar lo menos posible la corteza prefrontal para ahorrar energía. Esa es la razón por la cual nos cuesta abandonar hábitos arraigados: Cambiar produce una respuesta fisiológica en el cerebro.
El cambio también está condicionado por las variables sociales. Los grupos se mueven cuando hay una masa crítica que apoya el cambio. Una minoría jamás lo conseguirá.
Por lo tanto, ya se trate de un nuevo sistema, de una metodología ágil o de un nuevo entorno de desarrollo, es fundamental saber cómo implementar el cambio efectivamente.
Lamentablemente, a lo largo de los años me ha tocado ser testigo de cómo muchos programas de mejora han quedado solamente en promesas por no saber cómo encarar la necesaria transformación.
Aprender a cambiar es vital para la supervivencia de cualquier organización. Sin esa habilidad, poco éxito tendremos en la implementación de nuevas prácticas y procesos.
Personalmente, creo que SCRUM y FDD son lo mejor que ha surgido en los últimos años. Su visión de cómo organizar el trabajo es una verdadera bocanada de aire fresco en medio de tanta obsesión por el control (ver post acerca de Tom DeMarco).
Sin embargo, implementarlas no es tarea fácil. Si bien casi todas resultan "simpáticas", conseguir que se adopten masivamente es todo un desafío.
Caminando un poco el mercado, lo que se puede observar es la marcada incapacidad de muchas organizaciones de poner en marcha cualquier tipo de práctica que altere el status-quo.
Esa tendencia a mantener viejas costumbres está en la misma naturaleza del ser humano. Nuestro cerebro consume menos energía cuando dirige automáticamente actividades rutinarias. En cambio, cuando aprendemos algo nuevo usamos la corteza prefrontal, una zona que devora recursos.
El cerebro intentará usar lo menos posible la corteza prefrontal para ahorrar energía. Esa es la razón por la cual nos cuesta abandonar hábitos arraigados: Cambiar produce una respuesta fisiológica en el cerebro.
El cambio también está condicionado por las variables sociales. Los grupos se mueven cuando hay una masa crítica que apoya el cambio. Una minoría jamás lo conseguirá.
Por lo tanto, ya se trate de un nuevo sistema, de una metodología ágil o de un nuevo entorno de desarrollo, es fundamental saber cómo implementar el cambio efectivamente.
Lamentablemente, a lo largo de los años me ha tocado ser testigo de cómo muchos programas de mejora han quedado solamente en promesas por no saber cómo encarar la necesaria transformación.
Aprender a cambiar es vital para la supervivencia de cualquier organización. Sin esa habilidad, poco éxito tendremos en la implementación de nuevas prácticas y procesos.
jueves, 13 de agosto de 2009
¿Por qué son malos los servicios?
Estamos en una economía signada por la provisión de servicios. Sin embargo, son muy pocos los que toman conciencia de la importancia de diseñarlos. Resulta muy natural diseñar un producto, pero diseñar un servicio suena como algo raro.
En nuestro país tenemos muchos ejemplos de servicios mal pensados y pésimamente implementados. Los encontramos todos los días, en los lugares más diversos: en el consultorio del médico, en el banco, en los organismos públicos, en las mesas de ayuda...
En muchos casos, es uno el que tiene que hacer el follow-up de los trámites: "Ah, estábamos por llamarlo para avisarle que..."; "Cruce enfrente y saque fotocopias de las páginas 2 y 3"; "Tiene que traer una copia del resumen de cuenta"; etc; etc.
¿Tan difícil es organizarse? ¿Tan difícil es entender que si somos una empresa de servicios tenemos que diseñarlos para que nuestros clientes/usuarios tengan una experiencia agradable y no se vayan agobiados o desalentados por la mala experiencia de tener que interactuar con nosotros? ¿Tan complicado es publicar en la web los requisitos para realizar un trámite o para solicitar un servicio?
Lo mismo es válido para los servicios entre áreas internas: ¿Cómo hago para reportar un incidente con una aplicación?; ¿Cómo hago para pedir una PC?; ¿Cómo hago para...?
Es fácil demostrar cuán negativamente impactan los servicios que se brindan mal. No sólo hay problemas con la imagen de las organizaciones ("Me atendieron remal") sino también consecuencias económicas: duplicación de esfuerzo, información redundante, mal clima general por la desorganización, focalización en lo urgente y no en lo importante, etc., etc...
Las soluciones son relativamente fáciles: hay que diseñar la experiencia del usuario/cliente, definiendo los atributos del servicio y estableciendo los procesos adecuados para proveerlo. De más está decir que al usuario/cliente no le interesa si su pedido está trabado en un departamento determinado o en está detenido en el proceso de aprobación: Lo único que considerará en su evaluación es si lo atendieron amablemente, si le pidieron la información indispensable y no tuvo que repetir 25 veces lo mismo ante otros tantos interlocutores, y si el servicio recibido y los tiempos estuvieron acordes con los estipulados por el proveedor ("En 48. hs lo visitará uno de nuestros técnicos").
Entre tantas cosas que andan dando vueltas por ahí, hay un modelo de capacidades para la tercerización de servicios con fuerte base tecnológica. Se llama eSCM (eSourcing Capability Model) y fue desarrollado por el IT Services Qualification Center de Carnegie Mellon (la misma universidad de CMMI, pero en la facultad de Ciencias de la Computación). Vale la pena darle una mirada. Aquí está el link.
En nuestro país tenemos muchos ejemplos de servicios mal pensados y pésimamente implementados. Los encontramos todos los días, en los lugares más diversos: en el consultorio del médico, en el banco, en los organismos públicos, en las mesas de ayuda...
En muchos casos, es uno el que tiene que hacer el follow-up de los trámites: "Ah, estábamos por llamarlo para avisarle que..."; "Cruce enfrente y saque fotocopias de las páginas 2 y 3"; "Tiene que traer una copia del resumen de cuenta"; etc; etc.
¿Tan difícil es organizarse? ¿Tan difícil es entender que si somos una empresa de servicios tenemos que diseñarlos para que nuestros clientes/usuarios tengan una experiencia agradable y no se vayan agobiados o desalentados por la mala experiencia de tener que interactuar con nosotros? ¿Tan complicado es publicar en la web los requisitos para realizar un trámite o para solicitar un servicio?
Lo mismo es válido para los servicios entre áreas internas: ¿Cómo hago para reportar un incidente con una aplicación?; ¿Cómo hago para pedir una PC?; ¿Cómo hago para...?
Es fácil demostrar cuán negativamente impactan los servicios que se brindan mal. No sólo hay problemas con la imagen de las organizaciones ("Me atendieron remal") sino también consecuencias económicas: duplicación de esfuerzo, información redundante, mal clima general por la desorganización, focalización en lo urgente y no en lo importante, etc., etc...
Las soluciones son relativamente fáciles: hay que diseñar la experiencia del usuario/cliente, definiendo los atributos del servicio y estableciendo los procesos adecuados para proveerlo. De más está decir que al usuario/cliente no le interesa si su pedido está trabado en un departamento determinado o en está detenido en el proceso de aprobación: Lo único que considerará en su evaluación es si lo atendieron amablemente, si le pidieron la información indispensable y no tuvo que repetir 25 veces lo mismo ante otros tantos interlocutores, y si el servicio recibido y los tiempos estuvieron acordes con los estipulados por el proveedor ("En 48. hs lo visitará uno de nuestros técnicos").
Entre tantas cosas que andan dando vueltas por ahí, hay un modelo de capacidades para la tercerización de servicios con fuerte base tecnológica. Se llama eSCM (eSourcing Capability Model) y fue desarrollado por el IT Services Qualification Center de Carnegie Mellon (la misma universidad de CMMI, pero en la facultad de Ciencias de la Computación). Vale la pena darle una mirada. Aquí está el link.
viernes, 7 de agosto de 2009
Estoy cansado del movimiento ágil...
En mi anterior post reproducía algunos comentarios de Ivar Jacobson acerca del movimiento ágil. Creo que sus dichos reflejan lo que muchos pensamos: las principales ideas del movimiento ágil ya forman parte (o al menos deberían) del background de la mayoría de la gente (de ahí a que las pongan en práctica es otro tema). Se habla tanto de "agilidad" que prácticamente ha perdido su significado (lo mismo está pasando con lean).
Por esa misma razón, creo que no tiene sentido ya hablar de "ágil" versus "no ágil." Los que estamos en este negocio desde hace años sabemos que para cada problema hay un enfoque determinado; para un desarrollo pequeño, de baja complejidad, las herramientas deben ser forzosamente sencillas. Para emprendimientos más complejos, el enfoque debe ser diferente. En todos los casos debemos ser ágiles y estar en condiciones de adaptarnos.
Por supuesto que debemos aceptar que en todos estos años hemos aprendido mucho. Algunos "evangelistas" que se inmolan en el púlpito olvidan que el enfoque "tradicional" era el único que había para desarrollar software, aunque en general lo que se hiciera fuera "codificar y probar". Lo que muy bien ha hecho el movimiento ágil fue integrar ideas que estaban dando vueltas desde hace mucho, tomar prestadas algunas otras de otros dominios (por ejemplo, del desarrollo de productos) y agregar las suyas. Su filosofía y las prácticas que propone ya forman parte del cuerpo de conocimiento de la ingeniería de software.
Lo que creo que nunca terminaremos de entender como profesionales es cuánto es suficiente. Me he topado con gente que no entiende que el planeamiento debe ser gradual y progesivo y piden "planes detallados" cuando no es el momento. O supuestos "especialistas" que hacen planes de proyecto con tareas tan granulares que duran menos de quince minutos ("Agendar reunión"). O gente que quiere cerrar los requerimientos antes de empezar con el desarrollo y se consume la mitad del tiempo y los recursos en preparar una propuesta de proyecto. Hace años que sabemos que en la mayoría de los proyectos los planes y los requerimientos se irán refinando en forma progresiva. Me causa un poco de gracia cuando algunos agilistas acusan al ciclo de vida en cascada de todos los males de este mundo. La verdad, no he visto en veinte años un proyecto con ese ciclo de vida (y dicho sea de paso, muy pocos con algún ciclo de vida). ¿Alguien vio alguno?
En el otro extremo, me he encontrado con desarrolladores que no pueden estimar el esfuerzo de hacer algo. Sus argumentos son que simplemente no pueden hacerlo. "OK, pero estamos hablando de una componente de tal tipo, de tales características, para hacer esto". "No puedo hasta que no lo haga". ¿No es de locos? Por supuesto que el desarrollo de software es buena medida exploratorio, pero sigue siendo imporante para el negocio hacer pronósticos. "¿Vamos a gastar 20 pesos o dos millones de dólares?".
En definitiva, creo que el único camino es balancear constantemente lo que sabemos y aplicar adecuadamente las herramientas. Los extremos son malos...
Por esa misma razón, creo que no tiene sentido ya hablar de "ágil" versus "no ágil." Los que estamos en este negocio desde hace años sabemos que para cada problema hay un enfoque determinado; para un desarrollo pequeño, de baja complejidad, las herramientas deben ser forzosamente sencillas. Para emprendimientos más complejos, el enfoque debe ser diferente. En todos los casos debemos ser ágiles y estar en condiciones de adaptarnos.
Por supuesto que debemos aceptar que en todos estos años hemos aprendido mucho. Algunos "evangelistas" que se inmolan en el púlpito olvidan que el enfoque "tradicional" era el único que había para desarrollar software, aunque en general lo que se hiciera fuera "codificar y probar". Lo que muy bien ha hecho el movimiento ágil fue integrar ideas que estaban dando vueltas desde hace mucho, tomar prestadas algunas otras de otros dominios (por ejemplo, del desarrollo de productos) y agregar las suyas. Su filosofía y las prácticas que propone ya forman parte del cuerpo de conocimiento de la ingeniería de software.
Lo que creo que nunca terminaremos de entender como profesionales es cuánto es suficiente. Me he topado con gente que no entiende que el planeamiento debe ser gradual y progesivo y piden "planes detallados" cuando no es el momento. O supuestos "especialistas" que hacen planes de proyecto con tareas tan granulares que duran menos de quince minutos ("Agendar reunión"). O gente que quiere cerrar los requerimientos antes de empezar con el desarrollo y se consume la mitad del tiempo y los recursos en preparar una propuesta de proyecto. Hace años que sabemos que en la mayoría de los proyectos los planes y los requerimientos se irán refinando en forma progresiva. Me causa un poco de gracia cuando algunos agilistas acusan al ciclo de vida en cascada de todos los males de este mundo. La verdad, no he visto en veinte años un proyecto con ese ciclo de vida (y dicho sea de paso, muy pocos con algún ciclo de vida). ¿Alguien vio alguno?
En el otro extremo, me he encontrado con desarrolladores que no pueden estimar el esfuerzo de hacer algo. Sus argumentos son que simplemente no pueden hacerlo. "OK, pero estamos hablando de una componente de tal tipo, de tales características, para hacer esto". "No puedo hasta que no lo haga". ¿No es de locos? Por supuesto que el desarrollo de software es buena medida exploratorio, pero sigue siendo imporante para el negocio hacer pronósticos. "¿Vamos a gastar 20 pesos o dos millones de dólares?".
En definitiva, creo que el único camino es balancear constantemente lo que sabemos y aplicar adecuadamente las herramientas. Los extremos son malos...
martes, 28 de julio de 2009
Jacobson habla del movimiento ágil
Acabo de topar con un muy interesante post de Ivar Jacobson de abril de este año. Hace allí algunas reflexiones acerca de la saturación que está produciendo el movimiento ágil en algunos actores. Aparentemente, la gente está empezando a aburrirse de todo lo que tenga la etiqueta "ágil" (últimamente, casi todo).
Jacobson no está en contra del movimiento ágil, pero llama a tener una actitud un poco más equilibrada para balancear la práctica con la postura de los evangelistas desenfrenados.
Uno sólo de los párrafos da para iniciar un debate que probablemente sea interminable:
"Fortunately agile has grown up a bit – and the zealots have mostly been replaced by more reasonable proponents who know that there are many good things in agile approaches, but they need to be blended with other things to really be successful."
Que lo disfruten.
Jacobson no está en contra del movimiento ágil, pero llama a tener una actitud un poco más equilibrada para balancear la práctica con la postura de los evangelistas desenfrenados.
Uno sólo de los párrafos da para iniciar un debate que probablemente sea interminable:
"Fortunately agile has grown up a bit – and the zealots have mostly been replaced by more reasonable proponents who know that there are many good things in agile approaches, but they need to be blended with other things to really be successful."
Que lo disfruten.
miércoles, 15 de julio de 2009
40 años de ingeniería de software. ¿Valieron la pena?
Tom DeMarco acaba de publicar un excelente artículo en donde presenta algunas reflexiones con motivo de cumplirse cuarenta años de la famosa conferencia de la OTAN en la que se presentó por primera vez el término ingeniería de software.
DeMarco hace una profunda autocrítica del papel que jugó su libro Controlling Software Projects: Management, Measurement, and Estimation en el establecimiento de una obsesión colectiva en torno a la predictibilidad y el control, aspectos que se tornaron en algo demasiado relevante dentro de la ingeniería de software.
A continuación, reproduzco algunos de los párrafos más importantes:
"...strict control is something that matters a lot on relatively useless projects and much less on useful projects."
"Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to Control them, no matter how assiduously we apply ourselves to control."
"Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business."
DeMarco concluye su artículo con una clarificadora reflexión:
"Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been."
DeMarco hace una profunda autocrítica del papel que jugó su libro Controlling Software Projects: Management, Measurement, and Estimation en el establecimiento de una obsesión colectiva en torno a la predictibilidad y el control, aspectos que se tornaron en algo demasiado relevante dentro de la ingeniería de software.
A continuación, reproduzco algunos de los párrafos más importantes:
"...strict control is something that matters a lot on relatively useless projects and much less on useful projects."
"Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to Control them, no matter how assiduously we apply ourselves to control."
"Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business."
DeMarco concluye su artículo con una clarificadora reflexión:
"Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been."
martes, 14 de julio de 2009
Una crítica al sistema lean
En estos últimos días he estado leyendo un excelente libro llamado "Myths at Work", en donde se analizan y critican varias de las creencias más arraigadas en el management moderno, tales como la globalización, la participación de la mujer en el mundo del trabajo,el sistema lean, etc.
Más allá de estar de acuerdo o no con todo lo que los autores plantean, creo que es muy interesante el análisis que hacen de cada uno de los temas. La mayoría de las veces se adoptan escuelas de pensamiento como si fueran "modas", lo cual genera expectativas desmedidas que después no se cumplen y que terminan "quemando" el tema. El mundo de la tecnología está repleto de ideas que prometieron resolver todos nuestros problemas y que luego cayeron en el olvido.
Hay muy buenas ideas en el movimiento lean, pero hay que sopesar -como en todo los órdenes de la vida- todos sus aspectos. Los autores de este libro lo hacen y demuestran que no todo es color de rosa.
Se pueden consultar algunos capítulos en Google Books.
Más allá de estar de acuerdo o no con todo lo que los autores plantean, creo que es muy interesante el análisis que hacen de cada uno de los temas. La mayoría de las veces se adoptan escuelas de pensamiento como si fueran "modas", lo cual genera expectativas desmedidas que después no se cumplen y que terminan "quemando" el tema. El mundo de la tecnología está repleto de ideas que prometieron resolver todos nuestros problemas y que luego cayeron en el olvido.
Hay muy buenas ideas en el movimiento lean, pero hay que sopesar -como en todo los órdenes de la vida- todos sus aspectos. Los autores de este libro lo hacen y demuestran que no todo es color de rosa.
Se pueden consultar algunos capítulos en Google Books.
lunes, 6 de julio de 2009
Value Driven Planning
Tom Gilb ha publicado una excelente presentación acerca de la complementación entre los métodos ágiles y Evo. Se puede descargar aquí.
viernes, 12 de junio de 2009
¿Se puede controlar un proceso creativo?
Muchas de las críticas que se le hacen a CMMI -y que se le hicieron en su momento a SW-CMM- han tenido que ver con la viabilidad de aplicar las técnicas del control estadístico a procesos de desarrollo de software, una disciplina conocimiento-intensiva que gira en torno al diseño y a la creatividad y no alrededor de la fabricación repetitiva de un mismo tipo de producto [Curtis-2008a].
Uno de los principales críticos, por ésta y otras razones, ha sido el movimiento Ágil. Para sus proponentes, no tiene sentido controlar un proceso que, por su naturaleza, se ubica al borde del caos (ver [Anderson, pág.9] y [Schwaber, pág.102]). Según ellos, debido a la natural complejidad del desarrollo de software, se impone la aplicación de otro tipo de control de procesos, llamado control empírico. La idea principal detrás de este punto de vista es que no hay una teoría que explique el fenómeno observado: la única opción posible es observar y adaptar los procesos en función de los resultados obtenidos. En esta visión, no hay procesos definidos (al menos, con el nivel de detalle esperable de una organización madura) ni predecibles.
Sin embargo, no todos en la comunidad ágil piensan lo mismo. David Anderson, uno de los creadores del método FDD (Feature Driven Development) y autor de Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results [Anderson], asegura que un proceso empírico puede arrojar resultados de una precisión similar a la esperada en un proceso definido.
Para Anderson, no siempre el desarrollo de software está al borde del caos: siempre es posible la planificación y la predicción de los resultados dentro de ciertos límites de incertidumbre. Un proceso convergente -ya sea éste empírico o definido- mostrará con el tiempo un comportamiento predecible. En cambio, un proceso divergente se comportará en forma caótica y será imposible de controlar.
Anderson concluye asegurando que es necesario controlar a los procesos para que las organizaciones puedan obtener resultados económicos superiores. De ninguna manera, según su punto de vista, puede confiarse únicamente en los controles reactivos tan populares en los métodos ágiles [Anderson, cap.32].
Ideológicamente más cerca de CMMI, Bill Curtis -co-autor de SW-CMM, People CMM y del reciente Business Process Maturity Model [OMG]- ha cuestionado la aplicabilidad de los grafos de control -una de las herramientas que está en el mismo corazón de la gestión cuantitativa- a los procesos de desarrollo de software [Curtis-2008b], ya que en general las fuentes de datos empleadas son de naturaleza heterogénea.
Curtis plantea que un sistema compuesto por una persona produciendo piezas de código de similares características y bajo las mismas circunstancias tendrá un comportamiento similar a un proceso con causas comunes de variación. Sin embargo, la situación sería otra si las piezas que se le asignaran a esta persona fueran de diferente dificultad. En este caso se estaría introduciendo en el proceso una fuente de variación que alteraría su desempeño, sus límites de control y su predictibilidad. La única solución viable sería desagregar los datos de manera tal de poder construir un grafo de control para cada una de las diferentes complejidades de los componentes.
La situación se tornaría más complicada en el caso de involucrar a más personas en el proceso, ya que aparecerían nuevas fuentes de variación (la productividad y la capacidad de trabajo podrían no ser las mismas en todos). Esto implicaría construir más grafos de control para mantener la homogeneidad de datos, lo cuál sería claramente impracticable.
Curtis y su coautor concluyen afirmando que son otras las herramientas estadísticas que deberían usarse en estos casos, caracterizados por múltiples fuentes de variación. El grafo de control no sería el más aplicable en dichas situaciones.
Esta conclusión es sumamente relevante, ya que las raíces de CMMI en la industria manufacturera son muy profundas. En ella, los supuestos de Walter Shewhart se cumplen y el grafo de control es la herramienta más adecuada. La situación sería completamente diferente en la industria del software.
Buscando el equilibrio
Claramente, el debate está lejos de finalizar. La comunidad informática debe encontrar el punto medio que le permita equilibrar la necesidad de predecir resultados -un imperativo del management de cualquier organización- con la de disponer de procesos ágiles y adaptables.
Varios trabajos ([Dutton], [Fritzsche], [Paulk-1], [Glazer]) puntualizan que en realidad hay más similitudes que diferencias entre los métodos ágiles y CMMI. De hecho, muchas de las prácticas propuestas por el movimiento ágil son una reinterpretación de prácticas existentes en la ingeniería de software y en otras industrias desde hace años y no necesariamente son incompatibles con CMMI.
Probablemente, los puntos más conflictivos sean los relacionados con las áreas de proceso de los niveles 4 y 5. La afirmación de que debe aplicarse un control empírico sobre los procesos contradice el precepto básico de CMMI de que los procesos deben ser controlados estadísticamente. Sin embargo, la recomendación del modelo de seleccionar cuidadosamente cuáles subprocesos controlar pareciera no entrar en conflicto con los preceptos del movimiento ágil.
De todas maneras, el debate continúa y probablemente continuará por bastante tiempo más. Lo que está claro por el momento es que de la discusión surgirá un nuevo enfoque para gestionar el desarrollo de software, basado con seguridad en las mejores ideas de las diferentes escuelas.
Referencias
[Anderson]
David J. Anderson
Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results
Prentice Hall, 2004
[Curtis-2008b]
Bill Curtis, Bob Raczynski
Software Data Violate SPC’s Underlying Assumptions
IEEE Software, Mayo/Junio 2008
[Dutton]
Jeffrey L. Dutton, Richard S. McCabe
Agile/Lean Development and CMMI®
Systems & Software Consortium
Presentación en la SEPG Conference 2006
http://www.sei.cmu.edu/cmmi/adoption/pdf/dutton.pdf
[Fritzsche]
Martin Fritzsche, Patrick Keil
Agile Methods and CMMI: Compatibility or Conflict?
e-Informatica Software Engineering Journal, Volume 1, Issue 1, 2007
http://www.e-informatyka.pl/e-Informatica/attach/Issue1/Vol1Iss1Art1eInformatica.pdf
[Glazer]
Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum
CMMI® or Agile: Why Not Embrace Both!
CMU/SEI-2009-TN-003
http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html
[OMG]
Object Management Group
Business Process Maturity Model - Version 1.0
OMG, 2008
[Paulk-1]
Mark Paulk
Extreme Programming From a CMM Perspective
IEEE Software, Vol.18, Nro.6; noviembre/diciembre 2001
[Schwaber] Ken Schwaber
The Enterprise and Scrum
Microsoft Press, 2007
Uno de los principales críticos, por ésta y otras razones, ha sido el movimiento Ágil. Para sus proponentes, no tiene sentido controlar un proceso que, por su naturaleza, se ubica al borde del caos (ver [Anderson, pág.9] y [Schwaber, pág.102]). Según ellos, debido a la natural complejidad del desarrollo de software, se impone la aplicación de otro tipo de control de procesos, llamado control empírico. La idea principal detrás de este punto de vista es que no hay una teoría que explique el fenómeno observado: la única opción posible es observar y adaptar los procesos en función de los resultados obtenidos. En esta visión, no hay procesos definidos (al menos, con el nivel de detalle esperable de una organización madura) ni predecibles.
Sin embargo, no todos en la comunidad ágil piensan lo mismo. David Anderson, uno de los creadores del método FDD (Feature Driven Development) y autor de Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results [Anderson], asegura que un proceso empírico puede arrojar resultados de una precisión similar a la esperada en un proceso definido.
Para Anderson, no siempre el desarrollo de software está al borde del caos: siempre es posible la planificación y la predicción de los resultados dentro de ciertos límites de incertidumbre. Un proceso convergente -ya sea éste empírico o definido- mostrará con el tiempo un comportamiento predecible. En cambio, un proceso divergente se comportará en forma caótica y será imposible de controlar.
Anderson concluye asegurando que es necesario controlar a los procesos para que las organizaciones puedan obtener resultados económicos superiores. De ninguna manera, según su punto de vista, puede confiarse únicamente en los controles reactivos tan populares en los métodos ágiles [Anderson, cap.32].
Ideológicamente más cerca de CMMI, Bill Curtis -co-autor de SW-CMM, People CMM y del reciente Business Process Maturity Model [OMG]- ha cuestionado la aplicabilidad de los grafos de control -una de las herramientas que está en el mismo corazón de la gestión cuantitativa- a los procesos de desarrollo de software [Curtis-2008b], ya que en general las fuentes de datos empleadas son de naturaleza heterogénea.
Curtis plantea que un sistema compuesto por una persona produciendo piezas de código de similares características y bajo las mismas circunstancias tendrá un comportamiento similar a un proceso con causas comunes de variación. Sin embargo, la situación sería otra si las piezas que se le asignaran a esta persona fueran de diferente dificultad. En este caso se estaría introduciendo en el proceso una fuente de variación que alteraría su desempeño, sus límites de control y su predictibilidad. La única solución viable sería desagregar los datos de manera tal de poder construir un grafo de control para cada una de las diferentes complejidades de los componentes.
La situación se tornaría más complicada en el caso de involucrar a más personas en el proceso, ya que aparecerían nuevas fuentes de variación (la productividad y la capacidad de trabajo podrían no ser las mismas en todos). Esto implicaría construir más grafos de control para mantener la homogeneidad de datos, lo cuál sería claramente impracticable.
Curtis y su coautor concluyen afirmando que son otras las herramientas estadísticas que deberían usarse en estos casos, caracterizados por múltiples fuentes de variación. El grafo de control no sería el más aplicable en dichas situaciones.
Esta conclusión es sumamente relevante, ya que las raíces de CMMI en la industria manufacturera son muy profundas. En ella, los supuestos de Walter Shewhart se cumplen y el grafo de control es la herramienta más adecuada. La situación sería completamente diferente en la industria del software.
Buscando el equilibrio
Claramente, el debate está lejos de finalizar. La comunidad informática debe encontrar el punto medio que le permita equilibrar la necesidad de predecir resultados -un imperativo del management de cualquier organización- con la de disponer de procesos ágiles y adaptables.
Varios trabajos ([Dutton], [Fritzsche], [Paulk-1], [Glazer]) puntualizan que en realidad hay más similitudes que diferencias entre los métodos ágiles y CMMI. De hecho, muchas de las prácticas propuestas por el movimiento ágil son una reinterpretación de prácticas existentes en la ingeniería de software y en otras industrias desde hace años y no necesariamente son incompatibles con CMMI.
Probablemente, los puntos más conflictivos sean los relacionados con las áreas de proceso de los niveles 4 y 5. La afirmación de que debe aplicarse un control empírico sobre los procesos contradice el precepto básico de CMMI de que los procesos deben ser controlados estadísticamente. Sin embargo, la recomendación del modelo de seleccionar cuidadosamente cuáles subprocesos controlar pareciera no entrar en conflicto con los preceptos del movimiento ágil.
De todas maneras, el debate continúa y probablemente continuará por bastante tiempo más. Lo que está claro por el momento es que de la discusión surgirá un nuevo enfoque para gestionar el desarrollo de software, basado con seguridad en las mejores ideas de las diferentes escuelas.
Referencias
[Anderson]
David J. Anderson
Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results
Prentice Hall, 2004
[Curtis-2008b]
Bill Curtis, Bob Raczynski
Software Data Violate SPC’s Underlying Assumptions
IEEE Software, Mayo/Junio 2008
[Dutton]
Jeffrey L. Dutton, Richard S. McCabe
Agile/Lean Development and CMMI®
Systems & Software Consortium
Presentación en la SEPG Conference 2006
http://www.sei.cmu.edu/cmmi/adoption/pdf/dutton.pdf
[Fritzsche]
Martin Fritzsche, Patrick Keil
Agile Methods and CMMI: Compatibility or Conflict?
e-Informatica Software Engineering Journal, Volume 1, Issue 1, 2007
http://www.e-informatyka.pl/e-Informatica/attach/Issue1/Vol1Iss1Art1eInformatica.pdf
[Glazer]
Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum
CMMI® or Agile: Why Not Embrace Both!
CMU/SEI-2009-TN-003
http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html
[OMG]
Object Management Group
Business Process Maturity Model - Version 1.0
OMG, 2008
[Paulk-1]
Mark Paulk
Extreme Programming From a CMM Perspective
IEEE Software, Vol.18, Nro.6; noviembre/diciembre 2001
[Schwaber] Ken Schwaber
The Enterprise and Scrum
Microsoft Press, 2007
viernes, 5 de junio de 2009
Los famosos 14 puntos de Deming
Es sorprendente ver cuán vigentes se mantienen hoy las ideas de Deming. Las dejo en inglés:
- Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.
- Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
- Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
- End the practice of awarding business on the basis of price tag. Instead, minimise total cost. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.
- Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
- Institute training on the job.
- Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of an overhaul, as well as supervision of production workers.
- Drive out fear, so that everyone may work effectively for the company.
- Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.
- Eliminate slogans, exhortations, and targets for the workforce asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
- a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.
b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership. - a. Remove barriers that rob the hourly paid worker of his right to pride in workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.
b. Remove barriers that rob people in management and engineering of their right to pride in workmanship. This means, inter alia, abolishment of the annual or merit rating and management by objective. - Institute a vigorous program of education and self-improvement.
- Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.
martes, 28 de abril de 2009
Servicios de TI
La semana pasada, junto a Jorge Mazzini y Héctor Sambucetti, participé de un webinar organizado por el Foro Help Desk. El tema fue el diseño de servicios basados en tecnología informática.
La charla tuvo muy buena aceptación -participaron cerca de 250 personas- y promete expandirse en tres cursos que se estarán lanzando próximamente.
El video y el audio de la charla pueden descargarse aquí.
La charla tuvo muy buena aceptación -participaron cerca de 250 personas- y promete expandirse en tres cursos que se estarán lanzando próximamente.
El video y el audio de la charla pueden descargarse aquí.
miércoles, 11 de marzo de 2009
Eclipse Process Framework
Gratamente me ha sorprendido la versatilidad del Eclipse Process Framework para especificar procesos. Es una herramienta libre basada en el Rational Process Composer de IBM.
Si bien puede parecer complicada al principio, es muy fácil de usar cuando se entienden algunos puntos clave. De ahí en más, el camino es en bajada. Los sites generados lucen sumamente profesionales y se resuelven automáticamente muchas relaciones (roles vs. actividades, roles vs. artefactos, etc.) que de otra manera habría que construir a mano.
No puedo menos que reomendarlo.
Si bien puede parecer complicada al principio, es muy fácil de usar cuando se entienden algunos puntos clave. De ahí en más, el camino es en bajada. Los sites generados lucen sumamente profesionales y se resuelven automáticamente muchas relaciones (roles vs. actividades, roles vs. artefactos, etc.) que de otra manera habría que construir a mano.
No puedo menos que reomendarlo.
martes, 3 de marzo de 2009
¡Ya salió CMMI for Services!
El SEI acaba de publicar -increíblemente, antes de lo estimado- la nueva constelación de CMMI, llamada CMMI for Services o CMMI-SVC.
Claramente inspirado en ITIL y en IT-CMM, este nuevo trabajo busca cubrir el vacío dejado por CMMI-DEV en todo lo relacionado con el desarrollo de sistemas de servicio y su posterior gestión.
El reporte está disponible para su descarga en http://www.sei.cmu.edu/publications/documents/09.reports/09tr001.html.
Claramente inspirado en ITIL y en IT-CMM, este nuevo trabajo busca cubrir el vacío dejado por CMMI-DEV en todo lo relacionado con el desarrollo de sistemas de servicio y su posterior gestión.
El reporte está disponible para su descarga en http://www.sei.cmu.edu/publications/documents/09.reports/09tr001.html.
Suscribirse a:
Entradas (Atom)