cesclaveria

  Los valores suelen ser una idea muy abstracta al momento de aplicarlos, los valores pueden guiar nuestros pensamientos pero en su conversión a acciones puede que se desvíen. Para servir de puente entre los valores y prácticas, entran los principios, estos no son los únicos principios que se pueden aplicar al desarrollo de software, hay muchos más, pero son sobre los cuales XP está basado.

Humanidad:

Una verdad innegable es que es la gente quien desarrolla software, son las personas quienes lo usan, necesitan y disfrutan. Pero aun así muchas veces el proceso de desarrollo de software no toma en cuenta la humanidad de los participantes, fallando al considerar sus necesidades, sus debilidades y aprovechar sus fortalezas.

Para que el humano se sienta a gusto en el desarrollo necesita que se cumplan algunas necesidades como:

Seguridad, sentido de logro, sentimiento de pertenecer a algo, oportunidad de crecimiento y el ser entendido (y entender) por otros.

Parte del desafío de mantener este principio es el de balancear correctamente las necesidades individuales con las del equipo, en ningún momento las necesidades de una persona han de dañar u obstaculizar al equipo, pero esto no quiere decir que hay que sacrificar la individualidad, si no que, cada miembro es responsable por cubrir sus necesidades, y no el equipo completo.

Economía:

Alguien tiene que pagar por el desarrollo del software, y siempre hay que tener en mente que las cosas se desarrollan con un propósito, para cubrir una necesidad o agregar valora un negocio. Priorizar correctamente las necesidades del negocio y atender esos aspectos primero maximiza el valor del proyecto, un desarrollo incremental permite aprovechar los beneficios del trabajo en el menor tiempo posible.

Beneficio Mutuo:

Toda actividad ha de ser beneficiosa para los involucrados, ninguna solución (aun en casos desesperados) ha de ser implementada de una manera que le cause perdida a otro miembro y solo beneficio a uno o a unos pocos, el daño a relaciones valiosas puede ser a la larga una perdida mucho más grande que el costo de buscar otra solución.

Auto-Similitud:

Cuando se encuentra una estructura y método que funciona, y que ha resuelto un problema, hay que intentar aplicar los mismos principios a otros problemas, aun en distinto contexto a distinta escala. En XP la estructura normal es: Escribir una prueba, hacerla funcionar. Esto aplica en la planeación de varios meses (temas), en la planeación semanal (tickets e “historias”) y en el trabajo diario (las pruebas necesarias para resolver una tarea).

Esto no quiere decir que siempre tratemos de aplicar los mismos patrones, a veces puede que sea necesario utilizar una solución realmente única y eso no quiere decir que este mal.

Mejoramiento:

En el desarrollo de software, si nos sentamos a esperar hasta que encontremos la solución perfecta, posiblemente nunca la encontremos, la excelencia por medio del mejoramiento constante es el verdadero objetivo de XP. En cada ciclo de trabajo debemos de hacer nuestro mejor esfuerzo hoy, pero aprendiendo y entendiendo lo necesario para hacerlo mejor mañana.

Diversidad:

Para que un equipo aumente su efectividad necesita diversidad, necesita juntar en el equipo personas con una variedad de destrezas, actitudes y perspectivas para enfrentar los problemas y buscar soluciones. El encontrar desacuerdos, que seguramente los habrá, es una oportunidad para aprender y aprovechar las ventajas de los involucrados, se debe de ser manejarlos de una manera productiva y con respeto.

Reflexión:

Los buenos equipos de trabajo, piensan y analizan su trabajo, cómo y por qué están haciendo lo que están haciendo. Analizan las razones de su éxito y fracasos, no intentan esconderlos si no que los exponen y aprenden de ellos.

Flujo:

En XP el flujo de software valioso entregado debe de ser alto, esto se logra realizando muchas actividades de desarrollo en conjunto. El proceso ha de ser constante, grandes entregas de código separadas por mucho tiempo suelen presentar problemas muy grandes y difíciles de manejar, la retroalimentación es lenta y puede conducir a quedar estancado o necesitar cambios aun más grandes.

Oportunidades:

Los problemas han de ser vistos como la oportunidad del cambio, para alcanzar la excelencia los problemas se han de convertir en oportunidades de aprendizaje y mejoramiento. Si un solo desarrollador comete muchos errores, cambie a una estrategia en pareja, si hay demasiada retroalimentación, pues mejore el proceso de asignar prioridades. Muchos problemas pueden traernos una oportunidad de mejora.

Redundancia:

Los costos de implementar redundancia en los procesos de desarrollo de software puede ser mínimo frente al costo de lidiar con los problemas que se pueden escapar por no hacerlo, los problemas críticos y difíciles deben de ser resueltos de más de una manera, así si una solución falla, la otra previene el desastre. Aunque la redundancia puede ser costosa (pruebas de unidad, revisiones de código y fases de prueba) nunca se debe de eliminar un sistema redundante que esté cumpliendo un propósito.

Fracaso:

Si no se conoce la respuesta correcta, la manera más rápida de encontrar la adecuada es fallando y aprendiendo de la falla. Aunque el fracasar puede parecer un desperdicio, en muchas ocasiones el conocimiento que imparte es enormemente valioso. Esto no es excusa para fallar cuando ya se conoce la solución, pero si no conocemos el camino al éxito, fallar puede mostrárnoslo rápidamente.

Calidad:

La calidad ha de ser un factor que reúna varios ideales, puede ser medida en cantidad de defectos, la efectividad del diseño y la experiencia de trabajar en el desarrollo. Las personas necesitan sentirse satisfechas con el trabajo que realizan. El control de la calidad se puede aplicar variando el alcance de los ciclos, cada cuarto o semana se puede variar con el propósito de aumentar la calidad.

Pasos Pequeños:

Los cambios grandes son peligrosos, y llegan a ser muy costosos cuando fallan, por más tentador que parezca cambiar mucho en muy poco tiempo, es mejor detenerse y preguntar: “¿Qué es lo menos que se puede hacer, que aun sea reconocible como un progreso?” Esto no significa llegar a quedar estancados, bajo las condiciones correctas los pasos pequeños nos pueden llevar muy lejos en muy poco tiempo, sin producir grandes desperdicios si uno de ellos llega a fallar. XP expresa este principio con prácticas como programación orientada a pruebas y la integración continua.

Responsabilidad Aceptada:

Solo nosotros podemos decidir si somos capaces de tomar una responsabilidad, no nos puede ser impuesta. XP practica la responsabilidad con hechos como, quien se apunte para realizar una tarea, también estime cuanto tiempo le tomara. Quien introduzca nuevo código, también es responsable de probarlo adecuadamente.