Este documento presenta una discusión sobre la usabilidad de las prácticas y procesos de desarrollo de software. Se propone que la usabilidad se refiere a qué tan fácil es seguir una práctica o proceso, incluyendo el esfuerzo necesario para aprenderlo y la probabilidad de cometer errores. El documento describe una actividad para que los participantes evalúen ejemplos de prácticas y procesos usando criterios de usabilidad como "menos es más", "devolución de comentarios" y "tolerar errores".

1. Usabilidad de
Prácticas y
Procesos
Diego Fontdevila
©The M.C. Escher Company B.V.
@dfontde
diego. font dev ila @gr upoe sfe ra. com.ar

2. Reconcebir es cambiar
nuestras ideas a la luz de
las ideas de los demás
Rob Austin y Lee Devin

3. Plan
● Introducción (10min)
● Actividad 1: En parejas, uno cuenta una
práctica
● Usabilidad aplicada a prácticas y
procesos.
● Actividad 2: En grupos, discutimos la
usabilidad de prácticas o procesos de
desarrollo.
● Evaluación en común de las prácticas
discutidas mediante criterios de usabilidad.
● Retrospectiva (10 min)

4. ¿Por qué práctica y
proceso?

5. El Proceso es el flujo de
trabajo, productos e
información para coordinar
las actividades de
distintos participantes,
para producir valor.

6. La práctica describe las
actividades compartidas y la
experiencia de hacer el
trabajo.

7. Actividad 1: Una práctica

8. “Your company may define your job as
processing 33 medical claims a day
according to certain standards, but the
competence required to do this in
practice is something you determine with
your colleagues as you interact day after
day”
John Seely Brown and Paul Duguid

9. Pregunta
¿Sirve aplicar principios y
heurísticas de usabilidad
para evaluar si una práctica
o proceso le conviene a una
organización?

10. Un ejemplo por favor
● Scrum parece fácil
● ¿XP parece difícil? (High Disc.)
● Registrar esfuerzo (en TSP) en
minutos parece molesto.
● ¿Suena lógico que el equipo sea
quien haga el plan?
● La auto­organización resulta
difícil de vender

11. Usabilidad de Prácticas
y Procesos
Una medida de cuán fácil es
seguir una práctica o proceso,
incluyendo el esfuerzo necesario
para aprenderla, la probabilidad
de cometer errores, el costo de
esos errores y la satisfacción y
motivación general promovida por
seguir esa práctica o proceso.

12. Actividad 2: Ejemplos de usabilidad de
prácticas y procesos

13. Criterios de usabilidad
● Menos es más
● Corresondencia
Natural/Affordance
● Modelos mentales consistentes
● Tolerar errores
● Funciones restrictivas
● Devolución (Feedback)

14. Menos es más
● Simplicidad (KISS)
● Implica menor complejidad
● La confianza ayuda
● Eliminemos o reemplacemos overhead
● Ejemplos
● Contratos más simples
● Timeboxing
● Limitar los datos recolectados
● Automatizar

15. Devolución (Feedback)
● Si da resultado, tiendo a insistir
● Métricas
● De cerca ¿Son evidentes las ventajas y
desventajas?
● Si la usamos inapropiadamente ¿Tiene algo
que decir al respecto?
● Ejemplos
● Build de 10'
● Integración Continua
● Revisiones

16. Correspondencia Natural/
Affordance
● ¿Para qué sirven nuestras
prácticas?
● ¿Nos sirven a nosotros o a otros?
● Ejemplos
● ¿Las pruebas están para encontrar
defectos?
● Integración continua

17. Actividad: La cajita

18. Modelos Mentales
Consistentes
● ¿Qué áreas/departamentos involucra? Los
procesos integran distintas prácticas
● ¿Qué piensan ellos de nosotros? ¿Cómo
nos gustaría que fueran ellos?
● Conocimiento mutuo (Sabemos que saben)
● Ejemplos
● Programación de pares
● CMMI
● Desarrollo vs. Operaciones

20. Actividad: ¿Cómo nos ven?
¿Cómo queremos que sean?

21. Tolerar errores
● ¿Cuán riesgosas son mis prácticas?
● ¿Qué consecuencia tiene un error? (Bridget
Jones)
● Ejemplos
● Pruebas automatizadas
● Propiedad compartida del código
● ¡Un aplauso!
● Wise fool (Coplien y Harrison)
● ¿Se usan las métricas para juzgar?(Tobías)

22. Actividad: Rueda de sillas

23. Funciones restrictivas
● Limitan el daño de un proceso o
práctica mal ejecutado.
● Ejemplos
● 40hs por semana
● Timeboxing
● Compromisos controlados por el
equipo

24. Actividad: Aprender a armar un...

25. ¿Entonces?
Actividad: Evaluar un ejemplo

26. Checklist por Criterio de
Usabilidad

27. Menos es más
● 1.1 Is the team prejudiced against the practice or
process? (e.g. Is it perceived as non value adding? Ryan's
skeptic patterns and recommendations might help deal with
such prejudice)
● 1.2 Is there a way to optimize, automate, replace or
eliminate the practice or process? (Keep in mind that all
of these usually require first mastering the practice or
activity to be able to make informed decisions)
● 1.3 Are all records created actually used?
● 1.4 Are activities time­boxed?
● 1.5 Is the process or practice easy to adapt to remove
non value added elements?

28. Devolución (feedback)
●
1.1 Does the process or practice provide feedback? Are results visible?
(e.g. Iterative and incremental processes, continuous integration practice)
●
1.2 Is the feedback timely? Are activities performed frequently enough to
allow appropriate reactions? (e.g. are architecture reviews performed before
much rework will emanate from that feedback)
●
1.3 Do they provide positive feedback? (i.e. make the job more satisfactory
for those involved)
●
1.4 Do they promote collaboration with others that might provide feedback?
●
1.5 Are there related issues in the organization that no one will
acknowledge? (A Wise Fool who points them out might help)

29. Correspondencia natural
● 1.1 Are the practices aligned with the team's community of practice?
In other words, do they make up the competences that define the
identity of those belonging to the community? (e.g. do they make a
good tester or architect)
● 1.2 Are practice and process purposes clear to practitioners?
● 1.3 Are process and practices described using a language/terminology
that matches the team's own?
● 1.4 Are those goals meaningful at the team/department level or
mainly at the organizational level?
● 1.5 Are practices focused in a single purpose or do they serve
multiple purposes?
● 1.6 Do the practices work well by themselves? (e.g. continuous
integration requires automated builds).
● 1.7 Do they work better in conjunction with others (e.g. continuous
integration and test automation, or risk management and iterative
projects, the second is not a requirement but certainly improves the
results of the first).

30. Modelos mentales
correspondientes
● 1.1 Do process activities match the practices of the team?
● 1.2 Does the activity involve participants from different
communities of practice? (e.g. Joint Application Design sessions
and Scrum Product Reviews usually put together both developers and
business stakeholders)
● 1.3 Are the participants experienced or trained in the practice
or process?
● 1.4 Does the practice or process's conceptual model match the
conceptual model the team has of the same activities? (e.g. not
true in the case of pair programming, where we have two people
working at one workstation).
● 1.5 Does the preconceived conceptual model the team has of the
practice or process match the actual conceptual model? (remember
Ryan's Burned skeptic pattern).

31. Tolerar errores
● 1.1 Does the organization foster innovation?
● 1.2 Does the organization provide a safe environment for learning?
● 1.3 Does the organization provide a safe environment for work?
● 1.4 Is feedback timely enough that the cost of fixing defects is low?
(again, are architecture reviews performed frequently enough so that no one
will fear pointing out the flaws because of their impact).
● 1.5 Are metrics used to measure or to judge?
● “metrics should be used to measure truth — not to measure success or
failure. Only measures of truth can be trusted not to incite quick­fix
behavior in a team”1. TSP, for example, mandates that individual metrics be
kept private by the leader and team member, to avoid judgmental
considerations and to keep the focus on improvement.
● 1.6 Are metrics assigned meaning in a context sensitive way?

32. Funciones restrictivas
1.1 Does the practice promote sustainable work? (e.g.
Extreme Programming Energized work, formerly 40hs week,
or Team owned schedules).
● 1.2 Does the practice or process put hard limits on
effort? (e.g. Time boxing).
● 1.3 Is there a higher level decision maker available
to resolve issues? (e.g. someone appointed to brake
ties, resolve exceptional situations or handle
conflicts).
● 1.4 Can the forcing function be replaced by a more
elegant practice or process step?

33. Lecturas recomendadas
● Austin, Robert, Devin, Lee, Artful making, 1993
● Coplien, James, Harrison, Neil B., Organizational
Patterns of Agile Software Development, Prentice
Hall, 2005.
● Nielsen, Jakob, Usability Engineering, Morgan
Kauffman Press, 1993.
● Norman, Donald, The Design of Everyday Things,
Basic Books, 1988.

34. Actividad: La estructura del feedback