He terminado hace poco este interesante libro, y quería compartir brevemente mis

impresiones. El libro describe cómo se aplica la metodología ágil Kanban al

desarrollo del sistema de información que usa la policía nacional de Suecia para
gestionar su trabajo. El objetivo era poner en cada coche de policía un portátil y
una aplicación Web que permitiera a los agentes consultar información y hacer
ciertos “papeleos” sin tener que pasar por comisaría. El resultado ha sido muy
positivo y ha permitido agilizar mucho la burocracia, permitiendo que los policías
pasen más tiempo en la calle y menos en la comisaría.

El libro describe dos años de desarrollo de proyecto (2009-2011), incluyendo el

primer piloto con usuarios reales y el lanzamiento a nivel nacional. En el desarrollo
empiezan trabajando 10 personas, pero en las últimas fases son más de 60. El ritmo
de trabajo puede parecer “lento” para un proyecto ágil (primera versión con
usuarios reales en un año, y sistemas integrados en producción cada dos meses),
pero si se compara con proyectos gubernamentales similares, este ritmo es bastante
rápido.

Kanban es una aproximación al desarrollo de software ágil que sobre el papel es

muy simple puesto que solo tiene tres reglas:

1. Visualiza el flujo de trabajo: tareas escritas en tarjetas y puestas en

columnas que representan las fases de este flujo de trabajo.
2. Limita el trabajo en marcha: límites explícitos a cuántas tarjetas puede haber
en cada columna.
3. Mide y gestiona el tiempo de ciclo: tiempo medio para que una tarea pase
por todo el flujo de trabajo hasta estar completada.
Una organización que decida aplicar Kanban tendrá que decidir cómo encajar esas
tres reglas con el trabajo que tiene que realizar, y aquí es donde entra este libro,
describiendo cómo se organizó el trabajo en este proyecto basándose en estas tres
reglas. El libro es ameno, proporciona muchas ideas útiles y puede ser una gran
ayuda para entender cómo de algo tan aparentemente simple como Kanban puede
surgir una metodología de trabajo para llevar a cabo con éxito un proyecto
complejo como el que se presenta. Es interesante hacer notar que a pesar de que no
usan Scrum, muchas de las prácticas que los equipos de trabajo del proyecto van
desarrollando se acaban pareciendo mucho a algunas de las técnicas fundamentales
de Scrum y de otras metodologías ágiles.

Además de la experiencia con el proyecto, el libro también tiene una pequeña

sección sobre técnicas, pero es cortita y la selección de temas parece un poco
aleatoria.
En resumen, un libro interesante, que se lee rápido, y que proporciona una visión
desde dentro sobre el trabajo en proyectos de software moderadamente complejos
siguiendo metodologías ágiles.

__________________________________________________________________

Página 1
Lean from the Trenches
Gestión de proyectos de gran escala con Kanban
Henrik Kniberg; The Pragmatic Programmers, LLC, 2011, 157 páginas
ISBN 978-1-934356-85-2
Informe del libro
Jim McDonough, 27 de abril de 2012
revisión
Este libro es principalmente un estudio de caso de cómo Lean y Kanban se
utilizaron en un proyecto de software para
La aplicación de un nuevo sistema de investigación digital para la Autoridad
Nacional de Policía de Suecia. Parte I, Cómo
We Work, comprende dos tercios del libro y aborda este estudio de caso. A
continuación le sigue la Parte II, A
Una mirada más cercana a las técnicas, que describe más de los aspectos
académicos de Agile Software
Procesos de desarrollo utilizados en el estudio de caso. Incluye un prólogo de
Kent Beck, quien dice:
"He tenido la suerte de trabajar con Henrik un poco, y me dijo que realmente
sólo tiene un truco:
Hacer que toda la información importante sea visible en un lugar y luego decidir
qué hacer juntos "(p.
Ix)
Estas ideas de "hacer visible la información" y "decidir juntos" se refuerzan a lo
largo del
Autor describe en detalle cómo el equipo se acercó al proyecto, admitiendo
libremente no adherirse
Cualquier proceso prescrito con este descargo de responsabilidad sincero:
"No afirmo que nuestra forma de trabajar sea perfectamente Lean. Lean es una
dirección, no un lugar. Es todo
Acerca de la mejora continua. "(P.
1 - Acerca del proyecto
Para establecer el escenario para el resto del libro, el autor comienza con
algunos antecedentes sobre el estudio de caso,
Incluyendo el tipo de trabajo realizado por el cliente, el plazo previsto para la
implementación del nuevo
Las versiones de software, el número de participantes, la división del trabajo y
la participación del cliente
Con el esfuerzo de desarrollo de software. Reforzando el concepto de mejora
continua, el autor
Indica que se utilizó un enfoque Lean no sólo para facilitar el diseño y
desarrollo de software, sino también
Para mejorar el proceso por el cual entregar ese software:
"[El proyecto] es parte de un cambio cultural dentro de [la Autoridad Nacional
de Policía Sueca], un
Iniciativa Lean en todo el país. Por lo tanto, tenía sentido comenzar a aplicar
Principios lean para el proceso de desarrollo en sí mismo! "(Página 5)
Cada proyecto tiene sus propios ajustes cuando se aplica la teoría a la práctica:
"Mi enfoque principal fue poner en práctica principios Lean y Agile y ayudar a
los equipos
Evolucionar sólo el proceso adecuado para su contexto.
"Una de las características más importantes de un proceso de Lean es que sigue
evolucionando.
A veces encontramos mejores soluciones. A veces una solución aparentemente
grande ayer causa una
Nuevo problema hoy. A veces nuestro entorno y circunstancias cambian,
forzándonos a
Adaptar ". (Pp. 5-6)

Página 2
2 - Estructuración de los Equipos
Los equipos para este proyecto consistieron en tres equipos de características,
un equipo de requisitos y un equipo de pruebas,
Aunque hubo cierta superposición entre los miembros de cada equipo tanto
como el equipo de requisitos y
Equipo de pruebas tenía representantes en cada uno de los tres equipos de
funciones. Además, todos los equipos estaban ubicados en
La misma planta del mismo edificio. Tanto la colocación como la superposición
de miembros del equipo facilitaron
Comunicación entre todos los participantes. El autor afirma que se trata de un
arreglo beneficioso cuando
El proyecto se amplió:
"En el pasado, los equipos estaban organizados por especialidad. Teníamos un
equipo de requisitos
Distintos equipos de pruebas y equipos de desarrollo distintos que no tenían
probadores o
Analistas. Eso no escaló muy bien, porque como más gente fue agregada al
proyecto,
Problemas de comunicación desarrollados. Los equipos tendían a comunicarse
con otros equipos
Documentos en lugar de hablar, y tendían a culpar a los problemas entre
sí. Equipos también
Tendían a concentrarse en obtener su parte del trabajo realizado en lugar de todo
el producto "(pp. 10-11).
Este arreglo, agrega el autor, no estaba en su lugar al principio, sino que se
convirtió en la estructura del equipo después de
Evolucionando gradualmente.
3 - Asistir al Cocktail diario
Un vistazo se proporciona en el uso de una técnica a la que muchos se refieren
como el diario stand-up scrum, corto
Reuniones, un máximo de quince minutos, donde se discute el estado y progreso
del equipo
Sus miembros. Hubo tres niveles de estas reuniones que tienen lugar en este
proyecto:
•
Primer nivel - Los tres equipos de la característica; Uno comenzando a las 9:15
am y los otros dos comenzando a las 9:30 am.
•
Segundo Tier - Tres reuniones de sincronización por especialidad: una para el
equipo de requisitos, una
Para el equipo de pruebas y uno para la sincronización de desarrollo de los tres
equipos de primera categoría,
Con todas las reuniones que tienen lugar simultáneamente a partir de las 9:45
am.
•
Tercer Nivel - Sincronización del proyecto de las tres reuniones de segundo
nivel, comenzando a las 10:00 am.
Esto facilitó una comunicación eficaz:
"Eso es. Un total de siete reuniones stand-up cada día, organizado en tres
capas. Cada
timeboxed reunión está a quince minutos, cada reunión tiene un conjunto básico
de participantes que muestran
Cada día, y cada reunión es pública, así que cualquiera puede visitar cualquier
reunión si quiere aprender
Qué está pasando o tiene algo a contribuir. Y todo ha terminado a las 10:15 am.
"Muchos problemas que de otro modo resultarían en la creación de documentos
y reglas de proceso son
Resuelto directamente en estas reuniones de la mañana. Un ejemplo concreto es
decidir qué equipo es
Desarrollar qué característica; Otro ejemplo es decidir si gastamos nuestro
tiempo de desarrollo
Funcionalidad orientada al cliente o mejoras invisibles para el cliente en la
infraestructura técnica.
En lugar de establecer reglas de política para esto, los equipos simplemente
hablan de esto durante la
Reuniones y tomar decisiones sobre la marcha sobre la base de la situación
actual. Esta es la clave para permanecer
Ágil en un gran proyecto y no quedar atascado en la burocracia ".
4 - La Junta del Proyecto
Al referirse a ella como el eje de comunicación del proyecto, el autor describe
las características de la
Proyecto bordo
"La nuestra es una pizarra de varios metros de largo que muestra todas las
características clave del proyecto que fluye a través de la
Tubería desde los requisitos, el desarrollo y la prueba del sistema, todo el
camino hacia la producción. "(Página 19)

Página 3
Completo con fotografías del tablero real utilizado durante este proyecto,
"Si usted está en Kanban, reconocerá esto como un sistema Kanban, lo que
significa que hacemos un seguimiento de la
Flujo de valor de la idea a la producción y que limitamos la cantidad de trabajo
en progreso en cada
Paso del proceso "(página 19)
Y utiliza una analogía de tráfico para describir cómo fluye el trabajo a través del
sistema.
"Al igual que con un sistema de tráfico, un bloqueador que permanece durante
demasiado tiempo causará efectos de rizo
En todo el sistema. Además, nada fluirá más rápido que la sección de cuello de
botella del
Camino, por lo que concentrar todos los esfuerzos en la solución de estos
cuellos de botella. "(P.25)
5 - Escalando los tableros Kanban
El autor explica cómo la junta del proyecto permitió gestionar el reto de
aumentar el tamaño de la
A medida que avanzaba el proyecto,
"La velocidad de un proyecto se determina en gran medida por lo bien que todos
entienden lo que está pasando.
Si todo el mundo sabe dónde estamos ahora y hacia dónde vamos, es mucho
más fácil para todos
Para moverse en la misma dirección.
"Es por eso que creamos la junta del proyecto. Es una forma de mantener un
registro de la imagen
Características del proyecto a medida que pasan de los requisitos al desarrollo, a
la prueba del
producción.
"Esta junta tuvo un fuerte efecto sobre la cultura de la organización. Ahora
podíamos ver! Y todos nosotros
tenía la misma imagen! "(p. 27)
Pero la junta del proyecto no era la única junta Kanban utilizada en el proyecto:
"Así, el tablero del proyecto contiene tarjetas de características, y cada equipo
tiene su propio tablero con el
Funciones en las que están trabajando, más el desglose de tareas
asociado. Imagine que "haga doble clic"
Una característica en el tablero del proyecto y "acercar" al equipo
correspondiente para ver qué tareas
Están involucrados en esa característica y que está trabajando en qué tarea.
"(Página 29)
Dado que este proyecto no estaba siguiendo una fórmula prescrita, sino que los
miembros del equipo estaban descubriendo
Lo que funcionó para ellos, no hubo ningún intento de que cada equipo de
bordo se ajustan a algún formato arbitrario:
"Como se puede ver en las imágenes, cada equipo tiene su propio diseño de
tablero. No hemos tratado de
Estandarizar esto. En su lugar, dejamos que cada equipo encuentre la estructura
de tablero que mejor funcione para ellos ".
(Página 30)
6 - Seguimiento de la Meta de Alto Nivel
El objetivo de alto nivel se publicó en el tablero de Kanban para que todos lo
vean. Esto alivió el problema
Experimentado en algunos proyectos en los que sólo se puede suponer que todo
el mundo es consciente de la meta, cuando en
Realidad puede haber una amplia gama de opiniones sobre lo que constituye el
objetivo de alto nivel.
Además, la meta fue revisada periódicamente en la reunión de sincronización
del proyecto para determinar si
No los participantes todavía sentían que la meta era alcanzable. Un método
simple de votar levantando los dedos,
De 1 a 5, determinaría si había alguna razón para ajustar la meta de alto nivel.
"Puedo recomendar fuertemente tener una meta clara y una verificación
periódica de la realidad, sin importar qué tipo de
Proyecto en el que está involucrado. El costo de hacer esto es muy bajo, y el
beneficio es muy alto! "(Página 34)

Página 4
7 - Definición de Listo y Listo
La definición de "hecho" apareció en la parte superior de la mayoría de las
columnas del tablero del proyecto, y también sirvió para
Indican la definición de "listo" para la siguiente columna, siendo los dos más
importantes el "listo para
Desarrollo "y" listo para la prueba del sistema ".
"Estas dos declaraciones de política - definición de lista para el
desarrollo y definición de lista para
prueba del sistema - han mejorado significativamente la colaboración entre los
equipos. Esta mejora
Se destacó claramente cuando hice una breve encuesta para comprobar lo que la
gente pensó acerca de alto el proceso
Cambios hasta el momento "(página 38).
8 - Manejo de historias de tecnología
El autor explica qué son las historias de tecnología y qué tan importante es
incorporarlas al flujo de
trabajo:
"Las historias técnicas son cosas que necesitan hacerse pero que no son
interesantes para el cliente, como
Actualizar una base de datos, limpiar el código no utilizado, refactorizar un
diseño desordenado o ponerse al día
Automatización de pruebas para funciones antiguas. Llamamos a estas mejoras
internas, pero en retrospectiva, la tecnología
Historias es probablemente un término mejor, ya que estamos hablando de cosas
que hacer con el producto, no
Mejoras en los procesos. "(P.39)
El autor cita una historia humorística sobre una unidad de medida que surge de
este proyecto para medir la
Esfuerzo involucrado en la implementación de historias de tecnología:
"Una de las clases en nuestra base de código estaba fuera de control y
necesitaba algunas
Refactoring, pero había cierta resistencia a pasar tiempo en eso. Por lo tanto,
uno de los líderes del equipo
Imprimió la clase entera y la colocó a través de la mesa de la
conferencia! Estaba a más de 7 metros
Largo (23 pies)!
"Mirando esa impresión monstruosa, todo el mundo claramente vio que
necesitábamos una historia tecnológica para arreglar eso
Clase inmediatamente! No se necesita argumento. Esto también ilustraba la
consecuencia de estar en una
Prisa y no prestar suficiente atención al diseño.
"Nos divertimos especulando sobre futuros desarrollos a lo largo de este
tema. Que tal si nosotros
Estimar las características de los codimetros y medir la velocidad en codimetros
por día? Podríamos incluso
separados de códigos metros ideal (el tiempo que el código sería si nos
mantenía muy limpia), con real
Codificadores. Reste esos dos, y obtiene la deuda técnica - en
metros! Podríamos incluso dibujar un
Línea en el suelo para simbolizar la cantidad de deuda técnica que tenemos
('Hey mira, tenemos 23 metros de
Deuda! '). "(Pp. 42-43)
9 - Manejo de errores
El autor recomienda tanto el sistema continuo de pruebas y la fijación de errores
de inmediato, en contraposición a
Ahorrando lotes de trabajo terminado para ser probado sistema a la vez. Un
argumento convincente es
Presentado para la forma en que el sistema continuo de pruebas se ahorrará
tiempo y esfuerzo a largo plazo.
También se sugiere una política práctica hacia los errores, una en la que no
todos los errores se arreglarán, ya que hay algunos
Bugs de tan bajo significado que sus posibilidades de ser abordados son
nulas. Mejor reconocer
Publicamente que estos insectos no serán tratados en lugar de proporcionar
falsas esperanzas de que serán solucionados.

Página 5
Algunos bugs son tan importantes que obtienen su propia etiqueta de
seguimiento en el tablero del proyecto. Otros que son de
Menos importancia será rastreada en una cola de errores. El tamaño de la cola
de errores es limitado. Cuando un nuevo error
Y no es lo suficientemente importante como para obtener su propia etiqueta de
seguimiento en la junta del proyecto, se toma una decisión
Si se debe agregar a la cola de errores completa, en función de si es más
importante que alguna otra
Bug ya en la cola de errores. Si no, el nuevo error se ignora; De lo contrario
sustituye en la cola el error
A la que es más importante. Así es como el número de bugs se gestiona sólo a
aquellos que serán
Corregido.
"Limitar el tamaño del rastreador de errores genera confianza. La lista de
errores es corta, pero las cosas ahí en realidad
Se arregla, en lugar de estar sentado durante meses sin que nada suceda. Si un
error es
Es improbable que se fije ... somos honestos sobre eso desde el principio, en
lugar de construir falsos
Expectativas ". (Página 49)
10 - Mejora Continua del Proceso
La mejora del proceso de desarrollo de software en sí consistió en mantener
retrospectivas de equipo,
Personal en talleres de mejora de procesos y gestión de la tasa de cambio. Este
es un aspecto que parece
Para obtener muy poca atención en aquellos proyectos de desarrollo de software
en los que la
Siguiendo un proceso documentado es suficiente. De hecho, como explica el
autor:
"Nuestro proceso no estaba diseñado de antemano. Nunca habría sido capaz de
imaginar todo esto
Fuera, especialmente no solo. E incluso si pudiera, no habría ningún buy-in del
proyecto
Participantes, por lo que cualquier proceso diseñado de antemano nunca habría
alcanzado
Documento en el que fue escrito.
"Nuestro proceso fue descubierto más que diseñado." (P.53)
A pesar de contar con un proceso que facilita el cambio, fue necesario
estrangular la tasa de cambio para evitar
Abrumando al personal con demasiados cambios a la vez:
"Pero la tasa de cambio también causó confusión, especialmente para la mayoría
de las personas que
No estaban en el equipo cruzado y que vio un montón de cambio sucediendo sin
que siempre se le da un
Oportunidad de entender o discutir el cambio "(p.54).
Esto no sólo limita los cambios simultáneos a un nivel manejable, sino que
también apoya la proposición de que
Aquellos que están sujetos a cambios deben ser capaces de contribuir al proceso
de cambio.
11 - Gestión del trabajo en curso
El panel del proyecto tiene columnas para trabajos en curso (WIP), así como las
columnas de almacenamiento en búfer usadas como escenario
Áreas para gestionar el trabajo que se mueve entre las columnas de trabajo en
curso. El autor utiliza una analogía de buzón para
Explicar la relación entre el trabajo en curso y sus buffers - un buzón de correo
sólo puede contener tanto
Correo electrónico antes de que tenga que ser borrado de contenido - y presenta
un buen argumento para limitar la cantidad de
Trabajo que puede estar activo para una columna de trabajo en curso.
"El propósito de los límites de WIP es evitar demasiada multitarea y sobrecargar
un downstream
proceso. Si los probadores tienen demasiado trabajo que hacer, no queremos
que los desarrolladores sigan construyendo nuevos
Características y añadir a su carga de trabajo - en su lugar, deben centrarse en
ayudar a la prueba. Ley de límites de WIP
Como una señal de alerta para resaltar el problema antes de que se salga de la
mano. "(Página 69)
12 - Captura y uso de métricas de proceso
En este proyecto se realizaron dos mediciones:

Página 6
•
Características por semana (velocidad)
•
Semanas por función (tiempo de ciclo)
La métrica de velocidad se utilizó de dos maneras: 1) como un control de la
realidad para asegurarse de que el plan de liberación fue
Realista, y 2) predecir aproximadamente cuántas características se harán en una
cierta fecha.
La métrica del tiempo de ciclo se utilizó para predecir cuánto tiempo se tardaría
en completar una característica.
El autor proporciona razones para no usar algunas de las otras técnicas de
rastreo comunes en
Proyectos de desarrollo de software, tales como el uso de puntos de la historia,
la medición del tiempo de ciclo todo el camino a la producción
Y el flujo acumulativo.
13 - Planificación del lanzamiento de Sprint
Se convoca una reunión de planificación para determinar qué hacer a
continuación. La lista resultante de características
Proyecto en la columna titulada "Diez funciones siguientes". El autor admite
cierta divergencia de
Scrum, declarando que el equipo no se compromete a un conjunto específico de
características para el siguiente
Sprint, como en Scrum, ni siquiera utilizan sprints. Simplemente se ponen de
acuerdo sobre lo que se
La velocidad no ha sido lo suficientemente estable como para poder predecir
cuántas características se podrían hacer en el corto plazo
término. Las características se eligen en función de los siguientes criterios
(página 86):
Valor de negocio -
¿Cuáles son las características que el cliente será más feliz de ver?
Conocimiento -
¿Cuáles características generarán conocimiento (y así reducirán el riesgo)?
Utilización de los recursos - queremos un balance de las áreas de funciones para
que cada equipo tenga cosas para trabajar
en.
Dependencias -
¿Cuáles características se construyen mejor juntos?
Testabilidad -
Características que son más lógicas de probar conjuntamente y por lo tanto
deben
Desarrollados en estrecha proximidad entre sí?
14 - Cómo hacemos el control de la versión
Problemas de gestión de software comenzó a derivar en la escala de treinta a
sesenta personas. En el momento en que
El sistema de control de versiones utilizado era inestable, conteniendo troncos
rotos y ramas durante largos períodos.
Para corregir esto, se instituyó un modelo principal consistente en un tronco
estable con ramas para cada equipo
Y una rama para la prueba del sistema.
"El sistema de control de versiones es realmente el corazón de cualquier
proyecto de desarrollo multiteam. Como el
Organización se convierte en más Lean y Agile, el sistema de control de
versiones suele
Evolucionó también. Por lo tanto, mantener un ojo en esto. Averigüe cuánto
tiempo se tarda en cambiar una sola línea de
Código y conseguirlo en la producción. ¡Esa puede ser la métrica más
importante en el proyecto! "(Página 94)
15 - Por qué Utilizamos Solo Tableros Kanban Físicos
Con todas las herramientas de software disponibles para la gestión de proyectos,
fue refrescante saber que este proyecto había
Utilizó un tablero de proyecto físico en lugar de una contraparte electrónica. El
autor explica que el
Versión más adaptable a la evolución de la junta del proyecto, siendo necesarios
los cambios
Fácilmente aplicable a una entidad física muy fácilmente por casi cualquier
persona, mientras que una versión electrónica sería
Requerir conocimientos especializados de la herramienta en sí, y todavía no
podría mantener con la tasa de cambio tan fácilmente como
Una versión física.

Página 7
Otra razón mencionada para el uso de una junta física fue la colaboración entre
los participantes. los
Cócteles diarios (stand-up scrums) se realizó frente a las juntas físicas,
proporcionando una plataforma para
Facilitar la interacción para la discusión en curso.
"Un patrón claro que he notado con todos mis clientes es que tablas como esta
pueden cambiar la cultura de
Una organización, y esto definitivamente sucedió [en este] proyecto. Pude ver
cómo los patrones de
Interacción cambiada y cómo mejoró la confianza entre los equipos al colaborar
frente al
Tableros todos los días. Durante nuestra primera retrospectiva a nivel de
proyecto, uno de los primeros
en el marco de seguir haciendo era "seguir usando tableros Kanban para
visualizar el trabajo. '" (p. 97)
16 - Lo que aprendimos
Basado en su experiencia en este proyecto, el autor comparte su observación
sobre lo que hace
proceso:
"Un gran proceso no está diseñado; su evolucionado. Por lo tanto, lo importante
no es su proceso; el
Lo importante es el proceso para la mejora de su proceso. "(p. 99)
Un resumen de algunas de las cosas aprendidas en este proyecto son:
•
Conozca su objetivo
•
Experimentar
•
Fracaso del abrazo
•
Resolver problemas reales
•
Han dedicado agentes de cambio
•
Involucrar a las personas
17 - Ágil y Lean in Nutshell
El autor ofrece breves resúmenes "... en pocas palabras" de los siguientes
conceptos de desarrollo de software:
•
Ágil
•
Apoyarse
•
Melé
•
XP
•
Kanban
Agile se describe a partir de 2001 cuando diecisiete líderes de desarrollo de
software se reunieron en una estación de esquí en
Utah, resultando en la creación del Manifiesto Ágil, aunque muchas de las
técnicas que abarcan Agile
Ya se había desarrollado antes de esta fecha.
Lean se describe como originario de las técnicas de fabricación japonesas,
específicamente el Toyota
Sistema de Producción, con los principios adaptados al software descritos por
Mary y Tom Poppendieck:
•
Optimizar el conjunto
•
Eliminar residuos
•
Construir calidad en
•
Aprende constantemente
•
Entrega rápida
•
Involucrar a todo el mundo
•
Sigue mejorando

Página 8
Scrum se describe como un enfoque desarrollado a principios de 1990 por Jeff
Sutherland y Ken Schwaber,
Basado en principios de control empírico de procesos y teoría de sistemas
complejos adaptativos, con explicaciones
Para términos de scrum como cartera de productos, sprints, equipos
multifuncionales y proceso continuo
ajuste.
XP se describe como un enfoque desarrollado a mediados de los años 90 por
Kent Beck, basado en los valores de simplicidad,
Comunicación, retroalimentación, coraje y respeto. Se muestra cómo XP y
Scrum se complementan entre sí
Y proporciona detalles adicionales para términos de XP tales como integración
continua, programación de pares, pruebas
Desarrollo, propiedad colectiva del código y mejora incremental del diseño.
Kanban, una palabra japonesa que significa "tarjeta visual", se describe como
una técnica asociada con Lean, con
Definición de sus características de visualización del flujo de trabajo, limitación
de los trabajos en curso y
Medir y administrar el tiempo de ciclo. Como estos aspectos conceptuales de
Kanban se revelan, junto con un
Serie de imágenes Kanban que representan un ejemplo de progresión temporal,
sirve para aclarar
Principios en el trabajo para la junta del proyecto que se había utilizado como
base para el estudio de caso.
18 - Reducir el backlog de automatización de pruebas
Después de declarar lo que parece ser una barrera para el progreso de muchas
organizaciones de desarrollo de
Ausencia de pruebas automatizadas para el código heredado - el autor presenta
opciones para abordar esta dificultad:
1. Ignorar el problema
2. Reconstruir el sistema desde cero utilizando el desarrollo de pruebas
3. Inicie un proyecto de automatización de prueba independiente
4. Deje que el equipo mejore la cobertura de la prueba con cada iteración
Al identificar la opción 4 como la más práctica basada en su experiencia, el
autor presenta una hoja de ruta
De cómo abordar la tarea desalentadora de proporcionar nuevas pruebas
automatizadas para el software existente.
"Independientemente de la cartera de automatización de pruebas,
cada nueva característica debe incluir una prueba automatizada
En el nivel de característica. Esa es la práctica XP conocido como pruebas de
aceptación del cliente. No hacer esto
Es lo que consiguió su sistema en este lío en el primer lugar.
"Pero además de implementar nuevas historias, queremos pasar algún tiempo
automatizando viejas pruebas
Casos ". (Página 122)
Es encomiable que el autor aborda el problema de la acumulación de
automatización de pruebas, ya que la automatización de pruebas
Fácilmente se puede percibir como una herramienta útil que se aplica sólo a un
nuevo desarrollo.
Para aquellos que aún no han adoptado el concepto de pruebas automatizadas, el
autor hace una
Para su uso:
"Tenga en cuenta que el costo de prueba manual se incurre cada vez que se
ejecuta la prueba, mientras que el costo de automatización se incurre
sólo una vez. Por lo tanto, el tiempo dedicado a escribir código de
automatización de pruebas es en realidad una inversión, no un costo "(p.
120)
19 - Dimensionar el backlog con Planning Poker
El planeamiento del póker, un término acuñado por James Grenning y
popularizado por Mike Cohn, es una técnica usada para
Estimando el esfuerzo involucrado en tareas de desarrollo de software. El autor
muestra cómo "jugar" el
Estimando el juego usando las tarjetas que tienen cinco símbolos diferentes para
significar el esfuerzo estimado:
S - Pequeño esfuerzo
M - esfuerzo medio

Página 9
L - Gran esfuerzo
? - No lo sé
Taza de café - tiempo para un descanso
Cada miembro del equipo obtiene una de cada tarjeta. Se presenta una
característica para la estimación. Cada miembro del equipo
Presenta una de las cartas, boca abajo. Cuando se hayan jugado todas las cartas,
cada una de ellas
Revelar su símbolo. Consenso virtual sobre el esfuerzo estimado se logra
cuando hay una convergencia a uno
Tipo de tarjeta. En los casos de divergencia amplia, se sigue una discusión para
determinar por qué existe tal
Desacuerdo sobre el esfuerzo estimado, y el juego continúa en otra ronda,
repitiendo el ciclo hasta
Existe cierto acuerdo sobre el esfuerzo estimado.
Este uso de tarjetas elimina la influencia que algunos miembros del equipo
tendrían sobre otros en casos donde
Cada persona se pregunta en serie para expresar verbalmente su estimación, o
donde algunos miembros del equipo, debido a
Confusión o falta de atención, simplemente especifique una estimación del
esfuerzo ya declarado por otra persona.
20 - Diagramas de causa-efecto
Un tratamiento exhaustivo del uso de los diagramas de causa y efecto muestra
cómo estos diagramas pueden resaltar
Problemas en el proceso en lugar de sólo los síntomas. Una técnica presentada
es el formato A3 típico
De Lean, mientras que otro es el uso de los Cinco porqués.
El autor muestra cómo usar los cuadros para diagramar los aspectos de un
proceso. Las flechas de conexión
Relaciones entre las cajas. Aquellas cajas con sólo flechas entrantes representan
problemas; Aquellos con
Sólo las flechas salientes representan las causas raíz; Aquellos con flechas
entrantes y salientes representan
Los síntomas. Una vez identificadas, las causas fundamentales pueden ser
abordadas.
Un resultado interesante del uso de este tipo de diagrama es la aparición de una
serie de cuadros de síntomas
Relacionados entre sí a través de un conjunto circular de flechas de conexión,
conocidas como ciclos viciosos y como refuerzo
Bucles
"Los problemas recurrentes casi siempre implican [reforzar] bucles ... pero
pueden tomar algún tiempo para
encontrar. Detectar éstos aumentará considerablemente su probabilidad de
resolver el problema con eficacia y
Permanentemente! "(Página 136)
Se crea un diagrama causa-efecto siguiendo una simple secuencia de pasos:
"Aquí está el proceso básico:
1. Seleccione un problema - cualquier cosa que le molesta - y anótelo.
2. Trace 'hacia arriba' para averiguar las consecuencias del negocio, el 'daño
visible' que su
Problema está causando '.
3. Trace 'hacia abajo' para encontrar la causa raíz (o causas).
4. Identificar y destacar ciclos viciosos (caminos circulares).
5. Itére estos pasos unas cuantas veces para refinar y aclarar su diagrama.
6. Decida qué causas raíz se deben abordar y cómo (es decir, qué contramedidas
Implementar). "(Página 134)
El uso de diagramas de causa-efecto se resume como ayudar a los equipos a
•
Crear un entendimiento común
•
Identificar cómo afectan los problemas al negocio
•
Encontrar las causas principales
•
Identificar y eliminar los ciclos viciosos
Resumen

Página 10
Este libro contiene un buen balance de la teoría ágil y su aplicación práctica. El
libro es corto y
Fácil de leer y el autor hace un trabajo excelente de describir cómo Agile, Lean
y Kanban se utilizaron en
Práctica sobre un proyecto específico, así como la presentación de información
general sobre estos conceptos. Aunque no
Libro que describa una implementación real del uso de prácticas Ágiles debe ser
usado como un
otros la copien, este libro presenta el estudio de caso de una manera donde el
lector puede apreciar cómo
la información se pone a disposición, lo que permite al equipo a decidir
juntos cómo proceder.
Pasajes notables
"Una persona actuó como el principal" cliente "(o" comprador ") en el
proyecto. Ella tenía una lista de
Un nivel muy alto. Los llamamos áreas de característica, que equivale
aproximadamente a qué gente ágil
Llamaría épicos "(p.7)
"Para el observador casual mirando el tablero [del proyecto], este sistema podría
parecer una cascada
Proceso: análisis de requisitos → desarrollo → prueba del sistema → prueba de
aceptación → producción.
Sin embargo, hay una gran diferencia. En un modelo de cascada, todos los
requisitos se completan antes
El desarrollo comienza y el desarrollo se completa antes de que empiecen las
pruebas. En un sistema Kanban,
Estas fases se desarrollan en paralelo. Mientras que un conjunto de
características es comenzar a aceptar-probado por
Usuarios, otro conjunto de características está siendo probado en el sistema, se
inicia un tercer conjunto de características
Y un cuarto conjunto de características está siendo analizado y dividido en
historias de usuarios. Es un flujo continuo
Del valor de la idea a la producción "(p.21).
"Usando Kanban para descubrir Scrum - Esto parece ser un patrón general: Veo
muchos Kanban
Equipos que gradualmente descubren (o a veces redescubren) el valor de
muchos de los Scrum
Prácticas. De hecho, a veces los equipos Kanban empiezan a hacer Kanban
porque no les gusta Scrum
Y más tarde descubrir que Scrum era realmente muy bueno y sus problemas
habían sido
Expuesto por Scrum, no causado por él. Su verdadero problema era que habían
estado haciendo Scrum también
Mucho "por el libro" en lugar de inspeccionar y adaptarlo a su contexto. "(P.22)
"Si haces un análisis de causa-efecto sobre los bugs, verás que los bugs no son
realmente un problema; son
Un síntoma. Errores en su producto son un síntoma de errores en el proceso. Si
se concentra en la fijación
Su proceso, reducirá drásticamente el número de nuevos errores en su
producto. Es como si
Usted se enfoca en la prevención de incendios, reducirá la necesidad de
combatir incendios "(p.52).
"El propósito declarado de [el taller de mejora de procesos] es aclarar y mejorar
nuestra
trabajando. Una de mis tareas más importantes como entrenador fue establecer y
facilitar estos procesos
Talleres de mejora hasta que se convirtieron en parte de la cultura. "(P.55)
"Cada taller semanal de mejora de procesos causó una ráfaga de cambios, en su
mayoría
mejor. Sin embargo, después de un tiempo, nos dimos cuenta de que estábamos
cambiando demasiado, demasiado rápido. Esto era
Un problema interesante. En la mayoría de las organizaciones con las que he
trabajado, el problema es que también hay
cambio pequeño proceso - todo el mundo se ha quedado atascado en su proceso
ineficaz actual. Aquí teníamos
Alcanzó el problema opuesto. Estábamos haciendo un montón de cambios, y es
cuestión de días o, a veces
Semanas para un cambio de proceso significativo para ondular a través de un
proyecto de 60 personas. Muchos equipos
Los miembros se confundieron (ya veces frustrados) cuando el equipo cruzado
introdujo nuevos cambios
Antes de que el polvo de los cambios previos se hubiera resuelto. "(P.62)
"... Kanban no proporciona muchas reglas específicas. Depende de ti decidir
cosas como cuántas
Tablas para usar en un proyecto Esa es la belleza (y el dolor) de Kanban - es
flexible, y usted figura
Cosas a medida que avanza. Simplemente ateniéndose a esta regla general: "En
caso de duda, elija el más simple
Solución "." (Página 64)
"Si tuviéramos un tablero electrónico Kanban, podríamos usar un proyector para
mostrarlo en la pared. Pero nosotros
Perdería la mayor parte de la interacción, la parte donde la gente toma una
tarjeta de la pared y la agita

Página 11
Mientras habla de ello, o donde la gente escribe cosas en las tarjetas o las mueve
alrededor durante el
reunión. La gente lo más probable es actualizar el tablero mientras está sentado
en su escritorio - que es más
Conveniente pero menos colaborativa ". (P.97)
"A la mayoría de la gente le gusta el cambio; que simplemente no les gusta ser
cambiado. Por lo tanto, no hacer ningún cambio sin
Primero involucrando a las personas que serán afectadas por ella. Obligar a las
personas a cambiar es usualmente
Ineficaz, innecesario y, bueno, cruel. Si la gente se resiste a su gran propuesta
de cambio, usted
Probablemente no han hecho el problema suficientemente claro. O estás
resolviendo el problema equivocado. Regresa
A su diagrama causa-efecto ... y pensar de nuevo! "(Página 100)
"Ágil y Lean pueden ser vistos como primos con valores comunes, pero
diferentes orígenes. Lean surgió
Desde la fabricación. Agile surgió del desarrollo de software. Ambos conjuntos
de principios encajan bien
Y son muy ampliamente aplicables. Más y más organizaciones de desarrollo de
software
Están descubriendo cómo combinar estos principios para cubrir toda la cadena,
desde el concepto de producto hasta
Entrega ". (Página 106)
"La mayoría de los equipos como Planning Poker, ya que toma mucho del dolor
de la estimación y en vez
lo convierte en un proceso sencillo y divertido. El mayor valor es realmente en
las conversaciones que se interponen
desencadenada durante la reproducción; la estimación en sí es sólo un efecto
secundario positivo ". (p. 129)
"[Un] organización estaba haciendo Scrum, pero estaba teniendo algunos
problemas. El diagrama de causa-efecto
que surgieron después de las entrevistas y talleres demostraron que no estaban
haciendo Scrum correctamente,
y esto estaba causando los problemas ". (p. 144)