Estaba tratando de buscar información que me ayude a sustentar una metodología a utilizar para la empresa donde estoy trabajando ahora, ya que cada empresa es un caso diferente y sus requerimientos cambian constantemente se debe trabajar sobre una base que soporte dichos cambios y me encontré con que SCRUM es perfecta para este caso.
Para sustentarlo me decidí en adentrarme más en esta metodología y encontré la web SCRUM for Team System, la cual contiene documentación completa sobre esta metodología, aunque ya había comentado algo sobre esta metodología en otro post, he encontrado mas detalles en esta web que definitivamente dan una mejor explicación.
La mayoría de las empresas tienen el problema de la metodología cuando quieren desarrollar proyectos, si bien es cierto pueden escoger cualquier metodología el otro problema viene cuando quieren encontrar los documentos que deben generar.
ReadySET es un proyecto open-source para producir y mantener una librería de plantillas reutilizables para ingeniería de software. Estas plantillas proveen un punto de partida para los documentos utilizados en proyectos de desarrollo de software. Utilizando buenas plantillas puede ayudar a los desarrolladores a trabajar más rápido, pero también ayudarán a evitar discusiones y a evitar pasar por alto problemas importantes.
Pueden acceder a las plantillas o descargar libremente desde http://readyset.tigris.org/es/index.html, ya las he visto y de hecho pueden servir para nuestros proyectos (adivinen como llegué, si! investigando), claro! recordando que siempre debemos adecuar las plantillas que tengamos a nuestro caso particular.
Y llegamos a la última entrega de los roles en RUP. Estos últimos roles son adicionales y no tienen un peso relevante dentro del proceso de desarrollo, sin embargo, pueden ser utilizados en caso de que el proyecto sea de mayor tamaño. Lo bueno que tiene RUP es que todo su proceso puede ser acomodado para satisfacer las necesidades de nuestro proyecto, del mismo modo, todos los roles presentados hasta el momento pueden o no ser tomados en cuenta dependiendo del proyecto.
Aquí quien tiene la mayor responsabilidad es el Jefe del Proyecto, ya que será él quien administre todos los recursos y determine para un proyecto específico las etapas, los roles y demás necesarios; recordemos que un proyecto puede ser, desde un Backup de una BD hasta el desarrollo de un sistema distribuido completo.
Para no dilatar mas, aquí los roles que faltaban: Leer más…
Hace un tiempo tuve la oprtunidad de dictar una conferencia en la Universidad Nacional del Callao, el tema que trate fue “Gestión de Proyectos de TI”, navegando recientemente por mis archivos me encontré con la diapositiva que utilicé para dicha conferencia, así que la publicaré ahora para que puedan verla si es que les interesa.
En realidad esto fue solo darle un vistazo general al tema, de manera que como verán no se ha ahondado mucho y ya que el público en su mayoría eran estudiantes, no me podía mandar con demasiadas cosas… ahora que recuerdo, incluso tuve que apurarme porque los expositores previos demoraron en sus presentaciones y me dejaron menos tiempo :S
Continuamos con el tema de RUP, y ahora presento las descripciones del rol Manager en RUP. Este rol que contiene a otros roles, trata aquellas funciones que cumplen un cargo de responsables en una etapa o en alguna actividad en particular del proyecto. Esto sin duda es importante ya que los diferentes managers serán los responsables de que dicha etapa se lleve a cabo de forma correcta.
Entonces los roles incluidos dentro del rol genérico Manager en RUP son los siguientes:
Process Engineer El rol ingeniero de procesos es responsable del proceso de desarrollo de software. Esto incluye configurar el proceso antes inicio del proyecto y continuamente mejorar el proceso durante el desarrollo del proyecto.
Siguiendo con la secuencia de roles en RUP, ahora toca ver el rol Tester, este rol es más sencillo de describir porque es único y tiene la responsabilidad de ejecutar las pruebas unitarias y de integración del software que se esta desarrollando.
A diferencia de los otros roles vistos, como el del analista o el del desarrollador, en este caso hay un único rol, pero no esta solo, apoyan al tester otro roles que se han comentado y/o se irán comentando conforme avancemos.
Muchas metodologías de software son muy nombradas hoy en día, lamentablemente no todas se usan como deberían, ya sea porque son muy pesadas o no hay mucha documentación al respecto. Ante este caso se presenta Scrum, una metodología que de hecho, muchos practicamos pero no sabemos que lo hacemos.
¿Qué es Scrum?
Scrum es un proceso ágil y liviano que sirve para administrar y controlar el desarrollo de software. El desarrollo se realiza en forma iterativa e incremental (una iteración es un ciclo corto de construcción repetitivo). Cada ciclo o iteración termina con una pieza de software ejecutable que incorpora nueva funcionalidad. Las iteraciones en general tienen una duración entre 2 y 4 semanas. Scrum se utiliza como marco para otras prácticas de ingeniería de software como RUP o Extreme Programming.
Ya había escrito una entrada en la que hablaba sobre el rol del Analista en Rup, ahora toca ver el rol del Desarrollador con la finalidad de explicar los diferentes roles que hay tras este rol genérico de RUP. Como ya se había mencionado: los roles no son individuos; en lugar de ello, describen cómo los individuos se comportan en el negocio y qué responsabilidades tienen estos individuos. En tal sentido cabe recordar que no es necesario tener una persona por cada rol, sino que una misma persona puede tener diferentes roles.
Una pequeña entrada para indicar que el post acerca de El rol del analista en RUP que publiqué la semana pasada ahora cuenta con gráficos que les permitirán entender los roles y los artefactos que cada uno de ellos genera.
En estos días estaré posteando los demás roles ya que primero debo traducirlos porque todo esta en inglés, así mismo lo haré acompañado de las imágenes correspondientes.
El Proceso Unificado de Rational (RUP, el original inglés Rational Unified Process) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. RUP es en realidad un refinamiento realizado por Rational Software del más genérico Proceso Unificado.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Esta es una definición tomada de Wikipedia que explica muy bien el sentido de RUP, esta metodología es bastante mencionada pero muy poco utilizada por el desconocimiento acerca del tema. Como se lee, RUP es adpatable al contexto y necesidades de cada organización, y eso es lo bueno ya que seguirla fielmente resultaría en un trabajo bastante engorroso.
Lo que pretendo es hacer una descripción de RUP basándome en la plantilla de la propia Rational, empezaré definiendo los roles para entender un poco más esta metodología. Leer más…
Y llegamos a la última entrega de los roles en RUP. Estos últimos roles son adicionales y no tienen un peso relevante dentro del proceso de desarrollo, sin embargo, pueden ser utilizados en caso de que el proyecto sea de mayor tamaño. Lo bueno que tiene RUP es que todo su proceso puede ser acomodado para satisfacer las necesidades de nuestro proyecto, del mismo modo, todos los roles presentados hasta el momento pueden o no ser tomados en cuenta dependiendo del proyecto.
Comentarios recientes