¿Que es lo que mueve al mundo? ¡El amor! Vale... pero... ¿qué es lo que realmente lo controla? ¡El software! El desarrollo de software va más allá de lo que nos enseñan en la facultad de informática. Más allá de computación numérica, ingeniería del software y arquitectura de computadores, necesitamos habilidades que debemos desarrollar en nuestra carrera profesional. Así seremos capaces de entrar en un ciclo de mejora continua. Nos centraremos en lo más importante: en las personas. Nos centraremos en la colaboración con el cliente y en la respuesta al cambio. Objetivos: crear software de calidad y la felicidad. Movamos el mundo. Por Jessica Aguado y Jose Ramón Díaz

1. 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

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

3. 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

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

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

6. 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

7. 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. 8

9. 9

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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. ¿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

28. 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

29. ¡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

30. 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

31. 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

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

33. 32

34. 33

35. ¿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,
34

36. 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

37. 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

38. 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

39. 37

40. 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

41. 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

42. 40

43. 41