- un vehiculo a motor que transporte dos personas como mínimo,
- que tenga cuatro ruedas,
- que tenga asientos confortables,
- que consuma poco combustible ya que tienen pocos recursos económicos,
- solo necesitan que funcione con Safari 4,
- y que lo necesitan en 1 mes.
Por naturaleza empezamos a elucubrar ¿Pero de que pueden estar hablando?
| Un Smart |  | Una chiva |  |
| Un Nissan Micra |  | Un Audi R8 |  |
| Un Ferrari Enzo |  | O talvez un carruaje |  |
Nuestra imaginación normalmente nos empuja a crear productos más alla de los requerimientos iniciales (airbag, dirección asistida, GPS Integrado...), que en determinados casos son innecesarios; este comportamiento siempre se manifiesta en el momento más inesperado de la vida de un proyecto.
Cualquiera de estos coches citados anteriormente ¿cumple con lo requerido?.
Sin evaluar o conocer bien los requerimientos, unos dirán me apetece hacer un Audi R8 ya que mas urbano pero con mucha calidad, otros dirán pues el Smart..... y otros, un Ferrari por que nosotros también somos un ferrari ya que somos los mejores, etc, etc.
Implementamos dirección asistida, airbag, climatizador, reproductor de CDs ... merece la pena implementar todas estas características?
Realmente no son parte de los requisitos; implementarlas nos quitará un tiempo precioso! lo hacemos por decisión propia? Que cada cual responda con su consciencia je je je
Ese tipo de valor añadido al producto final, suele interferir en los tiempos de entrega, a menos que se pueda reaprovechar de otros proyectos. Ya que en ocasiones por añadir más de lo requerido, perdemos la visión del alcance del proyecto, y sin darnos cuenta empezamos a complicar el desarrollo de un producto que a priori deberia ser sencillo.
Pasada la fecha límite (1 mes), ¿como defender? al cliente, que no podemos entregarle lo que nos ha pedido, en la fecha indicada; sino que además tardaremos 6 meses más en entregárselo, por que le estamos haciendo un ferrari que tiene un sistema de localización mundial en caso de robo, y que estamos teniendo problemas de compatibilidad con Firefox e IE, pero que las estamos intentando solucionar.
Existen determinados tipos de filosofia o principios de desarrollo, que mezclados o aplicados en el momento exacto nos pueden favorecer a lo largo del proyecto, no solo en el alcance funcional, sino también el diseño o arquitectura del sistema, influyendo en el resultado final. Los más básicos son:
- YAGNI (You Ain't Gonna Need It),
consiste en no hacer nada mas alla de lo necesario. - DRY (Don't Repeat Yourself),
consiste en hacer sólo una vez las cosas, evitando la duplicación. - KISS(Keep It Short and Simple / Keep It Simple, Stupid),
recomienda usar la sencillez para que la aplicación sea comprensible a nivel de todos los perfiles del proyecto. - Peor es Mejor (Worse is Better),
se puede decir que la teoría de los antipatrones tiene mucho que argumentar sobre la mala aplicación de los patrones, a pesar de sus beneficios. - La navaja de Occam nos dice que a igualdad de condiciones la solución más sencilla probablemente sea la mas correcta "non sunt multiplicanda praeter necessitatem", es decir "no se debe presumir de más cosas de las que son absolutamente necesarias".
"El equilibrio" nos pone en el buen camino para el éxito de un proyecto, pero no no es fácil, ni siempre es el mismo, ya que depende de distintos factores.
Equilibrar las necesidades y espectivas del usuario, con las necesidades y espectativas del equipo, con las necesidades técnicas reales del proyecto, es un reto; pero los principios anteriormente citados ayudan a que ese ser vivo llamado "Aplicación" pueda llegar a buen puerto.
Probablemente no haya sido capaz de trasmitir todo lo que pienso, ni los matices que se aplican a cada una de mis frases, pero además de la sencillez, la visibilidad de nuestra faena y sobre todo la comunicación, son algunos de los puntos clave del éxito de un proyecto.
Enlaces relacionados:
Por que fracasan los proyectos de desarrollo software.
- FIN -
No comments:
Post a Comment