Martin Fowler es uno de los grandes gurús del mundo software. Firmante del manifiesto Agile y creador de Thoughtworks, una de las empresas de referencia en cuanto a desarrollo de software se refiere. El pasado mes de mayo visitó España e impartió un par de ponencias. Tuve la oportunidad de asistir a una de ellas en el evento itSMF España 2018 donde nuestra compañera de café ágil Esther Peinado dió una ponencia excelente hablando del framework Argos.
Martin Fowler nos resumió en tres ideas principales cómo debíamos de pensar en cuanto a desarrollo ágil: Visión de Producto, Sprints de una semana y Atención a la Calidad. ¡Vamos a analizarlas!
Tabla de contenido
Visión de Producto
La visión de producto es algo que llevo defendiendo bastante tiempo. Cuando me sumergí en esto de Scrum siempre pensé que era una manera diferente de conseguir que los proyectos funcionaran. Sin embargo, a medida que ganas experiencia descubres que Scrum no puede ayudarte a terminar un software en una fecha concreta con un coste controlado ¡Es imposible! La visión de proyecto nace como consecuencia de querer controlar nuestro software con una visión de ingeniería. Algunos gurús como Martin o Tobias Mayer nos advierten de que el software está más cerca de la artesanía que de la ingeniería. Precisamente, los ingenieros se jactan de controlarlo todo. Sin embargo, los informáticos si algo hacemos es quejarnos del descontrol que hay siempre. ¡La visión de proyecto no nos ayuda!
Una mentalidad de producto consiste en entender que tenemos que añadir pequeñas piezas a nuestro software para mejorarlo. Significa tomar decisiones en base a lo que dice el mercado: nuestros usuarios principalmente. Esta visión de producto es la verdadera revolución que propone Scrum y es lo más difícil de cambiar en las organizaciones.
En el mundo de la consultoría, rfps, departamento de compras etc, cuesta introducir el concepto “no se lo que va a costar” pero es el reto de los Scrum Master y Agile Coaches trabajarlo. La visión de producto es la de maximizar valor, generar beneficio, buscar ganar dinero y no tanto controlar el coste.
Sprint de 1 semana
El primer equipo Scrum con el que trabajé estuvimos haciéndolo con Sprint de 1 semana. Podríamos pensar que lo hicimos porque éramos muy ágiles, pero la verdad que no fue así. Nuestro Producto Owner pensaba que dar más tiempo al equipo iba a ser un descontrol, y tenía razón, teníamos que ganarnos más confianza.
He trabajado con pocos equipos que se atrevieran a tener Sprint de 1 semana. No es que sea obligatorio, y depende del contexto. Estoy convencido de que muchos de los equipos que he acompañado podrían haberlo intentado. Muchas veces no lo hacen porque aún tenemos el gen del waterfall de esperarnos al final para subirlo todo, y eso lleva tiempo.
En los Sprint de una semana se ve lo ágil que es un equipo. Pensad en la Sprint Planning, lo único que habría que hacer es contestar a una pregunta ¿Qué hacemos esta semana? La retrospectiva sería más ejecutiva, tenemos 45 minutos para pensar en una mejora para la semana que viene, si nos equivocamos no pasa nada porque solo son cinco días de trabajo.
Atención a la calidad
El concepto calidad es complicado hoy en día. Ninguna empresa va a decir “trabajo sin calidad”. De hecho, estuve en una organización que tenía el lema “con la calidad no se negocia”. Realmente, si estás negociando con tu cliente un alcance en fecha, estás negociando la calidad. ¿Por qué? Si miramos al triángulo de hierro, veremos que si el alcance es fijo, el tiempo es cerrado y el coste controlado ¿Qué nos queda variable? ¡La calidad! Por eso muchos equipos acaban por reducirla con tal de llegar. Después, tratamos de arreglarlo con un “en la fase dos lo hacemos” pero nunca hay tiempo.
Tobias Mayer reflexionaba que en los proyectos la calidad no era importante porque precisamente se basaban en la premisa de entrega en fecha. Por eso, la calidad no suele ser relevante en los proyectos. En al visión de producto la calidad es clave, si queremos perdurar en el tiempo tenemos que tener una calidad que nos permita retener al usuario y ofrecerle una experiencia de calidad.
Hacer ver a un cliente que la calidad es parte del desarrollo software es difícil. He visto a varios equipos conseguirlo y entregar con muchísima calidad, al final, los clientes lo valoran. A largo plazo la calidad reduce muchos costes de mantenimiento y por eso, tener un poco de paciencia nos ayuda a demostrarlo.
Además, atender la calidad tiene un efecto colateral. Los mejores profesionales que desarrollan software no quieren entregar cutradas, les gusta el buen desarrollo. Hacer calidad es conseguir que se sientan orgullosos de su trabajo y eso redunda en la atracción y fidelización del talento.
¿Cómo vas a cambiar?
Estos consejos de Martin Fowler a mi me han inspirado, porque me han hecho pensar que no estamos tan lejos de lo que queremos llevar a las organizaciones. El cambio es difícil, pero si los mejores apuntan en esa dirección ¿por qué no intentarlo?
Entradas relacionadas
La estimación tenía un precio0 (0)
Comentarios recientes