Individuos e iteraciones

La Metodologa, (del griego met "ms all", ods "camino" y logos "estudio"), hace referencia al conjunto de procedimientos basados en principios lgicos, utilizados para alcanzar una gama de objetivos que rigen en una investigacin cientfica o en una exposicin doctrinal. El trmino mtodo se utiliza para el procedimiento que se emplea para alcanzar los objetivos de un proyecto y la metodologa es el estudio del mtodo.

El desarrollo gil de software es un marco de trabajo conceptual de la ingeniera de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos mtodos de desarrollo gil; la mayora minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteracin. Cada iteracin del ciclo de vida incluye: Planificacin Anlisis de requerimientos Diseo Codificacin Revisin y documentacin. Los mtodos giles enfatizan las comunicaciones cara a cara en vez de la documentacin.

Un equipo gil es diestro y capaz de responder de manera apropiada a los cambios. Un equipo gil reconoce que el software es desarrollado por individuos que trabajan en equipo, y que su capacidad, su habilidad para colaborar, es el fundamento para el xito del proyecto.

No cometa el error de suponer que la agilidad le da permiso para improvisar soluciones. Se requiere de un proceso, y la disciplina es esencial

Se dice que un proceso gil bien diseado aplana el costo de la curva de cambios, lo que permite que el equipo haga cambios en una fase tarda de un proyecto de software sin que haya un efecto notable en el costo y en el tiempo.

Un proceso gil reduce el costo del cambio porque el software se entrega en incrementos y en esta forma el cambio se controla mejor.

El costo de cambio se emparenta muchas veces con el costo de oportunidad; uno ha tomado una decisin descartando otras. En muchos casos el retomar un viejo camino tiene que ver con las vivencias experimentadas sobre la marcha: el individuo puede realizar una valorizacin a priori de los pro y los contras de las variantes existentes pero recin cuando se pone en movimiento puede percatarse de factores que no haba considerado.

Ya sea retomar viejas decisiones, o la presencia de nuevas alternativas, implica una serie de costos que no siempre se pueden afrontar. Debe evaluarse si los beneficios de elegir un nuevo camino podrn compensar todos los gastos que supone el cambio.
Alquilar una nueva casa puede costar $400.- menos por

Hay Tiempo y Dinero que son necesarios erogar para poder materializar la supuesta ventaja.
Si usted para ahorrarse $400.- mensuales debe abonar

mes. Pero para poder realizar la mudanza hay que hacer nuevos contratos, pagar un servicio de mudanzas, realizar la reinstalacin del los aires acondicionados y cualquier otro servicios que tengamos.

$5000.- en los gastos que implican el cambio Cuntos meses de alquiler debern correr para compensar los mismos? 24 meses sern suficientes para recin dar beneficios ? Usted dispone de $5000.- ahora?

En estos casos es muy probable que continuemos alquilando la casa cara

El Costo del Cambio es muy alto, y como toda decisin tomada se precisa de tiempo para que sea rentable. Esto es algo muy comn en las empresas, en donde el retomar decisiones comerciales descartadas suele ser imposible.

Estamos descubriendo formas mejores de desarrollar software, por medio de hacerlo y de dar ayuda a otro para que lo hagan. Ese trabajo nos ha hecho valorar:

Los individuos y sus iteraciones , sobre los procesos y las herramientas. El software que funciona, mas que la documentacin exhaustiva. La colaboracin con el cliente, y no tanto la negociacin del contrato. Responder al cambio, mejor que apegarse a un plan.

Es decir, si bien son valiosos los conceptos que aparecen en segundo lugar, valoramos ms los que aparecen en primer sitio.

En PMBOK se establecen las propiedades y las caractersticas que debe poseer nuestro jefe de proyecto como tambin las fases y elementos que hay que tener en cuenta en la formacin de un equipo de trabajo. En los equipos podemos observar 4 fases de desarrollo o maduracin:

FORMACIN:

el quipo an no tiene los conocimientos necesarios y depende de la informacin y formacin propuesta por el jefe de proyecto. REACCIN: el equipo es capaz de responder a los interrogantes sobre el proyecto y ya tiene asumidos sus roles dentro de ste. NORMALIZACIN: es esta fase se crean normas de conducta para separar tareas y responsabilidades. Se intenta potenciar las relaciones interpersonales y aumentar la capacitacin individual. ACCIN: el equipo es independiente del jefe y slo lo requiere como facilitador. Su integracin en el proyecto es buena y pueden actuar correctamente.

Equipo

Formacin

Eventos

Normalizacin

Equipo Formado

Reaccin

El jefe de proyecto es una figura clave y la evolucin del proceso depende exclusivamente de l. Entre sus responsabilidades encontramos:

Gestin de costos, funciones y calidad Manejo y administracin de la informacin Gestin de los recursos humanos

Qu es un Equipo?....

Definimos equipo como un pequeo conjunto de personas con habilidades complementarias que tienen un mismo objetivo. Su conformacin es una tarea clave en toda metodologa.

El Liderazgo Servidor (Servant Leadership) es un modelo acuado por Robert Greenleaf en los aos 70. El Liderazgo Servidor nos invita a lograr que los dirigentes de cualquier organizacin o equipo sean primero servidores de sus supervisados y sean capaces de influir en sus mentes, corazones, cuerpos y espritus, creando una conexin muy slida, de gran empata y tica relacional. Greenleaf define el Liderazgo Servidor como el deseo natural de servir primero y liderar despus, como una consecuencia del servicio al otro.

Escucha: el lder tiene un compromiso profundo de escuchar atentamente a los otros. Empata: el lder-sirviente se esfuerza por entender y generar empata con los otros. Sanador: el aprender a curar es una poderosa fuerza para la transformacin, es el potencial curativo hacia uno y los otros. Toma de conciencia: el conocimiento general y la autoconciencia consolidan el liderazgo Persuasin: confa en poder persuadir antes que imponer Conceptualizacin: la capacidad de observar un problema desde una perspectiva de conceptualizacin significa que uno debe pensar ms all de las realidades cotidianas Previsin: La capacidad de entender las lecciones a partir del pasado, las realidades del presente, y las consecuencias probables de una decisin, para el futuro. Administracin: Administrar algo dado en confianza por otra persona Compromiso con el crecimiento de la gente: el lder-sirviente est profundamente comprometido con el crecimiento de cada individuo dentro de su institucin Construccin de una comunidad: Entre aquellos que trabajan dentro de una institucin determinada

Los miembros de un equipo gil tienen ms AUTONOMA en la manera de realizar el trabajo. Se potencia al equipo para que tome decisiones dado que sus miembros son los especialistas, los que tienen los conocimientos, habilidades y experiencias necesarios para llevar a cabo el trabajo. Los planteamientos conjuntos hacen ms sencillos los proyectos, permiten mejores soluciones a partir de las sinergias de todos los miembros del equipo, a diferencia de los modelos de gestin clsicos en que las jerarquas establecen quines son las personas que deciden, dirigen y controlan, con lo que las soluciones que aparecen estn limitadas a la capacidad de estas personas. En un entorno gil las jerarquas se diluyen. Los miembros de un equipo gil establecen un objetivo comn cuando entre todos deciden cuntos requisitos/objetivos son capaces de completar en una iteracin.

Adquieren un COMPROMISO CONJUNTO al elaborar la tctica que van a emplear para conseguir estos objetivos, identificando las tareas, asignndoselas entre ellos y auto-organizndose. Entre todos identifican cuales son los impedimentos, mitigaciones y acciones de mejora a realizar que les impiden proporcionar ms valor, ms calidad, ser ms productivos y disfrutar ms del trabajo. todos los miembros del equipo gil comparten la visin global del estado del proyecto respecto a los objetivos del cliente

Proceso para desarrollo orientado al trabajo en equipo y la aplicacin de las mejores practicas

Entre los aos 1985 y 1986, dos investigadores de origen Japons Hirotaka Takeuchi e Ikujijo Nonaka observaron de una gran cantidad de empresas en Estados Unidos y en Japn la cantidad de ingresos que estas obtenan por nuevos productos e innovacin. Las empresas observadas tenan, como diferencia principal el ciclo de desarrollo; sus fases de construccin se solapaban. Adems, en lugar de tener especialistas en diferentes equipos, muchas de las tareas las llevaban a cabo un solo grupo y en el mismo lugar fsico. A esto se lo denomin Campo de Scrum (Por su similitud con el Rugby). A pesar de estos estudios pasaron aos hasta que, en la dcada de los 90, Ken Schwaber y Jeff Sutherland comenzaron a implementar mtodos similares a los propuestos, siendo este ltimo quien la bautizara Scrum. Ambos autores presentaron, en 1995 durante las conferencias OOPSLA, los primeros artculos que describan esta metodologa.

Scrum presenta ventajas frente a otras metodologas:

Resultados anticipados: gracias a las entregas peridicas con funcionalidad, el cliente puede conocer mejor el estado del proyecto y afirmar sus requisitos o modificarlos sin impactos significativos Gestin del ROI (retorno de inversin): en cada iteracin el cliente dispone de un producto con mayor funcionalidad. En base a esto, plantear el camino a seguir. Cuando el costo de la funcionalidad pendiente sea superior que los beneficios que le aportar, se puede decidir la finalizacin del proyecto. Se obtiene una mayor gestin y un mejor control sobre el retorno de la inversin. Simpleza: la metodologa es muy simple y puede ser aprendida en minutos. Sin embargo, no debemos engaarnos ya que los profesionales que trabajan con Scrum conocen todos los pormenores y alcanzar este nivel de conocimiento lleva mucho tiempo y experiencia en el campo. Normas Claras: generalmente, al tener pocas referencias tcnicas, los equipos que utilizan Scrum se familiarizan rpidamente con la metodologa y con los lmites de sus funciones.

Delegacin: el equipo debe ser libre para gestionarse, organizarse y promover los cambio que crea necesarios para su desarrollo. Respeto: integrar a los profesionales de distintas disciplinas e intentar colaborar en las tareas respetando los puntos de vista dismiles. Responsabilidad: el integrante debe conocer lo que se espera de l y actuar en base a eso. La gestin de equipos tradicional basada en la disciplina puede no ser la ms adecuada para este tipo de desarrollo. Priorizar el Objetivo: la funcionalidad en la cual el equipo trabaja, tiene prioridad y se le asignan los recursos necesarios. Visibilidad: el equipo debe conocer la informacin correspondiente al proyecto, que debe ser fcilmente requerida, localizada y consultada.

Roles, Artefactos y Actividades

La iteracin en corto tiempo es una de las claves del xito

24 h

30 das

Backlog De Producto

Backlog De Sprint

Sprint

Incremento

Product owner (dueo del producto): Es el responsable de

obtener el mximo valor del producto para los clientes y usuarios. El encargado de este rol construye la documentacin respecto de los requisitos iniciales. El dueo del producto es el responsable del product backlog y la representacin del cliente, por lo tanto valorar el proyecto desde esta ptica. Team (el equipo): Los miembros deben operar como una unidad, siendo cada uno importante en su funcin en un momento determinado. Decimos que los equipos transforman el product blocklog en la funcionalidad del producto. Scrum Master: El Scrum Master tiene la responsabilidad de formar y garantizar el funcionamiento de la metodologa a la organizacin, adaptando las prcticas y el personal necesario.
Gestionar la lista de requisitos Participar de las reuniones moderando y ayudando a que todos sean escuchados. Guiar al equipo a lo largo del desarrollo Generar el clima adecuado de trabajo Lidiar con los problemas externos de forma tal que no afecten al ambiente interno

Normalmente los equipos de Scrum no deberan tener ms de diez integrantes Scrum Master Dueo del Producto Miembros Del Equipo

Roles Scrum Usuarios Stakeholders

Scrum tiene tres elementos principales:

Product backlog : Lista de requerimientos ordenadas de acuerdo a las prioridades del cliente. Sprint backlog: Lista de tareas, acciones que se realizaran en el sprint. Burn down: Herramientas de tareas y requisitos pendientes. Incremento: Porcin de desarrollo o incremento del sprint.

Es el reflejo de los deseos del cliente sobre el producto. Similar a la elicitacin de requerimientos. La diferencia radica en que el cliente participa del equipo de desarrollo, y su visin de los requisitos puede ir cambiando a lo largo del desarrollo, cuando el equipo y l mismo comprendan mejor el producto. El primer sprint requiere que se incorpore al product backlog algunos resultados u objetivos esperados por el cliente. Tanto l como el equipo trabajan sobre el documento, siendo primordial que todos compartan la visin.

La cantidad de datos puede adaptarse al proyecto

La informacin mnima requerida es: Identificador nico Descripcin Prioridad Estimaciones Observaciones

Existen herramientas automatizadas como Scrum Desk

Id Orden Esti. Descripcin Desarrollo de Interfaz de usuario Generar estructura de Datos Mdulo de impresin Criterio Validacin Obs.

30

Las pantallas tienen que tener un aspecto similar a la aplicacin actual

La estructura es validada por el DBA

Ninguna

B C

2 3

40 40

Ninguna

Se imprimen reportes en todas las impresoras

Las impresoras pueden estar en redes distintas.

seleccionan las funcionalidades esperadas , que estn expresadas en el product backlog , para poder gestionar las tareas necesarias para poder construirlas. En este documento asignamos Tareas => Aqu se

RRHH

Existen algunas consideraciones para realizar este documento:

Se definen todas las tareas que se van a realizar Las tareas deben tener 16hs Tarea 4hs El equipo completo puede tener acceso a l.

PILA DE SPRINT

Backlog
1 1 1

Tarea
Descripcin de la tarea 1 Descripcin de la tarea 2 Descripcin de la tarea 3

Tipo
Anlisis Prototipado Pruebas

Estado
Terminado Terminado Terminado

1
1 2 2

Descripcin de la tarea 4
Descripcin de la tarea 5 Descripcin de la tarea 6 Descripcin de la tarea 7

Codificacin
Codificacin Pruebas Codificacin

Terminado
Terminado Terminado En Curso

2
3 3 3

Descripcin de la tarea 8
Descripcin de la tarea 9 Descripcin de la tarea 10 Descripcin de la tarea 11

Codificacin
Pruebas Pruebas Codificacin

En Curso
En Curso En Curso Pendiente

Los contenidos mnimos recomendables son:

Identificacin del sprint Identificacin de la tarea Descripcin bsica de la tarea Persona responsable Tiempos Estado

Es aconsejable no limitarse a un formato, sino de buscar generar nuestro propio formato teniendo en cuenta nuestro medio.

Este elemento nos permite conocer los requisitos pendientes al comienzo de cada Sprint y la velocidad a la que se est completando el proyecto. Es una representacin grafica, que conecta Horas

de trabajo pendiente Vs Avance en el proyecto.

En el caso de un aumento o disminucin de los requisitos, la pendiente aumentar o decrecer a pesar de no haberse intervenido en el desarrollo. Este tipo de grfico puede utilizarse para las tareas pendientes dentro de una iteracin.

Avance del Proyecto 200 180 160 140 120 100

80
60

Hs. T Pend.

40
20

0
1-Feb 2-Feb 3-Feb 4-Feb 5-Feb

Incremento

Es la parte resultante del sprint, que debe ser totalmente funcional y entregable al cliente. Es necesario evitar generar sprints para obtener funcionalidad no entregable (normalizacin de tablas, depuracin de bugs, etc).

El incremento es una parte del producto realizada en un sprint y potencialmente entregable, es decir, que se encuentra terminada y probada.

Como en toda metodologa, en Scrum encontramos un conjunto de actividades que deben ser llevadas a cabo en forma ordenada:

Sprint planning (Planificacin del Sprint) Sprint (Seguimiento del Sprint) Scrum daily testing Sprint demostration Restrospective Replanificacin

La planificacin no debe durar ms de un da entre las dos etapas

La planificacin del sprint es la actividad que permite definir y organizar las tareas porpias del sprint que se ejecuta. Las reuniones se dividen en dos partes.
En la primera el cliente presenta la lista de requerimientos(product backlog) en conjunto con el cliente trabajan sobre ella y cierran la lista. En la segunda etapa se confecciona la lista de tareas (sprint backlog) evaluando tiempos y riesgos y asignando tareas y responsabilidades

Informacin necesaria para la reunin

El backlog de producto, en base al cual se planificarn las tareas que se van a desarrollar posteriormente. El producto actual (desarrollado) que se tomar como referencia. Factores que alteren el negocio del cliente.

Una vez finalizada la reunin, el equipo obtendr el backlog del sprint, la duracin del sprint y el objetivo de ste.
Ciclo de Trabajo Seguimiento del Sprint

Planificacin del Sprint

Sprint (15-30 das)

Revisin del Sprint

Incremento

La ejecucin de la iteracin debe durar entre

dos semanas y un mes para ser til en la metodologa.

Debemos tener en cuenta que la minimizacin de los requisitos de trabajo simultneo (WIP, Work In Progress) favorecer la capacidad de organizacin y reaccin del equipo frente a los cambios. Una vez que ha comenzado el sprint no se pueden alterar los requisitos

Funcionalidad

Product backlog

Prioridad

Ciclo de Trabajo (diario)

Sprint (15-60 das)

Sprint backlog

Incremento

Esta reunin no suele pasar de los 15 a 20 minutos, intenta poner a los integrantes del equipo en la misma situacin frente a la informacin del proyecto. Todos deben conocer en qu se est trabajando y cul es el objetivo real de esa tarea. Cada miembro del equipo podr responder:
Qu tareas realic? Qu problemas tuve? Cules son mis tareas pendientes?

Los mtodos para mantener el orden en las tareas puede ir desde las herramientas informticas hasta las notas adhesivas

Es un encuentro informal en el cual se le muestra al cliente los elementos finalizados en la iteracin. Se entrega un incremento de funcionalidad del producto finalizado Este mtodo permite que el cliente pueda tener una idea acerca de los requisitos que l cree faltantes, lo cual permite ser realistas en cuanto al trabajo pendiente.

En este encuentro el cliente intenta aprender sobre los errores y reforzar los aciertos para trasladarlos a la siguiente iteracin. Se evala:
Tiempos asignados a las tareas Dificultades no contempladas Cualquier otra variable que impacte en el proyecto
Tiempo de duracin de esta reunin: 3 a 4 Hs.

Toda iteracin comienza con una replanificacin del proyecto. Esta replanificacin no es traumtica puesto que Scrum minimiza el nmero de objetivos/requisitos en que el equipo trabaja (WIP, Work In Progress). El hecho los requisitos se completen en funcin del valor que aportan al cliente minimiza la probabilidad de que se produzcan grandes cambios en el transcurso del proyecto. Priorizacin de requisitos por valor. Cada iteracin el cliente dispone de unos requisitos completados y replanifica el proyecto en funcin del valor que le aportan los requisitos pendientes respecto del coste de desarrollo que tienen.

Fases de Preparacin, Sprint N

La fase de preparacin supone enfrentar un nuevo proyecto. En general define:

Qu trabajo tcnico se debe realizar en cada fase Cundo se deben generar los productos entregables de cada fase y cmo se revisa, verifica y valida cada producto entregable Quin est involucrado en cada fase Cmo controlar y aprobar cada fase

En Scrum se organizan las reuniones de exposicin y resolucin

Fase 0: Preparacin del Proyecto

Anlisis de la informacin y de los equipos que se van a comunicar

Estudios de campo, Alcances y Limitaciones del Sistema

Determinacin de la Tecnologa a emplear y el medio de interconexin

Los items del Backlog del Producto se estiman en das

ideales.

Queda entonces calcular cuntos das ideales podrn realizar los Miembros Del Equipo De Scrum durante el Sprint. El primer clculo ser simple: multiplicar la cantidad de integrantes por la cantidad de das hbiles del Sprint. Con esto obtendremos la cantidad total de das ideales disponibles para el Sprint.

Por ejemplo, si fuera un Sprint de 15 das y el equipo esta conformado por 4 personas se obtendra: 15 x 4 = 60 das ideales

En la vida real el equipo no se encuentra frente a das ideales por ello tenemos que hacer uso del Factor de Foco

Sprint 1 se puede usar ff(n) = 0,75

Al comenzar, el factor de foco suele estar entre 50% - 80%. A medida que van avanzando los Sprint, se puede tomar el ltimo factor de foco, o mejor an, un promedio de los ltimos 2-3 Sprint. Resumiendo:
ff(n): factor de foco del Sprint n ff(n) = ( ff(n-2) + ff(n-1) ) / 2

Al finalizar el Sprint tendremos ya la velocidad real que tuvo el equipo (sabiendo cuntos items del backlog pudo completar). As, contaremos con dos valores: la velocidad estimada al comienzo del Sprint y la velocidad real al finalizar el Sprint. Esta velocidad real al finalizar el Sprint deber ser la velocidad estimada para el prximo Sprint. A su vez, deber ajustarse el factor de foco para ver su valor real. Este nuevo factor de foco ser til en el caso de que se modifique la cantidad de integrantes del equipo para el siguiente Sprint, para poder recalcular la velocidad del mismo. El nuevo factor de foco ser:
ff(n): velocidad_real_fin_sprint / velocidad_ideal

Ejemplo

Supongamos un proyecto con un Equipo de 4 personas, y una duracin del Sprint de 15 das hbiles (3 semanas).
Para calcular la cantidad de das ideales disponibles durante el Sprint haramos:
4 x 15 = 60

Deberemos luego "achicar" este valor, aplicando un factor de foco. Como estamos comenzando el primer Sprint del proyecto, comenzamores con un factor de foco del 0.75
60 x 0.75 = 45

As, tendremos 45 puntos (o das) para poder tomar items del Backlog del Producto a realizar. Esta ser la velocidad estimada del Sprint

Al finalizar el Sprint podremos entonces ver cul fue la velocidad real del Sprint, en base a la cantidad de items del Backlog del Producto terminados. Por ejemplo: Velocidad estimada al comienzo del Sprint:45 Velocidad real al final del Sprint: 40

Con esto, la velocidad estimada del prxima Sprint deber ajustarse a 40. El nuevo factor de foco ser:

60 x FACTOR_DE_FOCO = 40 FACTOR_DE_FOCO = 40 / 60 FACTOR_DE_FOCO = 0.66

Scrum requiere en sus etapas la estimacin de los items del Backlog del Producto. Scrum por si mismo no especifica qu Tcnicas de Estimacin utilizar.
El Scrum Master puede aplicar otras tcnicas para que l y los miembros del equipo arriben a un estimacin

Claves que nos alertan de peligros en la implementacin

Los equipos de Scrum deben estar conformados por recursos humanos con alta capacitacin, con caractersticas personales que les permitan adaptarse al desarrollo bajo la metodologa. En conjunto con el rea de RRHH debemos buscar gente con mucha seguridad personal, gente lder de s misma, dispuesta a aceptar la responsabilidad por las acciones que realiza y por los resultados que produce, que sabe pedir ayuda sin complejos cuando la necesita y que, adems, se involucra en tareas para fortalecer al equipo, sobre todo en tareas que no son de su responsabilidad, pero que al hacerlas fortalecen al equipo.

Como lo ha sealado el investigador venezolano Dr. Oswaldo Romero Garca, trabajar en equipos es un reto que requiere una disposicin psicolgica particular. El conjunto de disposiciones psicolgicas, se manifiesta a travs de diversas conductas en la interaccin con los compaeros de equipo: respeto y

sensibilidad al dar feedback, humildad al solicitarlo y recibirlo; optimismo en las dificultades; y construccin de las deficiencias en el desempeo ms como retos que como fracasos (Romero garca,
Oswaldo, Cambio Organizacional y Equipos Autodirigidos, Memorias Evemo VII, Ediciones Rogya, Mrida, 1998, pgina: 14). Siempre es conveniente abordar la formacin del equipo incluyendo al rea de Recursos Humanos

El principal riesgo en una reunin se plantea en no poder

comunicarnos

Comunicarnos significa poner algo en comn, compartir algo. La comunicacin implica una comunidad de intereses, conocimientos, creencias y sentimientos y no una va unidireccional Cdigo: Es el conjunto de normas, lenguajes y smbolos empleados que sirven para articular y trasmitir el mensaje, si somos emisores en un proceso de comunicacin deberemos hacer un esfuerzo para adaptarnos al campo de conocimiento y cdigos del receptor Canal: Es el soporte de informacin que acta como lnea de contacto y transferencia a travs del cual se emite el mensaje desde el emisor hasta el receptor.

La confeccin de los documentos y la actualizacin o mantenimiento de ellos depende el tipo de compromiso que se tiene con la metodologa y con el proyecto mismo. Siempre deben seguirse los pasos definidos en la metodologa ya que estos han sido testeados ampliamente en el ambiente real. Si el equipo selecciona otra forma de documentar, no quiere decir que no pueda ser adaptada a Scrum
Product backlog? SCRUM

.?....
Especulacin

Concepto - Visin

Documentados como

Revisin

Ingeniera Requisitos del sistema? Software

Historias de usuarios?

En el estado ideal de aplicacin de la metodologa, los recursos empleados deben estar enfocados completamente en el proyecto. Se debe evitar tener personas trabajando en ms de un proyecto al mismo tiempo. En el caso de que no sea posible que se dediquen a un solo proyecto, es recomendable que las tareas o proyectos que se realicen presenten similitudes, para que el conocimiento y el estado adquirido en uno pueda hacer ms fcil las tareas en otros

Se intenta gestionar en todas las actividades y en cada momento.

Ampliacin descontrolada de caractersticas

Si bien en proyectos donde el cliente no tiene nocin sobre la duracin y costos, es normal que aparezcan requerimientos superfluos. Aparecen listas de requerimientos abultadas que dificultan la gestin obligando a recurrir al cliente con los inconvenientes que esto tiene. En Scrum, los requerimientos parten del product owner pero siempre son comentados y controlados por el equipo.

Obtencin de Requisitos Errneos

Scrum evita los inconvenientes de una mala recoleccin de requisitos, ya que estos son plasmados en el product backlog, que no es determinante. Este documento no se cierra y evoluciona con el proyecto Los ajustes pueden ser paulatinos e incrementales, no teniendo que detener o desperdiciar recursos de desarrollo.

Calidad Insuficiente

La calidad es algo que debemos tener siempre presente y aspirar al buen resultados que debemos mostrar. Que las funcionalidades sean las adecuadas para la presentacin al cliente.
Plazos de Entrega Equivocados

A diferencia de otras metodologas donde los tiempos son impuestos por personas ajenas al desarrollo, para que Scrum tenga xito es el equipo el que define y decide los plazos en base al trabajo y su conocimiento.
Diseo Inadecuado

La continua evaluacin sobre el producto real obliga al equipo a encontrar los problemas de diseo antes de su aumento de funcionalidad. Las revisiones peridicas permiten al equipo relacionarse con el proyecto y las expectativas que tiene el cliente sobre ste.

Desarrollo e Investigacin

Cualquier investigacin que no produzca resultados es daina para el proceso. Es importante que tengamos en cuenta que todas las actividades que realicemos consumirn nuestro tiempo y esto se ver reflejado en los grficos correspondientes, haciendo notoria la falta de orientacin al resultado
Personal Inadecuado

Scrum permite que los equipos se integren correctamente de forma interpersonal por medio de las reuniones que, si son bien dirigidas por el ScrumMaster , pueden ser beneficiosas para los integrantes y su relacin con los dems

Gracias por su tiempo!!! Lic. Bruno Conti brunocontisimon@gmail.com