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.

Cada persona que se llega a ver involucrada en el desarrollo de software suele tener una idea de que es lo más importante, una planeación meticulosa, utilizar cierto estilo y estándares de código o quizá la total libertad personal. Pero lo que realmente importa no es como cada individuo se comporta, si no como este se comporta dentro de un equipo de trabajo, y que estos valores de trabajo se enfoquen para el mejoramiento del equipo, que sean una ayuda para triunfar juntos.

XP acoge 5 valores para guiar el desarrollo de un proyecto en equipo.

Comunicación:

Probablemente el más importante de los valores a mencionar, la comunicación es fundamental dentro del equipo de trabajo. Muchas veces, para los problemas que se llegan a presentar alguna persona ya conoce la solución, pero por falta de comunicación este conocimiento no le llega a la persona en la posición para realizar los cambios.

Incluso cuando el problema es nuevo e inesperado, la comunicación dentro del equipo puede llegar a encontrar la solución más efectiva y evitar que estos se repitan.

Frente a nuevos problemas, siempre será útil reflexionar si este fue causado por falta de comunicación y de ser así, preguntarse qué nuevas formas de comunicación se necesitan para prevenir estos problemas y manejarlos de la mejor manera cuando se presentan. Comunicación dentro del equipo creara un ambiente de cooperación y unidad, que ayuda a poder aplicar los demás valores.

Simpleza:

El valor de simpleza no se significa necesariamente algo sencillo o fácil, significa enfrentar cada problema preguntado primero “¿Qué es lo más sencillo que podría aun funcionar?” y comenzar desde ahí. La simpleza debe de estar dentro del contexto del problema y del equipo de trabajo que lo resolverá, si existe una herramienta que ayuda a resolver el problema, pero nadie del equipo la sabe manejar, utilizarla posiblemente agregue complejidad innecesaria al problema. La simpleza busca evitar el gasto innecesario de cualquier recurso.

Los valores deben de complementarse unos a otros, obtener buena comunicación ayuda a la simpleza al eliminar o posponer requerimientos no necesarios para el problema actual, mientras que obtener simpleza reduce la cantidad de información que debemos comunicar.

Retroalimentación:

Durante la vida de un proyecto son muy pocas las direcciones que permanecen constantes, ya sean los detalles del desarrollo, los requerimientos del sistema, la arquitectura y muchas otras pueden cambiar. Los caminos empezados antes de la experiencia suelen ser modificados prontamente, el cambio es algo inevitable, pero para hacerlo correctamente necesitamos retroalimentación.

Hay muchas razones que no nos permiten implementar la solución “correcta” desde un principio, por ejemplo:

• Es un problema nuevo del que no se conoce una solución correcta o existen varias posibles soluciones.
• Cambios fuera de nuestro control invalidan nuestra solución actual.
• Hacer todo de la manera correcta desde el principio, puede tomar tanto tiempo que nuestra solución puede ser obsoleta antes de estar terminada.

Entonces, la posición que tomamos es la de estar satisfechos con mejoras graduales en lugar de esperar la perfección inmediata, pero para estas mejoras graduales necesitamos retroalimentación, la cual puede venir de:

• Opiniones de nuestros compañeros acerca de nuestras ideas.
• Como resulto el código una vez escrito.
• La facilidad y funcionamiento de las pruebas automáticas.
• Como se comporta la idea una vez esté en funcionamiento.

Se debe de tratar de obtener tanta retroalimentación tan pronto como se pueda, y siempre recordar atenderla, aunque esto signifique disminuir un poco la rapidez de las nuevas implementaciones.

La retroalimentación también complementa a la comunicación y a la simpleza, obteniendo nueva información para comunicar e identificando que soluciones son las más simples y efectivas. También hay que notar que entre más simple un sistema, más fácil es obtener buena retroalimentación.

Coraje/Valentia:

Coraje es la accion efectiva frente al miedo, aunque nuestro medio no es inherentemente peligroso,tambien nos enfretamos al miedo de las consecuencias de nuestras acciones. El coraje lo debemos de complementar con los otros valores para obtener una guia de que hacer frente a una situacion donde nos de miedo actuar, ya sea al resolver un problema o tomar responsabilidad de una falla, la comunicacion, simpleza y retroalimentacion tambien se benefician del coraje al
obtener informacion concreta para actuar.

Respeto:

Los valores anteriores se basan y diregen con este, si no hay respeto y aprecio entre el grupo de trabajo XP no se puede aplicar efectivamente, si el equipo no respeta el proyecto, este ya esta perdido.

Extreme Programming, es un estilo de desarrollo de software enfocado en la aplicación excelente de técnicas para programar, comunicación clara y trabajo en equipo con el propósito de conseguir mejores resultados, en un tiempo más corto y de una manera en que nos sintamos más felices y realizados con el trabajo que hacemos.

XP se basa en una serie de valores:

• Comunicación
• Retroalimentación (feedback)
• Simpleza
• Coraje
• Y Respeto

XP expresa estos valores por medio de una serie de prácticas, practicas que se complementan unas a las otras y amplifican sus efectos positivos en el desempeño personal y del equipo.

La unión, a nivel intelectual, de estas prácticas y valores las da un grupo de principios que nos guían en la aplicación de los valores, aun cuando no exista una práctica clara para resolver nuestros problemas.

Que distingue a XP de otras prácticas de desarrollo?

• Tiempos de desarrollo más cortos, que resultan en una pronta y continua realimentación durante el proceso de desarrollo.
• Una planificación incremental y adaptable, concentrándose en un plan general primero y esperar que evolucione durante la vida del proyecto.
• Permite calendarizar fácilmente la implementación de funcionalidad para responder rápidamente a las necesidades cambiantes del proyecto.
• Se base en pruebas automatizadas, creadas por todos los involucrados e interesados en el proyecto, que permiten que el sistema evolucione y detecte defectos tempranamente.
• La comunicación oral juega un papel importante, asi como las pruebas y el propio código para comunicar la estructura y el propósito del sistema.
• Trabaja desde un punto de vista de evolución, donde el trabajo continuara mientras el sistema este en funcionamiento.

XP reconoce que el desarrollo de software es un trabajo de humanos, humanos que pueden fallar, que necesitan comunicarse, que pueden cambiar de planes y que sobre todo necesitan trabajar juntos.