La experiencia y el conocimiento suman, pero tu actitud multiplica

Hace poco escuché una frase a un coach que me gustó mucho: la experiencia y el conocimiento suman, pero la actitud multiplica. Fijaros en la fórmula: (E+C)*A. Toda nuestra experiencia que vamos acumulando en cuanto a desarrollo software es vital, así como el conocimiento que vamos adquiriendo a base de la lectura y formación. Sin embargo, todo esto no sirve absolutamente de nada sin una actitud correcta y profesional. Una actitud de esfuerzo y búsqueda de la excelencia. Aún si tenemos poco conocimiento y poca experiencia, nuestra actitud nos llevará a buscar la manera de desarrollar todos esos skills que nos faltan.

actitud

Pero, ¿Qué ocurre si llevamos muchísimos años trabajando sin plantearnos si hay maneras mejores de hacerlo o simplemente sin ser autocríticos con nuestra forma de proceder? Este relato, está orientado a llevarte a la reflexión. Hoy en día, en España, “Scrum está de moda” y muchos adoptan la metodología pensando que es una cuestión principal consistente en leer un libro básico como por ejemplo Scrum y XP desde las trincheras (el cual no dejo de recomendar como iniciación) y seguir el procedimiento sin plantearse realmente de forma crítica si realmente tiene sentido lo que están haciendo, convirtiendo su día a día en rituales y referencias a una documentación que siento decirlo y a muchos les dolerá, pero resume tanto las cosas que puede llevar a la confusión en algunos casos si esta lectura no se complementa con otras (y os dejo aquí algunas sugerencias).

Naturalidad-infancia-Suavinex

A continuación os dejo un relato que escribí hace años. Este relato aunque está lleno de humor negro, no deja de presentar una realidad, al menos en España, que es la falta de profesionalidad. Empresas deciden adoptar una metodología (sea cual fuere, en el caso del relato Scrum, pero como veremos…podría ser cualquier otra) y eligen a personas para liderar el cambio organizacional que no están preparadas. Quizá han acumulado años de experiencia, pero su actitud no es precisamente la adecuada. Normalmente esto se produce por el contexto y falta de motivación. Usaba el nombre de Patrick B. tratando de buscar una relación entre este tipo de persona y la película American psycho. Os dejo con el relato.

american

A Patrick B. le tocó ser Scrum Master: momento y lugar inadecuados él decía sonriendo. En su empresa las cosas iban mal y los proyectos no terminaban del todo bien. Se dieron cuenta de que el 49% de los proyectos terminaban con un sobrecoste, el 27% no terminaban y se cancelaban y el resto estaba al borde de o acabar mal o cancelarse. Aunque había un pequeño número terminaban con éxito, cosa que nunca llegaron a entender. Algunos decían que era por la involucración de cliente en esos proyectos, otros decían que era suerte. A Patrick B. simplemente, no le importaban demasiado estos números.

Chuck Norris - Scrum master

Pero como iba diciendo, Patrick B. era Team Leader. Sumar, quitar y poner horas ya no tenía ningún misterio para él. Con su Gantt en la mano se sentía bastante seguro y “sus chicos”, como él los llamaba, estaban “a tope”. Si eso de la Zona de confort existiera, creo que la de Patrick B. era de látex con doble capa, con un televisor y con un par de pufs para apoyar sus cansadas piernas. Su vida era maravillosa, siempre cumplían los hitos, de una manera u otra. Tenía trucos que nadie conocía, como mandar la entrega en un CD rayado a cliente para tener cinco días más de desarrollo. Infalible.

scrum norris - gantt

Su empresa, una gran multinacional que poseía grandes, pesados y seguros procesos para todo. Tenía en el plan de desarrollo software un modelo en V descrito. La primera vez que escuchó de él, se imaginó que era algo novedoso, pero al parecer llevaba aplicado bastante tiempo. Lo leyó una vez y casi obligado. El caso es que fuera lo que fuera, parece ser que no funcionaba del todo y no tenían claro por qué. Patrick B. sabía que alguien había escrito el documento y lo había subido a control de configuración un tiempo atrás. ¿Qué más había que hacer para que funcionara?

ni idea de lo que hablas

Comenzó la moda en la que las grandes multinacionales con sus pesados, completos y e inexpugnables modelos en V y en cascada querían pasar a eso de las metodologías ágiles. Querían cambiar su filosofía, adaptarse al cambio. En algunas empresas, se contrata a un agile coach o especialista en metodologías de desarrollo. Patrick B. tenía un amigo que se dedicaba a eso y decía que es una gran trampa.  Muchas empresas normalmente no quieren cambiar su forma de trabajar y lo que quieren es que las nuevas formas de trabajar se adapten a ellos dando resultados positivos a corto plazo. Decía que contrataban a un agile coach y pensaban que sin ningún tipo de apoyo por parte de la dirección y mediante extraños rituales conseguirían llevar a cabo esos cambios tan deseados.

dilbert_ideas

Otras empresas contratan a un consultor externo. Pero Patrick B. decía que solían ser gente muy teórica que querían hacer cambios radicales. “Si quisiéramos hacer cambios radicales llamaríamos a Longueras”,  decía Patrick. “Estos devoradores de libros, están media hora y te cobran un ojo de la cara”. Alguien le contestó una vez que no le cobraba los 10 minutos de tiempo por resolver el problema, si no todo el tiempo que había invertido en aprender cómo resolver su problema en 10 minutos.

longueras

El caso es que a Patrick B., le cayó el tema agile y le tocó empaparse de todo esto de los “agiles”. Como Patrick B. era un tipo con recursos, lo primero que hizo fue teclear www.google.com  y buscar “agile V Model” y Eureka! Encontró una página que se titulaba “¿por qué Agile es mejor que V-Model?“. Le pareció curioso que estuviera la séptima y que hubiera antes páginas extrañas que hablaban de manuscritos, comunidades y trincheras. Patrick B. pensó que es lo mismo que cuando buscas cracks que te sale porno por todos sitios.

agile vmodel perturbado

Patrick B. vio un poco los dibujos y sintió que ya sabía de qué iba. Tras un análisis de 30 segundos llegó a la conclusión de que estaba muy bien desde el punto de vista teórico, pero en proyectos de verdad, de los que acaban con sobre-coste o se cancelan, esto no era aplicable… y menos en el suyo. Nunca le llegó a gustar eso del burndown chart: “eso de que la línea vaya hacia abajo y no hacia arriba, le resultaba extrañamente inquietantemente”.

sherlock2

Se  creó un backlog con las cosas que había que hacer, “historias de usuario” las llaman los agilistas. Debían tener una prioridad y un criterio de aceptación. Esto del scrum, es un marco de trabajo así que el bueno de Patrick B. decidió hacer su propia implementación adaptándolo a las necesidades de su proyecto. Decidió que iba a ser product owner y scrum master ya que estos roles se adaptaban más a lo que él conocía de antes. Dicen que son roles que no son compatibles por tener objetivos distintos, pero Patrick B. suponía que esta advertencia era como la fecha de caducidad de los yogures, es decir, opcional.

1241915072NEURAS

Empezaron con las reuniones diarias. Al principio las hacían de pié, pero a partir de los 45 minutos ya les dolía la espalda y decidieron hacerlas sentados. Cada uno contaba lo que había hecho el día anterior y lo que iba a hacer ese día. Dejaron de usar la pizarra porque tener que actualizarla era agotador y la verdad es que nadie la utilizaba. Al poco tiempo tampoco le encontraron mucho sentido a la reunión diaria, salvo para tomar el café de la mañana. Conocieron a mucha gente durante estas dailies ya que la gente se paraba para ver que hacían y algunos acabaron quedándose por hábito. Patrick B. conoció a su mujer en una daily.

batman

Las historias de usuario se mantenían tanto tiempo en la pizarra en progreso que tuvieron que designar responsables de historia de usuario para “ver si eso se movía un poco”. Patrick B. decidió ahondar un poco, mirando el las retrospectivas de los equipos de desarrollo. No solía echarles un vistazo porque opinaba que la gente al final acaba quejándose y no siendo constructiva. Hizo una lista con los últimos sprints pero no obtuvo respuesta ninguna a su problema. Decididamente pensó que la gente se quejaba por vicio. He aquí algunas de sus incoherentes quejas:

  • Los test unitarios tardan 3 horas en ejecutar.
  • Baja cobertura.
  • Rama de desarrollo inestable.
  • Cambios en mitad del sprint.
  • Demasiadas reuniones.
  • Si no nos hacen caso, que no nos pregunten, por favor.

shutterstock_39087388-A

Para favorecer la comunicación, Patrick B. decidió implantar reuniones diarias donde participaran algunos miembros del proyecto de distintos equipos. Eran unos 20 diariamente y trataban temas tan variopintos como el problema que había habido con tal módulo de desarrollo, problemas en testing, en especificaciones o los problemas de Pepe el chico de mantenimiento, que todos los días pasaba por allí hasta que al ver tanta gente reunida decidió tomarse el café de por la mañana con ellos.

tapon-reuters--644x362

Como Patrick B. siempre decía, “esto de las metodologías ágiles es sólo aplicable a entornos de laboratorio. En el mundo real, no funcionan.” No tenían ningún resultado positivo, el número de historias de usuario resueltas no bajaban. La motivación de los equipos estaba por los suelos y la calidad del código estaba deteriorándose cada día más. Patrick B. no paraba de repetir que no funcionaba en entornos reales porque se trataba de metodologías de plastilina.

El jefe de departamento contrató a un consultor Agile muy famoso que les dijo que tenían que partir las historias para reducir el cycle time, los sprints deberían ser del mismo tamaño para poder medir la velocidad del equipo y tenían que volver a hacer retrospectivas, dailies y planificaciones en los sprints. Patrick B. no entendía cómo podía todo eso arreglar su problema. No veía en que podía ayudarles nada de lo que ese famoso agile coach les decía. En las páginas web que había leído sobre agile no ponía absolutamente nada de “cycle time”, o de que los sprints tenían que tener el mismo tamaño. Patrick B. finalmente llegó a la conclusión de que este consultor al que él había admirado durante tanto tiempo se había vuelto tan teórico que ya no tenía los pies en la tierra: en alguna ocasión hasta le había visto intentar levitar.

Coach

En definitiva, Patrick B. se dio cuenta de que nada de esto funcionaba así que decidió volver a la metodología que tenía antes. Un maravilloso modelo en V, que aunque nunca les había dado buenos resultados, estaban acostumbrados a utilizar. Su modelo en V era algo particular y por eso Patrick B. había hecho algunos ajustes:

  • No hacían un análisis previo porque era una pérdida de tiempo ya que los requisitos cambian.
  • Preferían empezar el desarrollo antes de tener los requisitos. Ya que daban prioridad al software corriendo frente a documentación exhaustiva.
  • No creían en los test unitarios. O sólo en aquellas partes importantes…y si hubiera tiempo.
  • En cuanto a la verificación si tenían tiempo lo harían. Pero lo más seguro es que reservaran un mes de la planificación antes de la calificación con cliente para resolver bugs.

american ps

Así, Patrick B. volvió a la oscuridad de la que procedía sin haber aprendido absolutamente nada y con la extraña convicción de que ninguna metodología ágil podía aplicarse a proyectos de verdad y concretamente… al suyo propio.

autocritica

Como vemos en el relato, el problema no es la metodología, simplemente la actitud de las personas. Al final decide volver a lo mismo que tenían antes, pero deciden ajustarlo a su propia comodidad, rompiendo con todos los principios de V-Model, de forma que tampoco están haciendo un modelo en cascada, simplemente están haciendo otro tipo de rituales. Este relato aunque es inventado, las cosas que se cuentan son cosas que en algún momento, en algún equipo y en alguna empresa han ocurrido tal cual. Os invito a reflexionar, si realmente somos parte del ritual, o parte de la solución. La autocrítica, es el primer paso de la excelencia.

https://www.scrum.org/ScrumBut

PDFicono EXTENDIDO

Anuncios

El por qué de que algunos proyectos fracasen VI: RUP y un caso de éxito

Uno de los puntos positivos de Rational Unified Process (RUP) es que partimos de la idea de que “los requisitos van a cambiar”. Reconocer esto tiene gran mérito ya que en la cultura de desarrollo software  predominante en su nacimiento (años 90) lo que se hacía era negociar los requisitos con cliente y rezar compulsivamente para que no cambiasen. Creo que muchos jefes de proyecto se debían y deben sentir muchas veces como Jeff Murray en el día de la Marmota.

Atrapado en el tiempo

RUP dice que puesto que ya sabemos que los requisitos pueden cambiar, vamos a hacer una aproximación en 4 fases: Iniciación, Elaboración, Construcción y transición. Dentro de cada fase se producen una serie de hitos en los cuales debemos sacar un entregable, es decir, una baseline de mis requisitos, código  o lo que tengamos que entregar en esa fase. La idea es obtener feedback (interno) de lo que hemos realizado. Esos hitos por fase son de 4-6 semanas. En cada hito vamos a tratar de ir refinando la solución del problema, mejorando iterativamente nuestro conocimiento y necesidades del negocio a través del feedback aportado normalmente por los ingenieros de V&V(lo llaman feedback interno en RUP)…aunque la verdad es que nada impide que se tenga feedback externo de cliente, aunque esto no es obligatorio. Se trata en de un modelo de desarrollo en espiral de convergencia a la mejor solución  a través de inspección de sus artefactos (casos de uso, en general otros diagramas UML y distintas vistas de arquitectura) y adaptación en cada iteración.

rup_fundamentals_slide05

Cuando apliqué RUP años atrás en uno de los  proyectos en los que trabajé, cada fase era básicamente un proyecto completo y distinto donde cada hito final era de cobro, pudiendo haber sobre todo en la fase de construcción un par de hitos de cobro intermedios. No debe confundirse estas fases con las típicas de inicialización, planificación, ejecución y cierre de proyecto, ya que estas fases son exclusivamente para converger a la solución de una manera óptima en cuanto a recursos, minimización de coste y riesgo donde el alcance varía a lo largo de estas iteraciones. Supongo que como todo podría aplicarse de otros modos de acuerdo a lo que se estipule en el contrato con cliente, al fin y al cabo RUP es un marco de trabajo y no una metodología como tal. En las cuatro fases nosotros realizamos las siguientes actividades:

  • Iniciación: Aquí no participé, pero fue la toma de contacto con cliente. Donde se obtuvieron os requisitos de muy alto nivel y se estableció un poco como iban a realizarse los trabajos, es decir, preparamos un poco el terreno. De acuerdo a RUP, en esta fase se modela a alto nivel el negocio, el entorno donde va a ser desarrollado y desplegado, como se va a hacer la gestión de configuración y poco más.

como-redactar-una-carta-comercial-de-oferta-de-productos

  • Elaboración: Durante la fase de elaboración se le pregunta a cliente y se establece una idea de que es lo que vamos a desarrollar partiendo del output obtenido en la fase anterior. En nuestro caso hicimos un prototipo para apoyar los casos de uso y  obtuvimos los requisitos en varias entregas con cliente donde obtuvimos un feedback muy valioso. Tuvimos suerte de que en este caso el producto estaba basado en otro producto que habíamos desarrollado años antes donde además del software se documentaron requisitos, casos de usos y se trabajó en la gestión de la configuración, división en componentes, etc. La entrega fueron unos cuantos CDs con mucha documentación + un prototipo ejecutable.

Payme

  • Construcción: Después de pelearnos unos meses llevando el prototipo y algunos videos de su funcionamiento a algunas ferias, esperando que nos dieran el visto bueno para desarrollar el sistema que habíamos “elaborado”. Nos dieron el OK y formamos un equipo de unas 10 personas. Recuerdo que trabajamos sobre un software con un Core muy desarrollado y bien definido, por lo que a final de cuentas sólo hubo que desarrollar nuevas funcionalidades, específicas del problema, documentar mediante UML, pruebas, trazabilidad, etc.
    Se hicieron varias entregas intermedias y en alguna hubo algún susto que otro, pero al final se entregó todo con la calidad esperada y cubriendo todos los requisitos. La facilidad para lograr hitos fue sin duda de un equipo de desarrollo altamente cualificado donde no había diferenciación entre programadores y analistas, ya que se trataba de un equipo multifuncional donde todos éramos simplemente ingenieros de proyecto. Había alguno que estaba especializado en algún área de negocio o en alguna parte técnica como verificación y validación, pero a final de cuentas, no había más título que el de ingeniero de proyecto.

steve-ballmer-developers-bandwidthblog-664x534

  • Transición: Aquí ya no estuve. Se despliega el producto, se corrigen algunos errores. Se trata de la típica fase de mantenimiento donde se afinan un poco más los requisitos con el sistema ya funcionando, pero su objetivo es obtener feedback de cliente, no únicamente su mantenimiento. Aún se pueden cambiar algunas funcionalidades, aunque es esperado que tras el trabajo realizado en fases anteriores esto ocurra excepcionalmente. Aquí es donde tiene más peso el feedback de cliente según la teoría de RUP.

Rup_espanol

Mi experiencia fue buena y creo que la del equipo también. Sin embargo no creo que sea un buen ejemplo de aplicación de RUP a un proyecto complejo, si no de aplicación de RUP a un proyecto en el cual teníamos poca incertidumbre y por tanto muy poco riesgo, el cual estaba controlado. El feedback interno obtenido por el ingeniero de V&V estaba bien, pero al final lo que contaba era el feedback de cliente. Aunque como decía antes, no es un buen ejemplo de aplicación pura de RUP, quería sacar este ejemplo porque fue un caso de éxito que en teoría podría ser contado a nivel estadístico como un caso de éxito que utilizaba metodologías tradicionales (aunque tenga el ciclo de vida en espiral o incremental, no considero a RUP muy diferente de V-Model. Echar un vistazo a “Dual V Model”) .

developers

Hay que decir que a pesar de todo esto, hubo pequeños picos de trabajo  y algún que otro problema de entrega (errores humanos sin importancia). Sin embargo, no era un problema demasiado complejo. Tampoco digo que fuera fácil, pero conocíamos el camino, sólo teníamos que recorrerlo . Se trataba de un proyecto de riesgo controlado y no éramos más de 10 personas en el equipo en total, con lo que la capa de gestión estaba formada básicamente por un jefe de proyecto. Había un director técnico, pero la forma de trabajo era totalmente plana, se trataba de un equipo autoorganizado, senior y con varios años trabajando juntos.

equipo-aPara la documentación usamos Rational Rose y conseguimos cada mes alinear el diseño UML de manera semi-automática donde sólo nos consumía 1 persona 2 o 3 días. Esto no quiere decir que no hiciéramos diseños previos, si no que la documentación la hacíamos a posteriori apoyándonos de herramientas automáticas. Al fin y al cabo, eran entregables pedidos por cliente. Los casos de uso no fueron más que documentación que fue totalmente inútil tanto para ellos como para nosotros en la fase de construcción. Es cierto que en la fase de elaboración si tuvieron cierta utilidad para comunicarnos con el cliente, aunque el prototipo funcional tuvo mucho más peso. La documentación de arquitectura la hacíamos a posteriori y le encontré varias utilidades que no tienen nada que ver con los objetivos que plantea RUP (la cual se debería documentar a priori). Estas fueron:

  • Se detectaban desviaciones de la arquitectura de forma temprana en cada actualización. A veces pasa cuando hay falta de alineación, por lo que ayudó a mantener esa alineación entre los componentes del equipo en cuanto al “como hacer”. No hacíamos reuniones rápidas diarias para alinearnos y creo que uno de los miembros no estaba en la misma sala, era un fallo que teníamos.
  • El cliente prefería ver el sistema funcionando y relacionarlo con los diagramas a nivel de paquetes UML, que ver un montón de casos de uso que ya no le decían nada. Iban viendo las relaciones entre paquetes de alto nivel y podían navegar entre ellos gracias a la herramienta Rational Rose. Esta transparencia, dio mucha confianza al cliente en cuanto a la calidad interna del software y esto nos facilitó muchísimo las entregas debido a su tolerancia ante la aparición de errores.
  • Esta documentación era muy útil para que los nuevos integrantes del proyecto se “metieran en harina” sin tener que “bucear en el código”.

vueltatortilla

Realmente, hicimos algo de trampa porque, sin querer cubrimos muchos de los principios ágiles, los cuales desconocíamos por completo su existencia:

  • La jerarquía de proyecto era prácticamente plana y el equipo al completo se podría decir que era totalmente autoorganizado.
  • No teníamos procesos que seguir, más que los estrictamente necesarios para lograr nuestros objetivos.
  • Dimos prioridad al código ejecutable y funcionando frente a la documentación exhaustiva.
  • Dimos prioridad al conocimiento tácito, es decir, aquél que forma parte del equipo y del cliente de una manera informal, frente a la documentación de casos de uso.
  • Hablábamos con el cliente, pero de una manera informal y siempre con una versión del producto delante. Había requisitos, pero nos ayudábamos del cliente para entenderlos.
  • Dimos prioridad al uso de herramientas automáticas frente a la documentación previa y exhaustiva.
  • Hubo cambios en algunas partes. No fueron muy drásticos, pero los abrazamos sin ningún tipo de problema.

El éxito de este proyecto fue utilizar el sentido común de unos grandes profesionales que llevaban más de 20 años desarrollando este tipo de sistemas. No eran agilistas, pero sin lugar a duda eran ágiles.

Sinquerer

Actualmente RUP ha evolucionado a AUP (Agile Unified Process) donde han seguido manteniendo sus 4 fases pero han orientado el desarrollo de producto a XP. Básicamente quitaron todo parecido que tuviera con V-Model, casos de usos, UML… porque al final, creo que casi ningún proyecto de éxito lo seguía a rajatabla. Quizá después de todo acertamos.

Agile_Methodologies_lightweightfuller_approaches

En la teoría, nos enseñan a definir el sistema completo antes de comenzar el desarrollo mediante casos de uso, diseños arquitectónicos documentados con UML y al final cuando está todo pensado, debemos pasar a la acción escribiendo líneas de código como si ladrillos fuesen, tratando a los desarrolladores como meros interpretadores de esos planos tan detallados e infalibles.  En la realidad, se escribe una documentación que nunca llega a tiempo, o si llega, con un detalle parcial que proporciona a los desarrolladores una idea vaga de cómo se quiere el sistema. Si han tenido suerte de que el analista orgánico ha trabajado codo con codo con desarrollo, tendrán que realizar ajustes y seguramente el trabajo de la documentación haya servido como una primera aproximación al problema y tenga cierto valor. Pero si en el proyecto existe una clara separación entre analista orgánico y desarrollador, es muy probable que el trabajo del mismo haya sido una pérdida de tiempo y dinero razonable para proyecto.

sin dinero en el bolsillo

El diseño, la documentación, lo que hace el sistema está ahí, en el código. El problema es que es un lenguaje que hay que conocer. Además si no cuidamos el código, se trata de una documentación “infumable” y por tanto como documentación es poco útil. Imaginad una novela donde cambiamos palabras por etiquetas sin ningún sentido semántico, la indentación y las fuentes no son homogéneas, existen párrafos que están obsoletos y no deberías leer y la estructura es caótica. Dan ganas de leerla ¿eh?

repetir codigo

Lógicamente, no la leerías y pedirías que te escribieran un “guía burros” para poder entenderla. El código es la novela de tu producto. Hoy en día existen técnicas de diseño basadas exclusivamente en código (específicamente en pruebas automáticas): TDD y BDD. Además el tener pruebas unitarias con una buena cobertura, también nos proporciona cierta garantía de que si escribo un párrafo de mi libro tendrá coherencia con el resto de la novela. También existen herramientas que me detectan falta de homogeneidad, párrafos repetidos, etc. Realmente ¿crees necesario, escribir un mapa de tu libro para poder leerlo y entenderlo? Puedo entender que se escriba documentación porque el proyecto lo requiera y sea un entregable, pero ¿Quién crees que va leer cada clase y atributo en “un tocho” de 10000 páginas?

Libraco

He dicho anteriormente que hicimos trampa usando RUP, quizá haya exagerado en un momento de pasión. Simplemente no seguimos RUP. La documentación la tratamos como un entregable más que debía cumplir una serie de estándares y la obtuvimos automáticamente con el beneplácito del propio cliente. Le encontramos un valor a esos entregables que eran dar transparencia a cliente acerca de nuestra arquitectura y revisiones semi-automáticas de la evolución del código, el cual estaba debidamente comentado y cuidado. Fuimos ágiles, eficientes y utilizamos la documentación en nuestro favor de camino hacia la victoria. En resumen fuimos Culpables.

culpable

PDFicono EXTENDIDO

REFERENCIAS:

[1] RUP en wikipedia
[2] Rational Unified Process – Best Practices for software development teams
[3] Managing the development of large systems
[4] Manifiesto Ágil