como utilizar seguir scrum

MC. Eduardo Gasca Figueroa [email protected] de Proyectos de Software

ITH Software, Hermosillo, Sonora.

Introducción a las metodologías agiles: SCRUM como punto de partida.

ISC. Diego Medina Cota [email protected] MID de Software

ITH Software, Hermosillo, Sonora.

mailto:[email protected]

mailto:[email protected]

Credenciales

MC. Eduardo Gasca Figueroa, actualmente es maestro adscrito al departamento de sistemas y computación del Instituto Tecnológico de Hermosillo, trabaja en el área de desarrollo de software con metodologías agiles y patrones de diseño y de arquitectura tales como Model View Controller, por más de 4 años a realizado desarrollos de software a la medida en diferentes contextos como lo ha sido el gobierno del estado de sonora, ayuntamiento de Hermosillo y empresas privadas.

Estudió la maestría ciencias de la computación en el Centro de Investigación Científica y de Estudios Superiores de Ensenada(CICESE), trabajando con sistemas persuasivos en ambientes hospitalarios, este lugar es el segundo lugar en investigación en México a nivel mundial en desarrollo de tecnologías de la información.

Conferencista e Instructor en talleres y congresos nacionales e internacionales, ha impartido temas sobre Scrum como agilizar procesos de trabajo a empresas petroleras

Credenciales

ISC. Diego Medina Cota, actualmente es el líder del equipo de desarrollo de ITH Software, ha trabajado con metodologías agiles como Iconix y Scrum, tiene conocimientos en tecnologías tales como ORM, Entity Framework, Linq, MVC.NET, ASP.NET, PHP, PHP Frameworks, WebServices, Patrones de diseño, Pruebas unitarias. Ha participado en diferentes sistemas como sistemas biométricos, sistemas con firma electrónica avanzada, gestión de programas y georeferencia.

Diego, estudio en el Instituto Tecnológico de Hermosillo, y forma parte clave de desarrollo e implementación de nuevas tecnologías en ITH Software.

Actualmente se trabaja en una investigación para determinar que metodologías y modelos de calidad se deben de adoptar en pymes. El nombre de la investigación es: “Análisis y Selección de una Metodología de Desarrollo y Normas de Calidad en Fabricas de Software de Empresas Pequeñas”

Temario – 1er Día

El Desarrollo de software. Documento de Requerimientos. Metodologías Agiles.

ICONIX (opcional al tiempo) SCRUM.Scrum Como punto de partida - introducción.

Temario 2do día

SCRUM

Tipo de programación para las metodologías Agiles.

(propuesta de ITH SOFTWARE)

Temario 3er Día.

Color Verde, Idea Principal de la diapositiva. Autor de la información. Pregunta al publico en general (no hay necesidad de responder,

respuesta personal).

Notas del Instructor

Sistema de colores y simbología

Una fábrica de software es una empresa de la industria del software cuya misión es el desarrollo de software para sus clientes de acuerdo a los requerimientos específicos que aquel le solicita.

Desarrollo de Software

Según el Directorio de Empresas de Tecnologías de Información (DETI), existen en México 1243 empresas de desarrollo de software de las cuales 55% desarrollan software a la medida, seguidas por el 33% cuyo giro no es específicamente el software pero lo desarrollan y adquieren, y finalmente 12% que pertenecen al giro de desarrollo de software empaquetado.


Con base en estos resultados se establece que alrededor del 88% de las empresas de software en México (+- 10%) lo desarrolla de acuerdo con las especificaciones del cliente (requerimientos de software) y sólo el 12% restante desarrolla software para un mercado conocido (Gutiérrez et al,2008).


Un estudio realizado por The Standish Group a fabricas de software presentan problemas de presupuesto y tiempos de entrega.

Se realizó un estudio donde se analizó a más de 350 empresas norteamericanas y 8000 proyectos de software. Dicho estudio arrojo que el 16% de los proyectos de pequeñas compañías finalizaban dentro de los costos y plazos establecidos, mientras que para grandes compañías era del 9%.

El 52% de los proyectos finalizaban excediendo en presupuesto (más de 189%) y tiempo de entrega (122%).

Finalmente el resto de los proyectos (31%) se cancelaban representando 81 billones de dólares.


Fuente: The Standish Group

Los costos del proyecto se disparan. Tiempos no cumplidos de entrega. Clientes insatisfechos al momento de la entrega. Un mercado dinámico y cambiante de necesidades.

Un problema en constante evolución: cuando encontremos una solución, el problema habrá cambiado.

Cambios tecnológicos. Necesidad de software cada vez más robusto.

El desarrollo de software no es un proceso fácil (Canos et al, 2010)

Problemas permanentes…?

Preguntas

Si presentamos estos problemas dentro de nuestra organización, que pautas debemos de tomar para mejorar nuestros resultados

Por qué es tan complejo el problema

En la literatura y en la experiencia de algunas fabricas de software los siguientes puntos denotan los factores que deben de ser siempre vigilados dentro de un ambiente de software:

40 hrs por semana. Experiencia del equipo de trabajo. Tiempo de entrega bien definidos. Documentos de Requerimientos legible y estructurado. Ambiente de trabajo, y jerarquías. Modus operandi - Cliente y el usuario del sistema (Resistencia al

cambio). Nuevas Tecnologías y Capacitaciones (Frameworks). Metodología de Software (SCRUM,RUP, XP, SQUID, ICONIX, etc.). Modelos de calidad.

Desarrollo de software.

Formación y

especialización

Normas de

calidad y Metodolo

gías

Frameworks y

lenguajes especializ

ados.

Proceso Definido

Un proceso definido y efectivo disminuye el esfuerzo en el desarrollo de un producto de software, y aumenta la productividad del grupo de desarrollo (Clark, 2000).

Proceso

Personal

Modelo

El problema empieza al principio del desarrollo del software, en la creación del documento de requerimientos.

La coordinación en un proyecto de desarrollo de software es un factor crítico para liberar un producto de calidad dentro de las restricciones de tiempo, funcionalidad y costo acordadas con el cliente. Una de las estrategias para abordar este problema consiste en utilizar técnicas de modelado de procesos para capturar, evaluar y rediseñar el proceso(Jacobo, 2001).

Regla de Oro 40% análisis, 20 Programación, 40% mantenimiento.

Documento de requerimientos

Para saber qué vamos a construir.

Servir como contrato.

Para evitar conflictos.

Planeación y estimación.

Reducción del esfuerzo en el desarrollo.

Documento de Requerimientos¿Para qué necesitamos los requerimientos?

Es la razón de ser de un proyecto dado.

Pilar de desarrollo del proyecto.

Debe ser utilizable en las etapas de mantenimiento y uso.

Documento de Requerimientos

La calidad del documento está asociada a la etapa de análisis.

Si no se realiza una buena especificación de requerimientos, los costes y/o tiempos de desarrollo pueden incrementarse considerablemente, ya que se deben hacer cambios durante la creación de la aplicación.


El punto de partida de SCRUM es el documento de requerimientos . He aquí el corazón de SCRUM.


Análisis de software

ProblemaOportunidad Análisi

sModelo

Conceptual Abstracto

Análisis

Problema Identificado

ProblemaOportunidad Análisi

sModelo

Conceptual Abstracto


Información Incompleta y Ambigua.

Debilidad de los LenguajesNaturaleza del problema.Naturaleza del Cliente.

Modelo Conceptual Abstracto

Diseño

Modelo Computacional Abstracto


Análisis Detallado

Debemos de llegar a un modelo Conceptual incompleto a un modelo computacional Completo.

Metodologías de Software

Normas de

calidad y Metodolo

gías

Normas de calidad y

Metodologías de

software

Nada sirven buenas notaciones y herramientas para desarrollar software si no se proveen directivas para su aplicación. Así, esta década ha comenzado con un creciente interés en metodologías de desarrollo de software.

Las metodologías de desarrollo de Software surgen ante la falta de procedimientos, técnicas, herramientas y soporte documental que ayuden al momento de desarrollar un producto Software.


Las metodologías de desarrollo de Software a diferencia de los modelos de ciclo de vida, éstas indican los procedimientos de cómo hay que obtener los diferentes productos parciales y finales haciendo uso de uno o varios modelos de ciclos de vida que indicaran qué es lo que se debe de obtener durante el desarrollo del Software.


Las metodologías tienen como principio guiar al desarrollador durante la creación de un nuevo Software pero como los requerimientos son tan variados y cambiantes ha dado como resultado que existan diferentes metodologías para el desarrollo de Software.


Existen dos grandes tipos de metodologías de Software:

Metodologías Robustas, son metodologías orientadas al control de procesos, estableciendo rigurosamente las actividades, nociones, técnicas y herramientas a utilizar.

Metodologías Ágiles/Livianas, son metodologías orientadas a la interacción del cliente con el desarrollo incremental del Software, mostrando versiones parciales al cliente en cortos tiempos, para que se pueda crear una retroalimentación.


Este tipo de metodologías se enfocan en la definición detallada de las tareas y procesos que se realizarán, técnicas apropiadas, herramientas a utilizar y una documentación detallada de manera extensa que prevenga todo tipo de situación de antemano.

En este tipo de metodologías se encuentra la Metodología RUP (Rational Unifed Process) que es una forma disciplinaria de asignar tareas y responsabilidades en una empresa de desarrollo.

Metodologías Robustas

Esta metodología intenta adoptar todos los aspectos que se pueden tener en cuenta durante el ciclo completo del desarrollo de un Software.

Las características principales de RUP son:

Casos de uso como principal enfoque: El objetivo de ser del Software es servir a usuarios; en donde un caso de uso es una funcionalidad que debe de ofrecer al usuario, por lo que constituyen la guía para las actividades a realizar durante el desarrollo, incluyendo las etapas de diseño, análisis, implementación y los casos de prueba.

Colaboración entre equipos: Habrá una comunicación entre todos los participantes (directos o indirectos) en el desarrollo.

RUP (Rational Unifed Process)

Enfocado en la arquitectura: Al referirse a la arquitectura involucra a todos aquellos elementos importantes que interactúan con el Software, como son plataformas de Software, sistemas operativos, manejadores de base de datos, protocolos y todos aquellos requerimientos no funcionales.

Resultados iterativos: Cada cierto tiempo se entregaran/mostraran resultados de manera interna en donde cada entrega se evaluara la calidad y estabilidad del producto para sugerir nuevas mejores.

Enfocado en la calidad: La calidad del producto se deberá de evaluar en cada aspecto de desarrollo.

RUP (Rational Unifed Process)

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término “ágil” Aplicado al desarrollo de software. El punto de partida es fue el Manifiesto Ágil, un documento que resume la filosofía “ágil”

Metodologías Agiles

1 Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.

La gente es el principal factor de éxito de un proyecto software. Es más importante construir un buen equipo que construir el entorno.

Manifiesto Ágil

2 Desarrollar software que funciona más que conseguir una buena documentación.

La regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.

Manifiesto Ágil

3 La colaboración con el cliente más que la negociación de un contrato.

Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito

Manifiesto Ágil

4 Responder a los cambios más que seguir estrictamente un plan.

La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requerimientos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.

Manifiesto Ágil

Los valores anteriores inspiran los doce principios del manifiesto.

I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.

III. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.

V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.

Manifiesto Ágil

VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.

VII. El software que funciona es la medida principal de progreso.

VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante.

IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

X. La simplicidad es esencial.

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.

XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento.

Manifiesto Ágil

Confianza…

Puedo confiar en esta forma de trabajar

No solamente será una moda de trabajar y que pueda desestabilizar mi lugar de trabajo

Estadísticas

VersionOne.Com, es una de las herramientas más conocidas para la gestión de proyectos ágiles, cada año saca estadísticas sobre el uso de metodologías agiles, he aquí algunos de los resultados del 2011.

Entrevistaron aprox. 7000 personas que están relacionadas en algunos de los procesos de desarrollo de software.

Estadísticas

Es considerada una metodología semi ágil.

Está dirigida por casos de uso al igual que las metodologías robustas pero de una forma más ligera.

A diferencia de XP, provee una suficiente documentación de requerimientos y diseño.

ICONIX

Se basa en 4 diagramas de UML 2.0

Diagrama de Casos de Uso.Diagrama de Robustez.Diagrama de Secuencias.Diagrama de Clases.

ICONIX

Diagramas de Caso de Usos.

ICONIX

ICONIXDiagrama de Robustez

ICONIXDiagrama de Secuencia

ICONIXDiagrama de Clases

Dos vistasEstática.Dinámica.

Cuatro puntos de revisión(Milestones)Requerimientos.Análisis y diseño preliminar.Diseño detallado.Implementación.

ICONIX

ICONIX

ICONIXRevisión 1: Requerimientos

ICONIXRevisión 2: Diseño Preliminar

ICONIXRevisión 3: Crítica de Diseño

ICONIXRevisión 4: Implementación

SCRUM – La Metodología Ágil

METODOLOGIA SCRUM

SCRUM – La Metodología Ágil

METODOLOGIA SCRUM.

Se enfoca principalmente en aumentar la comunicación entre los interesados del proyecto.

¿Cuándo es conveniente?

LADO DEL EQUIPO• Cuando no se está entregando al cliente lo que

pidió o quiere (necesita).• Cuando las entregas se alargan demasiado (costos).• Los costos se disparan o la calidad no es aceptable.• Cuando se necesita capacidad de reacción (dead line).• Cuando la moral de los equipos es baja y la rotación

alta (inters y juniors).• Cuando es necesario identificar y solucionar

ineficiencias sistemáticamente (nuevos equipos).

¿Cuándo es conveniente?

LADO DEL PROYECTO.• Scrum está especialmente indicado para proyectos

en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

Ventajas

• Entregas frecuentes priorizadas por valor, potenciación del equipo de trabajo, mejora continua de producto y de proceso.

• Entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto.

• Se permite que los cambios dentro de un proyecto sean aceptados de manera natural y proporciona al cliente margen para flexibilidad e innovación así como productividad y calidad.

Uno de los principios esenciales de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan, lo que implica que el equipo ha de estar abierto a afrontar nuevos desafíos, y sobre todo CAMBIAR O HECHAR ABAJO ESTRUCTURAS, ARQUITECTURAS Y MODULOS COMPLETOS DEL SISTEMA.

Ojo

Scrum Basics

Define un marco para la gestión de proyectos. Está especialmente indicada para proyectos con un rápido cambio de requisitos.

Sus principales características se pueden resumir en 5 puntos.

1) Pila de Productos (The Product backlog), se dice que es corazón del Scrum, ya que es la visión del producto compilada por el dueño o cliente, este documento es una lista priorizada de lo que se requiere obtener (documento de requerimientos).

2) Sprints. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días como máximo(no se debe de extender nunca). El resultado de cada sprint es un incremento ejecutable del producto que se muestra al cliente.

3) Planeación del Sprint. Aquí se seleccionan los requerimientos que se van a ejecutar en un sprint, las reuniones deben de ser con el cliente y el equipo de Scrum (facilitador Scrum máster), discutir sobre las metas y contexto de los requerimientos. Aquí cada requerimiento seleccionado debe de ROMPERSE en pequeñas tareas, a estas tareas se les conoce como lista de sprint.

4) Reuniones a lo largo proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.

5) Revisiones y Retrospectiva, después de que termina el sprint, hay una revisión de sprint donde el equipo de Scrum , los interesados inspeccionan que se hizo durante el sprint y es sometido s discusión y se planea que es que se hará a futuro. Después de esta reunión el equipo de Scrum se junta para una retrospectiva de cuales El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad.

Scrum Basics

Roles de SCRUM

COMUNICACIÓN ENTRE ROLES

Equivalencias entre roles tradicionales y los de scrum

Visión General del Modelo

¿Scrum en mi empresa?

NO IMPORTA CUANTO TIEMPO TARDES PERO TRATA DE Implementar Scrum en todos los niveles de la empresa, probamos diferentes tamaños para los equipos (3 a 12 personas), diferentes duraciones de Sprint (2 a 6 semanas), diferentes maneras de definir “terminado”, diferentes formatos para las Pilas de Producto y Pilas de Sprint (Excel, Jira, tarjetas), diferentes estrategias de pruebas, diferentes maneras de hacer las demostraciones, pero no desistas nunca.

Temario 2do día

SCRUM

Nos podemos encontrar con problemas a la hora de desarrollar software y pensar que son problemas permanentes o comunes…

Elevados costos de producción. Poca comunicación entre el equipo (celo

profesional). Clientes insatisfechos (no participativos).

Review ….

Retrabajos y retrabajos. Tiempos no cumplidos de entrega. Clientes que cambian todo el enfoque de lo

que se requería y se planeaba. Juntas no definidas de entrega. Juntas inesperadas por petición del cliente.

Review ….

… las fabricas de software se demoran en las entregas de sus productos en tiempos superiores al 122% de lo establecido y rebasan su presupuesto en un 189%, derivado a que sus procesos no están establecidos correctamente.

Otro porcentaje muy considerable ni siquiera finalizan los proyectos ya que son cancelados originando pérdidas millonarias

Review …

El desarrollo de software no es una tarea fácil, todo lo contrario es un conjunto de procesos en los cuales se tiene que vigilar y administrar el desarrollo del mismo para asegurar la terminación del software con calidad, bajo el tiempo y los presupuestos establecidos.

Las fábricas de software es la industria que se encarga de desarrollar el software, se pueden identificar tres factores claves dentro de una fábrica de software para su éxito:

Review …

Formación y

especialización

Normas de

calidad y Metodolo

gías

Frameworks y

lenguajes especializ

ados.

Review - Proceso Definido

Un proceso definido y efectivo disminuye el esfuerzo en el desarrollo de un producto de software, y aumenta la productividad del grupo de desarrollo (Clark, 2000).

Proceso

Personal

Modelo

El documento de requerimientos es la piedra angular de todo proyecto de desarrollo de software, con el documento podemos saber y/o servir:

qué vamos a construir. Servir como contrato. evitar conflictos. Planeación y estimación. Reducción del esfuerzo en el desarrollo

Review …

Si no se realiza una buena especificación del documento de requerimientos, los costes y/o tiempos de desarrollo pueden incrementarse considerablemente, ya que se deben hacer cambios durante la creación de la aplicación por la ambigüedad que existen en estos.

Review …

La gente es el principal factor de éxito, se necesitan individuos motivados.

No producir documentos a menos que sean necesario.

Interacción constante entre el cliente y el equipo de desarrollo.

La habilidad de responder a los cambios.

Entregar frecuentemente software que funcione.

La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

Review …

Review …

The Product Owner (Cliente).

El propietario del producto es responsable de maximizar el retorno de inversión (ROI) mediante la lista de requerimientos priorizados (pila de productos), decide qué debe estar en la parte superior de la lista para el siguiente Sprint, y continuamente fija nuevas prioridades y perfecciona la lista.

ROLES DE SCRUM

En el caso de una aplicación interna, el propietario del producto no es responsable de retorno de la inversión en el sentido de un producto comercial (que generará ingresos), pero siguen siendo responsable en el sentido de elegir que requerimientos son importantes y ofrecer a la empresa máximo valor al producto con uso de bajos recursos.

Cliente

En multiequipos de scrum, el cliente puede delegar el trabajo a personas que lo representen en los equipos, pero todas las decisiones y direcciones vienen del nivel mas alto.

Cliente

El equipo de Scrum es el que construye el producto, el equipo de Scrum es multi funcional e incluye toda la experiencia necesaria para entregar el producto.

También es auto-organizado, con un alto grado de autonomía y responsabilidad.

Los miembros del equipo deciden en qué comprometerse, y la mejor forma de lograr que el compromiso sea terminado.

El equipo

El equipo de scrum deben de ser mas menos 7 personas. El equipo puede incluir programadores, diseñadores de interfaces y testers.

El equipo debe de ofrecer ideas al cliente acerca de cómo hacer que el producto sea “Genial”.

Los participantes de Scrum pueden trabajar en otros grupos de Scrum, pero esto puede ocasionar que el tiempo efectivo se reste.

El equipo

El Scrum Master ayuda al grupo de productos aprender y aplicar Scrum. El Scrum Master hace lo que está en su poder para ayudar al equipo a tener éxito.

Esta persona no es el administrador, sin embargo es el que sirve al equipo, los protege de interferencias de afuera, y los educa de cómo debe de ser la comunicación con el cliente.

Debe de tener un alto conocimiento de scrum.

The Scrum Máster

Arquitecto de software, nivel sénior.

Los equipos deberían tener un Scrum máster de tiempo completo, sin embargo en equipos pequeños puede tener un miembro del equipo que juegue este rol.

The Scrum Máster

El Scrum Máster y el cliente no puede ser la misma persona, a veces, el Scrum Máster deberá hablar con el cliente y ser energético en temas importantes que puedan desestabilizar la producción del producto. (por ejemplo, si tratan de introducir nuevos productos en el medio de un Sprint).

Scrum Master

La pila de producto es el corazón de Scrum. Es donde empieza todo. La Pila de Producto es, básicamente, las cosas que quiere el cliente con tiempo de desarrollo, a estas necesidades del cliente se le llamaran Historias.

Pilas de Producto

Pilas de Producto

Campos adicionales:Categoría(backoffice, optimización,

frontoffice).Componentes(base de datos, servidor,

vista).Bug tracking ID.

Pilas de Productos

El Cliente tiene una formación técnica, puede que añada historias del tipo “añadir índices a la tabla de eventos”. ¿Por qué quiere algo así?.

Puede ocurrir que los índices no fueran el cuello de botella que hiciera al formulario ir lento. El autentico objetivo probablemente sería algo como “aligerar el formulario de búsqueda de eventos en el backoffice”.

El equipo está normalmente mejor capacitado para averiguar como resolver algo, el Cliente debe de concentrarse en los objetivos de negocio.

Mantener Pila Producto a nivel de negocio

Asegúrate de que la Pila de Producto está perfectamente lista antes de la reunión de planificación de Sprint.

¿Y esto qué significa? ¿Que todas las historias deban estar perfectamente bien definidas? ¿Qué las estimaciones sean correctas? ¿Qué todas las prioridades hayan sido fijadas? ¡No, no y no!

Preparación Planificación Sprint

La pila de producto debe de existir. Debe de haber una pila de productos y un dueño

de producto. Todos los elementos importantes deben de tener

ratios de importancia asignados DIFERENTES. Los elementos no importantes pueden tener

radios iguales ya que probablemente no se discutan durante la planificación.

El dueño de producto debe de comprender(por qué está ahí) cada historia.

Preparación Planificación Sprint

Es probablemente la reunión más crítica.

El propósito de la planificación de Sprint es proporcionar al equipo suficiente información como para que puedan trabajar en paz y sin interrupciones durante unas pocas semanas, y para ofrecer al Dueño de Producto suficiente confianza como para permitírselo.

Realizar Planificación Sprint

La planificación del Sprint produce, concretamente:

Una meta de Sprint.Una lista de miembros (y su nivel de dedicación, si

no es del 100%)Una Pila de Sprint (lista de historias incluidas en el

Sprint)Una fecha concreta para la Demo del Sprint.Un lugar y momento definidos para el Scrum Diario.


¿Por qué debe de asistir el dueño de producto?“Disculpen, pero, ya he listado lo que quiero. No tengo tiempo para estar en la

reunión de planificación”.

El alcance y la importancia los fija el Dueño de Producto.

La estimación la proporciona el equipo. Durante una planificación de Sprint.

Estas variables sufren un ajuste fino y continuo a través del diálogo cara a cara entre el equipo y el Dueño de Producto.


Normalmente, el Dueño de Producto comienza la reunión resumiendo cuál es su meta para el Sprint y las historias más importantes.

El equipo las repasa y les asigna una estimación comenzando con la más importante.

Muchas veces aparecen dudas importantes respecto al alcance y todo lo que implica, las respuestas sorprenderán al equipo y les obligarán a cambiar sus estimaciones. Esto puede forzar al Dueño de Producto a cambiar la importancia de la historia.


Intentar que el Dueño de Producto comprenda su participación es crucial.

Intentar que alguien del equipo se presente voluntario como delegado del Dueño de Producto durante la reunión.

Tratar de convencer a la gerencia de que asigne un nuevo Dueño de Producto.

Posponer el lanzamiento del Sprint hasta que el Dueño de Producto encuentre el tiempo para asistir a la reunión. Mientras tanto, no comprometerse a ninguna entrega y permitir que el equipo pase el día haciendo cualquier cosa que les parezca importante hacer.

Realizar Planificación Sprint¿Qué ocurre si el Dueño de Producto nunca tiene

tiempo?

Lo más difícil de las Planificaciones de Sprint es que:1) La gente no piensa que vayan a durar tanto…2) ... ¡Pero lo hacen!

4 horas cómo máximo, tal vez otra reunión de 4 horas si no se tiene lo que se dice como Plan de Sprint(NADIE quiere esto).

Lo recomendable es acabar con la reunión. El Sprint sufrirá. La ventaja es que el equipo aprenderá que en la próxima ser más eficaces y ofrecerán menos resistencia a reuniones que anteriormente hubieran considerado excesiva.

Duración Planificación Sprint

Tener algún tipo de agenda u orden del día de la reunión de planificación de Sprint reducirá el riesgo de sobrepasar la duración determinada.

La agenda no es en absoluto inamovible. El Scrum Master puede ampliar o acortar los periodos según sea necesario conforme progresa la reunión.

Agenda Planificación de Sprint

Reunión de planificación de Sprint: 13:00 – 17:00 (10 minutos de descanso cada hora)

• 13:00 – 13:30. El Dueño de Producto comenta la meta del Sprint y resume la Pila de Producto. Se establece un lugar, fecha y hora para la Demo.

• 13:30 – 15:00. El equipo da estimaciones de tiempo, y divide los elementos tanto como sea necesario. El Dueño de Producto actualiza los ratios de importancia. Se clarifican los elementos. Para todos los elementos de alta importancia se establece el “Como probarlo”.

• 15:00 – 16:00. El equipo selecciona las historias que se incluirán en el Sprint.

Se realizan cálculos de velocidad para chequear si es factible. • 16:00 – 17:00. Se selecciona un lugar y hora para el Scrum

Diario (si es que cambio respecto al último Sprint). Se continúa dividiendo las historias en tareas.

Agenda Planificación de Sprint

Sprints cortos:Ciclo de feedback corto.Menos tiempo desarrollando en la dirección

incorrecta.Más entregas y más frecuentes.Más feedback del cliente.

Duración del Sprint

Sprints largos:El equipo tiene más tiempo para conseguir

impulso.Más espacio para recuperarse de problemas

y así poder cumplir la meta del sprint.Menos carga de gestión por reuniones de

planificación de Sprint, demos, etc.


Los dueños del producto prefieren sprint cortos.

Los desarrolladores les gustan los Sprint largos.

El tiempo recomendado para un sprint es de 3 semanas. Suficientemente cortos para proporcionarnos agilidad corporativa, suficientemente largos para lograr flujo y recuperarse de los problemas que aparezcan durante el Sprint.


Es difícil conseguir una meta de Sprint.

Es mejor una medio-meta roñosa que no tener ninguna.

Es importante que esté descrita en términos de negocios. Esto quiere decir que la gente fuera del equipo lo entienda.

Meta del Sprint

La meta podría ser “ganar más dinero” o “impresionar al Director General” o “hacer el sistema lo suficientemente bueno como para entregarlo a un grupo de usuarios beta reales” o “añadir soporte de backoffice básico” o lo que sea.

La meta debería ser algo que no se haya logrado aun.

Resulta muchas veces útil para cuando la gente comienza a sentirse confusa acerca de lo que deberían estar haciendo a mediados de Sprint.

Meta del Sprint

Historias a incluir en el Sprint

La Pila de Sprint de la derecha es una instantánea de las historias la Pila de Producto. Representa las historias a las que el equipo se compromete durante este Sprint.

La altura del corchete azul representa la velocidad estimada del equipo, es decir, cuántos puntos de historia cree el equipo que puede completar durante el próximo Sprint.

El equipo decide cuántas historias incluirá en el Sprint. No el Dueño de Producto ni nadie más.

Esto plantea dos cuestiones:1. ¿Cómo decide el equipo qué historias

incluir en el Sprint?2. ¿Cómo puede el Dueño de Producto

alterar la decisión del equipo?

Qué Historias Incluir

¿Cómo puede el Dueño de Producto alterar las historias

que se incluyen en el Sprint?

Supongamos que tenemos la siguiente situación durante una reunión de planificación de Sprint.

Al Dueño de Producto no le gusta que la historia D no se vaya a incluir en el Sprint. ¿Cuáles son sus opciones durante la reunión de planificación de Sprint?



Una es re-priorizar. Si le da al elemento D la mayor importancia, el equipo se verá obligado a añadirlo al Sprint en primer lugar (descartando en ese caso la historia C).



La segunda opción es cambiar el alcance – reducir el alcance de la historia A hasta que el equipo crea que la historia D podría caber en el Sprint.



La tercera sería dividir una historia. El Dueño de Producto podría decidir que hay algunos aspectos de la historia A que no son tan importantes, así que dividiría la historia A en dos historia A1 y A2 con diferentes niveles de importancia.



Como ves, aunque el Dueño de Producto no puede controlar normalmente la velocidad estimada, hay varias formas en las que puede influenciar qué historias entran en cada Sprint.

Utilizamos dos técnicas para esto:1. A ojo de buen cubero2. Cálculos de velocidad

¿Cómo decide el equipo qué historias incluir en el

Sprint?

ScrumMaster: “ A ver chicos, ¿podemos terminar la historia A en este Sprint?” (señala el elemento más importante de la Pila de Producto).

Lisa: “Bah. Por supuesto que podemos. Tenemos tres semanas, y es una funcionalidad bastante trivial.”

ScrumMaster; “Ok, ¿y si le añadimos la historia B?” (señala el segundo elemento más importante).

¿Cómo decide el equipo qué historias incluir en elSprint?

Ojo de Buen cubero

Tom&Lisa al unísono: “Sigue siendo muy fácil.”

ScrumMaster: “OK, ¿qué tal las historias A, B y C entonces?”

Sam (al Dueño de Producto): “¿La historia C incluye manejo avanzado de errores?”

Dueño de Producto: “No, no es necesario por ahora, podéis implementarlo con un manejo básico de errores.”


Ojo de Buen cubero

Sam: “Entonces C podría entrar también.” ScrumMaster: “OK, ¿y si añadimos la historia D?” Lisa: “Hmmm…” Tom: “Creo que podríamos hacerlo.” ScrumMaster: “¿Seguro al 90%? ¿Al 50%?” Lisa y Tom: “Más bien al 90%.” ScrumMaster: “OK, D entra entonces. ¿Y si

añadimos la historia E?” Sam: “Quizás.” ScrumMaster: “¿90%?¿50%?”


Ojo de Buen cubero

Sam: “Yo diría que más cerca del 50%”. Lisa: “Tengo mis dudas.” ScrumMaster: “OK, entonces lo dejamos

fuera. Nos comprometeremos a A, B, C y D. Por supuesto, terminaremos E si podemos, pero nadie debería contar con ello, así que lo dejamos fuera del plan de Sprint. ¿Qué tal así?”.

Todo el mundo: “OK!”


Ojo de Buen cubero

El ojo de buen cubero funciona bastante bien para equipos pequeños y Sprint cortos.


Ojo de Buen cubero

Esta técnica consta de dos pasos1. Decidir la velocidad estimada2. Calcular cuántas historias se pueden

añadir sin sobrepasar la velocidad estimada.

La velocidad es una medida de “cantidad de trabajo realizado”, donde cada elemento se evalúa en función de su estimación inicial.


Sprint?Cálculos de velocidad



El siguiente gráfico muestra un ejemplo de velocidad estimada al principio de un Sprint y la velocidad real al final de dicho Sprint.

Nota que la velocidad real esta basada en las estimaciones iniciales de cada historia. Cualquier actualización a la estimación de la historia realizada durante el Sprint es ignorada.



Pero…¿Cómo va a ser esto útil?!!!

¡Una velocidad alta o baja dependerá de un montón de factores!

!Programadores con poco sentido común!

!Estimaciones iniciales incorrectas!

!Distracciones imprevistas durante el Sprint!



Pero aun así es bastante útil, especialmente si lo comparamos con “nada en absoluto”.

“Sean cuales sean las razones, aquí está la diferencia aproximada entre cuánto pensábamos que podríamos

hacer y cuánto hicimos en realidad”



Una manera muy fácil de estimar la velocidad es revisar la historia del equipo.

¿Cuál fue su velocidad durante los últimos Sprints?

Y entonces asumir que la velocidad será más o menos la misma en el próximo Sprint.

Tomar en cuenta hora reales de trabajo.



Es importante que el dueño de producto y el equipo estén de acuerdo en una definición clara de “terminado”.

¿Está terminada una historia cuando todo el código ha sido chequeado?

¿O está terminada cuando se ha instalado en un entorno de pre-producción y ha sido verificada por un equipo de pruebas de integración?

Definición de “terminado”

Pueden funcionar las definiciones:

“Lista para pasar a producción”.

“Instalado en preproducción y lista para las pruebas de aceptación”.

“Una historia está terminada cuando el encargado de pruebas del equipo Scrum lo dice”.

Definición de “terminado”

Las historias son entregables de los que el Dueño de Producto se preocupa.

Dividir historias grandes en pequeñas que faciliten la planificación y el riesgo de acabar parcialmente completa, por lo que no aporta valor.

Dividir las historias en historias más pequeñas

Las tareas son no-entregables, o aspectos de los que el Dueño de Producto no se preocupa.

Dividir las historias en tareas

Este tipo de división desde el principio hace que los Scrum diarios sean notablemente más eficientes.

Este tipo de división frecuentemente revela trabajo adicional que hace que las estimaciones suban, con lo que se consigue un plan de Sprint más realista.

Sin esto, tu Sprint está condenado a un mal comienzo. El primer Scrum diario es esencialmente el lanzamiento, donde todo el mundo decide por dónde va a empezar a trabajar.

Desventaja de Scrums por las tardes: cuando llegas al trabajo por la mañana, tienes que acordarte de qué le dijiste a la gente sobre lo que deberían hacer hoy.

Desventaja de los Scrums por las mañanas: cuando llegas al trabajo por la mañana, debes acordarte de qué hiciste ayer para informar sobre ello hoy.

Definiendo el sitio y la hora para el Scrum diario

Es más importante es lo que vas a hacer, no lo que hiciste ayer.

Prioridad 1: Una meta de Sprint y una fecha para la demo. Es lo mínimo que necesitas para empezar el Sprint.

Prioridad 2: Lista de qué historias ha aceptado terminar el equipo en este Sprint.

Prioridad 3: Una estimación para cada historia del Sprint.

Prioridad 4: “Como probarlo”, relleno para cada historia del Sprint.

Definiendo prioridades si nos quedamos sin tiempo en la planeación

Prioridad 5: Cálculos de velocidad y recursos, como chequeo de la planificación del Sprint.

Prioridad 6: Un sitio y hora específicos para la realización del Scrum diario. Solo necesitas un momento para decidirlo.

Prioridad 7: Historias divididas en tareas. Sin embargo, esto puede hacerse en los SCRUM diarios pero interferirá levemente el flujo del Sprint.

Definiendo prioridades si nos quedamos sin tiempo en la planeación

Elementos no funcionales.

Escribir una descripción general del diseño: Por qué debe hacerse: porque los desarrolladores olvidan

constantemente el diseño general, y entonces escriben código inconsistente. Necesitan una visión global documentada para mantener a todo el mundo en la misma línea de diseño.

Reautorizar la capa de acceso a datos: Por qué debe hacerse: porque la capa de acceso a datos se ha vuelto

realmente desordenada y le está costando tiempo a todo el mundo debido a la confusión y los errores innecesarios. Limpiar el código ahorraría tiempo a todo el mundo y mejoraría la robustez del sistema.

Historias técnicas

Es importante mantener a toda la compañía informada sobre lo que está ocurriendo.

Utilizamos una “página de información de Sprint” para esto.

Como comunicar un sprint

Como comunicar un sprint

Una manera de poder trabajar el sprint o interacción durante las dos o cuatro semanas es utilizando herramientas visuales.

Formato Pila Sprint

Formato Pila Sprint

Diagrama burn-down

Lugar de trabajo

la mayor parte de las discusiones interesantes y valiosas sobre el diseño tienen lugar espontáneamente frente al tablón de tareas.

Por esta razón, tratamos de organizar esta área como una “esquina de diseño” explícitamente.

Distribución

Esto es muy útil. No hay mejor manera para obtener una visión general del sistema que estar de pie en la esquina de diseño y observar ambas paredes, entonces echar un vistazo en la computadora y probar la última compilación del sistema.

La “pared de diseño” es sólo una pizarra grande que contiene los garabateos más importantes sobre el diseño y la documentación impresa más importante (diagramas secuenciales, prototipos de la interfaz de usuario, modelos de

dominio, etc.).

Distribución

Distribución

¡Sienta al equipo junto!

Cuando se trata de construir equipos Scrum efectivos, no obstante, no hay alternativa. Incluso si tienes que amenazar personalmente a cada individuo, llevar sus cosas y limpiar sus viejas manchas de café. Si no hay espacio para el equipo, haz espacio.

Distribución

Una vez tengas al equipo junto, los resultados serán inmediatos. Tras un solo Sprint el equipo estará de acuerdo en que fue una buena idea sentarse juntos.

“Juntos” significa: Audibilidad: cualquier miembro del

equipo puede hablar con cualquier otro sin tener que levantarse de su sitio.

Distribución

Visibilidad: todo el mundo puede ver a los demás. Todo el mundo puede ver el tablón de tareas. No necesariamente tan de cerca como para poder leerlo, pero si por lo menos verlo.

Aislamiento: si todo el equipo necesitase levantarse y agruparse para una animada y espontánea discusión sobre el diseño, nadie fuera del equipo está tan cerca como para ser molestado. Y viceversa.

Distribución

Empiezan exactamente a su hora, cada día en el mismo sitio.

Realizar Scrum diarios frente a la tabla de Sprint. No hay nada mejor que eso.

Normalmente realizar las reuniones de pie, ya que eso reduce el riesgo de sobrepasar los 15 minutos.

Cómo hacemos Scrum diarios

Se agregan los elementos no planificados del día anterior y coloca un post-it para cada uno.

Seleccionan las tareas para trabajar.

Se mantiene sincronizado la tabla de Scrum.

Se actualizan estimaciones y se tachan la anterior.

Se suman todas las estimaciones de tiempo y se coloca un nuevo punto en el burn-down de Sprint.


¿Qué pasa cuando hay alguien(es) que no sabe qué hacer?

Considerar programación en parejas. Esto ayuda a tu equipo a aumentar las capacidades técnicas y de conocimiento.

Considerar buscar una historia técnica.

Agregar una nueva historia a tu pila de Sprint e informar al Dueño del Producto.


Una demo de Sprint bien ejecutada, aunque parezca poco espectacular, tiene un efecto muy profundo:

La demo consigue feedback vital de los interesados.

Hacer una demo fuerza al equipo a acabar realmente las cosas y entregarlas (incluso aunque sea sólo en entorno de pruebas). Sin las demos, seguimos consiguiendo enormes montones de cosas terminadas al 99%

Demostración del sprint

Si un equipo se ve obligado a hacer una demo de Sprint, incluso aunque no tengan mucho que realmente esté funcionando, la demo será embarazosa. El equipo tartamudeará y tropezará mientras hace la demo y el aplauso de después será frío. Tal vez se enfadarán con ellos por hacerles perder el tiempo con una demo pésima. Esto duele, pero el efecto es similar al de una amarga medicina. En el próximo Sprint, el equipo intentará por todos los medios tener cosas terminadas.

Demostración del sprint

No pierdas mucho tiempo preparando la demo, especialmente en llamativas presentaciones (funcionalidad).

Asegúrate de presentar claramente el objetivo del Sprint.

Mantén la demo a nivel de negocio, deja los detalles técnicos aparte.

Deja que la audiencia pruebe el producto por si misma.

Prepárate para la demostración

las retrospectivas son extremadamente útiles. Ya que ¡es tu mejor oportunidad para mejorar

Sin las retrospectivas encontrarás que el equipo sigue cometiendo los mismos errores una y otra vez.

Retrospectiva

Reservamos 1-3 horas, dependiendo de cuánta discusión esperemos.

Participantes: el Dueño de Producto, el equipo, scrum master.

Nos vamos a una reunión cerrada, un rincón cómodo con sofás, el patio del tejado o algún sitio similar. Que podamos tener una discusión sin interrupciones.

Retrospectiva

Normalmente no hacemos retrospectivas en la sala del equipo, ya que la atención de la gente suele diluirse.

Alguien es designado secretario.

El Scrum Master muestra la Pila de Sprint y, con ayuda del equipo, resume el Sprint. Eventos importantes, decisiones, etc.

Retrospectiva

Hacemos “la ronda”. Cada persona tiene una oportunidad de decir, sin ser interrumpida, qué piensan que ha ido bien, que podría haber ido mejor y que piensan que debería hacerse de forma diferente en el próximo Sprint.

Observamos la velocidad estimada frente a la real. Si hay una gran diferencia, intentamos analizar por qué.

Cuando el tiempo casi se ha acabado, el Scrum Master trata de resumir las sugerencias concretas cobre qué puede hacerse mejor el próximo Sprint.

Retrospectiva

Retrospectiva

Bien: si hiciéramos el Sprint otra vez, volveríamos a hacer estas cosas igual.

Mejorable: si hiciéramos otra vez el Sprint, haríamos estas cosas de forma diferente.

Mejoras: ideas concretas sobre cómo podemos mejorar en el futuro.

La información que surge durante una retrospectiva de Sprint es casi siempre tremendamente valiosa.

Retrospectiva

“Deberíamos haber pasado más tiempo dividiendo historias en subhistorias y tareas”

Acciones típicas: ninguna. El equipo probablemente corregirá esto por si mismo en el próximo Sprint.

Retrospectiva

“Demasiadas distracciones”

Acciones típicas:

Pide al equipo que reduzca su factor de dedicación el próximo Sprint de forma que tengan una planificación más realista.

Pide al equipo que lleven un registro de las interrupciones el próximo Sprint. Quién interrumpe, cuánto tiempo. Así será más fácil resolver el problema más adelante.

Pide al equipo que canalicen todas las distracciones a través del Scrum Master o el Dueño de Producto.

Retrospectiva

Los Sprint son muy intensos y como desarrollador nunca puedes relajarte, TODOS los días tienes que estar en una reunión y decirle a todo mundo qué conseguiste ayer.

Después de la demo y la retrospectiva tanto el Dueño de Producto como el equipo están llenos de información e ideas por digerir.

Descanso entre Sprint

Descanso entre Sprint

Todos los días:

Asegúrate de que el Scrum diario comienza y termina a su hora. Asegúrate de que todas las historias son añadidas o eliminadas de

la Pila de Sprint cuando sea necesario para mantener el Sprint en fecha.

Asegúrate de que se notifica al Dueño de Producto sobre estos cambios.

Asegúrate de que el equipo mantiene actualizados la Pila de Producto y el burn-down.

Asegúrate de que los problemas o impedimentos son solucionados o reportados al Dueño de Producto y/o el Jefe de Desarrollo.

Lista Comprobación del Scrum Master

Final de Sprint:

Haz una demo de Sprint abierta. Todo el mundo debería ser notificado acerca de la

demo uno o dos días antes. Haz una retrospectiva de Sprint con todo el

equipo y el Dueño de Producto. Invita al Jefe de Desarrollo también, de forma que pueda ayudar a difundir las lecciones aprendidas.

Lista Comprobación del Scrum Master

Cómo programar con metodologías

agiles

Constante cambios en el producto.

Terminar el producto lo más pronto posible.

Recordar que va a necesitar mantenimiento.

¿Por qué tomar en cuenta esto?

¿Alguna vez te ha impedido significantemente un código malo?

¿Por qué lo escribiste?

Mal Código

Si quieres ir rápido no escribas mal código.

Mal Código

*Nunca sigas la corazonada “Al rato lo hago bien”….

Tiempo de productividad

“Siempre deja el campamento más limpio de como lo encontraste”

Regla de los Boy Scout

Código Limpio

“Me gusta que mi código sea elegante y eficiente. La lógica debe ser sencilla para que sea difícil para los bugs esconderse, las dependencias mínimas para facilitar el mantenimiento, el control de errores completo de acuerdo con una estrategia articulada, y el rendimiento cerca de óptimo para no tentar a las personas para hacer el código desordenado con supuestos principios de optimización. Limpiar código hace una cosa también.” Bjarne Stroustrup. Inventor de C++

Código Limpio

“Usted sabe que está trabajando en un código limpio cuando cada rutina que lees resulta ser más o menos lo que esperabas. Puedes llamar código hermoso cuando el código también hace que parezca que el idioma se hizo para el problema.” Ward Cunningham, Inventor de Wiki, XP, etc

Nombres significante

Nombres Significantes

Funciones

Funciones chicas.

Una sola cosa por función(Abstracción).

Cuidado con los argumentos…

No más de 25 líneas de código y no más de 3 niveles.

Funciones

Funciones

Comentarios

“No comentes código malo, reescríbelo.”

Los comentarios no son para mal código.

Siempre tienen que estar actualizados.

Explica tu código por si mismo.

Comentarios informativos y sobre advertencias.

Comentarios

Buena Indentación

Manejo de Errores

Clases

Refactorizar

Sigue buenas prácticas.

No hagas mal código.

Sé autodidacta. Lee.

Sé autocritico y trata de desaparecer malos hábitos.

Estructura tú código.

Consejos

Siempre usa una arquitectura multicapa.

Busca maneras que te faciliten tu trabajo.

KISS (Keep It Simple, Stupid - Mantenlo simple, estúpido).

Si lo puede entender tu abuela… estás en el camino correcto.

CDN (Content Delivery Network) Es un grupo de servidores repartidos por todo el mundo en puntos estratégicos y pensados para la distribución de ficheros.

Conoce tu lenguaje y plataforma de desarrollo.

Consejos

E. Gutiérrez et al, ACERCA DE LA IMPLEMENTACIÓN DE LOS MODELOS DE CALIDAD EN LA

CONSTRUCCIÓN DE SOFTWARE EN MÉXICO, Revista Digital Universitaria, ISSN:1067-6079, 2008

Bibliografía

Preguntas

como utilizar seguir scrum

Documents

fbrica de software

software empaquetado

empresas de desarrollo

desarrollo de tecnologas

giro de desarrollo

mid de softwareith software

metodologa de desarrollo

desarrollo de softwaresegn