Las organizaciones que desarrollan software que han adoptado métodos ágiles, se encuentran con un fuerte cambio de paradigma que afecta a las otras funciones de la organización. ¿Qué podemos hacer para enfrentarlo?

1. Desafíos en la gestión
de las organizaciones
de software
Santa Fe, 7 de mayo de 2014
Alvaro Ruiz de Mendarozqueta

2. 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

3. Hoy el software
está en todos
lados

4. ¿Software en un BMW?
2006

5. Auto autónomo
2014

6. Fuente: Revista IEEE Spectrum (página web)
2014

8. Pierna
biónica

9. Mano
biónica

11. SARA

12. SAC-D
Aquarius

14. La industria creció
mucho desde el
año 2000

15. 16
El regreso
Empleo, ventas, exportaciones

16. 17
Egresados

17. Empleo
Egresados
Ventas/Exp.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
?

18. 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

19. Fuente:
639
15
13
Costos
RH Directos
RH Indirectos
Infraestructura
Otros
72 % RHCostos

20. En Santa Fe

21. Encuesta 2009 a MIPyME de SSI del Observatorio
PyME Regional Provincia de Santa Fe
89 % con instrucción universitaria o terciaria
Personal

22. 23
Insuficientes recursos humanos o
falta de capacitación
Encuesta 2009 a MIPyME de SSI del Observatorio
PyME Regional Provincia de Santa Fe

23. 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

24. Algunas ventajas
de la región en la
que estamos

25. Alto PBI

26. Universidades
Personas formadas
Time zone con USA y Latam
MERCOSUR
Ley de Software 2014
Polos tecnológicos
Emprendedorismo

27. Ley de Software
influyó en el uso
de modelos de
calidad

28. En UTN FRC hicimos
un proyecto con
modelos de calidad

29. Evaluaciones en período
2003-2007
40 evaluaciones
13 empresas
CMM, CMMI, ISO
Normalización de datos
Fuente: Lidicalso UTN FRC

30. CMMI 5

31. Fuente: Lidicalso UTN FRC

32. Observaciones
¿CMMI se usa menos?
¿se dejó de usar?
Foco en procesos
Hay problemas de calidad
La industria se expande

33. Observaciones…
Poco uso de herramientas
Procesos descritos en documentos
Poca integración entre
herramientas

34. Datos actualizados
de CMMI e ISO en
Argentina

35. 113 respuestas

36. 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

37. Cómo se hizo la
mejora de
procesos

38. Inicio
Establecer objetivos y
necesidades de mejora
Evaluar comparando con un
modelo y planificar las mejoras
Qué se debería hacer

39. Inicio
Establecer nivel de CMMI
deseado
Empezar por nivel 2 en orden y
seguir una receta
Qué se hace

40. Foco

41. 1
2
3
Orden de
implementación

42. No hay dos organizaciones
exactamente iguales
No hay dos organizaciones
totalmente diferentes
Gerald
Weinberg

43. Problemas
Interpretar a los modelos de una
única manera
Repetir recetas sin entender el
contexto
Repetir recetas sin entender al
equipo de trabajo

44. 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

45. Problemas
Es difícil ver mejoras
concretas en el corto
plazo

46. 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

47. Procesos
Toda construcción de software
sigue un proceso:
Formales
Informales
Muchos procesos están tan mal
hechos como el software

48. 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)

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

50. Percepción
de la
mejora de
procesos

51. Al mismo tiempo se
comenzaron a usar
los métodos ágiles
Cambio de
paradigma

52. Paradigma
Modelo Mental

53. ¡Cuidado
con el cerdo!

56. Paradigma ágil

57. Basado en el
plan
Fijo Requerimientos Recursos Calendario
Estimado FuncionalidadRecursos Calendario
Basado en el
valor
agregado
Tradicional Ágil

58. Tradicional

59. Ágil

60. El desarrollo de software
es, esencialmente, un proceso
de aprendizaje
Mary & Tom
Poppendieck
Lean Software
Development

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

62. A B C
Individuos e interacciones
sobre procesos y herramientas
Manifiesto
Valoramos más
http://agilemanifesto.org/

63. Software funcionando
sobre documentación extensiva
Manifiesto
Valoramos más
http://agilemanifesto.org/

64. Colaboración con el cliente
sobre negociación contractual
Manifiesto
Valoramos más
http://agilemanifesto.org/

65. Respuesta ante el cambio
sobre seguir un plan
Manifiesto
Valoramos más
http://agilemanifesto.org/

66. principio #1
Satisfacer al cliente
a través de
entregas tempranas y continuas
de software que
provea valor
Manifiesto ágil (‘01)
http://agilemanifesto.org/

67. 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/

68. 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/

69. … de software que
provea valor
despachador de
pedidos
generador de
valor
software que
funciona
software que cubre
una necesidad

70. enfoque
predictivo
enfoque
adaptativo
concepto
producto
plazo de
entrega
c1
p1
c2
p2 pn
cn
plazos de entrega

71. Scrum

72. Requerimientos Diseño Construcción Prueba
Producto
Funcionalidad
DiseñoCodificación
Prueba
Producto
Funcionalidad
DiseñoCodificación
Prueba
Producto
Funcionalidad
DiseñoCodificación
Prueba
Producto

73. Martin Fowler
un buen proyecto ágil
tendrá que desarrollar
algo mejor que
lo planeado
originalmente
The New
Methodology

74. Ventajas Agile
Cambios de requerimientos son
bienvenidos
Entregas rápidas
Feedback del cliente todo el tiempo
Software funcionando pronto
Testing temprano

75. Comparemos
proyectos de
software con la
mejora de procesos

76. Inicio
Establecer Fecha de
certificación ISO 9001
Contratar consultor y seguir una
receta
Qué se hace

77. ISO
9001
Fecha de auditoría
Manual de Calidad
Procesos de la organización
Auditoría
Comité de Calidad

78. ISO
9001
Fecha de auditoría
Manual de Calidad
Procesos de la organización
Auditoría
Comité de calidad

79. ¿Es ágil?

80. Inicio
Establecer nivel de CMMI
deseado
Empezar por nivel 2 en orden y
seguir una receta
Qué se hace

81. 1
2
3
Orden de
implementación

82. CMMI
L2
Fecha de appraisal
PAs
Procesos de la organización
Evaluación
Comité de calidad

83. ¿Es ágil?

84. 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)

85. Habíamos dicho en nuestro proyecto
en UTN

86. No es ágil

87. Tenemos proyectos ágiles y
organizaciones lentas
Proyecto “Diseño de
un sistema de gestión”
Lidicalso
UTN
FRC

88. ¿café?¿café?

89. Comparemos
proyectos de
software con un
plan de
entrenamiento

90. Si cree que la
capacitación es cara,
pruebe con la ignorancia
Derek Bok

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

92. ¿Cómo podemos
agilizar a la
capacitación?
Discusión

93. Desafío: cómo
hacemos que la
organización sea
más ágil

94. Veamos cómo
hacerlo en
capacitación

95. Un enfoque ágil para
entrenamiento
Caso

96. Planificación de redes de
comunicación
Ubicación de
antenas y nodos
Uso de GIS

97. Kanban

98. TDD Test Driven Developmet
Escribir un
caso de
prueba
Ver si falla
Escribir
código que
lo cubra
Ver si pasa
Refactor

99. Curso TDD
Roadmap de producto
Funcionalidad hecha en TDD
Métricas:
cobertura, complejidad ciclomática,
cantidad de defectos, etc.

100. Veamos cómo
hacerlo en mejora
de procesos

101. Inicio
Establecer objetivos y
necesidades de mejora
Evaluar comparando con un
modelo y planificar las mejoras
con un backlog
Qué deberíamos hacer

102. Aplicar
manifiesto y
principios
ágiles
Extender
resultados
de
proyectos
a mejora continua
Qué deberíamos hacer

103. Basado en el
plan
Fijo Modelo de calidad Recursos Calendario
Estimado Mejora funcionandoRecursos Calendario
Basado en el
valor
agregado
Tradicional Ágil
Compatible con el
modelo

104. A B C
Individuos e interacciones
sobre procesos y herramientas
Valoramos más
Equipo
Scrum para
la mejora
Proceso de
mejora

105. Software
funcionando
sobre documentación extensiva
Valoramos más
Mejora
implementada
Proceso
modificado

106. Colaboración con el cliente
sobre negociación contractual
Valoramos más
Empleados son
los clientes
Despliegue de
procesos

107. Respuesta ante el cambio
sobre seguir un plan
Valoramos más
Implementar
mejora de alto
impacto
Implementar
los procesos

108. 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)

109. 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)

110. Un enfoque ágil para
la mejora de procesos
Caso

111. 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

112. Comité de calidad
PMO Quality champion
Scrum
El sistema de gestión de calidad es
el producto
Todos los empleados son los
clientes

113. Scrum Team
Representa la mayoría de los roles de
la organización
Define el esfuerzo disponible
Director es el PO

114. Puntos claves
Mapas Agile vs ISO
Conocimiento de
Scrum
Prácticas de Ingeniería
Team members

115. Backlog

116. Mapa entre
Agile e ISO
Acciones
preventivas y
correctivas

117. Tablero Scrum
Create Quality
Policy [5.3] [4.2.1]trello.com

118. Mapa entre ISO
y Scrum

119. 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

120. Un enfoque ágil para
la mejora de procesos
Caso

121. Empresa de desarrollo de productos
para grandes empresas
Objetivo 2014
Mejora de un producto y sus
procesos
Consolidar prácticas ágiles
Automatización

122. 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

123. Backlog de mejoras priorizado
Implementación de herramientas
Capacitación
Visita a clientes y reuniones con
usuarios finales

124. Puntos claves
Gestión de
impedimentos
Team members
Balance: mejora vs.
producción
Compromiso

125. Tablero Scrum Integrado al
sistema de
gestión

126. User Story Desarrollo
propio

127. ¿Qué más
podemos hacer?

128. Cambiar la mirada
sobre las
organizaciones

129. [PMBOK]
DesarrolloTesting

130. Área de responsabilidad
Clientes
Productos
Proyectos
Ingeniería
Personas
Planeamiento, educación, calidad,
infraestructura, presupuesto

131. el enfoque predictivo limita
ciclos de aprendizaje
capacidad de adaptación
generación de valor
Funciones antes que
organigramas
Ejemplo: Modelo EFQM

132. Pasos a seguir
Para cada área o función clave
Determinar las sub funciones
Aplicar el manifiesto ágil

133. 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
communicat
e 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
communicat
ed to all
relevant
actors
roadmap
means
available
for the
whole
involved
people

134. Organización

135. Algunas
conclusiones

136. 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

137. Si hay una oportunidad
para las empresas de
software…
…necesitarán agilidad
para aprovecharla

138. Desafíos+

139. Comunicaciones

140. Tradicional
Customer Analyst Designer Programmer Tester
Comunicación

141. Ágil
Comunicación
Customer
Team
member
Team
member
Team
member
Team
member

142. 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/

143. conversación
cara a cara
principio #6

145. Evaluaciones

146. Evaluación vs auditoría

147. Este trabajo es
parte de un
proyecto…

148. 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

149. Aplicar
principios
ágiles
Extender
resultados
de proyectos
a una organización

150. 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

151. 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

152. Expertos
Joel Barker
Gerald Weinberg
Martin Fowler
Mary &Tom Poppendieck
Alistair Cockburn
Scott Ambler

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

154. ¡Gracias!
LIDICALSO
UTN
FRC

155. ¡Gracias por venir!
http://www.slideshare.net/AlvaroRuizdeMendaroz

156. Filminas
complementarias

157. principio #4
Los responsables de negocio y los
desarrolladores
trabajamos juntos
de forma cotidiana durante todo
el proyecto
Manifiesto ágil (‘01)
http://agilemanifesto.org/

158. 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/

159. 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/

160. principio #7
El software funcionando es la
medida principal de
progreso.
Manifiesto ágil (‘01)
http://agilemanifesto.org/

161. 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/

162. 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/

163. principio #10
La simplicidad, o el arte de
maximizar la cantidad de
trabajo no realizado, es esencial.
Manifiesto ágil (‘01)
http://agilemanifesto.org/

164. principio #11
Las mejores arquitecturas,
requisitos y diseños emergen de
equipos auto organizados
Manifiesto ágil (‘01)
http://agilemanifesto.org/

165. 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/