clientes y usuarios: de enemigos a aliados
TRANSCRIPT
CLIENTES Y USUARIOS:DE ENEMIGOS A ALIADOS
Poniendo el manifiesto Ágil en práctica
María José Ormaza
ABRIL 2015
AGENDA
INTRO ¿Qué dice el manifiesto
Ágil?
¿Qué dice la teoría y qué pasa en la práctica?
¿Cómo lograr el involucramiento
?
¿Por qué es importante hablar de algo tan obvio?
El agilismo como
herramienta de cambio
Revisemos el manifiesto Ágil y entendamos su enfoque en el elemento humano.
En el hermoso mundo de la teoría, todo marcha sobre ruedas. No siempre en la práctica sucede lo mismo.
La relación con los clientes / usuarios se construye día a día. ¿Cómo podemos hacerlo mejor?
¿Cómo usar las metodologías ágiles para promover el cambio?
La necesidad de tener stakeholders comprometidos
Cockburn, A., & Highsmith, J. (2001). Agile software development: The people factor. Computer, 34(11), 131-133.
Es imposible entender un problema ajeno si no te lo cuentan
Escenarios imprevistos: Si lo puedes imaginar, puede pasar.
Cuanto más entendamos las necesidades (y los cambios), mejor podremos solucionarlas
Cuando el equipo se integra, la colaboración fluye naturalmente
El objetivo no es construir un “sistema”, sino construir una SOLUCIÓN
4
¿Por qué no siempre sucede?
Cohn, M. and Ford, D., 2003. Introducing an agile process to an organization. Computer 36 (6), 74–78.Nerur, S., Mahapatra, R.K., Mangalaraj, G., 2005. Challenges of migrating to agile methodologies. Communications of the ACM 48 (5), 72–78.
Las metodologías tradicionales no fomentan la colaboración a lo largo de los proyectos
La documentación abruma a los stakeholders
Los equipos de desarrollo intentan que el cliente entienda su idioma en lugar de entender al cliente
Los clientes pierden el interés cuando los proyectos son largos y no se ve ningún resultado
5
¿Qué dice el manifiesto Ágil?Y qué significa eso en términos de la relación con los clientes y usuarios.
Revisemos un poco...
Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development,9(8), 28-35.
Individuos e interacciones > Procesos y herramientasInteracciones entre individuosInteracciones entre equipos
Software en funcionamiento > documentación extensivaEntrega de documentación útil: Suficiente y necesaria
Colaboración con el cliente > negociación contractualInteractuar como miembros del mismo equipo
Respuesta ante el cambio > seguir un planEntender los cambios para responder de la mejor maneraEntregar valorNegociar
7
¡No nos entendemos!
Racheva, Z., Daneva, M., Sikkel, K., Herrmann, A., & Wieringa, R. (2010, September). Do We Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study. In RE (pp. 147-156).
Queremos hablar en los mismos términos
El proyecto se terminará rápido, muy rápido
Queremos stakeholders ágilesQueremos mejorar sus procesos y
hacerlos más eficientes
9
Los stakeholders no entienden nuestra metodología y el equipo de desarrollo no entiende el negocio
Ágil no implica velozNo contemplamos los casos “raros”“Ellos” no saben lo que quieren y “nosotros” no entendemos por qué lo quieren
Expectativa Realidad
¡Involucremos a todos! ¿Quiénes son todos?
Racheva, Z., Daneva, M., Sikkel, K., Herrmann, A., & Wieringa, R. (2010, September). Do We Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study. In RE (pp. 147-156).
10
Todos los stakeholders estarán involucrados
Tendremos que cubrir las aristas necesarias para construir las funcionalidades necesarias
Visión global, involucramiento incremental
Hay stakeholders importantes que no están interesados
Los interesados en cada arista de negocio tienen diferentes prioridades
Todos quieren que su parte se construya primero, a más detalle, más rápido, con más recursos...
Expectativa Realidad
¡No hay tiempo!
Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. Software, ieee, 22(5), 30-39.
11
Los stakeholders estarán prestos a asistir a las sesiones de priorización, análisis, firma de historias
Se encontrará el tiempo estratégico en que el equipo de desarrollo se involucre en el negocio
Los stakeholders suelen tener un tiempo limitado. Muy limitado.
Cuando las personas idóneas no pueden asistir, otras personas menos adecuadas las reemplazan
El tiempo del equipo de desarrollo se puede ver segmentado para ajustarse al tiempo del negocio
Expectativa Realidad
“Siempre hemos trabajado así”
12
Los stakeholders aprenderán de nosotros y nosotros de ellos
Será fácil para ellos entender nuestros términos porque son menos técnicos que en las metodologías tradicionales
¿MVP? ¿Puntos? ¿Sprints? ¿Iteraciones? ¿Velocidad?¿Burn.. what?¿Cómo que no sabemos cuántos días y horas tomará terminar el proyecto?
Expectativa Realidad
Hablemos el mismo idioma
Racheva, Z., Daneva, M., Sikkel, K., Herrmann, A., & Wieringa, R. (2010, September). Do We Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study. In RE (pp. 147-156).
Es VITAL introducir la metodología en las fases más tempranas del proyecto
El equipo de desarrollo debe tener una visión holística de los problemas a resolver
14
Consejos prácticosTaller, mesa de trabajo sobre las particularidades de
nuestra metodología para los stakeholdersTaller, mesa de trabajo sobre las particularidades del
negocio para el equipo de desarrollo¿Aún así no nos entendemos? Cambiemos la estrategia e
intentémoslo nuevamente
Compartamos la estrategia
Dorairaj, S., Noble, J., & Malik, P. (2010). Understanding the importance of trust in distributed Agile projects: A practical perspective. In Agile Processes in Software Engineering and Extreme Programming (pp. 172-177). Springer Berlin Heidelberg.
No dejemos de hablar nuestro idioma, pero entendamos también el suyo
Ambas partes del equipo deben conocer qué y por qué se hace
15
Consejos prácticosPuntualidad, ¡Por favor!Reuniones periódicas sobre el avance del proyectoPriorización conjuntaGamification?
Promovamos la conversación
Ambler, Scott. Active Stakeholder Participation: An Agile Best Practice. http://agilemodeling.com/essays/activeStakeholderParticipation.htm
Saquemos el mayor provecho de la incepciónSesiones de priorizaciónFeedback periódico y constructivo
16
Consejos prácticosSeamos flexibles, pero asertivosNo subestimar las conversaciones informalesLas discusiones deben llegar a acuerdos.Evitemos frases generalizadoras de estilo “Como todos
sabemos...”
No somos Nosotros VS. Ellos, somos Nosotros Y Ellos
El equipo debe verse como un todo que persigue el mismo objetivo
Motivar la participación conjunta del equipo de desarrollo con el cliente
17
Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. Software, ieee, 22(5), 30-39.
Consejos prácticosEn las reuniones, procurar que el equipo se mezcleReconocer y recompensar los logros del equipoMostrar las ventajas de tener un equipo heterogéneo y
multidisciplinarioCompartir las sesiones de estimaciónFomentar la participación del equipo de desarrollo en sesiones de
feedback, retrospectivas, mesas de trabajo
El Agilismo como herramienta de cambio“Hacer la misma cosa una y otra vez; y esperar resultados distintos es locura.”
A. Einstein
El legado de nuestros proyectos
Adler, P. S., & Shenhar, A. (1990). Adapting your technological base: The organizational challenge. Sloan Management Review, (32)1, 25–37.Boehm, B., Turner, R., 2005. Management challenges to implement agile processes in traditional development organizations. IEEE Software 22 (5), 30–39. 19
Cambio de mentalidad sobre el uso de la tecnología
PriorizaciónOfrece al cliente una perspectiva diferente de sus propias necesidades
Cambio gradual Es más fácil de manejar y digerirGenera menos resistencia
Canales de comunicaciónFormal Informal
RelaciónNegativa Positiva
DisponibilidadIrregular Continua
ParticipaciónReactiva Proactiva
InteracciónFacilitada Activa
Ambler, Scott. Active Stakeholder Participation: An Agile Best Practice. http://agilemodeling.com/essays/activeStakeholderParticipation.htm
El legado de nuestros proyectos
Momentos claves
Cada contacto con el cliente es una oportunidad para fomentar su participación (en el contexto adecuado)
Aprovechar iteraciones productivas para estrechar relaciones con los clientes
La mejor forma de involucrar a los clientes y usuarios dependerá de la naturaleza del proyecto, el equipo humano, las restricciones temporales, ...
No construyamos para los clientes. Construyamos juntos.
21