Scrum – Metodología Agil #Scrum

scrum1

En esta oportunidad quiero presentarles algunas nociones básicas de Scrum como marco de trabajo que nos permite encontrar prácticas emergentes en dominios complejos, como la gestión de proyectos de innovación.

Scrum es un proceso agil que nos permite centrarnos en entregas de valor para el negocio en tiempos cortos. Es decir, manejamos proyectos basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del mismo. Así el trabajo es realizado mediante la colaboración de equipos auto-organizados y multidisciplinarios, inmersos en un proceso compartido de toma de decisiones a corto plazo.

Trabajar con este esquema permite una inspección rápida y continua del software en proceso de desarrollo en intervalos de tiempo cortos.  El negocio establece prioridades y el equipo se auto organiza para encontrar la forma de entregar las funcionalidades con mayor prioridad.  Cada dos o cuatro semanas cualquiera puede ver el trabajo real realizado, decidiendo así mismo si se puede liberar el producto o se debe continuar mejorando.

Veamos a continuación como nos organizamos para trabajar con Scrum.

scrum2.png

Lo primero que debemos definir es el o los equipos de trabajo, es decir tener  uno o más equipos de trabajo, con al menos 3 tres roles básicos dentro del equipo los cuales son:

1.dueño del producto,  Product Owner

Tiene la visión del negocio y conoce a detalle requerimientos del producto que se debe construir, lo que conlleva a ser el líder en cuanto a la toma de decisiones del desarrollo del producto.

2 ScrumMaster

El ScrumMaster es el responsable de que todos los involucrados entiendan y adopten los valores, principios y prácticas de SCRUM.

3 el equipo de desarrollo.

Responsables del diseño construcción y prueba del producto

Para entenderlo mejor veamos las características principales de cada rol.

scrum3

El Product Owner tiene la visión del negocio,  es quien tiene claro los requerimientos del desarrollo del software, siendo este quien tiene definido cada funcionalidad que debe desarrollarse es quien fija orden y prioridades en el product backlog; decide que debe construirse y que no.  En caso de hacer una modificación sobre alguna funcionalidad del software, es el product owner  quien fija las características minimas viables del software.

El Product Owner no da ordenes al equipo de desarrollo, solo debe asegurarse de hacer de conocimiento a cada integrante del equipo el product backlog, debe estar disponible y accesible al equipo para explicar las funcionalidades requeridas cada vez que sea necesario, participar en las reuniones diarias de avance , en los sprint de planificación, revisión y retrospectiva.

El Product Owner debe conocer la velocidad del equipo, para poder realizar las estimaciones de cuando estarán implementadas las necesidades en el producto.

En caso de que se requiera cancelar un Sprint por algún imprevisto externo, es el único responsable de  comunicar la cancelación.

El Product Owner es quien valida las entregas del equipo de desarrollo.

Es indiferente si el producto es una aplicación interna o un producto externo; el dueño del producto tiene la obligación de entregar el mayor valor posible, que incluye el foco en el desarrollo técnico.

scrum4

El Scrum master se encarga de que todo el equipo entienda scrum y lo aplique correctamente, es como un instructor, ayuda al equipo scrum y al resto de la organización a desarrollar la metodología dentro de la organización.  Implementar scrum es un proceso de cambio, el Scrum master apoya a todo el equipo en la adopción de la metodología

El ScrumMaster no tiene autoridad sobre el equipo de desarrollo, este rol no es similar al del jefe de proyecto de desarrollo. El ScrumMaster actúa como un líder, no como un jefe.

Las características más resaltantes del scrummaster:

1.Planifica la Implementación de scrum en conjunto con la organización

2.Ayuda al Product Owner que es quien tiene la visión del negocio a entender la agilidad.

3.Como instructor enseña al product owner a gestionar la planificación, elaboración del product backlog

4.Ayuda al equipo de desarrollo a convertirse en auto-organizado y multifuniocnal

5.Participa en las resuniones y se asegura que cumplan tiempo y objetivos establecidos.

6.Junto al equipo de desarrollo actualiza el progreso del trabajo

7.Promueve las buenas practicas de programación

8.Organiza y ejecuta cursos de aprender scrum si es necesario

scrum5

Equipo de desarrollo

Scrum define el rol de Equipo de Desarrollo, como una colección de diferentes actores, responsables de diseño, construcción o pruebas.

El equipo de desarrollo se debe auto organizar para presentar la mejor manera de cumplir con los requerimientos del usuario.

El equipo de desarrollo por lo general es de 5 a 9 personas; en forma colectiva tienen todas las habilidades necesarias para producir software de calidad.

Si el proyecto requiere de muchas más personas, digamos unas 35 personas, estas deben ser organizadas en equipos de desarrollo de máximo nueve personas.

scrum6

Los procesos de Scrum corresponden a todas aquellas actividades y al flujo de las mismas dentro de un proyecto Scrum.

En total la metodología desarrolla 19 procesos que se agrupan en 5 fases. Cada fases describe cada proceso en detalle, incluyendo sus entradas, herramientas y salidas asociadas. En cada proceso, algunas entradas, herramientas y salidas son obligatorias, y existen otras que son opcionales, cuyo uso dependerá de la naturaleza del proyecto.

Conozcamos un poco las fases y los procesos que incluyen cada una:

  1. Iniciación (6 procesos) 

En esta fase se crea la Visión del Proyecto que sirve de enfoque y dirección del mismo. Se crean e identifican roles claves del proyecto como el Scrum Master, Product Owner, interesados, equipo del proyecto. Así mismo, se define la lista de prioridades o el Product Backlog la cual sirve de base para la elaboración del plan de lanzamiento y tamaño de cada Sprit.

Procesos

Crear la visión del proyecto (Create Project Vision)

Identificar al Scrum Master y a los interesados o socios del proyecto (Identify Scrum Master and Stakeholder(s))

Formación del equipo Scrum (Form Equipo Scrum)

Desarrollo de épica(s) (Develop Epic(s))

Creación de la lista priorizada de pendientes del producto (Create Prioritized Product Backlog)

Realizar el plan de lanzamiento (Conduct Release Planning)

2. Planificación y Estimación (5 procesos):

Aquí se definen y aterrizan en los Sprints las historias de usuarios, se alinean a todo lo que genera valor a la organización y se hacen las estimaciones de tiempo y esfuerzo para cumplirlas, los cuales se traducen en listas de tareas cuyos tiempos de desarrollo se definen en reuniones de equipo correspondientes, así como el proceso de definición del Sprint Backlog que contiene todas las tareas que deben completarse en el Sprint.

Procesos

Elaborar historias de usuario (Create User Stories)

Aprobar, estimar y asignar historias de usuarios (Approve, Estimate, and Commit User Stories).

Elaboración de tareas (Create Tasks)

Estimar tareas (Estimate Tasks)

Elaboración de la lista de pendientes del Sprint (Create Sprint Backlog)

3. Implementación (3 procesos):

En esta fase se trabaja en las tareas del Sprint Backlog para crear Sprint Deliverables, para ello se utiliza a menudo un Scrumboard para realizar el seguimiento del trabajo y de actividades que se llevan a cabo. También,los inconvenientes o problemas que enfrenta el Equipo Scrum se actualizan en un Impediment Log. Durante esta fase se realizan las llamadas Daily Standup Meeting que son reuniones cortas y eficientes en tiempo donde el equipo da el estatus de sus actividades diarias y manifiesta cualquier inconveniente que pueda tener. Igualmente se actualiza o revisa la lista de prioridades de pendientes del producto.

Procesos

Crear entregables (Create Deliverables),

Llevar a cabo el standup diario (Conduct Daily Standup)

Mantenimiento de la lista priorizada de pendientes del producto (Groom Prioritized Product Backlog)

4. Revisión y Retrospectiva (3 procesos):

Para proyectos grandes que involucran varios equipos Scrum, se realiza en esta etapa, reuniones que permitan juntar a estos equipos y discutir y revisar avances, dependencias e impedimentos en el desarrollo del proyecto. También en esta etapa se lleva a cabo el proceso donde el Equipo Scrum le demuestra el Sprint Deliverable al Propietario del producto y a los Socios relevantes en un Sprint Review Meeting. Igualmente, el Scrum Master y el Equipo Scrum se reúnen para discutir las lecciones aprendidas a lo largo del Sprint, información que se documenta como las lecciones aprendidas que pueden aplicarse a los futuros Sprints.

Procesos

Convocar Scrum de Scrums (Convene Scrum of Scrums)

Demostración y validación del Sprint (Demonstrate and Validate Sprint)

Retrospectiva de Sprint (Retrospect Sprint)

5. Lanzamiento (2 procesos):

Finalmente, esta es la fase más esperada por los interesados o socios del proyecto así como del Scrum Master y Equipo Scrum. En esta fase se presentan los entregables y se les entregan a los Socios relevantes. Un acuerdo formal llamado Aceptación de Entregables, documenta la finalización con éxito del Sprint. Del mismo modo, se realizan actividades de restrospectiva que permite identificar mejoras y lecciones aprendidas del proyecto.

Envío de entregables (Ship Deliverables)

Retrospectiva del proyecto (Retrospect Project)

scrum7

Con Scrum El desarrollo se realiza de forma iterativa e incremental. El corazón de Scrum es un Sprint, es un intervalo prefijado durante el cual se crea un incremento de producto “Hecho o Terminado” utilizable, potencialmente entregable. A lo largo del desarrollo hay Sprints consecutivos de duración constante

Cada iteración, denominada Sprint, tiene una duración preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versión del software con nuevas prestaciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya construida y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor valor de negocio.

Veamos otros conceptos….

Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje no técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.

Sprint Planning: Reunión durante la cual  el Product Owner presenta las historias del backlog por orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint, para en una segunda parte de la reunión, decidir y organizar cómo lo va a conseguir.

Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product Backlog a las que se ha comprometido, en una nueva versión del software totalmente operativo.

Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint.

Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la que el equipo se sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el día anterior, que hará hoy y si hay impedimentos.

Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstración del producto. Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien, qué procesos serían mejorables y discute acerca de cómo perfeccionarlos.

Balanced Scorecard ( Indicadores de Gestión )

Tomado de El Carabobeño A-4 20-10-03 –  Profesor Chichí Paez

“La actividad y las técnicas del Control de Gestión Estratégico van a verse sometidas a unos cambios tan drásticos como no se habían visto desde la década de los años veinte”.       P. Lorino

Sin lugar a dudas que el estilo de gestión gerencial se ha visto afectado profundamente por los cambios que han ocurrido en esta aldea planetaria  en los últimos años. Se ha pasado vertiginosamente de unos principios taylorianos, los cuales en el presente están caducos, por cuanto la estabilidad ya no existe y la norma es el cambio, por lo tanto hay que gerenciar en el interior de cambio o mejor dicho hay que “gerenciar el cambio”. Para lograr este objetivo es necesario analizar de manera continua el “sistema -empresa”, a fin de identificar las principales lagunas o fallas y las desviaciones mas  significativas de los procesos, en donde el diagnóstico y el control es una herramienta estratégica de éxito, por cuanto entre las grandes metas de la empresa y la realidad de los comportamientos habituales, no existe una tendencia franca. En consecuencia se hace necesario la administración de una contabilidad legal y una contabilidad de gestión, entendiéndose la significación de contabilidad, como un sistema de información gerencial eficaz. En el área de contabilidad legal se presentan inevitablemente unas restricciones que conllevan a que estos procedimientos sean muy rígidos y los hacen poco aptos para proporcionar un buen piso informativo para la adopción de decisiones de gestión en un entorno cambiante; por tal motivo se hace imperiosa la implantación de un sistema de contabilidad de gestión, en donde los Indicadores de Control de Gestión ( Balanced Scorecard ) ocupan la plataforma necesaria e indispensable para evaluar los resultados logrados por la actuación de las personas que ocupan cargos en los diferentes niveles gerenciales organizacionales.

Existen muchas definiciones; no obstante esta realidad. Se menciona a continuación la del especialista Darío Abab Aranga, por tener una connotación sistémica y holística:

“Podríamos definir el control de gestión como un instrumento gerencial y estratégico que, apoyado en indicadores, índices y cuadros productivos en forma sistemática, periódica y objetiva, permita que la organización sea efectiva para captar recursos, eficiente para transformarlos y eficaz para canalizarlos”. Como puede apreciarse, de la misma se reafirman dos herramientas gerenciales fundamentales: “La Visión Compartida” y “El  Aprendizaje en Equipo”, que si no están presentes en la gestión gerencial, es imposible lograr la consecución de los objetivos estratégicos establecidos. El antes mencionado especialista considera las siguientes cualidades a los Indicadores de Control de Gestión: 1) son un instrumento gerencial por excelencia; 2) constituyen un eficaz apoyo para la adopción de decisiones; 3) se centran en el cómo, además de en la producción de resultados; 4) enfatizan en la producción de rendimientos; 5) emplean normas y patrones operativos; 6) proyectan el futuro de la organización y 7) son integrales.

Los Indicadores de Control de Gestión (ICG), forman parte de los Sistemas de Información Gerencial (SIG),  a los que J.A.Senn, define de la siguiente manera:

“Proporcionan información de apoyo en la toma de decisiones, donde los requisitos de información pueden identificarse de antemano. Las decisiones respaldadas por este sistema, frecuentemente se repiten”.

Analizados desde esta óptica, los Indicadores de Control de Gestión (ICG), son parte esencial y necesaria de todo tipo de Sistema de Información Gerencial (SIG), por cuanto no son bajo ninguna perspectiva solamente información, sino que agregan valor a los mismos.

En el actual mundo globalizado y altamente competitivo, en donde los recursos de capital, personal y tiempo son tan exiguos, se hace necesario concentrarse en las áreas funcionales u operativas claves decisivas del negocio. No siempre resulta fácil identificar los Factores Claves de Éxito (FCE); es menos difícil identificar las áreas que realmente forman la Unidades Estratégicas de Negocios (UEN) de la organización y hay que garantizarles la adecuada asignación de los recursos, para poder estar en condiciones de colocar la empresa en una posición de auténtica superioridad competitiva. El camino hacia la efectividad de la selección de los Factores Claves de Éxito (FCE), posee dos vertientes: a) eficacia, representada por los componentes calidad, satisfacción del cliente y resultados; y b) eficiencia, constituida por tiempos de procesos, costos operativos y desperdicios. Si se administran inteligentemente estas dos vertientes se podría estar en un proceso de una alta productividad. Esta realidad ideal buscada por todos los empresarios, reduce sustancialmente los escenarios de indecisión, de la ansiedad y la subjetividad, además de que existe un ambiente psico-social altamente motivador para los integrantes de los equipos autónomos de alto rendimiento, así como también estimula el crecimiento y desarrollo, tanto personal como profesional. Lo primordial en el uso de los Indicadores de Control de Gestión (ICG), no es solamente la consecución de los objetivos establecidos, sino obtenerlos con el mejor proceso y por supuesto el más económico.

De acuerdo con el especialista J. Beltrán J., los pasos metodológicos para el establecimiento de Indicadores de Control de Gestión, son los siguientes: 1) contar con objetivos y estrategias; 2) identificar los factores claves de éxito; 3) definir los indicadores para los factores claves de éxito; 4) determinar status, umbral y rango de gestión; 5) diseñar la medición; 6) determinar  y  asignar recursos; 7) mediar  y  ajustar;  8) estandarizar y formalizar y 9) mantener en uso y mejorar continuamente.

Evaluar Desempeño de los Proyectos / productos o servicios brindados TI

Uno de los factores de exito de todo proyecto en marcha que haya estado planificado, es el seguimiento y control sobre las actividades y entregables del proyecto.  Es por ello que debemos medir en cada uno de sus elementos las siguientes consideraciones:

  1. En cuanto a Cronograma de Progreso:

a. Hitos

Medición Descripción
Fechas de hitos Fechas de comienzo y fin (planificado y actual) para actividades, eventos y productos de trabajo/ entregables. Esta medición provee visibilidad sobre las actividades y eventos planificados. La comparación de fechas de hitos planificados contra actuales provee una comprensión de los cambios en la planificación a nivel de actividades.

 

b. Progreso de las Unidades de Trabajo

Medición Descripción
Estado de requerimientos Requerimientos en cada estado del proceso de desarrollo (análisis, diseño, construcción, prueba)
Estado de reporte de problemas Cuenta el nro. de problemas reportados y resueltos. Esta tasa indica también la calidad del proceso de resolución de problemas, basado en el promedio de problemas reportados y el tiempo promedio para resolverlos.
Estado de revisiones Cantidad de revisiones de producto y auditorias de procesos, planificadas y reales
Estado de requerimientos de cambio Cuenta el nro. total de requerimientos de cambio que afectan el producto. Provee un indicador de la cantidad de retrabajo que ha sido realizado o que es requerido.  La medición solo identifica el nro. de cambios; no el impacto funcional de los cambios, o el esfuerzo requerido para implementarlos.
Estado de componentes Componentes en cada estado del proceso de desarrollo (análisis., diseño, construcción, prueba)
Estado de Pruebas Mide el nro. de casos de prueba que han sido planificados contra el nro. que ha sido completado exitosamente.

2. En Cuanto a Recursos y Costos

a. Personal

Medición Descripción
Esfuerzo Esfuerzo en hs./persona, planificado y actual, por fase, etapa o entregable, y por rol
Experiencia del personal Cuenta la cantidad de personal experimentado en cada división o área. Permite determinar si se cuenta con suficiente personal experimentado. La experiencia es especialmente medida en años.
Rotación de personal Mide la cantidad de personal Ganado y perdido. Excesiva rotación impacta en curvas de aprendizaje, productividad, y la capacidad para implementar un sistema con los recursos provistos dentro del cronograma y costos. Esta medición es más efectiva cuando es usada en conjunto con Experiencia de personal. La pérdida de personal clave y experimentado es crítica.

b. Performance Financiero

Medición Descripción
Valor Agregado Compara el costo del trabajo realizado, al presupuestado. Presentado en $ o U$S presupuestados por cada componente de la WBS (Work Breakdown Structure). También identifica, tempranamente, sobrecostos de un proyecto.
Costos Mide los costos presupuestados y gastados en un proyecto. Provee información acerca de la cantidad de dinero gastado, en un proyecto o producto, comparado con los presupuestos.
Rentabilidad Mide la rentabilidad planificada y real en un proyecto. Provee información acerca de la cantidad de dinero ganado en un proyecto, en relación a los gastos incurridos.

3. Tamaño de producto y estabilidad

a. Tamaño físico y estabilidad

Medición Descripción
Líneas de Código Cantidad de líneas de código fuente que ha sido desarrollada para el proyecto o producto. También pueden contarse LOC agregadas, eliminadas o modificadas. Es una medición bien conocida que ayuda a estimar duración, esfuerzo, costo y productividad de proyectos. Esta medición se encuentra estrictamente relacionada al lenguaje de programación usado.

4. Tamaño de producto y estabilidad

a. Tamaño físico y estabilidad

Medición Descripción
Líneas de Código Cantidad de líneas de código fuente que ha sido desarrollada para el proyecto o producto. También pueden contarse LOC agregadas, eliminadas o modificadas. Es una medición bien conocida que ayuda a estimar duración, esfuerzo, costo y productividad de proyectos. Esta medición se encuentra estrictamente relacionada al lenguaje de programación usado.

5. Calidad de producto

a. Tamaño funcional y estabilidad

Medición Descripción
Requerimientos

 

Cantidad de Requerimientos por tamaño/ complejidad

b. Correctivos funcional

Medición Descripción
Defectos Califica el número, estado, y prioridad de los defectos reportados. El nro. de defectos indica la madurez del producto. Dar seguimiento al tiempo en que los defectos permanecen abiertos puede ser usado para determinar si se está progresando en la corrección de defectos, o si el retrabajo está siendo diferido.
Densidad de defectos Cantidad de defectos por tamaño del producto, o miles de líneas de código. Puede identificar componentes con mayor concentración de defectos.
Performance técnica Es una combinación de otras mediciones que son definidas por los requerimientos técnicos y funcionales del sistema. Estos requerimientos apuntan a características funcionales que pueden ser cualitativamente definidas y demostradas. Pueden medirse requerimientos como funciones de usuario, interoperabilidad de componentes, características de seguridad, tiempos de respuesta, etc. Estas mediciones proveen un indicador de la capacidad del sistema de satisfacer los requerimientos funcionales del usuario.

c. Mantenibilidad

Medición Descripción
Tiempo de restauración Mide el tiempo que se debe esperar para la recuperación a partir de una falla del sistema. Puede incluir dos tareas: restauración inmediata de la capacidad operacional, y corrección de la causa original del problema.

Una medición comprensiva incluye el tiempo transcurrido, esfuerzo, y recursos necesarios para restaurar el problema y resolver el problema.

Acciones de mantenimiento Cuenta el nro. e impacto de acciones de mantenimiento que son realizadas sobre el sistema. Esta medición es  mas efectiva cuando las acciones son agregadas con el tipo de acción realizada. Por ejemplo, preventiva/ no programada, diferida, tipo de componentes impactados, prioridad, impacto en el servicio al usuario, o tamaño relativo (hs. de trabajo o costo).

d. Eficiencia

Medición Descripción
Tiempo de respuesta Cantidad de tiempo requerido para llevar a cabo una función, tal como completar una tarea o procesar un pedido. Cuenta el tiempo entre el inicio y la conclusión de un evento. Indica si el componente responde de manera oportuna.

e. Portabilidad

Medición Descripción
Compatibilidad con estándares Mide la portabilidad e interoperabilidad de una arquitectura y sus componentes individuales. La medición ayuda a asegurar interfaces consistentes e identificar adherencia a los estándares documentados.

f. Usabilidad

Medición Descripción
Errores de operación Mide la facilidad de uso y confiabilidad del sistema en el ambiente operacional. Esta medición permite conocer fallas

g. Confiabilidad

Medición Descripción
Fallas Esta medición esta basada en la cantidad, criticidad, e intervalo de tiempo entre fallas. Una falla es la incapacidad de un componente del sistema para realizar una función requerida bajo ciertas condiciones en un tiempo especificado. Esta medición es usada para indicar la confiabilidad a través del tiempo promedio entre fallas.
Tolerancia a fallas Mide la capacidad de un sistema para continuar realizando sus funciones a pesar de fallas en sus componentes. La medición determina si el sistema puede operar dentro de los requerimientos de confiabilidad, mantenibilidad, disponibilidad, y seguridad después de ocurrida una falla. Es frecuentemente alcanzada a través de redundancia de componentes u otras características de diseño que permiten la recuperación funcional. Debe ser monitoreada en la fases de operación y mantenimiento.

6. Performance del proceso

a. Compatibilidad del proceso

Medición Descripción
Nivel de madurez Nivel de madurez del proyecto
Observaciones de auditorías de procesos Cantidad de requerimientos para cada área clave de proceso por estado (satisfecho, parcialmente satisfecho, y no satisfecho). Esto se mide para cada proyecto/ división.

b.Eficiencia

Medición Descripción
Productividad Compara la cantidad de productos completados en la cantidad de esfuerzo insumido.

c. Eficacia

Medición Descripción
Defectos encontrados Esta medición identifica defectos que fueron insertados durante un proceso y capturados dentro del proceso, o sus actividades de revisión independientes. Indica cuan bien es realizado el proceso de revisión. La cantidad de defectos encontrados está relacionada a la cantidad de esfuerzo, recursos y herramientas aplicadas.
Retrabajo Cantidad de horas de trabajo insumidas en retrabajo. O sea, esfuerzo dedicado a tareas que si se hubieran hecho bien desde el principio, no hubiera

7. Efectividad de la tecnología

a. Performance técnica

Medición Descripción
Cumplimiento técnico a los requerimientos Es una combinación de otras mediciones que son definidas por los requerimientos técnicos y funcionales del sistema. Estos requerimientos apuntan a características funcionales que pueden ser cualitativamente definidas y demostradas. Pueden medirse requerimientos como funciones de usuario, interoperabilidad de componentes, características de seguridad, tiempos de respuesta, etc. Estas mediciones proveen un indicador de la capacidad del sistema de satisfacer los requerimientos funcionales del usuario.

b. Impacto de la tecnología

Medición Descripción
Impacto de la nueva tecnología en  reducción del ciclo de   desarrollo Mide los cambios al proyecto o sistema, que son atribuidos a una tecnología específica. Estos cambios pueden ser positivos o negativos. Esta medición puede ser usada para apoyar decisiones tendientes a adoptar una tecnología particular o a mitigar los efectos negativos de la incorporación de cierta tecnología.
Cambios de línea base Monitorea la cantidad de veces que un producto cambia a través del tiempo.

Indica la estabilidad de una determinada tecnología o la estabilidad de un producto implementado en esa tecnología. Provee una visión acerca de la frecuencia con la cual la tecnología probablemente cambiará.

8. Satisfacción del Cliente

a. Feedback del cliente

Medición Descripción
Resultado de encuestas Muestra la calificación del cliente, respecto de los productos/ servicios que proveemos. Indica si las necesidades y expectativas del cliente están siendo satisfechas.

b. Soporte al Cliente

Medición Descripción
Requerimientos de soporte Mide la cantidad, tipo, estado, y prioridad de las llamadas del cliente para soporte del producto. Esta medición provee información sobre defectos del producto o problemas de usabilidad encontrados en el campo. El número de defectos descubiertos indica la calidad del producto entregado. El estado de los requerimientos de soporte (cantidad de abiertos y cerrados) refleja la capacidad de soportar el producto luego de la entrega.
Tiempo de soporte Mide el tiempo insumido para responder, resolver, o satisfacer los requerimientos de soporte de un cliente. Seguir la duración de los problemas no resueltos puede determinar el nivel de satisfacción, del cliente, alcanzado por la actividad de soporte del producto.

Preparando el escenario: Agiles y Scrum #scrum

Como mucha gente, nos entusiasma la adopción de Metodologías Agiles cuando trabajamos con proyectos de desarrollo de software, en particular la adopción de Scrum.

Para quienes hemos participado como Gerente de Proyectos con metodologías tradicionales para aplicar lineamientos de seguimiento y control, podremos observar que Scrum hace que el equipo de desarrollo de software alcance mejores rendimientos y niveles de productividad, debido Scrum nos enseña cómo dar unos pasos atrás para reflexionar sobre lo que hacemos y aprender a mejorar nuestras técnicas y procesos con nuevas ideas y conceptos.

Scrum nos ayuda a superar obstaculos, en forma ágil a traves del aprendizaje, todo cambio es dificil si no se gestiona adecuadamente, pero un buen manejo de las dificultades puede convertirse en oportunidades para mejora del proyecto.

¿Qué es la Fundación de Software Ágil Desarrollo y Gestión de Proyectos?

En 2001, un grupo de expertos en software se reunieron en la localidad de Utah, Snowbird para redactar lo que se conoce como el Manifiesto Ágil (www.agilemanifesto.org):

” Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

a. Individuos e interacciones sobre procesos y herramientas
b. Software funcionando sobre documentación extensiva
c. Colaboración con el cliente sobre negociación contractual
d. Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.”

Los doce Principios del Manifiesto Ágil:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

7. El software funcionando es la medida principal de progreso.

8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Aunque el Manifiesto Ágil se redactó en 2001, pocos años después de Scrum, es un hecho bien conocido entre los expertos que el manifesto tiene una gran influencia en Scrum.

Esta influencia fue evidente en el segundo libro de Ken Schwaber, Gestión ágil de proyectos con Scrum, siendo Scrum una de las metodologías ágiles con los valores y principios que se mencionan en el Manifiesto Ágil.

Es importante destacar en este momento la declaración de interdependencia realizada en el 2005 para Proyectos Agiles (http://pmdoi.org/index.html):

Los principios de esta declaración, que todo equipo de desarollo ágil debería asumir sin problemas, son:

“Nosotros…

1. Incrementamos el retorno de la inversión enfocándonos en lograr un contínuo flujo de valor.
2. Proporcionamos resultados fiables involucrando frecuentemente al cliente y compartiendo con el la propiedad del proyecto.
3. Esperamos incertidumbre y la manejamos mediante iteraciones, anticipación y adaptación.
4. Liberamos creatividad y motivación reconociendo a los individuos como la fuente última de valor y creando un entorno donde ellos puedan marcar la diferencia.
5. Impulsamos el rendimiento mediante la responsabilidad compartida en los resultados y efectividad del equipo.
6. Mejoramos la efectividad y la confianza mediante procesos, prácticas y estratégias especificas para cada situación.”

¿Como funciona Scrum?

Los Miembros del Equipo es uno de los Roles De Scrum. El equipo del proyecto es un grupo multi-funcional de personas con todas las habilidades diferentes que son necesarias para convertir los requerimientos en algo que es un incremento de una funcionalidad potencialmente productiva. Por lo tanto, usualmente consiste en:

  • analistas
  • diseñadores
  • encargados de Calidad (QA)
  • desarrolladores
  • documentadores
  • otras habilidades necesarias para realizar el trabajo

Este es el equipo que se compromete con el Dueño Del Producto en las tareas a realizar en cada iteración, y luego las hace. Al final de la iteración le muestran al Dueño Del Producto el resultado, de manera que pueda elegir cómo seguir.

Muchas organizacionse suelen tener un grupo de personas especializadas en distintos temas, como ser usabilidad, administradores de bases de datos, expertos en seguridad y arquitectos de sistemas. Cuando se necesita la participación de alguno de ellos, deberían pasar a formar parte del equipo. Es decir, no son parte de un grupo “externo” de expertos que dan consejos, sino que se convierten en miembros del equipo para aquellas iteraciones en las que es necesario construir una arquitectura, infraestructura o trabajar en la base de datos. Pueden estar trabajando o guiando, monitoreando a los miembros del equipo que hacen el trabajo.  Se comprometen al comienzo de la iteración junto al resto del equipo, y siguen con ellos hasta el fin de la iteración. Por lo tanto se convierten en cerdos por un período corto de tiempo.
Características

  • Multi-funcional.
  • Tamaño del equipo de entre 5 y 9 miembros.
  • Auto-Administrado, gestionado por los mismos miembros del equipo.
  • Responsabilidades

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 de 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 miembros del equipo los que realizan estas funciones.

En el equipo:

  • Todos los miembros conocen comprenden la visión del propietario del producto.
  • Aportan y colaboran con el propietario del producto en el desarrollo de la pila de 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.

Entonces las responsabilidades son:

  • Selecciona el objetivo de la iteración y determina los resultados del trabajo
  • Tiene el derecho para hacer todo lo necesario (dentro de los límites de las guías del proyecto) para alcanzar el objetivo de la iteración
  • Se organiza a si mismo y a su trabajo
  • Realiza demostraciones del resultado del trabajo ante el Dueño Del Producto y los stakeholders.

 

Planificación Del Sprint

El propósito de un Sprint es convertir un set de items del Backlog Del Producto en un incremento de funcionalidad potencialmente productiva. El Dueño Del Producto, el Scrum Master y los Miembros Del Equipo De Scrum se reunen antes de cada Sprint para determinar en qué funcionalidad del producto se seguirá trabajando. El Dueño Del Producto presenta el Backlog Del Producto y el equipo selecciona lo que cree puede ser construido durante el Sprint.

La reunión de Planificación del Sprint consiste de dos partes, cada una de las cuales puede durar hasta cuatro horas.

1. Selección del backlog (Exposición): el Dueño Del Producto presenta el backlog de mayor prioridad al equipo de desarrollo. Juntos colaboran para acordar cuántos de estos items pueden convertirse en un Incremento Del Producto potencialmente productivo durante el próximo Sprint. El equipo realiza la Estimacion Del Sprint y selecciona todo lo que crea pueda realizar.

2. Planificación de trabajo del Sprint (Resolución): el equipo define la arquitectura y el diseño de la funcionalidad que fue seleccionada, y luego define el trabajo, o tareas que conformarán el Backlog Del Sprint, para construir dicha funcionalidad durante el próximo Sprint.

El tiempo que dura la Planificación del Sprint debería estar en correspondencia con la duración misma del Sprint (donde, por ejemplo, en un sprint de 2 semanas no se deberían usar más de 4 horas en total para la planificación).

Pre-condiciones

La organización tiene determinados los recursos posibles para llevar a cabo el sprint.

El propietario del producto tiene preparado el backlog 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 ya previamente con el equipo. De esta forma su estimación previa de qué cantidad de backlog de producto se puede desarrollar 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

  • El backlog 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

  • Backlog del sprint.
  • Duración del sprint y fecha de la reunión de revisión.
  • Objetivo del sprint.
  • Funciones del rol de Scrum Manager

El Scrum Manager es responsable y garante de:

  • Se realiza esta reunión antes de cada sprint.
  • Que antes de la reunión que el propietario del producto disponga de un backlog adecuado y suficiente para realizar el sprint.
  • Que el diálogo principal de la reunión se realice entre el propietario del producto y el equipo. Otros asistentes pueden participar, pero su colaboración no puede implicar toma de decisiones ni limitar el diálogo principal.
  • Que la reunión sea un trabajo de colaboración activa entre los dos protagonistas: cliente y equipo, y concluyen con un acuerdo sobre el incremento de producto que van a realizar en el sprint.
  • Que el equipo comprende la visión y necesidades de negocio del cliente.
  • Que el equipo ha realizado una descomposición y estimación del trabajo realistas y ha considerado las posibles tareas necesarias de análisis, investigación o apoyo.
  • Que al final de la reunión están objetivamente determinados:
  • Los elementos del backlog del producto que se van a ejecutar.

El objetivo del sprint.

  • El backlog del sprint con todas las tareas estimadas.
  • La duración del sprint y la fecha de la reunión de revisión.
  • El Scrum Manager modera la reunión para que no dure más de un día. Debe evitar que el equipo comience a profundizar en trabajos de análisis o arquitectura que son propios del sprint.

Creación de historias

El Dueño del Producto presenta las historias de usuario, las cuales se escriben con títulos que el equipo comprenda en los post-it amarillos grandes. Estos post-it se pegan en la mesa para que todos los vean. Cada post-it contiene 3 datos:
1. Nombre de la historia
2. Importancia
3. Estimación

Validación

El nombre de la historia es una muy breve frase o título que describe a la historia (por ejemplo, “exportación de saldos”, “alta de usuario”, “modificación de dirección de facturación”, etc.).

La importancia es un número positivo; mientras más grande el número más importante la historia (y deberá terminarse antes que historias de menor importancia). La importancia la indica el Dueño del Producto.

La estimación en principio se deja en blanco, ya que será completada más adelante (pero dentro de la misma reunión).

La validación será la forma que el Dueño del Producto dará por aceptada la historia en la reunión de Revisión (Demo del Producto).

Así, luego de la exposición del Dueño del Producto, se tiene cierto número de historias pegadas sobre la mesa, ordenadas por importancia.

El Equipo además puede agregar historias propias, generalmente técnicas, que considera necesarias para la ejecución del proyecto (por ejemplo, la creación de un repositorio de código).

Pizarra de Trabajo

Es recomendable, que el propietario del producto emplee una hoja de cálculo, alguna herramienta similar, o el soporte de una intranet, para guardar en formato digital la pila del producto. Pero no es aconsejable emplearla como base para trabajar sobre ella en la reunión proyectándola sobre la pantalla de la sala. Es mucho mejor trabajar y manipular elementos físicos; y usar una pizarra y fichas removibles (adhesivas, con chinchetas o magnéticas).

Un ejemplo de pizarra.

La pizarra es una herramienta para facilitar la comunicación y el trabajo de la reunión. Al final de la reunión el propietario del producto registrará en la hoja de cálculo, o en la herramienta que emplee, el estado y las modificaciones en el backlog del producto. El equipo hará lo mismo con backlog del sprint. Según la distribución y espacio de la oficina de trabajo quizá se reutilice la pizarra o las notas para el seguimiento del sprint; o quizá no. Este es un ejemplo, pero la pizarra, y el resto de las formas, son técnicas que ayudan a trabajar de forma ágil; no reglas estrictas. En cada caso se pueden ajustar o modificar según las características de la organización. Algunos soportes que se suelen emplear:

  • Pizarra blanca y fichas adhesivas tipo “Post-it”
  • Pizarra de corcho laminado y chinchetas para sujetar las fichas.
  • Pizarra de acero vitrificado y soportes magnéticos para sujetar las fichas.
  • Se puede conseguir una solución práctica y económica empleando fichas adhesivas (“Post-it”) y usando como pizarra cartón pluma blanco de 5mm. fijado con puntas directamente sobre la pared. El cartón pluma es un material ligero, de acabado satinado que puede adquirirse en tiendas de materiales para bellas artes y manualidades.
  • Ejemplo De Backlog Del Sprint

Daily Scrum

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama “daily standup”. El scrum tiene unas guías específicas:

La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc)

Todos son bienvenidos, pero sólo los “cerdos” pueden hablar.

La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.

Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)

La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:

  • ¿Qué has hecho desde ayer?
  • ¿Qué es lo que estás planeando hacer hoy?
  • ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

 

 

 

Diferencias entre Metodologías Tradicionales y Ágiles #MetodologiasAgiles

Diferencias:

Metodologías Tradicionales

Metodologías Agiles

Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo Basadas en heurísticas provenientes de prácticas de producción de código
Cierta resistencia a los cambios Especialmente preparados para cambios durante el proyecto
Impuestas externamente Impuestas internamente (por el equipo)
Proceso mucho más controlado, con numerosas políticas/normas Proceso menos controlado, con pocos principios.
El cliente interactúa con el equipo de desarrollo mediante reuniones El cliente es parte del equipo de desarrollo
Más artefactos Pocos artefactos
Más roles Pocos roles
Grupos grandes y posiblemente distribuidos Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio
La arquitectura del software es esencial y se

expresa mediante modelos

Menos énfasis en la arquitectura del software
Existe un contrato prefijado No existe contrato tradicional o al menos es bastante flexible

Diferencias por etapas  y enfoque metodológico 

MODELOS RIGUROSOS

ETAPA

MODELOS AGILES

 

 

 

Planificación predictiva y “aislada”

 

 

Análisis de requerimientos

 

 

 

 

Planificación adpatativa:Entregas frecuentes + colaboración del cliente

 

Planificación

 

Diseño flexible y Extensible + modelos + Documentación exhaustiva

 

Diseño

 

Diseño Simple: Documentación Mínima + Focalizado en la comunicación

 

Desarrollo individual con Roles y responsabilidades estrictas

 

Codificación

Transferencia de conocimiento: Programación en pares + conocimiento colectivo

 

Actividades de control]: Orientado a los hitos + Gestión miniproyectos

Pruebas

Liderazgo-Colaboración: empoderamiento +auto-organización

 

Puesta en Producción

 Diferencias por las características del Proyecto

Modelo de Proceso

Tamaño del Proceso

Tamaño del Equipo

Complejidad del Problema

RUP Medio / Extenso Medio / Extenso Medio / Alto
ICONIX Pequeño / Medio Pequeño / Medio Pequeño / Medio
XP Pequeño / Medio Pequeño Medio / Alto
SCRUM Pequeño / Medio Pequeño Medio / Alto

 

 

 

 

 

En este cuadro se presenta una comparativa de las modelos de proceso en cuanto a las características del proyecto, analizamos el tamaño del proceso, del equipo y la complejidad del problema para cada uno de los modelos. Podemos resaltar que: con un pequeño equipo de desarrollo se puede realizar grandes proyectos, de alta complejidad; es el caso de XP y SCRUM.

Diferencias Por la curva de Aprendizaje

Modelo de Proceso

Curva de aprendizaje

Herramienta de integración

Soporte Externo

RUP Lenta Alto Soporte Alto Soporte
ICONIX Rápida Algún Soporte  Disponible Algún Soporte  Disponible
XP Rápida No mencionado Algún Soporte  Disponible
SCRUM Rápida No mencionado Algún Soporte  Disponible

 Con respecto a la curva de aprendizaje, vemos que los modelos ágiles,  nos ofrecen una mayor ventaja pero con ciertas limitaciones, ya que aun no hay sido explotadas a gran escala como lo es RUP que posee alto soporte y herramientas integrales que nos guían a través del mismo, facilitando aplicar con mayor efectividad esta metodología, permitiendo aprovecharla al máximo

Cabe destacar:

  •  El retrasar las decisiones en un proyecto de software permite potenciar el valor del producto tanto para el cliente como al equipo o empresa que desarrolla
  • Para que un grupo de desarrollo adopte una metodología ágil debe poseer experiencia  trabajando con metodologías tradicionales, ya que la experiencia es la que predomina en los mementos cruciales del proyecto, además debe tener la capacidad de ser equipos  auto-gestionados, altamente motivados y con gran innovación
  • Las metodologías ágiles permiten disminuir costos  y brindar flexibilidad a los proyectos de software donde la incertidumbre está presente
  • El uso de metodologías tradicionales es esencial al inicio en un equipo de desarrollo de software
  • Las metodologías ágiles se deberían aplicar en proyectos donde exista mucha incertidumbre donde el entorno es volátil, donde los requisitos no se conocen con exactitud, mientras que las metodologías tradicionales obligan al cliente a tomar las decisiones al inicio del proyecto.

 

ICONIX #MetodologiasAgiles

El proceso de ICONIX maneja casos de uso, como el RUP, pero le falta mucho para llegar al nivel del RUP. También es relativamente pequeño y firme, como XP, pero no desecha el análisis y diseño que hace XP.  Este proceso también hace uso aerodinámico del UML mientras guarda un enfoque afilado en el seguimiento de requisitos. (Visite: http://en.wikipedia.org/wiki/ICONIX)

El proceso se queda igual a la visión original de Jacobson del manejo de casos de uso, esto produce un resultado concreto, específico y casos de uso fácilmente entendible, que un equipo de un proyecto puede usar para conducir el esfuerzo hacia un desarrollo real. La Figura 6 muestra el cuadro del proceso. El diagrama retrata la esencia del enfoque aerodinámico al desarrollo del software, que incluye un juego mínimo de diagramas de UML y algunas valiosas técnicas que se toman de los casos del uso para codificar rápida y eficazmente. El enfoque es flexible y abierto; siempre se puede seleccionar de los otros aspectos del UML para complementar los materiales básicos.

SCRUM #MetodologíasAgiles

Scrum es un proceso ágil y liviano que sirve para administrar y controlar el desarrollo de software. El desarrollo se realiza en forma iterativa e incremental (una iteración es un ciclo corto de construcción repetitivo). (Visite: http://es.wikipedia.org/wiki/Scrum)

Cada ciclo o iteración termina con una pieza de software ejecutable que incorpora nueva funcionalidad. Las iteraciones en general tienen una duración entre 2 y 4 semanas. Scrum se utiliza como marco para otras prácticas de ingeniería de software como RUP o Extreme Programming.

Scrum se focaliza en priorizar el trabajo en función del valor que tenga para el negocio, maximizando la utilidad de lo que se construye y el retorno de inversión. Está diseñado especialmente para adaptarse a los cambios en los requerimientos, por ejemplo en un mercado de alta competitividad. Los requerimientos y las prioridades se revisan y ajustan durante el proyecto en intervalos muy cortos y regulares. De esta forma se puede adaptar en tiempo real el producto que se está construyendo a las necesidades del cliente. Se busca entregar software que realmente resuelva las necesidades, aumentando la satisfacción del cliente.

En Scrum, el equipo se focaliza en una única cosa: construir software de calidad. Por el otro lado, la gestión de un proyecto Scrum se focaliza en definir cuales son las características que debe tener el producto a construir (qué construir, qué no y en qué orden) y en remover cualquier obstáculo que pudiera entorpecer la tarea del equipo de desarrollo. Se busca que los equipos sean lo más efectivos y productivos posible.

Scrum tiene un conjunto de reglas muy pequeño y muy simple y está basado en los principios de inspección continua, adaptación, auto-gestión e innovación. El cliente se entusiasma y se compromete con el proyecto dado que ve crecer el producto iteración a iteración y encuentra las herramientas para alinear el desarrollo con los objetivos de negocio de su empresa.

Por otro lado, los desarrolladores encuentran un ámbito propicio para desarrollar sus capacidades profesionales y esto resulta en un incremento en la motivación de los integrantes del equipo.

MODELO DE EXTREME PROGRAMMING #MetodologiasAgiles

Es la más destacada de los procesos ágiles de desarrollo de software formulada por Kent Beck. La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. (Visite http://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema).

Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Las características fundamentales del método son:

  • Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
  • Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.
  • Programación por parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
  • Frecuente interacción del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
  • Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
  • Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
  • Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
  • Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que en más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

 

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

Ventajas

  •  Apropiado para entornos volátiles
  • Estar preparados para el cambio, significa reducir su coste.
  • Planificación más transparente para nuestros clientes, conocen las fechas de entrega de funcionalidades. Vital para su negocio
  • Permitirá definir en cada iteración cuales son los objetivos de la siguiente
  • Permite tener realimentación de los usuarios muy útil.
  • La presión esta a lo largo de todo el proyecto y no en una entrega final

Desventajas

  • Delimitar el alcance del proyecto con nuestro cliente

 

Para mitigar esta desventaja se plantea definir un alcance a alto nivel basado en la experiencia.

Metodologías Ágiles

Metodologías Ágiles

Después de leer sobre diversas opiniones tanto a favor como en contra de las metodologías tradicionales se genera un nuevo enfoque denominado, métodos ágiles, que nace como respuesta a los problemas detallados anteriormente y se basa en dos aspectos puntuales, el retrasar las decisiones y la planificación adaptativa; permitiendo potencia aún más el desarrollo de software a gran escala.

Como resultado de esta nueva teoría se crea un Manifiesto Ágil cuyas principales ideas son:

– Los individuos y las interacciones entre ellos son más importantes que las herramientas y los procesos empleados.
– Es más importante crear un producto software que funcione que escribir documentación exhaustiva.
– La colaboración con el cliente debe prevalecer sobre la negociación de contratos.
– La capacidad de respuesta ante un cambio es más importante que el seguimiento estricto de un plan.

Entre los principales métodos ágiles tenemos el XP (eXtreme Programming), Scrum, Iconix, Cristal Methods, AUP entre otras.

Estas metodologías ponen de relevancia que la capacidad de respuesta a un cambio es más importante que el seguimiento estricto de un plan. Nos lo proponen porque para muchos clientes esta flexibilidad será una ventaja competitiva y porque estar preparados para el cambio significar reducir su coste.

Retrasar las decisiones y Planificación Adaptativa

Es el eje en cual gira la metodología ágil, el retrasar las decisiones tan como sea posible de manera responsable será ventajoso tanto para el cliente como para la empresa, lo cual permite siempre mantener una satisfacción en el cliente y por ende el éxito del producto, las principales ventajas de retrasar las decisiones son:

– Reduce el número de decisiones de alta inversión que se toman.
– Reduce el número de cambios necesario en el proyecto.
– Reduce el coste del cambio

La planificación adaptativa permite estar preparados para el cambio ya que lo hemos introducido en nuestro proceso de desarrollo, además hacer una planificación adaptativa consiste en tomar decisiones a lo largo del proyecto, estaremos transformando el proyecto en un conjunto de proyectos pequeños.

Esta planificación a corto plazo nos permitirá tener software disponible para nuestros clientes y además ir aprendiendo del feedback para hacer nuestra planificación más sensible, sea ante inconvenientes que aceleren o retrasen nuestro producto.