estrellaComo cada proyecto, y cada empresa es diferente, éstos son cinco factores importantes para decidir si abordarlos con principios ágiles, o siguiendo modelos de procesos y planificación:

  • ¿Cuál es el nivel de estabilidad de los requisitos?. ¿Se esperan pocos cambios, o serán la tónica habitual?
  • ¿Cuál es el nivel de criticidad del proyecto? ¿Qué clases de pérdidas pueden producir los errores en su desarrollo: vidas, bienes materiales o funcionalidad para los usuarios? ¿Se trata del sistema de software para regular el núcleo de una central atómica, o para gestionar una agenda infantil?
  • ¿Cuál es el tamaño del equipo de desarrollo: 4 ó 40 personas?
  • ¿Cuál el porcentaje de técnicos competentes y expertos frente al de principiantes y menos duchos?
  • ¿Cuál es la cultura de la organización?. ¿Jerarquizada, de funciones delimitadas y procedimentadas, o por el contrario se trata de una cultura de autonomía, y multifuncionalidad?

estrella b t

Estas son las 5 puntas del gráfico propuesta por: Barry Boehm y Richard Turner. (1)

Si la estrella no te sale muy simétrica, si quizá se trata de desarrollar el sistema de asistencia al pilotaje de un avión, con un equipo de tres programadores junior.... igual estás buscando la cuadratura del círculo,  y ni los modelos ágiles ni los basados en procesos puedan ser de gran ayuda ;-)

(1) Boehm B. & Turner R (2002) Balancing Agility and Discipline (pág. 160) Boston:  Addison-Wesley

 

portadaHe cerrado una nueva revisión de este libro que empezó hace algunos años como recopilación de apuntes y artículos sobre scrum.

A ver si Iteración a iteración vamos a acabar haciendo de esto un libro :-)

A todos los que lo habéis leído, muchas gracias y disculpas por las erratas que me sonrojan al descubrirlas en cada revisión. Así que tirad la  anterior, y cambiadla por esta ;-) Y a los que no lo tuviérais y os pueda interesar, espero que os guste y sobre todo que os resulte útil.

Descargar: Gestión de proyectos Scrum Manager v 2.5

// Actualización Julio 2016 //

 

 

 

no prohibirHas aprendido a avanzar en scrum cuando sabes romper las reglas.

 

NIVELES DE

SCRUM

   

1.- Reglas

2.- Valores

Ken schwaber & Jeff Sutherland Nonaka & Takeuchi
Marco de reglas para desarrollo de software.
Autores: Ken Schwaber y Jeff Sutherland
(Origen: "Scrum Development Process OOPSLA'95" 1995)
Concepto original Scrum.
Autores: Hirotaka Takeuchi e Ikujiro Nonaka
(Origen: "The New New Product Development Game" 1986)
   

Reglas definidas

Valores ágiles...

   
Roles
  • Dueño de producto
  • Equipo de desarrollo
  • Scrum Master
Eventos
  • Sprint
  • Reunión de planificación
  • Scrum diario
  • Revisión de sprint
  • Retrospectiva de sprint
Artefactos
  • Pila de producto
  • Pila de sprint
  • Incremento
  • Personas > procesos
  • Resultado > documentación
  • Colaboración > negociación
  • Cambio > planificación

... "Para avanzar en Scrum"

  • Incertidumbre
  • Autoorganización
  • Fases de desarrollo solapadas
  • "Mutiaprendizaje"
  • Control sutil
  • Difusión del conocimiento
   
Scrum técnico Scrum pragmático
   
Scrum técnico Scrum
Para avanzar guiados por reglas Para avanzar en scrum, sin reglas.
Equipos autoorganizados asesorados por un Scrum Master Equipos autoorganizados sin Scrum Master

ÉticaLa "ética empresarial" es cuestionable cuando se antepone el beneficio propio al del cliente.

Para medir la ética de mis comportamientos no tengo que mirar los beneficios que me producen, sino los que producen en los demás.

La ética empresarial no se muestra con palabras, sino con los beneficios que la actividad de la empresa genera en los demás. La ética es esencialmente altruista, y las empresas éticas deberían responder más a motivaciones altruistas que egoístas.

En una empresa ética el beneficio propio es una consecuencia de su actuación para garantizar la continuidad de su trabajo, pero no es su fin. Su fin es el beneficio de sus clientes, trabajadores y la sociedad en general.

Quizá un criterio para determinar el nivel ético de la empresa pudiera ser saldo "green" y "commons" que produce esa empresa en el sistema: si es positivo o negativo y en qué proporción.

Post relacionado: ¿Cuál es la finalidad de las empresas?

Pepe Gotera y Otilio

Este fragmento de código prueba la afirmación de que la diferencia entre los promedios y los mejores, en programación no es 1:2 como en otros trabajos, sino 1:100 (Nathan Myhrvod)

Es un trabajo real escrito por un programador para hacer una función que comprueba la validez de una fecha, en un programa desarrollado con Visual Basic.

¿Hubiera sido muy diferente el resultado si lo hubiera realizado otra persona?

Otra persona podría haber empleado directamente la función que incorpora Visual Basic precisamente para calcular la validez de una fecha: IsDate()

Esta segunda persona no hubiera invertido un día de trabajo, sino medio minuto.

La función que se entregó al al cliente tiene 2 errores: considera como fechas válidas las cadenas vacías y comprueba mal los años bisiestos. La función que podría haber hecho otro programador (la de los 30 segundos) no tendría errores.

En una empresa de consultoría, de las que basan los resultados en modelos de procesos y emplean métricas formales para medir la eficiencia de los programadores (ej. procesos CMMI con métricas PSP) el primer programador tendría un volumen de trabajo de 110 líneas de código, mientras que el segundo sólo tendría una, por lo que es muy probable que el primero pudiera ofrecer mejores registros de eficiencia en su ficha profesional, del mismo modo que con un criterio similar de medición, Corín Tellado daría mejor foto como escritora que Camilo José Cela.

libroCeste me ha invitado de nuevo a impartir clases de Ingeniería del Software. He recopilado ejercicios y apuntes para las clases que comenzaron el mes pasado. Dejo aquí para quien pueda resultar útil, el fichero que resume en 650 diapositivas los temas que incluyen:

  • Introducción a la ingeniería del software
  • Gestión de proyectos predictiva
  • Producción basada en procesos
  • Ingeniería de procesos de software
  • Modelo de procesos CMMI
  • Modelo de procesos ISO IEC 15504
  • Ciclo de vida del software
  • Ciclos de desarrollo y patrones de gestión de proyectos
  • Los requisitos del software
  • Diseño del software
  • Documentación de usuario
  • Verificación y validación
  • Mantenimiento
  • Gestión de la configuración
  • Agilidad
  • Conocimiento
  • Síntesis entre procesos y agilidad
  • Scrum
  • Kanban
  • Gestión en organizaciones ágiles

Descargar "Compendio de Ingeniería del software" (rev. 0,9)

encajarEl Instituto de Ingeniería del Software americano (SEI) empezó  en los 90 el desarrollo de los modelos de procesos de la familia de CMM para ayudar a que los proveedores de sistemas de software para el Departamento de Defensa de los Estados Unidos cumplieran con de las condiciones de adquisición, principalmente: calidad, costes y fechas.

Al ser la norma que debían alcanzar las grandes suministradoras de soft del ejército americano, los CMMI's se convirtieron a principios de los 2.000 en el "vestido" con el que las software factory también se querían mostrar, para parecerse a las grandes.

Pero quizá porque muchas empresas de soft están empezando ya a pasar de tanto CMMI, y prefieren trabajar con métodos ágiles, SEI se acaba de publicar las primeras notas técnicas para ayudar al Departamento de Defensa a contratar con esas empresas tan tercas ;-)

Pueden ser información de referencia útil si se necesitan encajar procedimientos de contratación pesados con empresas de programación ágil.

Cito los dos párrafos siguientes de la nota "Agile Metrics: Progress Monitoring of Agile Contractors" que describen muy bien su objetivo y contenido:

"Esta es una de las notas técnicas publicadas por el Instituto de Ingeniería de Software destinadas a la ayuda de los profesionales del Departamento de Defensa de Estados Unidos encargados de la adquisición con proveedores que utilizan métodos ágiles de desarrollo de software. Estos profesionales de apoyo a la adquisición y mantenimiento de los sistemas de software están siendo testigos de cómo una gran parte de la industria se aleja de los llamados procesos de ciclo de vida "de cascada tradicional". La infraestructura existente apoyar el trabajo de los profesionales de adquisición ha sido moldeada por la experiencia de la industria, que hasta hace poco ha tendido a seguir un proceso de cascada. La industria está encontrando que los métodos orientados a los procesos del ciclo de vida heredados necesitan realinearse con las nuevas formas de hacer negocios." ...


... "Estos individuos suelen tener formación y experiencia en gestión de proyectos, y conocen bien las normas y reglamentos que rigen el proceso de adquisición. Sin embargo , muchos de estos profesionales cualificados no están familiarizados con los métodos de desarrollo ágil . Como muestra el gráfico de abajo, estos profesionales se encuentran a veces en el medio - entre un proveedor innovador y un conjunto arraigado de expectativas que deben ser satisfechas . Las conexiones entre las nuevas formas de trabajo y las viejas formas de hacer negocios pueden no son fáciles".

dod agile

"En la Sección 2, Fundamentos de métricas ágiles, ofrecemos una breve introducción a los métodos ágiles, comparándolos con los métodos tradicionales para ayudar al lector a comprender las restantes secciones del informe.
En la Sección 3, Consideraciones de medición seleccionadas en el Departamento de Defensa de Adquisición, se describe el contexto normativo en el que se deben implementar las métricas ágiles, junto con una lista de categorías de indicadores que habrá que tener en cuenta.
En la Sección 4, Métricas ágiles, se discuten las métricas empleadas específicamente por los métodos ágiles, ilustrando con ejemplos, los indicadores que normalmente utilizan los equipos de desarrollo ágil.
En la Sección 5, Seguimiento del avance de la adquisición usando métodos ágiles , ofrecemos un análisis detallado de las métricas utilizadas para monitorizar el trabajo en curso de los equipos de desarrollo ágil."

Información y descarga: