metodologías ágiles y el cuerpo de conocimiento
Post on 01-Jul-2015
238 Views
Preview:
TRANSCRIPT
2010
Diego Farias - dfarias2004@gmail.com, Juan Pablo Juan Delpino - juan.p.delpino@gmail.com, Fernando Garcia - fernando.d.garcia@gmail.com, Federico Repond - frepond@gmail.com, Marcelo Samia - msamia@gmail.com
[METODOLOGÍAS ÁGILES Y EL CUERPO DE CONOCIMIENTO (PMBOK)] El presente trabajo muestra los acuerdos y desacuerdos entre el PMBOK y las metodologías ágiles
Resumen (Abstract)
Desde hace unos años el uso de metodologías ágiles para el desarrollo de proyectos se fue
incorporando como una herramienta estándar para la creación de software. Sin embargo, estas no
parecen estar incluidas como una parte del manejo del proyecto descripto como cuerpo de
conocimiento o pmbok por estar íntimamente ligadas al proceso de desarrollo en sí mismo. Este
documento analiza las diferentes posturas respecto a la convivencia que estas dos herramientas
tienen en la actualidad y analiza cómo una metodología ágil en particular, Iconix, utilizada en conjunto
con otra herramienta llamada Léxico Extendido del Lenguaje pueden incluirse como parte del ciclo de
vida de un proyecto a partir del análisis de los requerimientos.
Introducción
A medida que se leen diferentes publicaciones es fácil distinguir dos posturas bien enfrentadas,
aquellos que apoyan las metodologías ágiles y los que lo hacen con la guías del pmbok. Es notorio
que se fuerce una comparación entre ambas ya que no son equiparables puesto que el pmbok es una
guía, en el sentido amplio de la palabra, de cómo llevar adelante proyectos, no una metodología de
cómo hacerlo. Esto queda claro cuando las guías del pmbok se aplican a proyectos que no tiene nada
que ver con el software, como los de la industria de la construcción [1]. Otra notoria asociación es la
de considerar al pmbok relacionado directamente con proyectos en cascada, cuando en el apartado
2.2 del mismo se define la interacción con los stakeholders y la el formato iterativo que tiene el
desarrollo de un proyecto [2]. Más aún, desde hace más de diez años se tiene en consideración
metodologías “ágiles” como “Rapid Throwaway Prototypes”, “Incremental Development” o
“Evolutionary Prototypes”, para citar algunos, que se comparan con los proyectos en cascada [3]. Por
otra parte, es en este punto también donde se enfatiza la colaboración con los stakeholders, su
participación constante y las iteraciones a partir de dicha colaboración [4]. Se pueden citar más
ejemplos que apoyen que las comparaciones entre ambos no son muy acertadas y la razón de esto
es que el pmbok es un framework y no una metodología. Entonces la pregunta que nace
inmediatamente es ¿las metodologías ágiles tienen lugar dentro de este framework?, y si es así,
¿cómo lo tienen?
¿Tiene sentido manejar un proyecto de software con el pmbok?
Si bien esta pregunta puede parecer extraña hay fundamento para formularla. Las metodologías
ágiles han tenido mucho éxito respecto de las consideradas tradicionales (pmbok) y su punto de
lanzamiento fueron, por mucho, los proyectos Web. Según mediciones del año 2003, aquellos que
adoptaron metodologías ágiles reportaron:
93% indico una mejora en la productividad
88% fundamentó que la calidad de las aplicaciones mejoró
83% experimentó mejoras en la satisfacción del negocio con el software
Estas metodologías, notablemente, promueven técnicas de gestión muy diferentes a las tradicionales,
como ser:
No intentar terminar rápidamente los requerimientos anticipadamente en el proyecto
Promover la incorporación de requerimientos de cambio a lo largo del ciclo de vida del
proyecto
Menos énfasis en la rigidez del planeamiento anticipado
Sin embargo a pesar que los números favorecen a las metodologías ágiles las membrecías al PMI se
incrementa un 20% anual [5]. Esto se debe a
que el cuerpo de conocimientos incorpora en su
framework la experiencia de campo de muchos
profesionales y su “correcta aplicación” en un
proyecto garantiza el éxito. Esta última frase es
la clave, ¿qué se entiende por correcta
aplicación?
Los detractores de las metodologías
tradicionales se quejan básicamente de los
mismos problemas: exceso de documentación,
alcance de la solución, tiempos asignados al
proyecto demasiados largos, insatisfacción del
cliente y costos muy elevados. Para sustentar
tales afirmaciones se han expuesto en trabajos en congresos forzando comparaciones entre los
métodos tradicionales y las metodologías ágiles. Uno de los fundamentos más importantes es que se
considera a los primeros manejado por el planeamiento y a los segundos por el valor agregado. La
Figura 1 muestra como se establece la comparación [6 y 7].
¿Si las metodologías ágiles tiene en evidencia de ser tan eficientes por qué insistir en compararlas
con las tradicionales utilizando como argumento el PMBOK? La respuesta es bastante simple: al ser
un framework sólo indica que se puede utilizar en el desarrollo de un proyecto, pero no implica el uso
obligatorio de todos sus componentes y las metodologías ágiles parecen no ajustarse a muchas
partes del framework. La razón de esto es que gran parte de la gestión del proyecto de estas últimas
se basan en la refactorización y la reingeniería localizada.
Ante las diferencias se trató, inclusive,
de generar un framework de
equivalencia al PMBOK, como el
propuesto por Jim Highsmith que se
muestra en la Figura 2, donde se utiliza
el siguiente criterio: “el PMBOK
identifica la inicialización, planificación,
ejecución, control y cierre de las fases
del proceso dentro de la gestión del
proyecto. Highsmith reconfigura estas
fases para reflejar mejor la realidad de
cómo el software es realmente
desarrollado, y se define como
conceptualización, especulación,
estudio, adaptación y cierre. En base a
estas equivalencias se enuncia que hay seis áreas de gestión del conocimiento clave en el PMBOK
que merecen especial atención y son la Gestión de Integración del Proyecto, Gestión del Alcance del
Figura 1 - PMBOK Project Management Process Groups mapped to Jim Highsmith's Agile Project Management framework
Figura 2 - - How is Agile Different from Traditional Approaches? The Paradigm Shift
Proyecto y Gestión del Tiempo Proyecto, la Gestión
de Calidad del Proyecto y la Gestión de Riesgos
del Proyecto, y la Gestión de Recursos Humanos
del Proyecto. Para cada una de estas áreas, las
prácticas preconizadas por el PMBOK tienen sus
primos en ágiles, pero son significativamente
diferentes en su aplicación [8].
Particularmente, la Gestión de Riesgos marca la
diferencia de interpretación en la metodología ágil
respecto del PMBOK. Si bien se han hecho
esfuerzos para generar modelos (templates) que
acerquen el uno al otro [9], la realidad es que el
estilo del manejo de riesgos en ágiles es como el
que muestra la Figura 3 [8].
Como se puede apreciar, la forma de documentar es muy pobre, pero favorece el brainstorming de
los integrantes de todo el equipo. Esto además se apoya en la distribución del trabajo
descomponiéndolo y asignándolo a equipos con funcionalidades recíprocas donde todos participan en
la evolución del proyecto [10].
Sin embargo, el PMBOK tiene su propia respuesta, como siempre, apoyada en las experiencias
llamada “Practice Standard for Earned Value Management” para “agilizar” una gestión correcta del
proyecto. Esta, a diferencia de la anterior, se basa en organizarse a través de la metodología
necesaria para integrar la gestión del alcance, tiempos y costos del proyecto y juega un rol crucial en
responder preguntas críticas para el éxito del mismo, como ser:
¿Se está atrasado o adelantado en el proyecto?
¿Qué tan eficientemente se está utilizando el tiempo?
¿Cuándo se cree que se va a terminar?
¿Se está por encima o por debajo del presupuesto?
¿Qué tan eficientemente se utilizan los recursos?
¿Cuánto va a costar el trabajo que falta?
¿Cuánto va a costar el proyecto entero?
¿Cuánto se estará por arriba o debajo del presupuesto al terminar?
Al usar esta metodología se puede identificar
¿Dónde ocurren los problemas?
¿Cuándo son críticos o no?
¿Cuánto costará reencaminar el proyecto?
Todo esto permite un amplio control sobre la
planificación y su correspondiente ejecución, como
muestra la Figura 4. Para poder manejarlo
correctamente se descompone en tareas simples, a los
Figura 3 - Planificación de respuesta al riesgo usaldo las categorías DeMarco/Lister
Figura 4 - EVM and the Basic PM Process
que comúnmente se llaman cuentas de control, que
permiten generar WBS (Work Breakdown Structures).
Mediante un OBS (Organization Breakdown Structure)
se puede asignar estas tareas más simples a
individuos o equipos de trabajo, como muestra la
Figura 5. Por lo tanto, esto brindará una unidad de
medida aproximada, minimizará los riesgos y reducirá
los costos [12]. Arriesgando una conclusión
prematura, se puede establecer que ambas posturas
tienen sus formas de enfrentar los costos, los tiempos
de desarrollo, la gestión de riesgos, etc. Si se parecen
tanto, ¿cómo una no puede tener cabida en la otra?
La respuesta es nuevamente simple: la tiene, sólo que al comparar una metodología con un
framework las diferencias parecen mayores a las similitudes. En el capítulo 2 (Ciclo de Vida del
Proyecto y Organización) del PMBOK se puede leer acerca de las fases, específicamente de las
relaciones de fase a fase y, aún más específico, la relación iterativa
“…sólo una fase está planificada en un momento dado y la planificación para la próxima se
lleva a cabo a medida que el trabajo avanza en la fase actual y los resultados finales. Este
enfoque es útil en entornos indefinidos, inciertos, o cambiantes rápidamente en gran medida,
como la investigación, pero puede reducir la capacidad de proporcionar planificación a largo
plazo. El alcance es entonces administrado por brindar de manera permanente los
incrementos del producto y dar prioridad a ciertos requerimientos para reducir al mínimo los
riesgos del proyecto y maximizar el valor del producto del negocio. También puede implicar
que todos los miembros del equipo de proyecto (por ejemplo, los diseñadores,
desarrolladores, etc) estén disponibles en todo el proyecto o, como mínimo, de dos fases
consecutivas.”
Tal vez la respuesta se encuentra en un punto medio, donde la metodología es en parte ágil y en
parte tradicional, permitiendo documentar, pero no mucho, gestionar riesgos y mantener formas de
comunicación con los equipos de desarrollo sin necesidad de pegar papeles con ideas sobre un
pizarrón, que pueda plasmar rápidamente los requerimientos y hacer ingeniería y análisis con ellos.
En pro de encontrar dicho punto medio, se comenzará con una propuesta de solución que arranca de
los documentos de especificación de requerimientos, conocidos como “system/software requirements
specification (SRS)”
Especificaciones Requisitos de Software
Este es el primer producto tangible de la mayoría de los ciclos de vida de desarrollo y una de las
principales fuentes de problemas en fases posteriores. Se han generado diferentes herramientas para
el planteo de este documento, como el del RUP (Rational Unified Process) o el de William M. Wilson
[14]. Todos proponen diferentes alternativas para categorizar los requerimientos utilizando distintos
atributos a los que se asignan valores dependiendo del estado del mismo. Inclusive, se propuso la
creación de herramientas gráficas que puedan categorizarlos minimizando la información textual [15].
Todas ellas además, desembocan escenarios, historias del usuario o casos de uso (junto con sus
Figura 5 - Control Account Matrix
analysis Class Model
Actor
Límite
ServicioEntidad
respectivos diagramas, cuando esto es aplicable). Sin embargo, una herramienta surge como más
interesante en el análisis de requerimientos por su capacidad para aprovecharla más allá de cualquier
otra metodología utilizada, el LEL (Léxico Extendido del Lenguaje y Escenarios).
La ingeniería de requerimientos carece actualmente de representaciones gráficas estándares. Sin
embargo se puede utilizar el léxico extendido del lenguaje y la metodología ágil Iconix extendiéndose
su funcionalidad para analizar y representar a los mismos. El documento propone una forma de
simplificar el desarrollo de sistemas y su ciclo de vida.
Una metodología ágil indica moverse rápidamente hacia delante y no invertir meses o años en
producir largas especificaciones de un proyecto para conseguir cumplir con los requerimientos del
producto planteado por el usuario. Sin embargo, moverse directamente desde los escenarios o casos
de uso al desarrollo de código provoca inevitablemente una refactorización o inclusive una
reingeniería constante en el ciclo de vida de un proyecto.
Se puede adaptar una metodología ágil para reducir la refactorización y la reingeniería. Esto tan sólo
agrega un poco más de documentación y se logra a cambio una mejora notable en los procesos de
análisis de requerimientos. Este documento propone una forma de realizar dicha mejora.
Análisis de robustez – Iconix [16, 17]
Desde hace un tiempo esta metodología fue ganando adeptos
porque cubre el vacío que existe entre los casos de uso, las
historias de los usuarios o los escenarios y los diagramas de clases
UML.. A primera vista parece una herramienta gráfica que sólo se
limita a cubrir dicha necesidad. Sin embargo se puede encontrar
una relación directa desde el léxico extendido del lenguaje (LEL) a
los diagramas que propone Iconix. Explotando dicha relación se
puede extenderlo su uso que originalmente fue pensado como una
forma de resolver en una primera fase de análisis los patrones de
diseño MVC que se detectaban dentro del análisis del modelo de
negocios estudiado, a un análisis de requerimientos basados en
LEL y reflejados mediante Iconix.
Iconix se basa en diagramas simples como los que se muestran en
la Figura 6 y todos se pueden refinar iterativamente.
Existen herramientas modernas que han aumentado la capacidad
de diagramas incluyendo componentes gráficos que registran
elementos no considerados en los cuatro gráficos elementales
originales y son los de la Figura 7
LEL [18]
El LEL (Léxico Extendido del Lenguaje y Escenarios) se introduce
como una herramienta para la creación y análisis de los escenarios
a partir de descripciones parciales del comportamiento del sistema.
Figura 6 - Elementos básicos de un diagrama Iconix
Figura 7 - - Elementos Iconix para interacción de los requerimientos
Esta herramienta permite construir correctamente escenarios y determinará el dominio de un sistema
apoyándose en modelos (templates) pre diseñados. A partir de un análisis de componentes estándar
dentro de la narración de los requerimientos por parte del usuario, como ser el sujeto, objeto, verbo y
estado se descubren la noción (lo que representa cada uno de estos elementos) y el impacto (cómo
influye cada uno de ellos en el análisis). Esto permite determinar los elementos estándar de los
escenarios como el nombre, objetivo, contexto, recursos, actores y episodios.
Objetivos del enfoque
Objetivos Consecuencias
Capturar Requerimientos
•Evitar abstracciones orientadas a una solución
•Brindar una visión más amplia del comportamiento del macro sistema
Proveer un medio de
comunicación
(Derivan de la utilización del lenguaje de la aplicación)
•Asegurar la comunicación entre el usuario y el ingeniero de software
•Garantizar la comunicación entre los miembros del equipo de
desarrollo
•Facilitar la validación de los requerimientos con el usuario
•Comprometer al usuario en el desarrollo
•Validar el LEL
Contar con un instrumento
de traceability
•Documentar los requerimientos
•Capacitar a nuevos miembros del equipo para comprender la
aplicación
•Promover la evolución de los escenarios a medida que avanza el
proceso de desarrollo
•Generar casos de prueba
Template de escenarios
Nombre Identifica al escenario.
Objetivo Establece la finalidad del escenario.
Contexto Acciones previas necesarias para iniciar el
escenario.
Recursos Objetos pasivos con los cuales los actores
Template de escenarios
trabajan.
Actores Entidades que se involucran activamente en el
escenario.
Episodio
Una acción realizada por actores con uso de
recursos, se incluyen las restricciones del
escenario o de cada episodio.
Casos alternativos Casos de excepción, que pueden corresponder a
otros escenarios.
Dudas Puntos pendientes a clarificar con el usuario.
Escenarios
Descripción parcial del comportamiento del sistema
Formas de representación:
– narrativa textual,
– storyboards,
– vídeo mock-ups,
– prototipos escritos o situaciones físicas.
– No son formales
El nivel de detalle depende de:
– importancia de los hechos específicos
– fase en la que se encuentra el proceso de desarrollo.
Se relacionan semánticamente entre sí
Evolucionan durante el ciclo de vida del software.
¿Son necesarios los casos de uso y los escenarios?
El LEL plantea una herramienta útil para la creación de escenarios y casos de uso mientras que
Iconix demostró ser eficiente para cubrir el vacío que se encuentra entre los escenarios o casos de
uso y el diseño de clases. Sin embargo, nacen inmediatamente las siguientes preguntas, ¿se podría
pasar directamente desde el análisis que ofrece LEL a Iconix?, ¿cómo se incorporaría una acción
semejante dentro del ciclo de vida de un proyecto?, ¿podría reflejarse esto dentro del cuerpo de
conocimiento del pmbok?
Las siguientes tablas muestran cómo influyen los elementos del LEL en los templates de escenarios:
Replanteando estas dos tablas por claridad, se puede ver la influencia en la
creación de escenarios desde otro punto de vista:
Cabe destacar que a diferencia del sujeto, todos
los otros elementos tienen influencia directa sobre
los episodios, dando a entender que un análisis del
dominio se podría “contar” como una historia del
usuario, escenario o caso de uso directamente en
un gráfico sin necesidad de redactar los mismos y
evitando la generación de mucha documentación
textual y sin perder contenido en el proceso.
Notar que esto también favorece elementos fundamentales como el seguimiento, la validación del
modelo y la verificación del modelo construido.
Es en este punto cuando se puede echar mano a una teoría existente para realizar la parte gráfica y
es donde interviene Iconix. Se puede tomar algunos elementos gráficos del mismo para generar una
representación simple de los requerimientos que no pierda información. La propuesta con las
respectivas equivalencias se muestra en una tabla comparativa respecto de LEL.
Elemento Elemento Noción (¿qué es?) Impacto (¿cómo influye?)
Sujeto Actor, Entidad
Actor, Entidad. Determina junto a los objetos y servicios afectados los límites de interacción
Nombre del Modelo. Determinación de actores. Determinación de los límites de interacción
Objeto Entidad, Servicio
Servicio o parte del mismo. Entidad persistente. Requerimiento no funcional
Requerimientos funcionales, no funcionales y persistencia. Graficado con enlaces
Verbos Servicio Servicios funcionales. Enlaces
Genera cambios de estado en el dominio. Graficado con enlaces. Indica interacción con el límite y entre objetos
Estado Servicio, Entidad
Servicio o parte del mismo. Entidad persistente afectada. Los enlaces indican el cambio de estado
Refleja los cambios dinámicos del sistema. Permita la validación y el seguimiento del modelo. Graficado con nombres en enlaces
Elemento Noción (¿qué es?) Impacto (¿cómo influye?)
1-Sujeto 5-¿quién es? 9-¿qué hace?
2-Objeto 6-¿qué es? 10-¿qué le hacen?
3-Verbos 7-¿cuál es el fin? 11-¿cómo se hace?
4-Estado 8-¿cómo se encuentra ahora? 12-¿transición?
Escenarios
Nombre 3,9
Objetivo 7
Contexto 4
Recursos 2,6
Actores 1,5
Episodios 8,10,11,12
Elemento Elemento Noción (¿qué es?)
Impacto (¿cómo influye?)
Sujeto Actores Actores Nombre
Objeto Recursos Recursos Episodios
Verbos Nombre Objetivo Episodios
Estado Contexto Episodios Episodios
El LEL toma cualquier forma de representación para obtener la información que determinarán los
requerimientos, lo cual va, por ejemplo, desde la narrativa textual a los storyboards o vídeo mock-ups.
En el siguiente ejemplo se muestra un análisis simple utilizando LEL para un sistema que permite la
obtención del pasaporte
Ejemplo:
Análisis LEL
Elemento Elemento Noción (¿qué es?) Impacto (¿cómo influye?)
Sujeto -Solicitante -Cajero
-Solicitante -Cajero
-Cobrar trámite
Objeto
-Formulario -Máquina timbradora -Pago
-Formulario -Máquina timbradora
-Presentación del importe -Formulario aprobado
Verbos
-Cobrar trámite -Controlar formulario -Timbrar formulario
-Cobrar el trámite al solicitante.
-Formulario controlado -Formulario cobrado -Formulario timbrado
Estado
-Trámite sin cobrar -Trámite pagado -Formulario sin timbrar -Formulario timbrado
-Presentar formulario en caja para pagarlo -Pagar el trámite -Colocar timbre en formulario
-Formulario presentado en caja -El formulario debe tener los datos del solicitante y la marca del tipo de trámite.
Escenario
Nombre: COBRAR TRAMITE
Objetivo: Cobrar el trámite al solicitante.
Contexto: El solicitante debió completar el formulario y pasar por el control de documentación.
Recursos:
formulario
máquina timbradora
Actores:
Solicitante
Cajero
Set de Episodios:
El solicitante se presenta con el formulario en la Caja.
El cajero informa el importe del trámite según el tipo de trámite que figura en el formulario.
El solicitante paga el trámite.
El cajero timbra el formulario con el importe.
El cajero entrega el formulario al solicitante.
Restricciones:
El formulario debe tener los datos del solicitante y la marca del tipo de trámite.
Casos Alternativos:
Máquina timbradora falla.
Del Análisis LEL a Iconix sin los escenarios
Sólo a fines de clarificar el traspaso de LEL a Iconix se presenta una tabla con las equivalencias
utilizadas, según se mostró en la Tabla anterior
Iconix Análisis LEL
Nombre Cobrar trámite
Actores Solicitante Cajero
Servicios y Enlaces Cobrar trámite Controlar formulario Timbrar formulario Pagar el trámite Colocar timbre en formulario Cobrar el trámite al solicitante. Presentar formulario en caja Pagar el trámite Colocar timbre en formulario Entregar formulario
Entidades Solicitante Cajero Formulario Máquina timbradora
Requerimiento no funcional
Máquina timbradora
Límites Recepción de formulario Recepción de Pago
Iconix Análisis LEL
Cambio de Estado de Entidades
Formulario sin presentar Formulario presentado Formulario sin cobrar Formulario cobrado Formulario sin timbrar Formulario timbrado Formulario entregado
Se debe tener en cuenta que el diagrama permite verificar, seguir y validar los requerimientos y
plantea un análisis inicial del problema del dominio que puede refinarse iterativamente.
Esta combinación de técnicas de ingeniería de requerimientos y análisis del dominio nos permite
plantear el problema principal, ¿cómo se incluiría una herramienta semejante dentro del esquema del
cuerpo de conocimiento? La respuesta es nuevamente simple. Esta combinación permite el desarrollo
de planes y su concreción con un mínimo esfuerzo incluyendo constantemente al stakeholder en el
proceso mediante un lenguaje gráfico simple.
Conclusión
La alternativa presentada permite ajustarse mejor a la guía del PMBOK que otras metodologías
La metodología ágil propuesta cumple con los 12 puntos establecidos en el Agile Manifesto.
Posee la documentación suficiente para cambiar los equipos de trabajo o solucionar problemas si
algo anda mal.
Se demostró que pueden existir alternativos ágiles que se ajusten al framework del PMBOK
analysis Cobrar trámite
Cajero
Solicitante
Cobrar trámite
Controlar formulario
Recepción de
formulario
Recepción de Pago
Formulario
Solicitante
Cajero
Timbrar formulario
Presentar formulario en caja
Pagar el trámiteFormulario sin timbrar
Colocar timbre en formulario
Formulario presentado
Formulario sin cobrar
Formulario cobrado
Formulario entregadoEntregar formulario
Referencias
[1]Building Better Software › What about Agile? - Andrew Stellman, Jennifer Greene -
http://www.stellman-greene.com/2007/04/27/what-about-agile/
[2]A guide to Project Management Body of Knowlegde – PMI Standards Committee
[3] A Strategy for Comparing Alternative Software Development Life Cycle Models - Alan M. Davis,
Edward H. Bersoff, and Edward R. Comer
[4] Building Better Software › Some great questions about PMP and Agile development- Andrew
Stellman, Jennifer Greene - http://www.stellman-greene.com/2007/12/06/some-great-questions-about-
pmp-and-agile-development/
[5] Using Agile Alongside the PMBOOK – Mike Griffiths -
http://leadinganswers.typepad.com/files/using-agile-alongside-the-pmbok_paper.pdf
[6] Agile Project Management: PMBOK vs. Agile - Neil Chaudhuri - Natalia Vainshtein
[7] Mapping the PMBOK Knowledge Areas to Agile Practices - Michele Sliger
[8] Relating PMBOK Practices to Agile Practices - Michele Sliger -
http://www.stickyminds.com/pop_print.asp?ObjectId=10365&ObjectTy
[9] Communicating Risk Information in Agile and Traditional Environments - Jaana Nyfjord and Mira
Kajko-Mattsson
[10] Distributed Scrum: Agile Project Management with Outsourced Development Teams - Jeff
Sutherland, Anton Viktorov and Jack Blount
[11] Practice Standard for Earned Value Management - Project Management Institute
[12] Earned Value, Clear and Simple - Tammo T. Wilkens
[13] Agile is in the PMBOK so it must be true - http://thecriticalpath.info/2010/06/04/agile-is-in-the-
pmbok-so-it-must-be-true/
[14] Writing Effective Requirements Specifications - William M. Wilson
[15] On Requirements Visualization - Orlena C.Z. Gotel, Francis T. Marchese, Stephen J. Morris
[16] Applying Use Case Driven Object Modeling with UML: An Annotated e-Commerce Example
Doug Rosenberg, Kendall Scott - Chapter 5. Robustness Analysis
[17] Agile Development with Iconix Process - Doug Rosenberg, Matt Stephens and Marl Collins-Cope
[18] Enhancing a Requirements Baseline with Scenarios - Julio Cesar Sampaio do Prado Leite,
Gustavo Rossi, Federico Balaguer, Vanesa Maiorana, Gladys Kaplan, Graciela Hadad and Alejandro
Oliveros
top related