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.
15 comentarios:
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.
Totalmente de acuerdo con tu explicación, tuve la oportunidad de implementar RUP como asesor en una empresa y luego fuimos moviendo la práctica a SCRUM y concuerdo 100% con lo que tu mencionas, de hecho con SCRUM siempre hago un diagrama de casos de uso para ubicarme y tener the bog picture! independientemente que utilice historias de usuario.
Te invito a leer mi blog. Saludos
https://gbonalde.blogspot.com
hola gustavo quisiera saber en que proyectos se han usado el SCRUM, cuales son los casos de exito. gracias por tu respuesta
En el mundo hay una cantidad enorme de casos de éxito. Por ejemplo:
http://agilepainrelief.com/notesfromatooluser/2008/11/scrum-case-studies.html
http://bradapp.blogspot.com/2006/08/agile-adoption-across-industry.html
En el Perú tengo también varias referencias, pero no están publicadas. Si deseas, puedes contactarme por correo para proporcionártelas.
HOLA GUSTAVO... FELICITACIONES ESTA MUY INTERESANTE TU INFORMACION DE HECHO ME HA SERVIDO DE MUCHO PARA LO QUE ESTOY INVESTIGANDO PERO ME GUSTARIA CONTACTARME CONTIGO PARA QUE ME PUEDAS DESPEJAR CIERTAS DUDAS..
MI CORREO ES marlinbriones@hotmail.com
Gracias :-)
:-)
Los frameworks ágiles tan populares hoy en día, son solo una evolución (con algunas variantes) de RUP (o de su concepto más general.) Quién HA TRABAJADO con RUP, sabe de qué estoy hablando. El cambio vino con RUP, no vino con las "ágiles". De hecho RUP NO ES UN CONCEPTO CERRADO.
Para opinar, habría que haber pasado desde las metodologías tradicionales (Yourdon) a las de hoy en día.
En lo particular, contrato dsearrollos de software con emprseas, y si no tengo una fomalidad de los artefactso entreaso, luego no tengo por donde hacer el sooprte yu mantenimientos que se requeire. Par los que no conoce, RUP no exige, ni pone camiza de fuerza, solo pone un abanico de psosibilidaddes y cada uno selecciona lo que requiere.
Respondo los últimos dos comentarios:
@Anonimo: RUP constituyó un cambio fuerte a nivel de proceso al popularizar el desarrollo incremental e iterativo. Lamentablemente, en mi experiencia, fue diluido en muchos lugares en donde las fases de RUP terminaron pareciéndose a una cascada. Los métodos ágiles de hecho son una evolución de cosas anteriores (como RUP), con importantes añadidos extraídos de otros enfoques. Por ejemplo, además de proponer un enfoque iterativo/incremental, hacen un fuerte énfasis en el aspecto psicológico/sociológico del desarrollo de software, cosa que RUP no tenía.
@Carlos Balladares: El artículo fue escrito desde el punto de vista de un equipo de desarrollo. De acuerdo con que si nos ponemos del punto de vista de una empresa que contrata el desarrollo, es esperable que esta exija ciertos artefactos. Desde un punto de vista ágil, lo que se propone es tener aquellos que realmente agreguen valor y considerarlos un soporte al entregable más importante que es el producto de software.
Publicar un comentario