Reproduzco a continuación un artículo recién publicado por Robert C. Martin.
Me ha gustado tanto que me he lanzado a traducirlo como un poseso, espero que lo disfrutéis.
En 1971 un ingeniero de software llamado Winston W. Royce escribió un artículo fundamental titulado Gestionando el Desarrollo de Grandes Sistemas de Software. Este artículo describía el proceso de software que Royce consideraba apropiado para sistemas a gran escala. Como diseñador para la industria aeroespacial, estaba perfectamente cualificado.
Comenzó el artículo describiendo un proceso “de paja” para luego derribarlo. Describió este inocente proceso como “grandioso”. Lo describió con un diagrama sencillo en una de las primeras páginas de su artículo. Y el artículo procedió entonces a destrozar metódicamente este “grandioso” proceso. Finalmente, Royce propuso una aproximación mucho más clarividente y matizada, dejando que el lector se riera de la estupidez del modelo “grandioso”.
El artículo fue un éxito instantáneo. Fue citado en muchos otros artículos , incluyendo documentos de varios importantes procesos en los primeros años 70. Una de los más influyentes fue el DOD2167, el documento que describía el proceso de desarrollo de software para el Departamento Americano de Defensa. Royce fue aclamado y se hizo conocido como el padre del proceso DoD.
Sólo había un problema. El proceso que el DOD adoptaba era el proceso “de paja”. Aparentemente los autores del DOD2167 no habían leído el artículo de Royce porque adoptaron a “grandioso”, el simplista proceso que el artículo ridiculizaba. Para su desesperación, el Dr. Winston W. Royce se hizo famoso como el padre del desarrollo en cascada o Waterfall.
Aunque Royce protestó amargamente y peleó contra ello, la bola de nieve ya estaba en movimiento. Siguió creciendo según descendía por las montañas de compañías de software y países industriales. Año a año ganaba popularidad, dejando a su padre preguntándose acerca de la justicia del universo y de si había vida inteligente sobre la Tierra.
A mediados de los 90, el proceso en cascada dominaba el mundo del software. El campo de la “Ingeniería de Software” era definido por ese proceso; y por el catálogo de documentos de análisis y diseño que se esperaba que Arquitectos, Diseñadores y Analistas produjeran. El código era un detalle - la parte menos importante del proceso. Si escribías tus documentos bien, y dibujabas todos los diagramas necesarios, entonces lo estabas haciendo bien. Eras un ingeniero. El código podía dejarse para los humildes plebeyos del sótano.
Esta actitud creó un cisma en la comunidad técnica. Estaba la élite de Arquitectos, Diseñadores y Analistas de Sistemas que hacían la ingeniería real satisfaciendo las primeras dos fases de la cascada. Y luego estaban los soldados rasos que tenían que hacer realmente que todo funcionara en la fase final. Cuando el proyecto se retrasaba, eran los soldados los que trabajaban horas de más. Cuando el proyecto fracasaba, eran los soldados los que cargaban con la culpa.
Este fue un gran reto para la élite de Arquitectos, Diseñadores y Analistas! ¿Quién no querría un trabajo como ese? Tienes la autoridad para especificarlo todo, y ninguna responsabilidad en hacerlo funcionar realmente. Consigues un buen sueldo, el respeto de tus pares, y la envidia de las masas; y casi no hay manera de que te equivoques. Cuando vienen mal dadas, siempre puedes culpar a los programadores.
Sí, esto es un poco exagerado, pero sólo un poco. Las actitudes de elitismo eran muy reales. Aquellos que analizaban y diseñaban eran considerados demasiado valiosos para malgastarlos en simple programación. El código se convirtió en el hijo huérfano de la Ingeniería de Software.
Para 1998 las grietas ya estaban apareciendo en el edificio del proceso en cascada. Programadores en todas partes comenzaban a rechazar el elitismo de Arquitectos, Analistas y Diseñadores. Comenzaron a quejarse de la rigidez y pesadez del manto que les obligaban a vestir. Beedle, Devos, Schwaber y Sutherland habían publicado su artículo fundacional sobre Scrum, y Kent Beck había creado un movimiento acerca de la Programación eXtrema (XP).
Scrum rompió la cascada en piezas. En lugar de gastar meses o años creando pilas de documentos a través de una serie de fases secuenciales, Scrum sugería que u equipo de desarrolladores debían trabajar en ciclos cortos de 30 días para implementar funcionalidades. Scrum sugería que el equipo debía decidir cuando y si un documento era necesario. Scrum quitó el énfasis de los documentos y artefactos, para ponerlo de lleno en obtener funcionalidades terminadas, y en dar el poder de tomar decisiones al equipo. Scrum rompió el monopolio de la autoridad esgrimida por las élites y la puso en manos del equipo de desarrollo.
XP llevó esto un paso más allá aumentando el énfasis en el acto de la programación, declarando que el código era importante. XP es la integración de Scrum con un conjunto de disciplinas técnicas. ¡Y esas disciplinas tienen un inmenso efecto!
Scrum es un proceso diario. Proporciona un marco que describe como debe de ser un día, pero no dice nada de cómo debes trabajar en las horas y minutos de ese día. XP es un proceso minuto a minuto. Las disciplinas de XP llenan tu día. XP proporciona guía para la creación de cada línea de código. Proporciona un marco en el que tomar las decisiones de diseño y programación.
Scrum es un proceso subjetivo: El equipo manda. No hay medida objetiva de éxito o de calidad, o incluso de “hecho”. Queda al equipo definir esos términos. Las técnicas de ingeniería de XP añaden algunas meddas objetivas a Scrum. XP define la calidad del diseño y de código, y proporciona guía sobre cómo conseguirla. XP define el significado de “hecho”, y como puede medirse.
En 2001 la comunidad del software estaba revolucionada con estas ideas. El Manifiesto Ágil se había escrito, y había pasado a ser el elemento central detrás de u movimiento energético, entusiasta y creciente. La mismísima definición de Ingeniería del Software estaba siendo desafiada, y el desafío estaba triunfando.
El elitismo engendrado por “Waterfall” estaba siendo atacado. Ni Scrum ni XP tenían un rol previsto para un elitista que asumiera autoridad sin aceptar responsabilidad. En Scrum, el poder del equipo es más fuerte que el poder de un Arquitecto o Diseñador. Las contribuciones son bienvenidas, pero no necesariamente obedecidas.
XP llevó esto incluso más lejos. Si querías contribuir a un equipo XP, eras bienvenido; pero tomabas la responsabilidad explícita de tus contribuciones. Para Arquitectos y Diseñadores esto significaba que escribieran código. Para Analistas esto significaba que escribieran tests. Todos en el equipo tenían la responsabilidad de hacer que las cosas funcionaran.
Durante un tiempo, pareció que el elitismo de la Ingeniería del Software estaba muriendo; que la autoridad y la responsabilidad habían sido reconducidas de una vez por todas. Pero el elitismo es algo difícil de matar.
Tanto XP como Scrum definen el rol de un coach. La responsabilidad del coach es defender el proceso. Recuerda a todos su compromiso con sus disciplinas y con el proceso. Cuando la fecha se aproxima y los clientes están enfadados, es el coach quien recuerda al equipo que la mejor manera de cumplir y calmar a los gestores es seguir sus disciplinas. En Scrum, este rol se denominó Scrum Master.
XP define el rol del coach de manera bastante informal. El rol se desplaza entre los miembros del equipo. Un mes sería Joe, el siguiente Jane. No era un título, y no concedía ninguna autoridad. No había decisiones a tomar, no había asignación de poderes. El coach tenía la responsabilidad de recordar, no de mandar.
En Scrum, sucedió algo diferente…
El primer curso de Certified Scrum Master se impartió en las oficinas de Object Mentor en Vernon Hills, Illinois. Ken Schwaber me llamó y me preguntó si podía usar una de nuestras salas de formación. Le dije que estaría encantado de albergar ese curso. Él amablemente permitió que muchas de las personas que trabajaban para mí en aquella época asistieran gratuitamente y se convirtieran en CSMs.
Francamente, pensé que la idea era un poco tonta. No pensaba que miles de persona harían cola para obtener sus certificaciones. Pero no había considerado el atractivo del elitismo. No se me ocurrió que aquel curso especial, junto con el término “Certified” Scrum Master, se convertiría en una cuña para romper la relación entre autoridad y responsabilidad.
¿Quienes eran estos que hacían cola para recibir estos cursos CSM? ¿Eran miembros de equipos Scrum que querían ayudar a sus equipos? ¿Eran programadores y testers? Sí, había ciertamente algunos CSM que venían de equipos existentes. Pero la inmensa mayoría de CSMs tenían experiencia de gestión de proyectos. En esencia, habían añadido CSM al PMBOK. Se habían convertido en CSMs para tener la autoridad de gestionar equipos Scrum.
Esa nunca fue la intención. El papel del coach era actuar como un suave recordatorio del proceso y de la disciplina. No debía gestionar ni el proyecto ni la agenda. De hecho, ambos roles eran contradictorio. Es el rol del project manager hacer al equipo consciente de las fechas y sugerirles cambiar cosas para cumplirlas. Es el papel del coach recordar al equipo que debe respetar el proceso.
Los verdaderos coaches XP no son ni project managers ni líderes de equipo. No llevan al equipo al éxito, y no pueden reclamar el crédito del éxito. De hecho, el rol es considerado opcional porque los equipos maduros probablemente no necesitan recordatorios. Pero los CSM a menudo asumen el papel del líder de equipo. Se les ve como un componente crítico del equipo, sin el cual el equipo no puede funcionar. En XP, un equipo sin coach no es nada raro; pero un equipo scrum sin un scrum master es una contradicción.
De hecho, el rol de Scrum Master se considera tan importante que requiere certificación para obtenerlo. Si tu equipo Scrum no tiene un Scrum Master Certificado es que algo va mal.
Cuando un equipo Scrum tiene éxito, es el CSM el que se adelanta para recibir el premio, por supuesto en el nombre del equipo. ¿Pero qué pasa cuando un equipo Scrum falla? ¿Es el CSM quien da un paso al frente y cae bajo la espada? ¿Es el CSM el que recibe los latigazos y protege al equipo?
El elitismo ha vuelto, y está creciendo. Más cursos con certificaciones están disponibles, más se vislumbran. Otras compañías de formación ofrecen sus propias certificaciones. Después de todo, la erótica del elitismo es un gran negocio. La bola de nieve baja rodando por las montañas, y se hace más grande en cada giro.
¿Y cuándo comienza la revolución…?
Sólo puedo esperar que cuando Scrum caiga no arrastre en su caída a todo el movimiento Ágil.
Robert C. Martin
20 Nov. 2010
_
Posts
