SlideShare una empresa de Scribd logo
1 de 66
Descargar para leer sin conexión
MANIFIESTO PARA EL DESARROLLO ÁGIL DE SOFTWARE
DISEÑO DE SOFTWARE INVERSO Y EXPERIMENTACIÓN
CONFERENCIAS TÉCNICAS DSN_XP SOBRE INGENIERÍA DE SOFTWARE
CONFERENCIA DICTADA EN LOJA ENERO 2011
El manifiesto ágil <?>
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
A través de este trabajo hemos aprendido a valorar:
• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más 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
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Kent Beck
PROGRAMACIÓN EXTREMA:
Inclusión del cliente al equipo, historias de usuario, jugar a
la planificación, pequeñas liberaciones, pruebas de
aceptación, espacios abiertos, diseño dirigido por pruebas,
comunicación por metáforas, diseño simple, recodificación
continua, integración continua, programación en parejas,
código fuente comunitario, estándares de codificación,
ritmo sostenible.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
James Grenning
RENACIMIENTO DEL SOFTWARE:
Programación extrema, diseño dirigido por pruebas, poker
de planificación, historias de usuario, pruebas automáticas,
integración continua, desarrollo iterativo e incremental,
negociación con el cliente sobre tiempos y alcances,
pruebas de aceptación, creación de la visión del producto y
desarrollo por características.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Robert C Martin
ENSEÑANZA DE OBJETOS:
Diseño simple orientado a objetos, principio de
responsabilidad única, principio de abierto-cerrado, principio
de sustitución de Liskov, principio de segregación de interfaz,
principio de inversión de dependencia, programación
extrema, diseño dirigido por pruebas de aceptación, pruebas
unitarias, formación de equipos multidisciplinares.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Mike Beedle
E-ARQUITECTURA:
Adopción de SCRUM, adaptación y aprendizaje, creación de
equipos multidisciplinares para soportar el CAOS, entornos
altamente productivos, adopción de cambios culturales en la
organización.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Jim Highsmith
TRABAJOS PENSANTES:
Liderazgo adaptativo, imaginación adaptativa, colaboración
con el negocio, adopción de SCRUM, trabajo en equipo,
formación de líderes, formación de ejecutivos, desarrollo
iterativo e incremental en períodos cortos de tiempo, retorno
de inversión, cadenas de valor productivas para el negocio.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Steve Mellor
MÉTODO DE SHLAER-MELLOR:
Diseño orientado a objetos, desarrollo dirigido por modelos,
uso de UML para el ciclo de vida, uso de lenguaje específico
del dominio, meta modelado de la arquitectura, intercambio
de metadata con XML, computación con objetos
empresariales distribuidos.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Arie van
Bennekum
MÉTODO DE DESARROLLO DE SISTEMAS DINÁMICOS:
Desarrollo rápido de aplicaciones, marco de trabajo para
gestión de proyectos tecnológicos con presupuestos fijos y
tiempos cortos de desarrollo limitados por el mercado,
enfoque para retorno de inversión.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Andy Hunt
PROGRAMADORES PRAGMÁTICOS:
Aprendizaje y pensamiento pragmático, estudio del
comportamiento humano en desarrolladores y miembros del
negocio, desarrollo de perfiles adecuados en equipos
multidisciplinares, estudio de la resistencia al cambio y la
necesidad de abrazar el cambio continuo.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Ken Schwaber
SCRUM:
Diseño de la metodología SCRUM y del método para la
gestión de proyectos tecnológicos de software, definición de
artefactos y principios para el desarrollo iterativo e
incremental de forma ágil, estudio de la ingeniería de
software y de los métodos predictivos que conducen al
fracaso de los proyectos de desarrollo.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Alistair Cockburn
METODOLOGÍA CRYSTAL:
Estudio del equipo enfocado en el manejo del talento
humano, desarrollo de perfiles adecuados en equipos
multidisciplinares, factores de comunicación entre equipos,
incremento del retorno de inversión, entrega temprana de
resultados, anticipación y adaptación, manejo de la
incertidumbre y de las expectativas, desarrollo de la
creatividad e innovación.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Ron Jeffries
PROGRAMACIÓN EXTREMA:
Adopción de XP en proyectos tecnológicos, estudio del
rechazo al cambio, integración de principios de XP y SCRUM
en el desarrollo de software, diseño dirigido por el dominio,
diseño dirigido por pruebas, integración continua.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Jeff Sutherland
SCRUM:
Diseño de la metodología SCRUM y del método para la
gestión de proyectos tecnológicos de software, definición de
artefactos y principios para el desarrollo iterativo e
incremental de forma ágil, estudio de la ingeniería de
software y de los métodos predictivos que conducen al
fracaso de los proyectos de desarrollo.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Ward
Cunningham
PROGRAMACIÓN EXTREMA:
Adopción de XP en proyectos tecnológicos, estudio del
rechazo al cambio, integración de principios de XP y SCRUM
en el desarrollo de software, diseño dirigido por el dominio,
diseño dirigido por pruebas, integración continua.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Jon Kern
PROCESOS ADAPTATIVOS:
Programación orientada a objetos, metodología COAD, diseño
con Java, UML, herramienta de modelado TOGETHERSOFT,
interacción con el equipo, resultados tangibles y frecuentes,
involucramiento del cliente, adaptación al cambio.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Dave Thomas
LABORATORIOS IBM DE TECNOLOGÍA INTERNACIONAL DE
OBJETOS:
Tecnología orientada a componentes y objetos, estrategias de
negocios, desarrollo de productos software basados en
componentes y marcos de trabajo.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Martin Fowler
TRABAJOS PENSANTES:
Liderazgo adaptativo, imaginación adaptativa, colaboración
con el negocio, investigación de métodos y mejoras para el
diseño y desarrollo de software, patrones de diseño, diseño
orientado al dominio, integración continua, pruebas unitarias y
de integración.
¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Brian Marick
ALIANZA ÁGIL:
Desarrollo ágil de software, disciplina y perfiles en trabajos con
equipos multidisciplinares, diseño dirigido por ejemplos,
desarrollo iterativo e incremental, utilización de herramientas
para acelerar el proceso productivo del equipo..
Los creadores del manifiesto para el desarrollo ágil de
software poseen una vasta experiencia en proyectos
exitosos de software, sin embargo, todas estas buenas
prácticas que han sido descubiertas a lo largo de la
existencia de la industria son la base para una nueva
filosofía de trabajo.
“El movimiento ágil”
Estamos cansados de la forma clásica
de producir software :o)
• ¿CÓMO SE ADOPTA EL MANIFIESTO ÁGIL EN
LA GESTIÓN DE PROYECTOS SOFTWARE?
• Nuestra experiencia adquirida en proyectos
Los proyectos se desarrollan en torno a individuos motivados.
Hay que darles el entorno y el apoyo que necesitan y confiarles
la ejecución del trabajo. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Individuos e interacciones sobre
procesos y herramientas
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el
elemento humano es considerado como un recurso, por lo tanto, es sujeto de
control. Tanto el cliente, como el usuario y el equipo de desarrollo son parte del
elemento humano y entre elementos humanos es necesaria la presencia de un
entorno apropiado para la transferencia de ideas y conceptos sobre un evento en un
determinado contexto. <DSN_XP>
Así adoptamos este principio
CRECIMIENTO, CUIDADO Y RESPETO POR EL EQUIPO HUMANO Y SU ENTORNO
NATURAL <Principio DSN_XP>
El método más eficiente y efectivo de comunicar información al
equipo de desarrollo y entre sus miembros es la conversación
cara a cara. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Individuos e interacciones sobre
procesos y herramientas
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el
elemento humano es considerado como responsable de una actividad, por lo tanto,
sujeto a evaluación. Tanto el cliente, como el usuario y el equipo de desarrollo son
parte del elemento humano y entre elementos humanos es necesaria la presencia de
un lenguaje apropiado para la transferencia de ideas y conceptos sobre un mismo
resultado o expectativa. <DSN_XP>
Así adoptamos este principio
DIÁLOGOS CONTINUOS FACE TO FACE Y FACE TO FACES
<Principio DSN_XP>
A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo y a continuación ajustar y perfeccionar su
comportamiento en consecuencia. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Individuos e interacciones sobre
procesos y herramientas
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el
elemento 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 elemento
humano y entre elementos humanos es necesario reconocer al error como factor
importante dentro del proceso de aprendizaje y mejoramiento continuo. <DSN_XP>
Así adoptamos este principio
RETROSPECTIVAS Y COMPROMISOS
<Principio DSN_XP>
La simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado, es esencial. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Individuos e interacciones sobre
procesos y herramientas
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el
elemento humano es un elemento productivo, por lo tanto, sujeto a explotación.
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 mediante
equipos multidisciplinares comprometidos con su trabajo que colaboran entre sí de
forma simple, con modelos simples y acciones simples. <DSN_XP>
Así adoptamos este principio
LA HONESTIDAD ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
Existen 3 fuerzas básicas detrás de un proyecto, cualquier alteración a una de estas
fuerzas se propaga en las otras 2, la conjugación correcta de las mismas determina la
calidad del producto final.
Cada fuerza es asociada a una variable de cálculo, el tiempo se convierte en
cronograma, los recursos en costos y el alcance en funcionalidades, la resultante se
mide en el éxito o fracaso del proyecto.
El equipo de desarrollo es responsable del alcance, el tiempo y los recursos son
asignados al cliente, el proceso creativo del software tiene que ser transformado en
retorno de inversión de acuerdo al esfuerzo aplicado a una funcionalidad específica.
El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
Existen 3 fuerzas básicas detrás del diseño de un producto, cualquier alteración a una
de estas fuerzas se propaga en las otras 2, la conjugación correcta de las mismas
determina la demanda del producto final.
Cada fuerza es asociada a una variable de cálculo, el producto se convierte en
esfuerzo, el mercado en ingresos y la administración en costos, la resultante se
miden en el éxito o fracaso del producto.
El equipo de desarrollo es responsable del producto, la administración y el mercado
son asignados al cliente, el costo de fabricación del software tiene que ser
transformado en la optimización de recursos de acuerdo al esfuerzo aplicado a una
funcionalidad específica.
El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
Existen 3 fuerzas básicas detrás de un proyecto software, cualquier alteración a una
de estas fuerzas se propaga en las otras 2, la conjugación correcta de las mismas
determina el entorno de trabajo.
Cada fuerza es asociada a una perspectiva de interés en el éxito del proyecto, el
software determina la usabilidad, el business determina el factor de oportunidad y el
team determina el compromiso de cada uno de los miembros del equipo
multidisciplinar. El adecuado proceso de estimación de esfuerzos tiene que ser
equilibrado para evitar cansancio en el team (sobrecarga de trabajo) ya que un
equipo cansado y no motivado repercute en el entorno de trabajo, en la calidad del
producto y en la entrega a tiempo de las funcionalidades.
• ¿CÓMO SE ADOPTA EL MANIFIESTO ÁGIL EN
LA EMPRESA?
• Nuestra experiencia adquirida en proyectos
Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de tiempo
más corto posible <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Software funcionando sobre
documentación extensiva
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, el factor de oportunidad está determinado por la estrategia adecuada
adoptada por el negocio, la adopción de la tecnología requiere de un correcto
entendimiento del procesamiento de la información para la toma de decisiones. El
equipo de desarrollo es responsable del código fuente y de su diseño. <DSN_XP>
Así adoptamos este principio
LA LIBERACIÓN DEL PRODUCTO SE REALIZA POR VERSIONES
<Principio DSN_XP>
LIBERACIÓN INTERNA DEL PROTOTIPO
INICIAL
LIBERACIÓN INTERNA DEL PROTOTIPO
FINAL
LIBERACIÓN PÚBLICA DEL PROTOTIPO
FINAL
ESTAMOS ESTABILIZANDO LA SALIDA A
PRODUCCIÓN
El software funcionando es la medida principal de progreso
<Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Software funcionando sobre
documentación extensiva
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, el software debe hacer lo que dice puede hacer, para determinar este
comportamiento del software se requiere un gran entendimiento del producto que
se desea construir o mantener. El equipo de desarrollo es responsable de la
concepción modular del producto y de su arquitectura. <DSN_XP>
Así adoptamos este principio
LA VISIBILIDAD ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
La atención continua a la excelencia técnica y al buen diseño
mejora la agilidad <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Software funcionando sobre
documentación extensiva
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, los criterios de diseño y arquitectura son transparentes para el negocio
durante el proceso de estimación de esfuerzo, se requiere disciplina para aplicar este
principio. El equipo de desarrollo es responsable de la definición de estándares de
programación incluyendo la adopción de una escuela de diseño y un entendimiento
apropiado del lenguaje de programación. <DSN_XP>
Así adoptamos este principio
TODA IDEA ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
Las mejores arquitecturas, requisitos y diseños emergen de
equipos auto-organizados <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Software funcionando sobre
documentación extensiva
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, la auto organización es producto de un adecuado balanceo de
responsabilidades entre los miembros de equipos multidisciplinares. El equipo de
desarrollo es responsable de realizar mejoras al diseño de forma continua y de que
dichos cambios no afecten la coordinación de esfuerzos. <DSN_XP>
Así adoptamos este principio
EQUIPOS MULTIDISCIPLINARES
<Principio DSN_XP>
BASE DE DATOS DEVELOPERS & QA
NEGOCIO Y PRODUCTO ARQUITECTURA
A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo y a continuación ajustar y perfeccionar su
comportamiento en consecuencia. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Software funcionando sobre
documentación extensiva
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, una
vez que se ha creado un producto software, el proceso de mantenimiento no es
considerado dentro de las tareas planificadas y si se desea mantener un producto ya
realizado no existe una estrategia adecuada de refactorización del producto. El
equipo de desarrollo es responsable de tomar decisiones sobre el diseño y
construcción del producto de forma continua. <DSN_XP>
Así adoptamos este principio
LA ESTIMACIÓN ADECUADA ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
REPORTES DE CODIFICACIÓN REPORTES DE AVANCES
REPORTES DE DESARROLLO REPORTES DE ARQUITECTURA Y DATABASE
El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
• ¿CÓMO SE NEGOCIA CON EL CLIENTE BAJO
UN DESARROLLO ÁGIL?
• Nuestra experiencia adquirida en proyectos
Nuestra mayor prioridad es satisfacer al cliente mediante la
entrega temprana y continua de software con valor
<Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Colaboración con el cliente sobre
negociación contractual
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, el retorno de valor se aplica en el lado del negocio (donde se ejecutará el
software) se compone tanto de la usabilidad del producto como del manejo de la
información. El equipo de desarrollo es responsable de comprender adecuadamente
las expectativas del cliente. <DSN_XP>
Así adoptamos este principio
LA HONESTIDAD ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
Los responsables de negocio y los desarrolladores trabajamos
juntos de forma cotidiana durante todo el proyecto
<Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Colaboración con el cliente sobre
negociación contractual
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, la participación activa del cliente se pone de manifiesto en la transferencia
de conocimientos y en la demanda de funcionalidades. Es responsabilidad de todos
el definir un canal adecuado de comunicación (metáforas y criterios de aceptación)
para un correcto entendimiento del producto y del impacto en el negocio en su
implantación. <DSN_XP>
Así adoptamos este principio
LA HONESTIDAD ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
Los procesos ágiles promueven el desarrollo sostenible.
<Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Colaboración con el cliente sobre
negociación contractual
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, un
desarrollo sostenible va más allá de una relación contractual, resulta como
consecuencia de un perfecto entendimiento entre las partes sobre un mismo objetivo.
Es responsabilidad del equipo de desarrollo el buscar los medios más adecuados para
mantener íntegra la confianza del cliente mediante entregas tempranas de software
funcionando que genera retorno de inversión para el cliente. <DSN_XP>
Así adoptamos este principio
EQUIPOS MULTIDISCIPLINARES
<Principio DSN_XP>
A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo y a continuación ajustar y perfeccionar su
comportamiento en consecuencia. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Colaboración con el cliente sobre
negociación contractual
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, la
visibilidad se utiliza para transparentar el proceso de desarrollo, tanto el cliente como
el equipo de desarrollo encuentran en las métricas indicadores que sirven para ajustar
continuamente el esfuerzo asignado. Es responsabilidad del equipo de desarrollo el
mantener actualizada esta información para una adecuada gestión del proyecto.
<DSN_XP>
Así adoptamos este principio
CONTROL DIARIO DE ACTIVIDADES Y RETROSPECTIVAS DIARIAS
<Principio DSN_XP>
El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
Existen 3 fuerzas básicas detrás de un proyecto, cualquier alteración a una de estas
fuerzas se propaga en las otras 2, la conjugación correcta de las mismas determina la
usabilidad del producto final.
Cada fuerza es asociada a una fuente de información, el stakeholder provee las
necesidades de requerimientos para la toma de decisiones, el usuario provee el
conocimiento y el proceso que se desea abstraer, el desarrollador provee las mejoras
al proceso y la simplicidad de la herramienta. Es responsabilidad del equipo de
desarrollo el comprender y balancear estos requerimientos en funcionalidades y
servicios para el uso correcto del producto.
El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
Existen 3 fuerzas básicas detrás de un producto, cualquier alteración a una de estas
fuerzas se propaga en las otras 2, la conjugación correcta de las mismas determina la
calidad del producto final.
Cada fuerza es asociada a un factor de diseño, las historias de usuario capturan las
necesidades del producto por parte de los usuarios (retorno de inversión), los
criterios de aceptación capturan las necesidades del stakeholder principal
(priorización) y las sentencias de trabajo definen sin ambigüedades las
especificaciones del software (esfuerzo). Es responsabilidad del equipo de desarrollo
el verificar que cada historia posea los tres indicadores para una adecuada gestión
del proyecto.
• ¿CÓMO SE SOPORTA EL CAMBIO EN LA
GESTIÓN DE PROYECTOS?
• Nuestra experiencia adquirida en proyectos
Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo <Principio Ágil>
A través de este trabajo hemos aprendido a valorar:
Respuesta ante el cambio sobre seguir un plan
Usualmente en la gestión de proyectos, no se toma en cuenta este principio, la
concepción de ágil descasa específicamente en este principio, a diferencia de la
escuela tradicional, el cambio continuo es la mejor estrategia de desarrollo, “las
buenas ideas no surgen exclusivamente al inicio de un proyecto sino que aparecen del
mismo entendimiento del producto durante su fabricación” <prototipo>. Es
responsabilidad del equipo de desarrollo el aplicar un diseño sencillo para el control
de cambios dentro de la configuración modular del producto. <DSN_XP>
Así adoptamos este principio
ADOPCIÓN DE SCRUM Y XP
<Principio DSN_XP>
Los procesos ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente <Principio Ágil>
A través de este trabajo hemos aprendido a valorar:
Respuesta ante el cambio sobre seguir un plan
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, la ventaja competitiva para el cliente implica de por sí la involucración del
cliente en el proceso de desarrollo, tanto el cliente como el equipo de desarrollo son
responsables del éxito o fracaso de un proyecto, pese a lo dicho, el fracaso representa
para el equipo de desarrollo una ventaja a favor del aprendizaje y de la mejora
continua. Es responsabilidad del cliente el definir adecuadamente el impacto de un
cambio en la gestión de su negocio. <DSN_XP>
Así adoptamos este principio
PLANIFICACIÓN CONTINUA DEL PRODUCTO
<Principio DSN_XP>
Los promotores, desarrolladores y usuarios debemos ser
capaces de mantener un ritmo constante de forma indefinida
<Principio Ágil>
A través de este trabajo hemos aprendido a valorar:
Respuesta ante el cambio sobre seguir un plan
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, el ritmo constante se adquiere en base a un adecuado proceso de
estimación de esfuerzos, aprendizaje y compromiso. Es responsabilidad del equipo de
desarrollo el gestionar adecuadamente el proceso de construcción mediante el uso de
mejores prácticas, marcos de trabajo, patrones de diseño y recodificación continua.
<DSN_XP>
Así adoptamos este principio
TRANSPARENCIA, INSPECCIÓN, ADAPTACIÓN
<Principio DSN_XP>
A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo y a continuación ajustar y perfeccionar su
comportamiento en consecuencia. <Principio Ágil>
A través de este trabajo hemos aprendido a valorar:
Respuesta ante el cambio sobre seguir un plan
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, la ventaja competitiva para el cliente implica de por sí la involucración del
cliente en el proceso de desarrollo, tanto el cliente como el equipo de desarrollo son
responsables del éxito o fracaso de un proyecto, pese a lo dicho, el fracaso representa
para el equipo de desarrollo una ventaja a favor del aprendizaje y de la mejora
continua. Es responsabilidad del cliente el definir adecuadamente el impacto de un
cambio en la gestión de su negocio. <DSN_XP>
Así adoptamos este principio
TRABAJO COMO UN SOLO EQUIPO
<Principio DSN_XP>
Follow DSN_XP
• En twitter: @dsn_xp
• En Facebook: /dsnxp
• E-mail: pacotoscano@gmail.com

Más contenido relacionado

La actualidad más candente

Como implementar La Automatización De Pruebas y No Morir En El Intento
Como implementar La Automatización De Pruebas y No Morir En El IntentoComo implementar La Automatización De Pruebas y No Morir En El Intento
Como implementar La Automatización De Pruebas y No Morir En El IntentoSoftware Guru
 
Metodologiasagilesarquitectura
MetodologiasagilesarquitecturaMetodologiasagilesarquitectura
Metodologiasagilesarquitecturaroisbelfigueroa
 
El reto de crear equipos digitales
El reto de crear equipos digitalesEl reto de crear equipos digitales
El reto de crear equipos digitalesMultiplica
 
Principios de las metodologías agiles
Principios  de las metodologías agilesPrincipios  de las metodologías agiles
Principios de las metodologías agilesjoselynvaleria93
 
data.driven.decisions
data.driven.decisionsdata.driven.decisions
data.driven.decisionsMultiplica
 
La importancia de la Arquitectura de Soluciones en el Ecosistema Latinoameric...
La importancia de la Arquitectura de Soluciones en el Ecosistema Latinoameric...La importancia de la Arquitectura de Soluciones en el Ecosistema Latinoameric...
La importancia de la Arquitectura de Soluciones en el Ecosistema Latinoameric...Software Guru
 
¿Cómo evito que mi proyecto se inunde de cambios?
¿Cómo evito que mi proyecto se inunde de cambios?¿Cómo evito que mi proyecto se inunde de cambios?
¿Cómo evito que mi proyecto se inunde de cambios?Software Guru
 
Metodologías agiles
Metodologías agilesMetodologías agiles
Metodologías agilesloreeleeii
 
Material Apoyo Ingenieria del Software USAL Argentina
Material Apoyo Ingenieria del Software USAL ArgentinaMaterial Apoyo Ingenieria del Software USAL Argentina
Material Apoyo Ingenieria del Software USAL ArgentinaSusana Daldin
 
Seminario de metodologías ágiles, bloque I
Seminario de metodologías ágiles, bloque ISeminario de metodologías ágiles, bloque I
Seminario de metodologías ágiles, bloque IJuan Carlos Rubio Pineda
 
Opensession. Herramientas ágiles en proyectos end to end
Opensession. Herramientas ágiles en proyectos end to endOpensession. Herramientas ágiles en proyectos end to end
Opensession. Herramientas ágiles en proyectos end to endMultiplica
 
¿Qué tiene de apasionante la ingeniería de software?
¿Qué tiene de apasionante la ingeniería de software?¿Qué tiene de apasionante la ingeniería de software?
¿Qué tiene de apasionante la ingeniería de software?Software Guru
 
El Factor Humano en Proyectos de Software
El Factor Humano en Proyectos de SoftwareEl Factor Humano en Proyectos de Software
El Factor Humano en Proyectos de SoftwareHaaron Gonzalez
 

La actualidad más candente (20)

METODOLOGÍAS ÁGILES EN TI
METODOLOGÍAS ÁGILES EN TIMETODOLOGÍAS ÁGILES EN TI
METODOLOGÍAS ÁGILES EN TI
 
Sistemas de gestion de proyectos con software libre
Sistemas de gestion de proyectos con software libreSistemas de gestion de proyectos con software libre
Sistemas de gestion de proyectos con software libre
 
Como implementar La Automatización De Pruebas y No Morir En El Intento
Como implementar La Automatización De Pruebas y No Morir En El IntentoComo implementar La Automatización De Pruebas y No Morir En El Intento
Como implementar La Automatización De Pruebas y No Morir En El Intento
 
Metodologiasagiles
MetodologiasagilesMetodologiasagiles
Metodologiasagiles
 
Metodologiasagilesarquitectura
MetodologiasagilesarquitecturaMetodologiasagilesarquitectura
Metodologiasagilesarquitectura
 
El reto de crear equipos digitales
El reto de crear equipos digitalesEl reto de crear equipos digitales
El reto de crear equipos digitales
 
Principios de las metodologías agiles
Principios  de las metodologías agilesPrincipios  de las metodologías agiles
Principios de las metodologías agiles
 
data.driven.decisions
data.driven.decisionsdata.driven.decisions
data.driven.decisions
 
La importancia de la Arquitectura de Soluciones en el Ecosistema Latinoameric...
La importancia de la Arquitectura de Soluciones en el Ecosistema Latinoameric...La importancia de la Arquitectura de Soluciones en el Ecosistema Latinoameric...
La importancia de la Arquitectura de Soluciones en el Ecosistema Latinoameric...
 
¿Cómo evito que mi proyecto se inunde de cambios?
¿Cómo evito que mi proyecto se inunde de cambios?¿Cómo evito que mi proyecto se inunde de cambios?
¿Cómo evito que mi proyecto se inunde de cambios?
 
Metodologías agiles
Metodologías agilesMetodologías agiles
Metodologías agiles
 
desarrollo ágil-ingenieria de softwaare
desarrollo ágil-ingenieria de softwaaredesarrollo ágil-ingenieria de softwaare
desarrollo ágil-ingenieria de softwaare
 
Desarrollo de software
Desarrollo de softwareDesarrollo de software
Desarrollo de software
 
Material Apoyo Ingenieria del Software USAL Argentina
Material Apoyo Ingenieria del Software USAL ArgentinaMaterial Apoyo Ingenieria del Software USAL Argentina
Material Apoyo Ingenieria del Software USAL Argentina
 
Seminario de metodologías ágiles, bloque I
Seminario de metodologías ágiles, bloque ISeminario de metodologías ágiles, bloque I
Seminario de metodologías ágiles, bloque I
 
Opensession. Herramientas ágiles en proyectos end to end
Opensession. Herramientas ágiles en proyectos end to endOpensession. Herramientas ágiles en proyectos end to end
Opensession. Herramientas ágiles en proyectos end to end
 
Tutorial Lean UX Workshop - MexIHC 2016
Tutorial Lean UX Workshop - MexIHC 2016Tutorial Lean UX Workshop - MexIHC 2016
Tutorial Lean UX Workshop - MexIHC 2016
 
¿Qué tiene de apasionante la ingeniería de software?
¿Qué tiene de apasionante la ingeniería de software?¿Qué tiene de apasionante la ingeniería de software?
¿Qué tiene de apasionante la ingeniería de software?
 
El Factor Humano en Proyectos de Software
El Factor Humano en Proyectos de SoftwareEl Factor Humano en Proyectos de Software
El Factor Humano en Proyectos de Software
 
AGILE Taller gestión de proyectos
AGILE Taller gestión de proyectosAGILE Taller gestión de proyectos
AGILE Taller gestión de proyectos
 

Similar a Los creadores del manifiesto ágil

SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;
SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;
SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;Walter Ariel Risi
 
Metodologías ágiles
Metodologías ágilesMetodologías ágiles
Metodologías ágilesEIYSC
 
Unidad 1.2 B Metodos Agiles 1
Unidad 1.2 B Metodos Agiles  1Unidad 1.2 B Metodos Agiles  1
Unidad 1.2 B Metodos Agiles 1Sergio Sanchez
 
El por qué de los métodos ágiles
El por qué de los métodos ágilesEl por qué de los métodos ágiles
El por qué de los métodos ágilesGiovanny Cifuentes
 
Programacion agil
Programacion agilProgramacion agil
Programacion agilXilena16
 
METODOLOGÍAS DE GESTIÓN DE PROYECTOS
METODOLOGÍAS DE GESTIÓN DE PROYECTOS METODOLOGÍAS DE GESTIÓN DE PROYECTOS
METODOLOGÍAS DE GESTIÓN DE PROYECTOS alexandermedranorodr
 
PREGUNTAS DE GESTION DE DESARROLLO DE SOFTWARE
PREGUNTAS DE GESTION DE DESARROLLO DE SOFTWAREPREGUNTAS DE GESTION DE DESARROLLO DE SOFTWARE
PREGUNTAS DE GESTION DE DESARROLLO DE SOFTWAREJuanJosePeraltaGutir
 

Similar a Los creadores del manifiesto ágil (20)

SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;
SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;
SEPG LA 2005 Presentation &quot;Practicas Agiles En Mejora De Procesos&quot;
 
IntroSCRUM_ES
IntroSCRUM_ESIntroSCRUM_ES
IntroSCRUM_ES
 
Curso Taller LEAN UX Clase 01/04
Curso Taller LEAN UX Clase 01/04Curso Taller LEAN UX Clase 01/04
Curso Taller LEAN UX Clase 01/04
 
Metodologías ágiles
Metodologías ágilesMetodologías ágiles
Metodologías ágiles
 
Unidad 1.2 B Metodos Agiles 1
Unidad 1.2 B Metodos Agiles  1Unidad 1.2 B Metodos Agiles  1
Unidad 1.2 B Metodos Agiles 1
 
El por qué de los métodos ágiles
El por qué de los métodos ágilesEl por qué de los métodos ágiles
El por qué de los métodos ágiles
 
El Emperador No Tiene Traje
El Emperador No Tiene TrajeEl Emperador No Tiene Traje
El Emperador No Tiene Traje
 
METODOLOGÍAS ÁGILES
METODOLOGÍAS ÁGILESMETODOLOGÍAS ÁGILES
METODOLOGÍAS ÁGILES
 
Scrum Master - Developer Capitulo 1
Scrum Master - Developer Capitulo 1Scrum Master - Developer Capitulo 1
Scrum Master - Developer Capitulo 1
 
Metodologías Ágiles
Metodologías ÁgilesMetodologías Ágiles
Metodologías Ágiles
 
Metodologiasagiles
MetodologiasagilesMetodologiasagiles
Metodologiasagiles
 
Programacion agil
Programacion agilProgramacion agil
Programacion agil
 
Angello revista digital
Angello revista digitalAngello revista digital
Angello revista digital
 
Ha2 nv50 rodriguez montiel moises-xp
Ha2 nv50 rodriguez montiel moises-xpHa2 nv50 rodriguez montiel moises-xp
Ha2 nv50 rodriguez montiel moises-xp
 
Programacion Extrema
Programacion ExtremaProgramacion Extrema
Programacion Extrema
 
Roles de los desarrolladores
Roles de los desarrolladoresRoles de los desarrolladores
Roles de los desarrolladores
 
METODOLOGÍAS DE GESTIÓN DE PROYECTOS
METODOLOGÍAS DE GESTIÓN DE PROYECTOS METODOLOGÍAS DE GESTIÓN DE PROYECTOS
METODOLOGÍAS DE GESTIÓN DE PROYECTOS
 
PREGUNTAS DE GESTION DE DESARROLLO DE SOFTWARE
PREGUNTAS DE GESTION DE DESARROLLO DE SOFTWAREPREGUNTAS DE GESTION DE DESARROLLO DE SOFTWARE
PREGUNTAS DE GESTION DE DESARROLLO DE SOFTWARE
 
Exposicion
ExposicionExposicion
Exposicion
 
AIS -Software.pdf
AIS -Software.pdfAIS -Software.pdf
AIS -Software.pdf
 

Último

Manual de Usuario APPs_AppInventor-2023.pdf
Manual de Usuario APPs_AppInventor-2023.pdfManual de Usuario APPs_AppInventor-2023.pdf
Manual de Usuario APPs_AppInventor-2023.pdfmasogeis
 
Segmentacion Segmantica_Modelos UNET and DEEPLABV3
Segmentacion Segmantica_Modelos UNET and DEEPLABV3Segmentacion Segmantica_Modelos UNET and DEEPLABV3
Segmentacion Segmantica_Modelos UNET and DEEPLABV3AlexysCaytanoMelndez1
 
Introducción a Funciones LENGUAJE DART FLUTTER
Introducción a Funciones LENGUAJE DART FLUTTERIntroducción a Funciones LENGUAJE DART FLUTTER
Introducción a Funciones LENGUAJE DART FLUTTEREMMAFLORESCARMONA
 
BREEAM ES Urbanismo como herramienta para un planeamiento sostenible - Miguel...
BREEAM ES Urbanismo como herramienta para un planeamiento sostenible - Miguel...BREEAM ES Urbanismo como herramienta para un planeamiento sostenible - Miguel...
BREEAM ES Urbanismo como herramienta para un planeamiento sostenible - Miguel...ITeC Instituto Tecnología Construcción
 
PARTES DEL TECLADO Y SUS FUNCIONES - EJEMPLO
PARTES DEL TECLADO Y SUS FUNCIONES - EJEMPLOPARTES DEL TECLADO Y SUS FUNCIONES - EJEMPLO
PARTES DEL TECLADO Y SUS FUNCIONES - EJEMPLOSelenaCoronadoHuaman
 
Unidad_3_T1_AutomatasFinitos presentacion
Unidad_3_T1_AutomatasFinitos presentacionUnidad_3_T1_AutomatasFinitos presentacion
Unidad_3_T1_AutomatasFinitos presentacionarmando_cardenas
 
Caso de éxito de Hervian con el ERP Sage 200
Caso de éxito de Hervian con el ERP Sage 200Caso de éxito de Hervian con el ERP Sage 200
Caso de éxito de Hervian con el ERP Sage 200Opentix
 

Último (7)

Manual de Usuario APPs_AppInventor-2023.pdf
Manual de Usuario APPs_AppInventor-2023.pdfManual de Usuario APPs_AppInventor-2023.pdf
Manual de Usuario APPs_AppInventor-2023.pdf
 
Segmentacion Segmantica_Modelos UNET and DEEPLABV3
Segmentacion Segmantica_Modelos UNET and DEEPLABV3Segmentacion Segmantica_Modelos UNET and DEEPLABV3
Segmentacion Segmantica_Modelos UNET and DEEPLABV3
 
Introducción a Funciones LENGUAJE DART FLUTTER
Introducción a Funciones LENGUAJE DART FLUTTERIntroducción a Funciones LENGUAJE DART FLUTTER
Introducción a Funciones LENGUAJE DART FLUTTER
 
BREEAM ES Urbanismo como herramienta para un planeamiento sostenible - Miguel...
BREEAM ES Urbanismo como herramienta para un planeamiento sostenible - Miguel...BREEAM ES Urbanismo como herramienta para un planeamiento sostenible - Miguel...
BREEAM ES Urbanismo como herramienta para un planeamiento sostenible - Miguel...
 
PARTES DEL TECLADO Y SUS FUNCIONES - EJEMPLO
PARTES DEL TECLADO Y SUS FUNCIONES - EJEMPLOPARTES DEL TECLADO Y SUS FUNCIONES - EJEMPLO
PARTES DEL TECLADO Y SUS FUNCIONES - EJEMPLO
 
Unidad_3_T1_AutomatasFinitos presentacion
Unidad_3_T1_AutomatasFinitos presentacionUnidad_3_T1_AutomatasFinitos presentacion
Unidad_3_T1_AutomatasFinitos presentacion
 
Caso de éxito de Hervian con el ERP Sage 200
Caso de éxito de Hervian con el ERP Sage 200Caso de éxito de Hervian con el ERP Sage 200
Caso de éxito de Hervian con el ERP Sage 200
 

Los creadores del manifiesto ágil

  • 1. MANIFIESTO PARA EL DESARROLLO ÁGIL DE SOFTWARE DISEÑO DE SOFTWARE INVERSO Y EXPERIMENTACIÓN CONFERENCIAS TÉCNICAS DSN_XP SOBRE INGENIERÍA DE SOFTWARE CONFERENCIA DICTADA EN LOJA ENERO 2011
  • 2. El manifiesto ágil <?> Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: • Individuos e interacciones sobre procesos y herramientas • Software funcionando sobre documentación extensiva • Colaboración con el cliente sobre negociación contractual • Respuesta ante el cambio sobre seguir un plan Esto es, aunque valoramos los elementos de la derecha, valoramos más 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. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Kent Beck PROGRAMACIÓN EXTREMA: Inclusión del cliente al equipo, historias de usuario, jugar a la planificación, pequeñas liberaciones, pruebas de aceptación, espacios abiertos, diseño dirigido por pruebas, comunicación por metáforas, diseño simple, recodificación continua, integración continua, programación en parejas, código fuente comunitario, estándares de codificación, ritmo sostenible.
  • 4. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. James Grenning RENACIMIENTO DEL SOFTWARE: Programación extrema, diseño dirigido por pruebas, poker de planificación, historias de usuario, pruebas automáticas, integración continua, desarrollo iterativo e incremental, negociación con el cliente sobre tiempos y alcances, pruebas de aceptación, creación de la visión del producto y desarrollo por características.
  • 5. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Robert C Martin ENSEÑANZA DE OBJETOS: Diseño simple orientado a objetos, principio de responsabilidad única, principio de abierto-cerrado, principio de sustitución de Liskov, principio de segregación de interfaz, principio de inversión de dependencia, programación extrema, diseño dirigido por pruebas de aceptación, pruebas unitarias, formación de equipos multidisciplinares.
  • 6. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Mike Beedle E-ARQUITECTURA: Adopción de SCRUM, adaptación y aprendizaje, creación de equipos multidisciplinares para soportar el CAOS, entornos altamente productivos, adopción de cambios culturales en la organización.
  • 7. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Jim Highsmith TRABAJOS PENSANTES: Liderazgo adaptativo, imaginación adaptativa, colaboración con el negocio, adopción de SCRUM, trabajo en equipo, formación de líderes, formación de ejecutivos, desarrollo iterativo e incremental en períodos cortos de tiempo, retorno de inversión, cadenas de valor productivas para el negocio.
  • 8. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Steve Mellor MÉTODO DE SHLAER-MELLOR: Diseño orientado a objetos, desarrollo dirigido por modelos, uso de UML para el ciclo de vida, uso de lenguaje específico del dominio, meta modelado de la arquitectura, intercambio de metadata con XML, computación con objetos empresariales distribuidos.
  • 9. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Arie van Bennekum MÉTODO DE DESARROLLO DE SISTEMAS DINÁMICOS: Desarrollo rápido de aplicaciones, marco de trabajo para gestión de proyectos tecnológicos con presupuestos fijos y tiempos cortos de desarrollo limitados por el mercado, enfoque para retorno de inversión.
  • 10. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Andy Hunt PROGRAMADORES PRAGMÁTICOS: Aprendizaje y pensamiento pragmático, estudio del comportamiento humano en desarrolladores y miembros del negocio, desarrollo de perfiles adecuados en equipos multidisciplinares, estudio de la resistencia al cambio y la necesidad de abrazar el cambio continuo.
  • 11. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Ken Schwaber SCRUM: Diseño de la metodología SCRUM y del método para la gestión de proyectos tecnológicos de software, definición de artefactos y principios para el desarrollo iterativo e incremental de forma ágil, estudio de la ingeniería de software y de los métodos predictivos que conducen al fracaso de los proyectos de desarrollo.
  • 12. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Alistair Cockburn METODOLOGÍA CRYSTAL: Estudio del equipo enfocado en el manejo del talento humano, desarrollo de perfiles adecuados en equipos multidisciplinares, factores de comunicación entre equipos, incremento del retorno de inversión, entrega temprana de resultados, anticipación y adaptación, manejo de la incertidumbre y de las expectativas, desarrollo de la creatividad e innovación.
  • 13. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Ron Jeffries PROGRAMACIÓN EXTREMA: Adopción de XP en proyectos tecnológicos, estudio del rechazo al cambio, integración de principios de XP y SCRUM en el desarrollo de software, diseño dirigido por el dominio, diseño dirigido por pruebas, integración continua.
  • 14. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Jeff Sutherland SCRUM: Diseño de la metodología SCRUM y del método para la gestión de proyectos tecnológicos de software, definición de artefactos y principios para el desarrollo iterativo e incremental de forma ágil, estudio de la ingeniería de software y de los métodos predictivos que conducen al fracaso de los proyectos de desarrollo.
  • 15. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Ward Cunningham PROGRAMACIÓN EXTREMA: Adopción de XP en proyectos tecnológicos, estudio del rechazo al cambio, integración de principios de XP y SCRUM en el desarrollo de software, diseño dirigido por el dominio, diseño dirigido por pruebas, integración continua.
  • 16. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Jon Kern PROCESOS ADAPTATIVOS: Programación orientada a objetos, metodología COAD, diseño con Java, UML, herramienta de modelado TOGETHERSOFT, interacción con el equipo, resultados tangibles y frecuentes, involucramiento del cliente, adaptación al cambio.
  • 17. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Dave Thomas LABORATORIOS IBM DE TECNOLOGÍA INTERNACIONAL DE OBJETOS: Tecnología orientada a componentes y objetos, estrategias de negocios, desarrollo de productos software basados en componentes y marcos de trabajo.
  • 18. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Martin Fowler TRABAJOS PENSANTES: Liderazgo adaptativo, imaginación adaptativa, colaboración con el negocio, investigación de métodos y mejoras para el diseño y desarrollo de software, patrones de diseño, diseño orientado al dominio, integración continua, pruebas unitarias y de integración.
  • 19. ¿Quiénes firman el manifiesto ágil? Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. Brian Marick ALIANZA ÁGIL: Desarrollo ágil de software, disciplina y perfiles en trabajos con equipos multidisciplinares, diseño dirigido por ejemplos, desarrollo iterativo e incremental, utilización de herramientas para acelerar el proceso productivo del equipo..
  • 20. Los creadores del manifiesto para el desarrollo ágil de software poseen una vasta experiencia en proyectos exitosos de software, sin embargo, todas estas buenas prácticas que han sido descubiertas a lo largo de la existencia de la industria son la base para una nueva filosofía de trabajo. “El movimiento ágil” Estamos cansados de la forma clásica de producir software :o)
  • 21. • ¿CÓMO SE ADOPTA EL MANIFIESTO ÁGIL EN LA GESTIÓN DE PROYECTOS SOFTWARE? • Nuestra experiencia adquirida en proyectos
  • 22. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan y confiarles la ejecución del trabajo. <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el elemento humano es considerado como un recurso, por lo tanto, es sujeto de control. Tanto el cliente, como el usuario y el equipo de desarrollo son parte del elemento humano y entre elementos humanos es necesaria la presencia de un entorno apropiado para la transferencia de ideas y conceptos sobre un evento en un determinado contexto. <DSN_XP>
  • 23. Así adoptamos este principio CRECIMIENTO, CUIDADO Y RESPETO POR EL EQUIPO HUMANO Y SU ENTORNO NATURAL <Principio DSN_XP>
  • 24. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el elemento humano es considerado como responsable de una actividad, por lo tanto, sujeto a evaluación. Tanto el cliente, como el usuario y el equipo de desarrollo son parte del elemento humano y entre elementos humanos es necesaria la presencia de un lenguaje apropiado para la transferencia de ideas y conceptos sobre un mismo resultado o expectativa. <DSN_XP>
  • 25. Así adoptamos este principio DIÁLOGOS CONTINUOS FACE TO FACE Y FACE TO FACES <Principio DSN_XP>
  • 26. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo y a continuación ajustar y perfeccionar su comportamiento en consecuencia. <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el elemento 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 elemento humano y entre elementos humanos es necesario reconocer al error como factor importante dentro del proceso de aprendizaje y mejoramiento continuo. <DSN_XP>
  • 27. Así adoptamos este principio RETROSPECTIVAS Y COMPROMISOS <Principio DSN_XP>
  • 28. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el elemento humano es un elemento productivo, por lo tanto, sujeto a explotación. 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 mediante equipos multidisciplinares comprometidos con su trabajo que colaboran entre sí de forma simple, con modelos simples y acciones simples. <DSN_XP>
  • 29. Así adoptamos este principio LA HONESTIDAD ES BIENVENIDA SIEMPRE <Principio DSN_XP>
  • 30. El uso de las triadas en la gestión de proyectos de desarrollo de software <Principio DSN_XP> Existen 3 fuerzas básicas detrás de un proyecto, cualquier alteración a una de estas fuerzas se propaga en las otras 2, la conjugación correcta de las mismas determina la calidad del producto final. Cada fuerza es asociada a una variable de cálculo, el tiempo se convierte en cronograma, los recursos en costos y el alcance en funcionalidades, la resultante se mide en el éxito o fracaso del proyecto. El equipo de desarrollo es responsable del alcance, el tiempo y los recursos son asignados al cliente, el proceso creativo del software tiene que ser transformado en retorno de inversión de acuerdo al esfuerzo aplicado a una funcionalidad específica.
  • 31. El uso de las triadas en la gestión de proyectos de desarrollo de software <Principio DSN_XP> Existen 3 fuerzas básicas detrás del diseño de un producto, cualquier alteración a una de estas fuerzas se propaga en las otras 2, la conjugación correcta de las mismas determina la demanda del producto final. Cada fuerza es asociada a una variable de cálculo, el producto se convierte en esfuerzo, el mercado en ingresos y la administración en costos, la resultante se miden en el éxito o fracaso del producto. El equipo de desarrollo es responsable del producto, la administración y el mercado son asignados al cliente, el costo de fabricación del software tiene que ser transformado en la optimización de recursos de acuerdo al esfuerzo aplicado a una funcionalidad específica.
  • 32. El uso de las triadas en la gestión de proyectos de desarrollo de software <Principio DSN_XP> Existen 3 fuerzas básicas detrás de un proyecto software, cualquier alteración a una de estas fuerzas se propaga en las otras 2, la conjugación correcta de las mismas determina el entorno de trabajo. Cada fuerza es asociada a una perspectiva de interés en el éxito del proyecto, el software determina la usabilidad, el business determina el factor de oportunidad y el team determina el compromiso de cada uno de los miembros del equipo multidisciplinar. El adecuado proceso de estimación de esfuerzos tiene que ser equilibrado para evitar cansancio en el team (sobrecarga de trabajo) ya que un equipo cansado y no motivado repercute en el entorno de trabajo, en la calidad del producto y en la entrega a tiempo de las funcionalidades.
  • 33. • ¿CÓMO SE ADOPTA EL MANIFIESTO ÁGIL EN LA EMPRESA? • Nuestra experiencia adquirida en proyectos
  • 34. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Software funcionando sobre documentación extensiva Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este principio, el factor de oportunidad está determinado por la estrategia adecuada adoptada por el negocio, la adopción de la tecnología requiere de un correcto entendimiento del procesamiento de la información para la toma de decisiones. El equipo de desarrollo es responsable del código fuente y de su diseño. <DSN_XP>
  • 35. Así adoptamos este principio LA LIBERACIÓN DEL PRODUCTO SE REALIZA POR VERSIONES <Principio DSN_XP> LIBERACIÓN INTERNA DEL PROTOTIPO INICIAL LIBERACIÓN INTERNA DEL PROTOTIPO FINAL LIBERACIÓN PÚBLICA DEL PROTOTIPO FINAL ESTAMOS ESTABILIZANDO LA SALIDA A PRODUCCIÓN
  • 36. El software funcionando es la medida principal de progreso <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Software funcionando sobre documentación extensiva Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este principio, el software debe hacer lo que dice puede hacer, para determinar este comportamiento del software se requiere un gran entendimiento del producto que se desea construir o mantener. El equipo de desarrollo es responsable de la concepción modular del producto y de su arquitectura. <DSN_XP>
  • 37. Así adoptamos este principio LA VISIBILIDAD ES BIENVENIDA SIEMPRE <Principio DSN_XP>
  • 38. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Software funcionando sobre documentación extensiva Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este principio, los criterios de diseño y arquitectura son transparentes para el negocio durante el proceso de estimación de esfuerzo, se requiere disciplina para aplicar este principio. El equipo de desarrollo es responsable de la definición de estándares de programación incluyendo la adopción de una escuela de diseño y un entendimiento apropiado del lenguaje de programación. <DSN_XP>
  • 39. Así adoptamos este principio TODA IDEA ES BIENVENIDA SIEMPRE <Principio DSN_XP>
  • 40. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Software funcionando sobre documentación extensiva Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este principio, la auto organización es producto de un adecuado balanceo de responsabilidades entre los miembros de equipos multidisciplinares. El equipo de desarrollo es responsable de realizar mejoras al diseño de forma continua y de que dichos cambios no afecten la coordinación de esfuerzos. <DSN_XP>
  • 41. Así adoptamos este principio EQUIPOS MULTIDISCIPLINARES <Principio DSN_XP> BASE DE DATOS DEVELOPERS & QA NEGOCIO Y PRODUCTO ARQUITECTURA
  • 42. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo y a continuación ajustar y perfeccionar su comportamiento en consecuencia. <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Software funcionando sobre documentación extensiva Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, una vez que se ha creado un producto software, el proceso de mantenimiento no es considerado dentro de las tareas planificadas y si se desea mantener un producto ya realizado no existe una estrategia adecuada de refactorización del producto. El equipo de desarrollo es responsable de tomar decisiones sobre el diseño y construcción del producto de forma continua. <DSN_XP>
  • 43. Así adoptamos este principio LA ESTIMACIÓN ADECUADA ES BIENVENIDA SIEMPRE <Principio DSN_XP> REPORTES DE CODIFICACIÓN REPORTES DE AVANCES REPORTES DE DESARROLLO REPORTES DE ARQUITECTURA Y DATABASE
  • 44. El uso de las triadas en la gestión de proyectos de desarrollo de software <Principio DSN_XP>
  • 45. El uso de las triadas en la gestión de proyectos de desarrollo de software <Principio DSN_XP>
  • 46. • ¿CÓMO SE NEGOCIA CON EL CLIENTE BAJO UN DESARROLLO ÁGIL? • Nuestra experiencia adquirida en proyectos
  • 47. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Colaboración con el cliente sobre negociación contractual Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este principio, el retorno de valor se aplica en el lado del negocio (donde se ejecutará el software) se compone tanto de la usabilidad del producto como del manejo de la información. El equipo de desarrollo es responsable de comprender adecuadamente las expectativas del cliente. <DSN_XP>
  • 48. Así adoptamos este principio LA HONESTIDAD ES BIENVENIDA SIEMPRE <Principio DSN_XP>
  • 49. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Colaboración con el cliente sobre negociación contractual Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este principio, la participación activa del cliente se pone de manifiesto en la transferencia de conocimientos y en la demanda de funcionalidades. Es responsabilidad de todos el definir un canal adecuado de comunicación (metáforas y criterios de aceptación) para un correcto entendimiento del producto y del impacto en el negocio en su implantación. <DSN_XP>
  • 50. Así adoptamos este principio LA HONESTIDAD ES BIENVENIDA SIEMPRE <Principio DSN_XP>
  • 51. Los procesos ágiles promueven el desarrollo sostenible. <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Colaboración con el cliente sobre negociación contractual Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, un desarrollo sostenible va más allá de una relación contractual, resulta como consecuencia de un perfecto entendimiento entre las partes sobre un mismo objetivo. Es responsabilidad del equipo de desarrollo el buscar los medios más adecuados para mantener íntegra la confianza del cliente mediante entregas tempranas de software funcionando que genera retorno de inversión para el cliente. <DSN_XP>
  • 52. Así adoptamos este principio EQUIPOS MULTIDISCIPLINARES <Principio DSN_XP>
  • 53. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo y a continuación ajustar y perfeccionar su comportamiento en consecuencia. <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Colaboración con el cliente sobre negociación contractual Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, la visibilidad se utiliza para transparentar el proceso de desarrollo, tanto el cliente como el equipo de desarrollo encuentran en las métricas indicadores que sirven para ajustar continuamente el esfuerzo asignado. Es responsabilidad del equipo de desarrollo el mantener actualizada esta información para una adecuada gestión del proyecto. <DSN_XP>
  • 54. Así adoptamos este principio CONTROL DIARIO DE ACTIVIDADES Y RETROSPECTIVAS DIARIAS <Principio DSN_XP>
  • 55. El uso de las triadas en la gestión de proyectos de desarrollo de software <Principio DSN_XP> Existen 3 fuerzas básicas detrás de un proyecto, cualquier alteración a una de estas fuerzas se propaga en las otras 2, la conjugación correcta de las mismas determina la usabilidad del producto final. Cada fuerza es asociada a una fuente de información, el stakeholder provee las necesidades de requerimientos para la toma de decisiones, el usuario provee el conocimiento y el proceso que se desea abstraer, el desarrollador provee las mejoras al proceso y la simplicidad de la herramienta. Es responsabilidad del equipo de desarrollo el comprender y balancear estos requerimientos en funcionalidades y servicios para el uso correcto del producto.
  • 56. El uso de las triadas en la gestión de proyectos de desarrollo de software <Principio DSN_XP> Existen 3 fuerzas básicas detrás de un producto, cualquier alteración a una de estas fuerzas se propaga en las otras 2, la conjugación correcta de las mismas determina la calidad del producto final. Cada fuerza es asociada a un factor de diseño, las historias de usuario capturan las necesidades del producto por parte de los usuarios (retorno de inversión), los criterios de aceptación capturan las necesidades del stakeholder principal (priorización) y las sentencias de trabajo definen sin ambigüedades las especificaciones del software (esfuerzo). Es responsabilidad del equipo de desarrollo el verificar que cada historia posea los tres indicadores para una adecuada gestión del proyecto.
  • 57. • ¿CÓMO SE SOPORTA EL CAMBIO EN LA GESTIÓN DE PROYECTOS? • Nuestra experiencia adquirida en proyectos
  • 58. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Respuesta ante el cambio sobre seguir un plan Usualmente en la gestión de proyectos, no se toma en cuenta este principio, la concepción de ágil descasa específicamente en este principio, a diferencia de la escuela tradicional, el cambio continuo es la mejor estrategia de desarrollo, “las buenas ideas no surgen exclusivamente al inicio de un proyecto sino que aparecen del mismo entendimiento del producto durante su fabricación” <prototipo>. Es responsabilidad del equipo de desarrollo el aplicar un diseño sencillo para el control de cambios dentro de la configuración modular del producto. <DSN_XP>
  • 59. Así adoptamos este principio ADOPCIÓN DE SCRUM Y XP <Principio DSN_XP>
  • 60. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Respuesta ante el cambio sobre seguir un plan Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este principio, la ventaja competitiva para el cliente implica de por sí la involucración del cliente en el proceso de desarrollo, tanto el cliente como el equipo de desarrollo son responsables del éxito o fracaso de un proyecto, pese a lo dicho, el fracaso representa para el equipo de desarrollo una ventaja a favor del aprendizaje y de la mejora continua. Es responsabilidad del cliente el definir adecuadamente el impacto de un cambio en la gestión de su negocio. <DSN_XP>
  • 61. Así adoptamos este principio PLANIFICACIÓN CONTINUA DEL PRODUCTO <Principio DSN_XP>
  • 62. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Respuesta ante el cambio sobre seguir un plan Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este principio, el ritmo constante se adquiere en base a un adecuado proceso de estimación de esfuerzos, aprendizaje y compromiso. Es responsabilidad del equipo de desarrollo el gestionar adecuadamente el proceso de construcción mediante el uso de mejores prácticas, marcos de trabajo, patrones de diseño y recodificación continua. <DSN_XP>
  • 63. Así adoptamos este principio TRANSPARENCIA, INSPECCIÓN, ADAPTACIÓN <Principio DSN_XP>
  • 64. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo y a continuación ajustar y perfeccionar su comportamiento en consecuencia. <Principio Ágil> A través de este trabajo hemos aprendido a valorar: Respuesta ante el cambio sobre seguir un plan Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este principio, la ventaja competitiva para el cliente implica de por sí la involucración del cliente en el proceso de desarrollo, tanto el cliente como el equipo de desarrollo son responsables del éxito o fracaso de un proyecto, pese a lo dicho, el fracaso representa para el equipo de desarrollo una ventaja a favor del aprendizaje y de la mejora continua. Es responsabilidad del cliente el definir adecuadamente el impacto de un cambio en la gestión de su negocio. <DSN_XP>
  • 65. Así adoptamos este principio TRABAJO COMO UN SOLO EQUIPO <Principio DSN_XP>
  • 66. Follow DSN_XP • En twitter: @dsn_xp • En Facebook: /dsnxp • E-mail: pacotoscano@gmail.com