Hoy he tenido que hacer el ejercicio de resumir los principios de diseño que yo creo que deben dirigir un proceso de construcción de software. Después de bastante reflexión me he quedado sólo con cuatro. Los siguientes:
- KISS (Keep it simple, stupid). Creo que nunca valoraremos lo suficiente el valor de simplificar todo lo posible los sistemas que construimos. ???? ????? ??? ????
- No construyas si puedes usar algo que ya existe.
- Entrega (parte de) el producto cuanto antes a sus usuarios, sigue construyéndolo apoyándote en los comentarios de los usuarios. ??????? ??? ?????
- La interfase del usuario debe ser web, siempre.
- La interfase del usuario es un animal totalmente distinto. 1xbet ???? Debe diseñarla y construirla un equipo de especialistas en interfases de usuario y debe estar totalmente desacoplada de la lógica de la aplicación.
¿Qué opináis?.
Totalmente de acuerdo, sobre todo con KISS, aparte, a mi siempre me han preocupado dos cosas:
1 РQui̩n ha definido lo que estoy haciendo?
2 – Dependo de alguien para poder hacerlo?
Me parecen acertados todos los puntos. Y veo que , en principio, los tres primeros primeros puntos siguen la filosofÃa de las metodologÃas ágiles o eso veo. Siguiendo por esa linea, justamente hoy he estado viendo este enlace a través de uno de los blogs que sigo, que puede complementar los puntos que indicas aunque va mas orientado a la gestiónd e lso equipos de desarrollo de software aunque en tu lista de 5 puntos no entras a ello.
http://www.navegapolis.net/content/view/1013/62/
No termino de estar de acuerdo con el punto 3, tan peligroso es que el equipo de desarrollo crea saber lo que los usuarios necesitan, como que estos últimos dirijan al equipo de desarrollo.
¡Bienvenido sea el desacuerdo! 🙂
Entiendo tu punto, José, pero te hago la siguiente pregunta, ¿cuál es el peligro al que te refieres?. ¿Estamos hablando de desvÃo del presupuesto y/o de las fechas?.
Si es asà estoy de acuerdo contigo, si involucramos al usuario en el proceso de construcción del sistema es imposible asegurar el cumplimiento de unas fechas, o de un presupuesto concreto y el usuario debe ser consciente de esta circunstancia. Ahora bien, ¿es ése el peligro del que debemos preocuparnos o deberÃamos preocuparnos del peligro de construir un sistema (en coste y plazo) que no sea el que resuelve el problema del usuario?.
Esta claro que el punto 3 apunta hacia procesos de construcción de software iterativos y/o ágiles como comentaba Helios.
Que tal, Jorge… Solo comentarte lo que ya supones que comentaré 🙂 sobre esos puntos.
Por grupos, el primero… genial. Tan totalmente de acuerdo como hastiado de no poder construirlo. En este pais de servicios (y de panderetas), si lo haces simple y sencillo, acabas pronto y bien… y pierdes negocio (por tiempo de facturación, por recursos, por falta de necesidad de mantenimiento, etc…). Fatal !!!!! (ironÃa)
El 5 es obvio… please, call Micro$oft.
En cuanto al 2,3 y 4, tÃpico pensamiento de servicios… mejor no decir nada mas, que si no publicarás esto 🙂
Si eso, coge los 5 puntos y los paseas por las empresas donde se hace verdadero software, no programitas para los clientes.
Un abrazo.