Tarea 2 Metodologias Agiles

7/23/2019 Tarea 2 Metodologias Agiles

1/19

Software Avanzado Hugo Ricardo Ariza Arriaga

Tarea 2 2008-43473.

INTRODUCCIN

Es una metodologa que ha sido creada por Alistair Cockburn ).

l ha explorado a fondo los mtodos giles, haciendo nfasis en la familia de metodologas

Crystal.

Es una familia porque cree que los diferentes tipos de proyectos requieren diferentes tiposde metodologa.

l mira esta variacin a lo largo de dos ejes: El nmero de personas en el proyecto Las consecuencias de los errores.

DEFINICIN

Crystal es una metodologa de desarrollo de Software gil, aunque ms bien se laconsidera un Conjunto de metodologas para el desarrollo de softwarecaracterizadas por estar centradas en las personas que forman parte del equipoyen la reduccin al mximo del nmero de artefactos producidos.

El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos enmejorar sus habilidades y destrezas, as como tener polticas de trabajo en equipodefinidas.

CARACTERISTICAS DE LA METODOLOGA CRYSTAL

Una de sus caractersticas principales es la de vital importancia a las personas que

componen el equipo de un proyecto, y por tanto sus puntos de estudio son:

Aspecto humano del equipo Tamao de un equipo (nmero de componentes) Comunicacin entre los componentes Distintas polticas a seguir Espacio fsico de trabajo

RASGOS DE UN EQUIPO CRYSTAL

Una disminucin en el nmero de desarrolladores proporcionar una mejor comunicacinentre los mismos.

Trabajar en un mismo lugar dar lugar a una disminucin de gastos por conceptos decomunicacin.La mejora individual habilitar el paso a la mejora del equipo y por consecuente alproducto final.

VENTAJAS Y DESVENTAJAS DE LAS METODOLOGAS CRYSTAL

VENTAJAS

Son apropiadas para entornos ligeros Al estar diseada para el cambio experimenta reduccin de costo.


2/19


Tarea 2 2008-43473.

Presenta una planificacin ms transparente para los clientes. Se definen en cada iteracin cuales son los objetivos de la siguiente. Permite tener una muy til realimentacin de los usuarios.

DESVENTAJAS

Delimita el alcance del proyecto con el cliente.

METODOLOGA Y PRIORIDAD

Cada metodologa tiene unas prioridades a la hora de intentar alcanzar el xito de laaplicacin:

La familia de Crystal => Combinacin de productividad y tolerancia.

METODOLOGAS CRYSTAL

Crystal Clear Crystal Orange Crystal Orange Web Crystal Yellow Crystal Red Crystal Magenta Crystal Blue

Aunque solamente tres de ellos han sido realmente construidos y son usados en proyectosempresariales, institucionales etc.

DIFERENTES POLTICAS DE EQUIPO

o

Se utilizaran polticas diferentes para equipos diferentes.o

Codificacin por colores de Crystal:o

Dependiendo del tamao del equipo. Por ejemplo:


3/19


Tarea 2 2008-43473.

METODOLOG CRYST L CLE R

1.QUE ES CRYSTAL CLEAR?

o Crystal Clear es una familia de metodologas con un cdigo gentico comn.o

Puede ser usado en proyectos pequeos y como casi todos los otros mtodos.o Consiste en valores, tcnicas y procesos.o Da flexibilidad y prioriza la parte humana, apuntando a lograr eficiencia,

habitabilidad y confianza en los miembros del equipo.

EL CDIGO GENTICO

Consiste en:

Un modelo de juegos cooperativos

Este modelo ve el desarrollo de software como una serie de partidos que consistenen inventar y comunicar. Cada partido es diferente y tiene como objetivo entregarsoftware y preparase para el siguiente juego. Esto permite al equipo trabajarconcentrado y en forma efectiva con un objetivo claro cada vez.

PRIORIDADES DE CRYSTAL CLEAR

Crystal Clear establece un conjunto de prioridades y principios que sirven de gua para latoma de decisiones:


4/19


Tarea 2 2008-43473.

PROPIEDADES DE CRYSTAL CLEAR

Estas tres propiedades son "obligatorias" para Crystal Clear

Frecuencia en la entregas Comunicacin Crecimiento reflexivo

Estas propiedades pueden agregarse en la medida de las necesidades de cada grupo yproyecto.

Seguridad personal Concentracin Fcil acceso a usuarios claves Entorno tcnico con :

o Testing automatizadoo Integracin frecuente

PRINCIPIOS DE CRYSTAL CLEAR

El grado de detalle necesario en documentar requerimientos, diseo,planeamiento, etc, vara segn el proyecto.

Es imposible eliminar toda documentacin pero puede ser reducida logrando unmodo de comunicacin ms accesible, informal y precisa que pueda ser accedidopor todos los miembros del equipo.

El equipo ajusta constantemente su forma de trabajo para lograr que cadapersonalidad encaje con los otros miembros, con el entorno y las particularidadesde cada asignacin.


5/19


Tarea 2 2008-43473.

CARACTERISTICAS DE CRYSTAL CLEAR

ESTRATEGIAS DE CRYSTAL CLEAR

TCNICAS DE CRYSTAL CLEAR


6/19


Tarea 2 2008-43473.

ROLES Y ARTEFACTOS DE CRYSTAL CLEAR

PROCESO DE CRYSTAL CLEAR


7/19


Tarea 2 2008-43473.

Crystal clear enfatiza el proceso como un conjunto de ciclos anidados.

En la mayora de los procesos se percibe siete ciclos:

QUE ES CRYSTAL ORANGE?

Crystal Orange es una metodologa de gestin de proyectos que pertenece a lafamilia de Cristal. Crystal Orange est diseado para proyectos de tamaomediano, que van desde 25 hasta 50 personas en el equipo.

Un proyecto de Crystal Orange tiene una duracin de entre uno y dos aos. Se suele dividir en varios equipos con la cruz de grupos funcionales.

ROLES DE CRYSTAL ORANGE

1. Patrocinador

2. Experto en negocios

3. Experto en usos tcnicos

4. Analista/diseador de negocios

5. Gerente del proyecto

6. Arquitecto de software

7. Diseador lder

8. Programador lder

9.

Otros diseadores-programadores

10.Diseador de interfaz de usuario

11.Reusepoint

12.Escritor de cdigo

13.Probador

PRINCIPIOS DE CRYSTAL ORANGE

Crystal Orange sustenta seis principios comunes durante el proceso de desarrollo:


8/19


Tarea 2 2008-43473.

ACTIVIDADES DE CRYSTAL ORANGE

CTIVID D REVIS R

Opiniones objetivas se realizan en esta fase. Cada incremento incluye varias iteraciones.


9/19


Tarea 2 2008-43473.

EL EQUIPO DE CRYSTAL ORANGE

Crystal Orange propone una amplia gama de funciones clave, agrupados en varios

equipos, tales como la planificacin, la tutora, Arquitectura, Mentor, Tecnologa y Equipos

de Prueba.

Incluye:

Un diseador de interfaz de usuario

ingeniero en base de datos

Arquitecto

Programadores

Probadores

Diseo

Punto de reutilizacin

Escritores

METODOLOG OR NGE WEB

1.QUE ES ORANGE WEB?

Crystal Orange Web es una metodologa que hemos creado para eBucks.com, una

compaa de entrega de cdigo para la Web en un flujo continuo.


10/19


Tarea 2 2008-43473.

Se diferencia de Crystal Orange en que esta metodologa no se refiere a un

proyecto, pero con un flujo continuo de iniciativas que requieren una

programacin y con los resultados de cada iniciativa que se fusion con la

creciente base de cdigo utilizado por el pblico.

CRYSTAL ORANGE WEB ESTA EN PERIODO DE PRUEBA

Esta metodologa est todava en su periodo de prueba. La incluyo aqu porque:

Un nmero creciente de empresas estn encontrando en este tipo de situacin Esto representa la aplicacin ms reciente de las ideas de este libro Tiene una forma diferente de Crystal Orange

LAS 5 CATEGORIAS DE CRYSTAL ORANGE WEB


11/19


Tarea 2 2008-43473.

METODOLOGIA AGIL DYNAMIC SYSTEM DEVELOPMENT METHOD DSDM)

El mtodo de desarrollo de sistemas dinmicos (en ingls Dynamic Systems DevelopmentMethod o DSDM) es un mtodo que provee un framework para el desarrollo gil desoftware, apoyado por su continua implicacin del usuario en un desarrollo iterativo ycreciente que sea sensible a los requerimientos cambiantes, para desarrollar un sistema

que rena las necesidades de la empresa en tiempo y presupuesto.

Que es?

Historia

Fue desarrollado en el Reino Unido en los aos 90 por un consorcio DSDM un conjunto deproveedores y de expertos en la materia del desarrollo de sistemas de informacin (IS), estaes una organizacin no lucrativa y proveedor independiente, que posee y administra elframework.

METODOLOGIA AGIL DYNAMIC SYSTEM DEVELOPMENT METHOD

(DSDM)

La metodolgica DSDM es caracterizada por su rapidez de desarrollo atendiendo a lasdemandas de tecnologa de forma eficaz y eficiente previendo que transcurra muchotiempo y la tecnologa cambie.

Es una metodologa gil situada dentro de las RAD(rapid aplication development), es idealpara proyectos de sistemas de informacin cuyos presupuestos y agendas son muyapretadas.

Trabajo en equipo tanto los desarrolladores, los usuarios y los Stakeholders. El equipo de desarrollo puede tomar sus decisiones sin depender de autorizaciones

de sus superiores. El desarrollo es iterativo e incremental El equipo de desarrollo debe realizar entregas cortas pero frecuentemente, estas

entregas deben ser funcionales. Todos los cambios pueden ser revertibles, es decir, debemos tener una linea base y

a partir de ella crear funcionalidad, pero si no tenemos los resultados deseadospodemos regresar a la linea base nuevamente.

La verificacin de calidad debe existir a lo largo del proceso de desarrollo y nosolamente en al final del proyecto.

Las caractersticas de DSDM son:

Ningn sistema es construido a la perfeccin en el primer intento.


12/19


Tarea 2 2008-43473.

La entrega del proyecto deber ser a tiempo, respetando presupuesto yasegurando la calidad.

DSDM solo quiere que se complete la iteracin con la funcionalidad suficientecomo para que inicie la siguiente iteracin.

DSDM es utilizado en sistemas TI pero tambin pudiera ser utilizado para proyectos

en donde se requiera cambio de algn sistema aunque no sea TI. La evaluacin de riesgo debe estar enfocada en entregar funcionalidad no en el

proceso de desarrollo La estimacin debe estar basada en funcionalidad del negocio.

Desventajas:

Tiempo Dinero(presupuesto) Desarrollo Iterativo

Concesin de requisitos Participacin

Ventajas:

Roles o funciones:

Patrocinador ejecutivo (fondos y recursos) Visionario (inicializa y mantiene) Embajador de usuario (conocimiento de UF) Asesor de usuario (ideas diarias UF)

Gerente del proyecto(gestiona) Coordinador Tcnico (diseo y calidad) Jefe de equipo (mantener) Escribano (registra decisiones, acuerdos o requisitos) Roles de Especialistas (Personas Esp. de Apoyo)


13/19


Tarea 2 2008-43473.

METODO AGIL

ASD ADAPTIVE SOFTWARE DEVELOPMENT)

1. INTRODUCCION

La tcnica de Adaptive software Development fue desarrollada por Jim Highsmith y SamBayer a comienzos de 1990. Esta metodologa se adapta al cambio en lugar de luchar contral. Se basa en la adaptacin continua a circunstancias cambiantes. En ella no hay un ciclode planificacin-diseo-construccin del software, sino un ciclo especular colaborar-aprender.

2.

DEFINICION

El mtodo gil ASD (Adaptive Software Development) traducido en espaol significaDesarrollo Adaptable de Software es un modelo de implementacin de patrones gilespara desarrollo de software. Al igual que otras metodologas giles, su funcionamiento escclico y reconoce que en cada iteracin se producirn cambios e incluso errores.

El desarrollo de software adaptable (Adaptive Software Development - ASD) es unametodologa de desarrollo que hace nfasis en aplicar las ideas que se originaron en elmundo de los sistemas complejos, adaptacin continua del proceso al trabajo.

3. CARACTERISITICAS

Sus principales caractersticas del ASD son:

Iterativo. Orientado a los componentes de software (la funcionalidad que el producto va

a tener, caractersticas, etc.) ms que a las tareas en las que se va a alcanzardicho objetivo.

Tolerante a los cambios. Guiado por los riesgos La revisin de los componentes sirve para aprender de los errores y volver a

iniciar el ciclo de desarrollo

4. CICLO DE VIDA

ASD utiliza un "cambio orientado hacia el ciclo de vida", que tiene tres componentes queson: especular colaborar y aprender.

EspecularUna primera fase de iniciacin para establecer los principales objetivos y metas delproyecto en su conjunto y comprender las limitaciones (zonas de riesgo) con las que


14/19


Tarea 2 2008-43473.

operar el proyecto.

En ASD se realizan estimaciones de tiempo sabiendo que pueden sufrir desviaciones. Sinembargo, estas son necesarias para la correcta atencin de los trabajadores que semueven dentro de plazos de forma que puedan priorizar sus tareas.

Se decide el nmero de iteraciones para consumir el proyecto, prestando atencin a lascaractersticas que pueden ser utilizadas por el cliente al final de la iteracin. Son por tantonecesarios, marcar objetivos prioritarios dentro de las mismas iteraciones.

Estos pasos se puede volver a examinar varias veces antes de que el equipo y los clientesestn satisfechos con el resultado.

ColaborarEs la fase donde se centra la mayor parte del desarrollo manteniendo una componentecclica. Un trabajo importante es la coordinacin que asegure que lo aprendido por unequipo se transmite al resto y no tenga que volver a ser aprendido por los otros equipos.

AprenderLa ltima etapa termina con una serie de ciclos de colaboracin, su trabajo consiste encapturar lo que se ha aprendido, tanto positivo como negativo. Es un elemento crtico parala eficacia de los equipos.

Jim Highsmith identifica cuatro tipos de aprendizaje en esta etapa:

Calidad del producto desde un punto de vista del cliente . Es la nica medida legtima dexito, pero adems, dentro de las metodologas giles, los clientes tienen un valorimportante.

Calidad del producto desde un punto de vista de los desarrolladores . Se trata de laevaluacin de la calidad de los productos desde un punto de vista tcnico. Ejemplos deesto incluyen la adhesin a las normas y objetivos conforme a la arquitectura.

La gestin del rendimiento. Este es un proceso de evaluacin para ver lo que se haaprendido mediante el empleo de los procesos utilizados por el equipo.

Situacin del proyecto. Como paso previo a la planificacin de la siguiente iteracin delproyecto, es el punto de partida para la construccin de la siguiente serie de caractersticas.


15/19


Tarea 2 2008-43473.

5. VENTAJAS Y DESVENTAJAS

Ventajas

La tercera fase del ciclo de vida, revisin de los componentes, sirve para aprenderde los errores y volver a iniciar el ciclo de desarrollo.

Apunta hacia elRapid Application Development (RAD), el cual enfatiza velocidadde desarrollo para crear un producto de alta calidad, bajo mantenimientoinvolucrando al usuario lo ms posible.

Utiliza informacin disponible acerca de cambios para mejorar el comportamientodel software.

Promulga colaboracin, la interaccin de personas. Anticipa cambios y trata automticamente con ellos dentro de un programa en

ejecucin, sin la necesidad de un programador.

Desventajas

Aunque el ciclo entre el aprendizaje y la especulacin es bueno permitindonosentregar productos con alta calidad, la prolongacin de dicho ciclo por errores ocambios que no son detectados en reuniones anteriores afecta tanto a la calidaddel producto como a su costo total.

Dado a que es una metodologa gil implica no realizar procesos que sonrequeridos en las metodologas tradicionales o por lo menos no realizarlos enprocesos diferentes, lo cual implica que empresas grandes las cuales necesitanllevar un mayor control a procesos y personas, tener tareas asignadas a un estado oproceso especifico, y en las cuales dicho incremento de procesos no afectan en

gran medida al costo final del producto, para dichas empresas el elegir unametodologa tradicional resulta mucho mas rentable tanto por el gran volumen depersonal, de productos, y de costos que se manejan y para los cuales se tendr unmayor control.
http://en.wikipedia.org/wiki/Rapid_application_developmenthttp://es.wikipedia.org/wiki/Desarrollo_r%C3%A1pido_de_aplicacioneshttp://es.wikipedia.org/wiki/Desarrollo_r%C3%A1pido_de_aplicacioneshttp://en.wikipedia.org/wiki/Rapid_application_development


16/19


Tarea 2 2008-43473.

6.

CONCLUSION

Es un concepto que se puede usar en las empresas cambiantes como lo son lasvendedoras de productos al menudeo, que donde cada da estn rotando sus necesidadesde acuerdo a la oferta y demanda, en este tipo de desarrollo es probable que el cliente este

pidiendo adecuaciones continuamente, el ciclo de vida de esta metodologa es dirigible yfcil de implementar

Usado de manera adecuada esta metodologa (Adaptive Software Development) se puedealcanzar excelentes resultados pero debido a las caractersticas que maneja es ms factibleusarla para proyectos pequeos y medianos, para adquirir practica y experiencia para aspoder llegar alRapid Application Development (RAD) en donde tendremos productos dealta calidad.

Lean software development

La metodologa de desarrollo de software Lean, es una traduccin de los principios y lasprcticas de la forma de producir LEAN, hacia el rea del desarrollo de software.Inicialmente, originado en el Sistema de Produccin de Toyota y ahora, apoyado por unacorriente que est surgiendo desde la comunidad gil. Este mtodo ofrece todo un marcoterico slido y basado en la experiencia, para las prcticas giles de gestin.

Origen

El trmino de desarrollo de software Lean tiene origen en un libro del mismo nombre, escrito

por Mary Poppendieck y Tom Poppendieck. El libro presenta los tradicionales principios Leanen forma modificada, as como un conjunto de 22 instrumentos y herramientas y lascomparaciones con otras prcticas giles. La participacin de Mary y Tom en la comunidaddel desarrollo gil de software, incluyendo charlas en varias conferencias, ha dado lugar adichos conceptos, que son ms ampliamente aceptados en la comunidad de desarrollo gil.Ejemplos de ello sera la utilizacin del trmino "Lean-Agile" por empresas de consultoracomo NetObjectives Pace y CC, as como la inclusin de algunos de estos conceptos.

Los principios Lean

El desarrollo Lean puede resumirse en siete principios, similares a los principios demanufactura esbelta.

Eliminar los desperdicios

Todo lo que no aade valor al cliente se considera un desperdicio:

Cdigo y funcionalidades innecesarias Retraso en el proceso de desarrollo de software Requisitos poco claros
http://en.wikipedia.org/wiki/Rapid_application_developmenthttp://es.wikipedia.org/wiki/Desarrollo_r%C3%A1pido_de_aplicacioneshttp://es.wikipedia.org/wiki/Desarrollo_r%C3%A1pido_de_aplicacioneshttp://en.wikipedia.org/wiki/Rapid_application_development


17/19


Tarea 2 2008-43473.

Burocracia Comunicacin interna lenta

Con el fin de poder eliminar los desperdicios deberamos ser capaces de reconocerlos yencontrarlos. Si alguna actividad podra ser excluida o el mismo resultado podra ser logradosin ella, esta actividad es considerada un desperdicio. Los procesos y funcionalidades extra

que no son usados por el cliente son desperdicios. Las esperas ocasionadas por otrasactividades, equipos o procesos son desperdicio. Los defectos y la baja calidad son losdesperdicios. Los gastos de gestin que no producen valor real son desperdicios. Se utilizauna tcnica llamada value stream mapping (o mapa de flujo de valor) para distinguir yreconocer los desperdicios. El segundo paso consiste en sealar las fuentes de losdesperdicios y eliminarlos. Lo mismo debe hacerse iterativamente hasta que incluso losprocesos y procedimientos que parecan esenciales sean eliminados.

Ampliar el aprendizaje

El desarrollo de software es un proceso de aprendizaje continuo, a ello se le suman los retosde los equipos de desarrollo y el tamao del producto final. El mejor enfoque para encararuna mejora en el ambiente de desarrollo de software es ampliar el aprendizaje. Laacumulacin de defectos debe evitarse ejecutando las pruebas tan pronto como el cdigoest escrito en lugar de aadir ms documentacin o planificacin detallada. Las distintasideas podran ser probadas escribiendo cdigo e integrndolo. El proceso de recopilacinde requisitos de usuarios podra simplificarse mediante la presentacin de las pantallas delos usuarios finales para que estos puedan hacer sus aportes. El proceso de aprendizaje esacelerado con el uso iteraciones cortas cada una de ellas acompaada de refactorizacin ysus pruebas de integracin.

Incrementando la retroalimentacin mediante reuniones cortas con los clientes se ayuda a

determinar la fase actual de desarrollo y se ajustan los esfuerzos para introducir mejoras enel futuro. Durante las reuniones, tanto los clientes como el equipo de desarrollo, logranaprender sobre el alcance del problema y buscan posibles soluciones para un mejordesarrollo. Por lo tanto, los clientes comprenden mejor sus necesidades basndose en elresultado de los esfuerzos del desarrollo y los desarrolladores aprenden a satisfacer mejorestas necesidades.

Otra idea para ampliar el aprendizaje es a travs de la integracin del cliente en el ambientede desarrollo para concentrar la comunicacin en las soluciones futuras y no en lassoluciones posibles, promoviendo as el nacimiento de la solucin a travs del dilogo conel cliente.

Decidir lo ms tarde posible

El desarrollo de software est siempre asociado con cierto grado de incertidumbre, losmejores resultados se alcanzan con un enfoque basado en opciones por lo que se puedenretrasar las decisiones tanto como sea posible hasta que stas se basen en hechos y no ensuposiciones y pronsticos inciertos. Cuanto ms complejo es un proyecto, ms capacidadpara el cambio debe incluirse en ste, as que debe permitirse el retraso de los compromisos


18/19


Tarea 2 2008-43473.

importantes y cruciales. El enfoque iterativo promueve este principio: la capacidad deadaptarse a los cambios y corregir los errores, ya que un error podra ser muy costoso si sedescubre despus de la liberacin del sistema.

Un enfoque de desarrollo de software gil puede llevarles opciones rpidamente a losclientes, lo que implica, retrasar algunas decisiones cruciales hasta que los clientes hayan

reconocido mejor sus necesidades. Esto tambin permite la adaptacin tarda a los cambiosy previene las costosas decisiones delimitadas por la tecnologa. Esto no significa que nohaya planificacin involucrada en el proceso, por el contrario, las actividades de planificacindeben centrarse en las diferentes opciones y se les adapta a la situacin actual; as como, sedeben clarificar las situaciones confusas estableciendo las pautas para una accin rpida.Evaluar las diferentes opciones es eficaz tan pronto como queda claro que ellos no son libres,pero proporcionando la flexibilidad necesaria para una tarda toma de decisiones.

Reaccionar tan rpido como sea posible

En la era de la rpida evolucin tecnolgica, no es el ms grande quien sobrevive, sino elms rpido. Cuanto antes se entrega el producto final sin defectos considerables ms prontose pueden recibir comentarios y se incorporan en la siguiente iteracin. Cuanto ms cortassean las iteraciones, mejor es el aprendizaje y la comunicacin dentro del equipo. Sinvelocidad, las decisiones no pueden ser postergadas. La velocidad asegura el cumplimientode las necesidades actuales del cliente y no lo que ste requera para ayer. Esto les da laoportunidad de demorarse pensando lo que realmente necesitan, hasta que adquieran unmejor conocimiento. Los clientes valoran la entrega rpida de un producto de calidad.

La ideologa de produccin Just In Time podra aplicarse a programas de desarrollo,reconociendo sus necesidades especficas y el ambiente. Lo anterior se logra mediante lapresentacin de resultados, la necesidad de dejar que el equipo se organizarse y dividiendo

las tareas para lograr el resultado necesario para una iteracin especfica.Al principio, el cliente dispone los requisitos necesarios. Esto podra ser simplementepresentar los requisitos en pequeas fichas o historias y los desarrolladores estimarn eltiempo necesario para la aplicacin de cada tarjeta. As, la organizacin del trabajo cambiaen sistema autopropulsado: cada maana durante una reunin inicial cada miembro delequipo evala lo que se ha hecho ayer, lo que hay que hacer hoy y maana y pregunta porcualquier nueva entrada necesaria de parte de sus colegas o del cliente. Esto requiere latransparencia del proceso, que es tambin beneficioso para la comunicacin del equipo.

Otra idea clave del Sistema de Desarrollo de Producto de la Toyota se establece a base dediseo. Si un nuevo sistema de frenos es necesario para un coche, por ejemplo, tres equipos

pueden disear soluciones al mismo problema. Cada equipo aprende sobre el ambiente delproblema y diseos de una posible solucin. Cuando una solucin se considera irrazonable,se desecha. Al final de un periodo, los diseos sobrevivientes se comparan y se elige uno,quiz con algunas modificaciones basadas en el aprendizaje de los dems, un gran ejemplode compromiso aplazado hasta el ltimo momento posible. Las decisiones en el softwaretambin podran beneficiarse de esta prctica para minimizar el riesgo provocado por unsolo gran diseo realizado por adelantado.


19/19


Tarea 2 2008-43473.

Potenciar el equipo

Ha habido una creencia tradicional en la mayora de las empresas acerca de la toma dedecisiones en la organizacin: los administradores dicen a los trabajadores cmo hacer supropio trabajo. En una tcnica llamada Work-Out, los roles cambian: a los directivos se lesensea a escuchar a los desarrolladores, de manera que stos puedan explicar mejor qu

acciones podran tomarse, as como ofrecer sugerencias para mejoras. Los directores deproyecto ms experimentados simplemente han declarado la clave de xito de los proyectos:"Buscar la buena gente y dejarles hacer su propio trabajo".

Otra creencia errnea ha sido considerar a las personas como recursos. Las personaspodran ser los recursos desde el punto de vista de una hoja de datos estadsticos, pero enel desarrollo de software, as como cualquier organizacin de negocios, las personasnecesitan algo ms que la lista de tareas y la seguridad de que no ser alterada durante larealizacin de las tareas. Las personas necesitan motivacin y un propsito superior para elcual trabajar: un objetivo alcanzable dentro de la realidad con la garanta de que el equipopuede elegir sus propios compromisos. Los desarrolladores deberan tener acceso a losclientes; el jefe de equipo debe proporcionar apoyo y ayuda en situaciones difciles, as como

asegurarse de que el escepticismo no arruine el espritu de equipo.

Crear la integridad

El siempre exigente cliente debe tener una experiencia general del sistema. A esto se le llamapercepcin de integridad: Cmo es publicitado, entregado, implementado y accedido? Essu uso intuitivo? Precio? Hasta qu punto resuelve los problemas? Integridad Conceptualsignifica que los componentes separados del sistema funcionan bien juntos, como en untodo, logrando equilibrio entre la flexibilidad, sostenibilidad, eficiencia y capacidad derespuesta. Esto podra lograrse mediante la comprensin del dominio del problema y

resolvindolo al mismo tiempo, no secuencialmente. La informacin necesaria es recibidapor los pequeos lotes, no en una vasta cantidad y con una preferible comunicacin cara acara, sin ninguna documentacin por escrito. El flujo de informacin debe ser constante enambas direcciones, a partir del cliente a los desarrolladores y viceversa, evitando as la grany estresante cantidad de informacin despus de un largo periodo de desarrollo en elaislamiento.

Una de las maneras ms saludables hacia una arquitectura integrante es la refactorizacin.Cuantas ms funcionalidades se aaden a las del sistema, ms se pierde del cdigo basepara futuras mejoras. As como en la Programacin extrema (XP), la refactorizacin esmantener la sencillez, la claridad, la cantidad mnima de funcionalidades en el cdigo. Lasrepeticiones en el cdigo son signo de un mal diseo de cdigo y deben evitarse. El

completo y automatizado proceso de construccin debe ir acompaada de una suitecompleta y automatizada de pruebas, tanto para desarrolladores y clientes que tengan lamisma versin, sincronizacin y semntica que el sistema actual. Al final, la integridad debeser verificada con una prueba global, garantizando que el sistema hace lo que el clienteespera que haga. Las pruebas automatizadas tambin son consideradas como parte delproceso de produccin y, por tanto, si no agregan valor deben considerarse residuos. Laspruebas automatizadas no deberan ser un objetivo, sino, un medio para un fin;especficamente para la reduccin de defectos.

Tarea 2 Metodologias Agiles

Documents

Transcript of Tarea 2 Metodologias Agiles