El enfoque AGILE y la necesidad de análisis empresarial en proyectos

 

requirements for agile

Of the four value statements presented in the AGILE Manifesto, the fourth one (We value responding to change over following a plan) causes frequent misinterpretation among technologists.

New AGILE practitioners need to keep in mind that adaptive methodologies were meant to address the lack of flexibility and fluidity during the construction of a solution design. In that sense, the arrival of AGILE 15 years ago exposed the value of delivering software in an adaptive way, emphasizing customer collaboration over agreement on a comprehensive statement of work, or a big plan to deliver it.

This has been certainly the greatest contribution of the AGILE movement: The realization that software that works could be delivered collaboratively by the team with just the right amount of specification up front.

Nevertheless, AGILE enthusiasts are sometimes so excited about avoiding big design and big planning that they tend to carry their skepticism on “big” efforts beyond the solution domain, all the way back into the problem domain. Thus, some AGILE teams would fall into the trap of also avoiding what they would perceive as “big analysis”, and would dismiss even the need for any preliminary structured requirements documentation.

This slant against starting a project with comprehensive requirements analysis is sometimes worn like a batch of AGILE purity by new converts. Its discourse, thrown around during project meetings, distracts the team from being effective at aligning solution design with strategic intent.

Strictly speaking there is no better defining moment for the success of an AGILE Project than prioritizing and grooming the product backlog to address high risks and high value opportunities during the earlier sprints. It follows that only comprehensive business analysis with a resulting requirements baseline can prepare the project team for this prioritization.

Project managers who are seasoned in AGILE would see no contradiction between employing adaptive methodologies in solution design while relying on a thorough analysis of the problem domain as a starting point, as long as requirements are identified and defined only at a low level of fidelity.

We are not stating anything outside the AGILE credo. Each iteration in AGILE is expected to start with the big Word: “Strategy” which means that AGILE expects a review of the problem domain, and an analysis of the requirements at the beginning of the sprint; however, in the real world, only in very limited contexts the team has the luxury of continuous access to a product owner who could articulate strategic intent.

For complex projects (think of an enterprise software implementation in a global context) it is harder to envision an AGILE team during their daily stand up or scrum, prioritizing among designs that address risks and opportunities, without a baseline of requirements validated by project stakeholders.

Arriving to such a baseline involves engaging in a comprehensive analysis of all processes to be impacted by the IT initiative. There is no cutting corners with enterprise analysis work here.

To follow the AGILE approach and define requirements “Just in Time” at the beginning of a sprint certainly adds flexibility and fluidity to product development; however, we have to be careful not to confuse “defining” requirements just in time with “discovering” requirements just in time. The latter is unpreparedness that increases project risk. It might not translate into reworks and value loss in very small projects (maybe not in the development of a webapp by a tech start-up, where strategic intent is questioned, shared, and understood by the team daily) But for more complex IT initiatives, with multiple stakeholders in matrix based contexts, the lack of a requirements baseline would make it harder for the AGILE team to determine which product increment would return the highest value in the project.

   December 28th, 2012 ByLarry Velarde, CBAP®

Leverforce  Copyright 2016 Leverforce Inc. Reservados todos los derechos. CBAP® es una marca registrada perteneciente al International Institute of Business Analysis. La marca de esta certificación es utilizada por los analistas de negocio que poseen la certificación CBAP, con el permiso expreso del International Institute of Business Analysis. IIBA®, el logo IIBA®, BABOK® y Business Analysis Body of Knowledge® son marcas registradas pertenecientes al Institute of Business Analysis. Estas marcas son utilizadas con el permiso expreso del International Institute of Business Analysis. 

Condiciones legales de uso y acceso a este sitio web

Módulos SAAS

  • Módulo: Necesidad de Negocio +

    Este módulo permite gestionar un listado de las necesidades de negocio asociada al análisis. Cada necesidad define lo que el cliente o el impulsor de la iniciativa (sponsor) busca obtener con los cambios solicitados en servicios TI, en términos de eliminación de problemas, mitigación de riesgos o aprovechamiento de oportunidades en su negocio. Read More
  • Módulo: Requisito de Usuario +

    Este módulo permite gestionar un listado de los requisitos de usuario asociados a una o varias necesidades de negocio. Un requisito de usuario explica un comportamiento o condición que el usuario necesita de un servicio TI para satisfacer la necesidad de negocio. Read More
  • Módulo: Requisito Funcional +

    Este módulo permite gestionar un listado de los requisitos funcionales asociados a uno o varios Requisitos de usuario. Un requisito funcional (Prefijo SLR) es la propuesta inicial del proveedor de TI que explica lo que hay que construir/cambiar en un servicio TI para que el usuario pueda disponer del comportamiento o condición solicitado en el requisito de usuario.. Read More
  • 1
  • 2
  • Modelio UML Tool +

    Leverforce permite la entrada de elementos UML (Casos de uso, Actividades, Actores, etc) desde la herramienta de modelado Modelio, vía la importación de archivos XMI. Read More
  • JIRA Issues +

    Set up JIRA projects from Leverforce’s SLA or Product Increment Modules. Read More
  • 1