UNIDAD IX

Metodologas giles Necesidad de metodologas alternativasSurgieron por la necesidad de generar software de manera rpida, y adems que cumpla con las siguientes caractersticas: Flexible De calidad Documentacin no exhaustivaNocin de cambios permanentes

Variables: Costo, Tiempo, Calidad, Alcance Costo : maquinas, especialistas, oficinas Tiempo: total y de entregas parciales. Calidad: externa e interna. Alcance: intervencion del cliente**Nota: Solo 3 de ellas pueden ser fijadas(valores fijo) por personas externas(clientes, jefe de proyecto) del proyecto 1 de ellas debe ser fijada por el equipo de desarrollo del proyectoEj: Si cliente elije: alcance y calidadY PM elije: PrecioEntonces el equipo de desarrollo tendr la libertad de determinar: el tiempo que durara el proyecto.

Manifiesto de metodologas giles"Desarrollo gil" es un trmino derivado del Manifiesto gil (Agile Manifesto), escrito en 2001 por un grupo que inclua: a los creadores de Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) y Crystal; un representante de desarrollo controlado por caractersticas; y otros coordinadores diversos del pensamiento en la industria del software.El Manifiesto gil (Agile Manifesto) estableci un conjunto comn de valores y principios dominantes para todas las metodologas giles individuales en el momento.El manifiesto detalla 4 valores claveIndividuos e interaccionessobre procesos y herramientasSoftware funcionandosobre documentacin extensivaColaboracin con el clientesobre negociacin contractualRespuesta ante el cambiosobre seguir un planEsto es, aunque valoramos los elementos de la derecha, valoramos ms los de la izquierda.Estos valores bsicos se sustentan en 12 principios:1. Nuestra mayor prioridad es satisfacer al clientemediante la entrega temprana y continua de softwarecon valor.2. Aceptamos que los requisitos cambien, incluso en etapastardas del desarrollo. Los procesos giles aprovechanel cambio para proporcionar ventaja competitiva alcliente.3. Entregamos software funcional frecuentemente, entre dossemanas y dos meses, con preferencia al periodo detiempo ms corto posible.4. Los responsables de negocio y los desarrolladorestrabajamos juntos de forma cotidiana durante todoel proyecto.5. Los proyectos se desarrollan en torno a individuosmotivados. Hay que darles el entorno y el apoyo quenecesitan, y confiarles la ejecucin del trabajo.6. El mtodo ms eficiente y efectivo de comunicarinformacin al equipo de desarrollo y entre susmiembros es la conversacin cara a cara.7. El software funcionando es la medida principal deprogreso.8. Los procesos giles promueven el desarrollosostenible. Los promotores, desarrolladores y usuariosdebemos ser capaces de mantener un ritmo constantede forma indefinida.9. La atencin continua a la excelencia tcnica y albuen diseo mejora la Agilidad.10. La simplicidad, o el arte de maximizar la cantidad detrabajo no realizado, es esencial.11. Las mejores arquitecturas, requisitos y diseosemergen de equipos auto-organizados.12. A intervalos regulares el equipo reflexiona sobrecmo ser ms efectivo para a continuacin ajustar yperfeccionar su comportamiento en consecuencia.Nota: Los 2 primeros principios son generales y los dems tienen que ver con: El proceso a seguir El equipo de desarrollo Las metas a seguirMs informacin completa en: https://msdn.microsoft.com/es-es/library/vstudio/dd997578(v=vs.110).aspx

Introduccin a la Programacin ExtremaMetodologa gil basada en cuatroprincipios: simplicidad,comunicacin,retroalimentacinyvalor. Adems, orientada porpruebasy refactorizacin, se disea e implementan las pruebas antes de programar la funcionalidad, el programador crea sus propios tests de unidad.Estemtodoes tpicamente atribuido a Kent Beck, Ron Jeffries y Ward Cinningham. Elobjetivode Xp songrupospequeos y medianos deconstruccindesoftwareen donde los requisitos an son muy ambiguos, cambian rpidamente o son de altoriesgo. Xp busca la satisfaccin delclientetratando de mantener durante todo el tiempo su confianza en elproducto. Adems, sugiere que el lugar detrabajosea una sala amplia, si es posible sin divisiones (en el centro los programadores, en la periferia los equipos individuales). Una ventaja del espacio abierto es el incremento en la comunicacin y el proporcionar una agendadinmicaen el entorno de cadaproyecto. Actividades de XP

1. CodificarEs necesario codificar y plasmar nuestras ideas a travs delcdigo. En programacin, el cdigo expresa lainterpretacindel problema, as podemos utilizar el cdigo para comunicar, para hacer comunes las ideas, y por tanto para aprender y mejorar.2. Hacer pruebasLas caractersticas del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas dan la oportunidad de saber si lo implementado es lo que en realidad se tena en mente. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestrosistema, entonces habremos acabado por completo.

3. Escuchar[5] nos menciona en una frase, "Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas denegociospiensan que son interesantes. Si ellos pudieran programarse su propio software para qu nos querran?".Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita lainformacin. Tenemos que escuchar a nuestros clientes cules son losproblemasde su negocio, debemos de tener una escucha activa explicando lo que es fcil y difcil de obtener, y la realimentacin entre ambos nos ayudan a todos a entender los problemas.4. DisearEldiseocrea unaestructuraque organiza lalgicadel sistema, un buen diseo permite que el sistema crezca con cambios en un solo lugar. Los diseos deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el diseo o malos diseos, estos deben de ser corregidos cuanto antes.Resumiendo las actividades de Xp: Tenemos que codificar porque sin cdigo no hayprogramas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que disear parapodercodificar, probar y escuchar indefinidamente. Prcticas Bsicas de XP.De forma aislada, cualquier prctica individual de Xp tiene poco sentido, pero en conjunto, unas compensan las carencias que las otras puedan tener.[4] nos dice que para evaluar Xp hay que mirar la gran foto, es decir, todo el conjunto de prcticas:

Eljuegode laPlanificacin- (Planning Game)El alcance de la siguiente versin esta definido por las consideraciones denegocios(prioridad de los mdulos, fechas de entrega) y estimacionestcnicas(estimaciones defunciones, consecuencias).Elobjetivodel juego es maximizar elvalordelsoftwareproducido, Laestrategiaes poner enproduccinlas caractersticas ms importantes lo antes posible, Las Piezas clave son las Story Cards, Los Jugadores son los desarrolladores y elclientey las Movidas son Exploracin,Selecciny Actualizacin. Versiones Pequeas (Short Releases)Unsistemasimple se pone rpidamente en produccin. Peridicamente, se producen nuevas versiones agregando en cada iteracin aquellas funciones consideradas valiosas para el cliente Metfora del Sistema (Metaphor)CadaProyectoes guiado por unahistoriasimple de cmo funciona el sistema en general, reemplaza a laarquitecturay debe estar enlenguajecomn, entendible para todos (Cliente y Desarrolladores), esta puede cambiar permanentemente. Diseo Simple (Simple Designs)El sistema se disea con la mxima simplicidad posible (YAGNY - "No vas a necesitarlo"), Se plasma eldiseoentarjetasCRC (ClaseResponsabilidad- Colaboracin), no se implementan caractersticas que no son necesarias, con esta tcnica, las clases descubiertas durante elanlisispueden ser filtradas para determinar qu clases son realmente necesarias para el sistema. Pruebas Continuas (Testing)Los casos de prueba se escriben antes que elcdigo. Los desarrolladores escribenpruebasunitarias y losclientesespecifican pruebas funcionales. Refactorizacin (Refactoring)Es posible reestructurar el sistema sin cambiar sucomportamiento, por ejemplo eliminando cdigo duplicado, simplificando funciones, Mejorando el cdigo constantemente, si el cdigo se esta volviendo complicado se debera modificar el diseo y volver a uno ms simple. Refactoring (Modificar la forma del cdigo sin cambiar su funcionamiento). Programacin por parejas (Pair Programming)El cdigo es escrito por dos personas trabajando en el mismocomputador. "Una sola maquina con untecladoy unmouse"Posesin Colectiva del Cdigo (Collective Code Ownership)Nadie es dueo de un modulo. Cualquier programador puede cambiar cualquier parte del sistema en cualquier momento, siempre se utilizan estndares y se excluyen los comentarios, Lostestsiempre deben funcionar al 100% para realizar integraciones con todo el cdigo permanentemente. Integracin continua (Continuous Integration)Los cambios se integran en el cdigo base varias veces por da. Todos los casos de prueba se deben pasar antes y despus de laintegracin, se dispone de una mquina para la integracin y se realizan test funcionales en donde participa el cliente. Semanalaboralde 40 horas (40-Hour Week)Cada Trabajador trabaja no ms de 40 Horas por semana. Si fuera necesario hacer horas extra, esto no debera hacerse dos semanas consecutivas. Sin hroes, esto hace que se reduzca la rotacin delpersonaly mejora lacalidaddelproducto. Cliente en el Sitio (On Site Customer)El equipo dedesarrollotiene acceso todo eltiempoal cliente, el cual esta disponible para responder preguntas, fijar prioridades, etc. Esto no siempre se consigue; Un cliente muy Junior no sirve y un cliente muy Snior no es disponible. "Lo ideal es un cliente Analista". Estndares deCodificacin(Coding Standard)Todo el cdigo debe estar escrito de acuerdo a un estndar de codificacin

Fases del ciclo de vida de las metodologas giles Resumen del ciclo de vidaXP se basa en historias de usuario, estas historias las escribe el cliente o le representante dentro del equipo y describen los escenarios claves del funcionamientos del SW.A partir de las historias de usuario, se generan los relase (entregas) entre el equipo y el cliente.Estos relase son los que permiten definir las iteraciones necesarias para cumplir con los objetivos, de manera que cada resultado de la iteracin sea un programa aprobado por el cliente.

Ciclo de Vida de XPElciclo de vidade Xp se enfatiza en elcarcterinteractivo e incremental del desarrollo, Segn [1] una iteracin de desarrollo es un perodo de tiempo en el que se realiza un conjunto de funcionalidades determinadas que en el caso de Xp corresponden a un conjunto de historias de usuarios.Las iteraciones son relativamente cortas ya que se piensa que entre ms rpido se le entreguen desarrollos al cliente, msretroalimentacinse va a obtener y esto va a representar una mejor calidad del producto a largo plazo. Existe una fase de anlisis inicial orientada a programar las iteraciones de desarrollo y cada iteracin incluye diseo, codificacin y pruebas, fases superpuestas de tal manera que no se separen en el tiempo.La siguiente figuramuestralas fases en las que se subdivide el ciclo de vida Xp:

[1] y [3] nos describen cada una de las fases en las que se subdivide el ciclo de vida de eXtreme Programming:Fase de la exploracin:En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son deinterspara la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con lasherramientas, tecnologas y prcticas que se utilizarn en el proyecto.Se prueba latecnologay se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploracin toma de pocas semanas a pocos meses, dependiendo del tamao y familiaridad que tengan los programadores con la tecnologa.Fase delplaneamiento:se priorizan las historias de usuario y se acuerda el alcance del release. Los programadores estiman cunto esfuerzo requiere cada historia y a partir de all se define el cronograma. La duracin del cronograma del primer release no excede normalmente dos meses. La fase de planeamiento toma un par de das. Se deben incluir varias iteraciones para lograr un release. El cronograma fijado en la etapa de planeamiento se realiza a un nmero de iteraciones, cada una toma de una a cuatro semanas en ejecucin. La primera iteracin crea un sistema con la arquitectura del sistema completo. Esto es alcanzado seleccionando las historias que harn cumplir laconstruccinde laestructurapara el sistema completo. El cliente decide las historias que se seleccionarn para cada iteracin. Las pruebas funcionales creadas por el cliente se ejecutan al final de cada iteracin. Al final de la ltima iteracin el sistema esta listo para produccin.Fase de produccin:requiere prueba y comprobacin extra del funcionamiento del sistema antes de que ste se pueda liberar al cliente. En esta fase, los nuevos cambios pueden todava ser encontrados y debe tomarse la decisin de si se incluyen o no en el release actual. Durante esta fase, las iteraciones pueden ser aceleradas de una a tres semanas. Las ideas y las sugerencias pospuestas se documentan para una puesta en prctica posterior por ejemplo en la fase demantenimiento. Despus de que se realice el primer release productivo para uso del cliente, el proyecto de Xp debe mantener el funcionamiento del sistema mientras que realiza nuevas iteraciones.Fase de mantenimiento:requiere de un mayor esfuerzo para satisfacer tambin las tareas del cliente. As, lavelocidaddel desarrollo puede desacelerar despus de que el sistema est en la produccin. La fase de mantenimiento puede requerir la incorporacin de nueva gente y cambiar la estructura del equipo.Fase demuerte:Es cuando el cliente no tiene ms historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera ladocumentacinfinal del sistema y no se realizan ms cambios en la arquitectura.La muertedel proyecto tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no haypresupuesto para mantenerlo.Otra explicacin de las fases ms resumidas:1.Fase de exploracin: oCliente plantea necesidades mediante redaccin de sencillas historias de usuariooProgramador estiman los tiempos de desarrollo con la info anterior.oEn ambientes muy cambiantes se pueden usar prototipos(Spyke)Salida de la fase: metfora del sistema y los requerimientos 2.Fase de planeamiento:oCliente y programadores se ponen de acuerdo para priorizar las implementacin , las entregas y alcance de la 1 versin del sistemaoTambin se pueden usar SpykesSalida de la fase: plan de entregas(o relase plan)3.Fase de desarrollo:oLas funcionalidades son desarrolladas , generando al final de cada una un entregable funcional (Ac se implementa las historias de usuarios asignadas a la iteracin)4.Fase de produccin:oEn esta fase se debe decidir si las nuevas funcionalidades o las modificaciones, se incluyen o no en la versin actual.

Otra explicacin de las fases tambin en: https://ingsotfwarekarlacevallos.wordpress.com/2015/05/08/metodologia-de-desarrollo-agil-xp-y-scrum/ Ventajas y Desventajas frente a Metodologas tradicionales

Actores y Responsabilidades de XpExisten diferentes roles (actores) y responsabilidades en Xp para diferentes tareas y propsitos durante elproceso: Programador (Programmer) Responsable de decisiones tcnicas Responsable de construir el sistema Sin distincin entre analistas, diseadores o codificadores En Xp, los programadores disean, programan y realizan las pruebas Cliente (Customer) Es parte del equipo Determina qu construir y cundo Escribe tests funcionales para determinar cundo est completo un determinado aspecto Entrenador (Coach) Ellderdel equipo - toma las decisiones importantes Principal responsable del proceso Tiende a estar en un segundo plano a medida que el equipo madura Rastreador (Tracker) Metric Man Observa sin molestar Conservadatoshistricos Probador (Tester) Ayuda al cliente con las pruebas funcionales Se asegura de que los tests funcionales se ejecutanSCRUMhttps://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum.html http://proyectosagiles.org/que-es-scrum/

Qu es?Scrum es una metodologa gil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversin para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspeccin continua, adaptacin, auto-gestin e innovacin.Scrum es un proceso en el que se aplican de manera regularun conjunto debuenas prcticasparatrabajar colaborativamente, en equipo, y obtenerel mejor resultado posiblede un proyecto.Estas prcticas se apoyan unas a otras y su seleccin tiene origen en unestudio de la manera de trabajar de equipos altamente productivos.En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum est especialmente indicado paraproyectos enentornos complejos, donde se necesitaobtener resultados pronto, donde losrequisitos son cambiantes o poco definidos, donde lainnovacin, lacompetitividad, laflexibilidady laproductividadson fundamentales.Scrum tambin se utiliza para resolver situaciones en queno se est entregando al cliente lo que necesita, cuandolas entregas se alargan demasiado,los costes se disparanola calidad no es aceptable, cuando se necesitacapacidad de reaccin ante la competencia, cuandola moral de los equipos es baja y la rotacin alta, cuando es necesarioidentificar y solucionar ineficiencias sistemticamenteo cuando se quiere trabajar utilizando unproceso especializado en el desarrollo de producto.

Cundo se utiliza?Con la metodologa Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteracin a iteracin. Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteracin sin ningn problema.

Esta metdica de trabajo promueve la innovacin, motivacin y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un mbito propicio para desarrollar sus capacidades.

BeneficionsCumplimento de expectativas:El cliente establece sus expectativas indicando el valor que le aporta cada requisito /historiadel proyecto, el equipo los estima y con esta informacin elProduct Ownerestablece su prioridad. De manera regular, en las demos de Sprint elProduct Ownercomprueba que efectivamente los requisitos se han cumplido y transmite se feedback al equipo.Flexibilidad a cambios:Alta capacidad de reaccin ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodologa est diseada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.Reduccin del Time to Market:El cliente puede empezar a utilizar las funcionalidades ms importantes del proyecto antes de que est finalizado por completo.Mayor calidad del software:La metdica de trabajo y la necesidad de obtener una versin funcional despus de cada iteracin, ayuda a la obtencin de un software de calidad superior.Mayor productividad:Se consigue entre otras razones, gracias a la eliminacin de la burocracia y a la motivacin del equipo que proporciona el hecho de que sean autnomos para organizarse.Maximiza el retorno de la inversin (ROI):Produccin de software nicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorizacin por retorno de inversin.Predicciones de tiempos:Mediante esta metodologa se conoce la velocidad media del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fcilmente para cuando se dispondr de una determinada funcionalidad que todava est en el Backlog.Reduccin de riesgos:El hecho de llevar a cabo las funcionalidades de ms valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.

Tamao del equipoEl tamao de un equipo estentre 5 y 9 personas. Por debajo de 5 personas cualquier imprevisto o interrupcin sobre un miembro del equipo compromete seriamente el compromiso que han adquiridoy, por tanto, el resultado que se va a entregar alclienteal finalizar la iteracin. Por encima de 9 personas, la comunicacin y colaboracin entre todos los miembros se hace ms difcil y se forma subgrupos.De cualquier manera, se puede hacer Scrum con 3 personas y se ha utilizado en proyectos con 250 personas en varios equipos. Cuando es necesario que ms de un equipo trabaje de manera gil en un mismo proyecto, existen diferentes tcnicas que permiten esta colaboracin, desde el Scrum de Scrums hasta equipos de integracin que dedican parte de su tiempo a trabajar con los equipos de desarrollo, siempre completando incrementos de producto de manera regular, con el resultado integrado de los diferentes equipos.

Compromiso del clienteScrum exige del cliente unaalta implicacin y una dedicacin regular:El cliente tiene la responsabilidad de dirigir los resultados del producto o proyecto:El cliente debe disponer de una visin de alto nivel del producto o proyecto y tener reflejadas sus expectativas en forma delista de requisitos priorizadadonde ha indicado el valor que le aportar cada uno. A partir de los costes de desarrollo que le proporcione el equipo, priorizar los requisitos en funcin del Retorno de la Inversin (ROI) ms rpido.El cliente replanifica el proyecto en cada iteracin para maximizar este ROI de manera continua.Al tratarse de un proyecto que va entregando resultados en iteraciones regulares, el cliente debe colaborar participando en el inicio de cada iteracin (reunin de planificacin) y en el fin de cada iteracin (demostracin), y debe estar disponible durante la ejecucin de cada iteracin para resolver dudas.

ProcesoEl desarrollo se realiza de forma iterativa e incremental. Cada iteracin, denominadaSprint,tiene una duracin preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versin del software con nuevas prestaciones listas para ser usadas. En cada nuevoSprint,se va ajustando la funcionalidad ya construida y se aaden nuevas prestaciones priorizndose siempre aquellas que aporten mayor valor de negocio.

Product Backlog:Conjunto de requisitos demoninados historias descritos en un lenguaje no tcnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversin considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.Sprint Planning:Reunin durante la cual el Product Owner presenta las historias del backlog por orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint, para en una segunda parte de la reunin, decidir y organizar cmo lo va a conseguir.Sprint:Iteracin de duracin prefijada durante la cual el equipo trabaja para convertir lashistoriasdelProduct Backloga las que se ha comprometido, en una nueva versin del software totalmente operativo.Sprint Backlog:Lista de las tareas necesarias para llevar a cabo lashistoriasdel sprint.Daily sprint meeting:Reunin diaria de cmo mximo 15 min. en la que el equipo se sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el da anterior, que har hoy y si hay impedimentos.Demo y retrospectiva:Reunin que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstracin del producto. Posteriormente, en la retrospectiva, el equipo analiza qu se hizo bien, qu procesos seran mejorables y discute acerca de cmo perfeccionarlos.

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos(iteracionesde un mes naturaly hasta dedos semanas, si as se necesita). Cada iteracin tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mnimo esfuerzo al cliente cuando lo solicite.

El proceso parte de lalista de objetivos/requisitos priorizadadel producto, que acta como plan del proyecto. En esta listaelclienteprioriza los objetivos balanceando el valor que le aportan respecto a su costeyquedan repartidos en iteraciones y entregas. De manera regular el cliente puedemaximizar la utilidad de lo que se desarrollay elretorno de inversinmediante lareplanificacin de objetivosdel producto, que realiza durante la iteracin con vista a las siguientes iteraciones.Las actividades que se llevan a cabo en Scrum son las siguientes:Planificacin de la iteracinEl primer da de la iteracin se realiza la reunin de planificacin de la iteracin. Tiene dos partes:Seleccin de requisitos(4 horas mximo). El cliente presenta alequipola lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos ms prioritarios que se compromete a completar en la iteracin, de manera que puedan ser entregados si el cliente lo solicita.Planificacin de la iteracin(4 horas mximo). El equipo elabora lalista de tareas de la iteracinnecesarias para desarrollar los requisitos a que se ha comprometido. La estimacin de esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas.Ejecucin de la iteracinCada da el equipo realiza unareunin de sincronizacin(15 minutos mximo). Cada miembro del equipo inspecciona el trabajo que el resto est realizando (dependencias entre tareas, progreso hacia el objetivo de la iteracin, obstculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunin cada miembro del equipo responde a tres preguntas:Qu he hecho desde la ltima reunin de sincronizacin?Qu voy a hacer a partir de este momento?Qu impedimentos tengo o voy a tener?Durante la iteracin elFacilitador (Scrum Master)se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad.Elimina los obstculos que el equipo no puede resolver por s mismo.Protege al equipo de interrupciones externasque puedan afectar su compromiso o su productividad.Inspeccin y adaptacinEl ltimo da de la iteracin se realiza la reunin de revisin de la iteracin. Tiene dos partes:Demostracin(4 horas mximo). El equipo presenta al cliente los requisitos completados en la iteracin, en forma de incremento de producto preparado para ser entregado con el mnimo esfuerzo. En funcin de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteracin, replanificando el proyecto.Retrospectiva(4 horas mximo). El equipo analiza cmo ha sido su manera de trabajar y cules son los problemas que podran impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargar de ir eliminando los obstculos identificados.

RolesEn Scrum, el equipo se focaliza en construir software de calidad. La gestin de un proyecto Scrum se centra en definir cules son las caractersticas que debe tener el producto a construir (qu construir, qu no y en qu orden) y en vencer cualquier obstculo que pudiera entorpecer la tarea del equipo de desarrollo.El equipo Scrum est formado por los siguientes roles:Scrum master:Persona que lidera al equipo guindolo para que cumpla las reglas y procesos de la metodologa. Gestiona la reduccin de impedimentos del proyecto y trabaja con elProduct Ownerpara maximizar el ROI.Product owner (PO):Representante de lso accionistas y clientes que usan el software. Se focaliza en la parte de negocio y el es responsable del ROI del proyecto (entregar un valor superior al dinero invertido). Traslada la visin del proyecto al equipo, formaliza las prestaciones enhistoriasa incorporar en elProduct Backlogy las reprioriza de forma regular.Team:Grupo de profesionales con los conocimientos tcnicos necesarios y que desarrollan el proyecto de manera conjunta llevando a cabo lashistoriasa las que se comprometen al inicio de cada sprint.

ActividadesPlanificacin de la iteracin (Sprint Planning)Ejecucin de la iteracin (Sprint)Reunin diaria de sincronizacin del equipo (Scrum Daily Meeting)Demostracin de los requisitos completados (Sprint Review)Retrospectiva (Sprint Retrospective)Replanificacin delproyectoResponsabilidadesCliente (Product Owner)Facilitador (Scrum Master)Equipo (Team)HerramientasLista de requisitos priorizada (Product Backlog)Lista de tareas de la iteracin (Sprint Backlog)Grficos detrabajo pendiente(Burndown Chart)

Herramientas que se suelen usar en scrumDefinicin de completado (DoD)Historias de usuarioTablero de tareasPlanning PokerVelocidad del equipoPrincipios de Lean Software Development

Fundamentos de scrumScum se basa en:El desarrolloincrementalde los requisitos del proyecto en bloques temporales cortos y fijos(iteracionesde un mes naturaly hasta dedos semanas, si as se necesita).Lapriorizacin de los requisitos por valor para el cliente y coste de desarrolloen cada iteracin.Elcontrol empricodel proyecto. Por un lado, al final de cada iteracin se demuestra al cliente el resultado real obtenido, de manera que pueda tomar las decisiones necesarias en funcin de lo que observa y del contexto del proyecto en ese momento. Por otro lado, el equipo se sincroniza diariamente y realiza las adaptaciones necesarias.Lapotenciacin del equipo, que se compromete a entregar unos requisitos y para ello se le otorga la autoridad necesaria para organizar su trabajo.La sistematizacin de lacolaboracin y la comunicacin tanto entreel equipo y como con el cliente.Eltimeboxingde las actividades del proyecto, para ayudar a la toma de decisiones y conseguir resultados.Estas prcticas se apoyan unas a otras y su seleccin tiene origen en unestudio de la manera de trabajar de equipos altamente productivos.

CaracteristicasSCRUM es un modelo de referencia que define un conjunto de prcticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutar durante un proyecto. Los roles principales en Scrum son elScrumMaster, que procura facilitar la aplicacin de scrum y gestionar cambios, elProductOwner, que representa a losstakeholders(interesados externos o internos), y elTeamque ejecuta el desarrollo y dems elementos relacionados con el. Durante cadasprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo y debe ser lo mas corta posible), el equipo crea un incremento de softwarepotencialmente entregable(utilizable). El conjunto de caractersticas que forma parte de cada sprint viene delProduct Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar (PBI, Product Backlog Item). Los elementos delProduct Backlogque forman parte del sprint se determinan durante la reunin deSprint Planning. Durante esta reunin, elProduct Owneridentifica los elementos delProduct Backlogque quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo conversa con el Product Owner buscando claridad y magnitud adecuadas (Cumpliendo el INVEST) para luego determinar la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.1Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que losrequisitosestn congelados durante el sprint.Scrum permite la creacin de equipos autoorganizados impulsando la co-localizacin de todos los miembros del equipo, y la comunicacin verbal entre todos los miembros y disciplinas involucrados en el proyecto.Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamadorequirements churn), y que los desafos impredecibles no pueden ser fcilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximacin pragmtica, aceptando que el problema no puede ser completamente entendido o definido, y centrndose en maximizar la capacidad del equipo de entregar rpidamente y responder a requisitos emergentes.Las caractersticas ms marcadas que se logran notar en Scrum seran: gestin regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptacin, retorno de inversin, mitigacin de riesgos, productividad y calidad, alineamiento entre cliente y equipo, por ltimo equipo motivado. Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado de manera regular en un conjunto de buenas prcticas para el trabajo en equipo y de esa manera obtener resultados posibles.Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fcil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

Artefactos XpA continuacin describimos los artefactos de Xp, entre los que se encuentran: Historias de Usuario, Tareas deIngenieray Tarjetas CRC. Historias de UsuarioRepresentan una brevedescripcindel comportamiento del sistema, emplea terminologa del cliente sin lenguaje tcnico, se realiza una por cada caracterstica principal del sistema, se emplean para hacer estimaciones de tiempo y para elplande lanzamientos, reemplazan un gran documento de requisitos y presiden la creacin de las pruebas de aceptacin.

Estas deben proporcionar slo el detalle suficiente como parapoderhacer razonable la estimacin de cunto tiempo requiere la implementacin de la historia, difiere de los casos de uso porque son escritos por el cliente, no por los programadores, empleando terminologa del cliente. "Las historias de usuario son ms "amigables" que los casos de uso formales".Las Historias de Usuario tienen tres aspectos: Tarjeta: en ella se almacena suficienteinformacinpara identificar y detallar la historia. Conversacin: cliente y programadores discuten la historia para ampliar los detalles (verbalmente cuando sea posible, pero documentada cuando se requiera confirmacin) Pruebas de Aceptacin: permite confirmar que la historia ha sido implementada correctamente.

Task card

Tarjetas CRC (Clase - Responsabilidad Colaborador)Estas tarjetas se dividen en tres secciones que contienen la informacin del nombre de la clase, sus responsabilidades y sus colaboradores. En la siguiente figura se muestra cmo se distribuye esta informacin.

Una clase es cualquierpersona, cosa, evento,concepto, pantalla o reporte. Las responsabilidades de una clase son las cosas que conoce y las que realiza, sus atributos ymtodos. Los colaboradores de una clase son las dems clases con las que trabaja en conjunto para llevar a cabo sus responsabilidades.En la prctica conviene tener pequeas tarjetas de cartn, que se llenarn y que son mostradas al cliente, de manera que se pueda llegar a un acuerdo sobre la validez de las abstracciones propuestas.Los pasos a seguir para llenar las tarjetas son los siguientes: Encontrar clases Encontrar responsabilidades Definir colaboradores Disponer las tarjetasPara encontrar las clases debemos pensar qu cosas interactan con el sistema (en nuestro caso el usuario), y qu cosas son parte del sistema, as como las pantallas tiles a la aplicacin (un despliegue de datos, una entrada de parmetros y una pantalla general, entre otros). Una vez que las clases principales han sido encontradas se procede a buscar los atributos y las responsabilidades, para esto se puede formular la pregunta Qu sabe la clase? y Qu hace la clase? Finalmente se buscan los colaboradores dentro de la lista de clases que se tenga.

Crticas a eXtreme ProgrammingAlgunas de las crticas recopiladas de Xp son: Xp tiene muchas crticas especialmente contra laprogramacinpor parejas por parte de muchos programadores con gran sentimiento de posesin del cdigo, piensan que ellos son los mejores conocedores de las herramientas y lenguajes que utilizan y que si alguien no lo entiende es por que no sabe lo suficiente. Tambin se critica elmitode las 40 horas semanales ya que es un lujo para las exigencias delmercado. Tambin hay crticas hacia Xp que dicen que solo puede funcionar con programadores muy buenos, como Kent Beck, que son capaces de hacer un buen diseo, sencillo y fcilmente extensible. Xp es mas unafilosofadetrabajoque unametodologa. Por otro lado ninguna de las practicas defendidas por Xp son invencin de estemtodo, Xp lo que hace es ponerlas todas juntas. Xp esta diseado paragruposde pequeos programadores, ms de 10 ya seria muy complicado, y mas aun para que estn en el mismo centro de trabajo.

Justificacion de los defensores de XPSe centra en base a: Los requerimientos Surgen cambios durante la marcha Es algo natural que pase eso Es inevitable Incluso deseable Creen que ADAPTARSE a los cambios de requisistosEs una aproximacion mejor y mas realista que definir los requerimientos al comienzo del proyectoY desp tener que invertir esfuerzos de ms si llegarana haber cambios de requisitos