El conocimiento está en constante evolución y a través de un patrón dialéctico de tesis, antítesis y síntesis, avanza en una espiral de continuo perfeccionamiento. Detenerse con lo aprendido o defenderlo y negar su evolución es quedarse atrás.
La primera "tesis" en el conocimiento de la programación comienza a gestarse en los 70 ofreciendo como respuesta a la crisis del software del 68 modelos de desarrollo basados en procesos y gestión predictiva de los proyectos.
En los 90, cuando empiezan a consolidar sus resultados (CMM, PMI) comienza la gestación de su antítesis: el desarrollo ágil.
Estas son las dos piezas de conocimiento sobre la que va a comenzar a surgir la primera síntesis de nuestra espiral de conocimiento.
|
|
19.06.2006 |
Forma 1:
Vamos de vacaciones 15 días a Túnez.
Salimos el sábado. Con el AVE de las 12 vamos a Madrid, y desde allá en avión hasta el aeropuerto de Túnez. Un autocar nos lleva al hotel en Hammamet. El domingo día de playa. El lunes empezamos una ruta turística por el desierto de 3 días...
|
|
|
19.04.2006 |
 La teoría de los textos de administración de empresas sobre "procesos" y "organización centrada en procesos" debería incorporar una advertencia, que a modo de prospecto dijera algo así:
Incompatibilidades: La administración en empresas del conocimiento debe realizarse bajo la supervisión de un experto.
Efectos secundarios: En estas empresas, la administración en dosis o forma errónea puede producir mediocridad.
Las empresas de programación son el mejor ejemplo que conozco de empresas del conocimiento, y aplicar en ellas teoría de procesos porque "es lo que se lleva", o lo que me dijeron en el master es una barbaridad.
Los modelos industriales emplean a personas, procesos y tecnología para inyectar valor en la materia prima y transformarla en producto. Los objetivos para este cometido son: conseguir la mayor cantidad de producto, con el mayor nivel de calidad posible de la forma más eficiente (con el menor coste).
|
|
|
28.12.2005 |
Ni todos los proyectos, ni todas las organizaciones son iguales, y en algunos casos sienta mejor estar más cerca de la "agilidad" que de la formalidad de los procesos, y viceversa.
Las preguntas clave son:
- ¿Cuál es el nivel de inestabilidad de los requisitos?. ¿Cambia el 1% cada mes, o el 50%? [...]
|
|
|
08.11.2005 |
Los modelos de calidad deberían incorporar en su primera página alguna advertencia del tipo: "Antes de suministrar este modelo a su empresa consulte con un experto", para evitar que algunos desorientados se empeñen en combatir el dolor de cabeza con antibióticos, o las infecciones con antigripales.
|
|
|
05.07.2005 |
| Los métodos ágiles nacieron con espíritu de respuesta revolucionaria a la rigidez y el engolamiento de los modelos de procesos de SEI e ISO (CMM - CMMI - 15504). Algunas de las cosas que han escrito sus autores y defensores reflejan bastante bien el descaro, la frescura y la rebeldía: |
|
La diferencia entre un atracador de bancos y un teórico de CMM es que con el atracador se puede negociar
...
La evaluación en CMM depende más de una buena presentación en papel que de la calidad real del producto de software. Tiene que ver más con el seguimiento a ciegas de una metodología que con el desarrollo y puesta en producción de un sistema en el panorama tecnológico. | Ken Orr, CMM versus Agile Development: Religious wars and software development. |
Si uno pregunta a un ingeniero de software típico si cree que CMM se puede aplicar a los métodos ágiles, responderá o con una mirada de sorpresa o con una carcajada histérica | Richard Turner y Apurva Jain, Agile meets CMMI: Culture Clash or Common Cause. |
Sin embargo algo parece estar cambiando, porque la semana pasada se podía leer en La Red:
|
|
|
<< Inicio < Anterior 1 2 Siguiente > Fin >>
|
| Resultados 16 - 20 de 20 |
Suscripción
RSS 
