En el desarrollo de software, nos encontramos con un conjunto de muros contra los que nos golpeamos una y otra vez. Describiremos algunos de los más típicos, y cómo levantaremos puentes con las metodologías ágiles para salvarlos.

1

¿qué mueve el mundo? Foto: http://www.flickr.com/photos/49120045@N03/4501214175/

2

Generalmente decimos que ¡el amor mueve el mundo! Pero no nos quedemos con esta visión romántica, por que… Foto: http://www.flickr.com/photos/vegard/193666911/sizes/z/in/photostream/

3

…realmente, ¿qué controla el mundo? Foto: http://www.flickr.com/photos/monte-biju/6707585301/

4

El software! Foto: http://www.flickr.com/photos/beatkueng/5182116596/sizes/z/in/photostream/

5

La responsabilidad es nuestra, de los desarrolladores de software. Nosotros somos los responsables de qué hacemos y cómo hacemos. Nosotros tenemos el control. Cuatro casos relevantes. 1) Google presenta las gafas de realidad aumentada. El mérito del invento es el control preciso que necesita de los datos, de tu posición, de dónde miras, de lo que te interesa, de lo que elige ofrecerte en cada momento como información, de los datos que recopila… todo, controlado por software. Alguien programó lo que vas a ver por el resto de tu vida. 2) Si tienes un smartphone, ¿cuántas horas, cientos, miles o millones de horas, llevas dedicadas al desarrollo en el bolsillo? ¿cuántas noches de programadores sin dormir? ¿de pizzas a las 10 de la noche en una oficina? ¿cuánta dedicación? 3) Un altísimo porcentaje de las operaciones en Bolsa, hoy en día son controladas por algoritmos implementados en software. ¿qué puede suceder ante un fallo, o un abuso de poder? 4) En el futuro, la investigación en los robots dará resultados impresionantes. ¿quién los controla?

6

Hay un dicho que nos gusta y es que para conocer a una persona no hay que preguntarle lo que piensa si no que es lo que verdaderamente le gusta y le hace feliz. En base a esto, vamos a presentarnos.

7

8

9

Foto: http://www.flickr.com/photos/sudhamshu/3202963823

10

Estamos aquí, porque hace unos diez años más o menos estábamos al otro lado. Sin saber qué nos depararía el futuro y con ganas de que alguien nos contase algo. Estamos aquí porque tenemos una historia a cuestas que nos ha marcado. Cuando estaba a punto de terminar la carrera no teníamos claro nuestro futuro, pero nos lo imaginábamos como un bonito amanecer (foto amanecer). Un largo camino por recorrer, empezando como programadores para algún día llegar a ser jefe de proyecto. Para programar estaría la gente de FP. Terminamos la carrera y nos lanzamos al mundo profesional. Desde fuera todo parecía bonito (foto huracán): has terminado la carrera y tienes un trabajo de lo tuyo! Pero la realidad es que desde dentro se ve diferente. Te encuentras metiendo horas, haciendo cosas que te dicen que sabes que se pueden hacer mejor, te aburres, deseas cambiar de trabajo…. Al cabo de los años, 5 en mi caso, te das cuenta de que no has avanzado a penas: no tengo 5 años de experiencia si no que uno repetido 5 veces (foto espiral). En este punto conocí a Joserra que se había embarcado en un nuevo proyecto para crear una oficina en San Sebastián desde 0 (foto oficina vacía). Poco a poco fuimos creciendo y la oficina se fue llenando de personas que trabajábamos juntas (foto trabajando). La diferencia con respecto a trabajos anteriores: las personas eran importantes. La confianza entre las personas era importante. La transparencia era importante. Llegamos a convertirnos en una pequeña familia (foto bikodonosti-family)

11

Por eso estamos aquí. Porque existe una forma de trabajar distinta que hace que las personas se sientan realizadas. Porque existe una forma de trabajar que nos ha hecho ser felices. Fotos: Amanecer: http://www.flickr.com/photos/tpenalver/2087638944 Huracán: http://www.flickr.com/photos/gsfc/6086341900/

11

Nuestro objetivo, nuestro fin, es ser felices haciendo lo que hacemos. Creando software. La felicidad no es ser jefe de proyecto La felicidad no es ser programador. La felicidad está en poder decidir cómo trabajamos, y en poder ser partícipe de la creación de proyectos e ideas. Foto: http://www.flickr.com/photos/pinksherbet/4463360814

12

Pero esto no es fácil. Para llegar a esto tenemos que derribar los muros que nos encontramos por el camino. ¿Cuáles son estos muros? Foto: http://www.flickr.com/photos/oshkar/2914122863/

13

Estas leyes estaban escritas en un pergamino ¡de la era de los romanos! ;) Sin embargo, no terminamos de creérnoslas, e intentamos esquivarlas escribiendo más requisitos al principio, protegiéndonos de manera más cerrada contra los cambios, y prometiendo que las cosas siempre estarán en la fecha estimada. Foto: http://www.flickr.com/photos/devontt/167285659

14

Salimos de la carrera y nos encontramos así: flotando con otras personas con las que no sabemos como trabajar. Recibimos formación sobre como trabajar con máquinas pero no con personas. Alguien nos ha explicado ¿Cómo liderar? ¿Cómo motivar? ¿Cómo generar confianza? ¿Qué es la empatía? El desarrollo de software va más allá de picar código, el desarrollo de software es un juego colaborativo entre personas. Foto:

15

No nos enseñan a comunicarnos y además usamos las herramientas inadecuadas. Un diagrama de Gantt no se puede usar como una herramienta de comunicación. Los canales escritos reducen el ancho de banda de la colaboración. Creamos pequeños ejércitos de programadores/analistas, donde no les dejamos comunicarse más que a través de canales mediocres: email, documentos, etc. Donde cada uno ve una parcelita del proyecto. Pero luego jugamos al teléfono roto con los proyectos, pues el cliente habla con el jefe de proyecto, que pasa la información a los análistas senior, que a lo mejor generan documentación para los programadores,… y hemos perdido muchísima información por el camino. Fotos: http://www.flickr.com/photos/basel/105997652 http://www.flickr.com/photos/d35ign/6226852671 http://www.flickr.com/photos/legofenris/4641828205

16

No creamos ambientes de colaboración sin comunicación, sin confianza. La falta de comunicación impide muchas veces ver lo que realmente sucede en un proyecto, los intereses ocultos impiden que la colaboración en post del éxito sea total. Así es imposible colaborar en la búsqueda de un objetivo común.

17

Si seguimos haciendo las cosas como las hemos hechos siempre, tiene poco sentido esperar que el resultado vaya a cambiar. Las cosas no cambian por ciencia infusa. ¡Cambiemos la forma de hacer las cosas!

18

Tradicionalmente ser programador venía a ser algo parecido a hacer las ranitas de papel de la imagen. Recortar un lado de la hoja y seguir las instrucciones, que en el mundo del software se traduce en: recibir una especificación y plasmarla en código. El cliente se reúne con el jefe de proyecto, este con el analista funcional, este con el analista, ….. Así hasta crear la especificación que llega al programador. No hay margen a la creatividad. No hay posibilidad de utilizar nuestra imaginación. Hacemos lo que hay que hacer, seguimos los pasos y así una y otra vez. Foto: http://www.flickr.com/photos/jacquedavis/3051222260/

19

Repetir una y otra vez lo mismo, sin posibilidad de aportar nada conlleva aburrimiento y merma la motivación. Cada persona puede tener su propia motivación, y la tiene! Poder decidir sobre su propio trabajo, motiva. Ver la película completa, motiva. Aprender, motiva… Estar motivado en el trabajo es básico. Foto: http://www.flickr.com/photos/assbach/220318384

20

En lugar de crear ranitas de papel con un recortable y unos pasos, el programador realmente es una persona creativa que conoce la necesidad del cliente y construye el software. Es algo similar a un lego: dadas las piezas y el objetivo, el programador crea el software, basándose en su creatividad. Todo el equipo habla con el cliente, todo el equipo opina y todo el equipo decide qué hacer y cómo hacerlo. Este modelo si que favorece motivación. Es una estructura sin jerarquías, donde solo importan las personas: completas, creativas y llenas de recursos. Foto: http://www.flickr.com/photos/kenjiys/3173014217/

21

Nosotros conseguimos nuestro objetivo de felicidad (pelotitas verdes), pero no debemos descuidar al cliente (pelotita amarilla). Nuestro objetivo debe ser que el cliente sea feliz. Es algo muy sencillo: tiene que tener lo que necesita. Para ello, tenemos que acertar en la diana de sus necesidades.

22

El enfoque más tradicicional de la gestión de proyectos pone el foco en el arranque del proyecto, donde se generan toda clase de artefactos y un plan detallado de por dónde debe marchar el proyecto para ir correctamente. Pero planeamos el disparo, y luego descubrimos vientos o problemas nuevos con los que no contábamos, y que la dirección a la que debíamos apuntar no era la correcta.

23

Los proyectos ágiles son como un misil teledirigido

Hipótesis:

El cliente va descubriendo lo que quiere

Los desarrolladores descubren cómo construirlo

Las cosas cambian durante todo el desarrollo

Realizamos ciclos cortos de desarrollo, comprobando tras cada uno de ellos, si vamos en la buena dirección, o tenemos problemas para solucionar.

24

El puente que nos permitirá saltar los muros serán la metodologías ágiles. Cambiar el enfoque básico para afrontar los proyectos software. http://www.flickr.com/photos/ecstaticist/902533511/

25

¿Dónde aparecen las metodologías ágiles? Se llaman así desde la escritura del manifiesto ágil, donde se plasmó lo que se consideró buenas prácticas y valores que expertos habían observado que contribuían al desarrollo con éxito del software. http://agilemanifesto.org/iso/es/ Existen muchas metodologías ágiles, siendo algunas de las más extendidas: Scrum o eXtremmeProgramming (http://www.extremeprogramming.org/).

26

Las personas son el ingrediente principal. Personas que trabajan en equipos autoorganizados: • Participan en la creación de la oferta y en su estimación • Cada día se reúnen y deciden qué van a hacer el resto del día • Si terminan algo saben con qué van a seguir, no dependen de un jefe que les diga

qué hacer y como Resultado: personas comprometidas que saben qué hacer y cómo en cada momento.

27

¡Divide y vencerás! Dividimos el producto y el tiempo. • Dividimos el producto en pequeñas funcionalidades y hacemos que el cliente las

ponga ordenadas por prioridades. • Fijamos periodo en el cual vamos a “crear” software (iteración). El equipo junto

con el cliente detallan las funcionalidades más prioritarias a desarrollar en ese periodo de tiempo.

• El equipo estima más fácilmente esas funcionalidades y adquiere un compromiso: al final de ese periodo de tiempo el cliente tendrá la funcionalidad a la que se ha comprometido el equipo

• Obtenemos feedback del cliente, para saber si vamos por buen camino tras cada iteración y poder así rectificar nuestro rumbo (cambiamos de rumbo al misil)

28

Tras cada ciclo, en reuniones de retrospectiva, analizamos qué cosas han funcionado y cuáles no. Qué problemas ha habido, y qué soluciones podemos tomar. Trabajamos para no dejar de mejorar, en ciclos cortos, que nos permiten aprender rápidamente si vamos por el camino correcto. Tratamos mejoras a nivel global del equipo, tanto mejoras técnicas como de comunicación, personales, problemas de colaboración, etc. Todo aquello que nos permita mejorar nuestro producto software.

29

Creamos espacios de confianza, y la transparencia es fundamental. Se utiliza mucho la información pública en forma de tablones, que representan los proyectos de manera explícita, permitiendo a cualquier persona conocer el estado de un proyecto o producto y el equipo. Esta transparencia es básica para lograr una buena comunicación, y nos permite sentar las bases de la confianza entre todas las partes implicadas.

30

http://www.flickr.com/photos/royskeane/413103429/

31

32

33

34

¿Cómo lo hacemos utilizando Scrum? • El equipo se reúne con el cliente para tener una visión general global: todos

conocemos qué necesita el cliente. • El resultado es una pila de funcionalidades: Product Backlog. Es imposible capturar

todos los requerimiento al comienzo del proyecto y sean cuales sean seguro que cambiarán: así que son especificaciones de funcionalidad a grandes rasgos, sin mucho detalle.

• El equipo planifica una iteración o sprint. Para ello, se basa en las funcionalidades más prioritarias del Product Backlog que desgrana junto con el cliente, para llegar a un nivel de detalle máximo.

• Como resultado de la planificación, el equipo tiene una pila de funcionalidades que se ha comprometido a tener lista para el final del sprint: Sprint Backlog.

• El sprint dura entre 1 y 4 semanas. Cada día de ese sprint, el equipo se reúne 15: Daily Scrum. En esta reunión, cada miembro del equipo cuenta: qué ha hecho el día anterior, qué impedimentos se ha encontrado y qué va a hacer el resto del día. Esto favorece la comunicación entre los miembros del equipo, la colaboración y la posibilidad de detectar desvíos en lo planificado para el sprint y poder hablar con el cliente.

• Al final del sprint, el resultado es que el equipo ha generado un incremento de software con las funcionalidades a que se había comprometido y se lo enseña al cliente en una demo. Así el cliente es capaz de ver lo que se está construyendo,

cómo se está haciendo y si es lo que el quiere realmente (feedback del cliente) • Al final del sprint, además el equipo se reune para ver qué impedimentos se han

econtrado y qué tienen que cambiar para hacer mejor las cosas: Retrospectiva de sprint. Siempre se puede mejorar (mejora contínua), estas reuniones ayudan al equipo a identificar qué han hecho bien para potenciarlo y qué han hecho mal para poder poner remedio.

34

Existen tres roles definidos en Scrum • Producto Owner: El “propietario del producto” es el único representante de

todos los interesados en el proyecto. Puede ser interno o externo. Define

los objetivos, los prioriza y dirige los resultados del proyecto para

maximizar el ROI. • Equipo: El equipo es multidisciplinar, autogestionado y comparte un

mismo objetivo. Normalmente cada equipo es de 5 a 9 personas*, que

trabajan en un espacio común para permitir la comunicación cara a cara y que se sincronizan diariamente. Realiza las estimaciones.

• Scrum Master: Facilitador de la colaboración intraequipo y con el cliente

(por ejemplo en las reuniones de Scrum) y quita impedimentos para que

el equipo se mantenga enfocado. Es el responsable del proceso. Impide

interferencias externas.

35

Scrum es un marco de gestión de equipos (y de proyectos), pero no debemos olvidar la parte técnica, fundamente en cualquier desarrollo de software. Extremme Programming es una metodología para el desarrollo de software completa, pero incluye las prácticas técnicas más básicas para garantizar que podemos desarrollar software de calidad, y muchas veces tomamos estas técnicas de XP y gestionamos el proyecto con Scrum. Prácticas como Test Driven Development o Continous Integration han sobrepasado ya incluso la frontera de las metodologías ágiles, y se reconocen como básicas en la ingeniería del software.

36

37

Escribe tu propia historia. Nunca te desanimes en el camino a la meta, recuerda que todo en la vida se trata de superar obstáculos.

38

Acércate a tu comunidad local de Agile-Spain, y ven a aprender con nosotros http://agile-spain.org/ En la zona norte nos juntamos en Durango (normalmente) una vez al mes para hablar de nuestras experiencias o intereses, somos Agile-Norte (síguenos en @agileNorte) Eventos recomendables: • AOS2012 (Agile Open Space 2012 ) – 23 de junio en Zaragoza -

http://aos2012.wordpress.com/ • Conferencia Agile-Spain (CAS2012) – sobre Octubre en Cáceres Lecturas interesantes: • Descargable y traducido por la comunidad, un libro muy ameno:

http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf

• Un libro sobre TDD : http://www.dirigidoportests.com/el-libro Un grupo que está arrancando dedicado a la puesta en práctica de los principios Agile/Lean con relación a la creación de nuevas empresas: Agile Entrepreneurship Euskadi http://www.meetup.com/Agile-Entrepreneurs-Euskadi/

39

40

41