PSP y TSP

PSP y TSP

PATRON MVC

Modelo Vista Controlador

Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes distintos. El patrón de llamada y retorno MVC (según CMU), se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista. 

Descripción 

• Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.
• Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.
• Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.

Muchos de los sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos: en líneas generales del MVC corresponde al modelo. La unión entre capa de presentación y capa de negocio conocido en el paradigma de la Programación por capas representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio y capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí.

Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente:

1. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.)
2. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.
3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se reflejan los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. Este uso del patrón Observador no es posible en las aplicaciones Web puesto que las clases de la vista están desconectadas del modelo y del controlador. En general el controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista. Por ejemplo en el MVC usado por Apple en su framework Cocoa. Suele citarse como Modelo-Interface-Control, una variación del MVC más puro
5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

 

Patrones

Patrones 




Patrón: Es aquel que describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de la solución a ese problema, de forma tal que esa solución puede ser usada un millón de veces, sin hacerlo de la misma manera dos veces.

       Patrones de  Diseño: Son aquellos que representan soluciones a problemas que surgen cuando se desarrolla software en un contexto particular.  Estos, facilitan la reutilización de arquitecturas y diseños de software exitoso. 

         

        Patrones Gof: 

• Creacionales: tratan con las formas de crear instancias de objetos. El objetivo de estos patrones es de abstraer el proceso de instanciación y ocultar los detalles de cómo los objetos son creados o inicializados.
  • Object Pool (Conjunto de Objetos): Se obtienen objetos nuevos a través de la clonación. Utilizado cuando el costo de crear una clase es mayor que el de clonarla. Especialmente con objetos muy complejos. Se especifica un tipo de objeto a crear y se utiliza una interfaz del prototipo para crear un nuevo objeto por clonación. El proceso de clonación se inicia instanciando un tipo de objeto de la clase que queremos clonar.
  • Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando.
  • Builder (Constructor virtual): Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto.
  • Factory Method (Método de fabricación): Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para elegir el subtipo que crear.
  • Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya existente.
  • Singleton (Instancia única): Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia.
• Estructurales: Los patrones estructurales describen como las clases y objetos pueden ser combinados para formar grandes estructuras y proporcionar nuevas funcionalidades. Estos objetos adicionados pueden ser incluso objetos simples u objetos compuestos.
  • Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla.
  • Bridge (Puente): Desacopla una abstracción de su implementación.
  • Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase.
  • Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.
  • Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.
  • Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.
  • Proxy: Mantiene un representante de un objeto.
• Comportamiento: Los patrones de comportamiento ayudan a definir la comunicación e iteración entre los objetos de un sistema. El propósito de este patrón es reducir el acoplamiento entre los objetos.
• Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
• Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
• Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo.
• Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos.
• Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.
• Memento (Recuerdo): Permite volver a estados anteriores del sistema.
• Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él.
• State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.
• Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.
• Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.
• Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.

Patrones Grasp: son patrones generales de software para asignación de responsabilidades, es el acrónimo de "General Responsibility Assignment Software Patterns" . Aunque se considera que más que patrones propiamente dichos, son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software.

Experto en Información: El GRASP de experto en información es el principio básico de asignación de responsabilidades. Nos indica, por ejemplo, que la responsabilidad de la creación de un objeto o la implementación de un método, debe recaer sobre la clase que conoce toda la información necesaria para crearlo. De este modo obtendremos un diseño con mayor cohesión y así la información se mantiene encapsulada (disminución del acoplamiento)

Problema: ¿Cuál es el principio general para asignar responsabilidades a los objetos?

Solución: Asignar una responsabilidad al experto en información.

Beneficios: Se mantiene el encapsulamiento, los objetos utilizan su propia información para llevar a cabo sus tareas. Se distribuye el comportamiento entre las clases que contienen la información requerida. Son más fáciles de entender y mantener.

Creador: El patrón creador nos ayuda a identificar quién debe ser el responsable de la creación (o instanciación) de nuevos objetos o clases.

La nueva instancia deberá ser creada por la clase que:

• Tiene la información necesaria para realizar la creación del objeto, o
• Usa directamente las instancias creadas del objeto, o
• Almacena o maneja varias instancias de la clase
• Contiene o agrega la clase.

Una de las consecuencias de usar este patron es la visibilidad entre la clase creada y la clase creador. Una ventaja es el bajo acoplamiento, lo cual supone facilidad de mantenimiento y reutilizacion La creación de instancias es una de las actividades más comunes en un sistema orientado a objetos. En consecuencia es útil contar con un principio general para la asignación de las responsabilidades de creación. Si se asignan bien el diseño puede soportar un bajo acoplamiento, mayor claridad, encapsulación y reutilización.

Controlador: El patrón controlador es un patrón que sirve como intermediario entre una determinada interfaz y el algoritmo que la implementa, de tal forma que es la que recibe los datos del usuario y la que los envía a las distintas clases según el método llamado.

Este patrón sugiere que la lógica de negocios debe estar separada de la capa de presentación, esto para aumentar la reutilización de código y a la vez tener un mayor control.

Se recomienda dividir los eventos del sistema en el mayor número de controladores para poder aumentar la cohesión y disminuir el acoplamiento.

Alta Cohesion y Bajo Acoplamiento: Los conceptos de cohesión y acoplamiento no están íntimamente relacionados, sin embargo se recomienda tener un mayor grado de cohesión con un menor grado de acoplamiento. De esta forma se tiene menor dependencia y se especifican los propósitos de cada objeto en el sistema.

Alta cohesión

Nos dice que la información que almacena una clase debe de ser coherente y debe estar (en la medida de lo posible) relacionada con la clase.

1. Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relación entre ellas.

2. Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, pero, en tiempo de ejecución, sólo una de ellas será llevada a cabo.

3. Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, como única relación el deber ser ejecutadas “al mismo tiempo”.

4. Cohesión de Procedimiento: La única relación que guardan las tareas de un módulo es que corresponden a una secuencia de pasos propia del “producto”.

5. Cohesión de Comunicación: Las tareas corresponden a una secuencia de pasos propia del “producto” y todas afectan a los mismos datos.

6. Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen su propio punto de arranque, su codificación independiente y trabajan sobre los mismos datos. El ejemplo típico: OBJETOS

7. Cohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea, teniendo un único objetivo a cumplir, se dice que tiene Cohesividad Funcional.

Bajo acoplamiento

Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases

1. Acoplamiento de Contenido: Cuando un módulo referencia directamente el contenido de otro módulo. (En lenguajes de alto nivel es muy raro)

2. Acoplamiento Común: Cuando dos módulos acceden (y afectan) a un mismo valor global.

3. Acoplamiento de Control: Cuando un módulo le envía a otro un elemento de control que determina la lógica de ejecución del mismo.

cc  

Conceptos Basicos

Polimorfismo: En programación orientada a objetos el polimorfismo se refiere a la posibilidad de enviar un mensaje a un grupo de objetos cuya naturaleza puede ser heterogénea. El único requisito que deben cumplir los objetos que se utilizan de manera polimórfica es saber responder al mensaje que se les envía.

Encapsulamiento: se denomina encapsulamiento al ocultamiento del estado, es decir, de los datos miembro, de un objeto de manera que sólo se puede cambiar mediante las operaciones definidas para ese objeto.

Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados a un objeto contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.

Clase: es una construcción que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Un objeto de una determinada clase se denomina una instancia de la clase. La clase que contiene (y se utilizó para crear) esa instancia se puede considerar como del tipo de ese objeto, por ejemplo, una instancia del objeto de la clase "Persona" sería del tipo "Persona".

Objeto: se define como la unidad que en tiempo de ejecución realiza las tareas de un programa. También a un nivel más básico se define como la instancia de una clase.

Herramientas case: Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de software Asistida por computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras, que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).

Arquitectura de Software: Según clements la AS es una vista del  sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema.

Framework: La palabra inglesa "framework" define, en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular, que sirve como referencia para enfrentar y resolver nuevos problemas de índole similar.

En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, con base a la cual otro proyecto de software puede ser más fácilmente organizado y desarrollado. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto.

Metodología: se encarga de elaborar estrategias de desarrollo de software que promuevan prácticas adaptativas en vez de predictivas; centradas en las personas o los equipos, orientadas hacia la funcionalidad y la entrega, de comunicación intensiva y que requieren implicación directa del cliente.

Modelo:  El modelo de desarrollo de software se compone de una mezcla de varios elementos, entre los que se encuentran la filosofía, el modelo de negocio, y el licenciamiento. Ni la calidad ni el desempeño dependen del modelo. 

Scrum

El origen: Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de las observaciones sobre nuevas prácticas de producción, realizadas por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80. (ver Gestión Predictiva y Gestión Ágil: El Nuevo Escenario). Aunque las prácticas observadas por estos autores surgieron en empresas  de productos

tecnológicos, también se emplean en entornos que trabajan con requisitos inestables y  que requieren rapidez y flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de software. Jeff Sutherland aplicó los principios observados por Nonaka y Takeuchi  al desarrollo de software en 1993 en Easel Corporation (Empresa que  en los macro-juegos de compras y fusiones se 

integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto_ágil. 

Introducción al modelo: Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro, porque no se basa en el seguimiento de un plan, sino en la adaptación continua  a las circunstancias de la
evolución del proyecto.
Como método ágil:

• Es un modo de desarrollo adaptable, antes que predictivo.
•  Orientado a las personas, más que a los procesos.
•  Emplea el modelo de construcción incremental basado en iteraciones y revisiones.

Control de la evolución del proyecto

Scrum controla de forma empírica y adaptable la evolución del proyecto, a través de las siguientes prácticas de la gestión ágil: 

Revisión de las Iteraciones

Al finalizar cada iteración (sprint) se lleva a cabo una revisión con todas las personas implicadas en el proyecto. Es por tanto la duración del sprint, el periodo máximo que se tarda en reconducir una desviación en el proyecto o en las circunstancias del producto.

Desarrollo incremental

Las personas implicadas no trabajan con diseños o abstracciones. El desarrollo incremental implica que al final de cada iteración se dispone de una parte de producto operativa, que se puede inspeccionar y evaluar.

Desarrollo evolutivo

Los modelos de gestión ágil se emplean para trabajar en entornos de incertidumbre e inestabilidad de requisitos. Intentar predecir en las fases iniciales cómo será el resultado final, y sobre dicha predicción desarrollar el diseño y la arquitectura del producto no es realista, porque las circunstancias obligarán a remodelarlo muchas veces. ¿Para qué predecir los estados finales de la arquitectura o del diseño si van a estar cambiando? Scrum considera a la inestabilidad como una premisa, y se adoptan técnicas de trabajo para permitir la evolución sin degradar la calidad de la arquitectura que también evoluciona durante el desarrollo. Durante el desarrollo se genera el diseño y la arquitectura final de forma evolutiva. Scrum no los 

considera como productos que deban realizarse en la primera “fase” del proyecto.

(El desarrollo ágil no es un desarrollo en fases)

Auto-organización

En la ejecución de un proyecto son muchos los factores impredecibles en todas las áreas y niveles. La gestión predictiva confía la responsabilidad de su resolución al gestor de proyectos. En Scrum los equipos son auto-organizados (no auto-dirigidos), con margen de decisión suficiente para tomar las decisiones que consideren oportunas. 

Colaboración

Las prácticas y el entorno de trabajo ágiles facilitan la colaboración del equipo. Ésta es necesaria, porque para que funcione la auto-organización como un control eficaz cada miembro del equipo debe colaborar de forma abierta con los demás, según sus capacidades y no según su rol o su puesto.

Visión general del proceso

Scrum denomina “sprint” a cada iteración de desarrollo y según las características del proyecto y las circunstancias del sprint puede determinarse una duración desde una hasta dos meses, aunque no suele ser recomendable hacerlos de más de un mes.

El sprint es el núcleo central que proporciona la base de desarrollo iterativo e incremental.

Los elementos que conforman el desarrollo Scrum son:

Las reuniones:

Planificación del sprint: Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál va a ser el trabajo y los objetivos que se deben conseguir en la iteración.

Seguimiento del sprint: Breve revisión diaria, en la que cada miembro describe tres cuestiones:

1.- El trabajo que realizó el día anterior.

2.- El que tiene previsto realizar.

3.- Cosas que puede necesitar o impedimentos que deben suprimirse para realizar el trabajo. 

Cada persona actualiza en la pila del sprint el tiempo pendiente de sus tareas, y con esta información se actualiza también el gráfico con el que el equipo monitoriza el avance del sprint (burn-down).

 Revisión del sprint: Análisis y revisión del incremento generado.

Los elementos: 

Pila del producto: (product backlog) lista de requisitos de usuario que a partir de la visión inicial del producto crece y evoluciona durante el desarrollo.

Pila del sprint: (sprint backlog) lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto.

Incremento: Resultado de cada sprint.

Los roles

Todas las personas que intervienen, o tienen relación directa o indirecta con el proyecto, se clasifican en dos grupos:  comprometidos e implicados.

En círculos de Scrum es frecuente llamar a los primeros (sin ninguna connotación peyorativa) “cerdos” y a los segundos “gallinas”. El origen de estos nombres es esta metáfora que ilustra de forma gráfica la diferencia entre “compromiso” e “implicación” con el proyecto: Una gallina y un cerdo paseaban por la carretera. La gallina preguntó al cerdo: “¿Quieres abrir un restaurante conmigo?”.

El cerdo consideró la propuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”.

La gallina respondió: “Jamón con huevos”.El cerdo se detuvo, hizo una pausa y contestó: 

“Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente 

comprometido, mientras que tu estarías sólo implicada”.

•  Propietario del producto: es la persona responsable de lograr el mayor valor de  producto para los clientes, usuarios y resto de implicados.
•  Equipo de desarrollo: grupo o grupos de trabajo que desarrollan el producto.
•  Scrum Manager: Responsable del funcionamiento de la metodología Scrum en la organización.

Algunas implementaciones de modelo Scrum, consideran el rol de gestor de Scrum como “comprometido” y necesario (Scrum Master) Con el criterio de Scrum Management, es recomendable que las  responsabilidades que cubre este rol, estén identificadas en una única persona cuando se comienzan a aplicar prácticas de Scrum en una organización. En organizaciones ágiles maduras puede tener menos sentido. En cualquier caso, las responsabilidades de Scrum Manager no son del proyecto, sino del grupo de procesos y métodos de la organización, por lo que no debe considerarse ni cerdo ni gallina.

Valores

Scrum es una “carrocería” que dá forma a los principios ágiles. Es una ayuda para organizar a las personas y el flujo de trabajo; como lo pueden ser otras propuestas de formas de trabajo ágil: Crystal, DSDM, etc.

La carrocería sin motor, sin los valores que dan sentido al desarrollo ágil, no funciona:

•  Delegación de atribuciones (empowerment) al equipo para que pueda auto-organizarse y tomar las decisiones sobre el desarrollo.
•  Respeto entre las personas. Los miembros del equipo deben confiar entre ellos y respetar sus conocimientos y capacidades.
•  Responsabilidad y auto-disciplina (no disciplina impuesta).
•  Trabajo centrado en el desarrollo de lo comprometido
•  Información, transparencia y visibilidad del desarrollo del proyecto

Resumen

Scrum es un modelo ágil de desarrollo, que toma forma de las prácticas de trabajo, que a partir de los 80 comienzan a adoptar algunas empresas tecnológicas, y que Nonaka y Takeuchi acuñaron como "Campos de Scrum". El modelo Scrum, aplicado al desarrollo de software, emplea el principio ágil: "desarrollo 

iterativo e incremental", denominando sprint a cada iteración de desarrollo.

Las prácticas empleadas por Scrum para mantener un control ágil en el proyecto son:

•  Revisión de las iteraciones
• Desarrollo incremental
•  Desarrollo evolutivo
•  Auto-organización del equipo
•  Colaboración

Los artefactos del modelo son:

•  Elementos:
•  Pila del producto o product backlog
•  Pila del sprint o sprint backlog
•  Incremento
•  Roles:
•  Propietario del producto
•  Equipo
•  Scrum Manager
•  Otros interesados
•  Reuniones:
• Planificación del sprint
•  Seguimiento del sprint
•  Revisión del sprint

Los valores que hacen posible a las prácticas de Scrum crear "campos de Scrum" son:

•  Autonomía (empowerment) del equipo
•  Respeto en el equipo
•  Responsabilidad y auto-disciplina
•  Foco en la tarea
•  Información transparencia y visibilidad

Roles y responsabilidades de proyecto

Responsabilidades 

generales Scrum 

Management

De management

•  Equilibrio sistémico de la organización
• Coherencia del modelo
• Medios y formación

De procesos

• Configuración de Scrum
• Mejora continua
• Garantía de funcionamiento de Scrum en 
  cada proyecto

De producción

• Producto
•  Auto-organización
•  Tecnología ágil

El uso de prácticas y tecnologías ágiles, el trabajo 

en equipos auto-organizados, disponer de una 

visión de producto definida y gestionada durante 

todo el proyecto y garantizar el funcionamiento de 

scrum durante la ejecución, son responsabilidades directas del ámbito del proyecto.

Que las diferentes áreas de la empresa se 

encuentren comunicadas y alineadas con una 

visión común, coherente con un modelo de 

trabajo ágil, disponga de medios para el diseño e 

implantación de una implantación ágil adecuada a 

la  empresa, mejora continua del modelo y 

formación a las personas, son responsabilidades 

de la organización.

Responsabilidades y roles  "del proyecto"

Éstas son las directamente implicadas en el desarrollo del producto.  En las implantaciones rígidas de scrum se asignan a roles fijos denominados “cerdos” (directamente implicados en el proyecto):

• Responsabilidad de funcionamiento de Scrum => A un gestor específico para el funcionamiento de Scrum (Scrum Master)
• Responsabilidad de gestión del producto => a un  "propietario de producto", o product manager.
• Responsabilidad de auto-organización y uso de prácticas y tecnologías ágiles => al equipo.

Las del propietario del producto, relativas a la definición desde la visión, la priorización del trabajo y la financiación del proyecto. Las del equipo, relativas a la auto-organización y uso de prácticas tecnológicas ágiles. También pertenece al grupo de responsabilidades del proyecto: la garantía de ejecución y funcionamiento correcto de las prácticas Scrum en cada proyecto.

Lo más común en las fases de implantación, cuando los equipos no están familiarizados con el modelo, es la asignación de esta responsabilidad en una persona experta en Scrum, ajena al equipo: el gestor de Scrum, o Scrum Manager.

Desde la perspectiva de implantación de prácticas ágiles de Scrum Management, resulta más eficiente adaptar los principios ágiles a la realidad de cada organización, de forma que lo relevante no es importar roles fijos: Product Owner o Scrum Master, sino cubrir adecuadamente todas las responsabilidades.

Una asignación habitual de las responsabilidades de proyecto suele ser sobre los roles:

• Garantía de funcionamiento de Scrum => Calidad o procesos
•  Garantía de gestión de producto => Product manager
• Auto-organización y tecnología ágil = Equipo

La visión cerrada de Scrum establece:

• Garantía de funcionamiento de Scrum => rol específico: Scrum Master
• Garantía de gestión de producto => Product Owner
• Auto-organización => Equipo

Tanto si en la implantación de  agilidad en la organización, las responsabilidades necesarias se asignan a roles de la estructura de la empresa, o se crean nuevos roles (Product Owner o Scrum Master), lo relevante es que las personas que los desempeñan tengan la experiencia y conocimiento profesional necesario.

El propietario del producto

El propietario del producto o “product owner” es la persona que toma las decisiones del cliente. Normalmente atribuida a un rol de propietario de producto o product manager. Para simplificar la comunicación y toma de decisiones es necesario que las responsabilidades de gestión del producto las asuma una única persona.

Si se trata de organizaciones cliente grandes o con varios departamentos, éstas pueden tener la forma de comunicación interna que consideren oportuna, pero en el equipo de desarrollo sólo se integra una persona representando al cliente, y ésta debe tener el conocimiento suficiente del producto y las atribuciones necesarias para tomar las decisiones que le corresponden.

El equipo

Se recomienda un tamaño de equipo entre 4 y 8 personas.

Más allá de 8 resulta más difícil mantener la agilidad en la comunicación directa, y se manifiestan con más intensidad las rigideces habituales de la dinámica de grupos (que comienzan a aparecer a partir de 6 personas). No se trata de un grupo de trabajo formado por un arquitecto, diseñador o analista, programadores, pruebas… Es un equipo multidisciplinario, en el que todos trabajan de forma conjunta para realizar cada sprint.

Las principales responsabilidades, más allá de la auto-organización y uso de tecnologías ágiles, son las que se derivan de la diferencia entre “grupo de trabajo” y “equipo”.

Un grupo de trabajo es un conjunto de personas que realizan un trabajo, con una asignación específica de tareas, responsabilidades y siguiendo un proceso o pautas de ejecución. Los operarios de una cadena, forman un grupo de trabajo: aunque tienen un jefe común, y trabajan en la misma organización, cada uno responde por su trabajo.

El equipo tiene espíritu de colaboración, y un propósito común: conseguir el mayor valor posible para la visión del cliente. Un equipo Scrum responde en su conjunto. Trabajan de forma cohesionada y auto-organizada. No hay un gestor que delimita, asigna y coordina las tareas. Son los propios componentes del 

equipo los que lo realizan.

En el equipo:

•  Todos conocen y comprenden la visión del propietario del producto.
•  Aportan y colaboran con el propietario del producto en el desarrollo de la pila del producto.
•  Comparten de  forma conjunta el objetivo de cada sprint y la responsabilidad del logro.
•  Todos los miembros participan en las decisiones.
•  Se respetan las opiniones y aportaciones de todos
•  Todos conocen el modelo de trabajo con Scrum.

Hay un responsable o líder del equipo que asume las responsabilidades de garantía de funcionamiento del campo de Scrum en el proyecto. En las fases de implementación de Scrum, con equipos sin demasiada experiencia en desarrollo ágil con Scrum, y en organizaciones con demasiada rotación de  personas de los equipos entre proyectos, es recomendable la figura de un gestor de Scrum o Scrum Manager para asumir 

estas responsabilidades.

Scrum Manager – Team Leade

Es el responsable  del funcionamiento de Scrum en el proyecto, cubriendo los aspectos siguientes que la organización necesite según el conocimiento, experiencia con el modelo… o aquellos que no cubra con otras personas con la formación e idoneidad adecuada.

•  Asesoría y formación al Propietario del producto.
•  Asesoría y formación al equipo.

Revisión y validación de la pila del producto.

•  Moderación de las reuniones.
•  Resolución de impedimentos que en el sprint pueden entorpecer la ejecución de las tareas.
•  Gestión de la “dinámica de grupo” en el equipo
•  Respeto de la organización y los implicados, con las pautas de tiempos y formas de Scrum
•  Configuración, diseño y mejora continua de las prácticas de Scrum en la organización.

Lo más habitual es que la garantía de funcionamiento de Scrum en el proyecto se asigne:

• Al rol de un Team Leader, en equipos experimentados en trabajo ágil, en organizaciones que tienen ya una cierta experiencia con agilildad.
• A un puesto específico para contar con esta garantía (Gestor de Scrum o Scrum Master), en equipos y organizaciones en fases tempranas de implementación de Scrum, sin experiencia previa en desarrollo ágil.

Resumen

Las responsabilidades del funcionamiento de Scrum Management en la organización se clasifican en tres niveles y son las siguientes: 

De management

• Equilibrio sistémico de la organización
• Coherencia del modelo
• Medios y formación

De procesos

•  Configuración de Scrum
•  Mejora continua
•  Garantía de funcionamiento de Scrum en cada proyecto

De producción

•  Producto
•  Auto-organización
•  Tecnología ágil

El rol de propietario del producto tiene las responsabilidades de producto.

El equipo:

•  Auto - organización
•  El uso de tecnología y técnicas ágiles en el desarrollo del sistema
• Garantía de funcionamiento de Scrum en el proyecto, cuando no hay un Scrum Manager

El resto de las responsabilidades no son propias del proyecto, y por tanto propias del equipo; sino 

de la organización.

Los elementos de Scrum

Los elementos centrales del modelo de trabajo Scrum son: 

•  Pila del producto (Product Backlog): Lista de  funcionalidades que necesita el cliente.
•  Pila del sprint (Sprint Backlog): Lista de tareas que se realizan en un sprint
•  Incremento: Parte del sistema desarrollada en un sprint

Los requisitos en el desarrollo ágil

La ingeniería  del software clásica diferencia dos áreas de requisitos

•  Requisitos del sistema
• Requisitos del software

Los requisitos del sistema forman parte del proceso de adquisición (ISO 12207), y por tanto es responsabilidad del cliente la definición del problema y de las funcionalidades  que debe aportar la solución.

No importa si se trata de gestión tradicional o ágil. 

La descripción del sistema es responsabilidad del cliente, aunque se aborda de forma diferente en cada caso.

•  En los proyectos predictivos, los requisitos del sistema suelen especificarse en documentos formales; mientras que en los proyectos ágiles toman la forma de pila del producto o lista de  historias de usuario.
•  Los requisitos del sistema formales se especifican de forma completa y cerrada al inicio del proyecto; sin embargo una pila del producto es un documento vivo, que evoluciona durante el desarrollo.
•  Los requisitos del sistema los desarrolla una persona o equipo especializado en ingeniería de requisitos a  través del proceso de obtención  (elicitación) con el cliente. En Scrum la visión del cliente es conocida por todo el equipo (el cliente forma parte del equipo) y la pila del producto se realiza y evoluciona de forma continua con los aportes de todo el equipo.

Requisitos y visión del producto

Scrum, aplicado al software, emplea dos formatos para registrar los requisitos:

•  Pila del producto (Product Backlog)
•  Pila del sprint (Sprint Backlog)

La pila del producto se  sitúa en el área de necesidades de negocio desde el punto de vista del cliente.  Es el área que en la ingeniería del software tradicional, cubren los requisitos del sistema o ConOps (Concept of Operations).  

La pila del sprint cubre la  especificación de los requisitos de software necesarios para dar respuesta a las funcionalidades esperadas por el cliente.

Estas listas no tienen por qué cumplir con un determinado “formato scrum-estándar”. Pueden, y deben, adoptar la forma más adecuada al sistema equipo-proyecto.

Requisitos del Sistema (pila del producto):

•  Las funcionalidades que incluye dan forma a una visión del producto definida y conocida por todo el equipo.
•  Las funcionalidades están individualmente definidas, priorizadas y preestimadas.
•  Están realizados y gestionados por el cliente (propietario del producto)

Requisitos del software (pila del sprint):

•  Incluyen todas las tareas necesarias para construir el incremento de un sprint.
•  El equipo ha estimado el esfuerzo de cada tarea.
•  El equipo ha asignado cada tarea a un miembro.
•  Las duraciones estimadas de las tareas no son ni inferiores, ni superiores a los límites definidos en el equipo.

Pila del producto: los requisitos del cliente


La pila del producto es el inventario  de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones de desarrollo.Representa todo aquello que esperan los clientes, usuarios, y en general los interesados. Todo lo que  suponga un trabajo que debe realizar el equipo tiene que estar reflejado en esta pila.
Estos son algunos ejemplos de posibles entradas de un backlog:

• Permitir a los usuarios la consulta de las obras publicadas por un determinado autor.
•  Reducir el tiempo de instalación del programa.
•  Mejorar la escalabilidad del sistema.
• Permitir la consulta de una obra a través de un API web

Formato de la pila del producto

El desarrollo ágil prefiere la comunicación directa, a la comunicación con documentos.

La pila del producto  no es un documento de requisitos, sino una herramienta de referencia para el equipo.

Si se emplea formato de lista, es recomendable que al menos incluya la siguiente información en cada línea: 

•  Identificador único de la funcionalidad o trabajo.
•  Descripción de la funcionalidad.
•  Campo o sistema de priorización.
•  Estimación 

Dependiendo del tipo de proyecto, funcionamiento del equipo y la organización, pueden resultar aconsejables otros campos:

•  Observaciones
•  Criterio de validación
• Persona asignada
•  Nº de Sprint en el que se realiza
•  Módulo del sistema al que pertenece
•  Etc.

Es preferible no adoptar ningún  protocolo de trabajo de forma rígida. El formato del product backlog no es cerrado. Los resultados de Scrum Management no dependen de la rigidez en la aplicación del protocolo, sino de la institucionalización de sus principios y la implementación en un formato adecuado a las características de la empresa y del proyecto.

La pila del sprint, (sprint backlog en inglés) es la lista que descompone las funcionalidades de la pila del producto en las tareas necesarias para construir un incremento: una parte completa y operativa del producto. La realiza el equipo durante la reunión de planificación del sprint, asignando cada tarea a una persona, e indicando en la misma lista cuánto tiempo falta aún para que la termine.

Es útil porque descompone el proyecto en unidades de tamaño adecuado para determinar el avance a diario, e identificar riesgos y problemas sin necesidad de procesos complejos de gestión.Es también una herramienta de soporte para la comunicación directa del equipo.

Condiciones

•  Realizada de forma conjunta por todos los miembros del equipo.
•  Cubre todas las tareas identificadas por el equipo para conseguir el objetivo del sprint.
•  Sólo el equipo lo puede modificar durante el sprint.
•  El tamaño de cada tarea está en un rango de 2 a 16 horas de trabajo.
•  Es visible para todo el equipo. Idealmente en una pizarra o pared en el mismo espacio físico donde trabaja el equipo.

Formato y soporte

Tres son las opciones: 

•  Hoja de cálculo.
•  Pizarra física o pared.
•  Herramienta colaborativa o de gestión de proyectos.

Y sobre la que mejor se adecua a las características del proyecto, oficina y equipo, lo apropiado es diseñar el formato más cómodo para todos, teniendo en cuenta los siguientes criterios:

• Incluye la información: lista de tareas, persona responsable de cada una, estado en el que se encuentra y tiempo de trabajo que queda para completarla.
•  Sólo incluye la información estrictamente necesaria.
•  El medio y modelo elegido es la opción posible que más facilita la consulta y comunicación diaria y directa del equipo.
•  Sirve de soporte para registrar en cada reunión diaria del sprint, el tiempo que le queda a cada tarea

El Incremento

El incremento es la parte de producto producida en un sprint, y tiene como características: que está completamente terminada y operativa, en condiciones de ser entregada al cliente final. No se trata por tanto de módulos o partes a falta de pruebas, o documentación o…Idealmente en el desarrollo ágil:

•  Cada funcionalidad de la pila del producto se refiere a funcionalidades entregables, no a trabajos internas del tipo “diseño de la base de datos”
• Se produce un “incremento” en cada iteración.

Scrum: Las reuniones

Scrum realiza el seguimiento y la gestión del proyecto a través de las tres reuniones que forman parte del modelo:

•  Planificación del sprint
•  Seguimiento del sprint
•  Revisión del sprint

Este tema describe los objetivos y  protocolos recomendados para cada una.

Planificación del sprint

Descripción general

En esta reunión se toman como base las prioridades y necesidades de negocio del cliente, y se determina cuáles y cómo van a  ser las funcionalidades que incorporará el producto tras el siguiente sprint.

En realidad es una reunión que consta de dos partes: 

En la primera, que puede tener una duración de una a cuatro horas, se decide qué elementos de la pila del producto se van a desarrollar. En la segunda se desglosan éstos para determinar las tareas necesarias, estimar el esfuerzo para cada una, y asignarlas a las personas del equipo.La planificación del sprint no debe durar más de un día. Las características de la reunión son: 

Pre-condiciones

• La organización tiene determinados los recursos disponibles para llevar a cabo el sprint.
•  El propietario del producto tiene preparada la pila del producto, con su criterio de prioridad para el negocio, y un nº suficiente de elementos para desarrollar en el sprint.
•  Siempre que sea posible, el propietario del  producto debe haber trabajado antes con el equipo. De esta forma su estimación previa del trabajo que se puede realizar en el sprint  será bastante ajustada.
•  El equipo tiene un conocimiento de las tecnologías empleadas, y del negocio del producto suficiente para realizar estimaciones basadas en "juicio de expertos”, y para comprender los conceptos del negocio que expone el propietario  del producto.

Entradas

• La pila del producto.
•  El producto desarrollado hasta la fecha a través de los sucesivos incrementos (excepto si se trata del primer sprint)
• Circunstancias de las condiciones de negocio del cliente y del escenario tecnológico empleado.

Resultados

•  Pila del sprint.
•  Duración del sprint y fecha de la reunión de revisión.
•  Objetivo del sprint.

Es una reunión conducida por el responsable del funcionamiento de Scrum (Scrum Manager, o un miembro del equipo en equipos ya expertos en trabajo con Scrum) a la que deben asistir el propietario del producto y el equipo completo, y a la que también pueden asistir otros implicados en el proyecto.

La reunión comienza con la presentación del propietario de la pila de producto (product backlog), en la que expone los resultados que por orden de prioridad necesita; especialmente los que prevé, se podrán desarrollar en el siguiente sprint.

Si la pila del producto ha tenido cambios significativos desde la anterior reunión; explica las causas que los han ocasionado. El objetivo es que todo el equipo conozca las razones y los detalles con el nivel necesario para  estimar el trabajo necesario.

Formato de la reunión

Esta reunión marca el inicio de cada sprint.  Una persona con la responsabilidad de procesos en la 

organización es el responsable de su organización y gestión.

Duración máxima: un día. 

Deben asistir: el propietario del producto, el equipo y el  Scrum Manager (o responsable de este rol)

Pueden asistir: es una reunión abierta a todos los que puedan aportar información útil.

Consta de dos partes separadas por una pausa de café o comida, según la duración.

Primera parte:

Duración de 1 a 4 horas.

Propietario del producto:

Presenta las funcionalidades de la pila del producto que tienen mayor prioridad y que estima se pueden realizar en el sprint.

La presentación se hace con un nivel de detalle suficiente para transmitir al equipo toda la información necesaria para construir el incremento.

El equipo

Realiza las preguntas y solicita las aclaraciones necesarias.

Propone sugerencias, modificaciones y soluciones alternativas.

Las aportaciones del equipo pueden suponer modificaciones en la pila. De hecho no es que “puedan” es que “deben” suponerlas. 

Esta reunión es un punto caliente del protocolo de Scrum para favorecer la fertilización cruzada de ideas en equipo y añadir valor a la visión del producto.

Segunda parte:

En la segunda parte, que puede alargarse hasta el final de la jornada:

El equipo desglosa cada funcionalidad en tareas, y estima el tiempo para cada una de ellas, determinando de esta forma las tareas de la pila del sprint.

En este desglose el equipo tiene en cuenta los elementos de diseño y arquitectura que deberá incorporar el sistema. Los miembros del equipo se auto-asignan las diferentes tareas tomando como criterios sus conocimientos, intereses y distribución homogénea del trabajo.

Esta segunda parte debe considerarse como una “reunión del equipo”, en la que deben estar todos sus miembros y ser ellos quienes descomponen, estiman y asignan el trabajo.

El papel del propietario del producto es atender a dudas y comprobar que el equipo comprende y comparte su objetivo.El Scrum Manager actúa de moderador de la reunión.