Documento de análisis y especificación Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil

Transcripción

1 Documento de análisis y especificación Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil 05/04/2014 Ingeniería de Sistemas - PUJ Juan Darío Murcia Torres 0

2 Tabla de contenido Qué es?... 4 Cómo va? (Historial de Cambios)... 5 Documento de análisis y especificación Ingeniería de Requerimientos Qué es un requerimiento? Tipos de Requerimientos El Proceso Problemática e introducción a las Metodologías Ágiles Metodologías Ágiles Scrum XP (extreme Programming) Kanban SEMAT (Software Engineering Method And Theory) Los Alfas Principios del Kernel de SEMAT El Kernel es Accionable El Kernel es Extensible El Kernel es Práctico Qué se está haciendo hoy en día? Bibliografía

3 Tabla de ilustraciones Ilustración 1. Clasificación de Requerimientos... 8 Ilustración 2. Relación de los requerimientos con otros procesos de un proyecto (Tomado de [3]).. 10 Ilustración 3. Scrum (Tomado de [11]) Ilustración 4. XP. (Tomado de 20 Ilustración 5. Tablero Kanban. (Tomado de [19]) Ilustración 6. "Cosas con las que siempre trabajamos". (Tomado de [22]) Ilustración 7. "Cosas que siempre hacemos". (Tomado de [22]) Ilustración 8. Alfa - Oportunidad. (Tomado de [23]) Ilustración 9. Estados Alfa - Oportunidad. (Tomado de [23]) Ilustración 10. Alfa - Oportunidad; Estado - Identificado. (Tomado de [23]) Ilustración 11. Alfa - Oportunidad; Estado - Solución necesaria. (Tomado de [23]) Ilustración 12. Alfa - Oportunidad; Estado - Valor establecido. (Tomado de [23]) Ilustración 13. Alfa - Oportunidad; Estado - Viable. (Tomado de [23]) Ilustración 14. Alfa - Oportunidad; Estado - Dirigido. (Tomado de [23]) Ilustración 15. Alfa - Oportunidad; Estado - Beneficio acumulado. (Tomado de [23]) Ilustración 16. Alfa - Stakeholders. (Tomado de [23]) Ilustración 17. Estados Alfa - Stakeholders. (Tomado de [23]) Ilustración 18. Alfa - Stakeholders; Estado - Reconocido. (Tomado de [23]) Ilustración 19. Alfa - Stakeholders; Estado - Representado. (Tomado de [23]) Ilustración 20. Alfa - Stakeholders; Estado - Involucrado. (Tomado de [23]) Ilustración 21. Alfa - Stakeholders; Estado - De acuerdo. (Tomado de [23]) Ilustración 22. Alfa - Stakeholders; Estado - Satisfecho por el despliegue. (Tomado de [23]) Ilustración 23. Alfa - Stakeholders; Estado - Satisfecho en uso. (Tomado de [23]) Ilustración 24. Alfa Requerimientos Ilustración 25. Estados Alfa Requerimientos. (Tomado de [23]) Ilustración 26. Alfa - Requerimientos; Estado - Concebido. (Tomado de [23]) Ilustración 27. Alfa - Requerimientos; Estado - Delimitado. (Tomado de [23]) Ilustración 28. Alfa - Requerimientos; Estado - Coherente. (Tomado de [23]) Ilustración 29. Alfa - Requerimientos; Estado - Aceptable. (Tomado de [23]) Ilustración 30. Alfa - Requerimientos; Estado - Direccionado. (Tomado de [23]) Ilustración 31. Alfa - Requerimientos; Estado - Cumplido. (Tomado de [23]) Ilustración 32. Alfa - Sistema de software. (Tomado de [23]) Ilustración 33. Estados Alfa - Sistema de software. (Tomado de [23]) Ilustración 34. Alfa - Sistema de software; Estado - Arquitectura seleccionada. (Tomado de [23]) Ilustración 35. Alfa - Sistema de software; Estado - Demostrable. (Tomado de [23]) Ilustración 36. Alfa - Sistema de software; Estado - Usable. (Tomado de [23]) Ilustración 37. Alfa - Sistema de software; Estado - Listo. (Tomado de [23]) Ilustración 38. Alfa - Sistema de software; Estado - Operacional. (Tomado de [23]) Ilustración 39. Alfa - Sistema de software; Estado - Retirado. (Tomado de [23]) Ilustración 40. Alfa - Equipo. (Tomado de [23]) Ilustración 41. Estados Alfa - Equipo. (Tomado de [23]) Ilustración 42. Alfa - Equipo; Estado - Seeded. (Tomado de [23]) Ilustración 43. Alfa - Equipo; Estado - Formado. (Tomado de [23]) Ilustración 44. Alfa - Equipo; Estado - Colaborando. (Tomado de [23])

4 Ilustración 45. Alfa - Equipo; Estado - Ejecutando. (Tomado de [23]) Ilustración 46. Alfa - Equipo; Estado - Suspendido. (Tomado de [23]) Ilustración 47. Alfa - Trabajo. (Tomado de [23]) Ilustración 48. Estado Alfa - Trabajo. (Tomado de [23]) Ilustración 49. Alfa - Trabajo; Estado - Iniciado. (Tomado de [23]) Ilustración 50. Alfa - Trabajo; Estado - Preparado. (Tomado de [23]) Ilustración 51. Alfa - Trabajo; Estado - Comenzado. (Tomado de [23]) Ilustración 52. Alfa - Trabajo; Estado - Bajo control. (Tomado de [23]) Ilustración 53. Alfa - Trabajo; Estado - Culminado. (Tomado de [23]) Ilustración 54. Alfa Trabajo; Estado Cerrado. (Tomado de [23]) Ilustración 55. Alfa - Forma de trabajar. (Tomado de [23]) Ilustración 56. Estados Alfa - Forma de trabajar. (Tomado de [23]) Ilustración 57. Alfa Forma de trabajar; Estado Principios. (Tomado de [23]) Ilustración 58. Alfa Forma de trabajar; Estado Bases establecidas. (Tomado de [23]) Ilustración 59. Alfa Forma de trabajar; Estado En uso. (Tomado de [23]) Ilustración 60. Alfa Forma de trabajar; Estado En su lugar. (Tomado de [23]) Ilustración 61. Alfa Forma de trabajar; Estado Trabajando bien. (Tomado de [23]) Ilustración 62. Alfa Forma de trabajar; Estado Retirado. (Tomado de [23])

5 Qué es? Este documento es una síntesis de los diferentes escritos, artículos, libros y contenido académico en general que ha sido consultado por el estudiante para el trabajo de grado Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil. Este es el principal entregable generado durante la fase de Análisis y Especificación, y tiene como objetivo fundamental servir como base de conocimiento para la fase de Integración de Componentes. 4

6 Cómo va? (Historial de Cambios) A continuación se muestran a modo de comentarios, las adiciones y modificaciones del documento. Fecha Sección Comentario 03/02/2014 Todas Creación del documento. Se tomó como base la información recopilada durante vacaciones. 07/02/2014 1, 2 Refinación de ideas e inclusión de comentarios del SWEBOKv3. 11/02/2014 1, 2 Inclusión de ideas del Software Requirements de Wiegers. 12/02/2014 1, 2 Inclusión de otras ideas de Wiegers. 15/02/2014 1, 2, 3 Corrección de contenido. 20/02/ Adición de la sección 4. Qué se está haciendo hoy en día? 21/02/2014 Todo Revisión total de documento, y determinación temas que hacen falta. 24/02/ Corrección de algunos de los comentarios hechos por el Ingeniero Miguel. 26/02/ Corrección de otros comentarios hechos por el Ingeniero Miguel. 04/03/ Creación sección 1.2. Tipos de Requerimientos. 05/03/ Refinación de ideas. 06/03/ Creación sección 1.3. El Proceso. 07/03/ , Creación de las secciones Obtención de requerimientos; y Análisis de requerimientos. 09/03/ , Creación de las secciones Especificación de requerimientos; y Validación de requerimientos. 10/03/ , 1.3 Creación de la sección Gestión de requerimientos. 12/03/ Revisión de toda la sección 1.3. El Proceso. 14/03/2014 4, 5 Cambio de la Sección 4. Qué se está haciendo hoy en día? Por la sección 5. Qué se está haciendo hoy en día? E inclusión de la nueva sección 4. SEMAT (Software Engineering Method And Theory). 15/03/ Inclusión de nuevas ideas 16/03/ Inclusión de nuevas ideas 17/03/ Creación de la sección 3.3. Kanvan 19/03/ Refinamiento SEMAT 21/03/ Refinamiento SEMAT (Detallando los Alfas) 5

7 22/03/ Mejor detalle del Kernel (Inclusión de imágenes), y mejor especificación de los Alfas 23/03/ Especificación de Alfas faltantes. 29/03/2014 Todas Limpieza de comentarios, aceptación de cambios y revisión general. Especificación estados del Alfa Oportunidad. 30/03/ Especificación de estados del alfa Stakeholders 31/03/ y Especificación de estados del alfa Requerimientos 01/04/ , y Especificación de estados de los alfas Equipo, Trabajo y Forma de trabajo. 04/04/ Especificación de Kanban. 05/04/2014 Todas Revisión final 6

8 Documento de análisis y especificación 1. Ingeniería de Requerimientos 1.1. Qué es un requerimiento? Se conoce como requerimiento o requisito a una petición o declaración realizada por una o más personas, el cual traduce o expresa una necesidad. En el mundo del software, los requerimientos son usados para desarrollar un sistema que cumpla con dichas necesidades, teniendo en cuenta las condiciones y restricciones que estas conlleven [1] Tipos de Requerimientos Los requerimientos son un complejo conjunto de combinaciones que se genera por la interacción entre los actores de los diferentes niveles en una organización [2]. En un proyecto de software, se pueden encontrar varios tipos de estos. A nivel general, se podrían clasificar en dos grandes clases, los requerimientos del producto [2], y a un nivel más de la organización, se encuentran los requerimientos de negocio [3]. En cuanto a los requerimientos de negocio, básicamente se pueden encontrar las reglas de negocio, y los requerimientos/restricciones de procesos. Este tipo de requerimientos afecta al producto en cuanto a que lo restringe de acuerdo a los objetivos de la organización y al negocio en sí mismo [3]. Acá se tienen en cuenta las diferentes reglamentaciones de acuerdo a la naturaleza de cada organización, y por tal motivo, esto también encierra diferentes estándares, pólizas y normas de regulación en general [3]. Este tipo de requerimientos son establecidos por la organización, y en algunos casos (como en los requerimientos de proceso) los clientes o terceros [2]. Los requerimientos del producto abarcan más tipos de requerimientos, y se refieren básicamente a las necesidades o restricciones del software desarrollado [2]. En esta categoría se encuentran contenidos los requerimientos de usuario, y los requerimientos del sistema, y estos a su vez se dividen en muchos más requerimientos. Todos los requerimientos de esta categoría son proporcionados en su gran mayoría por los Stakeholders (usuarios, clientes, y cualquier otra persona u organización afectada por el software a desarrollar), sin embargo, no se debe descartar la posibilidad de que la organización o terceros también proporcionen información de valor. A continuación se muestra un diagrama con la clasificación que he realizado, luego de leer diferentes autores, y cabe aclarar que estos son sólo algunos de los tipos de requerimientos más usados, sin embargo dependiendo de cada autor esta clasificación puede variar. 7

9 Requerimientos Req. Negocio Req. Producto Req. Proceso Reglas de Negocio Req. Usuario Req. Sistema Req. Software Req. Hardware Req. Funcionales Req. No Funcionales Ilustración 1. Clasificación de Requerimientos Pero cuáles son las características de cada tipo de requerimiento?, a continuación se explica brevemente cada uno: Requerimientos de negocio Se refieren a un conjunto de información de alto nivel que, en su totalidad, describe una necesidad del negocio, y que lleva a uno o más proyectos a ofrecer una solución y los resultados operativos deseados [3]. Dichas soluciones o resultados se podrían presentar por medio del desarrollo de un producto por parte de la misma organización, o acordar con algún tercero para que este lo haga. [2] Requerimientos de proceso Este tipo de requerimientos son proporcionados como necesidades durante todo el proceso del proyecto, y se refieren al cómo hacer las cosas. Se pueden ver como restricciones en cuanto a las metodologías usadas, con el fin de que estas no vallan en contra a los objetivos de la organización, ni de los clientes. Pueden ser proporcionados por las directivas, los clientes, e inclusive algunos terceros. [2] Reglas de negocio Se refieren a todo tipo de normas, estándares y reglamentación en general (tanto internas de la organización, como externas a esta), que limitan al negocio. [3] Requerimientos de producto Este tipo de requerimientos abarca a todas aquellas necesidades que sean tenidas en cuenta para el producto o sistema en general [2]. Dichos requerimientos suelen ser proporcionados por los usuarios y los clientes, sin embargo, también podrían estar derivados de algunos requerimientos de negocio [3] Requerimientos de usuario Describen a las necesidades del negocio, desde el punto de vista de las personas y los resultados que estas quieren obtener del nuevo producto. [4] 8

10 Requerimientos del sistema Este tipo de requerimientos agrupan a todos los relacionados con las capacidades del sistema, e incluyen las capacidades que deben ser proporcionadas por el software, el hardware y las personas [3] Requerimientos de hardware Se refieren a todas necesidades, características y restricciones de dispositivos y componentes físicos que sean necesarios para desarrollar y soportar la solución de software generada Requerimientos de software Este tipo de requerimientos tiene en cuenta más que al sistema en general, al conjunto de características y funcionalidades que se espera, tenga el software desarrollado Requerimientos funcionales Se pueden ver como una descripción del comportamiento que el sistema deberá mostrar bajo condiciones específicas [3]. Este comportamiento se entiende como la funcionalidad que el software va a ejecutar [2] Requerimientos no funcionales Este tipo de requerimientos son más que todo, restricciones que limitan al sistema, y que describen características que este debe mostrar. En algunos casos, son llamados atributos de calidad, y generan otro tipo de requerimientos como lo son, requerimientos de rendimiento, de mantenibilidad, de safety, de confiabilidad, de seguridad, y de interoperabilidad, entre otros. [2] Como se mencionó anteriormente, estos tipos de requerimientos son sólo algunos de los que se pueden encontrar en los textos, y que dependiendo el autor, podría variar el nombre y definición acá proporcionado. Una vez mencionado lo anterior, es pertinente decir, que los requerimientos no solo son proporcionados por los usuarios del sistema, los dueños de este, terceros o en general, los diferentes Stakeholders, ya que existen algunas propiedades emergentes que van saliendo a la luz a medida que avanza el proceso de Ingeniería de Requerimientos. Estas propiedades, también son consideradas como requerimientos, y por su naturaleza, no pueden ser trazables a componentes en específico, ya que estas dependen de cómo interactúen todos los componentes de software. [2] 1.3. El Proceso El término de Ingeniería de Requerimientos (IR) tal y como se conoce actualmente comenzó a usarse luego de una publicación de la IEEE Computer Society en 1990 [5], y corresponde a un proceso sistemático para el descubrimiento, desarrollo, trazabilidad, análisis, clasificación, comunicación y gestión de requerimientos, el cual define un sistema en niveles sucesivos de abstracción [6]. Desde entonces dicho proceso es considerado como una parte fundamental de cualquier proceso de desarrollo de software, sin embargo el detalle en cada una de sus etapas depende del tipo de metodología de desarrollo a implementar. Algunos autores consideran que el término de Ingeniería de Requerimientos está mal usado, y que en vez de este, debería ser el de Requerimientos de Software, sin embargo para este documento, y el resto de los entregables, se va a continuar usando el término de Ingeniería de Requerimientos para referirse a dicho proceso. Como ya se ha mencionado anteriormente, la IR es sólo un proceso dentro de todo proyecto de desarrollo de software. Este proceso busca fundamentalmente facilitar las tareas que soporten los demás procesos de negocio al interior de una organización [2]; y como todo proceso, sirve de entrada y salida para muchos otros. A medida que los Ingenieros de software adquieren 9

11 conocimiento y habilidad en la gestión de estos proyectos, se observan mayores capacidades para relacionar procesos de todo el proyecto u organización. Ilustración 2. Relación de los requerimientos con otros procesos de un proyecto (Tomado de [3]) Obtención de requerimientos Esto es lo primero en cualquier proceso de IR, y abarca todo lo relacionado con el descubrimiento de estos, y el cómo el ingeniero de software los recolecta. Acá se realizan actividades tales como entrevistas, creación de escenarios, reuniones y talleres, análisis de documentos y prototipos, observación de actividades e historias de usuarios, entre otras, con el fin de abarcar todo el entorno y obtener el mayor detalle posible acerca del nuevo software a desarrollar. [2] [3] En la obtención de requerimientos, así como en todo el proceso de IR y el Ciclo de Vida del Desarrollo de Software, el principio fundamental es la comunicación efectiva entre los Stakeholders (los cuales también son definidos con detalle en esta fase), y el equipo desarrollador [2]. Para facilitar la comunicación, se hace necesario tener modelos consistentes en los diferentes niveles de abstracción, y esto se logra primero que todo, clasificando e identificando a los individuos que mejor conocen los procesos que se verán afectados por el nuevo software, esto con el fin entender sus tareas y los objetivos de negocio con las que estas se alinean. También es fundamental aprender del entorno en el cual el nuevo producto será usado, con el fin de aterrizar los requerimientos obtenidos. [3] Para que esta fase tenga éxito, lo fundamental es tener un completo entendimiento de la problemática que se piensa solucionar, y esto implica conocer detalladamente: los objetivos de alto nivel de la organización, los Stakeholders, las reglas del negocio, y los ambientes operacional y organizacional Análisis de requerimientos Al igual que las otras fases del proceso de IR, esta parte es fundamental para el proyecto e implica un alto grado de compromiso y detalle por parte de los analistas de requerimientos. Los resultados de esta fase podrían definir en gran parte el éxito o fracaso del proyecto. 10

12 El análisis de requerimientos se ocupa principalmente de detectar y resolver los conflictos entre los requerimientos obtenidos en la etapa anterior, de igual forma descubrir los límites del software y cómo este podría interactuar con los ambientes organizacional y operacional. De igual forma, en esta fase, son generados los requerimientos de software con base a los requerimientos del sistema. [2] Para poder realizar lo mencionado anteriormente, primero que todo se debe analizar la información recolectada en la etapa de obtención de requerimientos, y detallar el objetivo de las tareas de los usuarios, esto con el fin de clasificar los requerimientos de acuerdo a su naturaleza, es decir, si son propiamente del negocio, o si son del sistema. Los requerimientos de negocio, aportarán información importante y un contexto a los del sistema y posteriormente a los de software [3]. Seguido de esto, se toman los requerimientos de alto nivel y se descomponen con un apropiado nivel de detalle [3]. Estos sirven para completar los requerimientos del sistema. Se detallan y clasifican los requerimientos de software, y con estos los funcionales, no funcionales y los demás requerimientos que hacen falta por clasificar [2] [3]. Una vez realizada dicha clasificación de requerimientos, se asigna una prioridad a cada requerimiento teniendo en cuenta los diferentes factores que pueden afectar al proyecto [2], estos son los costos, el tiempo, las probabilidades de cambio de estos durante el ciclo de vida del proyecto e inclusive los objetivos del negocio. Después de la priorización, viene el modelado. En esta parte la idea es entender mejor la situación en la que un problema dado ocurre, y la solución presentada. Para esto, se pueden usar diagramas de casos de uso, modelos de flujo de datos, modelos de estado, modelos basados en objetivos, interacciones entre usuarios, modelos de objetos y modelos de datos, entre otros [2]. Para realizar el modelado, hay que tener en cuenta factores como la naturaleza del problema, la experticia del ingeniero de software y las peticiones de cada usuario. En esta fase también es importante tener en cuenta la arquitectura del sistema, ya que los nuevos requerimientos deben satisfacer dicha arquitectura, y en algunas ocasiones se hace necesario modificarla para que se acople correctamente. Esta ya es la parte final de la fase, y una vez que se tiene en cuenta la priorización y la arquitectura, se procede a negociar los requerimientos con el usuario, ya que no siempre lo que este desea es posible Especificación de requerimientos La especificación de requerimientos consiste en, una vez establecidos los requerimientos que realmente tienen valor para el cliente y para el negocio, traducir estos a requerimientos formalmente constituidos [3]. Estos requerimientos formarán parte de un documento que podrá ser revisado, evaluado y aprobado de manera sistemática por parte del equipo de desarrollo y del cliente. Dependiendo de la complejidad de cada sistema, podrán ser generados hasta tres documentos diferentes en esta fase: Documento de Definición del Sistema, Especificación de Requerimientos del Sistema, y Especificación de Requerimientos de Software (SRS); para el caso de proyectos de software simples, sólo es necesario el SRS. [2] En el SRS se establecen los requerimientos negociados entre el cliente y la parte que va a desarrollar el software, de esta manera, se llega a un consenso sobre lo que el software debe y no debe hacer. Algo importante en la construcción de este documento, es el formalismo a la hora de escribir cada requerimiento, ya que entre más detallado y formal se escriba, permitirá reducir la probabilidad de errores en la especificación y con esto, tener que rediseñar el sistema en un futuro; también esto permitirá determinar con mayor precisión los costos, riesgos y el calendario. Este documento será la 11

13 base sobre la cual trabajarán los ingenieros en un futuro, y es sobre este que verificarán y validarán los planes. [2] Validación de requerimientos Una vez terminada la especificación, viene la validación de requerimientos. Acá básicamente se determina por parte de los desarrolladores, si los requerimientos especificados anteriormente realmente ayudarán a dar solución a la problemática, y si satisfacen los objetivos del negocio [3]. Para lograr lo anteriormente propuesto, es necesario asegurarse que los ingenieros de software hayan comprendido correctamente los requerimientos, y esto es posible realizando un conjunto de actividades en compañía de los diferentes Stakeholders a fin de aprobar o desaprobar lo que hasta el momento se ha especificado [2]. La primera actividad que se debe realizar es revisar los documentos generados en la fase anterior, con el fin de encontrar errores, suposiciones incorrectas y falta de claridad, esto último generado usualmente por requerimientos poco entendibles, inconsistentes e incompletos. Adicional a esto, se pueden crear prototipos que permitan una mejor interpretación de las suposiciones de los ingenieros de software, lo malo con estos, es que pueden ser costosos de desarrollar. Finalmente, se crean pruebas de aceptación, para determinar qué requerimientos después de todo no son válidos, y no deben ser tenidos en cuenta. Todo esto se debe hacer a fin de corregir posibles problemas antes de aceptarlos y continuar con el proceso de desarrollo Gestión de requerimientos La gestión de requerimientos no se ejecuta en algún momento en específico del proyecto, sino que abarca todo lo referente a la planeación, monitorización del progreso y gestión de cambios durante todo el ciclo de vida de este [6]. Tiene como principio el que los requerimientos de un proyecto de software pueden cambiar en cualquier momento [1], y teniendo en cuenta esto, establece procedimientos para la definición, control y publicación de requerimientos de línea base [1]. Existen muchos tipos de proyectos, y la gestión, es algo común en todos, sin embargo, dependiendo el tipo de proyecto, esta podría generar mejores resultados si se efectúa de una u otra forma. La planeación debería ser gestionada de acuerdo a los resultados generados en cada etapa. Dichos resultados tendrían que ser aprobados antes de realizar cualquier actividad por el experto del negocio, a fin de establecer si las soluciones propuestas van acorde a las necesidades de los usuarios, y si estas no van en contra de los objetivos del negocio. En el caso de proyectos de desarrollo de software, esta aprobación se da con la aceptación del documento SRS. [6] La monitorización del proyecto se realiza por medio de la recolección de métricas. Estas consisten en un conjunto de información obtenida a medida que avanzan las diferentes actividades propuestas. Existen diferentes tipos de métricas, como por ejemplo, las de calidad y rendimiento, las cuales por sí solas no dirán mucha información a menos que sean comparadas con los planes determinados anteriormente. Una vez que las métricas son comparadas con los planes, se podrá determinar el progreso del proyecto, y así, tomar decisiones más acertadas respecto a este. [6] La gestión de cambios usa como principal herramienta el versionamiento de los diferentes documentos y artefactos generados durante cada actividad. Acá es donde se definen las características y los artefactos de línea base que se generarán durante el proyecto, por lo que es necesario, siempre al principio de este, establecer las diferentes reglas (nombre, historial de cambios ) que se tendrán en cuenta a la hora de crear dichos artefactos, esto con el fin de lograr una fácil trazabilidad y manejo de versiones. En el caso de que en un futuro haya la necesidad de volver a un estado anterior en algún documento o versión de software, el proceso anterior hará que 12

14 no sea traumático, ni genere muchos inconvenientes. Un mal manejo de versiones y de gestión de cambios en general, podría verse traducido en tener que hacer re-planeación de alguna de las etapas establecidas desde el inicio del proyecto. [1] [6] Se debe tener cuidado con los excesos y/o fallas en la gestión, ya que esto podría traer sobrecostos, retrasos en el calendario, errores de diseño, clientes insatisfechos, y hasta la cancelación del proyecto [1]. 13

15 2. Problemática e introducción a las Metodologías Ágiles Los principales inconvenientes que surgen en un proyecto, con relación a los requerimientos, se dan por la importancia que tienen los Stakeholders, en cuanto a que al ser ellos los conocedores/afectados del sistema, son los encargados de proporcionar los requerimientos del mismo, los cuales se pueden observar como complejas combinaciones de diferentes niveles de la organización, y que se conectan con las características del ambiente en el que este va a operar [2]. Por esto, las personas son consideradas indispensables, pero muchas veces no cuentan con la paciencia o tiempo para participar en las actividades que implican este proceso [3]. Este tipo de problemas son más comunes en metodologías tradicionales, en las cuales los ingenieros deben valerse de diferentes técnicas durante la etapa de obtención de requerimientos, con el fin de que la información obtenida sea relevante y suficiente para continuar con las siguientes etapas y desarrollar el sistema que el cliente realmente espera. Caso contrario a las metodologías ágiles, en las cuales el cliente y/o usuario está presente durante la mayor parte del proceso de desarrollo, haciendo que el producto (o subproductos) final generado, esté más acorde a los requerimientos del usuario. Las metodologías ágiles fueron introducidas formalmente desde mitad de los años 90s con la implementación de los métodos más usados (RUP, Scrum y XP), pero fue hasta 2001 cuando se conocieron formalmente como metodologías ágiles con la publicación del Manifiesto Ágil [7] [8]. Teniendo en cuenta que una IR formal gasta tiempo, y con la necesidad de rápidos cambios en el software, las metodologías ágiles han obtenido gran popularidad debido a los enormes cambios tecnológicos de los últimos tiempos, y a las facilidades y oportunidades que ellos han generado en cuanto a comunicaciones, mercados y condiciones económicas. Estos cambios obligan a los sistemas nuevos y a los ya existentes a responder de manera competitiva a las diferentes demandas que se proponen a diario [9], por tal motivo, se espera que el software desarrollado hoy en día atienda dichas necesidades. En este tipo de metodologías, se considera que es mejor dedicar más esfuerzos y recursos a la elaboración propia del producto, y no sólo a las fases iniciales del proyecto. Teniendo en cuenta esto, se asume que la simplicidad en las tareas es un factor fundamental a la hora de desarrollar software [8]. Parte de esta simplicidad consiste en la reducción de la formalidad que implica el proceso de IR, dedicando más esfuerzos a la creación de software funcional por medio de una fuerte comunicación con el cliente, sin embargo, al no ser este tipo de metodologías lo suficientemente formal, algunos elementos no se encuentran claramente separados e identificados, provocando dificultades en el futuro cuando se necesite algún producto propio de estos procesos (problemas con la trazabilidad de requerimientos y/o subproductos generados) [10]. Con el paso del tiempo se han observado algunos cambios y tendencias en la forma de desarrollar software, y esto no solo incluye metodologías de desarrollo, sino también todo lo referente a la IR. Algunas cosas han cambiado y otras han continuado igual, como es el caso de la falta de relevancia que se le da al proceso de IR aun cuando es conocido por todos los Ingenieros de Software que éste hace parte fundamental en cualquier proyecto de desarrollo y el típico problema de todo proyecto que se da porque los Stakeholders ignoran lo que realmente quieren [3]. Por otro lado, el avance tecnológico de los últimos tiempos, unificado a la necesidad de que éste sea cada vez más rápido, y la búsqueda por cumplir las diferentes expectativas referentes a las comunicaciones y a los nuevos mercados, hace que el nuevo software a desarrollar deba ser más 14

16 competitivo. Teniendo en cuenta este contexto de continuo cambio, se han observado diferentes tendencias que cada vez son más fuertes. Algunas de dichas tendencias se podrían relacionar con el fortalecimiento de las metodologías ágiles por medio de un uso más amplio de la IR en proyectos de desarrollo, lo que genera una mayor y más fácil integración en proyectos futuros [3]. Adicional a esto, se han desarrollado herramientas que ayudan la gestión de requerimientos y de algunos de los componentes propuestos durante el proceso de IR como el Product Backlog (en el caso de Scrum) [3]. Dichas herramientas deberían poder usarse acorde al principal referente que se tiene hoy en día en cuanto a requerimientos, el estándar ISO/IEC/IEEE [1], el cual no garantiza por completo que lo que se esté haciendo se encuentre bien, pero por lo menos sirve de guía a los Ingenieros y Stakeholders en este importante proceso. 15

17 3. Metodologías Ágiles 3.1. Scrum Considerado como el método ágil más popular, Scrum es un framework iterativo e incremental para proyectos y productos o desarrollo de aplicaciones [11] que se desarrolla en ciclos de trabajo llamados Sprints. Scrum no es un proceso o técnica para construir productos; en lugar de eso es un marco de trabajo dentro del cual se pueden emplear varias técnicas y procesos [12]. El marco de trabajo de Scrum consiste en el equipo Scrum, roles, eventos, artefactos y reglas asociadas, los cuales son mostrados como interacción en la Ilustración 3. Ilustración 3. Scrum (Tomado de [11]) Scrum se encuentra basado en controles de procesos empíricos, de modo que se asegura que el conocimiento precede de la experiencia y se puedan tomar decisiones más acertadas. Existen tres pilares que soportan la implementación del proceso empírico, estos son [12]: Transparencia, que implica que los aspectos significativos deben ser visibles para los responsables del resultado, lo que se logra por medio de la estandarización de dichos aspectos. Inspección constante y moderada de los artefactos de Scrum, de manera que sin interferir en el trabajo, se logren identificar variaciones en estos. Adaptación de procesos o artefactos de manera oportuna, de tal forma que no se presenten mayores desviaciones en el rumbo del proyecto Scrum Team El equipo Scrum consta de 3 roles: Dueño del Producto (Product Owner): Es el único responsable (persona) de gestionar el Product Backlog, y sus decisiones deben ser respetadas por la organización. Esta gestión incluye [12]: 16

18 o o o o o Expresar claramente los elementos del Product Backlog. Ordenar los elementos del Product Backlog para alcanzar los objetivos y misiones de la mejor manera posible. Optimizar el valor del trabajo desempeñado por El Equipo. Asegurar que el Product Backlog sea visible, transparente y claro para todos, y que muestre en lo que El Equipo trabajará a continuación. Asegurar que el equipo de desarrollo entiende los elementos del Product Backlog al nivel necesario. El Equipo (The Team): Los equipos son auto-gestionados, auto-organizados y multifuncionales, y son los responsables de encontrar la manera de convertir el Product Backlog en un incremento de funcionalidad al interior de cada iteración gestionando su propio trabajo a ser realizado. Los miembros del equipo son responsables del éxito de cada iteración y del proyecto en conjunto [13]. El tamaño óptimo de El Equipo debe estar entre 3 y 9 personas, que es un grupo lo suficientemente pequeño como para permanecer ágil, y lo suficientemente grande como para completar una cantidad de trabajo significativa. Scrum Master: No es el administrador del equipo ni del proyecto. El Scrum Master es el responsable de asegurar que Scrum se aplique y sea entendido de la manera adecuada y está al servicio del Scrum Team para garantizar que éste trabaje ajustado a la teoría, prácticas y reglas de Scrum. De igual forma ayuda a externos al Scrum Team a entender qué interacciones con el equipo pueden ser de ayuda y cuáles no, además de maximizar el valor creado por el Scrum Team por medio de modificaciones de dichas interacciones. [12] Eventos de Scrum En Scrum, todo el trabajo se realiza en Sprints (son el corazón de Scrum), los cuales contienen a todos los eventos de Scrum. Dichos eventos son bloques de tiempo, de manera que tienen una duración máxima. Una vez comienza un Sprint, su duración es fija y no puede acortarse o alargarse. Los demás eventos pueden terminarse una vez alcancen el objetivo del evento, asegurando que se emplee la cantidad de tiempo apropiada y sin desperdicio en el proceso. [12]. Cada Sprint debe tener una duración de 2 a 4 semanas (no más, no menos); tiempo en el cual se crean incrementos en el producto. Estos incrementos implican un producto utilizable y potencialmente desplegable. No puede haber miembros de un mismo Equipo Scrum en Sprints simultáneos, por lo que cada iteración inicia con la finalización de la anterior. En un Sprint no se realizan cambios que afecten al Sprint Goal u Objetivo del Sprint, de manera que los objetivos de calidad no se disminuyen. El alcance puede ser clarificado y renegociado entre el Product Owner y El Equipo a medida que se obtiene nuevo conocimiento [12]. Un Sprint podría ser cancelado únicamente por el Product Owner, y sólo si el Sprint Goal quedara obsoleto por cambios en el negocio, mercado o tecnología. Debido a la corta duración de las iteraciones, es raro cancelar Sprints, sin embargo si esto llegase a suceder, se entra a una etapa de evaluación por parte del Product Owner para determinar si hay trabajo potencialmente entregable, y se vuelven a estimar los elementos no terminados del Product Backlog. Una cancelación genera costos y traumas para el proyecto. [12]. A continuación se enuncian y se da una breve explicación de los eventos en Scrum: 17

19 Objetivo del Sprint (Sprint Goal): Es propuesto durante el Sprint Planning Meeting, y corresponde a la meta establecida para el Sprint. Proporciona una guía al Equipo acerca del por qué se está realizando dicho incremento. Los eventos al interior de los Sprints que Scrum proporciona para la inspección y adaptación tanto de los procesos usados, como de los artefactos producidos, son los siguientes cuatro [12]: Reunión de planificación del Sprint (Sprint Planning Meeting): Es la reunión inicial de cada Sprint, en la que se planifica el trabajo a realizar durante la iteración. Esta reunión es vigilada por el Scrum Master para asegurar que se haga de la manera adecuada y no debería durar más de 8 horas. Durante esta reunión se responden principalmente las siguientes preguntas: o o Qué puede entregarse en el incremento resultante del Sprint que comienza? Cómo se conseguirá hacer el trabajo necesario para entregar el incremento? Scrum diario (Daily Scrum): Reunión diaria de 15 minutos de duración en la que todos los miembros del Equipo deben estar presentes, con el fin de crear un plan para las siguientes 24 horas. Durante esta reunión se pretende que cada miembro del Equipo responda las siguientes preguntas: o o o Qué hice ayer que ayudó al Equipo a cumplir con el Sprint Goal? Qué haré hoy para ayudar al Equipo a cumplir con el Sprint Goal? Veo algún impedimento que evite que El Equipo o yo logremos el Sprint Goal? Revisión del Sprint (Sprint Review): Al terminar el Sprint, El Equipo dedica 4 horas o menos (dependiendo la duración del Sprint) para presentar al Product Owner lo realizado durante la iteración [13], con el fin de actualizar el Product Backlog y definir los elementos para el siguiente Sprint. El Sprint Review corresponde a una reunión informal y no de seguimiento, en la que pueden además participar los interesados que colaboraron al Equipo. Adicional a la presentación ante el Product Owner, se busca fomentar la colaboración entre El Equipo. Al igual que en el Sprint Planning Meeting, es deber del Scrum Master asegurarse que la reunión se haga de la manera adecuada. Retrospectiva del Sprint (Sprint Retrospective): Reunión de duración no mayor a 3 horas (dependiendo la duración del Sprint), en la que se tiene como propósito: o o o Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas. Identificar y ordenar los elementos más importantes que salieron bien, y las posibles mejoras. Crear un plan para implementar las mejoras a la forma en que el equipo Scrum desempeña su trabajo. Las mejoras propuestas deben ser validadas junto al Scrum Master, garantizando que se implementen dentro del framework de Scrum. 18

20 Artefactos Scrum Scrum define los siguientes artefactos con el fin de proporcionar transparencia y oportunidades para la inspección y adaptación [12]: Product Backlog: Contiene una lista de los requerimientos (características) del sistema o producto a ser desarrollado por el proyecto, junto a una descripción, ordenación, estimación y valor para cada ítem. El Product Owner es el responsable del contenido y su priorización y disponibilidad. El Product Backlog es dinámico; la gestión cambia constantemente para identificar lo que el producto necesita para ser apropiado, competitivo y útil [13]. Un proceso continuo durante todo el proyecto, es el de refinamiento del Product Backlog, que consiste en añadir detalle, estimaciones y orden a los elementos de la lista en su interior. Durante este proceso son examinados y revisados los elementos de la lista. Este refinamiento es posible, gracias al avance logrado con el cumplimiento de los Sprint Goals [12]. Sprint Backlog: Especifica el trabajo o lista de tareas que El Equipo define seleccionar del Product Backlog para un Sprint específico. En el Sprint Backlog se hace visible todo el trabajo que El Equipo considera como necesario para lograr el Sprint Goal. A medida que el trabajo se completa, se va actualizando la estimación del trabajo restante XP (extreme Programming) Metodología ágil de desarrollo propuesta formalmente por primera vez en Extreme Programming Explained [14], donde fue definida como un ligero, eficiente, de bajo riesgo, predecible, científico y divertido método para desarrollar software. Se diferencia según su autor Kent Beck por [15]: Su anticipada, concreta, e inmediata reacción de ciclos internos. Su enfoque de planeación incremental, el cual rápidamente surge con un plan general que se espera, evolucione a través del ciclo de vida del proyecto. Su capacidad de programar con flexibilidad la implementación de la funcionalidad, en respuesta a las cambiantes necesidades del negocio. Su dependencia de pruebas automatizadas escritas por clientes y programadores para monitorear el progreso del desarrollo, permitiendo al sistema evolucionar y capturar los defectos tempranamente. Su dependencia de la comunicación oral, pruebas, y código fuente para comunicar la estructura y propósito del sistema. Su dependencia de un proceso de diseño evolutivo que dura lo que dura el sistema. Su dependencia de la estrecha colaboración de los programadores con conocimientos comunes. Su dependencia de las prácticas que funcionan tanto con los instintos de corto plazo de los programadores y como de los intereses a largo plazo del proyecto. 19

21 Como se mencionó anteriormente, XP es considerado una metodología ágil para el desarrollo de software, por lo que suele ser complementario a Scrum (que es menos técnico y más enfocado hacia la gestión de proyectos) [9]. En la primera versión de XP, este era definido con 4 valores, 15 principios básicos y 20 prácticas, y se indicaba de manera muy estricta que para poder ser XP, se tenían que cumplir las 20 prácticas propuestas, sin embargo, desde su segunda edición, pasó a ser definido por medio de 5 valores, 14 principios, 13 prácticas primarias y 11 de corolario. [16] Valores XP A continuación se enuncian los valores en los que se basa extreme Programming [16]: Comunicación: Para evitar errores y problemas es necesario que los miembros del equipo se comuniquen de manera adecuada y constante. Simplicidad: Aunque requiere experiencia, y trabajo duro, es necesario hacer las cosas lo suficientemente simples como para no afectar la comunicación en el equipo y reducir la cantidad de código. Retroalimentación: Es un componente importante de comunicación, y fortalece a esta en cuanto se realice de manera apropiada. Esto contribuye a la simplicidad. Coraje: Valores como la comunicación, simplicidad y retroalimentación permitirán hacer frente con valentía, incluso a grandes cambios en requerimientos y refactorización sustancial del sistema. Respeto: Para lograr lo anterior, los miembros del equipo de desarrollo deben ser respetuosos con ellos y sus contribuciones. Ilustración 4. XP. (Tomado de 20

22 Principios XP Los principios en los que se basa XP son [16]: Humanidad: El software es desarrollado por personas, por lo que es necesario saber estimar los objetivos y necesidades de las personas, pero esto debe hacerse de manera que no se afecte la productividad. Económico: Si se produce software, este debería generar valor para el negocio. Dos aspectos económicos son claves para XP: el valor presente y el valor de las opciones. El primer aspecto sugiere que entre más temprano se desarrolle el software, va a ser más rentable para el negocio. El segundo indica que se pueden aplazar las inversiones en diseño hasta que sean obvias. Beneficio mutuo: Cualquier actividad debería beneficiar a todas las personas y a la organización, sin embargo esto es difícil de realizar debido a que por lo general las cosas que son beneficiosas para unos, no siempre lo son para otros. Auto-semejanza: Se debe tener la capacidad de reutilizar soluciones similares en diferentes contextos. Mejora: La perfección no existe, sin embargo se debe luchar constantemente para alcanzarla, esto es por medio de iteraciones en el desarrollo que proporcionen funcionalidades y calidad por medio de la retroalimentación. Diversidad: Los equipos deberían incluir personas con diferentes conocimientos, cualidades y caracteres, ayudando a proporcionar una mayor cantidad de soluciones. Reflexión: Los equipos efectivos no deberían hacer el trabajo porque sí. Es necesario que se pregunten el cómo están trabajando, y el por qué lo están haciendo de esa manera. Flujo: Las prácticas de XP sugieren un continuo flujo de actividades y no una secuencia de diferentes fases que libere software hasta el final. Oportunidad: Los problemas deben ser vistos como oportunidades de mejora. Siempre se van a presentar inconvenientes y es allí donde se hace necesario aprender, y generar retroalimentación. Redundancia: Problemas críticos y dificultades deberían poder ser resueltos de diferentes maneras. Esto asegura que al tener muchas posibilidades, si alguna falla, otras podrían prevenir un desastre. Fracaso: No se debe relacionar con un aspecto negativo, siempre que se pueda aprender de ellos. Calidad: La calidad siempre debe ser máxima, y no se debe confundir con el perfeccionismo. Pequeños pasos: Es peligroso aplicar en un solo paso grandes cambios realizados en un largo periodo de tiempo. Por lo que se ve necesario proceder paso a paso y de manera iterativa, asegurando que no se produzcan daños por aplicar cambios en la dirección equivocada. Responsabilidad aceptada: La responsabilidad solo puede ser aceptada. Es fácil ordenar a los desarrolladores haga esto o haga aquello, pero esto no es trabajar. 21

23 Prácticas XP Existen dos grupos de prácticas, las primarias y las de corolario. Beck propone que estas prácticas deben aplicarse completamente para obtener los máximos beneficios de XP. Aunque no se proporciona una clasificación oficial por parte del autor, las prácticas se podrían clasificar de la siguiente manera [16]: Prácticas primarias o Planeación y análisis de requerimientos Historias: Las funcionalidades del sistema son descritas usando historias, que son pequeñas descripciones visibles al cliente, de lo que puede hacer el sistema. Ciclo semanal: El desarrollo de software es realizado por semana. Al comienzo de cada semana se realiza una reunión donde las historias de desarrollo son seleccionadas por el cliente. Ciclo trimestral: En escalas de tiempo mayor, el desarrollo es planeado por trimestre. Esto incluye reflexiones del equipo, del proyecto y del progreso. Flojo: Evite hacer promesas que no pueda cumplir. Todo plan incluye tareas que podrán ser ignoradas. o Factores humanos y equipo Sentarse juntos: Para maximizar la comunicación, los equipos de desarrollo deberían trabajar en espacios abiertos, permitiendo alojar al equipo completo. Todo el equipo: El equipo debe estar compuesto por miembros que cumplan con todas las características y necesidades del proyecto. Espacio de trabajo informativo: El espacio de trabajo debería ser provisto con carteleras y otras cosas que proporcionen información del estado del proyecto y las tareas a ser realizadas. Trabajo energizado: Los desarrolladores deben ser productivos y estar atentos a su trabajo. Programación en pares: El código debe ser escrito por dos programadores en una misma máquina. o Diseño Diseño incremental: El diseño es indispensable para obtener buen código, y se sugiere que sea realizado de manera incremental durante la codificación. Programación de primero prueba : Antes de escribir el código, se hace necesario desarrollar las pruebas que lo verificarán. o Codificación de software y liberación 22

24 Compilación de 10 minutos: El sistema debería ser compilado y todas las pruebas deberían ser finalizadas en 10 minutos, en orden de que se ejecute y se pueda obtener retroalimentación. Integración continua: Los desarrolladores deberían integrar cambios cada 2 horas. Prácticas de corolario o Planeación y análisis de requerimientos Participación real del cliente: Las personas que se vean afectadas por el sistema, deberían ser parte del equipo y pueden contribuir a la planificación semestral o trimestral. Despliegue incremental: Cuando se reemplacen los restos de un sistema, es necesario reemplazar primero algunas funcionalidades, y gradualmente todo el sistema. Contrato de alcance negociado: Los contratos para el desarrollo de software, deberían tener de manera fija elementos como tiempos, costos y calidad, pero el alcance del proyecto debería ser negociado durante su realización. Pago por uso: El cliente suele pagar por versión de software, esto crea un conflicto entre el proveedor y el cliente debido a que este último quiere grandes cambios en menos versiones, lo que está completamente por fuera de XP. o Factores humanos y equipo Continuidad del equipo: Los equipos de desarrollo deberían ser los mismos para todos los proyectos. Contracción de equipos: Como el equipo se vuelve más capaz y productivo, es necesario mantener la carga, pero reducir gradualmente al equipo, enviando a los miembros libres a formar nuevos equipos. o Diseño Análisis de origen de causa: Siempre que se encuentre un defecto, hay que eliminarlo junto a sus causas. Esto ayudará a que no vuelva a suceder. o Codificación de software y liberación Código y pruebas: Sólo el código y las pruebas son artefactos permanentes y deben ser preservados. Los otros documentos pueden ser generados con base a estos dos artefactos. Código compartido: Cualquiera en el equipo de desarrollo debe ser capaz de cambiar cualquier parte del sistema. Código base único: Esto es solo una versión oficial del sistema. 23

25 Despliegue diario: Cada noche se debe poner software en producción. Es costoso tener brechas entre versiones de software lanzadas y las de producción personal de los desarrolladores Kanban Este no es un método para el desarrollo de software, sino para la gestión de proyectos; y aunque poco a poco se ha ido adaptando a los proyectos referentes al software (gracias a David J. Anderson quien adaptó el método original al desarrollo de software [17], y a Microsoft quien lo usó por primera vez), fue pensado inicialmente para ayudar en los procesos de producción de Toyota, usando técnicas JIT (Just-In-Time). Esta metodología de gestión, tiene como base fundamental los principios Lean, y presenta su practicidad en el uso de tarjetas para modelar actividades. Precisamente por esto el nombre de Kanban, ya que es una palabra del japonés, que etimológicamente hablando traduce Kan visual y ban tarjeta. Estas tarjetas se usan comúnmente para identificar necesidades de material en la cadena de producción. [18] [19] Kanban sugiere sistemas de producción altamente efectivos, regidos por algunos principios que reflejan que su origen viene de Lean y que dependiendo el autor, pueden variar, pero aun así, mantienen la esencia. Los principios Kanban son [19]: Calidad garantizada: todo se debe hacer lo mejor posible desde el comienzo, y no debe esperarse a que haya problemas para solucionarlos. En Kanban no hay margen de error, y es preferible demorarse un poco más realizando las actividades y asegurar así que estas son de calidad, a tener que retrasar el proyecto por problemas generados al no hacer las cosas bien. Reducción de desperdicio: este principio propone que no hay que desgastarse haciendo cosas que generan poco o nada de valor para el proyecto. Sólo se debe trabajar en las cosas que sean necesarias para asegurar que se hagan bien y con el tiempo necesario. Mejora continua: todo el proyecto es un continuo aprendizaje. Kanban es un sistema de mejora y permite la aplicación de los conocimientos adquiridos durante el proyecto. Esto con el fin de mejorar dinámicamente el desarrollo del mismo. Flexibilidad: al igual que metodologías como Scrum, Kanban posee un Backlog donde se encuentran los ítems a desarrollar, sin embargo, Kanban no se limita al trabajo por Sprints, ya que su naturaleza consiste en el trabajo continuo. En este caso el Backlog no es gestionado por los Sprints, ya que las actividades y tareas se van priorizando de acuerdo a la necesidad. 24

26 Ilustración 5. Tablero Kanban. (Tomado de [19]) Algo fundamental en este método es el uso de un tablero de tareas para mejorar el flujo de trabajo durante el proyecto. Algunos autores proponen diferentes formas o pasos para acomodar la estrategia a ser usada con el tablero, y que más se acomode al proyecto. Algunos de estos pasos consisten [19]: 1. Definir el flujo de trabajo del proyecto. a. Crear un tablero visible por todos los miembros del equipo. b. Cada columna del tablero consiste en un estado concreto del flujo de tareas. c. Deben existir tantas columnas como estados tenga que pasar una actividad. d. Las actividades se gestionan de manera continua y no por Sprints. e. Las nuevas tareas son acumuladas en la sección inicial y priorizadas luego por el cliente. 2. Visualizar las fases del ciclo de producción. a. Principio de desarrollo incremental. b. Cada tarea es una serie de pasos para agilizar el proceso de producción. c. Cada paso se puede representar con un post-it. d. Cada post-it es colocado en la fase que corresponde de acuerdo a su estado. e. Cada post-it contiene información básica del paso: descripción + estimación de duración. f. Pueden ser usados más elementos en el tablero para detallar mejor cada actividad. g. La idea es clarificar al máximo el trabajo a realizar, las tareas asignadas, la priorización y la meta asignada. 3. Stop starting, start finish. a. Se prioriza el trabajo que está en curso en vez de comenzar tareas nuevas. b. El trabajo en curso debe estar limitado, por lo que existe un número máximo de tareas a realizar en cada fase. c. No se puede abrir una nueva tarea sin finalizar otra. 4. Control de flujo. a. No se aplica a un solo proyecto, sino que mezcla tareas y proyectos. b. Flujo de trabajo constante. c. Tareas importantes en cola y seguimiento pasivo para no interrumpir el trabajo. En la actualidad este sistema de producción altamente eficiente y efectivo, se ha venido implementando para la gestión de proyectos de desarrollo de software, teniendo principal afinidad con las metodologías ágiles. Como se mencionó anteriormente, este permite gestionar de una manera general la forma en la que se van completando las tareas, de una manera visual, permitiendo facilidades a la hora de establecer el estado del proyecto. Adicionalmente es de fácil 25

27 utilización, actualización y apropiación por parte del equipo, por lo que se convierte en una excelente herramienta para complementar la metodología de desarrollo seleccionada. 26

28 4. SEMAT (Software Engineering Method And Theory) Es una iniciativa tomada por Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence y Svante Lidman que busca redefinir la Ingeniería de Software por medio de lo que los autores consideran como La esencia de la Ingeniería de Software: El núcleo de SEMAT. [20] SEMAT busca dicha redefinición basándose en una teoría sólida, principios probados y las mejores prácticas aplicables a los proyectos de software, de manera que [21]: Se incluya un núcleo (Kernel) de elementos ampliamente aceptados y que se puedan extender a usos específicos. Traten asuntos tecnológicos y humanos. Los apoyen la industria, la academia, los investigadores y los usuarios. Apoyen la extensión ante los requisitos cambiantes y la tecnología. SEMAT se enfoca fundamentalmente en dos objetivos principales, y que son independientes el uno del otro [21]: Encontrar un Kernel de elementos ampliamente aceptados. Definición de una base teórica sólida. Para definir el Kernel, lo principal fue identificar un terreno común que de alguna u otra forma definiera a la Ingeniería de Software. Una vez identificado ese terreno, se determinó un conjunto de elementos esenciales que son universales a todos los esfuerzos de desarrollo de software y un lenguaje sencillo para describir métodos y prácticas. Luego de definidos los elementos esenciales, estos fueron clasificados en 2 grandes grupos, algunos, dentro de las cosas con las que siempre trabajamos cuando se desarrollan sistemas de software (Ver Ilustración 6), y los demás dentro de las cosas que siempre hacemos en dichos proyectos (Ver Ilustración 7). Estos dos grupos (y más en específico, los elementos al interior de cada uno) son lo que se conoce en SEMAT como la esencia del Kernel. [21] Ilustración 6. "Cosas con las que siempre trabajamos". (Tomado de [22]) 27

29 Ilustración 7. "Cosas que siempre hacemos". (Tomado de [22]) Una vez especificado el Kernel de SEMAT, este presenta 3 características únicas (principios fundamentales). El Kernel es accionable, extensible y práctico. Estos principios serán profundizados más adelante en la Sección 4.2. [21] Teniendo en cuenta todo el proceso anteriormente descrito, y previamente identificados los principios del Kernel de SEMAT, se puede decir que dicho Kernel proporciona [21]: Un marco de pensamiento para que los equipos razonen sobre el progreso que están haciendo y la salud de sus esfuerzos. Un terreno común para la discusión, mejoramiento, comparación e intercambio de métodos y prácticas de ingeniería de software. Un marco para que los equipos ensamblen y mejoren continuamente su forma de trabajo, mediante la composición de prácticas definidas por separado y de diverso origen. Un fundamento para la definición de medidas que no dependan de las prácticas, para evaluar la calidad del software producido y los métodos que se usan para producirlo. Y lo más importante, una forma de ayudarle a los equipos a comprender dónde están, qué deberían hacer luego y dónde necesitan mejorar. De acuerdo a esto, el Kernel asegura que todos los aspectos esenciales de la Ingeniería de software serán considerados en los proyectos. Adicionalmente, teniendo en cuenta que se trata de mantener independiente a prácticas de metodologías en específico, y que apoya los valores del Manifiesto Ágil, el Kernel valora a los individuos e interacciones por encima de los procesos y las herramientas. [21] Así mismo, considera más importante las necesidades de los miembros de cada equipo, y los valores del uso de métodos, por encima de la descripción de las definiciones de los métodos, apoyado en las mejores prácticas modernas de la ingeniería de software y permitiendo hacer uso de la metodología que se desee. [21] 4.1. Los Alfas Son elementos fundamentales del Kernel y esenciales a la Ingeniería de Software. Estos, han sido considerados como conjuntos de estados, en vez de elementos de trabajo (como documentación o herramientas de software), ya que así representan el progreso y salud del proyecto, y a la Ingeniería de Software en general no a metodologías en específico. [21] 28

30 Han sido identificados 7 Alfas, los cuales, como se mencionó anteriormente, corresponden a las cosas con las que siempre trabajamos. Cada Alfa tiene estado una serie de Estados, quienes de igual manera se encuentran asociados una lista de chequeo que especifica los criterios necesarios para alcanzar todo el estado. [21] Alfa Oportunidad ayuda a dar forma a los requerimientos del nuevo sistema de software, proporcionando una justificación para su desarrollo [23]. Es la oportunidad que une a los Stakeholders y proporciona la motivación para producir una actualización o un nuevo sistema de software. Es entendiendo la oportunidad que se puede identificar el valor y resultado deseado que los Stakeholders esperan realizar del uso del sistema de software, ya sea solo como una parte de todo el negocio, o como una solución técnica. Los estados de este Alfa son [23]: Ilustración 8. Alfa - Oportunidad. (Tomado de [23]) El Alfa Oportunidad se refiere al conjunto de circunstancias que hace que cambiar o desarrollar un sistema de software sea apropiado. Representa el entendimiento de las necesidades que comparten los Stakeholders y Ilustración 9. Estados Alfa - Oportunidad. (Tomado de [23]) 29

31 Estado Identificado Estado Solución necesaria Ilustración 10. Alfa - Oportunidad; Estado - Identificado. (Tomado de [23]) Una oportunidad comercial, social o de negocio ha sido identificada y podría ser gestionada por una solución de software. La lista de chequeo para este estado es: Ha sido identificada alguna de las siguientes cosas: Una idea para mejorar la forma de trabajar o la cuota de mercado; la aplicación de un nuevo o innovador sistema de software. Al menos uno de los Stakeholders desea hacer una inversión en mejorar la comprensión de la oportunidad y el valor asociado que genera dirigirla. Han sido identificados los demás Stakeholders que comparten la oportunidad. Ilustración 11. Alfa - Oportunidad; Estado - Solución necesaria. (Tomado de [23]) Este estado se da cuando la necesidad de una solución de software ha sido identificada. La lista de chequeo para este estado es: Han sido identificados los Stakeholders en la oportunidad y la solución propuesta. Han sido establecidas las necesidades de los Stakeholders que generan la oportunidad. Ha sido identificado cualquier problema subyacente y la raíz de sus causas. Ha sido confirmado que es necesaria una solución basada en software. Ha sido propuesta por lo menos una solución de software. 30

32 Estado Valor establecido Estado Viable Ilustración 12. Alfa - Oportunidad; Estado - Valor establecido. (Tomado de [23]) Este estado se da cuando el valor de una solución exitosa ha sido establecido. La lista de chequeo para este estado es: El valor de abordar la oportunidad ha sido cuantificado en términos absolutos o de retornos o ahorros por periodo. Ilustración 13. Alfa - Oportunidad; Estado - Viable. (Tomado de [23]) Se acuerda que una solución puede ser producida de manera rápida y lo suficientemente económica como para abordar con éxito la oportunidad. La lista de chequeo para este estado es: Ha sido bosquejada una solución. Ha sido entendido por los Stakeholders el impacto de la solución. Ha sido entendido el uso del sistema de software y el valor que este ofrece a los Stakeholders que lo financian. La solución puede ser desarrollada y desplegada teniendo en cuenta las restricciones. El riesgo asociado a la solución es aceptable y manejable. Está claro el criterio de éxito por el cual el desarrollo del sistema será juzgado. El costo de la solución es menor que el valor anticipado de la oportunidad. Los resultados deseados y requeridos de la solución, están claros y cuantificados. Las razones para el desarrollo de una solución basada en software son entendidas por todos los miembros del equipo. Es claro que la persecución de la oportunidad es viable. 31

33 Estado Dirigido Estado Beneficio acumulado Ilustración 14. Alfa - Oportunidad; Estado - Dirigido. (Tomado de [23]) Este estado se logra una vez se demuestra que la solución aborda la oportunidad. La lista de chequeo para este estado es: Ilustración 15. Alfa - Oportunidad; Estado - Beneficio acumulado. (Tomado de [23]) Este estado se da una vez el uso operacional o venta de la solución, crea valor y beneficios tangibles. La lista de chequeo para este estado es: Un sistema usable que demuestre que aborda la oportunidad, está disponible. La solución ha comenzado a acumular beneficios para los Stakeholders. Los Stakeholders acordaron que vale la pena desplegar la solución disponible. El perfil de rentabilidad de la inversión es al menos tan buena como lo esperado. Los Stakeholders están satisfechos con que la solución producida aborde a la oportunidad. 32

34 Alfa Stakeholders Ilustración 16. Alfa - Stakeholders. (Tomado de [23]) Los Stakeholders proporcionan la Oportunidad, y son la fuente de los requerimientos. Ellos están involucrados a lo largo del proceso de Ingeniería de Software con el fin de apoyar al equipo y asegurar la aceptación del sistema de software. [23] Ilustración 17. Estados Alfa - Stakeholders. (Tomado de [23]) Los Stakeholders son fundamentales para el éxito del sistema y del trabajo realizado para producirlo. Sus comentarios y aportes en general, ayudan a dar forma a todo el sistema y al software resultante. Los estados de este Alfa son [23]: 33

35 Estado Reconocido Estado Representado Ilustración 18. Alfa - Stakeholders; Estado - Reconocido. (Tomado de [23]) Este estado se produce una vez los Stakeholders han sido identificados. La lista de chequeo para este estado es: Se han identificado todos los grupos de Stakeholders que son o se verán afectados por el desarrollo y futura operación del sistema. Existen acuerdos entre los grupos de Stakeholders a ser representados. Estos deberían por lo menos financiar, usar, apoyar, y mantener el sistema. Ilustración 19. Alfa - Stakeholders; Estado - Representado. (Tomado de [23]) Los representantes de los Stakeholders han sido nombrados y se han acordado mecanismos para involucrar a los Stakeholders. La lista de chequeo para este estado es: Los representantes de los Stakeholders han acordado asumir sus responsabilidades. Los representantes de los Stakeholders están autorizados para llevar a cabo sus responsabilidades. Se han definido las responsabilidades de los representantes de los Stakeholders. Se ha acordado colaboración entre los representantes de los Stakeholders. Los representantes de los Stakeholders apoyan y respetan la forma de trabajar del equipo. 34

36 Estado Involucrado Estado De acuerdo Ilustración 20. Alfa - Stakeholders; Estado - Involucrado. (Tomado de [23]) Los representantes de los Stakeholders están activamente involucrados en el trabajo y cumplimiento de sus responsabilidades. La lista de chequeo para este estado es: Los representantes de los Stakeholders ayudan al equipo de acuerdo a sus responsabilidades. Ilustración 21. Alfa - Stakeholders; Estado - De acuerdo. (Tomado de [23]) Este estado se presenta cuando los representantes de los Stakeholders se encuentran de acuerdo. La lista de chequeo para este estado es: Los representantes de los Stakeholders están de acuerdo sobre las expectativas mínimas para el siguiente desarrollo del nuevo sistema de software. Los representantes de los Stakeholders proporcionan retroalimentación y toman parte de las decisiones de manera oportuna. Los representantes de los Stakeholders comunican de manera oportuna los cambios que serán relevantes para sus grupos de Stakeholders. Los representantes de los Stakeholders están contentos con su participación en el trabajo. Los representantes de los Stakeholders están de acuerdo con que sus aportes son valorados por el equipo y son tratados con respeto. 35

37 Los miembros del equipo están de acuerdo con que sus aportes son valorados por los representantes de los Stakeholders y son tratados con respeto. Los representantes de los Stakeholders proporcionan retroalimentación al sistema desde la perspectiva de su grupo de Stakeholders. Los representantes de los Stakeholders están de acuerdo con la forma en que sus diferentes prioridades y perspectivas están siendo balanceadas para proporcionar una clara dirección del equipo. Los representantes de los Stakeholders están de acuerdo con que el sistema está listo para ser desplegado Estado Satisfecho en uso Estado Satisfecho por el despliegue Ilustración 23. Alfa - Stakeholders; Estado - Satisfecho en uso. (Tomado de [23]) Este estado se da una vez el sistema ha reunido o excede las expectativas mínimas de los Stakeholders. La lista de chequeo para este estado es: Ilustración 22. Alfa - Stakeholders; Estado - Satisfecho por el despliegue. (Tomado de [23]) Las expectativas mínimas de los Stakeholders han sido logradas. La lista de chequeo para este estado es: Los Stakeholders están usando el nuevo sistema, y proporcionan retroalimentación de su experiencia. Los Stakeholders confirman que el nuevo sistema cumple con sus expectativas. 36

38 Alfa Requerimientos Los requerimientos son capturados como un conjunto de ítems. Estos pueden ser comunicados y almacenados de varias formas y con distintos niveles de detalle. Así como es importante que los requerimientos totales sean entendidos, es necesario que los ítems acá usados de manera individual también lo sean. Entre otras cosas esto ayudaría a determinar cuándo un sistema ya está terminado, e inclusive a determinar si un requerimiento está dentro del alcance. Los estados de este Alfa son [23]: Ilustración 24. Alfa Requerimientos Este Alfa se refiere a lo que debería hacer el software para dirigir la oportunidad y satisfacer las necesidades de los Stakeholders. [23] Es importante descubrir qué se necesita del sistema de software, compartir esto con los Stakeholders y los miembros del equipo, y usarlo para manejar el desarrollo y pruebas del nuevo sistema. [23] Ilustración 25. Estados Alfa Requerimientos. (Tomado de [23]) 37

39 Estado Concebido Estado Delimitado Ilustración 26. Alfa - Requerimientos; Estado - Concebido. (Tomado de [23]) Este estado se da una vez las necesidades del nuevo sistema de software han sido acordadas. La lista de chequeo para este estado es: Ilustración 27. Alfa - Requerimientos; Estado - Delimitado. (Tomado de [23]) El tema y propósito del nuevo sistema está claro. La lista de cheque para este estado es: El conjunto inicial de Stakeholders está de acuerdo que un nuevo sistema de software será producido. Se han identificado los Stakeholders involucrados en el desarrollo del nuevo sistema. Se han identificado los Stakeholders que usarán el sistema. Se han identificado los Stakeholders que financiarán el trabajo inicial en el sistema. Los Stakeholders están de acuerdo con el propósito del nuevo sistema. Está claro cuál será el éxito para el nuevo sistema. Hay una clara oportunidad de dirigir al nuevo sistema. Los Stakeholders tienen un entendimiento compartido del alcance de la solución propuesta. Se ha acordado la forma en que los requerimientos serán descritos. 38

40 Los mecanismos para la gestión de requerimientos están en su lugar. Está claro el esquema de priorización. Se han identificado y considerado las restricciones. Las suposiciones se han escrito claramente. El origen de los requerimientos es claro. La razón de ser de los requerimientos es clara. Los requerimientos conflictivos son identificados y atendidos. Los requerimientos comunican las características esenciales del sistema a ser liberado Estado Coherente Los escenarios de uso más importantes para el sistema pueden ser explicados. La prioridad de los requerimientos es clara. Es comprendido el impacto de implementar los requerimientos. El equipo comprende lo que será liberado, y está de acuerdo con liberarlo. Ilustración 28. Alfa - Requerimientos; Estado - Coherente. (Tomado de [23]) Los requerimientos proporcionan una descripción consistente de las características esenciales del nuevo sistema. La lista de chequeo para este estado es: Los requerimientos son capturados y compartidos con el equipo y los Stakeholders. 39

41 Estado Aceptable Los requerimientos son estables Estado Direccionado Ilustración 29. Alfa - Requerimientos; Estado - Aceptable. (Tomado de [23]) Los requerimientos del sistema describen un sistema que es aceptable por los Stakeholders. La lista de chequeo para este estado es: Los Stakeholders aceptan que los requerimientos describen una solución aceptable. La tasa de cambio de los requerimientos acordados es relativamente baja y se encuentra bajo control. El valor proporcionado por la implementación de los requerimientos es claro. Las partes de la oportunidad que son satisfechas por los requerimientos están claras. Ilustración 30. Alfa - Requerimientos; Estado - Direccionado. (Tomado de [23]) Suficientes requerimientos han tratado de satisfacer las necesidades del nuevo sistema, con el fin de que este sea aceptado por los Stakeholders. La lista de chequeo para este estado es: Suficientes requerimientos han abordado para dar como resultado un sistema aceptable a los Stakeholders. Los Stakeholders aceptan los requerimientos que reflejan exactamente lo que hace y no hace el sistema. El conjunto de requerimientos que han sido implementados proporcionan un valor claro a los Stakeholders. 40

42 El sistema de implementación de los requerimientos es aceptado por los Stakeholders como digno de hacerlo operativo Estado Cumplido Ilustración 31. Alfa - Requerimientos; Estado - Cumplido. (Tomado de [23]) Los requerimientos que han sido abordados satisfacen completamente las necesidades del nuevo sistema. La lista de chequeo para este estado es: Los Stakeholders aceptan los requerimientos más precisos y que cumplan exactamente con las necesidades del nuevo sistema. No hay elementos pendientes que no permitan al sistema ser aceptado. El sistema es aceptado por los Stakeholders ya que satisface completamente los requerimientos 41

43 Alfa - Sistema de Software Ilustración 32. Alfa - Sistema de software. (Tomado de [23]) Un sistema de software se diferencia de otros sistemas ya que a pesar de estar compuesto por una combinación de software, hardware y datos con el fin de cumplir a cabalidad con los requerimientos, este proporciona valor principalmente por medio de la ejecución de software. Dicho sistema puede ser parte de otro software, hardware, negocio o solución social más grande que la que este pretende abarcar. Los estados de este Alfa son [23]: Ilustración 33. Estados Alfa - Sistema de software. (Tomado de [23]) 42

44 Estado Arquitectura seleccionada Se han comprado, construido y reusado decisiones Estado Demostrable Ilustración 34. Alfa - Sistema de software; Estado - Arquitectura seleccionada. (Tomado de [23]) Una arquitectura ha sido seleccionada para abordar el riesgo técnico clave y cualquier restricción técnica aplicable. La lista de chequeo para este estado es: Los criterios a ser usados a la hora de seleccionar la arquitectura, han sido acordados. Las plataformas de hardware han sido identificadas. Los lenguajes de programación y tecnologías a ser usadas han sido seleccionados. Los límites del sistema son conocidos. Se han efectuado las decisiones significantes sobre la organización del sistema. Ilustración 35. Alfa - Sistema de software; Estado - Demostrable. (Tomado de [23]) Una versión ejecutable del sistema está disponible para demostrar si la arquitectura del sistema es apta para el propósito y apoya las pruebas. La lista de chequeo para este estado es: Se han demostrado las características claves de la arquitectura. El sistema puede ser ejecutado y su rendimiento medido. Se han demostrado configuraciones críticas de hardware. Se han demostrado interfaces críticas. Se ha demostrado integración con otros sistemas existentes. 43

45 Los representantes de los Stakeholders están de acuerdo con que la arquitectura demostrada es apropiada. El valor agregado propuesto por el sistema es claro Estado Usable Estado Listo Ilustración 36. Alfa - Sistema de software; Estado - Usable. (Tomado de [23]) El sistema es usable y muestra todas las características de calidad de un sistema operacional. La lista de chequeo para este estado es: El sistema puede ser operado por los Stakeholders que lo usarán. Ha sido probada la funcionalidad proporcionada por el sistema. El rendimiento del sistema es aceptable para los Stakeholders. Los niveles de defectos son aceptables para los Stakeholders. Ilustración 37. Alfa - Sistema de software; Estado - Listo. (Tomado de [23]) El sistema total ha sido aceptado para desplegarse en un entorno real. La lista de chequeo para este estado es: Está disponible la instalación y otra documentación de usuario. Los representantes de los Stakeholders aceptan el sistema como apto para su propósito. Los representantes de los Stakeholders quieren hacer al sistema operacional. El sistema está completamente documentado. El apoyo operativo está en su lugar. Se conoce el contenido de la liberación. 44

46 Estado Operacional Estado Retirado Ilustración 38. Alfa - Sistema de software; Estado - Operacional. (Tomado de [23]) El sistema es usado en un ambiente operacional. La lista de chequeo para este estado es: Ilustración 39. Alfa - Sistema de software; Estado - Retirado. (Tomado de [23]) El sistema no va a tener soporte por más tiempo. La lista de chequeo para este estado es: El sistema realizado permite a los Stakeholders usarlo. El sistema ha sido reemplazado o descontinuado. Al menos un ejemplar del sistema es completamente operacional. El sistema ya no va a ser soportado. El sistema es completamente soportado de acuerdo a los niveles de servicio acordados. No hay Stakeholders oficiales que aún usen el sistema. No se producirán más actualizaciones del sistema. 45

47 Alfa Equipo competencias y habilidades. Para tener un alto rendimiento, los equipos no solo deben trabajar bien en equipo, sino potenciar este trabajo cooperativo junto a metas bien definidas y entendidas. [23] A pesar de que un equipo está compuesto por varias personas, cada una de las cuales con habilidades distintas, la guía que proporcionan los Alfas sólo debe ser usada por una persona (líder), con el fin de evitar ambigüedades. Los estados de este Alfa son [23]: Ilustración 40. Alfa - Equipo. (Tomado de [23]) El equipo corresponde a un grupo de personas que se encuentran activamente comprometidas al interior del proyecto. Esto quiere decir, durante el desarrollo, mantenimiento, entrega o soporte del sistema de software. [23] El proyecto puede estar constituido por uno o más equipos encargados de planear y ejecutar el trabajo necesario para crear, actualizar y/o cambiar el sistema de software. [23] En la Ingeniería de Software, los equipos deben ser como en los de deportes, donde se involucra la aplicación colaborativa de diferentes Ilustración 41. Estados Alfa - Equipo. (Tomado de [23]) 46

48 Estado - Cultivado Se han identificado las competencias requeridas. Se ha determinado el tamaño del equipo. Se han definido las reglas de juego. Se ha seleccionado un modelo de liderazgo. Ilustración 42. Alfa - Equipo; Estado - Seeded. (Tomado de [23]) La misión del equipo es clara, así como el saber hacer necesario para cultivar al equipo. La lista de chequeo para este estado es: La misión del equipo ha sido definida en términos de oportunidades y resultados. Se conocen las restricciones de operación del equipo. Se han implementado mecanismos para el crecimiento del equipo. Se ha definido la composición del equipo. Se han definido las restricciones del dónde y cómo trabajar. Se han explicado las responsabilidades del equipo. El nivel de compromiso del equipo es claro. 47

49 Estado Formado Se han identificado colaboradores externos (organizaciones, equipos o personas). Se han definido mecanismos de comunicación entre el equipo. Cada miembro del equipo se compromete a trabajar como se definió Estado Colaborando Ilustración 43. Alfa - Equipo; Estado - Formado. (Tomado de [23]) El equipo ya tiene suficientes personas como para comenzar la misión. La lista de chequeo para este estado es: Se han entendido las responsabilidades individuales. Se han reclutado suficientes personas como para permitir el progreso del trabajo. Todos los miembros del equipo comprenden cómo realizar su trabajo. Todos los miembros se han reunido, y comienzan a conocerse. Los miembros del equipo comprenden sus responsabilidades y cómo estas se alinean con sus responsabilidades. Los miembros del equipo aceptan su trabajo. Ilustración 44. Alfa - Equipo; Estado - Colaborando. (Tomado de [23]) Los miembros del equipo se encuentran trabajando juntos como una unidad. La lista de chequeo para este estado es: El equipo trabaja como unidad cohesiva. La comunicación entre el equipo es abierta y honesta. El equipo está empeñado en cumplir con el objetivo. 48

50 Los miembros del equipo se conocen entre sí Estado Suspendido Estado Ejecutando Ilustración 46. Alfa - Equipo; Estado - Suspendido. (Tomado de [23]) Ilustración 45. Alfa - Equipo; Estado - Ejecutando. (Tomado de [23]) El equipo se encuentra trabajando de manera efectiva y eficiente. La lista de chequeo para este estado es: El equipo cumple consistentemente sus compromisos. El equipo se adapta continuamente al contexto cambiante. El equipo identifica y aborda los problemas sin ayuda externa. El equipo ya no es responsable de llevar a cabo su misión. La lista de chequeo para este estado es: Las responsabilidades del equipo han sido manejadas o cumplidas. Los miembros del equipo están disponibles para ser asignados a otros equipos. No se están haciendo ningún esfuerzo por el equipo para completar la misión. Se está logrando un progreso efectivo, evitando al mínimo volver a realizar trabajo ya hecho. El trabajo desaprovechado y el potencial trabajo desaprovechado es continuamente eliminado. 49

51 Alfa Trabajo La habilidad de los miembros para coordinar, organizar, estimar, completar y compartir su trabajo, tiene un profundo efecto en el cumplimiento de los compromisos y entrega de valor a los Stakeholders. Los miembros del equipo deben entender cómo llevar a cabo su trabajo, y cómo reconocer cuándo el trabajo está bien hecho. Los estados de este Alfa son [23]: Ilustración 47. Alfa - Trabajo. (Tomado de [23]) Cuando se habla de trabajo, no sólo se deben considerar las actividades que impliquen esfuerzo físico. Dentro de esta definición también se debe incluir el esfuerzo mental, ya que el objetivo del trabajo siempre va a ser generar un resultado. Más aun, se podría definir el trabajo en este contexto como, cualquier cosa que se tenga que realizar por parte del equipo, para cumplir con los objetivos de producir un sistema de software, que cumpla con los requerimientos y que esté enfocada hacia la oportunidad presentada por los Stakeholders. [23] Ilustración 48. Estado Alfa - Trabajo. (Tomado de [23]) 50

52 Estado Iniciado Estado Preparado Ilustración 49. Alfa - Trabajo; Estado - Iniciado. (Tomado de [23]) Este estado se da una vez el trabajo ha sido solicitado. La lista de chequeo para este estado es: Ilustración 50. Alfa - Trabajo; Estado - Preparado. (Tomado de [23]) Todas las precondiciones para iniciar el trabajo han sido cumplidas. La lista de chequeo para este estado es: El resultado requerido del trabajo iniciado está claro. Hay compromiso. Se ha identificado claramente cualquier restricción de rendimiento para el trabajo. Se conoce a los Stakeholders que financiarán el trabajo. Se ha identificado claramente al iniciador del trabajo. Se conoce a los Stakeholders que aceptarán los resultados. Son claros los recursos del financiamiento. Se han estimado los costos y esfuerzo del trabajo. Se ha comprendido la disponibilidad de recursos. Las políticas y procedimientos están claras. Se ha comprendido la exposición al riesgo. Se han definido y acordado con el cliente los criterios de aceptación. Es clara la prioridad del trabajo. El trabajo se ha desglosado lo suficiente como para comenzar a trabajar. 51

53 Las tareas han sido identificadas y priorizadas por el equipo y los Stakeholders. Se lleva a cabo un plan creíble. Se ha financiado para comenzar a trabajar. El equipo o algunos de los miembros están listos para comenzar a trabajar. Se han definido los puntos de integración y liberación Estado Comenzado Ilustración 51. Alfa - Trabajo; Estado - Comenzado. (Tomado de [23]) Este estado se da una vez se proceda con el trabajo. La lista de chequeo para este estado es: El trabajo de desarrollo ha sido comenzado. El progreso del trabajo es monitoreado. El trabajo está siendo desglosado en ítems de trabajo accionables con claras definiciones de hacerlo. Los miembros del equipo están aceptando y progresando en las tareas. 52

54 Estado Bajo control Las repeticiones de trabajo están bajo control. Las tareas son consistentemente completadas a tiempo y dentro de los estimados Estado Culminado Ilustración 52. Alfa - Trabajo; Estado - Bajo control. (Tomado de [23]) El trabajo va bien, el riesgo está bajo control y los niveles de productividad son suficientes para lograr un resultado satisfactorio. La lista de chequeo para este estado es: Las tareas están siendo completadas. El trabajo no planificado está bajo control. Los riesgos están bajo control así como el impacto de que ellos ocurran, y la probabilidad de que esto suceda ha sido reducida a niveles aceptables. Las estimaciones son revisadas para reflejar el rendimiento del equipo. Las métricas están disponibles para mostrar el progreso y velocidad. Ilustración 53. Alfa - Trabajo; Estado - Culminado. (Tomado de [23]) El trabajo para producir resultados ha sido finalizado. La lista de chequeo para este estado es: Todas las tareas pendientes son de mantenimiento administrativo, o relacionadas a la preparación de la siguiente pieza de trabajo. Los resultados del trabajo han sido logrados. Los Stakeholders aceptaron el sistema de software resultante. 53

55 Estado Cerrado Ilustración 54. Alfa Trabajo; Estado Cerrado. (Tomado de [23]) Todas las tareas de mantenimiento restantes han sido completadas y el trabajo es oficialmente cerrado. La lista de chequeo para este estado es: Las lecciones aprendidas han sido detalladas, registradas y discutidas. Se han puesto a disposición las métricas. Todo ha sido archivado. El presupuesto ha sido conciliado y cerrado. El equipo ha sido liberado. No hay tareas pendientes ni incompletas. 54

56 Alfa - Forma de trabajar implica cualquier proceso de Ingeniería de Software. Los estados de este Alfa son [23]: Ilustración 55. Alfa - Forma de trabajar. (Tomado de [23]) La forma de trabajar se puede ver como el conjunto de prácticas y herramientas usadas por un equipo para guiar y soportar su trabajo. [23] El equipo evoluciona su forma de trabajar a medida que entiende mejor su misión y su ambiente de trabajo. Esta forma de trabajo es adaptativa y va cambiando de acuerdo al contexto. [23] Ilustración 56. Estados Alfa - Forma de trabajar. (Tomado de [23]) El equipo debe entender que es un equipo, y que esto implica trabajo colaborativo, para lo que es necesario que entre los mismos miembros se hagan acuerdos de cooperación que los guíen durante el esfuerzo que 55

57 Estado Principios establecidos Estado Bases establecidas Ilustración 57. Alfa Forma de trabajar; Estado Principios. (Tomado de [23]) Los principios y restricciones que dan forma a la manera de trabajar, son establecidos. La lista de chequeo para este estado es: Los principios y restricciones son pactados por el equipo. Los principios y restricciones son acordados por los Stakeholders. Se acordaron las necesidades de herramientas de trabajo y sus Stakeholders. Una recomendación para el enfoque a seguir está disponible. Es entendido el contexto dentro del cual el equipo operará. Son conocidas las restricciones que se aplican a la selección, adquisición y uso de prácticas y herramientas. Ilustración 58. Alfa Forma de trabajar; Estado Bases establecidas. (Tomado de [23]) Las prácticas clave y herramientas que originan las bases de la forma de trabajar, son seleccionadas y están listas para su uso. La lista de chequeo para este estado es: Son seleccionadas las prácticas clave y herramientas que formarán las bases de la forma de trabajar. Han sido acordadas por el equipo suficientes prácticas para comenzar a trabajar. Han sido identificadas todas las prácticas y herramientas no negociables. Han sido analizada y entendida la brecha que existe entre las prácticas y herramientas que son necesarias y las prácticas y herramientas que están disponibles. 56