INTRODUCCIN EDITORES INVITADOS

Software gil
Desarrollo:
Se trata de
realimentacin
y Cambio
Actualmente, la atencin se centra en la determinacin de cmo mezclar las
metodologas giles con el plan impulsado por los enfoques para el desarrollo
de software.

Desarrollo gil de software ha dado en el clavo en la comunidad de desarrollo

de software.
Algunas personas sostienen a gritos por ello, otros argumentan igualmente en
contra de ella, y otros son trabajando para mezclar gil y un plan impulsado
por enfoques. Muchas ms personas se preguntan exactamente lo agilidad es.
QU ES LA AGILIDAD?
En muchos mtodos de desarrollo, particularmente los planes impulsados se
cuenta el trabajo se inicia con la solicitud y la documentacin un conjunto
completo de requisitos. Comienzo a mediados de la dcada de 1990, muchos
encontraron estos requisitos iniciales paso documentacin frustrante y, tal vez,
imposible. Tanto la tecnologa y el entorno empresarial mantenido mueva
durante el proyecto, y ambos los requisitos y los planes del proyecto se
salieron de la fecha dentro incluso proyectos relativamente cortos. Clientes se
convirti cada vez ms incapaz de afirmar definitivamente sus necesidades en
la delantera.
Como resultado, los practicantes desarrollaron metodologas y prcticas para
abrazar, en lugar de rechazar, las tasas ms altas de cambio. Estas
metodologas fueron desarrollado en tres continentes diferentes: el Sistemas
Dinmicos mtodo de desarrollo en Europa; Feature-Driven Development en
Australia; y Extreme Programming, Crystal, software adaptativo Desarrollo y
Scrum en los EE.UU.. Aunque su prcticas y filosofas fundamental compartido.
Similitudes, estos practicantes autor de sus metodologas de forma
independiente.
Valores subyacentes

En febrero de 2001, 17 de estos profesionales y autores se reunieron en

Snowbird, Utah, para discutir la fundamental semejanza de sus experiencias y
su el entonces llamado Finding metodologas.2 ligero que sus hbitos de
trabajo tenan mucho en comn, reconocido que la ligereza en su proceso de
trabajo previsto un medio para alcanzar el fin ms relevantes: la satisfaccin
del cliente y de alta calidad. Categorizaron sus metodologas como "gil" -un
trmino con una dcada de uso en prcticas de fabricacin flexibles.
Los participantes escribieron el "Manifiesto por la Agile Desarrollo de Software
"(www.agilemanifesto.org), que describe los cuatro valores comparativos
subyacentes la posicin gil:
Individuos e interacciones sobre procesos y herramientas,
El software trabaja sobre una amplia documentacin,
Colaboracin con el cliente a travs de la negociacin del contrato, y
responder a cambiar con el seguimiento de un plan.

Estos cuatro valores comparativos reconocen la importancia de los elementos

de la derecha de cada comparacin, pero afirmar el predominio de los de la
izquierda.

Emprica frente a procesos definidos

Otro punto de coincidencia para todos mtodos giles es el reconocimiento de
software desarrollo como emprico (o no lineal) proceso. En ingeniera, los
procesos se clasifican proceso cado como se definen o empirical. Un define es
uno que se puede iniciar y se deja correr a la terminacin, produciendo los
mismos resultados cada tiempo. Montaje de un automvil es tal un proceso.
Los ingenieros pueden disear un proceso para montar el coche y especificar
una asamblea orden y acciones por parte de la lnea de montaje trabajadores,
mquinas y robots. En trminos generales, si el proceso de fabricacin se
ajusta a estos predefinidos pasos, se producir un coche de alta calidad.
Desarrollo de software no se puede considerar un proceso definido porque se
produce demasiado cambio durante el tiempo que el equipo est desarrollando
la producto. Es muy poco probable que cualquier conjunto de predeterminados
pasos multados conducirn a un resultado predecible deseable porque los
requisitos cambian, la tecnologa cambios, se agregan y quitan el equipo de
personas, etctera.
En un contexto de ingeniera, procesos empricos requieren corto "inspeccionary-adaptar" los ciclos y frecuente, retroalimentacin corto loops. Estos cortos
inspeccionar-y-adaptar los ciclos pueden ayudar a las metodologas giles
manejar mejor con- de la industria del software afligiendo y demandas
impredecibles.

Otros mtodos empricos que estn en sintona con Manifiesto gil tambin
puede considerarse gil.
Agilidad, aspirante a la agilidad, y varios competitiva contrapartes se han
convertido en temas candentes en las conferencias y revistas, incluyendo IEEE
Computer Society publications. Ahora hay dos libros y conferencias
internacionales anuales sobre el tema.
CONVERSACIONES EN CURSO
Como practicantes han ganado experiencia con el uso de mtodos giles, el
foco de sus conversaciones acerca de este enfoque para el desarrollo de
software ha cambiado.
Circunstancias adecuadas
En 2001, la conversacin en torno gil era: Qu es en realidad? Es viejo,
nuevo, una moda, loco, o qu?
Hemos encontrado que el desarrollo gil no es particularmente nuevo. Los
desarrolladores de software han sido espordicamente utilizando las tcnicas
por lo menos desde la dcada de 1960.
Lo que es nuevo, en todo caso, es la agrupacin de las tcnicas en un marco
terico y prctico y los fuertes, a veces vehemente, declaracin de su
importancia.
En 2001, se haban recogido muestras de proyectos suficientes para el caso de
que el desarrollo gil trabaja bajo "circunstancias adecuadas." Estas
circunstancias generalmente se pueden clasificar como sin seguridad crticos
proyectos con requisitos voltiles, construido por equipos colocated
relativamente pequeos y especializados.

Escalabilidad
En 2002, la conversacin gil se centr en dos preguntas: De qu manera nos
hacen escala ms all de stos "circunstancias adecuadas?" Se contradice la
agilidad Capacidad del Software Engineering Institute Modelo de Madurez e ISO
9000 normas?
Algunos proyectos de varios cientos de personas tienen succesfully.9 utilizado
el marco gil Sin embargo, durante 2002, los profesionales giles y otros
investigadores lleg a la conclusin de que el valor ajustado gil y practica
mejor traje equipos puestas de cerca de 50 personas o menos que tienen fcil
acceso a los expertos de los usuarios y de negocios y estn desarrollando
proyectos que no son crticas para la vida.
Aunque el conjunto de valores gil podra adoptarse (y puede ser adaptado) en
otras circunstancias, la condiciones de contorno para el comportamiento
verdaderamente gil parecen para fijar de manera justa.

Una lectura cerca pero liberal del CMM revela poco que impida equipos CMMinteresadas el uso de methods.10 gil Sin embargo, algunas comunes prcticas
de CMM estn en desacuerdo con la gil valor ajustado debido a su
dependencia de los procesos, planes, y la entrega de contrato original.
En general, la gente dispuesta a gastar el dinero en Certificacin CMM est
menos interesados en la gil propuesta de valor, mientras que aquellos que
necesitan agilidad para razones de negocios estn menos interesados en
conseguir CMM o la certificacin ISO 9000.

Adaptabilidad
En 2003, la conversacin ha cambiado de nuevo:
Podemos mezcla seleccionada prcticas giles con nuestro "regular"
prcticas? Cunto cambio es necesario al realizar la transicin hacia y usando
mtodos giles? Cmo pueden las prcticas giles mejorar la calidad de
nuestra productos?
Los grupos de desarrollo estn tratando de programacin en parejas sin otras
prcticas giles, prueba primero desarrollo sin programacin en parejas, y
corta ciclos de entrega sin programacin en parejas o de Exmenes primero el
desarrollo, y tratando de determinar cmo obtener cualquiera de estas
prcticas para trabajar con internacionalmente equipos distribuidos. Los
investigadores de todo el mundo se renen estas experiencias subconjunto
giles y el diseo y la puesta en escena experimentos adicionales a
empricamente evaluar la eficacia de prcticas aisladas o subconjuntos giles.
Vemos filosofas y prcticas giles dispersas en un rango ms amplio de
personas, proyectos y organizaciones.
Por ejemplo, muchos CMM y ISO 9000 organizaciones ahora piensan que la
adopcin parcial de prcticas giles, cuando se maneja con cuidado, podra
aumentar su eficiencia sin daar su certificaciones.

Hacer cambios
Como desarrollo gil se extiende desde principios del adoptantes a una
poblacin mayor de desarrolladores y gerentes de desarrollo, la cuestin del
cambio es a un primer plano.
El desarrollo gil lleva consigo la implicacin de cambiar los hbitos de trabajo.
Para aquellos que no tienen utilizan tcnicas giles, el cambio implica tratar y
seleccionar los apropiados. Para aquellos que ya utilizan algunas de las
tcnicas, el cambio implica ajustar y mejorar su uso sobre tiempo. Algunos
proporcin de la comunidad de desarrollo no tiene ningn inters en el cambio,
sin embargo, que podr imponer un lmite inevitable a la penetracin tcnicas
de giles.

El desarrollo gil puede afectar a la estructura de poder dentro de una

organizacin, ya que se extiende a la autoridad para tomar decisiones. Se
espera que los ejecutivos para hacer y tomar la responsabilidad para a nivel de
negocio decisiones, aplazando a los desarrolladores en tcnica temas como las
tcnicas y el tiempo de desarrollo estima. Los desarrolladores son entonces
responsables de estos temas.
Este enfoque toma de decisiones difiere de lo que vemos en muchas
organizaciones. En algunos, la programadores toman muchas decisiones
claves, incluyendo las relativas a los negocios, procesos y sistemas requisitos,
mientras que sus directivos, ya sea feliz o regaadientes ir adelante para el
paseo. En otras organizaciones, programadores han toma de decisiones
limitado autoridad, y se les trata como poco ms de los empleados de oficina.
En cualquier caso, el paso al desarrollo gil, con su reasignacin de autoridad
en la toma de decisiones y la rendicin de cuentas, puede causar
consternacin. Nosotros gerentes de encuentro que denuncian que consideran
desarrollo gil para ser una licencia para los desarrolladores hack, pero nos
encontramos tambin con desarrolladores que contienden que la agilidad no es
ms que una estratagema para que los administradores microgestin de su
trabajo. Apenas cmo manejar esto cambio de poder sigue siendo una cuestin
abierta.
Por ltimo, algunos cuestionan la capacidad de las prcticas giles para
mejorar la calidad del producto.

prcticas giles
estrs participacin temprana de los grupos de prueba y de la necesidad para
una rpida retroalimentacin, pero no dicen mucho acerca de la relacin entre
el desarrollo y los grupos de control de calidad. Integracin aseguramiento de
la calidad en los proyectos para mejorar la su agilidad requiere hacer cambios
en el relacin entre estos grupos e incluso en las prcticas de contratacin.

EN ESTA EDICIN
Los artculos de este nmero capturan algunos los resultados de las
conversaciones anteriores y establecer el escenario para los nuevos.
En su corta y colorido agilidad "a travs de Disciplina: Un Debate, "Kent Beck y
Barry Boehm sugerir que el desarrollo gil y un plan impulsado por existir en
diferentes nichos ecolgicos y que cada prosperarn o dominar en funcin de
la "corriente condiciones meteorolgicas. "En algn lugar entre el elefante, el
mono, el ratn, y el dinosaurio, su debate transmite el mensaje de que tanto
enfoques requieren disciplina para trabajar, aunque con algunos matices

diferentes de lo que la disciplina significa, y que cada uno trabaja bien en

especfico circunstancias.
Craig Larman y el artculo de Vic Basili, "iterativo y Desarrollo incremental: Una
breve historia " traza esta prctica gil piedra angular de nuevo a la 1950 e
incluso antes. Citan la NASA de 1957 Proyecto Mercurio, que utiliza
incrementos de medio da, y un informe de 1969 para la gestin de IBM que
reconoce "La inutilidad de la separacin de diseo, evaluacin, y
documentacin procesa en el software del sistema diseo. "Su artculo incluye
una cita de Gerald Weinberg, que escribe de una experiencia o menos en este
tiempo ", donde utiliza la tcnica era, en la medida de lo que pueda decir,
indistinguible de XP ".

Barry Boehm y Rich Turner examinan el gil frente al debate y ofrecer

recomendaciones del plan impulsado por sobre cmo y cundo mezclar los dos
enfoques. En "Uso de riesgo para el Equilibrio y Agile Mtodos de Plan-Driven,
"ponen de relieve tanto la terrenos y los riesgos asociados a cada hogar
enfoque. Describen cmo iban a elegir qu mtodo usar y en qu
circunstancias se mezclaran ellos, destacando su ideas con tres proyectos de
ejemplo que deben utilizar diferentes combinaciones de gil y un plan
impulsado por prcticas. Se caracterizan los proyectos que utilizan unos cinco
puntos diagrama radial que asla importante Caractersticas del proyecto que
impulsa esta decisin. El diagrama Tambin capta una parte de la capacidad de
la organizacin para llevar a cabo el cambio.
Boehm y Turner lista tres categoras de riesgo que pueden afectar a la eleccin
de la forma en gran medida a un sesgo proyectar hacia el lado gil o plan
impulsado por:
riesgos derivados de un enfoque gil: escalabilidad, la criticidad, la
simplicidad de diseo, churn del personal, y el personal de las habilidades;
riesgos derivados de un plan impulsado enfoque: nuevas necesidades,
constante cambiar, la necesidad de resultados rpidos, y las competencias del
personal; y
Riesgos ambientales generales: tecnologa incertidumbres, las diversas
partes interesadas, y
sistemas complejos.
En la enumeracin de estos riesgos, establecen un marco para examinar las
experiencias de los proyectos y caractersticas de los diferentes enfoques de
desarrollo, un marco repite en los otros tres artculos.
En "El desarrollo de proyectos complejos utilizando XP con Extensiones, "Martin
Lippert y sus coautores describen cmo se han ocupado de las circunstancias
encontrado en los proyectos que utilizan (sobre todo) Extreme Programacin.
Hay un eco de la BoehmTurner enumerar en este trabajo, a pesar de que los

autores llegado a su enfoque cclico para el desarrollo

independiente, basado en un proyecto especfico experiencias.

de

software

Los autores discuten cmo manejaron diversas y grupos de intereses en

conflicto que conducan un proyecto, la falta de pruebas en el lado del cliente
de la ecuacin, complejo sistemas y requisitos imprecisos, a largo plazo
planificacin, las dependencias entre nonprogramming tareas, y la necesidad
de definicin de requisitos en menos para fines de financiamiento. Es
refrescante que identificar las habilidades especiales de las personas en
puestos clave necesitar, incluyendo el gerente de producto, la autocritica, e
incluso el cliente. Sus experiencias proporcionan prcticas adicionales para los
desarrolladores giles a considerar el uso y demostrar los beneficios de la
mezcla los enfoques tradicionales seleccionados con estndar prcticas giles
y derivados situacional.
En "La introduccin de un proceso gil a una organizacin" ,Mike Cohn y Doris
Ford describen su experiencias con la introduccin de Scrum en siete
organizaciones durante un perodo de cuatro aos y reflexionar sobre lo que
han aprendido a lo largo del camino. Ellos describen viendo algunos
desarrolladores agregar documentos formales de nuevo en sus prcticastrabajo "que invariablemente encontramos programadores que disfrutan de la
produccin de artefactos NONCODE mucho ms de lo que estn dispuestos a
admitir ", y recordar otros desarrolladores demasiado entusiastas que ven gil
desarrollo en el sentido de que no deben pensar en el futuro.
A la luz de la Beck-Boehm debatir en torno a la disciplina, Cohn y Ford ofrecen
una interesante descripcin: "Ellos no tienen la disciplina XP requiere y, aunque
las apariencias frente a XP, que eran en realidadno hacer nada ms que la
piratera ". Estos autores discuten sus experiencias con algunos BoehmTurner
cuestiones como el desarrollo distribuido y describir otros problemas que
aparecieron en sus proyectos, tales como encontrar resistencia desarrollador
aligerar el proceso, el trabajo con la humana los recursos del departamento,
utilizando probadores, y la gestin de el proyecto y sus interfaces con otros
grupos.
Finalmente, en "Mtodos giles Migracin a Prctica del Desarrollo
estandarizada, "Mark Lycett y sus coautores abordan una nueva arruga a la
introduccin procesos giles en una organizacin: trabajo en una ISO 9000 o
entorno CMMI o uno en el que una gran corporacin ha ordenado que todos los
los proyectos debern utilizar un proceso comn. Hacen despejar la necesidad
de una empresa para establecer la calidad de producto, proceso, servicio y al
mismo tiempo dejar diferente proyectos de trabajo en las diversas formas que
se adapten ellos mejor.
Al informar sobre sus experiencias con una gran empresa, estos autores
describen su especial enfoque para la adaptacin del proceso especfico del
proyecto: un conjunto del proceso de "patrones" que se pueden asignar a la
Marco CMMI. Por ISO 9000, adoptaron una basado en modelo de la estructura
"suplantar repetibilidad con consistencia, mientras que proporciona la pista de

auditora necesaria para la evaluacin. "Para una buena projectspecific

resultados, se revisan el uso de los patrones despus de cada iteracin y
encontr que "hacer el proceso de toma visible es extremadamente valiosa
porque obliga a la Administracin para determinar activamente si una actividad
o artefacto es necesario y suficiente ". Hacindose eco y la ampliacin de la
primera Agile Valor Manifiesto, que describen su marco como "Sugiriendo
tcnicas adecuadas para la colaboracin, la interaccin y la comunicacin. "
Lycett y sus coautores ofrecen su propia resolucin del gil debate entre la
ingeniera: "Proceso Agile no vuela en la cara de la prctica de la ingeniera.
Si se utiliza aire pensativo, proporciona un claro mandato para realizar
prcticas de ingeniera magra y bien centrado ".
Es un placer presentar estos artculos en esta nmero especial. Capturan el
estado de la corriente conversacin, y esperamos que sirven de catalizador
para las futuras.