scrum 4 software originalScrum es el término dado por Nonaka y Takeuchi al método de desarrollo de nuevos productos realizado con equipos reducidos, multidisciplinares, trabajando con comunicación directa y empleando ingeniería concurrente, en lugar de ciclos o fases secuenciales.

Este marco de de trabajo logra niveles de eficiencia y valor en el producto superiores a los obtenidos con ingeniería secuencial y producción basada en procesos. En los 80, Nonaka y Takeuchi analizaron esta forma de producción, observando a los equipos de empresas tecnológicas que lograban mayores niveles de eficiencia y valor en sus productos ("New New Product Development Game"): Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard.

Diez años más tarde Ken Schwaber presentó en OOPSLA (1995) la descripción de un marco para implementar Scrum en el desarrollo de Delphi, en el que él trabajaba.

Las prácticas para aplicar Scrum en proyectos de software se vienen enriquecendo desde entonces, y poco tienen que ver las implementaciones actuales con la original de Ken. Ahora es muy raro que un equipo use Scrum con los controles originales (paquetes, cambios, riesgos, soluciones...) el Backlog único ha evolucionado a Backlog de producto y Backlog de Sprint. También es habitual usar un backlog estratégico o "Epics" de producto. La evolución añadió a la reunión de revisión de sprint, otra de inicio; y más tarde otra de retrospectiva. Tampoco se suele usar la fase de cierre, etc.

También la prácticas se han enriquecido. En 2001 apareció el gráfico burndown, más tarde empezó a ser habitual el uso de estimación de póker, luego tableros de control visual kanban...

Para tener una visión de retrospectiva, este es el "paper" de Ken Schwaber presentado en 1995 su implementación de Scrum en OOPSLA: "SCRUM Development Process " y este otro su artículo del mismo año "Living on the Edge" en el que describía su implementación de Scrum para Software.

Un adelanto de la "metodología" y su fases:

Los primeros en observar diferentes implementaciones de SCRUM para el desarrollo de nuevos productos con alto rendimiento fueron Takeuchi y Nonaka (1) en Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, y Hewlett-Packard.
Coplien ha seguido y documentado un enfoque similar para el desarrollo de software en Borland, logrando la mayor productividad con C++ (1). Recientemente, Jeff Sutherland ha aplicado un enfoque más refinado de SCRUM en Smaltalk, y Schwaber en el desarrollo de Delphi.
...
Llamamos a este enfoque metodología SCRUM (véase Takeuchi y Nonaka, 1986) por el uso del término SCRUM en rugby –la formación cerrada que forman los delanteros para realizar el avance-
...
Scrum es una metodología para mejora y mantenimiento de un sistema existente o la producción de un prototipo. Se asume la existencia de diseño y código en su mayor parte orientado a objetos, basado en librerías y clases. SCRUM gestionará la reingeniería completa posterior de sistemas heredados.
.....

FASES DE SCRUM

SCRUM comprende las siguientes fases:

1.- Pre-juego

Planificación: Definición de una nueva versión basada en la pila actual, junto con una estimación de coste y agenda. Si se trata de un nuevo sistema, esta fase abarca tanto la visión como el análisis. Si se trata de la mejora de un sistema existente comprende un análisis de alcance más limitado.
Arquitectura: Diseño de la implementación de las funcionalidades de la pila. Esta fase incluye la modificación de la arquitectura y diseño generales.

2.- Juego

Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con respeto continuo a las variables de tiempo, requisitos, costo y competencia. La interacción con estas variables define el final de esta fase. El sistema va evolucionando a través de múltiples iteraciones de desarrollo o sprints.

3.- Post-juego

Preparación para el lanzamiento de la versión, incluyendo la documentación final y pruebas antes del lanzamiento de la versión.

 

scrum 4 software original 1

 

herramienta scrumLa agilidad sólo tiene un factor imprescindible; uno sin el cual no es agilidad, y sin embargo es muy habitual centrar la atención y la formación en lo accesorio.

 

personas sobre procesos y herramientas

(Publicado originalmente en navegapolis.net el 26 de sept. de 2010)

 

huiAlgunas empresas deben a los procesos y la tecnología su "saber hacer". La maquinaria y los procedimientos se encargan de elaborar los productos con el menor número de operarios posible, y que aquellos sean de buena calidad, a pesar de estos.

La cultura empresarial no preocupa mucho, porque a los procedimientos y a las máquinas no les afecta, y como de las personas sólo interesa que las atiendan siguiendo los procedimientos, basta con que la cultura garantice la ausencia de huelgas y sabotajes.

Sin embargo, otras empresas deben su "saber hacer" a las personas. En ellas las máquinas y los procedimientos ayudan a los humanos, y no al revés; y como las personas son de sicología complicadas, resulta que el talento, aunque lo tengan, no lo pueden desarrollar si no se encuentran motivados. En estas empresas la cultura es una variable muy relevante, porque las culturas tóxicas atrofian o espantan al talento.

 

cultura

 

Resulta visual y acertada la simplificación de las posibles culturas de empresa posibles del artículo What Holds the Mordern Company Toghether (Rob Goffee, Gareth Jones, 1996). Desde su perspectiva, éstas son resultado de la combinación en mayor o menor medida de dos dimensiones: sociabilidad y solidaridad.

Tomando a la sociabilidad como el grado de relación emocional y no insturmental (que no es un simple medio de satisfacer las propias necesidades) que existe entre las personas. Las relaciones de amistad son relaciones de sociabilidad elevada.
Y tomando por solidaridad a la actitud del equipo en el que prima el enfoque estratégico, la reacción contra la amenaza de los competidores y la intolerancia al bajo rendimiento.

Con estas premisas, la cultura ideal es la comunal al combina ambas dimensiones, porque aunque podría parecer que con dosis elevadas de sociabilidad bastaría, la sociabilidad alta, con ausencia de solidaridad tiene inconvenientes, porque el predominio de la amistad puede tolerar rendimientos bajos.

Cuando el nivel de sociabilidad es mucho mayor que el de solidaridad, el trabajo se resuelve con el mejor "compromiso" no con la mejor "solución"; y también es frecuente el desarrollo de camarillas y redes informales que burlan y pueden socavar la institucionalización de procedimientos en la empresa.

 

cultura

 

"Estamos poniendo al descubierto mejores métodos para desarrollar software, haciendo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

A los individuos y su interacción, por encima de los procesos y las herramientas."

2001, Manifiesto Ágil

 

Este artículo se publico originalmente en navegapolis.net el 23 de septiembre de 2007

errorLos modelos de evaluación y mejora de procesos se basan en el principio "La calidad del sistema, o del producto depende principalmente de la calidad de los procesos empleados para su desarrollo".

Por ejemplo, CMMI identifica 25 áreas clave de procesos con objetivos y prácticas que determinan cómo de bien se está haciendo el producto: el software.

De esta forma, garantizar la integridad de los fuentes, y controlar adecuadamente las versiones de todos los documentos, librerías y demás elementos de la configuración es una de las 25 áreas de procesos.

Sin duda se pueden diseñar procesos y tecnología que garanticen la calidad cuando de producción industrial se trata, pero ¿también para construir diseños de arquitecturas ingeniosos e implementaciones inteligentes?

Cuando la eficiencia no consiste en producir más líneas de código en menos tiempo, sino en diseñar arquitecturas simples, robustas y escalables, ¿también se puede mejorar la eficiencia mejorando los procesos?

La innovación, los diseños de las arquitecturas y las estrategias de solución deben su valor a las personas, no a los procesos.

Las organizaciones que desarrollan software para sistemas novedosos o para sectores de mercado de cambios rápidos o bases tecnológicas inestables pueden mejorar su valor y eficiencia a través de los procesos en el porcentaje que sea, pero si buscan la excelencia, no en los procesos sino en el talento de personas motivadas, dispararán esos mismos valores.

Las organizaciones de software que dan soluciones a entornos de problemas bien conocidos, que necesitan poca innovación, que desarrollan sistemas con niveles altos de integridad, que trabajan en sistemas que pueden definirse con detalle desde el primer día, y sobre bases tecnológicas más contrastadas y estables, pueden aprovechar mucho mejor las ventajas de mejora, repetibilidad y escalabilidad que dan los modelos de mejora basados en procesos.

(publicado el 3.08.2006 en navegapolis.net)

 

 

 

agua aceiteCombinar la agilidad con un modelo de procesos puede ser una estrategia o un contrasentido; una táctica razonada y razonable, o el disparate de un gestor engañado.

Los modelos de procesos como CMMI, ISO 15504, o Spice (que fue la versión beta de éste último) se fundamentan en la teoría sobre calidad y eficiencia desarrollada en la manufactura industrial, donde los protagonistas y responsables del saber hacer y de la calidad son los procesos; y donde las personas son recursos necesarios para asistir a éstos.

"La industria manufacturera ha reconocido la importancia de la efectividad de los procesos y la eficiencia. Hoy en día, muchas organizaciones en el sector manufacturero y de servicios a reconocer la importancia de los procesos de calidad"...

En la década de 1930, Walter Shewhart comenzó a trabajar en la mejora de procesos con sus principios de control estadístico de calidad [Shewhart 1931]. Estos principios fueron refinados por W. Edwards Deming [Deming 1986], Philip Crosby [Crosby 1979], y Joseph Juran [Juran, 1988]. Watts Humphrey, Ron Radice, y otros extendido estos principios aún más y comenzó a aplicar a software en su trabajo en IBM y el SEI [Humphrey, 1989].
SEI ha tomado la premisa de la gestión sobre procesos, "la calidad de un sistema o producto es sobre todo consecuencia de de la calidad del proceso utilizado para su desarrollo y mantenimiento", y CMM se desarrolla sobre esta premisa. La creencia en esta premisa es compartida en todo el mundo por los movimientos de calidad, como lo demuestra la Comisión Electrotécnica Internacional (ISO / IEC) de la Organización Internacional de Normalización ISO..."

CMMI DEV 1.2, pág. 16


Las prácticas ágiles son exactamente lo contrario: métodos de trabajo que ayudan a los personas, que son quienes tienen el  know how y los responsables de la calidad.

"Preferimos el valor de las personas y su interacción al de los procesos y las herramientas"

Manifiesto ágil.

Hay empresas o departamentos que integran o mantienen sistemas, o que realizan tareas en las que quizá se puede explicitar en procesos el conocimiento necesario en un... ¿60, 70, 80%?.

En otros casos ocurre lo contrario.

Para no disparatar el modelo de producción conviene saber en qué caso se está, y no caer en la tentación de mezclar agua y aceite. Los dos principios a la vez, no son posibles. Sí lo es sin embargo una síntesis del conocimiento de ambos; y cuando se trata de una empresa ágil, que no busca también una evaluacion CMMI sino el conocimiento útil que de él puede emplear, este quizá sea un buen consejo:

Tomar las metas y prácticas globales de CMMI, pero olvidarse de aplicarlas a las áreas de procesos, y aplicarlas a las prácticas ágiles que emplean, porque CMMI cubre algo que las prácticas ágiles no abordan: la institucionalización y homogeneización de la forma de trabajo. Algo que llevan a cabo las metas y prácticas globales.

Se trataría de aplicar procesos para la homogeneidad en organización, la formación de las personas y la mejora de las prácticas y agilidad para la producción.

(Publicado el 29 del 11 de 2009 en navegapolis.net)

 

 

envejecido"La empresa empieza a contratar MBAs y ejecutivos con marchamo blue-chip. Empiezan a brotar, como las malas hierbas, los procesos, procedimientos, listas de control, etc. Sobre el inicial entorno igualitario se va construyendo una rígida jerarquia. Se crea orden en el caos, pero también se mata el espíritu emprendedor. Nace la burocracia para compensar la incompetencia y establecer la disciplina".

Jim Highsmith, Agile Project Management

 

(Publicado el 16.05.2008) en navegapolis.net

 

 

zapatonesSi en su empresa o en sus proyectos no trabajan más de 25 personas, y está pensando implantar modelos de procesos tipo CMMI o ISO 15504, le interesa mucho conocer las conclusiones a las que está llegando el comité ISO de estandarización para la Ingeniería del software (ISO/IEC JTC1 SC7):

"La industria del software reconoce la valiosa contribución de los productos y servicios aportados por las pequeñas empresas. Los estándares internacionales ISO no se han escrito para pequeños proyectos, organizaciones o empresas con menos de 25 personas".

En la actualidad el sub-comité SCT7 está trabajando para proporcionar a este tipo de proyectos y de empresas, versiones equivalentes adecuadas para ellos con los principios de los cuatro estándares actuales más importantes: ISO12207, ISO15288, ISO15504 (compatible con el modelo de mejora CMMI), ISO 9000-3.

El proyecto tiene como objetivo desarrollar normas que requieran poco esfuerzo de formación y adaptación y resulten adecuadas a los proyectos y empresas pequeñas, para hacer accesibles en ellas los estándares de la Ingeniería del Software. Los desarrollos serán armónicos y estarán alineados con los principales estándares ya definidos, así como con los principios de madurez de las normas ISO 15504 o CMMI.
La agenda del comité ISO prevé tener la propuesta de ciclo de vida del software para pequeñas empresas, preparada para pasar a la fase de aprobación como estándar internacional en noviembre de 2007.

Hace ya algún tiempo empecé a guiarme por mis propias conclusiones sobre los modelos de calidad, las técnicas ágiles, la gestión de los proyectos; y viendo por un lado las tendencias ágiles en busca del equilibrio entre agilidad y disciplina; y por otro que ISO trabaja en proyectos como este, creo que no estoy tan loco.

(Artículo publicado el 28 de agosto de 2006 en navegapolis.net)