Conferencia MANIFIESTO AGIL

8/7/2019 Conferencia MANIFIESTO AGIL

1/66

MANIFIESTO PARA EL DESARROLLO GIL DE SOFTWARE

DISEO DE SOFTWARE INVERSO Y EXPERIMENTACIN

CONFERENCIAS TCNICAS DSN_XP SOBRE INGENIERA DE SOFTWARE

CONFERENCIA DICTADA EN LOJA ENERO 2011


2/66

El manifiesto gil

Estamos descubriendo mejores formas de desarrollar software tanto por nuestra

propia experiencia como ayudando a terceros.

A travs de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentacin extensiva

Colaboracin con el cliente sobre negociacin contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos ms los de la

izquierda.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries,

Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber

Jeff Sutherland, Dave Thomas

2001


3/66

Quines firman el manifiesto gil?



Kent Beck

PROGRAMACIN EXTREMA:

Inclusin del cliente al equipo, historias de usuario, jugar ala planificacin, pequeas liberaciones, pruebas deaceptacin, espacios abiertos, diseo dirigido por pruebas,

comunicacin por metforas, diseo simple, recodificacincontinua, integracin continua, programacin en parejas,cdigo fuente comunitario, estndares de codificacin,ritmo sostenible.


4/66




James Grenning

RENACIMIENTO DEL SOFTWARE:

Programacin extrema, diseo dirigido por pruebas, pokerde planificacin, historias de usuario, pruebas automticas,integracin continua, desarrollo iterativo e incremental,

negociacin con el cliente sobre tiempos y alcances,pruebas de aceptacin, creacin de la visin del producto ydesarrollo por caractersticas.


5/66




Robert C Martin

ENSEANZA DE OBJETOS:

Diseo simple orientado a objetos, principio deresponsabilidad nica, principio de abierto-cerrado, principiode sustitucin de Liskov, principio de segregacin de interfaz,

principio de inversin de dependencia, programacinextrema, diseo dirigido por pruebas de aceptacin, pruebasunitarias, formacin de equipos multidisciplinares.


6/66




Mike Beedle

E-ARQUITECTURA:

Adopcin de SCRUM, adaptacin y aprendizaje, creacin deequipos multidisciplinares para soportar el CAOS, entornosaltamente productivos, adopcin de cambios culturales en la

organizacin.


7/66




Jim Highsmith

TRABAJOS PENSANTES:

Liderazgo adaptativo, imaginacin adaptativa, colaboracincon el negocio, adopcin de SCRUM, trabajo en equipo,formacin de lderes, formacin de ejecutivos, desarrollo

iterativo e incremental en perodos cortos de tiempo, retornode inversin, cadenas de valor productivas para el negocio.


8/66




Steve Mellor

MTODO DE SHLAER-MELLOR:

Diseo orientado a objetos, desarrollo dirigido por modelos,uso de UML para el ciclo de vida, uso de lenguaje especficodel dominio, meta modelado de la arquitectura, intercambio

de metadata con XML, computacin con objetosempresariales distribuidos.


9/66




Arie vanBennekum

MTODO DE DESARROLLO DE SISTEMAS DINMICOS:

Desarrollo rpido de aplicaciones, marco de trabajo paragestin de proyectos tecnolgicos con presupuestos fijos ytiempos cortos de desarrollo limitados por el mercado,

enfoque para retorno de inversin.


10/66




Andy Hunt

PROGRAMADORES PRAGMTICOS:

Aprendizaje y pensamiento pragmtico, estudio delcomportamiento humano en desarrolladores y miembros delnegocio, desarrollo de perfiles adecuados en equipos

multidisciplinares, estudio de la resistencia al cambio y lanecesidad de abrazar el cambio continuo.


11/66




Ken Schwaber

SCRUM:

Diseo de la metodologa SCRUM y del mtodo para lagestin de proyectos tecnolgicos de software, definicin deartefactos y principios para el desarrollo iterativo e

incremental de forma gil, estudio de la ingeniera desoftware y de los mtodos predictivos que conducen alfracaso de los proyectos de desarrollo.


12/66




Alistair Cockburn

METODOLOGA CRYSTAL:

Estudio del equipo enfocado en el manejo del talentohumano, desarrollo de perfiles adecuados en equiposmultidisciplinares, factores de comunicacin entre equipos,

incremento del retorno de inversin, entrega temprana deresultados, anticipacin y adaptacin, manejo de laincertidumbre y de las expectativas, desarrollo de lacreatividad e innovacin.


13/66




Ron Jeffries


Adopcin de XP en proyectos tecnolgicos, estudio delrechazo al cambio, integracin de principios de XP y SCRUMen el desarrollo de software, diseo dirigido por el dominio,

diseo dirigido por pruebas, integracin continua.


14/66




Jeff Sutherland

SCRUM:

Diseo de la metodologa SCRUM y del mtodo para lagestin de proyectos tecnolgicos de software, definicin deartefactos y principios para el desarrollo iterativo e

incremental de forma gil, estudio de la ingeniera desoftware y de los mtodos predictivos que conducen alfracaso de los proyectos de desarrollo.


15/66




WardCunningham


Adopcin de XP en proyectos tecnolgicos, estudio delrechazo al cambio, integracin de principios de XP y SCRUMen el desarrollo de software, diseo dirigido por el dominio,

diseo dirigido por pruebas, integracin continua.


16/66




Jon Kern

PROCESOS ADAPTATIVOS:

Programacin orientada a objetos, metodologa COAD, diseocon Java, UML, herramienta de modelado TOGETHERSOFT,interaccin con el equipo, resultados tangibles y frecuentes,

involucramiento del cliente, adaptacin al cambio.


17/66




Dave Thomas

LABORATORIOS IBM DE TECNOLOGA INTERNACIONAL DEOBJETOS:

Tecnologa orientada a componentes y objetos, estrategias denegocios, desarrollo de productos software basados en

componentes y marcos de trabajo.


18/66




Martin Fowler

TRABAJOS PENSANTES:

Liderazgo adaptativo, imaginacin adaptativa, colaboracincon el negocio, investigacin de mtodos y mejoras para eldiseo y desarrollo de software, patrones de diseo, diseo

orientado al dominio, integracin continua, pruebas unitarias yde integracin.


19/66




Brian Marick

ALIANZA GIL:

Desarrollo gil de software, disciplina y perfiles en trabajos conequipos multidisciplinares, diseo dirigido por ejemplos,desarrollo iterativo e incremental, utilizacin de herramientas

para acelerar el proceso productivo del equipo..


20/66

Los creadores del manifiesto para el desarrollo gil desoftware poseen una vasta experiencia en proyectosexitosos de software, sin embargo, todas estas buenas

prcticas que han sido descubiertas a lo largo de laexistencia de la industria son la base para una nuevafilosofa de trabajo.

El movimiento gil

Estamos cansados de la forma clsica

de producir software :o)


21/66

CMO SE ADOPTA EL MANIFIESTO GIL ENLA GESTIN DE PROYECTOS SOFTWARE?

Nuestra experiencia adquirida en proyectos


22/66

Los proyectos se desarrollan en torno a individuos motivados.Hay que darles el entorno y el apoyo que necesitan y confiarles

la ejecucin del trabajo.

A travs de este trabajo hemos aprendido a

valorar: Individuos e interacciones sobre

procesos y herramientas

Usualmente en la gestin de proyectos, no se toma en cuenta a este principio, elelemento humano es considerado como un recurso, por lo tanto, es sujeto decontrol. Tanto el cliente, como el usuario y el equipo de desarrollo son parte delelemento humano y entre elementos humanos es necesaria la presencia de unentorno apropiado para la transferencia de ideas y conceptos sobre un evento en undeterminado contexto.


23/66

As adoptamos este principio

CRECIMIENTO, CUIDADO Y RESPETO POR EL EQUIPO HUMANO Y SU ENTORNONATURAL


24/66

El mtodo ms eficiente y efectivo de comunicar informacin alequipo de desarrollo y entre sus miembros es la conversacin

cara a cara.




Usualmente en la gestin de proyectos, no se toma en cuenta a este principio, elelemento humano es considerado como responsable de una actividad, por lo tanto,sujeto a evaluacin. Tanto el cliente, como el usuario y el equipo de desarrollo son

parte del elemento humano y entre elementos humanos es necesaria la presencia deun lenguaje apropiado para la transferencia de ideas y conceptos sobre un mismoresultado o expectativa.


25/66


DILOGOS CONTINUOS FACE TO FACE Y FACE TO FACES


26/66

A intervalos regulares el equipo reflexiona sobre cmo ser msefectivo y a continuacin ajustar y perfeccionar su

comportamiento en consecuencia.




Usualmente en la gestin de proyectos, no se toma en cuenta a este principio, elelemento humano es propenso a cometer errores, por lo tanto, sujeto a sanciones.Tanto el cliente, como el usuario y el equipo de desarrollo son parte del elementohumano y entre elementos humanos es necesario reconocer al error como factorimportante dentro del proceso de aprendizaje y mejoramiento continuo.


27/66


RETROSPECTIVAS Y COMPROMISOS


28/66

La simplicidad, o el arte de maximizar la cantidad de trabajo norealizado, es esencial.




Usualmente en la gestin de proyectos, no se toma en cuenta a este principio, elelemento humano es un elemento productivo, por lo tanto, sujeto a explotacin.Tanto el cliente, como el usuario y el equipo de desarrollo son parte del proceso

productivo por lo que es evidente la necesidad de equilibrar esfuerzos medianteequipos multidisciplinares comprometidos con su trabajo que colaboran entre s deforma simple, con modelos simples y acciones simples.


29/66


LA HONESTIDAD ES BIENVENIDA SIEMPRE


30/66

El uso de las triadas en la gestin de proyectos

de desarrollo de software

Existen 3 fuerzas bsicas detrs de un proyecto, cualquier alteracin a una de estasfuerzas se propaga en las otras 2, la conjugacin correcta de las mismas determina lacalidad del producto final.

Cada fuerza es asociada a una variable de clculo, el tiempo se convierte encronograma, los recursos en costos y el alcance en funcionalidades, la resultante semide en el xito o fracaso del proyecto.El equipo de desarrollo es responsable del alcance, el tiempo y los recursos sonasignados al cliente, el proceso creativo del software tiene que ser transformado enretorno de inversin de acuerdo al esfuerzo aplicado a una funcionalidad especfica.


31/66



Existen 3 fuerzas bsicas detrs del diseo de un producto, cualquier alteracin a unade estas fuerzas se propaga en las otras 2, la conjugacin correcta de las mismasdetermina la demanda del producto final.

Cada fuerza es asociada a una variable de clculo, el producto se convierte enesfuerzo, el mercado en ingresos y la administracin en costos, la resultante semiden en el xito o fracaso del producto.El equipo de desarrollo es responsable del producto, la administracin y el mercadoson asignados al cliente, el costo de fabricacin del software tiene que sertransformado en la optimizacin de recursos de acuerdo al esfuerzo aplicado a una

funcionalidad especfica.


32/66



Existen 3 fuerzas bsicas detrs de un proyecto software, cualquier alteracin a unade estas fuerzas se propaga en las otras 2, la conjugacin correcta de las mismasdetermina el entorno de trabajo.Cada fuerza es asociada a una perspectiva de inters en el xito del proyecto, el

software determina la usabilidad, el business determina el factor de oportunidad y elteam determina el compromiso de cada uno de los miembros del equipomultidisciplinar. El adecuado proceso de estimacin de esfuerzos tiene que serequilibrado para evitar cansancio en el team (sobrecarga de trabajo) ya que unequipo cansado y no motivado repercute en el entorno de trabajo, en la calidad delproducto y en la entrega a tiempo de las funcionalidades.


33/66

CMO SE ADOPTA EL MANIFIESTO GIL ENLA EMPRESA?



34/66

Entregamos software funcional frecuentemente, entre dossemanas y dos meses, con preferencia al periodo de tiempo

ms corto posible


valorar: Software funcionando sobre

documentacin extensiva

Usualmente en la gestin de proyectos, no se toma en cuenta apropiadamente esteprincipio, el factor de oportunidad est determinado por la estrategia adecuadaadoptada por el negocio, la adopcin de la tecnologa requiere de un correctoentendimiento del procesamiento de la informacin para la toma de decisiones. Elequipo de desarrollo es responsable del cdigo fuente y de su diseo.


35/66


LA LIBERACIN DEL PRODUCTO SE REALIZA POR VERSIONES

LIBERACIN INTERNA DEL PROTOTIPOINICIAL

LIBERACIN INTERNA DEL PROTOTIPOFINAL

LIBERACIN PBLICA DEL PROTOTIPOFINAL

ESTAMOS ESTABILIZANDO LA SALIDA APRODUCCIN


36/66

El software funcionando es la medida principal de progreso




Usualmente en la gestin de proyectos, no se toma en cuenta apropiadamente esteprincipio, el software debe hacer lo que dice puede hacer, para determinar estecomportamiento del software se requiere un gran entendimiento del producto quese desea construir o mantener. El equipo de desarrollo es responsable de laconcepcin modular del producto y de su arquitectura.


37/66


LA VISIBILIDAD ES BIENVENIDA SIEMPRE


38/66

La atencin continua a la excelencia tcnica y al buen diseomejora la agilidad




Usualmente en la gestin de proyectos, no se toma en cuenta apropiadamente esteprincipio, los criterios de diseo y arquitectura son transparentes para el negociodurante el proceso de estimacin de esfuerzo, se requiere disciplina para aplicar este

principio. El equipo de desarrollo es responsable de la definicin de estndares deprogramacin incluyendo la adopcin de una escuela de diseo y un entendimientoapropiado del lenguaje de programacin.


39/66


TODA IDEA ES BIENVENIDA SIEMPRE


40/66

Las mejores arquitecturas, requisitos y diseos emergen deequipos auto-organizados




Usualmente en la gestin de proyectos, no se toma en cuenta apropiadamente esteprincipio, la auto organizacin es producto de un adecuado balanceo deresponsabilidades entre los miembros de equipos multidisciplinares. El equipo dedesarrollo es responsable de realizar mejoras al diseo de forma continua y de quedichos cambios no afecten la coordinacin de esfuerzos.


41/66


EQUIPOS MULTIDISCIPLINARES

BASE DE DATOS DEVELOPERS & QA

NEGOCIO Y PRODUCTO ARQUITECTURA


42/66






Usualmente en la gestin de proyectos, no se toma en cuenta a este principio, unavez que se ha creado un producto software, el proceso de mantenimiento no esconsiderado dentro de las tareas planificadas y si se desea mantener un producto ya

realizado no existe una estrategia adecuada de refactorizacin del producto. Elequipo de desarrollo es responsable de tomar decisiones sobre el diseo yconstruccin del producto de forma continua.


43/66


LA ESTIMACIN ADECUADA ES BIENVENIDA SIEMPRE

REPORTES DE CODIFICACIN REPORTES DE AVANCES

REPORTES DE DESARROLLO REPORTES DE ARQUITECTURA Y DATABASE


44/66




45/66




46/66

CMO SE NEGOCIA CON EL CLIENTE BAJOUN DESARROLLO GIL?



47/66

A d i i i


48/66



d b h d d


49/66

Los responsables de negocio y los desarrolladores trabajamosjuntos de forma cotidiana durante todo el proyecto


valorar: Colaboracin con el cliente sobre

negociacin contractual

Usualmente en la gestin de proyectos, no se toma en cuenta apropiadamente esteprincipio, la participacin activa del cliente se pone de manifiesto en la transferenciade conocimientos y en la demanda de funcionalidades. Es responsabilidad de todos

el definir un canal adecuado de comunicacin (metforas y criterios de aceptacin)para un correcto entendimiento del producto y del impacto en el negocio en suimplantacin.

A d t t i i i


50/66



A d b j h did


51/66

Los procesos giles promueven el desarrollo sostenible.




Usualmente en la gestin de proyectos, no se toma en cuenta a este principio, undesarrollo sostenible va ms all de una relacin contractual, resulta comoconsecuencia de un perfecto entendimiento entre las partes sobre un mismo objetivo.

Es responsabilidad del equipo de desarrollo el buscar los medios ms adecuados paramantener ntegra la confianza del cliente mediante entregas tempranas de softwarefuncionando que genera retorno de inversin para el cliente.

A d t t i i i


52/66


EQUIPOS MULTIDISCIPLINARES

A d b j h did


53/66






Usualmente en la gestin de proyectos, no se toma en cuenta a este principio, lavisibilidad se utiliza para transparentar el proceso de desarrollo, tanto el cliente comoel equipo de desarrollo encuentran en las mtricas indicadores que sirven para ajustar

continuamente el esfuerzo asignado. Es responsabilidad del equipo de desarrollo elmantener actualizada esta informacin para una adecuada gestin del proyecto.



54/66


CONTROL DIARIO DE ACTIVIDADES Y RETROSPECTIVAS DIARIAS


55/66



Existen 3 fuerzas bsicas detrs de un proyecto, cualquier alteracin a una de estasfuerzas se propaga en las otras 2, la conjugacin correcta de las mismas determina lausabilidad del producto final.

Cada fuerza es asociada a una fuente de informacin, el stakeholder provee lasnecesidades de requerimientos para la toma de decisiones, el usuario provee elconocimiento y el proceso que se desea abstraer, el desarrollador provee las mejorasal proceso y la simplicidad de la herramienta. Es responsabilidad del equipo dedesarrollo el comprender y balancear estos requerimientos en funcionalidades yservicios para el uso correcto del producto.


56/66



Existen 3 fuerzas bsicas detrs de un producto, cualquier alteracin a una de estasfuerzas se propaga en las otras 2, la conjugacin correcta de las mismas determina lacalidad del producto final.Cada fuerza es asociada a un factor de diseo, las historias de usuario capturan lasnecesidades del producto por parte de los usuarios (retorno de inversin), loscriterios de aceptacin capturan las necesidades del stakeholder principal(priorizacin) y las sentencias de trabajo definen sin ambigedades lasespecificaciones del software (esfuerzo). Es responsabilidad del equipo de desarrolloel verificar que cada historia posea los tres indicadores para una adecuada gestin

del proyecto.


57/66

CMO SE SOPORTA EL CAMBIO EN LAGESTIN DE PROYECTOS?


d b h d d l


58/66

Aceptamos que los requisitos cambien, incluso en etapastardas del desarrollo



Usualmente en la gestin de proyectos, no se toma en cuenta este principio, laconcepcin de gil descasa especficamente en este principio, a diferencia de laescuela tradicional, el cambio continuo es la mejor estrategia de desarrollo, las

buenas ideas no surgen exclusivamente al inicio de un proyecto sino que aparecen delmismo entendimiento del producto durante su fabricacin . Es

responsabilidad del equipo de desarrollo el aplicar un diseo sencillo para el controlde cambios dentro de la configuracin modular del producto.



59/66


ADOPCIN DE SCRUM Y XP

A d b j h did l


60/66

Los procesos giles aprovechan el cambio para proporcionarventaja competitiva al cliente



Usualmente en la gestin de proyectos, no se toma en cuenta apropiadamente esteprincipio, la ventaja competitiva para el cliente implica de por s la involucracin delcliente en el proceso de desarrollo, tanto el cliente como el equipo de desarrollo sonresponsables del xito o fracaso de un proyecto, pese a lo dicho, el fracaso representapara el equipo de desarrollo una ventaja a favor del aprendizaje y de la mejoracontinua. Es responsabilidad del cliente el definir adecuadamente el impacto de uncambio en la gestin de su negocio.



61/66


PLANIFICACIN CONTINUA DEL PRODUCTO

A t d t t b j h did l


62/66

Los promotores, desarrolladores y usuarios debemos sercapaces de mantener un ritmo constante de forma indefinida



Usualmente en la gestin de proyectos, no se toma en cuenta apropiadamente esteprincipio, el ritmo constante se adquiere en base a un adecuado proceso deestimacin de esfuerzos, aprendizaje y compromiso. Es responsabilidad del equipo de

desarrollo el gestionar adecuadamente el proceso de construccin mediante el uso demejores prcticas, marcos de trabajo, patrones de diseo y recodificacin continua.



63/66


TRANSPARENCIA, INSPECCIN, ADAPTACIN

A t d t t b j h did l


64/66





Usualmente en la gestin de proyectos, no se toma en cuenta apropiadamente esteprincipio, la ventaja competitiva para el cliente implica de por s la involucracin delcliente en el proceso de desarrollo, tanto el cliente como el equipo de desarrollo sonresponsables del xito o fracaso de un proyecto, pese a lo dicho, el fracaso representapara el equipo de desarrollo una ventaja a favor del aprendizaje y de la mejoracontinua. Es responsabilidad del cliente el definir adecuadamente el impacto de uncambio en la gestin de su negocio.



65/66


TRABAJO COMO UN SOLO EQUIPO


66/66

Follow DSN_XP

En twitter: @dsn_xp

En Facebook: /dsnxp

E-mail: [email protected]

Conferencia MANIFIESTO AGIL

Documents

Transcript of Conferencia MANIFIESTO AGIL