Embedded Files
El desarrollo de software es una tarea creativa. Al trabajar con gente (y no recursos) se les debe dar importancia por sobre los procesos. Esto no implica abandonarlos sino que los mismos no deben interponerse en la interacción de las personas.
Es más importante entregar un software funcional que una completa documentación. Esto no quiere decir que no hay que documentar, sino que hay que enfocarse en lo que al cliente más le agrega valor.
Flexibilidad para responder a los cambios y colaboración con el cliente, en vez de forzar el cumplimiento de contratos. Si entrego algo que cumple con un contrato, pero no le sirve al cliente, tampoco me sirve a mí.
Si el software que desarrollamos es para un negocio vivo (¿quién hizo uno que no lo fuera?) los requerimientos van cambiando a medida que pasa el tiempo. Cambia el mundo, cambia el contexto, cambia el negocio, cambian los requerimientos.
El software a desarrollar debe dividirse en etapas con funcionalidades determinadas (sólo se fijan las de la etapa actual). Las entregas frecuentes ayudan a reducir el riesgo por cambios de contexto o por no aceptación.
El cliente no conoce completamente la funcionalidad que quiere o necesita, por lo que pueden introducirse cambios que implique descartar o cambiar completamente funcionalidades ya desarrolladas y entregadas. Nuestro trabajo es entregar software funcional, no marcar tildes en una lista.
Al guiar el desarrollo por el valor que se le agrega al cliente se debe confiar en el equipo, quien finalmente es el que realiza el producto. Un equipo en el que no se confía no está motivado. Un equipo desmotivado contribuye a reducir las probabilidades de éxito del sistema.
Hubieron, hay y habrán errores, porque somos personas. Lo que nos diferencia es que podemos aprender de los mismos. Cada cierto tiempo hay que aislarse de la vorágine de los ciclos de entrega y las presiones y generar un momento para el aprendizaje. En SCRUM, por ejemplo, esto se llama retrospectiva.
Page updated
Google Sites
Report abuse