Sunteți pe pagina 1din 13

Metodologas Clsicas o pesadas

METODOLOGAS CLSICAS O PESADAS


Mtrica V3

Mtrica Versin 3 ha sido concebida para abarcar el desarrollo completo de Sistemas de
Informacin sea cual sea su complejidad y magnitud, por lo cual su estructura responde a
desarrollos mximos y deber adaptarse y dimensionarse en cada momento de acuerdo a las
caractersticas particulares de cada proyecto.
La metodologa descompone cada uno de los procesos en actividades, y stas a su vez en tareas.
Para cada tarea se describe su contenido haciendo referencia a sus principales acciones,
productos, tcnicas, prcticas y participantes.
El orden asignado a las actividades no debe interpretarse como secuencia en su realizacin, ya
que stas pueden realizare en orden diferente a su numeracin o bien en paralelo, como se
muestra en los grficos de cada proceso. Sin embargo, no se dar por acabado un proceso hasta
no haber finalizado todas las actividades del mismo determinadas al inicio del proyecto. As los
procesos de la estructura principal de Mtrica V3 son los siguientes:
Planificacin de sistemas de informacin
Desarrollo de sistemas de informacin
Mantenimiento de sistemas de informacin

RUP
La metodologa RUP, llamada as por sus siglas en ingls Rational Unified Process, divide en 4
fases el desarrollo del software:
Inicio
Elaboracin
Construccin
Transicin

Cada una de estas etapas es desarrollada mediante un ciclo de iteraciones, la cual consiste en
reproducir el ciclo de vida en cascada a menor escala. Los objetivos de una iteracin se establecen
en funcin de la evaluacin de las iteraciones precedentes.

Caractersticas de RUP:

Es un proceso iterativo.-
Permite considerar las variaciones de los requisitos.
La integracin de los distintos elementos se realiza progresivamente.
Permite disminuir los riesgos.
Facilita la reutilizacin al identificar partes comunes.
Permite una arquitectura ms robusta.
Se puede autorefinar el proceso de desarrollo.

Gestiona los cambios en los requisitos.-
Facilita el control de proyectos complejos.
Mejora la calidad del software y la satisfaccin del cliente.

Se basa en las tcnicas de modelado propuestas por UML.

Persigue la calidad del producto y la calidad del proceso.

Contempla la gestin de configuracin y la gestin de cambios.

Es un proceso orientado por los casos de uso.


giles o Poco pesadas
AGILES O POCO PESADAS
XP (Extreme programming).-

No fue la primera metodologa ligera o gil, pero es de las ms conocidas por su acrnimo XP. Se ha
mostrado como una metodologa muy efectiva en grupos de trabajo reducidos gracias a la baja
complejidad, por este motivo, los detractores de metodologas giles, apuntan a problemas de
escalabilidad en el uso de estos enfoques.
XP elimina mucho trabajo superfluo, con lo que consigue mayor eficacia, sin embargo en grandes
empresas, este trabajo extra es necesario para su correcto funcionamiento.
Los elementos de XP son los siguientes:
El juego de la planificacin (The Planning Game).-
XP convierte la planificacin de un proyecto en un juego de negocio. Involucra a todo el equipo en la
planificacin consiguiendo que la gente cooperativamente tome decisiones sobre su carga de trabajo, sus
responsabilidades, y las consecuencias de alcanzar o no los objetivos.
Todo este juego se realiza con historias que reflejan cada uno de los requisitos que necesita el cliente en
un lenguaje natural y una estimacin del esfuerzo necesario. Estas historias se valoran por el beneficio
empresarial del cliente y por su riesgo en el desarrollo. A partir de estos datos se gesta un plan de trabajo
basado en iteraciones, donde cada una dar al cliente un producto con un conjunto de servicios
priorizando su valor empresarial.

Pequeos estrenos.-
La continua liberacin de versiones del software en pequeos incrementos es una caracterstica de todos
los enfoques de giles en algn nivel. Esto conlleva varios beneficios:
Demuestra que el grupo de trabajo est desarrollando su actividad.
Puede proporcionar un valor real al cliente desde el principio, ayudando a compensar el costo del
proyecto.

Debido a que las historias son ordenadas por prioridad, la tendencia es entregar las ms valiosas funciones
al comienzo y, conforme progresa el desarrollo, perfila estas importantes funcionalidades a travs de las
sucesivas, lo que hace ms probable que funcionen correctamente.
El uso de una metfora.-
Para facilitar que los desarrolladores entiendan el objetivo del sistema para el cliente, XP ofrece crear una
metfora que explique con un ejemplo que hay que desarrollar.
Diseo simple.-
XP obliga a utilizar siempre el diseo ms simple que cumpla los requisitos actuales. En principio esto
puede provocar que en futuras versiones se tenga que cambiar todo el diseo, por lo que XP define
historias de extensin que indican futuros cambios seguros.
Refactorizacin.-
Esta es sin duda la parte ms difcil de XP. Con las nuevas iteraciones, la actual representacin de la base
de conocimiento debe ser refactorizada o reestructurada para mantener representada todo el
conocimiento que se genera en cada iteracin. El reto de modificar la estructura existente de un sistema
de software para representar el total de la base de conocimientos es la filosofa del mantenimiento del
software. El problema puede encontrarse en que la actual estructura de conocimiento contradice con la
nueva que se genera.
Pruebas.-
La metodologa XP exige a una continua poltica de pruebas de todo el cdigo que se produce, as mismo,
pruebas de integracin de cada nueva funcionalidad en el sistema y pruebas globales. Podemos decir que
las pruebas tienen una alta importancia en XP.
Programacin en parejas.-
Es la caracterstica ms famosa de XP. Una persona sola es incapaz de ver sus fallos, por lo que XP
recomienda que los trabajos se realicen en parejas, uno ejecuta la tarea y otro comprueba lo que est
desarrollando.

Propiedad colectiva.-
Adems de la programacin en parejas, XP ensalza la propiedad colectiva de todo el trabajo, incluyendo
el cdigo.
Integracin continua.-
Los cortos ciclos, el desarrollo iterativo y la constante refactorizacin hacen necesario que todo el sistema
se integre diariamente. Esto proporciona resultados diarios sobre las pruebas de integracin.

Limitacin de las horas de trabajo seminal.-
Para mejorar el trabajo de los desarrolladores, las horas de trabajo a la semana deben estar limitadas. La
motivacin y el cansancio del grupo de trabajo pueden hacer que el proyecto no se ejecute
correctamente.

En el lado del cliente.-
XP intenta romper con las barreras entre clientes y desarrolladores, acercndolos para mejorar su
comunicacin. Para resolver los problemas del cliente, este debe estar motivado dentro del grupo de
trabajo, as como el grupo de trabajo debe conocer bien el dominio del cliente.
Estndares de cdigo.-
XP tambin recomienda incluir estndares de cdigo.

Code Science
Code Science es una variante del desarrollo de XP que aade, elimina y modifica algunos de los procesos
de XP:
Anlisis del proceso de negocio.-
XP, como la mayora de las otras metodologas, asumen la disponibilidad de los requerimientos de
negocio. Sin embargo, que pasa si el equipo no tiene acceso al cliente para responder a sus preguntas.
Code Sciente aade un paso inicial en el que analiza el entorno de negocio y su situacin.

Estimaciones Delphi.-
Adems del Juego de la planificacin se realiza una estimacin ms formal usando el enfoque Delphi.
Esta aproximacin permite no solo estimar, sino aproximar a su varianza que permitir calcular los riesgos.

Arquitectura modular.-
XP hace caso omiso de la arquitectura global del sistema a favor de la continua refactorizacin en los ciclos
de desarrollo. Code Science toma algunos de los elementos esenciales de diseo ms clsico de los
modelos de desarrollo para obtener una base de la arquitectura que ser ms estable.

Automatizacin del contrato y Pruebas de regresin.
Code Science aade los contratos basados en la validacin automatizada, en especial para las pruebas de
regresin, en el desarrollo y ciclo de pruebas de XP.

Historia de Actores y Requisitos Personalizados.-
Adems de los requisitos tpicos de reunin de modalidades tales como casos de uso, Code Science
emplea la idea de desarrollar requisitos personalizados. Estos son los requisitos que estn vinculados a
una persona ficticia que se utiliza para interactuar con los requisitos. Esto refuerza la historia y permite a
los desarrolladores interpolar y extrapolar los requisitos.

Wall GANTT.-
El sistema de gestin de proyectos se ubica en un lugar pblico de la oficina donde se registra en un panel
como van avanzando cada una de las tareas, cada da hay una reunin informal donde se discute el estado.
De esta forma, todos los miembros de la organizacin conocen la totalidad del proyecto.

Generacin automtica de la documentacin.-
Incluyendo documentacin a lo largo del cdigo, permite la generacin automtica de la documentacin
del trabajo. Para ello todos los ficheros fuentes deben estar totalmente comentados.

Code Science permite otros ajustes como relajar el desarrollo de cdigo en parejas o permite que los
trabajadores excedan las 40 horas semanales de trabajo modificar la metodologa para adaptarla a
condiciones externas (trabajar para un organismo que las requiera).
Crystals
Los mtodos Crystals comparten con XP una orientacin humana, pero se centra en las personas de forma
diferente. Explora una metodologa menos disciplinada cuyos principios se indican a continuacin:

Se centra en las personas en lugar de en los procesos: los procesos (herramientas, productos de su trabajo,
etc.) slo existen para apoyar la capacidad de comprensin humana.
Flexibilidad del mtodo: el mtodo debe adaptarse a los diferentes proyectos, no solo por lo que rodea a
los proyectos, sino porque cada proyecto es en esencia diferente y puede requerir diferentes procesos.

Productos intermedios de trabajo puede reducirse en nmero, tamao y complejidad: el cdigo de prueba
y el producto proporcionan un canal de comunicacin ms ricos que los documentos secundarios en
papel.

El proyecto necesita menos control cuando cobra impulso.
El desarrollo es cclico; tanto aprendizaje como produccin.
La entrega del trabajo software se deber regular cada 2 o 3 meses.
Participacin directa del cliente en el proyecto.
Los productos de trabajo como: requisitos, casos de uso, pruebas de interfaz de usuario, modelado de
objetos, etc. Se deja a la eleccin del grupo de trabajo, en funcin de la naturaleza del proyecto y de sus
requerimientos.
Adaptative Software Development
La tcnica de Adaptive Software Development fue desarrollada por Jim Highsmith y Sam Bayer a
comienzos de 1990 y queda referenciada en el libro Adaptive Software Development (Highsmith, 2000).

Al igual que otras metodologas giles, su funcionamiento es cclico y reconoce que en cada iteracin se
producirn cambios e incluso errores.
ASD utiliza un "cambio orientado hacia el ciclo de vida", que tiene tres componentes:
Especular o explorar las opciones.
Cclicamente colaborar utilizando una variedad de habilidades y capacidades del equipo para "crecer" la
comprensin del sistema y de su solucin.
Aprender o mejor extraer lo que se ha aprendido para permitir que los conocimientos se apliquen al
sistema.

Estos componentes definen las siguientes actividades:
Especular.-
Una primera fase de iniciacin para establecer los principales objetivos y metas del proyecto en su
conjunto y comprender las limitaciones (zonas de riesgo) con las que operar el proyecto.

Es ASD se realizan estimaciones de tiempo sabiendo que pueden sufrir desviaciones. Sin embargo, estas
son necesarias para la correcta atencin de los trabajadores que se mueven dentro de plazos de forma
que puedan priorizar sus tareas.
Se decide el nmero de iteraciones para consumir el proyecto, prestando atencin a las caractersticas
que pueden ser utilizadas por el cliente al final de la iteracin. Son por tanto necesarios, marcar objetivos
prioritarios dentro de las mismas iteraciones.
Estos pasos se puede volver a examinar varias veces antes de que el equipo y los clientes estn satisfechos
con el resultado.
Colaborar.-
Es la fase donde se centra la mayor parte del desarrollo manteniendo una componente cclica. Un trabajo
importante es la coordinacin que asegure que lo aprendido por un equipo se transmite al resto y no
tenga que volver a ser aprendido por los otros equipos.
Aprender.-
La ltima etapa termina con una serie de ciclos de colaboracin, su trabajo consiste en capturar lo que se
ha aprendido, tanto positivo como negativo. Es un elemento crtico para la eficacia de los equipos.

Jim Highsmith identifica cuatro tipos de aprendizaje en esta etapa:
Calidad del producto desde un punto de vista del cliente. Es la nica medida legtima de xito, pero
adems, dentro de las metodologas giles, los clientes tienen un valor importante.

Calidad del producto desde un punto de vista de los desarrolladores. Se trata de la evaluacin de la
calidad de los productos desde un punto de vista tcnico. Ejemplos de esto incluyen la adhesin a las
normas y objetivos conforme a la arquitectura.
La gestin del rendimiento. Este es un proceso de evaluacin para ver lo que se ha aprendido mediante
el empleo de los procesos utilizados por el equipo.
Situacin del proyecto. Como paso previo a la planificacin de la siguiente iteracin del proyecto, es el
punto de partida para la construccin de la siguiente serie de caractersticas.
Scrum
Scrum fue desarrollado por Ken Schwaber y Jeff Sutherland y debidamente documentado en libro Agile
Software Development with Scrum (Schwaber, 2001).
Scrum se basa en ciclos de 30 das denominados Sprints, conformados por tres fases de planificacin,
desarrollo y monitorizacin. Las tres etapas se denominan pre-Sprint, Sprint y Post-Sprint.
Pre-Sprint.-
Antes de iniciar esta fase es necesario definir el Product Backlog. Este documento es responsabilidad del
cliente y en l comentar y priorizar las caractersticas del producto que necesite.
A partir de los datos del cliente, en esta primera fase se realiza la planificacin de los elementos que
esperan ser completados, tanto funciones del usuario y tecnologa como arquitectura del sistema.

Sprint.-
En esta fase se ejecutan las tareas identificadas permitiendo que los grupos se gestionen de forma
autnoma. Una caracterstica destacada es la reunin diaria scrum, una reunin informal donde se
comenta sobre la planificacin y el progreso que tiene el proyecto. En ella deben intervenir todas las
personas involucradas en el proyecto: desarrolladores y usuarios.
Durante los ciclos Sprint no se permiten modificaciones de la funcionalidad del producto, para ofrecer a
los grupos de trabajo un entorno estable.
Post-Sprint.-
Al final de cada ciclo se examinan los logros y deficiencias que se produjeron. Y por otro lado, el cliente
comprueba la funcionalidad del producto provisional.
Feature-Driven Development (FDD)
Feature-Driven Development (FDD) fue desarrollado por Jeff De Luca y Peter Coad, para ejecutar un
proyecto de un banco en Singapur a finales de 1990; antes el proyecto fue otorgado a una gran consultora
que no lo finaliz, generando enormes cantidades de documentacin pero no de cdigo.

FDD est documentado en el libro A Practical Guide to Feature-Driven Development (Palmer, 2002).

FDD tiene un par de caractersticas distintivas que hacen que sea de gran inters:

Es uno de los pocos mtodos diseados a partir del desarrollo de un gran sistema, y muestra algunas de
las cuestiones relativas a la escalabilidad.
No est centrada en el cdigo como otros mtodos; los trabajos tambin se centran en realizar un
modelado.

Por ltimo FDD utiliza un modelo de cinco etapas permitiendo cambios en el proyecto durante su
desarrollo y como en otros mtodos giles, flexibilizando las fases.

Desarrollar un modelo general.-
En esta primera etapa se desarrolla el modelado general del sistema sin entrar en detalles. Los detalles
son pospuestos para fases posteriores. El propsito de esta etapa es crear una base para la planificacin
del proyecto.
Construir Caractersticas.-
A partir del modelo y las prestaciones que necesita el cliente se genera la lista de caractersticas del
sistema. Se utiliza un enfoque denominado arriba-abajo, donde se van descomponiendo las funciones
solicitadas por el cliente.
Plan de Reportaje.-
El listado de caractersticas es utilizado por el equipo de planificacin de desarrollo para priorizarlas y
definir las funcionalidades del sistema al finalizar cada ciclo.
Diseo de Reportaje.-
Conjuntos de caractersticas relacionadas se integran en paquetes que sern las unidades que despus se
traducirn en cdigo.
Construir por Caracterstica.-
Cada equipo completa sus caractersticas asignadas implementando las clases y mtodos, escribiendo e
inspeccionando el cdigo, generando pruebas, e integrando todo a nivel de sistema.

Rapid Application Development (RAD)
Rapid Application Development (RAD) se desarroll como respuesta a los enfoques no giles de la dcada
de 1970 como el modelo en cascada. El problema que mantienen los anteriores enfoques radica en el
excesivo consumo de tiempo en definir las necesidades y cuando el sistema se desarrollaba quedaba
obsoleto por posibles cambios. A partir de las ideas de Brian Gallagher, Barry Boehm y Scott Shultz, James
Martin desarroll RAD en 1980 para IBM, formalizndolo en el libro Rapid Application Development
(Martin, 1991).
La metodologa se basa en el desarrollo iterativo, la construccin de prototipos y el uso de utilidades CASE
(Computer Aided Software Engineering). Tradicionalmente, el desarrollo de aplicaciones con este enfoque
implica compromisos en la facilidad de uso, funcionalidad y velocidad de ejecucin.

Es descrito como un proceso a travs del cual el ciclo de desarrollo de una aplicacin es acelerado,
permitiendo productos de calidad que se desarrollarn ms rpido, ahorrando recursos.

diagrama de flujo de rad.

Algunas de sus ventajas son:
Velocidad del desarrollo.- Los aumentos de la velocidad son debido al uso de la herramienta CASE.
Calidad.- Segn lo definido por el RAD, es el grado al cual un uso entregado resuelve las necesidades de
usuarios as como el grado al cual un sistema entregado tiene costes de mantenimiento bajos. El RAD
aumenta calidad con la implicacin del usuario en las etapas del anlisis y del diseo.

Por contrapartida RAD tiene dos desventajas principales:
Caractersticas reducidas.
Escalabilidad reducida.- debido a que RAD se desarrolla con prototipos.

Dynamic Systems Development Method (DSDM)
Este enfoque surgi a partir de Rapid Application Development (RAD). Cuenta con gran aceptacin en
Europa y ha generado grupos de presin en EE.UU. Como su nombre indica, tiene la intencin de ser ms
rpido y flexible que los mtodos tradicionales, y su incorporacin en la familia de mtodos giles indica
que es capaz de aceptar los cambios. Hay nueve principios bases por los que opera DSDM:
La participacin del usuario cliente es imprescindible.
Los equipos de desarrollo estn facultados para la toma de decisiones.
Entrega frecuente de versiones del producto al cliente.
El valor y la aceptacin basan la aptitud para el negocio en lugar de una produccin mtrica.
Desarrollo iterativo para converger en la mejor solucin para el negocio.
Los cambios realizados durante el desarrollo pueden revertirse, si es necesario.
Los requisitos base estn a un nivel alto, que implica un cierto grado de estabilidad de las
necesidades durante el desarrollo.
Los exmenes estn integrados en todo el ciclo de vida en lugar de ser una fase especfica.
DSDM se produce en un entorno de colaboracin entre todos los interesados.

El enfoque DSDM tiene cuatro etapas (incluyendo un estudio de viabilidad), tres de las cuales son cclicas.

Estudio de Factibilidad.-
Se desarrolla, bien antes del comienzo de un proyecto (si es nuevo) o entre los principales ciclos de
desarrollo. Su propsito es el clsico trabajo de viabilidad para determinar el alcance del proyecto, de este
modo, los proyectos que no son viables no se inician. Produce una lista inicial de necesidades funcionales
priorizadas, que se usar en la fase de modelado funcional.
Modelado funcional.-
DSDM explcitamente utiliza un enfoque de prototipos, probando, refinando, y aproximando los requisitos
del sistema en cada prototipo, en vez de utilizar documentacin pasiva en papel. Este ciclo se realiza con
ciclos de revisin incorporados para comprobar el funcionamiento del prototipo. El xito del prototipo
conduce la prxima fase.
Diseo y Construccin.-
Las fases de diseo y construccin pueden superponerse con otras fases; basan en los prototipos su
actividad principal. Los prototipos pueden ser construidos o ampliados en la fase de modelado funcional
y puede abordar cualquier aspecto (priorizados) del desarrollo: caractersticas, requisitos, funciones,
interfaces, capacidad, rendimiento, etc. DSDM depende ms, o quizs ms especficamente, sobre los
prototipos que otros enfoques.
Aplicacin.-
El final llega a partir de los prototipos de la fase de diseo y construccin con una mejora completa del
funcionamiento, incluyendo los servicios adicionales necesarios para que el sistema sea operativo.

DSDM tiene algunas facetas interesantes como que gran parte de la documentacin se considera los
propios prototipos. Tambin sugiere interesantes funciones para el director de proyecto y desarrollador.
Ofrece distintos roles a los usuarios/clientes del sistema:
Visionary.- Responsable de los objetivos del sistema a alto nivel.
Ambassador.- Comprende los procesos de negocio.
Advisor.- Se convierte en el asesor del equipo de desarrollo en el da a da.

Agile Unified Process (AUP)
Scott Ambler centra todo su trabajo en la mejora de Rational Unified Process, ya en 1999 desarroll
Enterprise Unified Process (EUP) que converta RUP en un verdadero ciclo de vida para el desarrollo de
sistemas informticos. A partir de 2001 se intenta imprimir aspectos giles hasta que en 2005 se libera la
primera versin de AUP.
As Agile Unifed Process describe de forma simple y fcil la creacin de software funcional usando tcnicas
giles y aplicando las mejores caractersticas de RUP. AUP aplica tcnicas comunes a otros enfoques giles
como el diseo conducido por pruebas, desarrollo dirigido por modelos giles, gestin gil de los cambios,
y tcnicas de refactorizacin de la base de datos para mejorar la productividad.

Como RUP, AUP define cuatro fases:
Inicio.-
Identifica el alcance inicial del proyecto, una posible arquitectura para el sistema, aborda la financiacin
del proyecto y la aceptacin de las condiciones por los implicados en el proyecto.

Elaboracin.-
Prueba la arquitectura del sistema.
Construccin.-
Construye el software sobre una base estable, las necesidades se van resolviendo de forma incremental
comenzando por las de ms alta prioridad para los clientes del proyecto.
Transicin.-
Valida y despliegue del sistema en el ambiente de produccin.

tareas en cada fase de aup.

De forma diferente a como lo define RUP, AUP tiene solamente siete disciplinas:
Modelo.-
Entender el negocio del cliente, el dominio del problema que trata el proyecto, e identificar una solucin
viable para tratar el problema.
Puesta en prctica.-
Transformar el modelo en cdigo ejecutable y realizar pruebas a un nivel bsico.
Prueba.-
Realizar una evaluacin objetiva para asegurar la calidad. Esto incluye encontrar defectos, validar que el
sistema trabaja segn lo diseado, y verificar que los requisitos estn resueltos.
Despliegue.-
Plan para la entrega del sistema haciendo que est disponible para los usuarios.
Gerencia de la Configuracin.-
Manejar el acceso a los artefactos del proyecto. Esto incluye no solamente seguir versiones de los
artefactos sino controlando los cambios que se producen en ellos.
Gerencia del Proyecto.-
Dirigir las actividades que ocurre dentro del proyecto. Esto incluye riesgos asumidos, direccin y
coordinacin del personal (asignacin de tareas, seguimiento del proyecto, etc.), y gestin de los recursos
externos para asegurar la entrega del producto dentro del tiempo y presupuesto.

Ambiente.-
Apoyar el esfuerzo asegurando que el proceso, guas (estndares y pautas), y las herramientas apropiadas
(hardware, software, etc.) esten disponibles para el equipo segn lo necesiten.
AUP se basa en las siguientes filosofas:
El personal sabe lo que est haciendo. El personal no va a leer una documentacin del proceso detallada,
sino que prefieren una gua a alto nivel o un tiempo de entrenamiento. El producto AUP proporciona
enlaces a muchos detalles que pueden ser vistos si se est interesado, pero es mejor no forzar a leerlos.

Simplicidad.- Se describe todo usando solo unas cuantas pginas, no millones de ellas.
Agilidad.- AUP se conforma con los valores y los principios del desarrollo gil del software y de la alianza
gil.

Foco de actividades de alto valor.- Centrarse en las actividades que van a suceder realmente, no a cada
cosa posible de poder suceder en el proyecto.
Independencia de la herramienta.- Se puede utilizar cualquier conjunto de herramientas con la
metodologa AUP. La recomendacin es que se utilicen las herramientas que satisfacen lo mejor posible
el trabajo, que son a menudo herramientas simples (como muchas soluciones de cdigo abierto).

Desear adaptar el AUP para resolver sus propias necesidades.
Por ltimo, AUP distingue entre dos tipos de iteraciones:

lnea de tiempo para proyectos aup.
Lean Development (LD)
Lean Development (LD) se origin como un enfoque sobre gestin de Bob Charette, y trmino definido en
el libro The Machine that Changed the World: The Story of Lean Production (Womack, 1991).
Bob Charette se limita a tratar de acelerar el desarrollo, aumentando el riesgo, sin aumentar la capacidad
equivalente para hacer frente al riesgo. LD identifica cuatro factores clave y doce principios. Los factores
clave de xito son:
Crear valor visible para el cliente rpidamente.
Construir en vez de cambiar la tolerancia.
Desarrollar slo la funcionalidad necesaria,
Ser agresivos en la fijacin de objetivos.
Los doce principios de LD son los siguientes:
Satisfacer al cliente como la ms alta prioridad; no cumplir un plan, llenar un documento, satisfacer a un
jefe, o construir algn tcnicamente muy avanzado.
Mejorar el valor econmico. El valor es la diferencia entre el coste para la creacin y el valor de negocio
que el sistema genera.
La participacin activa del cliente como uno de los engranajes que trabaja en el proyecto; formar parte
en la toma de decisiones del proyecto y sus consecuencias.
Esfuerzo de equipo en todos los aspectos de desarrollo, incluida la planificacin.

Aceptar el cambio como parte de la empresa, anticipar lo que podra ocurrir, esperar que se produzcan, y
ocuparse cuando se produzca.
Desarrollar soluciones para un dominio y no para un determinado problema.
Completar en lugar de construir. Comenzar con diseos base, utilizar lo que ofrezca el mercado, no iniciar
la construccin desde cero.
Solucin pragmtica de hoy en lugar de la solucin perfecta de maana. Los estudios han demostrado que
gran parte de la funcionalidad del software sigue siendo no utilizada a veces aos despus de desarrollo.
Impulsado por el primer principio de valor para el cliente, la solicitud anterior de algn valor es a menudo
ms valiosa que la solicitud posterior de ms valor.
Minimizar el papeleo, los gastos generales, material extra, por el exceso de comunicacin.

La necesidad determina la tecnologa en lugar de utilizar la tecnologa para alcanzar las necesidades. Elegir
una tecnologa viable y usarla en lugar de seguir buscando la tecnologa perfecta.
El crecimiento est determinado por un mayor nmero de funciones, no por ms cdigo. El tamao de
cdigo puede ser irrelevante. Lo importante es lo que (por valor) el sistema puede proporcionar.

Usar Lean Development donde su funcionamiento sea bueno. Si bien el entorno empresarial es cada vez
ms cambiante, y las necesidades de metodologas giles est creciendo, ninguno de estos enfoques es
perfecto, garantiza el xito al 100 por ciento, est universalmente aceptado en todas las empresas, y no
tiene esfuerzo. LD es una herramienta y al igual que otras herramientas, deben ser utilizadas con
inteligencia.

S-ar putea să vă placă și