Hola todos. Vamos a seguir para aprender más sobre las prácticas ágiles en esta sesión.

En la
sesión anterior aprendimos sobre la esencia de Agile, también discutimos el manifiesto ágil, y sus
doce principios. Fuimos en el estudio de la metodología ágil y ágil de los beneficios que tiene para
ofrecer. Tomamos un breve vistazo a Scrum y programación extrema. También se introdujeron en
el modelo de ciclo de vida ágil. Tuvimos una breve descripción de cada una de las fases del ciclo de
vida del modelo Agile.

En esta sesión, vamos a tener una mirada más atenta a lo que sucede en cada una de las fases del
ciclo de vida de ágil. La exploración, la planificación, la iteración, y fases de liberación constituyen
el ciclo de vida de ágil. Estos nombres de fases son, básicamente, tomadas de la programación
extrema.

La agenda de este módulo incluye tomar un vistazo más de cerca el ciclo de vida de Agile,
aprender acerca de las prácticas ágiles, y va sobre dos métodos ágiles. Para empezar, comenzamos
con el Modelo de Ciclo de Vida ágil.

Al final de este módulo usted debería ser capaz de describir las siguientes fases en las ágil:

- Exploración

- Planificación

- La iteración

- Lanzamiento de la producción

A continuación se estudian las prácticas ágiles. Al final de este módulo usted debería ser capaz de
familiarizarse con las prácticas de Agile les gusta:

- Juego de Planificación

- Diario reunión de pie

- Refactoring

- Test Driven Development

- Integración continua

- La programación Par

- Opiniones de iteración

- Retrospective
Para concluir vamos más de dos métodos ágiles, y aprender acerca de las métricas ágiles. Al final
de este módulo usted debería ser capaz de:

- Comparar XP con Scrum

- Enumerar los roles en XP y Scrum

- Entender las métricas ágiles

En la fase de exploración, como hemos visto antes, nos reunimos los requisitos. Nosotros
utilizamos una metáfora como el primer paso para recolección de requisitos o historias. En
nuestras próximas secciones vamos a entender lo que significa metáforas, y cómo ayudar en la
recopilación de historias de usuario. También estudiaremos el concepto de historias de usuario en
algún detalle. Vamos a discutir aspectos tales como constituyentes de una buena historia de
usuario, y la práctica preferida de la asignación de puntos a las historias. También vamos a ver en
las herramientas que se utilizarán en la fase de exploración.

¿Qué es exactamente una metáfora?

Un diccionario define la metáfora como un símbolo o alegoría - algo que se utiliza para describir o
representar otra cosa.

Comenzamos la recolección de historias de usuario con una metáfora, es decir, empezamos con un
ejemplo de un sistema. En este ejemplo se describe el sistema utilizando conceptos muy simples.
La metáfora tiene dos propósitos. La primera es la comunicación. Todos los métodos ágiles citan
explícitamente la "comunicación" como clave para la ejecución del proyecto éxito. La
comunicación implica el intercambio de información acerca del software entre el equipo del
proyecto y con los clientes. El uso de una metáfora es una herramienta poderosa para lograr la
comunicación.

Una segunda razón para usar una metáfora para reunir los requisitos es que desencadena nuevas
ideas y preguntas, por lo tanto, contribuir a los esfuerzos del equipo de desarrollo de software.
Dado que tanto los clientes y desarrolladores por igual el uso de la metáfora para aclarar el
proyecto, una buena metáfora debe ser fácilmente comprensible para los clientes, pero tienen
suficiente contenido para que pueda guiar el desarrollo de la arquitectura.

Aquí es un escenario. Examine cuidadosamente y encontrar una solución.

Dos personas, Lisa y Alice estaban teniendo una discusión con respecto a lo que el uso de una
metáfora significaba en la recopilación de requisitos. Aquí es lo que tenían que decir acerca de lo
que significa una metáfora. Quien está de acuerdo con?

Haga clic en la llamada que confirme su elección.

En la continuación de la conversación anterior, Lisa y Alice siguen debatiendo sobre el uso de
metáforas. Quien está de acuerdo con?

En fase de exploración las actividades involucradas están reuniendo los requisitos, obtención,
análisis de viabilidad y la preparación de la cartera de producto en términos de tarjetas de historia
o épica. La cartera de productos es un conjunto de requisitos que se espera que sean cumplidas
por el proyecto ágil a través de una serie de iteraciones.

¿Qué es una historia de usuario? Una historia de usuario es una definición muy alto nivel de un
requisito que contiene información suficiente para estimar, desarrollar y probarlo. Una historia de
usuario debe poder aplicarse en una sola iteración - si no el requisito se descompone en pequeñas
historias.

El formato de la historia de usuario se da como en la imagen. La historia de usuario debe contener

los detalles de quién lo necesita, lo que se necesita y por qué lo necesitan.

Tomemos un ejemplo sencillo de una aplicación relativo a la reserva de salas de conferencia en

una organización. Aquí tendrá requisitos que pueden leer de la siguiente manera:

Como usuario final, quiero reservar una sala de conferencias para una reunión.

Como usuario final, yo quiero ser capaz de cancelar la reserva de las salas de conferencias que
había reservado para que otros puedan utilizarlas.

Como usuario final, quiero ver los detalles de una sala de conferencias elegido para que pueda
evaluar si satisface mis necesidades.

Como usuario final, quiero ver todas las salas de conferencias que están libres en una fecha y hora
específica para que pueda elegir uno para reserva.

Como usuario final, quiero ver que ha reservado las salas de conferencias en un lugar determinado
en una fecha y hora específica para que pueda ponerse en contacto con la persona si surge la
necesidad.

Como administrador, quiero añadir más salas de conferencias a la base de datos para mantener la
lista actualizada.

Como administrador, quiero eliminar algunas salas de conferencias de la base de datos para
mantener la lista actualizada.

Como administrador, quiero actualizar los datos de sesión en la base de datos cada vez que
cambian los detalles.
Como se puede ver, cada uno de estos estados se describe lo que se requiere que el sistema en su
conjunto a hacer.

Es posible hacer la pregunta. En caso de que las historias de usuario siempre será una línea de
declaraciones como las descritas? Idealmente Sí, es necesario crear historias de usuario de una
manera sencilla mediante una línea de declaraciones. Sin embargo, las historias de usuario no son
el final de la documentación. Podría ser aumentado con otros documentos tales como capturas de
pantalla, casos de uso, alambre de marcos, etc.

Ve en la pantalla es un ejemplo sencillo de una historia de usuario, que describe un requerimiento

del usuario. historias de usuario deben tener lugar los titulares de prioridad, que será otorgado
por el cliente. La prioridad podría ser en una escala de 1 a 5 - 5 es el más alto, o podría ser en
términos de alta, media, baja o muy importante, importante, es agradable tener y así
sucesivamente. Es necesario tener un criterio de aceptación y prueba de aceptación junto con
cada historia. Esto ayuda en la elaboración del “una línea” historia, ofrece una forma de
documentar los requisitos y dirige el desarrollo en la dirección correcta.

Historias de usuarios también necesitan un marcador de posición para registrar las estimaciones
de alto nivel - que normalmente se concede durante el proceso de planificación de entregas. Las
historias generalmente se miden en términos de puntos de la historia. Un punto de la historia es
un número que refleja el tamaño y la complejidad de la historia - también llamada la “grandeza”
de la historia.

Se asignan puntos de la historia de una manera sencilla - al jugar una partida de póquer. Vamos a
través de esta sección con la analogía de un juego de póquer.

Usted tiene un montón de requisitos. El equipo recoge un requisito - normalmente el que tiene
mediana complejidad, y asigna puntos de la historia a la misma. Digamos que se le asigna 8
puntos. Posteriormente, el equipo comienza la asignación de puntos de la historia a las historias
restantes sobre la base de cuán simple o complejo que es cuando se compara con el que tiene un
punto de 8 pisos.

Una historia más simple podría ser asignado a 5 ó 3 puntos de la historia mientras que un
complejo podría ser asignado 13 o más. Todo el equipo lee la historia y elabora sus propios puntos
- que luego discuten las discrepancias hasta que llegan a un consenso. Nos detendremos aquí en
esto como las historias de usuario y la estimación merece una ranura de entrenamiento
completamente diferente. Aunque la forma de asignar puntos de la historia no es muy científico
que le da una vista de alto nivel de la clase de historias que están en la pila.

Usted debe recordar que no tiene puntos de la historia de los rangos varían, tales como de 1 a 10,
1 a 20. Esto no es bueno porque cuando se usan números secuenciales, sería muy difícil
diferenciar una historia de talla 16 y 17 - el equipo podría entrar en discusiones sin fin sobre la
asignación de estos puntos. Lo mejor sería usar serie de Fibonacci modificado como 1, 2, 3, 5, 8, 13
y 20 a grado de la historia. serie de Fibonacci están bien separados y por lo tanto más fáciles de
distinguir. Por muy pequeñas historias, se podría asignar un punto de ½ historia. Si la historia es
más grande que 20 puntos, es una indicación de dividir la historia de múltiples historias más
pequeñas.

Las buenas historias de usuario se deben adherir a invertir. Las historias tienen que ser
independientes entre sí para facilitar la priorización y planificación. Por ejemplo, echemos un
vistazo a la historia "Como usuario, puedo buscar boletos de avión con base en fechas específicas,
tarifas, marca las líneas aéreas y calificación de calidad" - se hace difícil dar prioridad a una
historia. El incumplimiento de esta en historias individuales más pequeñas para la búsqueda de
cada 1 o 2 campos será más fácil de establecer prioridades.

Las historias deben ser negociables - lo que significaría que necesita tener el margen de maniobra
para aumentar la exigencia en una fecha posterior, y no es una parte de un contrato rígido como
tal. Se lo mencionamos, en la sesión 1 que en los requisitos ágiles son sólo factores
desencadenantes de interacción con el cliente. En ese sentido, las historias no están destinados a
tener todos los detalles de la exigencia - una cierta flexibilidad de la cantidad que se necesita
aplicar.

Las historias por sí mismos cuando implementadas deben ser de valor para el usuario final y / o
cliente. Hay momentos en que tenemos que escribir historias que no son valiosos para el usuario
final, sino que tienen que ser tratados. Veamos lo que esto significa, tomando un ejemplo.
Supongamos que necesita para crear una tabla con un cierto número de campos. Esta historia en
particular puede no tener ningún sentido para el usuario final. Sin embargo, si esta historia no está
implementado, las otras historias no se pueden tomar hacia adelante e implementadas. Estas
historias se llaman historias técnicos. Usted puede tener uno o dos pisos técnicos en su cubierta
requisitos. Mantenerlos al mínimo, ya que proporcionan ningún valor para el usuario final o
cliente.

Usted debe ser capaz de estimar el tiempo requerido para implementar las historias. Puede no ser
capaz de estimar si usted no tiene el dominio requerido y conocimiento técnico o si la historia es
demasiado grande. En caso de falta de conocimiento, que necesita para obtener los conocimientos
necesarios a través de la formación, el aprendizaje de los demás, auto-lectura, etc. En caso de que
la historia es demasiado grande, tiene que ser desglosado a estimatable tamaño.

La historia debe ser de tamaño adecuado; lo que significa que no debe ser ni demasiado pequeño
ni demasiado grande. Aunque es extremadamente pequeñas historias pueden no sumar valor al
usuario final, las grandes historias son difíciles de estimar y de prueba. Las historias que se
ejecutarán en un futuro próximo tienen que ser lo suficientemente pequeño como para caber en
una iteración - donde como grandes historias pueden ser mantenidos en la cartera de pedidos sin
romper hacia abajo hasta que se toman para la aplicación.

Por último, debe ser capaz de probar las historias. Prueba demuestra que la historia cumple con
las expectativas del cliente. Por ejemplo, la historia de usuario “Los privilegios de acceso, debe
establecerse” no da una clara indicación de que el desarrollador y probador. Esto necesita ser
aumentada con detalles apropiados de las diferentes funciones y los privilegios de acceso para los
diferentes roles.

A continuación se enumeran las herramientas utilizadas en la fase de exploración. Estas

herramientas ayudan en la gestión de requisitos. También hay un conjunto común de
herramientas que se utilizan en todas las fases del ciclo de vida ágil que se utilizan para establecer
la comunicación entre los miembros del equipo y entre el equipo y el cliente.

Historias de usuarios necesitan adherirse a invertir. ¿Qué significa invertir?

Seleccione la opción apropiada y haga clic en Enviar.

Recapitulemos lo que hemos aprendido ahora.

En la fase de exploración:

- Nos hemos reunido los requisitos.

- Las metáforas se utilizan como el primer paso en la recopilación de requisitos o historias.

- Las buenas metáforas deben ser comprensibles para los clientes y deben tener un contenido
suficiente para el desarrollo de arquitectura.

- Una historia de usuario es una definición muy alto nivel de un requisito que contiene
información suficiente para estimar, desarrollar y probarlo.

- Historias de usuarios deben tener lugar los titulares para prioritarias, criterios de aceptación y las
estimaciones de alto nivel. prueba de aceptación también debe estar presente junto con cada
historia.

- El equipo de desarrollo asigna puntos a las historias de usuario en función de su nivel de

complejidad.

- Historias de usuarios necesitan adherirse a INVEST - que debe ser independiente, negociable,
valioso, estimatable, del tamaño adecuado y comprobable.

- Durante la fase de exploración, se podrían utilizar herramientas de gestión de requisitos, tales

como óptima Trace, Puertas, RequisitPro y CaliberRM.

Una vez que haya reunido suficientes historias que pueden justificar una versión de producción, se
inicia la planificación de la liberación. A identificar el conjunto mínimo de historias que usted
desee implementar en la primera versión y versiones posteriores. ¿Cómo se hace esto?

Durante la liberación de la planificación de las historias tienen prioridad, se estima el esfuerzo

necesario y el tiempo de comercialización que se decida. Herramientas tales como DSM se utilizan
en la planificación de la liberación.
El cliente da prioridad a las historias. Las prioridades pueden ser en términos como "alta, media,
baja", "sin duda necesario, necesario, es agradable tener" o sólo números con los números más
altos indican mayor prioridad. La responsabilidad de estimar el esfuerzo para poner en práctica las
historias se apoya en el equipo del proyecto. Una vez que el establecimiento de prioridades y la
estimación se hacen, la necesidad del cliente para ir al mercado el tiempo de que se decida, y una
fecha de lanzamiento tentativa se llega a.

¿Por qué el equipo de desarrollo también dar a sus estimaciones, no es la voz del cliente la
llamada final? Esto se debe al hecho de que más a menudo los clientes pueden no ser conscientes
de la complejidad técnica de la tarea en cuestión. Ellos son los mejor equipados para proporcionar
la prioridad, ya que tienen una visión sobre las necesidades de negocio. Agilistas creen que las
estimaciones deben provenir de las personas que están realmente involucrados en hacer el
trabajo. Ellos entienden las complejidades técnicas y están mejor equipados para proporcionar las
estimaciones.

Hay que señalar que a veces una historia de alta prioridad no se puede implementar sin la
aplicación de una historia de baja prioridad debido a las dependencias. Sería aconsejable utilizar la
matriz de la estructura de dependencias, una herramienta propagado como parte de la iniciativa
de Lean de Wipro, para identificar las dependencias y la secuencia de historias.

Consulte la VelociQ para más detalles sobre el DSM.

Aparte de DSM, utilizamos otras herramientas durante la fase de planificación, que se enumeran
en la tabla de aquí. También se enumeran las herramientas de comunicación que son comunes en
todas las fases.

Ves las siguientes ventajas en la planificación de entregas:

- Todas las partes interesadas del proyecto de obtener una visión clara de las características que
se implementarán para la próxima versión.

- Objetivos de la versión quedar identificados y establecidos.

Acabamos de discutir acerca de la fase de planificación de entregas. ¿Qué hemos aprendido?

Hemos aprendido que en la fase de planificación de entregas, el cliente prioriza las historias en
términos de alta, media o baja complejidad. El equipo de desarrollo estima el esfuerzo necesario
para poner en práctica las historias. Después de estas dos actividades se llevan a cabo, la
necesidad del cliente para ir al mercado el tiempo de que se decida. El conjunto mínimo de
historias para ser implementado son identificados, a continuación, la fecha de lanzamiento está
fijada.

Una vez que se realiza la planificación de entregas, a continuación, el equipo planea para la
iteración o Sprint - esto se hace al comienzo de cada iteración.
Iteración 0 implique actividades relacionadas con la configuración básica para permitir la ejecución
del proyecto. Las principales actividades realizadas en esta fase incluyen:

- configuración de la infraestructura para el desarrollo y pruebas

- Identificar y establecer las herramientas requisito para el desarrollo y pruebas

- Capacitación del equipo (en el modelo de proceso, aspectos técnicos, herramientas, etc.)

- Definición de la arquitectura o de alto nivel de diseño

- Al llegar a la estrategia de pruebas, pruebas de enfoque, el alcance de la prueba y la prueba del

plan

- Estudio de los criterios de aplicación y aceptación del proyecto por todo el equipo

- Definir el plan de construcción y despliegue

La duración y el período de solapamiento de la iteración 0 con respecto a la fase de exploración y

la planificación pueden variar dependiendo de la complejidad del proyecto.

Los principales parámetros de esta fase son: Cartera Aprobado y priorizada del producto, plan de
Herramientas, y el Plan de Formación.

Las salidas principales de esta fase son: Entornos de desarrollo en pleno funcionamiento y de
prueba, Estrategia y Plan de prueba, Arquitectura de documento, construir y plan de despliegue.

La ejecución exitosa de la iteración 0 es crítico para el éxito de los demás iteraciones.

En la fase de iteración,

- La planificación de Sprint o de la reunión de planificación de iteración se lleva a cabo, en las

historias de alta prioridad se seleccionan para su implementación.

- se implementan Las historias identificadas. El progreso se hace un seguimiento sobre una base
diaria. Hay algunas buenas prácticas que el equipo tiene que ser siguiente durante la ejecución.

- Al final de la revisión del sprint, se da la demostración para el cliente y se busca la

retroalimentación. El equipo también tiene una reunión retrospectiva en la que las lecciones
aprendidas, se discuten las mejores prácticas y métricas. Utilizamos ciertas herramientas en la fase
de iteración para facilitar la implementación y el seguimiento.

Vamos a discutir todos estos aspectos que acabamos de describir en nuestras próximas secciones.
En la reunión de planificación de Sprint, todas las partes interesadas, como los desarrolladores,
testers, analistas de negocios, gerentes, los clientes deben estar presentes.

De las historias previstas para la liberación, historias de alta prioridad son elegidos para la
iteración. Las historias recogidas para la iteración o Sprint formar el sprint backlog. Debe tenerse
en cuenta que las historias son recogidos por el equipo de desarrollo y no por los administradores
o clientes.

Los usuarios, clientes o analistas de negocios elaborarán estas historias de usuario a un mayor
detalle, si no lo ha hecho. Usted podría tener un registro de todas las cosas discutidas durante la
reunión sobre un documento, voz o vídeo - de modo que pudiera ser referido más adelante
durante la ejecución. Algunas veces estas dos actividades se llevan a cabo en una reunión previa a
la planificación hacia el final de la iteración anterior. Esto es especialmente útil en el caso de los
equipos distribuidos de manera que la reunión de planificación de iteración no toma demasiado
tiempo.

Durante la planificación de la iteración, los desarrolladores y probadores rompen las historias

seleccionadas en tareas más granulares. Es necesario tener cuidado de que la ruptura tarea es tan
granular como puede ser, por lo que una sola tarea no debe tardar más de un día para poner en
práctica. Las tareas se planifican de tal manera que mientras el equipo de desarrollo es la
codificación, el equipo de pruebas crea las pruebas requeridas para ponerlos a prueba.

Normalmente las iteraciones son el tiempo en caja a misma duración - entre 1 a 4 semanas. A
veces esto tendrá que ser cambiado en base a las historias seleccionadas para la iteración. En tales
casos, el equipo en su conjunto decide sobre una fecha límite para la iteración. También es
necesario velar por que las tareas se distribuyen de manera uniforme a los miembros del equipo, y
ningún miembro es o estresado con el trabajo, o tiene muy poco trabajo a la mano. Si se va a tener
algo más de tiempo, el plan para poner en práctica algunas de las historias de baja prioridad.

Los siguientes son los beneficios de la planificación de iteración:

- Las estimaciones son precisas ya que se han identificado y estimado tareas granulares.

- El equipo de desarrollo y equipo de pruebas es claro en las tareas a la mano.

- El cliente es consciente de la portería iteración.

- La falta de claridad sobre las historias se emergió - para que el cliente / empresa puede obtener
más detalles y completar la historia.

¿Qué hemos aprendido hasta aquí? Hemos aprendido que:

- Durante la planificación de la iteración, los desarrolladores, testers, analistas de negocios,

gerentes, clientes participan en la reunión de planificación.
- A partir de las historias planeadas para el lanzamiento, historias de alta prioridad son elegidos
para la iteración - estos forman el sprint backlog.

- Las historias seleccionadas se descomponen en tareas granulares.

- Las tareas se planifican para que el desarrollo y las pruebas se llevan a cabo en paralelo.

- duración de la iteración es típicamente 1 - 4 semanas.

Una vez que han llegado a las tareas y las estimaciones, usted y su equipo empezar a aplicar las
tareas. Ahora ¿cómo realizar un seguimiento de su progreso en la ejecución de las tareas? Uno de
los métodos es el Daily reunión de pie. reuniones de stand-up se llaman así porque todos los
miembros del equipo necesitan ponerse de pie mientras se discute su respectivo estado de
trabajo. Tienen que estar alerta, centrado, y terminar la reunión en un corto espacio de tiempo, no
más de 15 minutos. Usted tiene que asegurarse de que el equipo se reúne todos los días a una
hora determinada.

Cada persona, entonces se analiza lo siguiente:

¿Qué he hecho desde la última reunión de pie?

¿Qué voy a hacer antes de la próxima reunión de pie?

¿Hay problemas o impedimentos que están obstaculizando el progreso de la implementación?

Esto podría ser aumentado con algunas otras preguntas, en función de las necesidades del
proyecto.

Las preguntas que se podrían añadir son:

- ¿Hay nuevas tareas que tienen que ser añadido al plan y dirigida? A veces llega a ser difícil hacer
un seguimiento de todas las tareas que deben ser manejados. Por lo tanto se hace una verificación
cruzada para asegurar que ninguna de las tareas programadas para el ciclo iterativo se perdió.

- ¿Has aprendido algo nuevo, mientras que la aplicación de las tareas? La reunión de pie es el foro
ideal para discutir las lecciones aprendidas y las mejores prácticas, para que todo el equipo pueda
beneficiarse de las experiencias de los demás.

Lo ideal sería que la reunión de pie, no debe exceder los 15 minutos. Debe tener en cuenta que es
necesario que haya no más de 7 a 11 miembros en este tipo de reuniones de pie. Si tiene equipos
más grandes, romper el equipo de scrum en equipos más pequeños para asegurar que la reunión
tiene una duración de sólo 15 minutos. En ese caso, sería necesaria una avalancha de reunión
scrum. Los representantes de cada equipo scrum participan en scrum de los scrums y resolver las
dependencias e impedimentos entre los equipos.
No hable de soluciones a los problemas técnicos de la reunión de pie. Organizar un scrum técnica
para cuestiones técnicas que el equipo puede hacer frente. Todas las partes interesadas del
proyecto, incluyendo el cliente, pueden participar en la reunión diaria de pie. Los desarrolladores y
los que contribuyen a la implementación de las tareas discutirán el estado de su trabajo. El papel
de todos los demás, si es invitado, es observar y escuchar. Los riesgos / problemas / obstáculos
identificados durante la reunión de pie debe ser abordado en la máxima prioridad. En los casos en
que la solución a la relación riesgo / tema identificado requiere más tiempo, entonces esto puede
convertirse en una entrada para descoping la historia correspondiente.

Puede utilizar una herramienta, como el control visual, para el seguimiento y la supervisión del
progreso del proyecto. Mira a la pantalla. Verá que el control visual aquí simplemente muestra el
estado de trabajo del equipo.

La primera columna tiene una lista de historias aún no se ha iniciado. A medida que se desarrolla
el relato, que se desplaza a las respectivas columnas. La herramienta de control visual se actualiza
en función de la información recibida de la reunión Stand-Up diario. Control Visual es en realidad
un tablero visual que indica claramente el estado del proyecto.

En los proyectos, el seguimiento de esfuerzo real es importante, ya que indica la forma exacta que
ha sido en subir con las estimaciones. Cuando es necesario evaluar si se puede completar las
tareas dentro del tiempo estipulado, lo que es importante es estimar el esfuerzo restante
necesario para completar la tarea.

En tales casos, el equipo ágil traza el esfuerzo restante en el esfuerzo quemar la carta. En el gráfico
en la pantalla, se ve una línea continua azul que representa la espera incendiar días sabia. La línea
rosa indica la quemadura real hacia abajo o el esfuerzo que queda al final de cada día. Si la línea
rosa está por encima de la línea azul, es necesario tomar medidas, como las horas extraordinarias
de trabajo, descope ciertos requisitos y así sucesivamente. Se toman medidas para asegurarse de
que la iteración se completa dentro del tiempo estipulado.

Hemos aprendido que durante las reuniones diarias Stand-up:

- se realiza un seguimiento del progreso de la ejecución de las tareas.

- El estado de la tarea actual en la mano, se discute la siguiente tarea que deben abordarse.

También se identificaron los problemas que impiden el avance de los trabajos -.

- no se discuten cuestiones técnicas.

- En caso de equipos más grandes, scrum de reuniones scrum se llevan a cabo.

- El seguimiento y la supervisión del progreso del proyecto se realiza utilizando una herramienta -
el control visual.
 - el esfuerzo real y el esfuerzo restante son dos parámetros importantes que deben ser
rastreados.

Ahora que hemos entendido lo que la planificación y el seguimiento son todos acerca, vamos a ver
lo que planean para los equipos ágiles. Agilistas creen en la planificación de lanzamientos cortos.
Que necesita para obtener una pieza de trabajo de software a cabo después de cada ciclo
iterativo. Asegúrese de que se trata de una pieza completamente de trabajo - un producto
potencialmente entregable Incremento (PSPI).

Salida de cada iteración no puede ser liberado a la producción - sin embargo, debe ser un código
de lista de producción que deben pasar las pruebas de aceptación. Cada versión debe ser
planificada para dar al cliente el máximo valor de negocio.

comunicados más cortos ayudan a refinar los requisitos de los usuarios - muchas veces los clientes
necesitan ver un producto de trabajo para cristalizar los requisitos. El beneficio que se acumula
desde versiones más cortas es que el cliente ve el producto crezca de forma incremental - lo que
aumenta la confianza de los clientes en el equipo del proyecto. El equipo de desarrollo en vez
beneficia al obtener una retroalimentación constante por parte del cliente. Los resultados rápidos
y continuos explican en que se logra a través de comunicados cortos parte-1 de la sesión ágil.

El equipo tiene que trabajar a un ritmo sostenible. También es necesario para mantener el ritmo
de juego del equipo hasta el final del proyecto. El equipo tiene que ser capaz de mantener un nivel
uniforme y de alta energía durante todo el transcurso del proyecto.

Una buena planificación puede evitar que los equipos de horas extraordinarias de trabajo.
También podría evitar que los miembros del equipo de malgastando un tiempo precioso.

Si el equipo está estiramiento excesivo para cumplir con los objetivos de iteración o el equipo
pierde los objetivos de iteración, a pesar de un estiramiento excesivo, entonces el problema
necesita un profundo pensamiento. Si el equipo es incapaz de lograr ritmo sostenible para 2
iteraciones consecutivas, entonces la planificación de la iteración debe ser re-parecía. Las
estimaciones tendrán que ser reforzada o más memoria intermedia tiene que ser planificado para
que el equipo tiene un ritmo sostenible y todavía es capaz de alcanzar las metas de iteración.

Los beneficios que se derivan de mantener un ritmo uniforme son:

- El equipo trabaja con niveles de energía uniforme - que aumenta la motivación del equipo.

- El equipo estará dispuesto a hacer un esfuerzo extra en tiempos de crisis.

- nivelación de carga delegación adecuada, justa y uniforme de trabajo está asegurada.

Después de haber planeado para las versiones cortas y ritmo sostenible, que tendrá que centrarse
en las prácticas de ingeniería que ayuda en la consecución de este. Veamos primero en el proceso
de diseño.

tensiones ágiles en tener un diseño simple. Esta es la práctica del diseño de las funcionalidades de
la manera más sencilla posible que funcione. Mantener las cosas lo más simple posible, practicar
lo suficiente. Se medios de codificación para los requisitos especificados y no agregar
funcionalidad a menos que sea necesario por el cliente / empresa / usuario. tensiones ágiles en un
diseño simple / código limpio restringido a la iteración actual en lugar de especular cambios y
proporcionar una gran cantidad de ganchos de extensibilidad y plug-ins. Sin embargo, tiene que
ser flexible y debe ser capaz de absorber algunos cambios en el futuro.

El diseño / código debe centrarse en ser comprensible para los destinatarios previstos en lugar de
lo que es brillante y elegante. El diseño / código debe ser comunicativo para sus lectores y las
principales decisiones de diseño se deben documentar en el final de la iteración.

Es necesario comprender y seguir conceptos como KISS (Keep It Simple Stupid, o que sea breve y
simple), YAGNI (No vas a lo necesitan) y DRY (Do not Repeat Yourself).

El objetivo final es que el código en sí mismo debe ser tan simple y fácil de entender y no debe
necesitar documentación adicional.

Los beneficios de diseño simple es que el diseño es fácil de extender y fácil de probar.

Para recapitular lo que hemos aprendido hasta aquí:

- agilistas plan de lanzamientos cortos. La salida de cada ciclo iterativo debe ser una pieza de
trabajo de software y una versión lista para producción.

- El equipo ágil debe trabajar a un ritmo sostenible.

- Si el equipo sobre-extiende a cumplir los objetivos de iteración, entonces el proceso de

planificación de la iteración se debe volver a mirar.

- Agile subraya en el diseño simple, que es flexible y susceptibles de modificación.

llamadas ágiles para la refactorización del código constantemente. Refactorización es el proceso

de mejorar y aumentar la calidad del código, sin afectar la funcionalidad. Una sección de código de
ejemplo se muestra en la pantalla, que representa cómo el código se ha mejorado y mejorado
durante refactorización. Por refactorización, la calidad del código mejora la iteración en iteración y
malos efectos de diseño simple se anulan. Mientras Refactoring, tenemos que entender y poner
en práctica técnicas para obtener más abstracción, romper el código en trozos más lógicas y
mejorar nombres y ubicación de código. Un método para activar la refactorización es medir la
calidad del código usando las herramientas apropiadas y refactorizar el código cuando se alcanzan
ciertos umbrales.
Refactorización mejora el diseño interno de su aplicación, reduce la duplicación de código con
objeto de optimizar la mantenibilidad y la analizabilidad. También reduce los costes y riesgos de
desarrollo en comparación con un esfuerzo de aplicación completa reescritura.

Después de diseño, otros ciclos de vida hablan de codificación. Sin embargo, en ágil, de empezar a
escribir pruebas. Ágil recomienda Test Driven Development - también llamado como “Prueba
Primer Código Siguiente”.

En el desarrollo basado en pruebas, también llamado como prueba Primer Código A continuación,
se sigue un proceso de cuatro pasos - primero escribir la prueba, a continuación, ejecutar las
pruebas. Si la prueba fracasaría se escribe simplemente suficiente código, para pasar la prueba. En
el último paso, que refactorizar el código para garantizar que se abordan los requisitos no
funcionales.

la totalidad del producto de desarrollo de repetir la secuencia de etapas de las pruebas de

escritura, ejecución, codificación y refactorización en ciclos cortos. Agilistas sugieren que cada
ciclo debe tener menos de 15 minutos. La limitación del ciclo de desarrollo basado en pruebas de
15 minutos es un ejercicio difícil y requiere mucha práctica; con el tiempo, se puede lograr. En
cada ciclo, es necesario asegurarse de que pruebe toda su base de código, antes de ir al siguiente
ciclo. Esto significa 100% del código siempre debe ser probado unidad para cada registro de
entrada.

¿Qué ocurre con el código refactorizado? Una vez que se hayan completado los cuatro pasos, se
registre el código para una construcción integrada y una unidad de pruebas del 100%. La mejor
manera de lograrlo es mediante la automatización del proceso, ya que tiene que ser repetido una
y otra vez.

Si usted tiene casos de prueba manuales, todo el proceso se va a requerir mucho esfuerzo, y
propenso a errores. Por lo tanto, hacer uso de las herramientas de pruebas unitarias como JUnit,
NUnit, la prueba de puntos, prueba de CPP y así sucesivamente. No aseguran que por cada
cambio, todos los casos de prueba se ejecutan correctamente.

¿Cuáles son los beneficios de este proceso de desarrollo basado en pruebas?

- Usted está obligado a crear el diseño y el código de acuerdo a la perspectiva del usuario.

- Se puede trabajar en paz ya que no puede afectar el trabajo de su miembro del equipo, como
usted ha probado el 100% de su código antes de la llegada.

- También se sabe que el trabajo de los otros miembros del equipo no tiene impacto en su
trabajo, ya que también se han puesto a prueba el 100% de su código.
- También puede utilizar los casos de prueba como parte de la documentación de la funcionalidad.
El código debe ser lo suficientemente simple para servir como parte de la documentación si es
necesario.

- En cualquier momento del tiempo existe un código limpio que funciona.

- También ayuda en la codificación sólo lo que se requiere.

- Respuesta instantánea trae el entusiasmo y la satisfacción con el desarrollador y por lo tanto un

profundo efecto en la productividad, la calidad y el trabajo en equipo.

Para resumir lo que hemos aprendido:

- Refactoring es el proceso de mejorar y aumentar la calidad del código, sin afectar la

funcionalidad.

- Las cuatro fases de TDD están "Piense en lo que está por hacer, proceder con barra roja que es
escribir y ejecutar pruebas unitarias - pruebas fallarán, pasar a barra verde que es escribir código
suficiente para pasar la prueba y finalmente Refactor.

- Una vez refactorizado, el código se somete a prueba de la unidad 100% antes de cada uno en el
registro de entrada.

Colocar las actividades en el orden correcto, en la figura se muestra. Haga clic en Enviar al finalizar
el ejercicio.

Ahora introducimos el concepto de par-programación - que normalmente se siguió durante la

codificación. Este es un concepto único para la programación extrema.

La programación en parejas es una práctica en la que dos desarrolladores trabajan lado a lado. El
dos de ellos trabajan en conjunto sobre el mismo diseño, algoritmos, códigos o casos de prueba.

A una persona - el conductor - controla los códigos de teclado y, de hecho y prueba la

funcionalidad requerida con un enfoque principal en los problemas operativos que intervienen
durante la codificación. La otra persona - el navegador - observa continuamente el trabajo del
conductor y se centra en la identificación de defectos tácticos y también piensa estratégicamente
sobre la dirección de la obra. El navegador tiene un papel activo durante la refactorización.
También se asegura de que todas las pruebas requeridas están disponibles. El navegador también
se encarga de que apenas suficiente código está escrito para pasar la prueba.

Las funciones de conductor y navegante no son fijas - cambian periódicamente las funciones,
según sea necesario. Con frecuencia una lluvia de ideas sobre cualquier reto problemas, riesgos o
diseño. Los programadores no están obligados a trabajar juntos por el proyecto en su totalidad,
iteración o una historia. Sólo funcionan juntos por toda la longitud de una tarea. Cuando una
pareja se ha quedado atascado y con necesidad de una nueva perspectiva, ellos se separan y se
conmutan socios. Recuerde que los programadores no deben ser obligados a trabajar juntos; la
necesidad de trabajar juntos debe ser voluntaria, dependiendo de las necesidades del proyecto.

Veamos lo que los beneficios de la programación en parejas son:

- Par de programación ayuda a tener la revisión de código constante y refinamiento. Puesto que
usted tiene el navegador de revisar constantemente el trabajo del conductor, hay menos
posibilidades de errores en el código.

- El conocimiento perteneciente al código se distribuye uniformemente entre los miembros del

equipo. Que son capaces de evitar situaciones causando cuellos de botella en el desarrollo del
proyecto como una sola persona cae enferma o se va de vacaciones.

- Par de programación ofrece una buena plataforma para el intercambio de conocimientos

técnicos. Jóvenes tienen la ventaja de ser tutelado por las personas mayores, y hay un equilibrio
de talento en todo el equipo.

- Par de programación es mucho más rápido y mejor que la programación individual. Hace cumplir
los buenos hábitos de programación y produce código de alta calidad.

- Las distracciones que interrumpen el pensamiento, los procesos y flujo de trabajo se reducen al
mínimo.

Es posible hacer las preguntas - no es tener dos personas trabajan en una tarea particular una
sobrecarga? Si una sola persona puede hacerse cargo de la codificación, ¿por qué es necesario
contar con dos personas trabajando en él?

Martin Fowler, uno de los firmantes del manifiesto ágil dijo con razón - "La programación en
parejas es una sobrecarga si tuviera que tener en cuenta que el único papel de los desarrolladores
es que escribir código Sin embargo, como hemos visto, una gran cantidad de pensamiento. entra
en el proceso de codificación. Esta es la programación en parejas, donde resulta beneficioso, en
donde se tienen dos personas cuyas ideas se agruparon para dar mayores beneficios ".

Tenga en cuenta que la programación en parejas es seguido sólo cuando el equipo encuentra la
necesidad de la misma.

¿Dónde cree que la programación en parejas demuestra un activo?

Lo ideal sería que el emparejamiento se ha de hacer para todos pieza de trabajo que necesita ser
mantenida. La programación en parejas, mientras que sí ayuda a la implementación de tareas que
son críticos para el proyecto. También ayuda cuando se tiene que codificar componentes
reutilizables. Es necesario hacer frente a preguntas como “¿Cuándo emparejar, cómo emparejar?”
Antes de emprender la práctica. Cuando no se puede practicar la programación en parejas 100%
de las veces, es necesario aumentar el número de comentarios el código pasa a través de todos los
días.
La idea principal es reducir los residuos en términos de retrabajo y reducir el inventario.

los estándares de codificación son el conjunto común de normas elaboradas a partir de los
mejores estilos de codificación. los estándares de codificación nos dan algunas ventajas: Hacen
que sea fácil de leer el código de la otra y por lo tanto cualquier persona puede hacer cambios. Los
nuevos miembros serían capaces de producir el mismo código de calidad que sus predecesores. Es
imprescindible que usted tiene los estándares de codificación para un proyecto ágil, ya que
proporciona una plataforma para otras prácticas como el desarrollo basado en pruebas, la
programación en parejas, refactorización y la propiedad colectiva.

A continuación vamos a entender el concepto de propiedad colectiva. Este concepto central de

Agile afirma que todo el mundo es responsable de todo el sistema, y que cualquier persona tiene
la libertad de cambiar de código. No puede haber un solo propietario para cualquier pieza de
código o módulo. Si un desarrollador trabaja en un pedazo de código durante una iteración, otro
desarrollador podría trabajar sobre la misma pieza de código tal vez para añadir más
funcionalidades en la siguiente iteración. Si la segunda persona necesita una aclaración sobre un
tema concreto en el código, el autor podría ser abordado. Esta práctica ayuda en compartir el
conocimiento a través del equipo. Esta práctica hace hincapié en un objetivo común para todo el
equipo del proyecto. Par de programación se discutió anteriormente mejora este tipo de
pensamiento.

Desarrollo basado en pruebas explicado anteriormente le da la confianza para llevar adelante el

trabajo de otra persona, porque ese trozo de código, que ha trabajado en ha superado el 100% de
los casos de prueba. Si por alguna razón algo falla, esto es debido al código que ahora se ha
introducido.

Todas estas prácticas como la programación en parejas, el desarrollo basado en pruebas, las
normas de codificación de refactorización, la propiedad colectiva están relacionados entre sí y
deben ocurrir en tándem.

Hagamos un resumen de lo que hemos aprendido acerca de la programación en parejas, los

estándares de codificación y la propiedad colectiva.

- La programación en parejas es una práctica en la que dos desarrolladores trabajan lado a lado.
Un desarrollador-el conductor escribe el código, y el otro observa, e identifica los defectos
tácticos.

- Par de programación se practica normalmente para el código que tiene que ser mantenido y
durante la codificación de componentes reutilizables.

- agilistas creen en la estricta adhesión a los estándares de codificación. los estándares de

codificación son el conjunto común de normas elaboradas a partir de los mejores estilos de
codificación.
 - Ágil insiste en la propiedad colectiva donde cada uno es responsable de todo el sistema, y que
cualquier persona tiene la libertad de cambiar de código.

Otra buena práctica de ingeniería en ágil es la integración continua.

Durante el desarrollo basado en pruebas, el equipo comprobaría en su código de frecuencia -

idealmente después de la codificación y la unidad de prueba de una funcionalidad muy minúscula
del sistema. Se crea una construcción integrada de todo el código que se ha registrado. Todos los
defectos se abordan en la máxima prioridad. Compilaciones son seguido de la prueba de humo.
Las pruebas de humo es preliminar a más pruebas, que deberán revelar fallos simples lo
suficientemente graves como para rechazar una versión de software prospectivo.

El proceso de integración continua sigue el ciclo de desarrollo basado en pruebas. Dado que el
ciclo de desarrollo basado en pruebas idealmente sigue 15 ciclos por minuto, lo que necesita para
llevar a cabo la integración continua también una vez en cada 15 ciclos hora en un escenario ideal.
La realización de todas estas actividades en ciclos cortos necesita práctica. Debe asegurarse de
que la acumulación no se rompe, si no sería el foco de todo el equipo para obtener de nuevo en
condiciones de trabajo. Cuando la integración continua no es posible, se puede programar la
actividad de integración una vez o dos veces cada día - todo el mundo se echa en su pedazo de
código antes de la acumulación prevista. Tenga en cuenta que en los proyectos ágiles, una
acumulación debe ocurrir al menos una vez al día.

Es necesario utilizar herramientas para hacer el trabajo proceso de integración continua - hay
varias herramientas como crucero, climatizador, Clearmake, Omake, ANT, StarTeam, que se puede
hacer uso de. El éxito de builds debe ir seguido de pruebas funcionales - es mejor para automatizar
pruebas funcionales en la medida de lo posible.

La ventaja de tener esta práctica de integración continua en su lugar es que se descubre defectos
de integración muy temprano en su ciclo de vida del proyecto. Se asegura de que una pieza de
trabajo de software de prueba está disponible en cualquier punto dado del tiempo. Dado que
construye se realizan al menos una vez al día - cuando una acumulación rompe solamente un día
de trabajo tendrá que ser depurado, lo que sería mucho más fácil de rectificar.

Ágil promueve tener un cliente emplazamiento común. El cliente, los desarrolladores y los
probadores de todo el trabajo en un lugar de trabajo abierto, por lo que la interacción se vuelve
fácil.

Al tener todas las personas involucradas en el proyecto en un solo lugar hace que la colaboración y
la cooperación entre los miembros del equipo mucho más fácil. La presencia del cliente es
importante, ya que puede dar sus comentarios sobre el trabajo en curso y aclarar cualquier duda
sobre la funcionalidad de la historia en tiempo real. Los desarrolladores y diseñadores pueden ver
inmediatamente en los comentarios y modificar su trozo de código y diseño para asegurar que el
cliente está satisfecho. El cliente también recibe un conocimiento de primera mano de cómo está
progresando el trabajo, y los desafíos que enfrenta el equipo del proyecto.
Durante los primeros días, los métodos ágiles estaban disuadiendo de desarrollo offshore. Sin
embargo el desarrollo en alta mar es una realidad y por lo que los métodos ágiles tendrá que ser
adaptado para el desarrollo distribuido. Si no se puede tener todo el equipo y el cliente en un solo
lugar, asegurarse de que hay un coordinador técnico que el sitio es técnicamente competente,
disponible en la ubicación del cliente.

En grandes proyectos, o en proyectos donde los requerimientos de negocio están cambiando con
frecuencia, usted podría tener un pequeño equipo in situ en el lugar del cliente.

Como ya hemos comentado anteriormente, al final del ciclo iterativo que realice una revisión del
sprint, donde se demuestra el subgrupo de trabajo del producto al cliente. se busca la
retroalimentación de los clientes. Evaluaciones podrían ser los cambios, se añaden mejoras o
bugs.These a la pila de producto como historias de usuario. Toda la pila de producto se
repriorizados antes de la próxima iteración. Así, las historias basadas en la retroalimentación de
los usuarios se abordan en iteraciones posteriores en función de sus prioridades.

Al final de la Revisión del Sprint, tienes una reunión retrospectiva. Durante la reunión de
retrospectiva, analice las lecciones aprendidas, las mejores prácticas y las métricas. Se hace una
lista de lo que funciona, lo que no funciona, y los cambios que tienen que ser hechas. Una cosa
importante para recordar es dar prioridad a las acciones y recoger unos pocos para su aplicación
durante la siguiente iteración. Durante la retrospectiva, el equipo de voz a sus preocupaciones y
llega a soluciones para hacer frente a ellos, mientras que los gerentes observan y escuchan y
ofrecen ayuda como y cuando sea necesario. Las reuniones retrospectivos sirven como una mejor
plataforma para la mejora continua y por tener equipos auto-organizados.

Vamos a resumir en los últimos pocos temas que tratamos.

- El proceso de integración continua sigue el ciclo de desarrollo basado en pruebas.

- Durante el desarrollo basado en pruebas, casos de prueba se escriben primero y ejecutados.

Código está escrito a continuación para asegurarse de que pasan las pruebas. Finalmente se
rediseñado el código.

- Después del ciclo de TDD, el código se registró y una construcción integrada se crea a partir del
código todos los desarrolladores. Todos los defectos identificados durante la construcción se
abordan en la máxima prioridad.

- Ágil hace hincapié en tener un equipo de emplazamiento común. La presencia del cliente es
importante como retroalimentación sobre el trabajo en curso y aclaraciones sobre la funcionalidad
de la historia puede ser buscada y obtenida en tiempo real.

- Al final del ciclo iterativo una revisión del sprint se lleva a cabo en el software de trabajo, que es
un subconjunto de todo el producto se demuestra con el cliente y se obtiene la retroalimentación.
Esta retroalimentación ayuda en la orientación del desarrollo de productos de acuerdo a las
necesidades del cliente.

- Al final de la Revisión del Sprint, tienes una reunión retrospectiva. Durante la reunión de
retrospectiva, el equipo analiza las lecciones aprendidas, mejores prácticas, métricas, e identifica
las mejoras necesarias.

En la fase de lanzamiento de la producción, antes de que el producto es liberado para apuntar

medio ambiente, llevamos a cabo pruebas de nivel de versión y documentación de usuario. La fase
de liberación del producto implica actividades relacionados con la liberación del producto en
entorno de destino / producción. Las actividades claves son realizadas las pruebas de nivel de
versión, documentación del usuario y capacitación del usuario final.

Poniendo todo junto, se ve el ciclo de vida ágil representado en el modelo ETVX aquí. En Wipro, el
ágil LCM contiene las prácticas de XP y Scrum. La mayoría de los clientes pedir la adhesión a las
prácticas de Scrum, XP, pero tiene un conjunto de prácticas de ingeniería básicos que se necesitan
para la implementación exitosa de Scrum.

Una cosa que se ha añadido explícitamente aquí es el Sprint 0 o la iteración 0. Se podría centrarse
en la definición de la arquitectura básica y la configuración del motor de entrega durante esta
etapa. Por motor de entrega, nos referimos a la infraestructura básica incluyendo hardware,
software, configuración de las herramientas necesarias, la capacitación del equipo, trabajo en
equipo, etc. Una vez que empieza a correr, el equipo va a estar muy ocupado centrándose en las
entregas, sprint, literalmente significa “RUN” - por lo tanto, es importante tomar un tiempo libre
para Sprint 0 para obtener el suelo listo para carreras de velocidad.

Hagamos ahora una comparación de XP y Scrum. Usted llama a su baraja de requisitos o historias
como tarjetas de historia en XP y como una pila de producto en Scrum. Iteración y la planificación
de la iteración en XP se conoce como la planificación de Sprint y Sprint en Scrum. El diario reunión
de pie en XP se conoce como reunión de Scrum en XP. Mientras que en XP, es necesario tener una
integración continua, en la que una acumulación que hay que hacer después de cada registro,
Scrum sin embargo exige un diario construye. Tiene algunas buenas prácticas de ingeniería
defendidas explícitamente por XP, como el diseño simple, refactoring, desarrollo impulsado por la
prueba, normas de codificación y el cliente emplazamiento común. Estas prácticas no se
mencionan en Scrum, pero se entienden tácitamente. La programación en parejas es algo que
hace hincapié en XP, mientras que no existe tal concepto se explica en Scrum.

A continuación, vamos a hablar de los diferentes roles en XP. Kent Beck ha definido los siguientes
7 funciones para XP.

- El programador es responsable de identificar y estimar las tareas a la mano, ya que las

actividades de ingeniería también se realizan incluyendo el diseño, la redacción de casos de
prueba, codificación y las pruebas unitarias, refactorización y comunicarse y colaborar con otros
miembros del equipo.

- El probador, ayuda a que el cliente llegue a los casos de pruebas funcionales. El equipo de
pruebas ejecuta las pruebas de funcionalidad con regularidad, registra los resultados, y mantiene
las herramientas de prueba.

- El cliente, el jugador clave, es el responsable de escribir historias y pruebas de aceptación. El

cliente también identifica y da prioridad a las historias que tienen que ser tomadas para el
lanzamiento y la iteración.

- El gerente es responsable de mantener abiertos los canales de comunicación entre los

desarrolladores, clientes y probadores. Si cualquier conflicto o asunto se pusiesen de manifiesto,
lo que impide el progreso del proyecto, es el deber del gerente para resolverlo.

- El sistema de seguimiento del proyecto realiza un seguimiento del progreso realizado durante
cada iteración. El seguidor recoge y analiza las métricas, y proporciona información sobre el
análisis.

- El entrenador es un evangelista ágil - El entrenador es un jugador fundamental que ayuda a los

miembros del equipo entiendan las prácticas ágiles y ayuda al equipo para adaptar el proceso de
acuerdo a sus necesidades.

- El consultor desempeña el papel de una guía técnica. Él ayuda a los miembros del equipo cada
vez que se enfrentan a un problema técnico, y ayuda a resolver el problema en cuestión.

Mientras que hay 7 funciones definidas en XP, Scrum habla de sólo 3 roles- propietario del
producto, Scrum Master y el Equipo Scrum. El propietario producto define y prioriza las
funcionalidades que deben entregarse. El propietario decide en el objetivo final de cada sprint. El
dueño del producto revisa el resultado de sprint al final de cada carrera y proporciona la
retroalimentación.

El Scrum Master se asegura de que todas las reuniones scrum se llevan a cabo como estaba
previsto. El maestro asegura que el foco en el objetivo del Sprint se mantiene durante las
reuniones scrum. Se mantiene el scrum quemar la carta a través de las pruebas de velocidad. El
scrum master asegura que los impedimentos identificados durante las reuniones scrum se
abordan y se retiran. También se asegura de que el equipo no está sobre cargado con nuevas
tareas antes de que se completen las tareas actuales para esa iteración particular. La adhesión a
los procesos definidos, incluidos los de planificación de Sprint Sprint y revisión son responsabilidad
del scrum master.

El Equipo Scrum trabaja en conjunto para asegurar que se logre el objetivo del Sprint.
responsabilidad del equipo es actualizar el sprint backlog sobre una base diaria, para registrar el
progreso y mantener todas las partes interesadas informadas sobre los avances y desafíos. El
equipo de scrum es multi funcional y organiza a sí mismos para ser productivos. Demostrando el
producto del trabajo al final de cada carrera es responsabilidad del equipo.

En esta sesión, hemos aprendido acerca de la metodología ágil. La metodología consta de cuatro
fases a saber - Exploración, Planificación, y la liberación de iteración. También vimos que los
proyectos ágiles siguen ciertas buenas prácticas.

Las prácticas de XP que hemos explorado son: (1) La metáfora, (2) Planificación Juego (Release e
iteración), (3) los lanzamientos cortos, (4) Pace Sostenible, (5) Diseño simple, (6) Refactoring, (7)
prueba Driven Development, (8) la programación en parejas, (9) Integración continua, (10)
Estándares de Codificación, (11) la propiedad colectiva, y (12) Colocado al cliente.

Scrum tiene tres ceremonias - (1) Planificación del Sprint, (2) reuniones scrum diario y (3)
reuniones Revisión del Sprint.

La clave para todas estas prácticas es la colaboración, apertura y confianza entre todos los
interesados.

Para obtener información sobre las prácticas ágiles y personalizaciones (por precio fijo o equipos
grandes / distribuidos), consulte el manual ágil en VelociQ.