Agilidad - Disciplina - Caos

www.psl.com.
co
Agilidad, Disciplina o Caos
Reflexiones sobre el desarrollo de software

II Jornada Gerencia de proyectos
de software

Bogot, Marzo 25 de 2004
1
Reflexionar sobre algunas de las soluciones
que a estos problemas plantean los mtodos
denominados giles y las aproximaciones ms
formales al desarrollo de software
2
Preguntas y respuestas
3
Agilidad, disciplina o caos
Agenda
Plantear algunos de los problemas que se
presentan en el desarrollo de software.
Introducir los conceptos de disciplina y
agilidad
1
2
3
Agenda
agilidad
Un productor de software le contesta a un potencial cliente que no
sabe cunto tiempo toma y cunto cuesta un proyecto de software
sobre el cual estn hablando?
Usted le responde a su compaa cunto va demorar el proyecto (y
hasta desarrolla un cronograma detallado)?
El productor de software se compromete en trminos de costo
y tiempo (y en su propuesta incluye un cronograma que deja
muy satisfecho al cliente)?
Que sucedera si
Usted le respondiera a su compaa que no tiene ni idea cunto va a
demorar un nuevo proyecto de software del cual usted es
responsable?
Que sucede cuando .
Que hara si
A usted, que considera que la documentacin es una prdida de
tiempo, un proveedor de software externo no le presentara un
diagrama de arquitectura de la aplicacin que usted le contrat, se
la entregara sin documentacin, etc.?
Usted, que es conciente de la importancia de la documentacin,
tiene que decidir entre salir a produccin un mes despus, o hacerlo
antes sacrificando la misma (Time to market)?
La burocracia de su compaa no permite elicitar los requerimientos
de un nuevo sistema con la celeridad que se requiere?
La informalidad o falta de mtodo no permite que el software sea
construido de tal manera que satisfaga los requerimientos del
cliente y usuarios finales (Yo entend eso , No me dijeron, Si le
dije)?
Que hara si
Despus de cuatro cronogramas el grupo de ingenieros sigue
incumpliendo? Los cambiara? Llamara a un asesor? Se tirara por
la ventana? Nada?
Luego de entregar a tiempo un proyecto con aproximaciones no
formales, el software parece un crispetero, es lento, se cae a toda
hora y no le gusta a los usuarios?
Si ya se le acab el presupuesto y sabe que an tiene meses
hombre de trabajo por delante?
Si los usuarios siguen cambiando los requerimientos a pesar de
mltiples reuniones, compromisos, conversaciones con la
presidencia, peleas, etc.?
Estas y otras cuestiones han estado siempre
en el centro de la discusin en cuanto a
Ingeniera de software se refiere

y han conducido a los metodologistas a asumir
posiciones extremas.

Incorrectamente, a juicio del autor, se plantea a
cuestin como si se tratara de una decisin entre
Disciplina y Agilidad.

Incorrectamente, a juicio del autor, se predica la
universalidad de uno y otro enfoque
Se oponen estos dos conceptos? Ser cierto
que algo gil no puede ser disciplinado y algo
disciplinado no puede ser gil?

Agilidad. Rapidez y buena
coordinacin
Disciplina. Apego a procedimientos
establecidos. Auto control.
D
i
s
c
i
p
l
i
n
a

Agilidad Baja
Baja
Alta
Alta
Burocrtica
Nueva organizacin
(Startup)
Gran organizacin
Jerrquica
No se oponen. Se complementan (*)
(*) Collins. Matriz de disciplina creativa.
La disciplina es la base de cualquier esfuerzo
exitoso. Los atletas entrenan, los msicos practican
y los ingenieros aplican procesos. Sin estos
fundamentos, puede darse el xito ocasional, pero la
consistencia profesional y el xito a largo plazo son
limitados.

Donde la disciplina arraiga y fortalece, la agilidad
libera e inventa. Le permite a los atletas hacer la
jugada inesperada, a los msicos improvisar y a
los ingenieros ajustarse a los cambios en tecnologa

Versin. Barry Boehm and Richard Turner. Balancing Agility and Discipline.
1
2
3
Agenda
agilidad
Las dos aproximaciones, aparentemente
antagnicas, son conocidas en la literatura
como .

Metodologas giles. Entre las mas conocidas se
encuentran XP, SCRUM, UP (RUP), etc. Algunos no
consideran RUP como gil, pues es una mezcla.
Metodologas guiadas por un plan. Algunos las
consideran como la aproximacin tradicional al desarrollo
de software.
Algunos relacionan las metodologas guiadas
por un plan con el desarrollo en cascada
tradicional porque .

Las Metodologas guiadas por un plan surgieron hace
algunos aos, cuando se intentaba producir software con una
aproximacin en cascada.

Los primeros intrpretes de CMM, por ejemplo, adaptaron el
modelo a ese ciclo de vida, influenciados por el tipo de
Ingeniera de Sistemas que requera, en aquel entonces, el DoD
de los EE.UU., y compaas como Siemens, Hitachi, IBM, etc.

Como se ver, las aproximaciones modernas reconocen una
mezcla de aproximaciones denominadas giles y
aproximaciones guiadas por un plan.

obedece a la mala
adaptacin de la
planeacin predictiva al
desarrollo de software

Salvo excepciones, el modelo en cascada
no funciona bien en el desarrollo de
software
El modelo en cascada
En este modelo, se aborda una secuencia
definitiva de eventos, tal cual se hace en la
planeacin predictiva
Requerimientos
Anlisis y diseo
Codificacin
Pruebas
Diseo detallado
Operaciones
Lo cual normalmente no funciona ..
Manufactura predecible Desarrollo de nuevo producto
Es posible completar las
especificaciones y luego construir el
producto de manera repetida
Raramente es posible crear desde el
comienzo especificaciones que no
cambien
Cerca al comienzo, se pueden hacer
estimaciones confiables de esfuerzo y
costo
Cerca al comienzo no es posible
estimar. La confiabilidad crece en la
medida que avanza el proyecto
Es posible identificar, definir,
programar y ordenar todas las
actividades en detalle
Cerca al comienzo no es posible
hacerlo pues se trata de un nuevo
producto (casi siempre)
La adaptacin a cambios
impredecibles no es la norma pues la
rata de cambios es baja
La adaptacin a los cambios es la
norma. La rata de cambios es elevada
Integracin en etapas finales y problemas tardos de diseo
Mucho re trabajo
Software que no satisface las necesidades de clientes y
usuarios
Y conduce a
Sobre costos, proyectos muy demorados en el tiempo, baja calidad.
En general, proyectos impredecibles.
Foco en documentos y reuniones formales de diseo (IWKIWISI).
Quiz por esta razn se habla que las aproximaciones basadas en
planes producen muchos documentos
Insatisfaccin generalizada de los interesados (Cliente,
usuarios, grupo de ingeniera, proveedor del software, etc.)
Etctera

Prdida de dinero (sobre costos, necesidad
del producto, etc.)
Cuestionamiento al grupo de ingeniera (interno
o externo)
Abordar el problema incorrecto

Hoy en da no triunfan las empresas mas poderosas
econmicamente, lo hacen las ms rpidas y ms
innovadoras

Lo que significa .
Y todos .
El desarrollo es cascada, que se le atribuye a Royce [1970], tuvo una
gran influencia, sobre todo a partir de las necesidades de la
ingeniera de sistemas, no la ingeniera de software (Royce
realmente pregon el desarrollo iterativo)
El desarrollo en cascada es fcil de explicar. El iterativo e
incremental es mas complejo
Por qu se persiste en un modelo que no
funciona?
Para cada problema complejo, existe una solucin simple,
ordenada e incorrecta (Mencken). Ejemplos: La tierra es plana, todo
gira alrededor de la tierra, la creacin del hombre, etc.
Puede dar la ilusin , en algunas personas, de un proceso
ordenado, predecible y medible
Por qu se persiste en un modelo que no
funciona?
Porque no se quiere hacer el esfuerzo para buscar otras formas de
hacerlo
Por presin de compradores, la cual a su vez proviene de los
CEO, CIO, etc. Cunto se demora, Cunto vale, etc.
Por la legislacin de compras de los gobiernos
Porque la Ingeniera de Software no es fcil, aunque no es
para seres especiales

Todas las aproximaciones giles
son un subconjunto de las
aproximaciones Iterativas

La respuesta a los problemas de la
aproximacin en cascada y basadas en
documentos son las aproximaciones
denominadas giles

XP (eXtreme Programming)
Scrum
UP (o su versin RUP)
ASD (Adaptive Software Development)
Crystal
Evo (como referencia)

Las aproximaciones iterativas mas
conocidas son

Una aproximacin para construir
software (o cualquier cosa), en la
cual el ciclo de vida se descompone
en varias iteraciones en secuencia.
Cada iteracin es un mini
proyecto autocontenido

El desarrollo Iterativo es

Liberar un sistema parcialmente
completo, probado, integrado y
estable.
Algunas iteraciones son internas,
otras se liberan a operaciones.

El objetivo de cada iteracin consiste en
IID no es nuevo
IBM public en 1972 documentos que contenan esta
aproximacin
Los japoneses utilizaron IID para el desarrollo de nuevos
productos en electrnica de consumo, vehculos, etc.
EVO (Evolutionary Project Management) data de los aos 60.
Alexander Proudfoot aplic a fines de los 40, lo que el
denomin el SIS (Short Interval Scheduling) en una compaa
de correo masivo en Chicago
Las nuevas aproximaciones estn basadas en ideas ya viejas
Iterativo e Incremental significa
Iteracin 1 Iteracin 2 Iteracin 3
Feedback
Feedback
Release 1
Iteracin 4 Iteracin 5 Iteracin 6
Feedback
Feedback
Release 2
La longitud de cada iteracin es de 1 a 6 semanas como mximo
La planeacin de iteraciones contiene elementos
diferentes a la aproximacin tradicional
Planeacin basada en el riesgo o en el cliente
El tiempo de cada iteracin es fijo, pase lo que pase (timeboxing)
No se aceptan cambios de interesados externos
No se hacen cronogramas en su forma tradicional
Se trabaja en varias disciplinas simultneamente aunque el
nfasis cambia (requerimientos, anlisis, diseo, codificacin,
testing, etc.)
El cono de incertidumbre se va estrechando a
medida que avanza el proyecto
Estimados y cronogramas
prematuramente definidos
Perodo realista
para estimados
X
4X
0.1 X
I 1 I 2
Aunque el IID es la base, las aproximaciones
giles adoptan otra serie de paradigmas
Manifiesto gil

Individuos y sus interacciones sobre procesos y
herramientas
Software sobre documentacin comprensiva
Colaboracin del cliente sobre contratos
Respuesta a los cambios sobre el seguimiento de
un plan

Enfatiza mas sobre las posturas a la izquierda de sobre
Y aproximaciones metodolgicas diferentes ..
Conocimiento tcito basado en
interaccin muy fuerte del grupo
Poca o ninguna documentacin
Customer On site Desarrolladores y clientes trabajan en
el mismo sitio
Pair Programming Si la revisin de cdigo es buena la
llevamos al extremo
Test first programming Si el testing es bueno lo llevamos al
extremo
Diseo simple Disee para la batalla no para la
guerra (YAGNI)
Refactoring Cuando encuentre algo que sea
necesario cambiar, cmbielo
Y aproximaciones metodolgicas diferentes ..
Propiedad colectiva del cdigo Cualquiera puede cambiarlo
Grupo auto controlado Los procesos no estn definidos
Planeacin de release e Iteracin
basado en la seleccin del cliente
Paradjicamente, XP y SCRUM son quiz las aproximaciones mas
disciplinadas que existen, y requieren de mucho talento en los integrantes
del grupo.

Se resquebrajan fcilmente sin disciplina y talento ...
y pueden presentar problemas serios
El conocimiento tcito promueve la agilidad, pero presenta
serios problemas de escalamiento cuando el grupo crece o no
tiene el talento
Se requieren personas muy talentosas
El diseo simple (YAGNI) puede llegar a ser muy riesgoso y
costoso, en proyectos de alguna importancia donde pueda
preverse el cambio.
El Peer Review ha mostrado mejores resultados que el Pair
Programming
La carencia de procesos definidos puede llevar al caos. Es
muy disciplinado y controlado el desarrollo (Chaordic).
y puede presentar problemas serios
Es til en grupos pequeos, requerimientos cambiantes o
desconocidos
Vamos a cambiar otra vez el plan?
Yo no le puedo dar mantenimiento a eso, no existe documentacin
de ninguna naturaleza
Balance entre adaptacin y optimizacin (*)
Liviana Pesada
Bajo
Alto
H
a
b
i
l
i
d
a
d
e
s
,

c
o
n
o
c
i
m
i
e
n
t
o

Procesos, documentacin
(*) Tomado de Cockburn y Highsmith
La solucin ha consistido en introducir elementos
basados en el plan
Mejor definicin de milestones para evitar acabar sin acabar
Planes que abarquen la definicin y prueba de arquitectura
Mejor elicitacin de requerimientos, cuando es posible
Utilizacin de patrones de diseo y soluciones de arquitectura en
lugar de YAGNI
Procesos definidos pero no mecnicos. Mtodos formales de
monitoreo (CEP)
Crystal y RUP son buenos ejemplos de aproximaciones mixtas
Seleccione su aproximacin basado en el riesgo

No se vuelva un defensor a ultranza de una u otra
aproximacin. Al fin y al cabo usted lo que requiere
es:

Producir software de buena calidad, que cumpla
los requerimientos de su cliente
Estar en capacidad de mantenerlo y evolucionarlo
No ser persona dependiente

No insista en lo que no funciona, eso solo lo
conducir al caos

1
2
3
Agenda
agilidad
En Dios confiamos, todos los dems
traigan datos

Deming, a propsito del CEP


Agilidad - Disciplina - Caos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Agilidad - Disciplina - Caos

Загружено:

Авторское право:

Доступные форматы

www.psl.com.

Вам также может понравиться