archivo

Archivo de la etiqueta: Jeff Sutherland

Para Jeff Sutherland: “El compromiso de trabajar juntos sólo ocurre cuando las personas están de acuerdo en objetivos comunes y luego luchan para mejorar como personas y como equipo”.

Precisamente por eso es tan complicado alcanzar ese compromiso y por eso creo que se requiere un cierto bagaje personal y profesional para entender qué ventajas supone trabajar de esta manera y lo necesario que resulta para sacar adelante los proyectos.

Los equipos funcionan cuando existe un compromiso entre los miembros del equipo. Cuando cada cual va por su cuenta no estamos hablando de equipo sino de un conjunto de personas que comparten un espacio físico.

El compromiso es dar lo mejor de nosotros mismos por el equipo y por el proyecto y exigir a los demás que hagan lo mismo. Si el nivel de exigencia no es justo favoreciendo a unos sobre otros, no se debe llamar compromiso, sino amiguismo ya que el compromiso solo tienes con unos cuantos y esos cuantos contigo.

Tampoco son buenas las políticas del todo el mundo es bueno, porque generalmente cuando se aplican es precisamente para evitar ciertas decisiones poco agradables. Lo fácil siempre es hacer la media aritmética y tratar a todos por igual lo hagan bien o lo hagan mal, estén comprometidos o no. Este tipo de estrategias hacen mucho daño a aquellas personas que precisamente ofrecen un mayor compromiso.

Cuando un equipo funciona tiene como consecuencia natural la autogestión en la que cada miembro del equipo asume su responsabilidad y se resuelven los conflictos en el equipo (salvo que por su trascendencia tengan que escalarse).

A la hora de realizar una estimación existen dos problemas principales, primero la ingerencia de los gestores de proyecto y de los responsables funcionales que normalmente pretenden acomodar los plazos a sus necesidades (que lo mismo son las necesidades reales del proyecto) y segundo cuando el equipo de proyecto pierde la objetividad y opta por actitudes demasiado optimistas o pesimistas (defensivas) al margen del contexto real del proyecto.

Si la estimación no se ajusta a los plazos deseables en el proyecto y no es posible mejorar esos tiempos metiendo más personal, intentando aplicar algunas estrategias que puedan mejorar la productividad o cualquier otra posible solución, lo mejor es negociar bien otros plazos o una reducción de las expectativas del sistema para ese marco temporal.

Es cierto que, en algunos casos (menos de los que creemos y admitimos), los plazos son los plazos y no tendremos más remedio que convivir con ellos, en esos casos hay que buscar fórmulas para intentar llegar a ellos, sin renunciar a eliminar toda funcionalidad que no sea absolutamente necesaria para conseguir los objetivos (aunque se tenga que desarrollar más tarde).

Todos, y me incluyo, nos sentimos tentados a intervenir en las estimaciones, pero es algo que tenemos que intentar evitar, salvo que sea algo tan evidente que nos haga actuar (si no entendemos algo, tenemos que preguntar, si vemos que algo es disparatado, hay que pedir explicaciones y si procede, rechazar la estimación).

Para Jeff Sutherland: “Las personas que están realizando el trabajo son los que siempre deben estimar el trabajo” y la experiencia me ha demostrado que así debe ser.

Estoy de acuerdo con Jeff Sutherland cuando comenta que “Los documentos con requisitos de gran tamaño, rara vez se leen y mucho menos se siguen”, realmente lo que interesa es conocer lo necesario para desarrollar una funcionalidad, ni más ni menos y eso va más allá de la formalidad que requieren los catálogos de requisitos.

Como es lógico en el caso de sistemas críticos se podría plantear una mayor formalidad y un mayor nivel de detalle, pero la realidad es que la mayoría de los sistemas no requieren de catálogos de requisitos de esas características que además quedan obsoletos en la siguiente iteración del producto, salvo que se sigan escrupulosamente los procesos y se utilicen las herramientas adecuadas, lo que requiere un importante esfuerzo que habría que evaluar lo realmente necesario que resulta.

No se trata de renunciar a los requisitos sino de utilizar fórmulas que resulten más livianas como pueden ser las historias de usuario que tienen como misión específica describir una determinada funcionalidad que vamos a implementar a corto plazo. En el futuro la historia de usuario será una referencia de lo que se desarrolló en un momento concreto del tiempo que no es poco porque realmente: ¿necesitamos mucho más?.

Jeff Sutherland entiende que (traducción libre): “Los miembros del equipo deben compartir un propósito y visión común, además de pasión por su trabajo. Los equipos no son solo un conjunto de personas que trabajan juntas, sino que todas deben estar comprometidos con su trabajo y con el de los compañeros”.

Coincido con él, para mi eso es realmente un equipo.

Sin embargo lograrlo no es nada sencillo sobre todo teniendo en cuenta lo variables e impredecibles que somos las personas y que cada cual tenemos una forma de ser que supone nuestro background en la relación con nuestro entorno. A lo anterior hay que sumar el contexto individual de cada persona en su vida profesional y personal y el contexto en el que el equipo realice su trabajo (hay veces donde las circunstancias no ayudan a la cohesión de un equipo).

No se trata, por tanto, de colocar a una serie de personas en una habitación, dar una charla y ponerse a trabajar, se requiere mucho más para llegar a tener un equipo que funcione como tal, para empezar que cada uno crea que este es el camino para lograr los objetivos del proyecto pero que también lo es para conseguir los objetivos del grupo y los individuales.

Después las propias necesidades de la organización también condicionan todo, si un proyecto termina puede provocar que el equipo se disgregue entre otros equipos existentes en la organización y la química en estos nuevos equipos no será la misma, por lo menos durante un tiempo.

Ahora bien, si un equipo funciona hay que intentar por todos los medios mantenerlo unido, salvo que integrantes del mismo quieran rotar. Para eso puede ser interesante tener una cultura de trabajo en equipo en la organización y si no es posible, por lo menos en los proyectos que sean de tu responsabilidad porque de esta forma las rotaciones no solo tendrán menos impacto sino que incluso pueden ser beneficiosas para incrementar sus habilidades y experiencia.

Comenta Jeff Sutherland que entre el 50% y el 80% del contenido de las reuniones corporativas no es productivo. No sé si en esos porcentajes pero la mayoría de nosotros sí que tiene esa percepción.

Yo considero interesantes las reuniones (por ejemplo Steve Jobs y Apple en general presumían precisamente de ellas) ya que fomenta el intercambio de reflexiones y con ello se gana el análisis de diferentes visiones sobre una determinada situación y, además, reduce o evita los malos entendidos. Las personas de vez en cuando necesitan tratar directamente sobre un tema y no dejarlo todo en manos del correo electrónico, del teléfono o incluso de la videoconferencia.

Las reuniones deben tener una intención, reunirse por reunirse no aporta nada y es una pérdida de tiempo. Las reuniones deben tener un orden del día y unas conclusiones que pueden dar lugar a la realización de tareas que, además, deben ser objeto de seguimiento.

Jeff Sutherland ve las reuniones desde el punto de vista de Scrum en las cuales ya existe un guión establecido (ya sea en los scrums diarios, en las retrospectivas, en la definición de pila de sprint, etc…) y existe un tiempo limitado (por ese motivo comenta que ese problema, el de las reuniones donde buena parte de su contenido o duración es improductivo se elimina con Scrum desde el primer día).

Pero más allá de ellas, habrá otro tipo de reuniones que tendrán que realizar determinados perfiles donde esas reglas del juego no se apliquen (reuniones con clientes, con otros departamentos de la organización, etc…).

La eficiencia no se consigue eludiendo las reuniones sino utilizándolas de manera precisa, Scrum lo hace pero tenemos que intentar conseguir los mismos efectos en otros contextos aún aplicando técnicas distintas.

La gestión del conocimiento en una organización suele ser uno de sus puntos débiles. El día a día y la orientación exclusiva a la ejecución de los trabajos hace que queden en un segundo plano medidas orientadas a que el conocimiento no sea algo exclusivo de las personas sino un bien de la organización.

Además, muchas personas tienden a acumular conocimiento sobre determinadas materias y hacerlos estanco para los demás, creando de esta forma una parcela de poder (un cortijo) que lo haga fuerte tanto en su continuidad en la organización como en su promoción.

Es cierto que siempre habrá alguien que domine mejor una tecnología, un área de negocio o conozca mejor a un cliente, eso resulta lógico y razonable y además puede ser una ventaja importante personas tan especializadas. En estos casos lo que hay que intentar hacer es que su conocimiento llegue a más compañeros y en lo posible que lo más significativo quede registrado por escrito.

Si nos centramos en marcos de desarrollo fuertemente colaborativos como por ejemplo la programación extrema el conocimiento debería ser algo colectivo por la rotación existente de manera interna en un equipo donde una semana uno puede estar haciendo programación por pares de un módulo con una persona y la siguiente estar con una funcionalidad totalmente distinta en otro subsistema.

Jeff Sutherland en relación a la acumulación de conocimientos por parte de personas concretas opina lo siguiente: “No debe haber un tipo que acumule todo el conocimiento sobre un tema. Yo despediría a aquellas personas que tienen todo el conocimiento sobre un dominio concreto ya que no se debe tener un único punto de error”.

Pocas reflexiones pueden describir mejor en pocas palabras la realidad evolutiva del software que la realizó Jeff Sutherland, creador junto a Ken Schwaber de la metodología Scrum: “Los usuarios no saben lo que quieren hasta que lo ven y siempre se reservan el derecho a cambiar de opinión”.

Es cierto que hay técnicas que ayudan a afinar en los requisitos, como son los prototipos, pero por muy bien que estén hechos, hasta que no lo utilizan (voy más allá del hecho de que lo vean) no terminan de dar las indicaciones necesarias para que el producto satisfaga sus expectativas.

Esto nos lleva a un enfoque iterativo incremental en el desarrollo de software, como modelo de referencia para ajustarnos a esta realidad.

Una vez analizados los principios y valores del manifiesto ágil, en este artículo se va a realizar un breve perfil de sus diecisiete participantes, con el objetivo de que se pueda apreciar que todo el equipo de personas que participaron eran profesionales de reconocido prestigio y que en su trayectoria profesional tenían experiencia e incluso habían publicado artículos y libros sobre la aplicación de estrategias que posteriormente a alto nivel se plasmaron en el manifiesto ágil.

– Kent Beck: Americano. Creador de la metodología de programación extrema y de la metodología de desarrollo guiado por las pruebas (TDD: Test-driven Development). Coautor de JUnit. Promotor de la reunión que dio lugar a la creación de manifiesto ágil para el desarrollo de software.

– Mike Beedle: Americano. Ha sido uno de los pioneros en la aplicación de Scrum (desde 1995) en proyectos de desarrollo de software en diferentes organizaciones y tipos de sistemas (en cuanto al proceso o procesos de negocio que tratan de informatizar).

– Arie van Bennekum: Holandés. Jefe de proyectos y consultor especializado en la metodología DSDM (método de desarrollo de sistemas dinámicos), representó al DSDM Consortium en la reunión.

– Alistair Cockburn: Americano. Creador de la familia de metodologías Crystal. Contribuyó a la expansión de la utilización de los casos de uso con la definición que hizo de los mismos en el libro “Escribir casos de uso efectivos” publicado en el año 2000, propiciando la generalización de su uso para describir el comportamiento de los requisitos software y de los procesos de negocio (a más alto nivel). La creación del concepto de caso de uso es bastante anterior, del año 1986 y fue realizada por el sueco Ivar Jacobson

– Ward Cunningham: Americano. Howard G. Cunningham fue el creador de la primera solución Wiki (WikiWikiWeb) y se considera un pionero tanto en la aplicación de programación extrema como en la utilización de patrones de diseño.

– Martin Fowler: Americano. Especialista en procesos de refactorización de software, programación orientada a objetos, UML y programación extrema. Hizo popular el uso del término “inyección de dependencias”.

– James Grenning: Americano. Especialista en sistemas empotrados. Fue uno de los pioneros en desarrollo de proyectos bajo la metodología de programación extrema. Experto en TDD (Test-driven Development). Ha sido el creador de la técnica de estimación Planning Poker.

– Jim Highsmith: Americano. James A. Highsmith III. Ingeniero de software experimentado que ha participado en proyectos de desarrollo de software en muchos países del mundo. En el año 1999 publicó el libro “Adaptative Software Development” donde puso de manifiesto la naturaleza adaptativa de los proyectos de desarrollo de software. Se ha especializado en la consultoría de proyectos que se realizan en entornos inestables y con una complejidad creciente.

– Andrew Hunt: Americano. Desarrollador de software con gran experiencia. Publicó junto a Dave Thomas en el año 1999 el libro “The Pragmatic Programmer”, en el que realizó una definición de lo que consideraban un programador práctico o pragmático:

– Early adopter.
– Curioso.
– Pensador crítico.
– Realista.
– Aprendiz de todo, maestro de nada.

Fue uno de los introductores en occidente de la programación en Ruby, mediante la publicación en el año 2000 del libro “Programming Ruby: A Pragmatic Programmer’s Guide”.

– Ron Jeffries: Considerado junto a Kent Beck y Ward Cunningham como uno de los creadores de la programación extrema. Participó junto a Beck en el proyecto de 1996 en Chrysler que dio lugar a este concepto.

– Brian Marick: Americano. Especialista en realización de tareas de testing. En el año 1995 publicó uno de sus libros más conocidos: “The Craft of Software Testing: Subsystem Testing Including Object-based and Object-oriented Testing”. Experto en Ruby.

– Robert C. Martin: Americano. Robert Cecil Martin (Uncle Bob). Dedicado a tareas de desarrollo de software desde 1970. Especialista en programación orientada a objetos sobre todo en el área de patrones de diseño.

– Steve Mellor: Americano. Especialista en sistemas empotrados, programación orientada a objetos y MDA (Model Driven Architecture). Creador junto a Sally Shlaer del método Shlaer-Mellor que es uno de los métodos de análisis y diseño orientado a objetos que surgió a finales de la década de los ochenta como respuesta a las principales problemáticas que presentaba el análisis y diseño estructurado, entre las cuales destacaban la complejidad de los diseños estructurados y la dificultad de mantener tanto su documentación de análisis como de diseño.

– Jon Kern: Americano. Inició su carrera profesional en sistemas empotrados en el área militar. Considerado como uno de los pioneros en la aplicación de la programación orientada a objetos. Especialista en programación Java y en MDA.

– Ken Schwaber y Jeff Sutherland: Americanos. Creadores de la metodología Scrum.

– Dave Thomas: Inglés. Autor junto a Andrew Hunt del libro “The Pragmatic Programmer”. También junto al mismo autor se considera uno de los introductores de Ruby en occidente.

Soy un converso, quizá por eso mi postura es más radical. Estoy cansado de participar en desarrollos con metodologías clásicas que no terminan de tener éxito (no tener éxito no es lo mismo que fracasar, aunque bastante de ellos sí que se podrían considerar un fracaso), podría ser algo que solo me pasara a mi, pero no es así, sucede con frecuencia y seguro que todos nosotros conocemos o hemos vivido proyectos con estos resultados.

La crisis del software sigue existiendo y existirá mientras no cambien muchas cosas. Los que nos dedicamos a esto tenemos muchos esquemas mentales que cambiar, son años haciendo los desarrollos de una determinada manera y también de formación centrada exclusivamente en metodologías clásicas.

El éxito o el fracaso de un proyecto no es exclusivo de las metodologías, pero sí predisponen a obtener unos resultados u otros.

Los proyectos de desarrollo de software tienen una naturaleza cambiante, es complicado acertar en todo: obtener los requisitos del usuario, la mecánica de comunicación entre usuario y sistema, la interfaz, etc… y lo es porque ni los usuarios tienen claro lo que quieren hasta que ven funcionalidades implementadas y también porque no siempre se interpreta adecuadamente por parte de los analistas o técnicos del proyecto las necesidades de los usuarios.

Metodologías de carácter eminentemente predictivo como las clásicas no son acordes con la naturaleza del desarrollo de software, habrá excepciones porque no existen llaves maestras que sirvan para todo.

Las metodologías ágiles, son adaptativas, son iterativas, incrementales. Sin embargo por encima de ellas está la propia filosofía del desarrollo ágil, realmente es la esencia, una vez entendida es mucho más trascendente que cualquier forma de llevarla a cabo.

Teniendo claro qué significa ser ágil, hasta su aplicación en metodologías clásicas las hace más flexibles.

En el año 2001 se reunieron en Salt Lake City diecisiete prestigiosos expertos en gestión de proyectos, ingeniería y desarrollo de software. La convocatoria la realizó Kent Beck, padre de la programación extrema.

En la reunión analizaron las problemáticas existentes en el desarrollo de software y en la necesidad de cambiar la forma en que se enfocaban y hacían los proyectos de desarrollo de software, lo cual dio lugar a unas conclusiones, recogidas en el manifiesto ágil.

En mi opinión, se trata de un manifiesto a favor del desarrollo de software, en su defensa, en la defensa de los que nos dedicamos a esta profesión ya que la mejor forma de dignificarnos es conseguir que la mayor parte de nuestros proyectos tengan éxito. Hay que romper con lo que no funciona, si el desarrollo de software es de una manera, actuar de otra es ir contra natura.

Los firmantes del manifiesto fueron las siguientes personas: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.

El contenido del manifiesto es el siguiente, primero pongo el original en inglés y a continuación su traducción:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

– Individuals and interactions over processes and tools.
– Working software over comprehensive documentation.
– Customer collaboration over contract negotiation.
– Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.”

“Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo 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.
– El software que funciona, por encima de la documentación exhaustiva.
– La colaboración con el cliente, por encima de la negociación contractual.
– La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.”

En el próximo artículo sobre esta materia comenzaré a exponer mi punto de vista sobre cada principio de los que componen el manifiesto.