desafíos en las organizaciones que desarrollan software

Desafíos en la gestión de las organizaciones

de software

Santa Fe, 7 de mayo de 2014

Alvaro Ruiz de Mendarozqueta

Desafíos en la gestión de las organizaciones de software

LIDICALSO

Laboratorio de Investigación y Desarrollo en Ingeniería y Calidad de Software

LIDICALSO http://www.institucional.frc.utn.edu.ar/sistemas/lidicalso/

Departamento de Ing. en Sistemas de Información UTN FRC

Hoy el software está en todos

lados

¿Software en un BMW?

2006

Auto autónomo

2014

Fuente: Revista IEEE Spectrum (página web)

2014

Pierna biónica

Mano biónica

SARA

SAC-D Aquarius

La industria creció mucho desde el

año 2000

16

El regreso

Empleo, ventas, exportaciones

17

Egresados

Empleo

Egresados

Ventas/Exp.

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015 ?

19

Ciencias de la Computación FCEyN - UBA

67 75 61

46

19

11

0

10

20

30

40

50

60

70

80

60s 70s 80s 90s 00 Actual

Porcentaje de egresadas

Fuente:

63 9

15

13

Costos

RH Directos

RH Indirectos

Infraestructura

Otros

72 % RH Costos

En Santa Fe

Encuesta 2009 a MIPyME de SSI del Observatorio PyME Regional Provincia de Santa Fe

89 % con instrucción universitaria o terciaria

Personal

23

Insuficientes recursos humanos o falta de capacitación

Encuesta 2009 a MIPyME de SSI del Observatorio PyME Regional Provincia de Santa Fe

18,4

12,2

28,6

40,8

Desarrollo de Sw

No tiene dificultad

Dif baja

Dif media

Dif alta

Encuesta 2009 a MIPyME de SSI del Observatorio PyME Regional Provincia de Santa Fe

Dificultad para contratar personal

Algunas ventajas de la región en la

que estamos

Alto PBI

Universidades

Personas formadas

Time zone con USA y Latam

MERCOSUR

Ley de Software 2014

Polos tecnológicos

Emprendedorismo

Ley de Software influyó en el uso de modelos de

calidad

En UTN FRC hicimos un proyecto con

modelos de calidad

Evaluaciones en período 2003-2007

40 evaluaciones

13 empresas

CMM, CMMI, ISO

Normalización de datos

Fuente: Lidicalso UTN FRC

CMMI 5

Fuente: Lidicalso UTN FRC

Observaciones ¿CMMI se usa menos?

¿se dejó de usar?

Foco en procesos

Hay problemas de calidad

La industria se expande

Observaciones…

Poco uso de herramientas

Procesos descritos en documentos

Poca integración entre herramientas

Datos actualizados de CMMI e ISO en

Argentina

113 respuestas

CMMI DEV 1.3 Año Cantidad Porcentaje 2011 5 0,8 % 2012 9 1,5 % 2013 9 1,5 % CMMI DEV 12 Año Cantidad Porcentaje 2011 8 1.3 % Porcentaje considerando 600 empresas

Cómo se hizo la mejora de procesos

Inicio

Establecer objetivos y necesidades de mejora

Evaluar comparando con un

modelo y planificar las mejoras

Qué se debería hacer

Inicio

Establecer nivel de CMMI deseado

Empezar por nivel 2 en orden y

seguir una receta

Qué se hace

Foco

1 2

3

Orden de implementación

No hay dos organizaciones

exactamente iguales

No hay dos organizaciones

totalmente diferentes

Gerald Weinberg

Problemas Interpretar a los modelos de una única manera

Repetir recetas sin entender el contexto

Repetir recetas sin entender al equipo de trabajo

Problemas No asignar recursos a mejora

“Están ocupados trabajando…”

No planificar

El área de calidad no hace lo que recomienda…

Personal de calidad sin experiencia

Problemas

Es difícil ver mejoras concretas en el corto plazo

Riesgos SQA no es lo único que se hace

Calidad es lo que hacen los de calidad

Falta de integración de actividades

Poca planificación

Que la mejora no sea continua

Procesos Toda construcción de software sigue un proceso:

Formales

Informales

Muchos procesos están tan mal hechos como el software

Horror de proceso CMMI, PP

SG 3 Commitments to the project plan are established and maintained.

SP 3.3 Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.

Planilla con firma de cada uno de los miembros del equipo (pocos participaron de la confección del plan)

Más horror… Procesos con 15 roles para una organización cuyo promedio es de 4 personas por proyecto

Percepción de la mejora de procesos

Al mismo tiempo se comenzaron a usar los métodos ágiles

Cambio de paradigma

Paradigma Modelo Mental

¡Cuidado con el cerdo!

Paradigma ágil

Basado en el

plan

Fijo Requerimientos Recursos Calendario

Estimado Funcionalidad Recursos Calendario

Basado en el

valor

agregado

Tradicional Ágil

Tradicional

Ágil

El desarrollo de software

es, esencialmente, un proceso

de aprendizaje

Mary & Tom Poppendieck

Lean Software Development

Manifiesto por el desarrollo Ágil de software

http://agilemanifesto.org/

Estamos descubriendo formas mejores de

desarrollar software tanto por nuestra propia

experiencia como ayudando a terceros.

A través de este trabajo hemos aprendido a

valorar:

A B C

Individuos e interacciones

sobre procesos y herramientas

Manifiesto

Valoramos más http://agilemanifesto.org/

Software funcionando sobre documentación extensiva

Manifiesto

Valoramos más http://agilemanifesto.org/

Colaboración con el cliente sobre negociación contractual

Manifiesto

Valoramos más http://agilemanifesto.org/

Respuesta ante el cambio

sobre seguir un plan

Manifiesto

Valoramos más http://agilemanifesto.org/

principio #1

Satisfacer al cliente a través de

entregas tempranas y continuas

de software que provea valor

Manifiesto ágil (‘01)

http://agilemanifesto.org/

principio #2

Aceptamos que los requisitos cambien, incluso en etapas

tardías del desarrollo

Los procesos ágiles aprovechan el cambio para proporcionar

ventaja competitiva al cliente.

Manifiesto ágil (‘01)

http://agilemanifesto.org/

principio #3

Entregamos software funcional frecuentemente, entre dos

semanas y dos meses,

con preferencia al período de tiempo más corto posible.

Manifiesto ágil (‘01)

http://agilemanifesto.org/

… de software que provea valor

despachador de pedidos

generador de valor

software que funciona

software que cubre una necesidad

enfoque predictivo

enfoque adaptativo

concepto

producto

plazo de entrega

c1

p1

c2

p2 pn

cn

plazos de entrega

Scrum

Requerimientos Diseño Construcción Prueba Producto

Funcionalidad

Diseño Codificación

Prueba

Producto

Funcionalidad

Diseño Codificación

Prueba

Producto

Funcionalidad

Diseño Codificación

Prueba

Producto

Martin Fowler

un buen proyecto ágil

tendrá que desarrollar

algo mejor que

lo planeado

originalmente

The New Methodology

Ventajas Agile Cambios de requerimientos son bienvenidos

Entregas rápidas

Feedback del cliente todo el tiempo

Software funcionando pronto

Testing temprano

Comparemos proyectos de

software con la mejora de procesos

Inicio

Establecer Fecha de certificación ISO 9001

Contratar consultor y seguir una

receta

Qué se hace

ISO 9001

Fecha de auditoría

Manual de Calidad

Procesos de la organización

Auditoría

Comité de Calidad

ISO 9001

Fecha de auditoría

Manual de Calidad

Procesos de la organización

Auditoría

Comité de calidad

¿Es ágil?

Inicio

Establecer nivel de CMMI deseado

Empezar por nivel 2 en orden y

seguir una receta

Qué se hace

1 2

3

Orden de implementación

CMMI L2

Fecha de appraisal

PAs

Procesos de la organización

Evaluación

Comité de calidad

¿Es ágil?

Mejora de Procesos

personas e interacción

software funcionando

colaboración con clientes

responder a los cambios

herramientas y procesos

documentación exhaustiva

negociación de contratos

seguir un plan

Parece que valoramos más

foco en los resultados ¿cuál es el foco?

Manifiesto ágil (‘01)

Habíamos dicho en nuestro proyecto en UTN

No es ágil

Tenemos proyectos ágiles y

organizaciones lentas

Proyecto “Diseño de

un sistema de gestión”

Lidicalso UTN FRC

¿café? ¿café?

Comparemos proyectos de

software con un plan de

entrenamiento

Si cree que la

capacitación es cara,

pruebe con la ignorancia

Derek Bok

Capacitación Presupuesto anual Calendario anual de cursos Revisión mensual Dictados Asistencia Costos Encuesta de satisfacción Evaluación anual de desempeño

¿Cómo podemos agilizar a la

capacitación?

Discusión

Desafío: cómo hacemos que la organización sea

más ágil

Veamos cómo hacerlo en

capacitación

Un enfoque ágil para entrenamiento

Caso

Planificación de redes de comunicación

Ubicación de antenas y nodos

Uso de GIS

Kanban

TDD Test Driven Developmet

Escribir un caso de prueba

Ver si falla

Escribir código que

lo cubra Ver si pasa

Refactor

Curso TDD Roadmap de producto

Funcionalidad hecha en TDD

Métricas:

cobertura, complejidad ciclomática, cantidad de defectos, etc.

Veamos cómo hacerlo en mejora

de procesos

Inicio

Establecer objetivos y necesidades de mejora

Evaluar comparando con un

modelo y planificar las mejoras con un backlog

Qué deberíamos hacer

Aplicar manifiesto y

principios ágiles

Extender resultados

de proyectos

a mejora continua

Qué deberíamos hacer

Basado en el

plan

Fijo Modelo de calidad Recursos Calendario

Estimado Mejora funcionando Recursos Calendario

Basado en el

valor

agregado

Tradicional Ágil

Compatible con el modelo

A B C

Individuos e interacciones

sobre procesos y herramientas

Valoramos más

Equipo Scrum para la mejora

Proceso de mejora

Software

funcionando sobre documentación extensiva

Valoramos más

Mejora implementada

Proceso modificado

Colaboración con el cliente sobre negociación contractual

Valoramos más

Empleados son los clientes

Despliegue de procesos

Respuesta ante el cambio

sobre seguir un plan

Valoramos más

Implementar mejora de alto

impacto Implementar los procesos

Apliquemos el principio #1 a la mejora continua

satisfacer al cliente a través de

entregas tempranas

y continuas de software que

provean valor

Manifiesto ágil (‘01)

Apliquemos el principio #1 a la mejora continua

satisfacer al cliente a través de

entregas tempranas

y continuas de mejoras que provean valor

Manifiesto ágil (‘01)

Un enfoque ágil para la mejora de procesos

Caso

Empresa de desarrollo de software con filosofía ágil

Objetivo 2014

Certificación ISO 9001:2008

Toda la organización

Aplicar Agile en toda la organización

Comité de calidad

PMO Quality champion

Scrum

El sistema de gestión de calidad es el producto

Todos los empleados son los clientes

Scrum Team Representa la mayoría de los roles de la organización

Define el esfuerzo disponible

Director es el PO

Puntos claves

Mapas Agile vs ISO

Conocimiento de Scrum

Prácticas de Ingeniería

Team members

Backlog

Mapa entre

Agile e ISO

Acciones

preventivas y

correctivas

Tablero Scrum Create Quality

Policy [5.3] [4.2.1] trello.com

Mapa entre ISO

y Scrum

QMS Product realization

7

One to four weeks

Daily Customer

Needs

Product Owner

Requirements

Team Product

Records

Reviwers

V&V

Product Backlog

Sprint Backlog

Scrum Master

A1

A2

A3 A4

A5

Architecture

Impediments

Sprint Review

Retrospective

UX

Customer

Sprint planning

7.1

7.2

7.2

7.2.3

8.2.1

8.2.1

7.3

7.3

7.2

7.2

7.1

7.3

Sprint

7.3.1

7.3.3

7.3.4/5/6

7.3 7.3

6.2

6.2

8.2.2

7.3.4

Un enfoque ágil para la mejora de procesos

Caso

Empresa de desarrollo de productos para grandes empresas

Objetivo 2014

Mejora de un producto y sus procesos

Consolidar prácticas ágiles

Automatización

Scrum

Equipo: multi empresa y multi rol

Cliente: técnico y gestión

Empresa: técnico y gestión

Consultor externo

Scrum master

PO: gerente del cliente

Backlog de mejoras priorizado

Implementación de herramientas

Capacitación

Visita a clientes y reuniones con usuarios finales

Puntos claves

Gestión de impedimentos

Team members

Balance: mejora vs. producción

Compromiso

Tablero Scrum Integrado al sistema de

gestión

User Story Desarrollo propio

¿Qué más podemos hacer?

Cambiar la mirada sobre las

organizaciones

[PMBOK]

Desarrollo Testing

Área de responsabilidad Clientes

Productos

Proyectos

Ingeniería

Personas

Planeamiento, educación, calidad, infraestructura, presupuesto

el enfoque predictivo limita

ciclos de aprendizaje

capacidad de adaptación

generación de valor

Funciones antes que organigramas

Ejemplo: Modelo EFQM

Pasos a seguir Para cada área o función clave

Determinar las sub funciones

Aplicar el manifiesto ágil

what why

Individuals and

interactions over

processes and tools

M#1

Tangible Results over comprehensi

ve documentati

on M#2

Customer collaboratio

n over contract

negotiation M#3

Responding to change

over following a

plan M#4

continues delivery

of valuable Results

P#1

Products

know the roadmap (strategy)

to align projects and resources

communicate roadmap often, face-to-face, and collect feedback

roadmap should be clear, making-sense for engineering and business

customer needs being covered by the roadmap should be clear for all parts

make sure changes and its reasons are properly introduced and communicated to all relevant actors

roadmap means available for the whole involved people

Organización

Algunas conclusiones

La mejora de procesos no parece ser efectiva con el enfoque usual Agile trajo un cambio de paradigma Sus principios aportan sentido común Pueden extrapolarse a otras actividades Mejora de procesos

Si hay una oportunidad para las empresas de software…

…necesitarán agilidad para aprovecharla

Desafíos +

Comunicaciones

Tradicional

Customer Analyst Designer Programmer Tester Comunicación

Ágil

Comunicación

Customer

Team member

Team member

Team member

Team member

principio #6

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.

Manifiesto ágil (‘01)

http://agilemanifesto.org/

conversación cara a cara

principio #6

Evaluaciones

Evaluación vs auditoría

Este trabajo es parte de un proyecto…

diseño de un sistema de gestión de una

operación de desarrollo de software, usando

métodos ágiles y

modelos de calidad

Laboratorio de Investigación y Desarrollo en Ingeniería y Calidad de Software

LIDICALSO http://www.institucional.frc.utn.edu.ar/sistemas/lidicalso/

Departamento de Ing. en Sistemas de Información UTN

Aplicar

principios ágiles

Extender

resultados de proyectos

a una organización

Qué aprendimos en los proyectos

entregas frecuentes flujo de trabajo

generación de valor expandir conocimiento

prácticas XP construcción de SW

principios Lean concepto - producto

proceso Scrum-Kanban gestión de proyectos

disciplina diseño de calidad automatización

típicamente propuesta

Marco de gestión

procesos

organigrama

conformidad

generación de valor

áreas de responsabilidad

visión / resultados

foco en

organización

mecanismo

Expertos Joel Barker

Gerald Weinberg

Martin Fowler

Mary &Tom Poppendieck

Alistair Cockburn

Scott Ambler

Colaboraciones Natalia Andriano Diego Rubio Miguel Insaurralde Mariano Zibecchi Gabriel Zurita Fabio Grigorjev Adrián Lucero Álvaro Loeschbor Daniel Céspedez Daza

¡Gracias! LIDICALSO UTN FRC

¡Gracias por venir!

http://www.slideshare.net/AlvaroRuizdeMendaroz

Filminas complementarias

principio #4

Los responsables de negocio y los desarrolladores

trabajamos juntos

de forma cotidiana durante todo el proyecto

Manifiesto ágil (‘01)

http://agilemanifesto.org/

principio #5

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.

Manifiesto ágil (‘01)

http://agilemanifesto.org/

principio #6

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.

Manifiesto ágil (‘01)

http://agilemanifesto.org/

principio #7

El software funcionando es la medida principal de

progreso.

Manifiesto ágil (‘01)

http://agilemanifesto.org/

principio #8

Los procesos ágiles promueven el desarrollo sostenible.

Los promotores, desarrolladores y usuarios

debemos ser capaces de mantener un ritmo constante

de forma indefinida.

Manifiesto ágil (‘01)

http://agilemanifesto.org/

principio #9

La atención continua a la excelencia técnica y al

buen diseño mejora la agilidad

Manifiesto ágil (‘01)

http://agilemanifesto.org/

principio #10

La simplicidad, o el arte de maximizar la cantidad de

trabajo no realizado, es esencial.

Manifiesto ágil (‘01)

http://agilemanifesto.org/

principio #11

Las mejores arquitecturas, requisitos y diseños emergen de

equipos auto organizados

Manifiesto ágil (‘01)

http://agilemanifesto.org/

principio #12

A intervalos regulares el equipo reflexiona sobre

cómo ser más efectivo para a continuación ajustar y

perfeccionar su comportamiento en consecuencia.

Manifiesto ágil (‘01)

http://agilemanifesto.org/