©T

he M

.C. E

sche

r Com

pany

 B.V

. 

diego.fontdevila@grupoesfera.com.ar

Usabilidad de Prácticas y Procesos

Diego Fontdevila

@dfontde

Reconcebir es cambiar nuestras ideas a la luz de 

las ideas de los demásRob Austin y Lee Devin

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)

¿Por qué práctica y proceso?

El Proceso es el flujo de trabajo, productos e

información para coordinar las actividades de

distintos participantes, para producir valor.

La práctica describe las actividades compartidas y la 

experiencia de hacer el trabajo.

Actividad 1: Una práctica

“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

Pregunta

¿Sirve aplicar principios y heurísticas de usabilidad 

para evaluar si una práctica o proceso le conviene a una 

organización?

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

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.

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

Criterios de usabilidad

● Menos es más

● Corresondencia Natural/Affordance

● Modelos mentales consistentes

● Tolerar errores

● Funciones restrictivas

● Devolución (Feedback)

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

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

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

Actividad: La cajita

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

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

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)

Actividad: Rueda de sillas

Funciones restrictivas

● Limitan el daño de un proceso o práctica mal ejecutado.

● Ejemplos● 40hs por semana ● Timeboxing● Compromisos controlados por el equipo

Actividad: Aprender a armar un...

¿Entonces?

Actividad: Evaluar un ejemplo

Checklist por Criterio de Usabilidad

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?

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)

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

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

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?

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?

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.

Actividad: La estructura del feedback