kanbanUn tablero kanban es una herramienta para mostrar la situación de trabajos previstos y los que están en curso. La gestión ágil y el desarrollo evolutivo de proyectos TIC usan tableros kanban  para gestionar visualmente un flujo de tareas continuo, sin atascos ni tiempos muertos (o al menos para intentarlo ;-)
 
En foros de gestión ágil,  compañeros habituales del término kanban son: lean y wip, ambos como "claves" para su funcionamiento. También es muy frecuente la relación con  la filosofía "start-up" y su concepto de "mínimo producto viable" por el que los clientes o los gestores de producto deben priorizar los trabajos que necesitan para, con los recursos de que disponen, desarrollar el mayor valor de producto en el menor tiempo.
 
A modo de mapa de situación de las relaciones entre kanban, lean, WIP, priorización de tareas y la teoría de gestión de colas, he preparado esta infografía con la que actualizar los apuntes de Ingeniería del Software, ahora que me vuelve a invitar CESTE a retomar las clases.
 
La comparto aquí para todos los que os pueda servir.
 
Kanban, claves para la mejora del flujo
 

 

Safe Creative #1312089540117

 

criticasSon muchas las críticas que argumentan que la ingeniería del software se asienta sobre bases y conceptos erróneos. En algunas se afirma incluso que el desarrollo de software no se sujeta a los principios científicos y rigurosos, propios de las ingenierías.

Este artículo es una versión modificada del publicado en wikipedia "Criticism of software engineering" , y recoge la relación de críticas más frecuentes hacia la ingeniería del software; acompañadas de sus correspondientes reflexiones.
El espíritu de muchas de ellas es común a otras actividades humanas.

Gestión de las expectativas

crítica
La ingeniería del software considera transcendental para el éxito de sus proyectos, satisfacer las expectativas del cliente relativas al resultado y a las fechas de entrega. Por esta razón se parece más a la sicología o al marketing, y no a una ingeniería tradicional con regulación legal de responsabilidades por incumplimiento de intereses generales para la sociedad o para sus clientes.

Respuesta
Todas las profesiones e ingenierías gestionan expectativas. De hecho el concepto de responsabilidad frente a intereses generales de la sociedad implica la satisfacción de las expectativas de quienes en mayor o menor medida resultan implicados por los proyectos de ingeniería.

Requisitos deficientes

Crítica
La mayoría de los proyectos de ingeniería del software tienen requisitos incompletos o inconsistentes. Unas veces se debe a la poca experiencia de los clientes para especificar requisitos. Otras a que no saben bien qué es lo que necesitan y se limitan a decir "Lo sabré cuando lo vea". Incluso los clientes que conocen qué es exactamente lo que quieren encuentran difícil expresarlo en forma de requisitos.
Además de estas dificultades suele ser normal que los clientes esperen más de lo que han expresado, o que los documentos de requisitos describan aplicaciones sin una solución práctica informatizable.

Respuesta
El nivel de certidumbre que se puede obtener de la visión final de un sistema al comenzar su construcción varía en función de sus características: sistemas novedosos sin antecedentes similares previos, sistemas para integrarse en dispositivos de hardware, sistemas para realizar operaciones en negocios veteranos y conocidos o novedosos y sin experiencia previa por parte de los clientes, etc.

Optar por evitar todos los proyectos con requisitos deficientes o difíciles, o por aplicar siempre técnicas de prototipado y desarrollo ágil, o sus contrarias de no comenzar a trabajar hasta tener definido el sistema no son soluciones válidas.
La aplicación de metodologías de ingeniería de requisitos preventiva, o de desarrollo ágil reactivo debe decidirse según las características de cada proyecto.

DispararEste artículo es una traducción autorizada del post "I Killed The Scrum Master (And Why He Had It Coming) de Daniel Markham publicado el pasado jueves, 24 de octubre en Tiny Giant Books, y al que desde aquí agradezco el permiso y la disposición para publicarlo en Navegápolis.

Por qué maté al Scrum Master

Ayer me preguntaba un cliente cómo podía mejorar un equipo que ya estaba trabajando muy bien. No lo tuve que pensar dos veces, vi la respuesta inmediatamente:

"Desazte del ScrumMaster"

¿Por qué?. ¿Lo estaba haciendo mal el ScrumMaster?. No. Su ScrumMaster es muy bueno. 
¿Se está confundiendo al SM con uin gestor de proyectos?. Quizá un poco, pero no más de lo habitual.

Tras haber visto decenas o cientos de equipos intentando lograr niveles altos de scrum y agilidad, sigo viendo una cosa: a una persona especial que sólo se ocupa de las tareas del ScrumMaster. Es como si tuviéramos en el equipo a alguien que sólo trabaja con bases de datos, o a una persona encargada sólo del interfaz de usuario. Es algo que simplemente no encaja en un equipo autónomo. Peor aún, es algo que genera una barrera entre los desarrolladores y el resto de la organización.
No era un rol destinado a producir eso, pero lo hace.

Siempre he pensado que el papel del SM debe rotar entre los miembros del equipo, y cuantos más equipos scrum conozco, más me reafirmo.
Veo que está surgiendo una industria en torno a "ser un líder de su equipo" y lo que está transmitiendo es claro: el SM es un líder, un perro pastor, un facilitador del que se espera un don de gentes especial.

En otras palabras, el ScrumMaster es sólo la versión del siglo 21 del gestor del proyecto.

introvertidoJung descubrió que las diferencias de personalidad entre las personas pueden clasificarse en patrones que afloran en la infancia se modelan durante la vida.
Partiendo de la obra de Jung "Tipos psicológicos", Katharine Briggs y su hija Isabel Briggs Myers dedicaron 30 años al estudio de la personalidad y al desarrollo de un método para la clasificación y medición de los diferentes patrones.
El resultado es el indicador de tipos Myers-Briggs (MBTI), uno de los modelos de clasificación y medición de la personalidad más utilizados.
Este indicador clasifica la personalidad según cuatro dimensiones básicas, con grados distintos según el nivel en cada una:

mbti1


Combinando los ocho caracteres resultantes de estas cuatro escalas, se generan 16 posibles tipos psicológicos de personalidad:

mbti2


En cada uno de los 16 tipos, las diferencias de grado en cada factor multiplica las combinaciones posibles. 

Estas son las cuatro dicotomías básicas que definen el tipo de estrategia conductual al que tiende cada persona:

E-I Grado de vivencia hacia el exterior (E) o hacia el interior (I) de la persona
S-N Grado de atención que la persona presta a la realidad que ve y toca (S) y a la intuición (N)
T-S En qué grado basa las decisiones en el pensamiento (T) o en los sentimientos (F)
J-P En qué grado el estilo de vida tiende hacia el análisis y el juicio (J) o hacia la percepción (P)



Sin duda esta es una visión tan genérica del modelo MBTI, que con toda razón cualquier sicólogo la tacharía de simplista, pero nos sirve de marco para situar los datos que ofrece Steve Mc Conell en su libro "Professional Software Development" donde recoge (capítulo Orphans Preferred) el resultado de dos estudios exhaustivos realizados por Rob Thomsett y Michael L. Lyons al mostrar que mientras que el 6% de la población se casifica en el tipo ISTJ (Introvertido, Sensorial, Racional, Calificador) entre los programadores el porcentaje llega a alcanzar el 40%. 

Parece ser cierto que los programadores son más introvertidos que el resto de las personas. La media general es del 25%, mientras que entre los programadores el porcentaje pasa del 50% llegando hasta el 75%. 
También hay una diferencia muy marcada en el factor "Racional - Emocional", particularmente importante por la gran influencia que tiene en el estilo de toma de decisiones. Entre el 80 y el 90% de los desarrolladores predomina la componente sensorial sobre la intuición, mientras que en la media de la población es del 50%. 

La diferencia entre la personalidad habitual de los programadores y la de sus jefes puede ayudar para explicar algunos de los motivos de la falta o dificultad de comunicación  entre ellos, y el que los jefes intenten motivar a los programadores en la misma forma que a ellos les gustaría.  
A los programadores les motiva participar en las planificaciones y trabajar sobre agendas que conocen y tienen una base lógica y razonada. Las fechas y compromisos cuya planificación y lógica desconocen y consideran irreal, no funcionan como "retos ilusionanes para su carrera", sino como desmotivadores. 

A los programadores, en general, les preocupa menos la responsabilidad o el reconocimiento y más los estímulos técnicos, la autonomía, la posibilidad de aprender, usar nuevas técnicas, participar en la planificación y el respeto a sus vidas privadas.

prototipoEs difícil hoy pensar en un nuevo producto o servicio que no incorpore software para su funcionamiento, o para servicios colaterales, de marketing u otros. Así por ejemplo, son habituales los productos que tienen una app. asociada.

Los clientes de estos nuevos proyectos de software son cada vez más exigentes en términos de personalización, captura de las necesidades del usuario, innovación del producto, lanzamiento rápido al mercado e incorporación continua y rápida de cambios.

El marco de desarrollo ágil Scrum, en su configuración estándar da respuesta a las necesidades de lanzamiento rápido e incremento continuo centrándose en el ámbito del software, pero presta un nivel de atención somero al área de requisitos.

Para productos donde diseño y concepto son foco de atención primordial para el cliente, y para los que se requiere por parte de todo el equipo conocimiento y comprensión profunda  del dominio del problema, usar el marco "pelado" de Scrum, sin personalizar se queda corto.

Para personalizarlo en una configuración más apropiada a los productos y servicios de requisitos complejos o críticos en diseño y concepto,  la Universidad St. Gallen, a instancias de SAP y con la colaboración del departamento de Ingeniería de Sistemas de Hasso-Plattner-Institut  ha desarrollado la propuesta "Jumpstarting Scrum with Design Thinking"  

scrum dt


Como apunta el título del estudio, el refuerzo al marco estándar de Scrum en el área de atención a las necesidades del cliente, lo aporta la incorporación de la estrategia ágil de requisitos "Design Thinking", que en los últimos años se está consolidnado como metodología eficaz para concebir productos innovadores y que resulta especialmente apropiada en marcos ágiles por su concepto de evolución iterativa y centrada en el usuario. Es la aproximación empleada por empresas como Google, Microsoft o SAP (1)

En esta página han publicado la información y el documento técnico(2) en el que lo explican:Jumpstarting Scrum with Design Thinking.(3)

dod agilEl Departamento de Defensa de los Estados Unidos (DoD) está desarrollando un proceso "ágil" para la adquisición de Sistemas de Tecnologías de la Información. 

Este es el informe(1) en el que pide al Senado autorización para emprender el desarrollo, por los cambios legislativos (aparte de los procedimentales) que implicará en el modelo de contratación pública  con el Departamento de Defensa.

Y estos los 5 puntos que deben inspirar el resultado (pág. 4)
  1. Entrega temprana y frecuente.
  2. Desarrollo y pruebas incrementales e iterativas.
  3. Racionalización e implicación de los usuarios en los requisitos.
  4. Procesos flexibles y adaptados.
  5. Plantillas de programadores profesionales y expertos.
Como se menciona en el informe, para adoptar las prácticas que cada vez resultan más habituales en el sector de las Tecnologías de la Información van a desarrollar un proceso de adquisición iterativo e incremental en ciclos de tiempo prefijado (time-boxing)
...
direccion unicaEn el último viaje a San Francisco pude conocer a programadores de Google, de Apple y de proyectos más modestos. Todos tenían en común estas dos cosas: 

  1. Su forma de trabajar las prácticas y métodos dan forma a principios ágiles: trabajan con una visión conocida y compartida por todo el equipo que van dibujando y mejorando de forma continua o a través de iteraciones cortas. 
  2. Pasan de metodologías y dogmas ágiles.

Centrarse en las prácticas ágiles y no el fondo es como esforzarse en la caligrafía para lograr buenas novelas, o como fijarse en el dedo en lugar de la luna a la que señala. La agilidad sin flexibilidad es un dogma paradógico: definir las prácticas de gestión de los equipos "autoorganizados" (?). Es como aquello del "prohibido prohibir"

Me recuerda las conclusiones de Jared M. Spool en su conferencia de edui 2009:

  • Los mejores equipos no tienen una metodología ni siguen un dogma.
  • Los equipos con problemas a menudo intentan seguir una metodología, sin éxito.
  • Los mejores equipos exploran nuevas técnicas de trabajo de forma continua.
  • Los equipos con problemas tienen un repertorio de técnicas fijo y limitado.
Vídeo de la conferencia de Jared M Spool: Gourmet User Experience of Fast Food Budget.


(1) Artículo migrado de la versión anterior de navegápolis (navegapolis.net). Publicado originalmente el 16 de Enero de 2011