Desarrollo de software magro

Por David J.Anderson.David J.Anderson es el autor de tres libros, Lessons en administración de Agile: En el Road a Kanban, que se publicó en 2012, Kanban: Cambio correcto de Evolutionary del negocio de Tecnología, [1] que se publicó en 2010, y, Administración de Agile para el software Engineering: Aplicando la teoría de las restricciones del negocio Resultados, [2] que se publicó en 2003.Era un miembro del equipo que creó el método de desarrollo del Software Agile, desarrollo basado en características, en Singapur entre 1997 y 1999.Se creó MSF for CMMI process Improvement, y se co-creó la nota técnica del software Engineering Institute, “CMMI y Agile: Porqué no abrazo ambos!” Éste es un fundador de sistemas Society de Lean (http://www.leansystemssociety.org).Es CEO de Magro - Kanban Universidad. Inc., un aprendizaje acreditado y la organización de las normas de calidad que proporciona el aprendizaje de Kanban en una red de socios en el mundo y de que realiza una formación para la administración y una empresa consultora internacionales, j de David.Anderson & Associates Inc.(http://www.agilemanagement.net) que ayuda a las empresas de tecnología a mejorar su rendimiento con mejores políticas de administración y toma de decisiones.

En noviembre de 2011, noviembre de 2012 actualizado.

Anderson describe el sistema Lean Software Development.

Se aplica a

Lean, desarrollo de software, administración de proyectos, Team Foundation Server

• Introduction

• Lean y Agile

• Lean más allá de Agile

• Definir Lean Software Development

• Valores

• Principios

• Procedimientos

El término Lean Software Development (desarrollo de software ajustado) se acuñó por primera vez como título de una conferencia organizada por la iniciativa ESPRIT de la Unión Europea, en Stuttgart, Alemania, en octubre de 1992.Independientemente, al año siguiente, Robert “Bob” Charette en 1993, planteó el concepto de “Lean Software Development” como parte de su trabajo para investigar mejores formas para administrar los riesgos en proyectos de software.El término “Lean” (ajustado) data de 1991, y fue sugerido por James Womack, Daniel Jones y Daniel Roos en su libro La máquina que cambió el mundo[3] como el término en inglés para describir el método de administración utilizado en Toyota.La idea que Lean podría aplicarse al desarrollo de software se estableció muy temprano, solo 1 o 2 años después de que el término se utilizara asociado a tendencias en procesos de fabricación y en ingeniería industrial.

En su segundo libro, publicado en 1995, Womack y Jones[4] definieron cinco pilares básicos del patrón de pensamiento Lean.Estos eran:

• Valor

• Flujo de valor

• Flujo

• Extracción

• Perfección

Esta sería la definición operativa predeterminada para la metodología Lean durante la mayor parte de la década siguiente.Se sugirió que la búsqueda de la perfección se consiguió eliminando residuos.Aunque había 5 pilares, fue el quinto, la búsqueda de la perfección a través de la identificación sistémica de actividades generadoras de residuos y su eliminación, la que resonó realmente en gran parte de la audiencia.Lean se asoció prácticamente de forma exclusiva a la práctica de eliminación de desechos desde finales de los años 90 hasta comienzos del siglo XXI.

La definición de Womack y de Jones para Lean no se admite universalmente.Los principios de administración en Toyota son mucho más sutiles.La palabra inglesa “waste” (residuos) se describe de una manera más precisa mediante tres términos en japonés:

• Muda: literalmente indica “desecho” pero implicando actividad sin valor añadido.

• Mura: indica “desigualdad” y se interpreta como “variabilidad de flujo”

• Muri: significado “sobrecarga” o “irracional”

La perfección se persigue a través de la reducción de la actividades sin valor añadido pero también a través de perfeccionar el flujo y eliminado la sobrecarga.Además, el enfoque de Toyota se basaba en un respecto fundacional por las personas que estaba muy influenciado por las enseñanzas de control de calidad del siglo XX y por expertos en control de procesos estadísticos como W.Edwards Deming, destacados representantes del ámbito de control de calidad del siglo XX.

Desgraciadamente, hay casi tantas definiciones de Lean como autores sobre el tema.

Lean y Agile

Invitaron a Bob Charette pero no pudo asistir a la reunión de 2001 en Snowbird, Utah, donde se creó el Manifiesto para el desarrollo del Software Agile[5].A pesar de faltar a esta reunión histórica, Lean Software Development fue considerado como uno de varios enfoques de Agile respecto al desarrollo de software.Jim Highsmith dedicó un capítulo de su libro de 2002[6] a una entrevista con Bob sobre el tema.Más adelante, Mary y Tom Poppendieck continuaron con una serie de 3[7,8,9] libros.Durante los primeros años del siglo XXI, los principios de Lean se usaron para explicar por qué los métodos del software Agile eran mejores.Según la metodología Lean los métodos de Agile contenían pocos “desechos” y por consiguiente generaron mejores resultados económicos.Los principios de Lean se usaron como un “otorgante de permisos” para adoptar los métodos de Agile.

Lean más allá de Agile

En años recientes, Lean Software Development ha emergido realmente como una disciplina única relacionada con el movimiento Agile, pero sin ser específicamente un subconjunto del mismo.Esta evolución se inició con la síntesis de las ideas de desarrollo de productos según la metodología Lean y el trabajo de Donald G.Reinertsen[10,11] y las ideas procedentes del mundo no ágil de ingeniería de sistemas a gran escala y de los escritos de James Sutton y Peter Middleton[12].También sinteticé el trabajo de Eli Goldratt y W.Edwards Deming desarrolló un enfoque sobre el flujo en lugar de una reducción de desechos[13].En instancias de Reinertsen hacia 2005, introduje el uso de los sistemas kanban que restringen el trabajo en curso y “extraen” nuevo trabajo solo cuando el sistema está listo para procesarlo.Alan Shalloway sumó sus pensamientos en el desarrollo de software Lean en su libro de 2009 sobre el tema[14].Desde 2007, la aparición de Lean como nueva fuerza en el progreso de la profesión de desarrollo de software se ha centrado en mejorar el flujo, la administración del riesgo y la toma de decisiones (de administración).Kanban se ha convertido en un habilitador para las iniciativas de Lean en trabajo relativo a TI.Parece que centrarse en el flujo, en lugar de en la eliminación de desechos, está probando ser mejor catalizador para la mejora continuada en actividades de trabajos del conocimiento, como el desarrollo de software.

Definir Lean Software Development

La definición de Lean Software Development es un reto porque no hay ningún método o proceso específico de Lean Software Development.Lean no es un equivalente de Personal Software Process, V-Model, Spiral Model, EVO, Feature-Driven Development, Extreme Programming, Scrum o Test-Driven Development.Un proceso del ciclo de vida de desarrollo de software o un proceso de administración de proyectos podría decirse que es "Lean" si se comprobado que cumple los valores del movimiento Lean Software Development y los principios del Lean Software Development.Los que anticipen una receta simple que se puede seguir y denominar Lean Software Development estarán decepcionados.Debe crear o ajustar su propio proceso de desarrollo de software comprendiendo los principios de Lean y adoptando los valores básicos de Lean.

Hay varias escuelas de pensamiento de Lean Software Development.El mayor, y discutible el espacio, la escolar es sistemas Society de Leer, que incluye Donald Reinertsen, Jim Sutton, Alan Shalloway, Bob Charette, Mary Poppendeick, y j de David.Anderson.El trabajo de Mary y de Tom Poppendieck desarrollado antes de la formación de Society y su credo se coloca por separado, como el trabajo de Craig Larman, de Bas Vodde [15,16], y, recientemente, de Jim Coplien [17].Búsquedas de este artículo de ser ampliamente representante del punto de vista de los sistemas Society de Eficientes como se expresa en su credo y proporcionar una síntesis y un resumen de las ideas.

Valores

Los sistemas Society de Lean publicados su credo [18] en el software 2012 de Lean y la [19] conferencia de sistemas.Esto se basaba en un conjunto de valores publican un año anterior.Esa los valores incluyen:

• Aceptar la condición humana

• Aceptar que la complejidad y la incertidumbre son naturales para el trabajo de conocimiento

• Trabaje con vistas hacia un mejor resultado económico

• Mientras se posibilita un mejor resultado de sociológico

• Buscar, adoptar y cuestionar ideas de una amplia gama de disciplinas

• Una comunidad basada en valores mejora la velocidad y la profundidad de cambios positivos

Aceptar la condición humana

El trabajo de conocimiento como el desarrollo de software lo realizan personas.Los seres humanos somos inherentemente complejos y, aunque somos pensadores lógicos, también nos dejamos llevar por nuestras emociones y algunos rasgos animales inherentes que no se pueden dominar tan fácilmente.Nuestra psicología y neuropsicología debe tenerse en cuenta cuando se diseñan los sistemas o procesos en los que trabajamos.El comportamiento social también debe incorporarse.Los seres humanos son por naturaleza emocionales, sociales y tribales, y nuestro comportamiento cambian con el cansancio y la tensión.Los procesos correctos serán los que adopten e implementen la condición humana, no los que tratan de denegarla y asumir un comportamiento lógico propio de máquinas.

Aceptar que la complejidad y la incertidumbre son naturales para el trabajo de conocimiento

El comportamiento de los clientes y los mercados es imprevisible.El flujo de trabajo a lo largo de un proceso y una colección de trabajadores es imprevisible.Los defectos y el trabajo por duplicado necesario son imprevisibles.El desarrollo de software conlleva riesgos o comportamientos aparentemente aleatorios en muchos niveles.El propósito, los objetivos y el ámbito de los proyectos suelen cambiar mientras se entregan.Parte de esta incertidumbre y variabilidad, aunque inicialmente desconocida, se puede conocer en el sentido de que se puede estudiar y cuantificar, así como administrar sus riesgos, pero cierta variabilidad es desconocida de antemano y no se puede anticipar de forma adecuada.Como resultado, los sistemas de Lean Software Development deben poder responder a los eventos unfold y el sistema debe poder adaptarse las circunstancias fluctuantes.Por consiguiente, cualquier proceso de Lean Software Development debe existir dentro de un marco que permite la adaptación (del proceso) para eventos unfold.

Trabaje con vistas hacia un mejor resultado económico

Las actividades humanas como Lean Software Development se deben centrar en generar un mejor resultado económico.El capitalismo es aceptable cuando contribuye al valor empresarial y beneficia al cliente.Los inversores y los propietarios de negocios merecen una mayor rentabilidad de la inversión.Los empleados y los trabajadores merecen una tarifa justa por su esfuerzo en la realización del trabajo.Los clientes merecen un buen producto o servicio que ofrezca las ventajas prometidas a cambio de un precio justo.Mejores resultados económicos implican una entrega de más valor al cliente, a menor precio, mientras que se administra el capital implementado por parte de los inversores o los propietarios de la manera más eficaz posible.

Habilitar un mejor resultado sociológico

No se deben obtener mejores resultados económicos a expensas de los que están realizando el trabajo.Es esencial crear un lugar de trabajo que respete a personas mediante la aceptación de la condición humana y que proporcione sistemas de trabajo que respeten la naturaleza psicológica y sociológica de las personas.Crear un buen sitio para hacer un gran trabajo es un valor básico para la comunidad de Lean Software Development

Principios

La comunidad Lean Software & Systems parece estar de acuerdo con algunos principios que respaldan los procesos de Lean Software Development.

• Siga Systems Thinking & Design Approach

• Los resultados emergentes pueden estar influenciados por la creación de la arquitectura del contexto para un sistema adaptable complejo

• Respetar a las personas (como parte del sistema)

• Utilice el modo científico (para controlar las mejoras)

• Fomentar el liderazgo

• Genere visibilidad (en los trabajos, flujos de trabajo y operación del sistema)

• Reducir el tiempo de flujo

• Reducir residuos para mejorar la eficacia

Siga Systems Thinking & Design Approach

Esto se conoce a menudo en la literatura de Lean como “optimizar el todo”, lo que implica que es el resultado de todo el sistema (o el proceso) lo que se desea optimizar, y no se deben optimizar partes con la esperanza equivocada de que esto optimizará el conjunto mágicamente.La mayoría de los usuarios creen que la consecuencia es así, que la optimización de elementos (optimización local) dará lugar a un resultado que no será óptimo.

Lean Systems Thinking and Design Approach requiere tener en cuenta las peticiones en el sistema realizadas por las partes interesadas externas, como clientes, y el resultado deseado requerido por tales partes interesadas.Debemos estudiar la naturaleza de la demanda y compararla con la capacidad de entrega de nuestro sistema.La petición incluirá la denominada “petición de valor”, por la que los clientes están dispuestos a pagar, y la “petición de errores”, que normalmente implica una revisión o una petición adicional a causa de un error en el suministro de la de petición de valor.Las peticiones erróneas tiene dos formas por lo general: revisión del trabajo respecto a una petición de valor previamente satisfecha y servicios adicionales o soporte debido a un error a la hora de entregar la petición de valor.En el desarrollo de software, la demanda de error suele solicitar una corrección de errores así como una función de atención al cliente o de soporte técnico.

Un enfoque de diseño de sistemas requiere que también sigamos el enfoque de planear, hacer, estudiar, actuar (Plan-Do-Study-Act, PDSA) para procesar el diseño y las mejoras.HoraEdwards Deming usó las palabras “estudiar” y “capacidad” para indicar que estudiamos la filosofía natural del comportamiento del sistema.Este sistema se compone de nuestro proceso de desarrollo de software y de todas las personas involucradas en él.Tendrá un comportamiento visible en términos de plazos de entrega, calidad, cantidad de las características o funciones entregadas (lo cual se denominado en la literatura de Agile “velocidad "), etc.Estas métricas mostrarán variabilidad y, estudiando la media y la dispersión de las variaciones, podemos entender mejor nuestra capacidad.Si no se corresponden correctamente con la demanda y las expectativas del cliente, el sistema necesitará ser rediseñado para cerrar la brecha.

Deming también nos enseñó que la capacidad está influenciada en un 95% por el diseño del sistema y solo el 5% está condicionado por el rendimiento de las personas.Es decir, podemos respetar a personas no culpándolas por un desequilibrio entre capacidad y la demanda y rediseñando el sistema para permitirles hacer bien las cosas.

Para entender diseño de sistemas, debemos tener conocimientos científicos de la dinámica de la capacidad del sistema y cómo puede verse afectada.Los modelos se desarrollan para predecir la dinámica del sistema.Cuando hay muchos modelos posibles, se suelen usar los más populares: la comprensión de costos económicos; los denominados costos de transacción y de coordinación relacionados con la producción de productos o servicios valorados por el cliente; la teoría de las restricciones (la comprensión de los cuellos de botella); y la teoría del conocimiento profundo (el estudio y el reconocimiento de si las variaciones son propias del diseño del sistema, o especiales y externas al diseño del sistema).

Los resultados emergentes pueden estar influenciados por la creación de la arquitectura del contexto para un sistema adaptable complejo

Los sistemas complejos tienen condiciones de inicio y reglas simples que, cuando se ejecutan en iteración, generan un resultado emergente.Los resultados emergentes son difíciles o imposibles de predecir, dadas las condiciones de inicio.El experimento informático “The Game of Life” es un ejemplo de un sistema complejo.Un sistema adaptable complejo incluye cierta conciencia y un método interno de reflexión que le permita tener en cuenta en qué medida su conjunto de reglas actual le permite lograr los resultados deseados.El sistema adaptable complejo podrá entonces optar por adaptarse él mismo (para cambiar sus reglas simples) para cerrar el hueco entre el resultado actual y el resultado deseado.El juego de la vida adaptado de modo que las reglas se puedan volver a escribir durante el juego sería un sistema adaptable complejo.

En los procesos de desarrollo de software, las “reglas sencillas” de sistemas adaptables complejos son las directivas que constituyen la definición de proceso.El principio básico aquí se basa en la creencia de que desarrollar productos y servicios de software no es una actividad determinista, y por consiguiente un proceso definido que no puede adaptarse a sí mismo no será una respuesta adecuada a eventos imprevistos.Por consiguiente, el proceso diseñado como parte de nuestro patrón de pensamiento y enfoque del diseño debe ser personalizable.Se adapta a través de la modificación de las directivas de las que se compone.

El enfoque de Kanban a Lean Software Development utiliza este concepto tratando las directivas del sistema de extracción kanban como “las reglas sencillas”, y las condiciones iniciales son que el trabajo y el flujo de trabajo se visualizan, el flujo se administra mediante la comprensión del la dinámica del sistema y la organización utiliza un enfoque científico para comprender, proponer e implementar mejoras de procesos.

Respetar a las personas

La comunidad Lean adopta la definición de Peter Drucker de trabajo de conocimiento que afirma que los trabajadores son trabajadores de conocimiento si están más informados sobre el trabajo que realizan que sus jefes.Esto crea la implicación de que los trabajadores están en una posición mejor para tomar decisiones sobre cómo realizar el trabajo y cómo modificar los procesos para mejorar los métodos de trabajo.Por lo que la voz del trabajador debe ser respetada.Los trabajadores deben estar facultados para organizarse por su cuenta para completar el trabajo y lograr los resultados deseados.También deben tener autorización para sugerir e implementar oportunidades de mejora de procesos o “eventos de kaizen”, como se conocen en la literatura Lean.Crear directivas de proceso explícitas de modo que los trabajadores sean conscientes de reglas que restringen su actividad es una forma de respetarles.Las reglas bien definidas fomentan una organización autónoma ya que eliminan el miedo y la necesidad de tener valor.Respetar a las personas dándoles autoridad y ofreciéndolas un conjunto de directivas declaradas explícitamente permite ser fiel al valor básico de respeto a la condición humana.

Use el método científico

Utilice modelos para entender la dinámica de cómo se realiza el trabajo y de cómo funciona el sistema Lean Software Development.Observe y estudie el sistema y su capacidad y, a continuación, desarrolle y aplique los modelos para predecir su comportamiento.Recopile datos cuantitativos en las revisiones y use esos datos para entender cómo rinde el sistema y predecir cómo puede cambiar cuando cambia el proceso.

La comunidad Lean Software & Systems utiliza métodos estadísticos, como gráficos de control de proceso estadístico e histogramas de análisis espectral de datos sin formato para conseguir tiempo y velocidad para comprender la capacidad del sistema.También utilizan modelos como: la teoría de las restricciones para entender los cuellos de botella; el sistema de conocimiento profundo para entender la variación inherente al diseño del sistema frente a la que procede de influencias externas; y un análisis de costos económicos para las tareas meramente de coordinación, configuración, entrega o limpieza posteriores a la creación de productos o servicios valorados por el cliente.Otros modelos se están empezando a utilizar, como la teoría de la opción de real, que intenta aplicar teoría de la opción financiera de la administración de riesgos financieros a la toma de decisiones del mundo real.

El método científico sugiere: estudiamos; postulamos un resultado en función de un modelo; perturbamos el sistema basándonos en esa predicción; y observamos de nuevo para ver si la perturbación produjo los resultados que el modelo predijo.De no ser así, comprobamos los datos y reconsideramos si nuestro modelo es exacto.El uso de modelos para controlar las mejoras de procesos lo convierte en una actividad científica, dejando de ser una actividad supersticiosa basada en la intuición.

Fomentar el liderazgo

La dirección y administración no son iguales.Administración es la actividad de diseñar procesos, crear, modificar y eliminar directivas, de tomar decisiones estratégicas y operativas, de recopilar recursos, de proporcionar financiación e instalaciones y de comunicar información sobre contexto como estrategia, objetivos y resultados deseados.La dirección tiene que ver con la visión, la estrategia, la táctica, el valor, la innovación, la valoración, la propugnación y muchos otros atributos.La dirección puede y debe proceder de cualquier persona dentro de una organización.Pequeños actos de liderazgo de los trabajadores crearán una cascada de mejoras que posibilitarán los cambios necesarios para crear un proceso de Lean Software Development.

Genere visibilidad

El trabajo de conocimiento no es visible.Si no puede ver algo, es (casi) imposible administrarlo.Es necesario generar visibilidad en el trabajo que se emprende y en el flujo de ese trabajo a través de una red de personas, conocimientos y departamento hasta que se complete.Es necesario crear visibilidad en el diseño del proceso encontrando maneras de visualizar el flujo del proceso y creando directivas del proceso explícitas para que todo el mundo las vea y las tenga en cuenta.Cuando todas estas cosas estén visibles, el uso del método científico es posible, y las conversaciones sobre posibles mejoras podrán ser colaborativas y objetivas.La mejora del proceso de colaboración es casi imposible si el trabajo y el flujo de trabajo no están visibles y si las directivas de proceso no son explícitas.

Reducir el tiempo de flujo

Los profesionales del desarrollo de software y el personal académico que estudia ingeniería de software tradicionalmente se han centrado en medir el tiempo empleado en trabajar en una actividad.La comunidad de Lean Software Development ha descubierto que podría ser más útil medir el tiempo transcurrido real que algo tarda en procesarse.Esto se conoce normalmente como duración del ciclo y normalmente se califica mediante los límites de las actividades realizadas.Por ejemplo, la duración del ciclo hasta llegar a Listo para la implementación mediría el tiempo total transcurrido para un elemento de trabajo, como un caso de usuario, que debe analizarse, diseñarse, desarrollarse, probarse en varios sentidos, y colocarse en cola listo para su implementación en un entorno de producción.

El centrarse en el tiempo que se necesita para recorrer el proceso es importante de varias maneras.Se han mostrado duraciones de ciclo más largas que se correlacionan con un crecimiento no lineal en el porcentaje de errores.Por consiguiente, los tiempos del ciclo llevan a una mayor calidad.Esto es contraintuitivo, ya que parece ridículo que los errores se puedan insertar en el código mientras está esperando en la cola y realmente no lo está tocando nadie.Tradicionalmente, la profesión de ingeniería del software y los académicos que la han estudiado han omitido este tiempo de inactividad.Sin embargo, las pruebas empírica sugieren que la duración de ciclo es importante para la calidad inicial.

Alan Shalloway también habla sobre el concepto de “trabajo inducido”. Su observación es que un retraso en realizar una tarea puede conducir a que esa tarea que requiera muchos más esfuerzos de los necesarios.Por ejemplo, encontrar y corregir inmediatamente un error puede llevar tan solo 20 minutos, pero si ese error se evalúa, se pone en la cola y después se esperan varios días o semanas a que se solucione, podría llevar muchas horas su corrección.Por consiguiente, el retraso en el tiempo del ciclo tiene trabajo adicional “inducido”.Como este trabajo es evitable, en términos de Lean, debe considerarse como un “desperdicio”.

La tercera razón para centrarse en la duración del ciclo es una razón relacionada con el negocio.Cada característica, función o caso de usuario tiene un valor.Ese valor puede ser incierto pero, sin embargo, hay un valor.El valor puede variar con el tiempo.El concepto de valor variable con el tiempo se puede expresar económicamente como una función de rentabilidad de mercado.Cuando se comprende la función de rentabilidad de mercado para un elemento de trabajo, aunque la función presente una variedad de valores para modelar la incertidumbre, es posible evaluar un “costo de retraso”. El costo de retraso permite poner un valor en la reducción del tiempo del ciclo.

Con algunos elementos de trabajo, la función de rentabilidad de mercado no se inicia hasta una fecha futura conocida.Por ejemplo, una característica diseñada para utilizarse durante el día festivo del 4 de julio en los Estados Unidos de América no tiene valor antes de esa fecha.Acortar el tiempo de ciclo y poder predecir su duración con cierta confiabilidad sigue siendo útil en este ejemplo.En el mejor de los casos, queremos empezar con el trabajo para entregar la característica “en el plazo exacto” cuando sea necesaria y no significativamente antes de la fecha deseada, ni tarde, ya que una entrega fuera del plazo conlleva costos por retraso.La entrega a su debido tiempo garantiza que el uso óptimo se creó con recursos disponibles.Una entrega antes de tiempo implica que puede que hayamos trabajado en algo más y, implícitamente, haber incurrido en un costo de oportunidad por aplazamiento.

Como resultado de estas tres razones, Lean Software Development busca minimizar el tiempo de flujo y grabar los datos que permitan realizar predicciones sobre el tiempo de flujo.El objetivo es minimizar la demanda por errores debida a errores, los residuos de la sobrecarga debida al retraso en la solución de errores y maximizar el valor evitando los costos por retraso y los costos de oportunidad por aplazamiento.

Reducir residuos para mejorar la eficacia

Para cada actividad que agregue valor, hay actividades de configuración, de limpieza y de entrega que son necesarias pero no agregan valor por sí mismas.Por ejemplo, una iteración del proyecto que desarrolla un incremento de software que funciona requiere un planeamiento (una actividad de configuración), un entorno y quizás una bifurcación de código en el control de versiones (conocido en su conjunto como administración de configuración y también como actividad de configuración), un plan de lanzamiento y realizar el lanzamiento en sí (una actividad de entrega), una demostración al cliente (una actividad de entrega) y posiblemente destruir o reconfigurar el entorno (una actividad de limpieza.) En términos económicos, las actividades de configuración, limpieza y entrega son costos de transacción para llevar a cabo el trabajo de valor añadido.Estos costos (o gastos generales) se consideran residuos en la metodología Lean.

Cualquier forma de sobrecarga de comunicación puede considerarse un desperdicio.Las reuniones para determinar el estado del proyecto y para programar o asignar trabajo a miembros del equipo se considerará un costo de coordinación en terminología económica.Todos los costos de coordinación son irrelevantes en esta percepción de Lean.Los métodos de Lean Software Development pretenden eliminar o reducir los costos de coordinación con la colocación de miembros del equipo, reuniones cara a cara de poca duración como reuniones sin sentarse y controles visuales como los muros de cartas.

El tercer tipo común de residuos del Lean Software Development es la demanda por errores.Las peticiones erróneas son una carga para sistema de desarrollo de software.Las peticiones de erróneas suelen conllevar un trabajo de revisión u otras formas de trabajo como efecto secundario de una baja calidad.Las formas más habituales de demanda por errores en el desarrollo de software son los errores, los defectos de producción y las actividades de soporte al cliente derivadas de un uso incorrecto del software.El porcentaje de trabajo en curso que es demanda por errores suele denominarse carga por errores.El porcentaje de trabajo de valor añadido frente a la demanda por errores es una medida de la eficacia del sistema.

El porcentaje de trabajo de valor añadido frente al trabajo total, incluidos todos los costos de coordinación y transacción que no añaden valor, determina el nivel de eficacia.Un sistema sin costes de transacción y de coordinación y las cargas erróneas no se considerarán eficaces al 100%.

Tradicionalmente, las ciencias empresariales occidentales han enseñado que la eficacia se puede mejorar aumentando el tamaño de lote de trabajo.Normalmente, los costos de transacción y coordinación son fijos o suben ligeramente con un aumento del tamaño de lote.Como resultado, los lotes grandes de trabajo son más eficaces.Este concepto se conoce como “economía de escala”. Sin embargo, con los problemas relacionados con los trabajos de conocimiento, los costos de coordinación tienden a subir de forma no lineal con el tamaño del lote, mientras que los costos de transacción puede presentar a menudo un crecimiento lineal.Como resultado, el enfoque tradicional del siglo XX relativo a la eficacia no es adecuado para los problemas de trabajo sobre los conocimientos el desarrollo de software.

Es mejor centrarse en la reducción de las sobrecargas conservando un tamaño pequeño de tamaño de lote para mejorar la eficacia.Por consiguiente, la forma según Lean de ser eficaz es reducir los desechos.Los métodos de Lean Software Development se centran en métodos rápidos, baratos y de planeación rápida; sobrecarga baja de comunicación; y mecanismos de coordinación de sobrecargas bajas efectivos, como controles visuales en sistemas kanban.También promueven la automatización de las pruebas y de la implementación para reducir los costos de transacción de las entregas.Las herramientas modernas para minimizar los costos de configuración y de destrucción de entorno, como sistemas de control de versiones modernos y uso de la virtualización, también ayudan a mejorar la eficacia de pequeños lotes de desarrollo de software.

Procedimientos

Lean Software Development no recomienda procedimientos.Es más importante mostrar que las definiciones de proceso reales están en concordancia con los principios y valores.Sin embargo, varios procedimientos se están adoptando normalmente.Esta sección proporciona información general breve sobre algunas de ellas.

Diagramas de flujo acumulativos

Los diagramas de flujo acumulativos llevan siendo una parte estándar de la elaboración de informes en Team Foundation Server desde 2005.Los diagramas de flujo acumulativos trazan un gráfico de área de los elementos de trabajo acumulativos en cada estado de un flujo de trabajo.Contienen una gran cantidad de información y pueden utilizarse para derivar la duración de ciclo media entre los pasos de un proceso, así como la tasa de rendimiento (o “velocidad”).Diversos procesos del ciclo de vida de desarrollo de software generan diferentes signaturas visuales en diagramas de flujo acumulativos.Los usuarios pueden reconocer los patrones del mal funcionamiento en el proceso que se muestra en el gráfico de áreas.Un proceso verdaderamente Lean mostrará true áreas uniformemente distribuidas de color, incrementándose naturalmente a un ritmo constante.La imagen aparecerá suavizada sin pasos escalonados o bloques visibles de color.

En su forma más básica, los diagramas de flujo acumulativos se usan para visualizar la cantidad de trabajo en curso en un momento determinado en el ciclo de vida del elemento de trabajo.Esto se puede utilizar para detectar cuellos de botella y para observar los efectos de “mura” (variabilidad de flujo).

Controles visuales

Además de usar diagramas de flujo acumulativos, los equipos de Lean Software Development usan las placas físicas, o proyecciones de sistemas electrónicos de visualización, para visualizar el trabajo y observar el flujo.Estas visualizaciones ayudan a los miembros del equipo a observar la acumulación de trabajo en curso y les permite ver los cuellos de botella y los efectos de “mura”. Los controles visuales también permiten a los miembros del equipo organizarse entre ellos para elegir el trabajo y colaborar juntos sin una planeación o una dirección o intervención específica de administración.Estos controles visuales se denominan a menudo “muros de cartas” o a veces (incorrectamente) “paneles kanban”.

Sistemas Kanban virtuales

Un sistema kanban es una práctica adoptada de la fabricación Lean.Usa un sistema de cartas físicas para limitar la cantidad de trabajo en curso en cualquier fase determinada en el flujo de trabajo.Tales sistemas limitados de trabajo en curso crean una “extracción” donde se inicia el nuevo trabajo solo cuando hay kanban libres que indiquen que dicho trabajo se puede “extraer” en un estado determinado y el trabajo puede progresar en él.

En Lean Software Development, el kanban es virtual y su seguimiento se realiza normalmente estableciendo un número máximo para un paso determinado en el flujo de trabajo de un tipo de elemento de trabajo.En algunas implementaciones, los sistemas electrónicos llevan un seguimiento del kanban virtual y proporcionan una señal cuando el trabajo se puede iniciar.La señal puede ser visual o en forma de alerta, como un correo electrónico.

Los sistemas kanban virtuales se combinan con los controles visuales para proporcionar un sistema kanban virtual visual que representa el flujo de trabajo de uno o varios tipos de elemento de trabajo.Tales sistemas se denominan a menudo “paneles kanban” o “sistemas kanban electrónicos”. Un sistema kanban virtual visual, denominado Visual WIP[20], está disponible como complemento para Team Foundation Server,.Este proyecto lo desarrolló Hakan Forss en Suecia como código abierto.

Tamaños pequeños de lote/flujo de parte única

Lean Software Development requiere que el trabajo se realice en pequeños lotes, lo que a menudo se llama “iteraciones” o “incrementos” o los elementos de trabajo fluyan de forma independiente, lo que se denomina “flujo de la parte única”. El flujo de la parte única requiere una estrategia de administración de la configuración sofisticada del trabajo completado que va a entregarse mientras que el trabajo no terminado no se lanza accidentalmente.Esto normalmente se logra utilizando estrategias de bifurcación en el sistema de control de versiones.Un lote de trabajo pequeño normalmente se considera un lote que puede asumir un equipo pequeño de 8 personas o menos en 2 semanas.

Los lotes pequeños y el flujo de parte única requieren interacción frecuente con los propietarios del negocio para reponer el trabajo pendiente, la cola o el trabajo.También requieren cierta capacidad de lanzar versiones con frecuencia.Para permitir la interacción frecuente con los propietarios del negocio y las entregas frecuentes, es necesario reducir los costos de transacción y de coordinación de ambas actividades.Una manera común de conseguirlo es usar la automatización.

Automatización

Lean Software Development espera un nivel alto de automatización para habilitar de forma económica el flujo de la parte única y fomentar la alta calidad y reducir la demanda errónea.El uso de la prueba automatizada, la implementación automatizada y los generadores de software para automatizar la implementación de los modelos de diseño y la creación de secciones repetitivas de poca variabilidad de código fuente serán habituales en los procesos Lean Software Development.

Eventos de Kaizen

En la literatura de Lean, el término kaizen quiere decir “mejora continua” y un evento de kaizen es el acto de crear un cambio en un proceso o herramienta que se supone que desembocará en una mejora.

Los procesos de Lean Software Development usan diversas actividades para generar eventos kaizen.Se enumeran aquí.Cada una de estas actividades se ha diseñado para estimular una conversación sobre los problemas que afectan negativamente a la capacidad y, por consiguiente, a la capacidad cumplir los requisitos de la demanda.La esencia de kaizen en el trabajo de conocimiento es que debemos provocar conversaciones sobre problemas entre grupos de usuarios de equipos diferentes y con distintos conocimientos.

Reuniones informales diarias

Los equipos de desarrolladores de software, a menudo formados por hasta 50 personas, se agruparán normalmente delante de un sistema de control visual como una pizarra que muestra una visualización del trabajo en curso.Discuten la dinámica del flujo y los factores que afectan al flujo de trabajo.Se presta especial atención al trabajo externamente bloqueado y al trabajo con retrasos a causa de errores.Los problemas con el proceso por lo general se hacen evidentes tras varias reuniones informales.El resultado es que un grupo más pequeño puede quedarse tras la reunión para analizar el problema y proponer una solución o un cambio en los procesos.Luego se producirá un evento de kaizen.Estas reuniones espontáneas a menudo se conocen como círculos de calidad espontáneos en la literatura más antigua.Este tipo de reuniones espontáneas son el corazón de una cultura realmente de kaizen.Los administradores fomentarán la aparición de eventos kaizen después de reuniones informales diarias para controlar la adopción de Lean en la organización.

Retrospectivas

Los equipos de proyecto pueden programar reuniones regulares para reflejar el rendimiento reciente.Estas suelen tener lugar después de completar determinadas entregas del proyecto o después de los incrementos de tiempo de desarrollo denominados iteraciones o sprints en Agile Software Development.

Las retrospectivas utilizan normalmente un enfoque anecdótico para la reflexión haciendo preguntas como “¿qué salió bien?", “¿qué haríamos de forma diferente?” y “¿qué debemos dejar de hacer?”

Las retrospectivas normalmente generan un trabajo pendiente de sugerencias para eventos de kaizen.El equipo puede dar prioridad a algunas de ellas para la implementación.

Revisiones de operaciones

Una revisión de las operaciones normalmente es mayor que una retrospectiva e incluye representantes de una secuencia completa de valores.Es común que hasta 12 departamentos presenten datos objetivos y cuantitativos que muestren la demanda obtenida y que reflejen su capacidad de satisfacer esta demanda.Las revisiones de operaciones por lo general se efectúan mensualmente.Las diferencias clave entre una revisión de operaciones y una retrospectiva es que las revisiones de operaciones abarcan un conjunto más amplio de funciones, generalmente una cartera de proyectos y otras iniciativas, y utilizan datos objetivos y cuantitativos.Las retrospectivas, por el contrario, suelen restringirse a un proyecto único; implican a pocos equipos, por ejemplo análisis, desarrollo y prueba; y son, por lo general, de naturaleza anecdótica.

Una revisión de las operaciones provocará debates sobre la dinámica que afecta al rendimiento entre equipos.Quizás un equipo genera una petición errónea que procesa otro equipo.Quizás esa demanda errónea es molesta y provoca que un segundo equipo no cumpla sus compromisos y no entregue según las expectativas.Una revisión de las operaciones proporciona una oportunidad de explicar tales problemas y de proponer cambios.Las revisiones de operaciones por lo general generan un pequeño trabajo pendiente de eventos kaizen potenciales que a los que se pueden asignar prioridades y programar para la implementación posterior.

No existe un único proceso de Lean Software Development.Se puede decir que un proceso es Lean si se corresponden claramente con los valores y los principios de Lean Software Development.Lean Software Development no recomienda ningún procedimiento, pero algunas actividades se han convertido en habituales.Las organizaciones que trabajan con Lean tratan de fomentar el kaizen a través de la visualización del flujo de trabajo y de los trabajos en curso y a través de una comprensión de la dinámica de flujo y de factores (como cuellos de botella, disponibilidad no inmediata y desechos) que le afectan.Las mejoras en el proceso se sugieren y se justifican como una forma de reducir las fuentes de variabilidad, eliminar desechos, mejorar los flujos o mejorar la entrega de valor o la administración de riesgos.Como tal, los procesos de Lean Software Development evolucionarán siempre y estarán individualizados de forma única para la organización dentro en la que se desarrollan.No se puede copiar una definición de proceso desde una organización a otra y pretender que funcione en un contexto diferente.También es improbable que si se regresa a una organización después de unas semanas o meses, el proceso en uso sea igual al anteriormente observado.Evolucionará siempre.

Una organización que utilice un proceso de desarrollo de Lean se puede decir que es Lean si solo exhibió cantidades pequeñas de residuos en sus tres formas (“mura”, “muri” y “muda") y se puede demostrar que optimiza la entrega de valor mediante una administración efectiva del riesgo.La búsqueda de la perfección en Lean siempre es un viaje.No hay ningún destino.Las organizaciones que trabajan con Lean buscan siempre mejoras adicionales.

Lean Software Development sigue siendo un campo emergente y se puede esperar que continúe evolucionando durante la década próxima.

1. Anderson, David J., Kanban: Successful Evolutionary Change for your Technology Business, Blue Hole Press, 2010

2. Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

3. Womack, James P., Daniel T.Jones and Daniel Roos, The Machine That Changed the World: The Story of Lean Production, 2007 updated edition, Free Press, 2007

4. Womack, James P. y Daniel T.Jones, Lean Thinking: Banish Waste and Create Wealth in your Corporation, 2nd Edition, Free Press, 2003

5. Beck, Kent et al, The Manifesto for Agile Software Development, 2001 http://www.agilemanifesto.org/

6. Highsmith, James A., Agile Software Development Ecosystems, Addison Wesley, 2002

7. Poppendieck, Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesely, 2003

8. Poppendieck, Mary and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2006

9. Poppendieck, Mary and Tom Poppendieck, Leading Lean Software Development: Results are not the Point, Addison Wesley, 2009

10. Reinertsen, Donald G., Managing the Design Factory, Free Press, 1997

11. Reinertsen, Donald G., The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009

12. Sutton, James y Peter Middleton, Lean Software Strategies: Proven Techniques for Managers and Developers, Productivity Press, 2005

13. Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

14. Shalloway, Alan, Guy Beaver y James R.Trott, Lean-Agile Software Development: Achieving Enterprise Agility, Addison Wesley, 2009

15. Larman, Craig and Bas Vodde, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum, Addison Wesley Professional, 2008

16. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison Wesley Professional, 2010

17. Coplien, James O.y Gertrud Bjornvig, Lean Architecture: for Agile Software Development, Wiley, 2010

18. http://leansystemssociety.org/credo/

19. http://lssc12.leanssc.org/

20. http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/