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?
Introducción¿Por qué hablar de “ellos”?
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 herramientas○ Interacciones entre individuos○ Interacciones entre equipos
● Software en funcionamiento > documentación extensiva○ Entrega de documentación útil: Suficiente y necesaria
● Colaboración con el cliente > negociación contractual○ Interactuar como miembros del mismo equipo
● Respuesta ante el cambio > seguir un plan○ Entender los cambios para responder de la mejor manera○ Entregar valor○ Negociar
7
¿Qué dice la teoría... Y qué pasa en la práctica?
¡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 ágiles● Queremos 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 veloz● No 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
¿Cómo lograr el involucramiento?Logremos este objetivo en el día a día.
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ácticos○ Taller, mesa de trabajo sobre las particularidades de nuestra
metodología para los stakeholders○ Taller, 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ácticos○ Puntualidad, ¡Por favor!○ Reuniones periódicas sobre el avance del proyecto○ Priorización conjunta○ Gamification?
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ón● Sesiones de priorización● Feedback periódico y constructivo
16
● Consejos prácticos○ Seamos flexibles, pero asertivos○ No subestimar las conversaciones informales○ Las 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ácticos○ En las reuniones, procurar que el equipo se mezcle○ Reconocer y recompensar los logros del equipo○ Mostrar las ventajas de tener un equipo heterogéneo y
multidisciplinario○ Compartir las sesiones de estimación○ Fomentar 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ón○ Ofrece al cliente una perspectiva
diferente de sus propias necesidades● Cambio gradual
○ Es más fácil de manejar y digerir○ Genera 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
