En este post voy a hacer referencia a una entrevista realizada por Marino Posadas en el #87 de dNM (antes DotNetManía) a Eric Evans, Udi Dahan y Diego Vega en el marco de la Conferencia DDD (Domain Driven Design) sobre Arquitecturas de Aplicaciones empresariales (evento inaugural de IASA-Spain Chapter, Madrid-7 Nov. 2011).
Aunque la noticia/entrevista ya tiene un tiempo, el tema de fondo es un "clásico" con el interés suficiente para ser comentado y revisado, o por lo menos a mí me lo parece ;).
Concretamente una pregunta dirigida a Eric Evans ("padre" de DDD, una filosofía de diseño de sistemas de software complejos, uno de los grandes autores y referentes de la Ingeniería del Software) que no tiene desperdicio (en el buen sentido de la expresión).
La pregunta (cito de la revista): ¿Cuál dirías que es hoy la mejor aproximación para el análisis?¿CMMI o las tecnologías ágiles?
Eric Evans responde que trata de no ser muy imperativo en cuanto al proceso pero que además ha de añadir que necesitas ser capaz de iterar, de recorrer el proceso varias veces. De ir atrás y revisar lo hecho, o añadir nuevas características.
Agrada de la respuesta la manera de centrar el tema, yendo al fondo de la cuestión al contestar sobre el Proceso, ese "todo" en el que se enmarcan las distintas "partes" referidas en la pregunta.
Vuelve a sorpender gratamente la actitud prudente (la humildad del sabio) que demuestra al decir que sobre esto no hay palabra de Dios (no ser imperativo)...
...aunque no deja lugar a dudas desde el primer momento sobre su apuesta por un proceso iterativo, rasgo característico fundamental de las metodologías ágiles.
EE continúa explicando que el modelado (haciendo referencia a la esencia de su paradigma en el cual se busca un modelo del dominio para nuestro problema de negocio) es un proceso de aprendizaje y añade si pretendes haberlo completado totalmente desde el principio, el resultado no va a ser muy bueno. Y si empleas mucho tiempo al principio tratando de refinar el modelo, aún así vas a tener problemas.
EE vuelve a hacer alusión a otro de los mantras de las metodologías ágíles, el del fracaso de tratar de aplicar a rajatabla los procesos de la ingeniería civil a la la ingeniería del software (tablas de pesos y medidas, modelo en V, cascada, etc.). Es interesante también notar que EE no es extremista ya que reconoce implícitamente un valor a las fases de diseño, pero dejando claro que una inversión fuerte en las mismas no será garantía de éxito.
Continúa pasando a dar su consejo: Es mejor empezar y aprender del proceso, y a medida que avanzas vas aprendiendo y vas cambiando una y otra vez el modelo, en un proceso de refinamiento progresivo.
Es decir, desarrollo iterativo e incremenental basado en un modelado / diseño "emergente".
Esa es la única forma en la que he visto auténticos modelos de calidad en funcionamiento. Y esa es una de las cosas que enfatiza más claramente el modelo ágil.
El maestro concluye la respuesta sentenciando: En resumen, aunque creo que no son la panacea, las tecnologías ágiles me parecen más válidas, desde el momento en que refuerzan estos principios.
Una vez más sin caer en la tentación de dogmatizar, nos deja claro cuál es su opinión al respecto: en este complejo negocio de los proyectos de desarrollo de software en el que los riesgos de desviaciones, insatisfacciones y pérdidas económicas acechan, tenemos en las metodologías ágiles nuestra mejor carta de navegación y compás para tratar de llegar a buen puerto (y si la tripulación es experimentada... pues mejor).
Podéis ver el vídeo de la entrevista aquí.
Sunday, February 19, 2012
Friday, February 03, 2012
Una sola voz: Scrum y la natación textil
Muchas veces, a la hora de aplicar determinados sistemas, prácticas o métodos que de antemano reconocemos como válidos y beneficiosos, podemos vernos tentados por hacer ciertos ajustes que permitan despejar de la ecuación determinadas variables que nos molestan o incomodan...
Aquellos aspectos que se nos antojan prescindibles o incluso que consideramos mejor eliminar haciendo una aplicación del método "protestante" o libreinterpretativa que permita, desde luego, "mejorarlo". Me quedo con esto que mola, aquello no, que rollo, o no me conviene en este momento, y si lo hago así o asáu me encaja perfectamente... uy!, quizá alguien esté empezando a pensar en esa famosa disciplina textil de la natación, también conocida como nadar y guardar la ropa.
Como se dice coloquialmente "un poner": sea una metodología famosa, eso es, Scrum y sea uno de sus axiomas, principios básicos y reglas de fuego: Una sola voz.
Qué profundo suena..., seguro que a los que habéis ido a un cursillo de alguno de los gurús del tema os suena (cómo les gusta repetirlo a los muy pesados, se ve que lo hacen porque quedan como autenticos chulapos ante la audiencia).
Es decir, que estos del Scruntx se ponen pelmas con que debe existir un único ordeno y mando, que elabore la pila de producto y fije las prioridades (ojo y también que se responsabilice de que la gasolina funcional para que ande el equipo no este baja de octanaje, ¡no todo va a ser mandar hombre!). Los del cursillo, ya sabéis de quién estoy hablando: el Dueño de Producto, aunque a mi me mola más decir el productouner (otro día hablaremos de los guachimanes...)
Pues bien, en nuestra búsqueda de la perfección y mejor adaptación del método podemos decidir tener un par de productouners, así si uno está de vacaciones el otro le hace la sustitución, y quizá además alguno se lleve mejor con algunos miembros del equipo, o quizá uno sepa más que el otro del negocio o la tecnología y eso sea genial porque se puedan complementar.
Además el equipo puede preguntar a dos, como una segunda opinión médica, y ver cuál es la respuesta que más le conviene según lo que ya llevaba desarollado, etc. y ser más eficiente en su trabajo.
Vamos todos son ventajas, no sé cómo no se le ocurrió al que lo inventó... Pero espera... alguien ha dicho algo de axioma o regla básica... ¿a ver si nos cargamos algo por meterle mano a esto...? no sé, igual no lo tocamos y buscamos otros espacios de mejora... a lo mejor en Kanban que lo del productouner no está tan perfilado... bien!
Aquellos aspectos que se nos antojan prescindibles o incluso que consideramos mejor eliminar haciendo una aplicación del método "protestante" o libreinterpretativa que permita, desde luego, "mejorarlo". Me quedo con esto que mola, aquello no, que rollo, o no me conviene en este momento, y si lo hago así o asáu me encaja perfectamente... uy!, quizá alguien esté empezando a pensar en esa famosa disciplina textil de la natación, también conocida como nadar y guardar la ropa.
Como se dice coloquialmente "un poner": sea una metodología famosa, eso es, Scrum y sea uno de sus axiomas, principios básicos y reglas de fuego: Una sola voz.
Qué profundo suena..., seguro que a los que habéis ido a un cursillo de alguno de los gurús del tema os suena (cómo les gusta repetirlo a los muy pesados, se ve que lo hacen porque quedan como autenticos chulapos ante la audiencia).
Es decir, que estos del Scruntx se ponen pelmas con que debe existir un único ordeno y mando, que elabore la pila de producto y fije las prioridades (ojo y también que se responsabilice de que la gasolina funcional para que ande el equipo no este baja de octanaje, ¡no todo va a ser mandar hombre!). Los del cursillo, ya sabéis de quién estoy hablando: el Dueño de Producto, aunque a mi me mola más decir el productouner (otro día hablaremos de los guachimanes...)
Pues bien, en nuestra búsqueda de la perfección y mejor adaptación del método podemos decidir tener un par de productouners, así si uno está de vacaciones el otro le hace la sustitución, y quizá además alguno se lleve mejor con algunos miembros del equipo, o quizá uno sepa más que el otro del negocio o la tecnología y eso sea genial porque se puedan complementar.
Además el equipo puede preguntar a dos, como una segunda opinión médica, y ver cuál es la respuesta que más le conviene según lo que ya llevaba desarollado, etc. y ser más eficiente en su trabajo.
Vamos todos son ventajas, no sé cómo no se le ocurrió al que lo inventó... Pero espera... alguien ha dicho algo de axioma o regla básica... ¿a ver si nos cargamos algo por meterle mano a esto...? no sé, igual no lo tocamos y buscamos otros espacios de mejora... a lo mejor en Kanban que lo del productouner no está tan perfilado... bien!