Desarrollo de Software Esbelto: Se puede?

Monterrey Business Unit Manager ItEra

Ernesto Elizalde

Objetivo

Abordar de manera pragmtica cmo los principios de la Manufactura Esbelta pueden ser trasladados al Desarrollo de Software

2

Agenda Historia de la Manufactura Esbelta (Lean Manufacturing) y el Pensamiento Esbelto (Lean Thinking). 7 Principios y Herramientas Do It Yourself Conclusiones Preguntas y Respuestas

3

Lean Thinking y Lean Development Toyota revoluciona en los 80s la industria automotriz con su enfoque Lean Manufacturing que promova: eliminar el desperdicio resaltar la cadena de valor producir bajo demanda (justo a tiempo) y enfocarse en la gente que agrega valor

El Pensamiento Esbelto: capitaliza la inteligencia de los trabajadores que estn en la lnea de produccin tiene la conviccin de que son ellos quienes determinan y mejoran continuamente la manera de ejecutar su trabajo.

Mary y Tom Poppendieck han logrado transferir los principios de la industria de la manufactura al desarrollo de software. www.poppendieck.com

Desarrollo de Software Esbelto Lean es una metodologa genrica que mejora la calidad y productividad en industrias de manufactura o logstica. Lean Software Development (DSE en espaol) es una variacin que toma principios Lean para aplicarlos en la produccin de software. Se basa en la identificacin y eliminacin de cualquier fuente que genere "desperdicios", para que los objetivos globales se cumplan exitosamente, estimulando la productividad. El entendimiento de sta filosofa puede ser el paso previo al uso de tcnicas de las llamadas giles.

En una Era donde ser esbelto es lo in, podemos poner a dieta nuestros procesos de desarrollo de software?

7 Principios (Tips) para adelgazar Eliminate Waste (Eliminar el Gasto) Amplify Learning (Amplificar el Aprendizaje) Decide as Late as Possible (Decidir lo ms Tarde posible) Deliver as Fast as Possible (Entregar lo ms Rpido posible) Empower the Team (Facultar al Equipo) Build Integrity In (Construir Integridad) See the Whole (Ver el Todo)

Tip #1: Eliminar los desperdicios No significa tirar toda la documentacin. Significa invertir el tiempo solo en aquello que agregue valor real. Es el principio fundamental y del cual dependen el resto de los principios. El primer paso para implementar DSE es aprender a ver los desperdicios, identificar las fuentes y eliminarlas.

Tipos de Desperdicios 1/2 Funcionalidad desarrollada y no utilizada.Esto genera cdigo extra, el cual tuvo que seguirse, compilarse y testearse, el mismo incrementa la complejidad y es un posible punto de fallo. sea solo la necesaria ya que consume recursos, demoras, se pierde y se vuelve obsoleta.

La documentacin

Asignar una persona a mltiples proyectos.Cada vez que el desarrollador de software tiene que cambiar entre tareas, pierde un tiempo significativo para retomar la funcionalidad en la que estaba trabajando. Pertenecer a diferentes equipos de trabajo causa ms interrupciones que beneficios.

Tipos de Desperdicios 2/2 Esperas. Uno de los grandes desperdicios, en cuanto atiempo, es esperar a que sucedan cosas: se espera al comienzo del proyecto, en la definicin de requerimientos, en el armado de excesiva documentacin, en la codificacin, en revisin y aprobacin, en testeo, etc.

Movimiento, cuando un desarrollador tiene una pregunta,cuanto cuesta encontrar la respuesta? Los requerimientos van a los analistas, de los analistas a los diseadores, de aqu a los desarrolladores y luego al testeo en cada pasaje es probable que se pierda algo, ya que un porcentaje de conocimiento tcito queda con el creador del documento y no se transmite.

Errores en el Software, el porcentaje de desperdicio

causado por un error se puede medir como el impacto del mismo por el tiempo sin ser detectado. Hay que encontrarlos en cuanto ocurran, corregirlos, probarlos y actualizar la versin en produccin.

Do It YourSelf: Descubre DesperdiciosMapa de la Cadena de Valor del proceso de Desarrollo de Software. Con papel y lpiz sigue tu proceso de desarrollo de software desde la perspectiva de un Cliente. No preguntes lo que se hace, vvelo, busca los datos, obsrvalo por ti mismo. Anota el tiempo promedio que el equipo invierte en cada actividad. Abajo del mapa, dibuja una lnea de tiempo en la que separes el tiempo de Valor y el tiempo de Espera. Revisa las actividades con mayor tiempo de espera e identifica las fuentes del retraso o esperas y define cmo bajar ese tiempo.

Mapa Cadena de ValorRecibir Solicitudes 2 hrs Aprobar Proyecto 4 hr Anlisis de Requerimientos 6 wks Firma del Anlisis de Cliente CU < 1hr 1 wk Diagramas de Clases 3 wks Modelos de Revisin Diseo Diseo 1 wkCdigo Cdigo

Diseo Casos Prueba 2 wks

Automatizacion Casos Prueba 2 wks

Distribucin 2 wks

4 hrs 1 wk

1 wk

Tiempo de Valor Tiempo de Espera2 wks 1 wk

Cadena Valor = 34 wks Tiempo Valor 19 wks 56% 8.5 months Tiempo Espera 15 wks 44%2 wks 56% 44%Seleccionar 1er Segmento Evaluar ProblemasDisear, codificar y probar

1 wk

1 wk

1 wk

1 wk 1 wk

1 wk

2 wks

1 wk

1 wk

Cadena Valor = 34 wks Tiempo Valor 19 wks 8.5 months Tiempo Espera 15 wksRecibir SolicitudesAprobar Proyecto

Arquitectura Preliminar

Seleccionar 2do Segmento Evaluar ProblemasDisear, codificar y probar

Seleccionar 3er Segmento Evaluar ProblemasDisear, codificar y probar

2 hr 4 hr

Tiempo de Valor Tiempo de Espera

Cadena Valor=2 day 1 wk

2 wks

20 wks 5 months1 wk

Revisar con Cliente Distribuir (Opcional)

5 wks

Tiempo de Valor = 17 wks5 wks

Revisar con Cliente Distribuir (Opcional)

Revisar con Cliente Distribuir (Opcional)

85% 15%

5 wks

Tiempo de Espera =1 day 17 wks 3 wks 85% 15%

3 wks1 day

Cadena Valor=

20 wks 5 months

Tiempo de Valor = Tiempo de Espera =

Tip #2: Amplificar el Aprendizaje Incrementar el feedback con el usuario, parapoder determinar con la mayor exactitud posible lo que desea y resolver los problemas complicados que se presenten.

La funcionalidad que se desarrolle ser exactamente lo que el usuario desea y la utilizar (eliminando una fuente de desperdicio). Incrementar el feedback dentro del equipo de trabajo, lograr que todos los involucrados conozcan el problema y participen en la resolucin. Ejecutar pruebas peridicas para detectar rpidamente cundo un proceso no funciona. Esto permite aprender mediante la experimentacin.

Iteraciones y Sincronizacin Un punto de partida universal son las iteraciones: puntos de sincronizacin donde los Clientes y el equipo ven lo que se ha alcanzado. Cuando varios individuos estn trabajando en la misma actividad, existe la necesidad de sincronizar, lo cual es fundamental. Integrar diariamente dentro del equipo (check-in al menos 1 vez por da en un repositorio local). Integrar semanalmente a travs de varios equipos (check-in al menos 1 vez por semana en un repositorio central)

Hacer builds frecuentemente (proveen mucho ms feedback). La construccin de builds y las pruebas a stos deberan de automatizarse lo ms posible.

Do It YourSelf: Incrementa Feedback Al final de cada iteracin mantn una reunin con todo el equipo y pregunta: Cmo sucedieron las cosas en sta iteracin ? Qu puede hacerse mejor ? Qu cambiamos para avanzar mejor y ms rpido ?

Y con el Cliente: Se cubrieron las expectativas ? Qu se requiere para llevar sta parte del producto a produccin ? Qu puede ser mejorado ?

Involucra al equipo de operaciones al principio del proyecto. Establece la poltica en la que el equipo de Desarrollo es responsable de mantener el producto.

Tip #3: Decidir lo ms tarde Posible La idea es esperar hasta el momento en que se encuentre disponible la mejor y mayor informacin. La idea no es aplazar la toma de decisiones, sino poder tomar una decisin en el momento de mayor certeza, as la misma estar basada en conocimiento concreto, no en especulacin. Por ejemplo, antes de desarrollar una funcionalidad de diferentes formas, es mejor comunicarlas y decidir junto al usuario.

Identificar el Ultimo Momento Responsable, el cual es el momento en el cual se elimina una alternativa importante si no se toma una decisin.

Cuidado con las decisiones prematuras Comprometer diseos detallados prematuros restringe el aprendizaje, predispone el impacto de los defectos e incrementa el costo del cambio. Crear planes detallados tempranamente puede hacer que las cosas queden escritas en piedra. Tener Planes y predicciones no es malo, pero debemos evitar tomar decisiones irrevocables basados en especulaciones. No codifiques opciones, comuncalas al Cliente y decide con l. Desarrollar la capacidad de identificar las opciones que deben quedar abiertas, no es fcil, requiere tiempo y experiencia.

Do It YourSelf: Ejercita el UMR En una reunin de equipo, elabora una lista de decisiones que deban ser tomadas. Agrpalas en 2 categoras las fciles y las difciles. Escoge 3 decisiones difciles y aplica la tctica del Ultimo Momento Responsable para retrasar esas decisiones lo ms posible. Evala tu personalidad, y define si ests ms inclinado hacia un pensamiento de amplitud o de profundidad; busca a alguien con la inclinacin opuesta, discutan y decidan qu enfoque tomarn en el siguiente proyecto de desarrollo.

Tip #4: Entregar lo ms rpido posible El usuario tiene la funcionalidad que necesita cuando la necesita. Obtienes un feedback ms confiable por parte del usuario. Obtienes mayor certeza para la toma de decisiones, sepueden tener varias opciones hasta estar mejor informado.

El principio de Entregar lo ms Rpido posible, complementa el principio de Decidir lo ms tarde Posible.La velocidad de entrega determinar tu capacidad de retrasar decisiones (p.ej: si tienes la capacidad de entregar un cambio en una semana, entonces tienes una semana antes de decidir acerca de ese cambio).

Pull Systems Debe ser claro para todo el equipo, en todo momento, lo que cada uno debera de hacer para lograr una contribucin efectiva. Para una organizacin personal (self-organization) efectiva, se deben utilizar mtodos de sealizacin adecuados. Una de las caractersticas de un Pull System es el control visual y la gestin mediante la vista. Todos deben ser capaces de ver qu est ocurriendo, qu debe de hacerse, qu problemas existen y qu progreso se ha hecho.

Do It YourSelf: Crea tu propio PS Identifica un nico lugar (pizarrn, pared, portal, etc.) donde todos los que estn interesados en un proyecto puedan ver: La meta de la iteracin actual Qu se ha hecho ? Qu se est haciendo ? Qu no se ha hecho ? La misin del proyecto y lo que se ha hecho para cumplirla. Lo que falta por hacer para cumplir dicha misin.

Al final de cada iteracin, revisa tu proceso para entender en dnde se est invirtiendo el tiempo. Presenta al equipo el resultado y decidan qu se puede hacer para ir ms rpido y mejor. Toma las 2 mejores ideas e implemntalas en la siguiente iteracin.

Tip #5: Faculta al equipo No significa abandonar el liderazgo, pero s dejar que la gente que agrega valor utilice su potencial al mximo. Algunos programas de mejora intensifican factores que llevan a la insatisfaccin en el trabajo (polticas, supervisin, administracin) ms que la satisfaccin (logros, reconocimiento, responsabilidad). El pensamiento Lean capitaliza la inteligencia de quienes ejecutan el trabajo, con la certeza de que son ellos quienes determinan la manera de ejecutar su trabajo y mejorarlo constantemente. Facultar al equipo para que tome decisiones en el nivel ms bajo posible. En una organizacin Lean, la gente que agrega valor es el centro de la energa organizacional.

Bloques de Motivacin (sentidos) Pertenencia. Cada uno tiene clara su meta yest comprometido con su logro; el grupo gana o pierde como un equipo.

Seguridad. No mates la motivacin con una

mentalidad de mediciones personales, procura el aprendizaje con la experimentacin. genera un sentido de libertad, sino de incertidumbre. Un sentido de competencia viene de un equipo que tiene habilidades, conocimiento, recibe retroalimentacin y trabaja con convenciones establecidas entre ellos mismos. avanzado. En cada iteracin el equipo pone lo mejor de s mismo. Cuando el equipo logre un objetivo significativo, es tiempo de festejar !.

Competencia. Un ambiente indisciplinado no

Progreso. Es necesario sentir que se ha

Do It YourSelf: Faculta a tu equipo Elabora una lista de malas y buenas prcticas del equipo.De la primer lista, decide cules sern eliminadas y cules de la segunda sern implementadas y cmplelas. No lo hagas una sola vez, reptelo al final de cada iteracin.

Asegrate que el equipo de desarrollo comienza cada iteracin declarando y escribiendo la meta de la iteracin,una o dos oraciones que reflejen la aportacin de la iteracin a los objetivos del negocio o del proyecto. Coloca la meta en un lugar prominente (p.ej. tu PS). programacin por pares y en las revisiones de diseo, mantn el foco en el aprendizaje y el compartir experiencias, ms que en exacerbar errores.

Utilizar programacin por pares y revisiones de diseo. En Pide a cada persona que escriba un rea en la que considere que el equipo est dbil, ponlas a votacin y seleccionalas 3 con mayor puntaje. Organiza actividades para fortalecer esas reas (comprar un libro, llevarlos a Software Gur, revisar algn estndar para establecer convenciones, etc.).

Tip #6: Construir la Integridad Se pueden encontrar 2 clases distintas de integridad: Perceptiva, Conceptual. La integridad perceptiva tiene que ver con la percepcin que tiene el cliente del sistema, cuanto ms a gusto est y cuanto ms

cercano sea a sus exigencias y requerimientos, ms alta ser la integridad perceptiva.

La integridad conceptual significa que el concepto central del sistema trabaje en conjunto, como un todo cohesivo, y es un factor crticoque impacta en la integridad perceptiva.

La adaptabilidad es otro nivel de integridad para el software, es aquel que esta relacionado conla adaptabilidad del mismo en el futuro. Un software con integridad tiene una arquitectura coherente, se ajusta a los propsitos, es mantenible, adaptable y extensible fcilmente.

Cmo asegurar la integridad ? Utiliza partes existentes y software off-the-shell tanto como sea posible. Por ejemplo, utiliza CrystalReports antes que construirun mdulo de reportes.

Escribe software antes de que todos los detalles del diseo hayan sido finalizados y muestra parcialidades del software a clientes yusuarios para obtener su feedback.

Asegura que los desarrolladores tienen acceso al Clientepara obtener respuestas a sus preguntas tan pronto como sea posible. desarrollada.

Ejecuta pruebas en cada funcionalidad tan pronto como sea Desarrolla y ejecuta pruebas de Cliente a lo largo de la iteracin,no slo al final.

Si detectas que no hay suficiente tiempo, reasigna el tiempo paradetallar los requerimientos y dirgelo hacia el diseo de los Casos de Prueba de Cliente.

Do It Yourself: Construyendo Integridad En una reunin de equipo, invita a personas que: Prueban el sistema Distribuyen el sistema Entrenan a los usuarios Operan el sistema en produccin Trabajan en el Service Desk Mantienen el sistema Responsables de otros sistemas que interactan

Recolecta los principales comentarios con respecto al sistema en desarrollo, priorzalos y escoge los 3 con mayor puntuacin. En 2 semanas renanse de nuevo para ver cmo se han atendido stos 3 puntos y repitan el proceso. Estima el tiempo promedio que transcurre entre: Escribir la funcionalidad y las pruebas de Desarrollo Escribir la funcionalidad y las pruebas de Cliente Escribir la funcionalidad y su Distribucin

Determina un tiempo objetivo (mximo de 30% menos) por cada uno y ataca sta lista de arriba hacia abajo para lograr el tiempo objetivo.

Tip #7: Ver el Todo No significa ignorar los detalles, pero si generar conciencia de la tentacin de optimizar las partes en lugar del todo. Un problema desconocido produce sntomas que no pueden ser ignorados.No atacar los sntomas, sino buscar la causa raz. Los quick fixes normalmente enmascaran los problemas y promueven que se hagan ms grandes. menos 5 veces o hasta que identifiques una respuesta razonable. es el sistema, ms tentacin de dividirlo y mejorar las partes, en lugar de ver el desempeo del todo.

Identifica la causa raz, pregunta por qu?, al

Evita la sub-optimizacin. Entre ms complejo

Medir el Todo La manera de asegurar que la mtrica est centrada en el todo y evitar la suboptimizacin es por agregacin, que consiste en mover la mtrica un nivel hacia arriba. Utiliza Mtricas de Informacin (obtenidas por datos agregados que ocultan el desempeo individual). No lleves la rastreabilidad de los defectos a nivel del desarrollador. Menos del 20% de los defectos de calidad estn bajo control del desarrollador.

Do It Yourself: Medir el Todo Asegrate que el sistema de control de defectos sea un sistema de medicin, no de desempeo personal. Los defectos pueden ser rastreados hasta el desarrollador que caus el defecto ? por qu? Si no hay una buena razn que lo sustente, ni siquiera recolectes los nombres. Si existiera una razn para mantener el nombre, asegura que solamente el desarrollador que tiene asignados los defectos es el nico que puede conocerlos. No publiques o gestiones los defectos ordenados por desarrollador.

Conclusiones La aplicacin de los principios Lean en el desarrollo de software permite mejorar los procesos y as obtener mejores resultados. Aumenta la calidad del producto, posibilitando bajar los costos y acortar los tiempos de desarrollo. Estos principios son una gua universal, muchas metodologas giles aplican algunos de ellos, pero el DSE provee una visin integral. Lo importante es poder entender y adoptar la escencia de los principios Lean. Las mejoras que se pueden lograr son increbles, no solo en el producto final y su evolucin, sino en la participacin, compromiso y satisfaccin de las personas involucradas.

Preguntas

Ernesto Elizaldeeelizalde@itera.com.mx