
Mucha gente acostumbrada a RUP, cuando comienza a aprender acerca de Scrum y métodos ágiles, se hace preguntas similares a la siguiente:
"Para hacer el diseño de un software en RUP se hacer realización de casos de uso (diagramas de secuencia, colaboracion, etc), diagramas de clases, componentes y otros. ¿Se pueden utilizar estos entregables de RUP adicionalmente a los usuales de Scrum (Product Backlog, Sprint Backlog, Impediment List, Burndown chart)?"
Mi respuesta es la siguiente:
En vista de que Scrum es un framework mínimo para crear un proceso de desarrollo de software, no prohibe la creación de artefactos o documentos adicionales a los que indica como obligatorios. Lo único que dice Scrum al respecto es que juzgues la necesidad, la utilidad y el costo (vs. el beneficio) de cada uno de los artefactos que decides agregar. Mi opinión es que siempre es necesario realizar ciertas actividades de modelamiento antes de iniciar un desarrollo.
Lo importante es que los modelos producidos sean como una luz que guíe el resto del proyecto, no una camisa de fuerza, y dejar que evolucionen junto con el código producido. Más aún, es crucial comunicar estos modelos al resto del equipo, por lo que muchos equipos ágiles prefieren utilizar pizarras (vs. herramientas CASE) para realizar sesiones de modelamiento en conjunto.
Esto es lo que se conoce como Agile Modeling.Una buena fuente de información sobre cómo combinar Scrum y RUP, es el site del OpenUP.





7 comments:
muy buena comparacion lo de la camisa de fuerza!! jeje .. sigue asi compare
Ok, siempre son necesarios ciertos artefactos, pero personalmente no he encontrado aún un proyecto donde "todos" los artefactos utilizados sean de utilidad...
¿Cuales dirias son los que no tienen pierde en ese caso Gustavo?
Estoy de acuerdo con la afirmación de que es muy raro que se requieran todos los artefactos de RUP. Es más, los expertos en RUP declaran como paso esencial, dentro de la adopción de este proceso, el escoger adecuadamente cuáles artefactos se utilizarán.
Como los proyectos de desarrollo de SW pueden ser de diversos tipos (y por lo tanto tener diversas necesidades), ciñéndonos únicamente al ámbito de los sistemas empresariales, yo opino que uno de los artefactos que "no tiene pierde" es un diagrama de clases que modele el dominio del problema en cuestión.
A nivel de documentos, uno que describa la arquitectura (SAD) también es muy útil. En el caso de OpenUP, se refieren a este artefacto como Architecture Notebook, lo cual comunica claramente la intención de privilegiar el fondo sobre la forma.
Holas Gustavo, tal como te mencioné en la entrevista, muy bueno tu blog. Saludos. Nos vemos
Aparte de scrum y rup que otros procesos de desarrollo de software existen??
Alguien me podria asesorar?
Se los agradeceria mucho
Los procesos ágiles más populares son: Scrum, Extreme Programming, Crystal, Lean Software Development y Feature Driven Development (FDD).
Otros no tan ágiles (cortesía del SEI) son PSP (Personal Software Process) y TSP (Team Software Process).
Dentro de RUP también hay variantes: OpenUP, EssUP, AgileUP, Enterprise UP.
Publicar un comentario en la entrada