Date post: | 01-Jul-2015 |
Category: |
Software |
Upload: | alvaro-ruiz-de-mendarozqueta |
View: | 344 times |
Download: | 0 times |
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/