Métodos Agiles: Productividad vs Actualización

A Study of Non-linearity in the Statistical Convertibility of Function Points into COSMIC

Function PointsMétodos Agiles: Productividad vs Actualización

Gabriela RobioloFacultad de Ingeniería

Universidad AustralBuenos Aires, Argentina

Motivación

Una nueva forma de trabajo que pareciera satisface las necesidades de la industria del software.

Promete importantes soluciones a problemas recurrentes detectados en los procesos de desarrollo.

¿Son los métodos ágiles un ambiente de mayor productividad o simplemente una evolución de los métodos tradicionales?

19/04/23Dra. Gabriela Robiolo 2

http://www.google.com/imgres?imgurl=http://3.bp.blogspot.com/_K-_S4fE0g9o/TGLpAIcu8cI/AAAAAAAAAB4/FQZK2SWWK1w/s1600/desarrollo.jpg&imgrefurl=http://web2-alberto.blogspot.com/2010/08/ing-de-soft-ceprog.html&usg=__Som852R-yPkbJ1uf-YcprNtczCA=&h=300&w=400&sz=30&hl=es&start=2&zoom=1&tbnid=mZN6WGKNo5Qj0M:&tbnh=93&tbnw=124&prev=/images%3Fq%3Dm%25C3%25A9todos%2Bde%2Bdesarrollo%2Bsoftware%26hl%3Des%26safe%3Dactive%26gbv%3D2%26tbs%3Disch:1&itbs=1

Un poco de Historia


Aspecto Tradicionales Agiles

Ideas claves Especificación CompletaPredeciblePlanificación intensiva

Código de alta calidad Grupos pequeñosMejora continua del diseño Testing permanenteRápido feed back Adaptación al cambio

Conducción Jefe identificado y control predefinido

Liderazgo y colaboración

Comunicación Formal Informal

Modelo de desarrollo Cascada o espiral Evolutivo, incremental

Organización Burocrática - Grande –Jerárquica

Participativa – Pequeña y mediana – auto_organizados -plana

Control de calidad Planificado – Testing tardío

Control continuo

Métodos Tradicionales vs Agiles


Métodos Agiles


Métodos Agiles

19/04/23Dra. Gabriela Robiolo

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6

Métodos Agiles


El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

El software funcionando es la medida principal de progreso.

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

A intervalos regulares el equipo reflexiona sobrecómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

7



Métodos Tradicionales

Métodos AgilesUP

8

http://www.google.com/imgres?imgurl=http://www.uhu.es/cine.educacion/didactica/0imagenesdidactica/0042direcciongrupo.gif&imgrefurl=http://www.uhu.es/cine.educacion/didactica/0042tecnicasgrupos.htm&usg=__Uw7qqSOqSipe80-iWCHIHQbXEnY=&h=325&w=333&sz=31&hl=es&start=12&zoom=1&tbnid=_6wC9sVCoxuaAM:&tbnh=116&tbnw=119&prev=/images%3Fq%3Dgrupo%2Btrabajo%26hl%3Des%26safe%3Dactive%26gbv%3D2%26tbs%3Disch:1&itbs=1

http://www.google.com/imgres?imgurl=http://www.csd.com.es/boletin/img/grupo_csd.gif&imgrefurl=http://www.csd.com.es/boletin/visualizar_boletin_csd.aspx%3Fid_boletin%3D00000000000000000237&usg=__qp8Rcb9fdADah7aJP5b4Oigu8Pk=&h=90&w=100&sz=6&hl=es&start=176&zoom=1&tbnid=GGCbntMjnKDNfM:&tbnh=74&tbnw=82&prev=/images%3Fq%3Dm%25C3%25A9todos%2Bagiles%26start%3D160%26hl%3Des%26safe%3Dactive%26sa%3DN%26gbv%3D2%26tbs%3Disch:1&itbs=1

Evidencias empíricas XP [2]

• Difícil de ser adoptado en organizaciones complejas

• Proyectos pequeños

• Funciona

• Diferentes ambientes

• Clientes– Feed-back y respuesta al

cambio

– On site: no es sostenible por un tiempo prolongado

• Grupos experimentados

• Perfiles con facilidad de comunicación interpersonal

• Programación de a pares (opiniones contradictorias)

• Profesionales más satisfechos

• Estudiantes – Entrenamiento para trabajo

futuro

– Dificultad para el testing


Evidencias empíricas - Productividad

Apple, una experiencia: la inadecuada utilización de las prácticas ágiles podría ser contraproducente [5]

Un proceso ágil (en un contexto académico) no obtuvo un mejor rendimiento de la inversión (ROI) que un proceso tradicional (o conducido por planificación) [6]


XP [2]

10

Evidencias empíricas Scrum [3]

Experiencia• Correlación entre el

nivel de adopción del atributo y el éxito del proyecto (medido desde la perspectiva del ingeniero de software)

• Ingenieros de Software (Scrum user group), Recife, PE (Brazil).

Atributo• Entrega regular del software

• Entrega temprana de las características más importantes

• Test de Integración correcto

• Miembros del grupo con alta experiencia

• Aplicación de prácticas de administración de requerimientos de agile

• Aplicación de prácticas de administración de la configuración de agile

• Grupo coherente y auto organizado

• Buena relación con el cliente



Experiencia• Identificación

de problemas en un mega-proyecto en ámbito político.

• 11 Grupos Scrum de diferentes sub-contratistas

• Entrevistados 13 participantes

Problemas• Restricciones en la colaboración debido a incompleta

explicitación contractual de responsabilidades.

• Baja prioridad de cualidades arquitectónicas y técnicas

• Conflictos entre control organizacional y flexibilidad

• Demorada y volátil definición de requerimientos

• Falta de una visión compartida del producto final.

• Limitada difusión de los conocimientos funcionales

• Dependencias excesiva entre las partes del programa.

• Sobrecarga del personal clave.

• Dificultades para mantener el buen funcionamiento de entornos técnicos.

• Dificultades en la coordinación de las pruebas y la implementación con las partes externas.



Caso de estudio

• 150 empleados, distribuidos en distintos grupos

• ¿La aplicación de Scrum mejora la calidad del software, en términos de cantidad de defectos?


RUP versus Scrum - UA

Motivos de la selección

– Ambos son usados en el ámbito de la industria del software

– Es posible hacer de RUP una metodología ágil




Métodos AgilesUP

15

http://www.google.com/imgres?imgurl=http://www.csd.com.es/boletin/img/grupo_csd.gif&imgrefurl=http://www.csd.com.es/boletin/visualizar_boletin_csd.aspx%3Fid_boletin%3D00000000000000000237&usg=__qp8Rcb9fdADah7aJP5b4Oigu8Pk=&h=90&w=100&sz=6&hl=es&start=176&zoom=1&tbnid=GGCbntMjnKDNfM:&tbnh=74&tbnw=82&prev=/images%3Fq%3Dm%25C3%25A9todos%2Bagiles%26start%3D160%26hl%3Des%26safe%3Dactive%26sa%3DN%26gbv%3D2%26tbs%3Disch:1&itbs=1

http://www.google.com/imgres?imgurl=http://www.javidominguez.com/wp-content/uploads/2010/05/grupo-trabajo.jpg&imgrefurl=http://www.javidominguez.com/%3Fcat%3D8&usg=__FVo4aTPkQLywlACc-UB1dhAYIbs=&h=683&w=1024&sz=176&hl=es&start=4&zoom=1&tbnid=Q9eHh4ak1cuWPM:&tbnh=100&tbnw=150&prev=/images%3Fq%3Dgrupo%2Btrabajo%26hl%3Des%26safe%3Dactive%26gbv%3D2%26tbs%3Disch:1&itbs=1

UP vs Agile


Aspecto UP Métodos AgilesCliente Define y aprueba los

Requerimientos. Valida el sistema.

Es parte del equipo, define prioridades

Fuerza del grupo de trabajo

En el proceso En las personas

Arquitectura Centrado en la Arquitectura Da importancia al códigoRequerimientos Casos de Uso De alguna forma. Lo más

característico: User StoriesDocumentación Consiste en una selección

adecuada de entregables Esta en el código

Testing Es una de las disciplinas Esencial el testing automatizado. Completa la deficinión de los requerimientos

Administración de Proyectos

Es una de las disciplinas Se le da un peso importante, llegando a marcar un estilo propio

Tamaño de Proyectos

Pequeños – medianos - grandes

Chicos

Cantidad de personas por team

No determinado Tendiendo a 10 personas

[1] Traducción del término artifacts

16

RUP versus Scrum


RUP vs Scrum

Preguntas de investigación:– Tamaño funcional: ¿Scrum > RUP ?– Diseño: ¿RUP es mejor que Scrum ?– Comprensión: ¿ RUP > Scrum ?– ¿Existen diferencias significativas en la

implementación de la arquitectura?


Definición del experimento

Contexto

– Taller de diseño de 4to año de Ingeniería en Informática

– 3 horas semanales

– Los alumnos desarrollan un producto de software

– Se dividió la clase en 2 grupos: RUP y Scrum equilibrando los grupos en base a:• Rendimiento académico

• Experiencia laboral

• Carga académica

– Ambos grupos desarrollaron un juego de estrategia por turnos partiendo de una misma definición de requerimientos



19/04/23 Dra. Gabriela Robiolo

22/20


Atributos estudiados– Tamaño funcional– Calidad de diseño– Grado de comprensión del diseño– Características de implementación de la

arquitectura– Diseño externo– Calidad de programación



Variables controladas–Capacidad del grupo de desarrollo– Ambiente de desarrollo– Tiempo–Nivel de capacitación en el

dominio–Complejidad del producto


Resultados - Tamaño funcional


Producto Medida [T]P1 8P2 10P3 23P4 6P5 51P6 7P7 38

RUPRUP

Agile

Media RUP = 7DesvS RUP = 1

Media A= 30,50

DesvS A= 17,82

Resultados - Calidad de diseño


Producto Cantidad de Clases afectadas por los cambios

P1 8P2 17P3 9P4 9P5 9

P6 10P7 10

RUPRUP

Agile

Media RUP = 9DesvS RUP = 1

Media A= 11,25DesvS A= 3,86

Resultados Grado de comprensión del diseño

o


RUP

RUP

Agile

Grupo Respuesta clara confusa incorrecta

P1 35 4 6P2 28 19 13P3 39 1 0P4 12 5 0P5 14 5 0P6 18 2 0P7 18 2 0

Media RUP 21,67 3,67 2,00

DesvS RUP 11,93 1,53 3,46Media A 24,75 6,75 3,25

DesvS A 11,18 8,34 6,50

Resultados Grado de comprensión del diseño

o


RUPTeam Motivation /

Students’ Commitment

Motivation /

Leader’s Commitment

Leader’s experience

P1 High High MediumP2 Medium High MediumP3 High High HighP4 Medium (*) Medium MediumP5 High High HighP6 Medium (*) High HighP7 High High High

(*) No preferencia por RUP

Requerimientos

Nro. Function Points

Transacciones Objetos de Entidad

Caminos

UseCase 14 98 26 10 52

UserStory 10 68 12 8 8

Importancia del testing y la participación del cliente


Conclusiones de la comparación

RUP– Menos funcionalidad implementada– No hay evidencia de un mejor diseño– Un resultado más acotado y predecible

Scrum– Mayor funcionalidad implementada – Mayor desviación estándar en la productividad– Empezó a producir código funcional en menor tiempo– Mayor dispersión en la comprensión global de la solución

implementada (depende de las personas)– Sensible a la motivación y liderazgo

No se puede afirmar taxativamente que un método sea mejor que otroLa componente humana tiene un gran impacto en los métodos ágiles 19/04/23Dra. Gabriela Robiolo 30

Conclusiones

Pocas evidencias empíricasNo hay evidencia de una mayor:– productividad– calidad

Profesionales más satisfechosEs una natural evolución que captura características atrayentes para las empresas y jóvenes desarrolladores

Los métodos ágiles son una tendencia


Agilidad e informalidad responden a parámetros de conducta de los jóvenes

[email protected]


Métodos Agiles: Productividad vs Actualización

Documents

Transcript of Métodos Agiles: Productividad vs Actualización