Pensamiento colaborativo

El trabajar en el desarrollo de un producto de software requiere colaboración de un equipo. En este, cada persona debe enfocarse en el éxito colectivo. En esta presentación se habla acerca de los principios y organización de un equipo, se muestra un posible ejercicio para determinar los valores de un equipo y se introduce a la práctica de la programación en pares.

Transcript

1. Principios Pensamiento colaborativo ¿Cuál es su estrategia para crear un equipo efectivo? Oscar Centeno oscar.centeno@gmail.com Noviembre 2014
2. Lección de Hoy Personas y sus interacciones Ejercicio: Compartiendo valores Pair Programming
3. agilemanifesto.org Individuals and interactions over processes and tools We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: That is, while there is value in the items on the right, we value the items on the left more.
4. PARA CREAR SOFTWARE DEBEMOS COLABORAR Pensamiento colaborativo
5. La comunicación es clave • “Cuando no hay problemas de comunicación, un equipo puede rendir hasta un 50% más que el equipo promedio” Jeff Sutherland (http://msdn.microsoft.com/en- us/library/dd997578.aspx)
6. Ciclos de Inspeccionar-Adaptar Para fomentar la comunicación Minutos… Pocas horas… Cada día… Cada iteración… Pair programming Integración continua Daily Scrum Revisión y retrospectiva
7. Funciona sólo si existe • Respeto por cada persona • Verdad en la comunicación • Transparencia • Confianza en cada miembro del equipo • Compromiso con el equipo y sus metas
8. Barreras • Experiencias pasadas • “La honestidad causa conflictos” • “Hablar de impedimentos muestra debilidad” • “No se puede confiar en las personas” • “Las jefaturas no son sinceras” • “Si muestro compromiso me darán más tareas”
9. Respeto y Maslow http://en.wikipedia.org/wiki/Maslow's_hierarchy_of_needs
10. Respeto • Leer artículo “Lean Principle #6 – Respect People” (www.allaboutagile.com) • Enumerar en grupo qué consideramos respeto en nuestro lugar de trabajo.
11. Respeto por los empleados “No desperdicie las habilidades de las personas” W. Edwards Demming Leer artículo “Respect for Employees” (http://blog.deming.org/2013/06/resp ect-for-employees-dont-waste-the- ability-of-people/)
12. Respeto en el trabajo • Ambiente de trabajo seguro y ergonómico. • Involucramiento en establecer prioridades, resolver problemas y realizar mejoras. • Ser retado a alcanzar su potencial. • Ver que las ideas propias son adoptadas.
13. Compromiso • En Scrum… – Miembro de Equipo – Scrum Master – Dueño de Producto
14. Compromiso: El Dueño de Producto If you are a Team Member on a Scrum team and you get asked to do something that is outside the Sprint Backlog, you’ve GOTTA turn it over to the Product Owner to deal with - The Single Wringable Neck. Scrum Style. “Someone needs to be responsible for the decisions.” – Mike Vizdos
15. Verdad y Transparencia • Avances • Logros • Expectativas • Impedimentos • Proyecciones • Conflictos y decisiones
16. Confianza • ¿Cómo se crea confianza? En el día a día, cuando una persona hace lo que dice que hace. • Para integrar un equipo Agile, se debe conformar por personas que tengan las capacidades requeridas para poder confiar en ellas.
17. Confianza: Un equipo Agile • Multi-disciplinario • Tiene todas las habilidades para construir el producto terminado en una iteración corta: – Definir (elaborar y priorizar requerimientos) – Construir (escribir el código y sus pruebas) – Probar (validar la solución) • Se auto organiza. • Se auto administra.
18. Confianza: Un equipo Agile • Se confía en sus estimaciones. • Se confía en que darán visibilidad de impedimentos. • Es responsable de sus resultados. • Determina la mejor solución técnica. • Se confía de que siempre busca cómo mejorar.
19. Ejercicio (1)
20. Ejercicio (2) ¡Coloque sus tarjetas en la canasta! Distribuya las tarjetas.
21. Ejercicio (3)
22. Ejercicio (3) Cada uno leerá en voz alta. Estos son nuestros valores.
23. Ejercicio (4) Pizarra de Valores. Repita luego de 2 meses.
24. Implementar cambios es difícil… • Cuando quiera hacer un cambio, siempre recibirá oposición, excusas, comentarios negativos… ¿Vale la pena?
25. Práctica: Pair Programming • “All code to be sent into production is created by two people working together at a single computer.” – extremmeprogramming.org • “In pair programming, one person is programming and the other is thinking ahead, anticipating problems and strategizing” – The Art of Agile Development
26. Pair Programming Driver: codifica – se enfoca en que el código sea sintácticamente correcto. Navigator: piensa – piensa en lo que el driver escribe – asuntos estratégicos.
27. Estadísticas • “Pairing toma 15% más esfuerzo que el trabajo individual, pero produce resultados de mayor calidad con 15% menos defectos” Cockburn & Williams
28. Reglas • Aplique en todo código de producción. • El escritorio debe ser cómodo para ambos. • Deben sentarse al lado, frente al monitor. • La conversación es esencial – piense alto. • Como navigator, ¡no se enfoque en corregir los pequeños errores de sintaxis! “Te faltó el punto y coma” • Cambie de rol cada media hora al menos.
29. Resultados esperados • Mayor calidad. • Menos interrupciones. • Cansancio, pero satisfacción. • El código es compartido por el equipo. • Induce a cada persona a trabajar en equipo.
30. Bibliografía • Respect for the People the Lean Way: http://www.slideshare.net/KarenMartinGroup/re spect-for-people-the-lean-way • Sharing values in agile teams: http://www.solutionsiq.com/sharing-values-an- agile-team-building-exercise/ • Agile and trust http://www.solutionsiq.com/agile-and-trust/ • Scaled Agile Framework – Agile Teams http://scaledagileframework.com/agile-teams/
31. Bibliografía • The single wringable neck. http://www.implementingscrum.com/2009/0 1/12/the-single-wringable-neck-scrum-style/ • The Art of Agile Development, O’Reilly, Shore, 2007. • Pair programming http://www.extremeprogramming.org/rules/p air.html