Una vuelta de tuerca a la ley del cambio
- La ley del cambio: La probabilidad de que nuestro software debe evolucionar y cambiar es mayor cuanto más tiempo de vida tenga.
- La mayoría de los programadores no digerimos aun la naturaleza cambiante de cualquier software.
- El cambio hace notar ciertos bugs que pasaron desapercibidos, las exigencias de nuevas funcionalidades, la aparición de nuevos cambios legales, etc.
- «Cambio continuo»: cada nueva release implementa más y mejores funcionalidades y resuelve problemas anteriores.
- «Continuous delivery»: iteraciones periódicas donde entregamos software funcional mejorado. (Lo que hacen las metodologías ágiles actuales.)
- Cuando se lanza al mercado un producto, cuanto más éxito tengas, más cambios y mejoras se le va a pedir; La necesidad de aplicar cambios es un síntoma de éxito.
- La necesidad de poder modificar y evolucionar nuestro software debe ser la piedra angular de nuestros desarrollos: Todo cambio es bienvenido.
- Un programador profesional no reinventa la rueda, usa y acopla de manera óptima librerías de terceros, las cuales también cambian con el tiempo (para bien y para mal).
- La capacidad de desarrollar software es también la de saber ensamblar correctamente módulos que nosotros no escribimos.
- Uno de los motivos por el cual la tecnología avanza tan rápido es que nos gusta compartir nuestro trabajo para que otros lo utilicen, y al hacer esto los programadores encuentran mejores maneras de resolver los mismos problemas.
- Uno de los grandes errores que cometemos como programadores es elegir librerías de terceros desde un punto de vista de gustos personales o por que es la más reciente y no evaluamos aspectos más técnicos e importantes.
- Podemos afirmar casi sin margen de error que mientras más popular sea un tecnología más cambios tendrá y por ende más evolucionara en el tiempo.
- En la medida de lo posible antes de elegir una librería externa debemos saber:
- Tiene una comunidad amplia
- Hay documentación buena y confiable.
- Es posible reemplazarla con otra de manera sencilla.
- Qué tan nueva es la liberia.
El coste de hacer una mala elección a mediano plazo puede ser abrumador y fatal para el proyecto.
Los términos para elegir una tecnología deben ser más técnicos que emocionales.
El error de un desarrollador novato es usar tecnologías por la única razón de que le guste y nada más. El desarrollador profesional evaluará el costo-beneficio a mediano y largo plazo que provoca elegir esa tecnología para el proyecto.
Cualquier tecnología que se use siempre debe poder ser justificada técnicamente.
Te guste o no, el tiempo de vida de una aplicación de software es limitado.
Tenemos que tener el hábito de desacoplar lo más posible nuestro software del resto de componentes. Esto nos permitirá poder sustituirlos de manera más fácil y menos traumática.
Principios detrás del Manifiesto Ágil
Nuestra máxima prioridad es satisfacer al cliente
a través de la entrega
temprana y continua de software valioso.
Bienvenidos los requisitos cambiantes, incluso al final del
desarrollo. Los procesos ágiles aprovechan el cambio para
la ventaja competitiva del cliente.
Entregue software que funcione con frecuencia, desde un par de semanas hasta un
par de meses, con
preferencia a la escala de tiempo más corta.
Los empresarios y los desarrolladores deben trabajar
juntos diariamente durante todo el proyecto.
Construir proyectos en torno a individuos motivados.
Bríndeles el entorno y el apoyo que necesitan,
y confíe en ellos para hacer el trabajo.
El método más eficiente y efectivo para
transmitir información hacia y dentro de un equipo de desarrollo
es la conversación cara a cara.
El software de trabajo es la medida principal del progreso.
Los procesos ágiles promueven el desarrollo sostenible.
Los patrocinadores, desarrolladores y usuarios deben poder
mantener un ritmo constante indefinidamente.
La atención continua a la excelencia
técnica y el buen diseño mejoran la agilidad.
La simplicidad, el arte de maximizar la cantidad
de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños
surgen de equipos autoorganizados.
A intervalos regulares, el equipo reflexiona sobre cómo
ser más efectivo, luego sintoniza y ajusta
su comportamiento en consecuencia.
Te dejo el link gratuito de El libro negro de programador por si te intesa leerlo, o dale click a la imagen:
Top comments (0)