Desafíos en la gestión

de las organizaciones
de software

Alvaro Ruiz de Mendarozqueta

Santa Fe, 7 de mayo de 2014

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
2014
Auto autónomo
 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
Empleo, ventas, exportaciones
El regreso

16
Egresados

17
 Ventas/Exp.

Empleo

Egresados
2015
2005 2007 2009 2011 2013 ?

2006 2008 2010 2012 2014

Ciencias de la Computación FCEyN - UBA
80

70

67 75
60 61
50

46
40

30

Porcentaje de egresadas 19
20

11
10

60s 70s 80s 90s 00 Actual

19
Costos Costos
72 % RH
13 RH Directos

15 RH Indirectos

Infraestructura
9 63
Otros

Fuente:
En Santa Fe
Personal
89 % con instrucción universitaria o terciaria

Encuesta 2009 a MIPyME de SSI del Observatorio

PyME Regional Provincia de Santa Fe
 Insuficientes recursos humanos o
falta de capacitación

Encuesta 2009 a MIPyME de SSI del Observatorio

23
PyME Regional Provincia de Santa Fe
Dificultad para contratar personal
Desarrollo de Sw

18,4
No tiene dificultad
40,8
Dif baja
12,2
Dif media
Dif alta
28,6

Encuesta 2009 a MIPyME de SSI del Observatorio

PyME Regional Provincia de Santa Fe
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
Qué se debería hacer
Inicio

Establecer objetivos y
necesidades de mejora

Evaluar comparando con un

modelo y planificar las mejoras
 Qué se hace
Inicio

Establecer nivel de CMMI

deseado

Empezar por nivel 2 en orden y

seguir una receta
Foco
Orden de
implementación

1
2
3
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
 Tradicional Ágil
Fijo Requerimientos Recursos Calendario

Basado en el
valor
agregado

Basado en el
plan

Estimado Recursos Calendario Funcionalidad

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
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:

http://agilemanifesto.org/
 Manifiesto

Individuos e interacciones
sobre procesos y herramientas

A B C

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

Software funcionando
sobre documentación extensiva

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

Colaboración con el cliente

sobre negociación contractual

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

Respuesta ante el cambio

sobre seguir un plan

Valoramos más
http://agilemanifesto.org/
 Manifiesto ágil (‘01)
principio #1
Satisfacer al cliente
a través de

entregas tempranas y continuas

de software que
provea valor

http://agilemanifesto.org/
 Manifiesto ágil (‘01)
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.
http://agilemanifesto.org/
 Manifiesto ágil (‘01)
principio #3
Entregamos software funcional
frecuentemente, entre dos
semanas y dos meses,

con preferencia al período de

tiempo más corto posible.

http://agilemanifesto.org/
 … de software que
provea valor

despachador de generador de
pedidos valor

software que software que cubre

funciona una necesidad
 enfoque enfoque
predictivo adaptativo

c2 cn
concepto c1

producto p1 p2 pn

plazo de
entrega
plazos de entrega
Scrum
 Producto
Requerimientos Diseño Construcción Prueba

Prueba Funcionalidad

Producto
Codificación Diseño

Prueba Funcionalidad

Producto
Codificación Diseño

Prueba Funcionalidad

Producto
Codificación Diseño
 un buen proyecto ágil
tendrá que desarrollar
algo mejor que
lo planeado
originalmente

Martin Fowler
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
 Qué se hace
Inicio

Establecer Fecha de
certificación ISO 9001

Contratar consultor y seguir una

receta
ISO Fecha de auditoría
9001
Manual de Calidad

Procesos de la organización

Auditoría

Comité de Calidad
ISO Fecha de auditoría
9001
Manual de Calidad

Procesos de la organización

Auditoría

Comité de calidad
¿Es ágil?
 Qué se hace
Inicio

Establecer nivel de CMMI

deseado

Empezar por nivel 2 en orden y

seguir una receta
Orden de
implementación

1
2
3
CMMI Fecha de appraisal
L2
PAs

Procesos de la organización

Evaluación

Comité de calidad
¿Es ágil?
Mejora de Procesos
Parece que valoramos más

personas e interacción herramientas y procesos

software funcionando documentación exhaustiva

colaboración con clientes negociación de contratos

responder a los cambios seguir un plan

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
 Discusión
¿Cómo podemos
agilizar a la
capacitació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

Refactor Ver si falla

Escribir
Ver si pasa código que
lo cubra
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
Qué deberíamos hacer
Inicio

Establecer objetivos y
necesidades de mejora

Evaluar comparando con un

modelo y planificar las mejoras
con un backlog
Qué deberíamos hacer
Aplicar Extender
manifiesto y resultados
principios de
ágiles proyectos

a mejora continua
 Tradicional Ágil
Fijo Modelo de calidad Recursos Calendario

Basado en el
valor
agregado

Basado en el
plan

Estimado Recursos Calendario Mejora funcionando

Compatible con el
modelo
Individuos e interacciones
sobre procesos y herramientas

Equipo
Proceso de
Scrum para
mejora
la mejora

A B C

Valoramos más
Software
funcionando
sobre documentación extensiva

Mejora Proceso
implementada modificado

Valoramos más
Colaboración con el cliente
sobre negociación contractual

Empleados son Despliegue de

procesos
los clientes

Valoramos más
Respuesta ante el cambio
sobre seguir un plan

Implementar
mejora de alto Implementar
impacto los procesos

Valoramos más
Manifiesto ágil (‘01)
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
 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
 Acciones
Mapa entre preventivas y
Agile e ISO correctivas
Tablero Scrum
Create Quality
trello.com Policy [5.3] [4.2.1]
Mapa entre ISO
y Scrum
QMS 7
Reviwers
7.3
Product realization 7.2
7.1
7.3.4/5/6
Sprint 8.2.2
planning 7.3.1 V&V 7.3.4
7.2 6.2
Product Sprint
Backlog Backlog
7.3
7.1 7.2 Scrum Master Sprint Review 7.2
Impediments 7.3.3

8.2.1
7.2.3
Customer Product
Daily Customer
Owner 7.3
Sprint
One to four weeks Product
Needs Team
6.2 Retrospective
Requirements
UX A3 A4

A2 A5

A1

7.3 Architecture 7.3

Records 8.2.1
 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
Testing Desarrollo

[PMBOK]
Área de responsabilidad
Clientes
Productos
Proyectos
Ingeniería
Personas
Planeamiento, educación, calidad,
infraestructura, presupuesto
 Funciones antes que
organigramas

el enfoque predictivo limita

ciclos de aprendizaje
capacidad de adaptación
generación de valor

Ejemplo: Modelo EFQM

Pasos a seguir
Para cada área o función clave
Determinar las sub funciones
Aplicar el manifiesto ágil
 Individuals Tangible
Customer Responding continues
and Results over
collaboratio to change delivery
interactions comprehensi
n over over of
what why over ve
contract following a valuable
processes documentati
negotiation plan Results
and tools on
M#3 M#4 P#1
M#1 M#2

Products
know the to align communicat roadmap customer make sure roadmap
roadmap projects and e roadmap should be needs being changes and means
(strategy) resources often, face- clear, covered by its reasons available
to-face, and making- the roadmap are properly for the
collect sense for should be introduced whole
feedback engineering clear for all and involved
and business parts communicat people
ed to all
relevant
actors
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

Comunicación Customer Analyst Designer Programmer Tester

 Ágil

Team
member

Team Team
member Customer member

Team
member
Comunicación
 Manifiesto ágil (‘01)
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.

http://agilemanifesto.org/
 conversación
principio #6
cara a cara
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 Extender
principios resultados
ágiles de proyectos

a una organización
Qué aprendimos en los proyectos
principios Lean generación de valor
concepto - producto expandir conocimiento

proceso Scrum-Kanban entregas frecuentes

gestión de proyectos flujo de trabajo

disciplina
prácticas XP diseño de calidad
construcción de SW
automatización
Marco de gestión
típicamente propuesta

foco en procesos generación de valor

organización organigrama áreas de responsabilidad
mecanismo conformidad visión / resultados
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
 Manifiesto ágil (‘01)
principio #4
Los responsables de negocio y los
desarrolladores
trabajamos juntos

de forma cotidiana durante todo

el proyecto

http://agilemanifesto.org/
 Manifiesto ágil (‘01)
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.
http://agilemanifesto.org/
 Manifiesto ágil (‘01)
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.

http://agilemanifesto.org/
 Manifiesto ágil (‘01)
principio #7

El software funcionando es la
medida principal de
progreso.

http://agilemanifesto.org/
 Manifiesto ágil (‘01)
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.

http://agilemanifesto.org/
 Manifiesto ágil (‘01)
principio #9

La atención continua a la excelencia

técnica y al
buen diseño mejora la agilidad

http://agilemanifesto.org/
 Manifiesto ágil (‘01)
principio #10

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

http://agilemanifesto.org/
 Manifiesto ágil (‘01)
principio #11

Las mejores arquitecturas,

requisitos y diseños emergen de
equipos auto organizados

http://agilemanifesto.org/
 Manifiesto ágil (‘01)
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.

http://agilemanifesto.org/