PRCTICA N 1

Nombre:

Molina Suarez Ivan

Fecha: 30/08/2016

Materia:

SIS 3651 A Diseo de Sistemas

Docente:

M. Cs. Ing. Nelson Tapia Hinojosa

PARADIGMAS Y METODOS RECIENTES DE DESARROLLO AGIL

1) SCRUM
SCRUM es el nombre con el que se denomina a los marcos de desarrollo giles caracterizados por:

Adoptar una estrategia de desarrollo incremental, en lugar de la planificacin y ejecucin completa del
producto.

Basar la calidad del resultado ms en el conocimiento tcito de las personas en equipos auto organizados, que
en la calidad de los procesos empleados.

Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o
en cascada.

Caractersticas de Scrum
SCRUM es un modelo de referencia que define un conjunto de prcticas y roles, y que puede tomarse como punto de
partida para definir el proceso de desarrollo que se ejecutar durante un proyecto. Los roles principales en Scrum son
el Scrum Master, que procura facilitar la aplicacin de scrum y gestionar cambios, el Product Owner, que representa
a los stakeholders (interesados externos o internos), y el Team (equipo) que ejecuta el desarrollo y dems elementos
relacionados con l. Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el
equipo y debe ser lo ms corta posible), el equipo crea un incremento de software potencialmente entregable
(utilizable). El conjunto de caractersticas que forma parte de cada sprint viene del Product Backlog, que es un
conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar (PBI, Product Backlog Item). Los
elementos del Product Backlog que forman parte del sprint se determinan durante la reunin de Sprint Planning.
Durante esta reunin, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y
los hace del conocimiento del equipo. Entonces, el equipo conversa con el Product Owner buscando la claridad y
magnitud adecuadas (Cumpliendo el INVEST) para luego determinar la cantidad de ese trabajo que puede
comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo
que significa congelados durante el sprint.
Scrum permite la creacin de equipos auto-organizados impulsando la co-localizacin de todos los miembros del
equipo, y la comunicacin verbal entre todos los miembros y disciplinas involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea
sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafos impredecibles no
pueden ser fcilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una
aproximacin pragmtica, aceptando que el problema no puede ser completamente entendido o definido, y
centrndose en maximizar la capacidad del equipo de entregar rpidamente y responder a requisitos emergentes.

Las caractersticas ms marcadas que se logran notar en Scrum seran: gestin regular de las expectativas del cliente,
resultados anticipados, flexibilidad y adaptacin, retorno de inversin, mitigacin de riesgos, productividad y
calidad, alineamiento entre cliente y equipo, por ltimo equipo motivado. Cada uno de estos puntos mencionados
hacen que el Scrum sea utilizado de manera regular en un conjunto de buenas prcticas para el trabajo en equipo y de
esa manera obtener resultados posibles.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas
"post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fcil de
aprender, y requiere muy poco esfuerzo para comenzarse a utilizar. As, si se utiliza una pizarra con notas
autoadhesivas cualquier miembro del equipo podr ver tres columnas: trabajo pendiente ("backlog"), tareas en
proceso ("in progress") y hecho ("done"). De un solo vistazo, una persona puede ver en qu estn trabajando los
dems en un momento determinado.

Roles en Scrum

Roles Principales

Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde
la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product
Backlog.
ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstculos que impiden que el
equipo alcance el objetivo del sprint. El ScrumMaster no es el lder del equipo (porque ellos se auto-organizan), sino
que acta como una proteccin entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de
que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
Equipo de desarrollo
El equipo tiene la responsabilidad de entregar el producto. Es recomendable un pequeo equipo de 3 a 9 personas
con las habilidades transversales necesarias para realizar el trabajo (anlisis, diseo, desarrollo, pruebas,
documentacin, etc).

Roles Auxiliares

Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol formal y no se involucran
frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una
aproximacin gil es la prctica de involucrar en el proceso a los usuarios, expertos del negocio y otros
interesados ("stakeholders"). Es importante que esa gente participe y entregue retroalimentacin con respecto a la
salida del proceso a fin de revisar y planear cada sprint.
Stakeholders (Clientes, Proveedores, Vendedores, etc).
Administradores (Managers)
Son los responsables de establecer el entorno para el desarrollo del proyecto.
Sprint
El Sprint es el perodo en el cual se lleva a cabo el trabajo en s. Es recomendado que la duracin de los sprints sea
constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duracin de sprint
en particular (2 o 3 semanas) e ir ajustndolo con base en el ritmo del equipo, aunque sin relajarlo demasiado. Al
final de cada sprint, el equipo deber presentar los avances logrados, y el resultado obtenido es un producto que,
potencialmente, se puede entregar al cliente.

As mismo, se recomienda no agregar objetivos al sprint o sprint backlog a menos que su falta amenace al xito del
proyecto. La constancia permite la concentracin y mejora la productividad del equipo de trabajo.
Beneficios de Scrum

Flexibilidad a cambios. Gran capacidad de reaccin ante los cambiantes requerimientos generados
por las necesidades del cliente o la evolucin del mercado. El marco de trabajo est diseado para
adecuarse a las nuevas exigencias que implican proyectos complejos.

Reduccin del Time to Market. El cliente puede empezar a utilizar las caractersticas ms
importantes del proyecto antes de que est completamente terminado.

Mayor calidad del software. El trabajo metdico y la necesidad de obtener una versin de trabajo
funcional despus de cada iteracin, ayuda a la obtencin de un software de alta calidad.

Mayor productividad. Se logra, entre otras razones, debido a la eliminacin de la burocracia y la

motivacin del equipo proporcionado por el hecho de que pueden estructurarse de manera autnoma.

Maximiza el retorno de la inversin (ROI). Creacin de software solamente con las prestaciones
que contribuyen a un mayor valor de negocio gracias a la priorizacin por retorno de inversin.

Predicciones de tiempos. A travs de este marco de trabajo se conoce la velocidad media del equipo
por sprint, con lo que es posible estimar de manera fcil cuando se podr hacer uso de una
determinada funcionalidad que todava est en el Backlog.

Reduccin de riesgos El hecho de desarrollar, en primer lugar, las funcionalidades de mayor valor y
de saber la velocidad a la que el equipo avanza en el proyecto, permite despejar riesgos efectivamente
de manera anticipada.

2) MTODO DE DESARROLLO DE SISTEMAS DINMICOS

El mtodo de desarrollo de sistemas dinmicos (en ingls Dynamic Systems Development Method o DSDM) es un
mtodo que provee un framework para el desarrollo gil de software, apoyado por su continua implicacin del
usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos cambiantes, para desarrollar un
sistema que rena las necesidades de la empresa en tiempo y presupuesto. Es uno de un nmero de mtodos de
desarrollo gil de software y forma parte de la alianza gil.
DSDM fue desarrollado en el Reino Unido en los aos 90 por un consorcio de proveedores y de expertos en la
materia del desarrollo de sistemas de informacin (IS), el consorcio de DSDM, combinando sus experiencias de
mejores prcticas. El consorcio de DSDM es una organizacin no lucrativa y proveedor independiente, que posee y
administra el framework. La primera versin fue terminada en enero de 1995 y publicada en febrero de 1995. La
versin actualmente en uso (abril de 2006) es la versin 4.2: El framework para el Negocio Centralizado
Desarrollado lanzado en mayo de 2003.
Como extensin del Desarrollo rpido de aplicaciones (RAD), DSDM se centra en los proyectos de sistemas de
informacin que son caracterizados por presupuestos y agendas apretadas. DSDM trata los problemas que ocurren
con frecuencia en el desarrollo de los sistemas de informacin en lo que respecta a pasar sobre tiempo y presupuesto
y otras razones comunes para la falta en el proyecto tal como falta de implicacin del usuario y de la comisin
superior de la gerencia.
DSDM consiste en 3 fases: fase del pre-proyecto, fase del ciclo de vida del proyecto, y fase del post-proyecto. La
fase del ciclo de vida del proyecto se subdivide en 5 etapas:

1. estudio de viabilidad,
2. estudio de la empresa,
3. iteracin del modelo funcional,
4. diseo e iteracin de la estructura, e
5. implementacin.
DSDM reconoce que los proyectos son limitados por el tiempo y los recursos, y los planes acorde a las necesidades
de la empresa. Para alcanzar estas metas, DSDM promueve el uso del RAD con el consecuente peligro que
demasiadas esquinas estn cortadas. DSDM aplica algunos principios, roles, y tcnicas.
En algunas circunstancias, hay posibilidades para integrar contenido de otros mtodos, tal como el Proceso
Unificado de Rational (RUP), Programacin Extrema (XP), y Proyectos en ambientes controlados (PRINCE2), para
complementar el DSDM en la realizacin de un proyecto. Otro mtodo gil que tiene semejanzas proceso y concepto
con DSDM es Scrum.
Principios del DSDM
Hay 9 principios subyacentes al DSDM consistentes en cuatro fundamentos y cinco puntos de partida para la
estructura del mtodo. Estos principios forman los pilares del desarrollo mediante DSDM.

Involucrar al cliente es la clave para llevar un proyecto eficiente y efectivo, donde ambos, cliente y
desarrolladores, comparten un entorno de trabajo para que las decisiones puedan ser tomadas con precisin.

El equipo del proyecto debe tener el poder para tomar decisiones que son importantes para el progreso del
proyecto, sin esperar aprobacin de niveles superiores.

DSDM se centra en la entrega frecuente de productos, asumiendo que entregar algo temprano es siempre
mejor que entregar todo al final. Al entregar el producto frecuentemente desde una etapa temprana del
proyecto, el producto puede ser verificado y revisado all donde la documentacin de registro y revisin
puede ser tenida en cuenta en la siguiente fase o iteracin.

El principal criterio de aceptacin de entregables en DSDM reside en entregar un sistema que satisface las
actuales necesidades de negocio. No est dirigida tanto a proporcionar un sistema perfecto que resuelva
todas las necesidades posibles del negocio, si no que centra sus esfuerzos en aquellas funcionalidades crticas
para alcanzar las metas establecidas en el proyecto/negocio.

El desarrollo es iterativo e incremental, guiado por la realimentacin de los usuarios para converger en una
solucin de negocio precisa.

Todos los cambios durante el desarrollo son reversibles.

El alcance de alto nivel y los requerimientos deberan ser base-lined antes de que comience el proyecto.

Las pruebas son realizadas durante todo el ciclo vital del proyecto. Esto tiene que hacerse para evitar un
caro coste extraordinario en arreglos y mantenimiento del sistema despus de la entrega.

La comunicacin y cooperacin entre todas las partes interesadas en el proyecto es un prerrequisito

importante para llevar un proyecto efectivo y eficiente.

DSDM tambin se apoya en otros principios (tambin llamadas asunciones).

Ningn sistema es construido a la perfeccin en el primer intento (El principio de pareto - regla 80/20).
En el proceso de desarrollar un sistema de informacin, el 80% del beneficio de la empresa proviene del 20%
de los requisitos del sistema, as DSDM comienza implementando primero este 20% de requisitos para
cumplir con el 80% de las necesidades de la empresa, lo que es suficientemente bueno tanto en cuanto los
usuarios estn ntimamente involucrados en el proceso de desarrollo y en una posicin de asegurar que el
20% restante no causar serias consecuencias al negocio. Implementar la totalidad de requerimientos a
menudo causa que un proyecto supere plazos y presupuestos, as la mayora de las veces es innecesario
construir la solucin perfecta.

La entrega del proyecto debera ser a tiempo, respetando presupuestos y con buena calidad.

DSDM solo requiere que cada paso del desarrollo se complete lo suficiente como para que empiece el
siguiente paso. De este modo una nueva iteracin del proyecto puede comenzar sin tener que esperar a que la
previa se complete enteramente. Y con cada nueva iteracin el sistema se mejora incrementalmente.
Recurdese que las necesidades del negocio cambian constantemente y a cualquier ritmo con el tiempo.

Ambas tcnicas de Desarrollo y Gestin de proyectos estn incluidas en DSDM.

Adems de desarrollar nuevos SI, DSDM puede ser usado tambin en proyectos de ampliacin de
sistemas TI actuales o incluso en proyectos de cambio no relacionados con las TI.

La Evaluacin de riesgos debiera centrarse en entregar funcin de negocio, no en el proceso de

construccin.

La gestin recompensa la entrega de productos ms que la consecucin de tareas.

La Estimacin debera estar basada en la funcionalidad del negocio en lugar de lneas de cdigo.

3) PROGRAMACIN EXTREMA
La programacin extrema o eXtreme Programming (de ahora en adelante, XP) es una metodologa de desarrollo de
la ingeniera de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999). Es el ms destacado de los procesos giles de desarrollo de software. Al igual
que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms
nfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos
sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser
capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor
y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en
controlar los cambios en los requisitos.
Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de
acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida
del software.
Valores
Los valores originales de la programacin extrema son: simplicidad, comunicacin, retroalimentacin (feedback) y
coraje. Un quinto valor, respeto, fue aadido en la segunda edicin de Extreme Programming Explained. Los cinco
valores se detallan a continuacin:

Simplicidad
La simplicidad es la base de la programacin extrema. Se simplifica el diseo para agilizar el desarrollo y facilitar el
mantenimiento. Un diseo complejo del cdigo junto a sucesivas modificaciones por parte de diferentes
desarrolladores hacen que la complejidad aumente exponencialmente.
Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es la manera de mantener el cdigo
simple a medida que crece.
Tambin se aplica la simplicidad en la documentacin, de esta manera el cdigo debe comentarse en su justa medida,
intentando eso s que el cdigo est autodocumentado. Para ello se deben elegir adecuadamente los nombres de las
variables, mtodos y clases. Los nombres largos no decrementan la eficiencia del cdigo ni el tiempo de desarrollo
gracias a las herramientas de autocompletado y refactorizacin que existen actualmente.
Aplicando la simplicidad junto con la autora colectiva del cdigo y la programacin por parejas se asegura que
cuanto ms grande se haga el proyecto, todo el equipo conocer ms y mejor el sistema completo.
Comunicacin
La comunicacin se realiza de diferentes formas. Para los programadores el cdigo comunica mejor cuanto ms
simple sea. Si el cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo autodocumentado es ms
fiable que los comentarios ya que stos ltimos pronto quedan desfasados con el cdigo a medida que es modificado.
Debe comentarse slo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un
mtodo.
Las pruebas unitarias son otra forma de comunicacin ya que describen el diseo de las clases y los mtodos al
mostrar ejemplos concretos de cmo utilizar su funcionalidad. Los programadores se comunican constantemente
gracias a la programacin por parejas. La comunicacin con el cliente es fluida ya que el cliente forma parte del
equipo de desarrollo. El cliente decide qu caractersticas tienen prioridad y siempre debe estar disponible para
solucionar dudas.
Retroalimentacin (feedback)
Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real.
Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no
cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es ms importante.
Considrense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda
debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El cdigo tambin es
una fuente de retroalimentacin gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan
sobre el estado de salud del cdigo. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a
cambios recientes en el cdigo.
Coraje o valenta
Muchas de las prcticas implican valenta. Una de ellas es siempre disear y programar para hoy y no para maana.
Esto es un esfuerzo para evitar empantanarse en el diseo y requerir demasiado tiempo y trabajo para implementar el
resto del proyecto. La valenta le permite a los desarrolladores que se sientan cmodos con reconstruir su cdigo
cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se
implementaran ms fcilmente. Otro ejemplo de valenta es saber cundo desechar un cdigo: valenta para quitar
cdigo fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirti en crear ese cdigo. Adems, valenta

significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un da entero, y
luego lo resolver rpidamente al da siguiente, slo si es persistente.
Respeto
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los
programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de
sus compaeros. Los miembros respetan su trabajo porque siempre estn luchando por la alta calidad en el producto
y buscando el diseo ptimo o ms eficiente para la solucin a travs de la refactorizacin del cdigo. Los miembros
del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo eleva su ritmo
de produccin.
Caractersticas fundamentales
Las caractersticas fundamentales del mtodo son:

Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.

Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin.

Se aconseja escribir el cdigo de la prueba antes de la codificacin. Vase, por ejemplo, las herramientas de
prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP.
Estas tres ltimas inspiradas en JUnit, la cual, a su vez, se insipir en SUnit, el primer framework orientado a
realizar tests, realizado para el lenguaje de programacin Smalltalk.

Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en
un mismo puesto. La mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido
mientras se escribe- es ms importante que la posible prdida de productividad inmediata.

Frecuente integracin del equipo de programacin con el cliente o usuario. Se recomienda que un
representante del cliente trabaje junto al equipo de desarrollo.

Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes.

Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la
refactorizacin no se ha introducido ningn fallo.

Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en
grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier
parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados.

Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr
aadir funcionalidad si es necesario. La programacin extrema apuesta que es ms sencillo hacer algo simple
y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca
utilizarlo.

La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms

fcil identificar qu se debe y qu no se debe hacer. Cuanto ms simple es el sistema, menos tendr que comunicar
sobre ste, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de
programadores.
Roles

Programador
Escribe las pruebas unitarias y produce el cdigo del sistema. Es la esencia del equipo.
Cliente
Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Asigna la prioridad a las
historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar el mayor valor de
negocio.
Tester
Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo
y es responsable de las herramientas de soporte para pruebas.
Tracker
Es el encargado de seguimiento. Proporciona realimentacin al equipo. Debe verificar el grado de acierto entre las
estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.
Entrenador (coach)
Responsable del proceso global. Gua a los miembros del equipo para seguir el proceso correctamente.
Consultor
Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Ayuda
al equipo a resolver un problema especfico. Adems este tiene que investigar segn los requerimientos.
Gestor (Big boss)
Es el dueo de la tienda y el vnculo entre clientes y programadores. Su labor esencial es la coordinacin.
4) KANBAN (DESARROLLO)
Kanban es un mtodo para gestionar el trabajo intelectual, con nfasis en la entrega justo a tiempo, mientras no se
sobrecargan a los miembros del equipo. En este enfoque, el proceso, desde la definicin de una tarea hasta su entrega
al cliente, se muestra para que los participantes lo vean y los miembros del equipo tomen el trabajo de una cola.
Kanban se puede dividir en dos partes:

Kanban - Un sistema de gestin de proceso visual que le indica qu producir, cundo producirlo, y cunto
producir.

El mtodo Kanban - Una aproximacin a la mejora del proceso evolutivo e incremental para las
organizaciones.

El mtodo Kanban
En el desarrollo de software, utilizamos un sistema Kanban virtual para limitar el trabajo en curso. A pesar de que el
nombre se origina del idioma japons "Kanban", y se traduce aproximadamente como "tarjeta de seal", y hay
tarjetas utilizadas en la mayora de las implementaciones de Kanban en desarrollo de software, estas tarjetas no
funcionan en realidad como seales para realizar ms trabajo. Representan los elementos de trabajo. De ah el
trmino "virtual" porque no existe una tarjeta fsica.

El mtodo Kanban formulado por David J. Anderson es una aproximacin al proceso gradual, evolutivo y al cambio
de sistemas para las organizaciones. Utiliza un sistema de extraccin limitada del trabajo en curso como mecanismo
bsico para exponer los problemas de funcionamiento del sistema (o proceso) y estimular la colaboracin para la
mejora continua del sistema. Un ejemplo del sistema de extraccin es el sistema Kanban, y es despus de esta
popular forma de trabajo en curso, que se ha denominado el mtodo.
Los principios del mtodo Kanban
El mtodo Kanban tiene sus races en cuatro principios bsicos:
1. Comience con lo que hace ahora
El mtodo Kanban se inicia con las funciones y procesos que ya se tienen y estimula cambios continuos,
incrementales y evolutivos a su sistema.
2. Se acuerda perseguir el cambio incremental y evolutivo
La organizacin (o equipo) deben estar de acuerdo que el cambio continuo, gradual y evolutivo es la manera
de hacer mejoras en el sistema y debe apegarse a ello. Los cambios radicales pueden parecer ms eficaces,
pero tienen una mayor tasa de fracaso debido a la resistencia y el miedo en la organizacin. El mtodo
Kanban anima a los pequeos y continuos cambios incrementales y evolutivos a su sistema actual.
3. Respetar el proceso actual, los roles, las responsabilidades y los cargos
Tenemos que facilitar el cambio futuro; acordando respetar los roles actuales, responsabilidades y cargos,
eliminamos los temores iniciales. Esto nos debera permitir obtener un mayor apoyo a nuestra iniciativa
Kanban.
4. Liderazgo en todos los niveles
Se debe alentar hechos de liderazgo en todos los niveles de la organizacin de los contribuyentes individuales
a la alta direccin.
Cinco prcticas centrales del mtodo Kanban
Anderson identific cinco caractersticas bsicas que haban sido observadas en cada implementacin correcta del
mtodo Kanban. Posteriormente fueron etiquetadas como prcticas y se ampliaron con la adicin de una sexta
caracterstica.
1. Visualizar
Visualizar el flujo de trabajo y hacerlo visible es la base para comprender cmo avanza el trabajo. Sin
comprender el flujo de trabajo, realizar los cambios adecuados es ms difcil. Una forma comn de visualizar
el flujo de trabajo es el uso de columnas. Las columnas representan los diferentes estados o pasos en el flujo
de trabajo.
2. Limitar el trabajo en curso
Limitar el trabajo en curso implica que un sistema de extraccin se aplica en la totalidad o parte del flujo de
trabajo. El sistema de extraccin acta como uno de los principales estmulos para los cambios continuos,
incrementales y evolutivos en el sistema.
3. Dirigir y gestionar el flujo

Se debe supervisar, medir y reportar el flujo de trabajo a travs de cada estado. Al gestionar activamente el
flujo, los cambios continuos, graduales y evolutivos del sistema pueden ser evaluados para tener efectos
positivos o negativos.
4. Hacer las Polticas de Proceso Explcitas
Configure las reglas y directrices de su trabajo. Entienda las necesidades y asegrese de seguir las reglas. Las
polticas definirn cundo y por qu una tarjeta debe pasar de una columna a otra. Escrbalas. Cambie las
reglas cuando la realidad cambie.
5. Utilizar modelos para reconocer oportunidades de mejora
Cuando los equipos tienen un entendimiento comn de las teoras sobre el trabajo, el flujo de trabajo, el
proceso y el riesgo, es ms probable que sea capaz de construir una comprensin compartida de un problema
y proponer acciones de mejora que puedan ser aprobadas por consenso. El mtodo Kanban sugiere que un
enfoque cientfico sea utilizado para implementar los cambios continuos, graduales y evolutivos. El mtodo
no prescribe un mtodo cientfico especfico para utilizarlo.
Comportamiento emergente con Kanban
Hay una creciente lista de comportamientos emergentes que hemos llegado a esperar de la implementacin de
Kanban, tales como:

Proceso nico a la medida de cada cadena de valor

Cadencias desacopladas

Trabajo programado por el costo de la demora

Valor optimizado con clases de servicio

Gestin de riesgo con asignacin de capacidad

Tolerancia en la experimentacin de procesos

Gestin cuantitativa

Propagacin viral de Kanban en toda la organizacin

Pequeos equipos fusionados para crear bolsas de trabajo ms fluidas.

La implementacin del mtodo Kanban

Algunos profesionales han implementado Kanban en fsico utilizando notas adhesivas, o tableros con ranuras. Ms a
menudo la seal es generada por un software de seguimiento de trabajos especiales, tales como:

Kanban Tool

JIRA Greenhopper

Cardmapping

Tablero Kanban online

Targetprocess

5) PROCESO UNIFICADO AGIL (AUP)

El Proceso Unificado Agil de Scott Ambler o Agile Unified Process (AUP) en ingls es una versin simplificada del
Proceso Unificado de Rational (RUP). Este describe de una manera simple y fcil de entender la forma de desarrollar
aplicaciones de software de negocio usando tcnicas giles y conceptos que an se mantienen vlidos en RUP. El
AUP aplica tcnicas giles incluyendo Desarrollo Dirigido por Pruebas (test driven development - TDD), Modelado
Agil, Gestin de Cambios Agil, y Refactorizacin de Base de Datos para mejorar la productividad.
El proceso unificado (Unified Process o UP) es un marco de desarrollo software iterativo e incremental. A menudo es
considerado como un proceso altamente ceremonioso porque especifica muchas actividades y artefactos
involucrados en el desarrollo de un proyecto software. Dado que es un marco de procesos, puede ser adaptado y la
ms conocida es RUP (Rational Unified Process) de IBM.
AUP se preocupa especialmente de la gestin de riesgos. Propone que aquellos elementos con alto riesgo obtengan
prioridad en el proceso de desarrollo y sean abordados en etapas tempranas del mismo. Para ello, se crean y
mantienen listas identificando los riesgos desde etapas inciales del proyecto. Especialmente relevante en este sentido
es el desarrollo de prototipos ejecutables durante la base de elaboracin del producto, donde se demuestre la validez
de la arquitectura para los requisitos clave del producto y que determinan los riesgos tcnicos.
El proceso AUP establece un Modelo ms simple que el que aparece en RUP por lo que rene en una nica disciplina
las disciplinas de Modelado de Negocio, Requisitos y Anlisis y Diseo. El resto de disciplinas (Implementacin,
Pruebas, Despliegue, Gestin de Configuracin, Gestin y Entorno) coinciden con las restantes de RUP.
CICLO DE VIDA DEL PROCESO UNIFICADO AGIL (AUP).-

Al igual que en RUP, en AUP se establecen cuatro fases que transcurren de manera consecutiva y que acaban con
hitos claros alcanzados: Inception(Concepcin): El objetivo de esta fase es obtener una comprensin comn
clienteequipo de desarrollo del alcance del nuevo sistema y definir una o varias arquitecturas candidatas para el
mismo.

 Elaboracin: El objetivo es que el equipo de desarrollo profundice en la comprensin de los requisitos del sistema
y en validar la arquitectura.
Construccin: Durante la fase de construccin el sistema es desarrollado y probado al completo en el ambiente de
desarrollo.
Transicin: el sistema se lleva a los entornos de preproduccin donde se somete a pruebas de validacin y
aceptacin y finalmente se despliega en los sistemas de produccin.
Las disciplinas se llevan a cabo de manera sistemtica, a la definicin de las actividades que realizan los miembros
del equipo de desarrollo a fin de desarrollar, validar, y entregar el software de trabajo que responda a las necesidades
de sus interlocutores. Las disciplinas son:
1. Modelo. El objetivo de esta disciplina es entender el negocio de la organizacin, el problema de dominio que se
abordan en el proyecto, y determinar una solucin viable para resolver el problema de dominio.
2. Aplicacin. El objetivo de esta disciplina es transformar su modelo (s) en cdigo ejecutable y realizar un nivel
bsico de las pruebas, en particular, la unidad de pruebas.
3. Prueba. El objetivo de esta disciplina consiste en realizar una evaluacin objetiva para garantizar la calidad. Esto
incluye la bsqueda de defectos, validar que el sistema funciona tal como est establecido, y verificando que se
cumplan los requisitos.
4. Despliegue. El objetivo de esta disciplina es la prestacin y ejecucin del sistema y que el mismo este a
disposicin de los usuarios finales.
5. Gestin de configuracin. El objetivo de esta disciplina es la gestin de acceso a herramientas de su proyecto. Esto
incluye no slo el seguimiento de las versiones con el tiempo, sino tambin el control y gestin del cambio para
ellos.
6. Gestin de proyectos. El objetivo de esta disciplina es dirigir las actividades que se lleva a cabo en el proyecto.
Esto incluye la gestin de riesgos, la direccin de personas (la asignacin de tareas, el seguimiento de los progresos,
etc), coordinacin con el personal y los sistemas fuera del alcance del proyecto para asegurarse de que es entregado a
tiempo y dentro del presupuesto.
7. Entorno. El objetivo de esta disciplina es apoyar el resto de los esfuerzos por garantizar que el proceso sea el
adecuado, la orientacin (normas y directrices), y herramientas (hardware, software, etc) estn disponibles para el
equipo segn sea necesario.
INCREMENTO Y DESARROLLO DE AUP.Los equipos de AUP suelen ofrecer versiones de desarrollo al final de cada iteracin en preproduccin rea (s). Una
versin de desarrollo de una aplicacin es algo que podran ser liberados en la produccin si se ponen a travs de su
pre-produccin de garanta de calidad (QA), las pruebas y los procesos de despliegue. La primera produccin de
liberacin a menudo toma ms tiempo para entregar versiones posteriores. La primera produccin de liberacin
puede tomar doce meses para entregar la segunda versin de nueve meses, y luego otras liberaciones se entregan
cada seis meses. Una de las primeras se centra en cuestiones de despliegue, no slo permite evitar los problemas,
sino que tambin permite tomar ventaja de sus experiencias durante el desarrollo. Por ejemplo, cuando despliegue un
software en su rea deber tomar notas de lo que funciona y lo que no, toma nota de que puede servir como la
columna vertebral de su instalacin de scripts.

PRINCIPIOS DE LA AUP.La AUP es gil, porque est basada en los siguientes principios:
1. El personal sabe lo que est haciendo. La gente no va a leer detallado el proceso de documentacin, pero algunos
quieren una orientacin de alto nivel y / o formacin de vez en cuando. La AUP producto proporciona enlaces a
muchos de los detalles, si usted est interesado, pero no obliga a aquellos que no lo deseen.
2. Simplicidad. Todo se describe concisamente utilizando un puado de pginas, no miles de ellos.
3. Agilidad. gil ARRIBA El ajuste a los valores y principios de la Alianza gil.
4. Centrarse en actividades de alto valor. La atencin se centra en las actividades que se ve que son esenciales para el
de desarrollo, no todas las actividades que suceden forman parte del proyecto.

5. Herramienta de la independencia. Usted puede usar cualquier conjunto de herramientas que usted desea con el gil
UP. Lo aconsejable es utilizar las herramientas que son las ms adecuadas para el trabajo, que a menudo son las
herramientas simples o incluso herramientas de cdigo abierto.
6. Adaptacin de este producto para satisfacer sus propias necesidades. La AUP producto es de fcil acomodo comn
a travs de cualquier herramienta de edicin de HTML. No se necesita comprar una herramienta especial, o tomar un
curso, para adaptar la AUP.
CONCLUSIONES.Si deseamos un mtodo gil entre XP y RUP tradicionales, que incluya explcitamente las actividades y las
herramientas que estn acostumbrados, entonces la ms aconsejable es la AUP.
XP no muestra explcitamente cmo crear algunos de las herramientas que la administracin quiere ver. En el otro
extremo del espectro est RUP, que es el gestor ms utilizado de los desarrolladores, pero presenta una gran cantidad
de herramientas. La AUP en comparacin entre los dos, es la adopcin de muchas de las tcnicas giles de XP y otros
procesos giles que mantiene de las RUP.
El usuario final es el mejor juez que determina se la AUP es el mtodo gil ms adecuado.
En relacin al XP, el AUP resulta ser un proceso muy pesado y en relacin al RUP resulta ser un proceso muy
simplificado, entonces, los desarrolladores debern decidir en: si desea buscar una forma de trabajo ligero esta XP y
si desea trabajar con un proceso ms detallado esta RUP.
6) LEAN SOFTWARE DEVELOPMENT
La metodologa de desarrollo de software lean (traduccin aproximada de lean: fino o esbelto) es una
traduccin de los principios y las prcticas 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 una corriente que est surgiendo
desde la comunidad gil. Este mtodo ofrece todo un marco terico slido y basado en la experiencia, para las
prcticas giles de gestin.
Los principios lean
El desarrollo lean puede resumirse en siete principios, similares a los principios de manufactura 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

Burocracia

Comunicacin interna lenta

Con el fin de poder eliminar los desperdicios deberamos ser capaces de reconocerlos y encontrarlos. Si alguna
actividad podra ser excluida o el mismo resultado podra ser logrado sin 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 otras actividades, equipos o procesos son desperdicio. Los defectos y la baja calidad son los
desperdicios. Los gastos de gestin que no producen valor real son desperdicios. Se utiliza una tcnica llamada value
stream mapping (o mapa de flujo de valor) para distinguir y reconocer los desperdicios. El segundo paso consiste en

sealar las fuentes de los desperdicios y eliminarlos. Lo mismo debe hacerse iterativamente hasta que incluso los
procesos 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 retos de los equipos de
desarrollo y el tamao del producto final. El mejor enfoque para encarar una mejora en el ambiente de desarrollo de
software es ampliar el aprendizaje. La acumulacin de defectos debe evitarse ejecutando las pruebas tan pronto como
el cdigo est escrito en lugar de aadir ms documentacin o planificacin detallada. Las distintas ideas podran ser
probadas escribiendo cdigo e integrndolo. El proceso de recopilacin de requisitos de usuarios podra simplificarse
mediante la presentacin de las pantallas de los usuarios finales para que estos puedan hacer sus aportes. El proceso
de aprendizaje es acelerado con el uso iteraciones cortas cada una de ellas acompaada de refactorizacin y sus
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 en el futuro. Durante las reuniones, tanto los clientes
como el equipo de desarrollo, logran aprender sobre el alcance del problema y buscan posibles soluciones para un
mejor desarrollo. Por lo tanto, los clientes comprenden mejor sus necesidades basndose en el resultado de los
esfuerzos del desarrollo y los desarrolladores aprenden a satisfacer mejor estas necesidades.
Otra idea para ampliar el aprendizaje es a travs de la integracin del cliente en el ambiente de desarrollo para
concentrar la comunicacin en las soluciones futuras y no en las soluciones posibles, promoviendo as el nacimiento
de la solucin a travs del dilogo con el cliente.
Decidir lo ms tarde posible
El desarrollo de software est siempre asociado con cierto grado de incertidumbre, los mejores resultados se
alcanzan con un enfoque basado en opciones por lo que se pueden retrasar las decisiones tanto como sea posible
hasta que stas se basen en hechos y no en suposiciones y pronsticos inciertos. Cuanto ms complejo es un
proyecto, ms capacidad para el cambio debe incluirse en ste, as que debe permitirse el retraso de los compromisos
importantes y cruciales. El enfoque iterativo promueve este principio: la capacidad de adaptarse a los cambios y
corregir los errores, ya que un error podra ser muy costoso si se descubre despus de la liberacin del sistema.
Un enfoque de desarrollo de software gil puede llevarles opciones rpidamente a los clientes, lo que implica,
retrasar algunas decisiones cruciales hasta que los clientes hayan reconocido mejor sus necesidades. Esto tambin
permite la adaptacin tarda a los cambios y previene las costosas decisiones delimitadas por la tecnologa. Esto no
significa que no haya planificacin involucrada en el proceso, por el contrario, las actividades de planificacin deben
centrarse en las diferentes opciones y se les adapta a la situacin actual; as como, se deben 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 el ms rpido. Cuanto antes
se entrega el producto final sin defectos considerables ms pronto se pueden recibir comentarios y se incorporan en
la siguiente iteracin. Cuanto ms cortas sean las iteraciones, mejor es el aprendizaje y la comunicacin dentro del
equipo. Sin velocidad, las decisiones no pueden ser postergadas. La velocidad asegura el cumplimiento de las
necesidades actuales del cliente y no lo que ste requera para ayer. Esto les da la oportunidad de demorarse
pensando lo que realmente necesitan, hasta que adquieran un mejor 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 la presentacin de resultados, la necesidad de dejar que el
equipo se organice y dividiendo las tareas para lograr el resultado necesario para una iteracin especfica.
Al principio, el cliente dispone los requisitos necesarios. Esto podra ser simplemente presentar los requisitos en
pequeas fichas o historias y los desarrolladores estimarn el tiempo necesario para la aplicacin de cada tarjeta. As,
la organizacin del trabajo cambia en sistema autopropulsado: cada maana durante una reunin inicial cada
miembro del equipo evala lo que se ha hecho ayer, lo que hay que hacer hoy y maana y pregunta por cualquier
nueva entrada necesaria de parte de sus colegas o del cliente. Esto requiere la transparencia 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 de diseo. 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 del problema 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 ejemplo de compromiso
aplazado hasta el ltimo momento posible. Las decisiones en el software tambin podran beneficiarse de esta
prctica para minimizar el riesgo provocado por un solo gran diseo realizado por adelantado.
Potenciar el equipo
Ha habido una creencia tradicional en la mayora de las empresas acerca de la toma de decisiones en la organizacin:
los administradores dicen a los trabajadores cmo hacer su propio trabajo. En una tcnica llamada Work-Out, los
roles cambian: a los directivos se les ensea a escuchar a los desarrolladores, de manera que stos puedan explicar
mejor qu acciones podran tomarse, as como ofrecer sugerencias para mejoras. Los directores de proyecto 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 personas podran ser los recursos desde el
punto de vista de una hoja de datos estadsticos, pero en el desarrollo de software, as como cualquier organizacin
de negocios, las personas necesitan algo ms que la lista de tareas y la seguridad de que no ser alterada durante la
realizacin de las tareas. Las personas necesitan motivacin y un propsito superior para el cual trabajar: un objetivo
alcanzable dentro de la realidad con la garanta de que el equipo puede elegir sus propios compromisos. Los
desarrolladores deberan tener acceso a los clientes; 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 llama percepcin de
integridad: Cmo es publicitado, entregado, implementado y accedido? Es su uso intuitivo? Precio? Hasta qu
punto resuelve los problemas?. Integridad Conceptual significa que los componentes separados del sistema
funcionan bien juntos, como en un todo, logrando equilibrio entre la flexibilidad, sostenibilidad, eficiencia y
capacidad de respuesta. Esto podra lograrse mediante la comprensin del dominio del problema y resolvindolo al
mismo tiempo, no secuencialmente. La informacin necesaria es recibida por los pequeos lotes, no en una vasta
cantidad y con una preferible comunicacin cara a cara, sin ninguna documentacin por escrito. El flujo de
informacin debe ser constante en ambas direcciones, a partir del cliente a los desarrolladores y viceversa, evitando
as la gran y estresante cantidad de informacin despus de un largo periodo de desarrollo en el aislamiento.
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 base para futuras mejoras. As como en la
Programacin extrema (XP), la refactorizacin es mantener la sencillez, la claridad, la cantidad mnima de

funcionalidades en el cdigo. Las repeticiones 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 suite completa y automatizada de
pruebas, tanto para desarrolladores y clientes que tengan la misma versin, sincronizacin y semntica que el sistema
actual. Al final, la integridad debe ser verificada con una prueba global, garantizando que el sistema hace lo que el
cliente espera que haga. Las pruebas automatizadas tambin son consideradas como parte del proceso de produccin
y, por tanto, si no agregan valor deben considerarse residuos. Las pruebas automatizadas no deberan ser un objetivo,
sino, un medio para un fin; especficamente para la reduccin de defectos.
Vase todo el conjunto
Los sistemas de software hoy en da no son simplemente la suma de sus partes, sino tambin el producto de sus
interacciones. Los defectos en el software tienden a acumularse durante el proceso de desarrollo por medio de la
descomposicin de las grandes tareas en pequeas tareas y de la normalizacin de las diferentes etapas de desarrollo.
Las causas reales de los defectos deben ser encontradas y eliminadas. Cuanto ms grande sea el sistema, ms sern
las organizaciones que participan en su desarrollo y ms partes son las desarrolladas por diferentes equipos y mayor
es la importancia de tener bien definidas las relaciones entre los diferentes proveedores con el fin de producir una
buena interaccin entre los componentes del sistema.
La manera de pensar ofrecida Lean tiene que ser bien entendida por todos los miembros de un proyecto antes de
aplicarlo de manera concreta en una situacin de la vida real.
"Piensa en grande, acta en pequeo, equivcate rpido; aprende con rapidez" estas consignas resumen la
importancia de comprender el terreno y la idoneidad de implementar los principios Lean lo largo del proceso de
desarrollo de software. Slo cuando todos los principios de Lean se aplican al mismo tiempo, combinado con un
fuerte "sentido comn" en relacin con el ambiente de trabajo, hay una base para el xito en el desarrollo de
software.