dudasKen Schwaber dice que scrum funciona "Si tienes un equipo de ingenieros brillantes, que usan excelentes herramientas y prácticas de ingeniería, comprendiendo de arriba a abajo el ámbito tecnológico y del negocio, a los que no se les interrumpe, y tienen los recursos tecnológicos que necesitan.

¡Toma! ¡Así no sólo funciona scrum, sino cualquier metodología!

A ver si va a ser verdad que los buenos equipos no usan metodologías  (y que los malos, ni con ellas ;-)

 

 

dardosEsta fue una de las afirmaciones de Steve McConell, que ayer (1) defendió su postura ecléctica sobre los modelos de desarrollo de software en su intervención "10 Most Important Ideas in Software Development" en el congreso SD WEST2006 (Software Development Conference & Expo).
Su experiencia profesional combina el conocimiento teórico de la ingeniería del software, por su etapa como editor jefe y miembro de IEEE Computer Society, con la visión real de la industria del desarrolo por su puesto actual de Ingeniero Jefe de Construx Software.

Desde su planteamiento central de que diferentes tipos de software necesitan diferentes modelos de desarrollo, argumentó el error que supone plantearse si para nuestra industria lo conveniente es la perspectiva ágil o la basada en procesos.

Defensor del valor de las personas sobre los procesos, y del desarrollo incremental e iterativo sin embargo en su razonamiento ecléctico criticó el exceso de confianza en los modelos ágiles, "en los que inicialmente se había depositado un entusiasmo excesivo. Algo frecuente en las nuevas tecnologías, como ya ocurrió por ejemplo con las herramientas CASE."
Apuntó la contradicción que están demostrando los modelos ágiles cuyos valores teóricos son las personas y su interacción, y que sin embargo en la mayor parte utilizan procesos y tecnología.

En cuanto al resumen de su charla: ideas correctas, e ideas erróneas en el desarrollo de software, expuso los principios que recogen sus obras:

Algunas de las ideas correctas:

  • El software lo desarrollan personas, y su capacidad es un factor crítico.
  • El desarrollo incremental e iterativo es esencial.
  • El coste de arreglar defectos es mayor cuanto más avanzado está el desarrollo, independientemente de que el modelo sea ágil o no.
  • Diferentes tipos de software necesitan diferentes modelos de desarrollo.
  • Ya hay un cuerpo de conocimiento de la ingeniería del software (SWEBOK) con disciplinas como la gestión de la configuración, mantenimiento y pruebas.
  • No cree que SWEBOK sea la ultima palabra pero es un buen inicio.
  • La precisión de las estimaciones se puede mejorar con el tiempo.

Algunas de las ideas erróneas:

  • Sólo hay dos opciones para desarrollar software: iteración continua o modelo secuencial.
  • Con los modelos ágiles el coste de reparar errores no se incrementa al avanzar el desarrollo.
  • Los proyectos de desarrollo de software son problemáticos "per se".
  • Los cambios en los requisitos son inevitables.
  • Los requisitos no se "obtienen", basta tomarlos como maná caido del cielo.
  • Los proyectos empresariales no deben temer a los riesgos
  • Un buen modelo de desarrollo se puede aplicar a todos los proyectos.

Diapositivas de la presentación.

(1) Artículo publicado el 14 de marzo de 2006 en la versión anterior de navegápolis (navegapolis.net)

 

vendidoLos "CMMI's" cada vez se llevan menos. Tras 20 años de ayudar a las empresas de programación, no se sabe si a mejorar el software, o a licitar con ventaja en los concursos públicos, han perdido fuelle y terreno frente a la agilidad.

Así que ahora le toca al negocio de la consultoría renovarse, porque el asesorar con "CMMI's" se vende cada vez peor, y la agilidad es sin duda la nueva tendencia. Lo malo es que algunos, o bien no entienden lo que venden, o sólo les preocupa hacer el dibujo de un marco lo suficientemente creíble para engatusar a los clientes que se conforman con aparentar e ir a la moda.

 

agile for phbs

 

Así que van a convertir a la agilidad en otro modelo de procesos, porque gracias a su capacidad de marketing, van a ser muchas las empresas a las que les van a enseñar cómo deben organizar a los equipos autoorganizados, o a las que convencerán de que Scrum tan sólo es un ciclo iterativo que pueden implementar sin dejar de "embau-contratar" con clientes y administraciones como hasta ahora, porque su marco ágil funciona sin esa bobada de la colaboración estrecha entre cliente y desarrolladores, que sólo serviría para destapar información inconveniente, como que le están facturando 7 "recursos senior" y en su proyecto sólo hay dos becarios desmotivados.

Y de cosas como la autonomía y "empowerment" de los equipos, cultura ágil de la organización... mejor ni hablar.

 

coste laboralEl coste laboral está en relación directa con el salario: coste = salario, pero con un modificador importante: "valor que aporta la persona".

coste = salario / valor.

En la manufactura industrial, y demás trabajos que aplican ingeniería de procesos para garantizar la calidad del resultado,  y que la diferencia entre las personas no resulte significativa, al factor "valor" se le puede considerar una constante.
Además la ingeniería de procesos minimiza la pérdida de know how en la rotación de personal, así que si no escasean los "operarios" en el mercado laboral, se puede simplificar la fórmula y dejarla en "coste = salario", considerando más barato al que menos cobra.

Sin embargo, en la construcción de software, la diferencia de valor aportado entre los buenos y los mejores es enorme. Tan grande que resulta miope mirar al factor "salario" para reducir el coste.
Y por supuesto a los malos y mediocres, ni los considere. A ningún precio; porque disparan el coste al no aportar valor, o aportarlo negativo, porque degradan y complican el código tocan.

 

triadaEs posible que en determinados trabajos se necesiten personas con una de estas fortalezas:

Su capacidad de trabajo:
"Dame gente trabajadora, dispuesta a echar horas o fines de semana".

Su talento:
"No necesito gente para calentar la silla; quiero brain time, no body time".

O su nivel de compromiso:
"Quiero gente que sienta los colores, que se sienta empresa".

Sin embargo un equipo Scrum no funciona por su dedicación, talento o compromiso, sino por la combinación equilibrada de los tres. De hecho no es otro el motor de Scrum: gente capaz, comprometida y laboriosa, trabajando en equipo.

 

perfil equipo scrum

 

 

excipientes

Excipientes de Scrum

Gráficos burndown, estimación de póquer, product backlog, sprint backlog, formatos de historias de usuario, reuniones de pie, tableros visuales kanban etc.

Principios activos de Scrum:

  • Visión: El proyecto tiene un objetivo definido, conocido y asumido por todos los miembros.
  • Priorización: El criterio de prioridad del cliente define en cada momento las tareas inmediatas para avanzar hacia el objetivo.
  • Visibilidad: No hay información oculta y en las decisiones se tienen en cuenta las consideraciones y aportaciones del todo el equipo.
  • Competencia: Todos los miembros tienen la competencia profesional necesaria para aportar un trabajo valioso.
  • Respeto: Todos los miembros dan y reciben respeto y valoración.
  • Compromiso: Las personas no anteponen sus intereses propios a los del equipo.
  • Confianza: Todo el equipo tiene confianza real en el desempeño, valor y compromiso de los demás.
  • Coraje: Todos los miembros y el equipo en su conjunto hace frente con decisión y solvencia a las situaciones adversas.
  • Responsabilidad: Cada persona tiene el margen de acutación y decisión necesario para su aportación al proyecto y es responsable de sus decisiones, acciones y omisiones.
  • Ritmo: El desarrollo se realiza con una cadencia de avance objetivo continuo y sostenible.
  • Retroalimentación: De forma periódica el equipo analiza su forma de trabajo y toma decisiones de mejora.

La mejora que cabe esperar al emplear prácticas Scrum un equipo sin principios ágiles es la propia de un placebo.

 

Gestión de proyectos predictiva - evolutiva (cascada - agilidad)