PDF de programación - Scrum Manager II - Para avanzar en scrum - Gestión de proyectos con Scrum Manager

Scrum Manager II

Para avanzar en scrum



v. 2.5





Scrum Manager II

Para avanzar en scrum



Versión. 2.5 – Abril 2014



Diseño de cubierta: Scrum Manager.
Imagen derivada de la original: The Albert Bridge 04 – Belfast de William Murphy (http://www.streetsofdublin.com/)



© 2014 Juan Palacio
© De la edición: Scrum Manager®
Información de derechos y licencia de uso:



http://www.safecreative.org/work/1404240651197


Scrum Manager® es marca registrada, propiedad de Iubaris Info 4 Media S.L.





Contenido

Contenido

Formación Scrum Manager

Servicios de formación y asesoría Scrum Manager

Mejora continua y control de calidad Scrum Manager

1.- Conocimiento en continua evolución

2.- Empresa como sistema

3.- Flexibilidad

Scrum pragmático

Scrum Pragmático

Responsabilidades

Metodologías

Mapa de metodologías.

Conceptos

Patrones de gestión del proyecto

Personas, Procesos y Tecnología

Procesos

Personas

Gestión visual kanban para scrum

Gestión visual kanban para obtener incremento continuo.

Introducción: De la artesanía a la producción lean

Lean

Lean Software Development

Kanban: Origen y definición

Tableros kanban: conceptos

Kanban: Operativa

Casos prácticos de tableros kanban

Kanban Box

Muda, Mura y Muri y consejos para ajustar el flujo.

Bibliografía

Tabla de ilustraciones

Índice



2005-2014 – ScrumManager - http://www.scrummanager.net

5

7

7

9

11

13

14

15

16

17

19

19

19

20

21

21

22

23

24

25

27

28

30

32

33

36

40

43

45

47

48



5





Formación Scrum Manager



Formación Scrum Manager

Este libro cubre el nivel II del conocimiento troncal de
formación Scrum Manager®



Los contenidos de formación se mantienen regularmente actualizados. Puede descargar la última versión, o
consultarla en línea en la dirección: http://www.scrummanager.net/bok

Este documento es un recurso educativo abierto (OER) y puede emplearse
gratuitamente para consulta y autoformación.



No está permitido su uso para actividades comerciales.



Los recursos educativos abiertos de Scrum Manager son posibles gracias al
soporte de los:

Servicios de formación y asesoría Scrum Manager



 Cursos en convocatorias presenciales, o a medida para empresas o grupos de estudiantes.

o Puede consultar el calendario de convocatorias en diferentes ciudades en la página de

cursos de http://www.scrummanager.net:

o Para información de cursos a medida: contacte con un Centro Oficial de Formación Scrum

Manager (http://scrummanager.net/centros) o en la dirección [email protected]



 Exámenes presenciales de certificación. con supervisión de la ejecución de la prueba, e

identificación del alumno

Incluidos en los cursos presenciales.

o
o Disponibles en centros de formación autorizados.

Puede localizar centros certificados para servicios profesionales de formación y asesoría en la implantación
y mejora de Scrum Management, en el directorio de centros de formación autorizados Scrum Manager
http://scrummanager.net/ o solicitar información en la dirección [email protected]



Más información:

http://www.scrummanager.net – (preguntas frecuentes)
http://www.scrummanager.net/oks
[email protected]



2005-2014 – ScrumManager - http://www.scrummanager.net



7





Control de calidad Scrum Manager



Mejora continua y control de calidad Scrum Manager

Gracias por elegir los servicios de formación de Scrum Manager

Su valoración es el criterio del control de calidad de Scrum Manager, y decide la validez o no de los
servicios de formación, y en su caso la continuidad de los cursos, centros y profesores.

Si ha participado en una actividad de formación auditada por Scrum Manager, le rogamos y agradecemos
que valore la calidad del material, profesor, temario, etc. así como tus comentarios y sugerencias.

Scrum Manager anonimiza la información recibida, de forma que comparte con los profesores, y centros
autorizados las valoraciones y aspectos de mejora, pero en ningún caso los nombres de los alumnos que
las han realizado.

Puede realizar la valoración en la página accesible a miembros de Scrum Manager:
http://scrummanager.net/qa.



2005-2014 – ScrumManager - http://www.scrummanager.net



9



1.- Conocimiento en continua evolución
Los marcos de prácticas ágiles no llegan a los proyectos TIC como “tesis” de conocimiento, sino como
“antítesis” al que la Ingeniería del Software venía desarrollando.

Comenzaremos viendo qué significa esto, y así tomar la distancia necesaria para ver con perspectiva las
razones por las que los proyectos TIC abrazaron la agilidad a finales del siglo pasado, y sus diferencias con
la ingeniería de procesos; no desde las prácticas concretas, sino desde los principios en los que se basan, y
con ello comprender las fortalezas y debilidades de la agilidad.

Alcanzar una visión de las razones y los principios de cada metodología, más allá de la concreción de un
modelo es clave para dar el salto de gestión técnica a gestión experta. Esto es, de gestión basada en la
aplicación de prácticas a gestión basada en la aplicación del propio conocimiento.



Gestión técnica: Gestión basada en la aplicación de modelos de prácticas y procesos.

Gestión experta: Gestión basada en el conocimiento tácito del gestor



El patrón dialéctico

Al cuestionar el conocimiento, se inicia su evolución que sigue un patrón dialéctico de: tesis, antítesis y
síntesis.

De manera esquemática el patrón dialéctico puede definirse como el ritmo de avance que contrapone una
antítesis a una concepción previa, entendida como tesis. La antítesis muestra los problemas y
contradicciones de la tesis, y de la confrontación surge un tercer momento llamado síntesis, una resolución
o una nueva comprensión del problema.

Ilustración 1: Patrón dialéctico



De esta forma la estrategia de abordar con ingeniería de procesos los retos de los proyectos de software,
supuso la primera tesis para dar respuesta a la “crisis del software”, y sus problemas y contradicciones han
sido puestos de manifiesto por su antítesis: la agilidad.

En 1968, en la primera conferencia sobre desarrollo de software celebrada por la organización OTAN, se
analizaron los problemas de la programación del software, y en ella se acuñó el término “crisis del software”
para referirse a ellos.

La conclusión de la conferencia (Bauer, Bolliet, & Helms, 1969) fue la necesidad de crear una disciplina
científica que, como ocurría en otras áreas, permitiera aplicar un enfoque sistemático disciplinado y
cuantificable al desarrollo, operación y mantenimiento de los sistemas del software, es decir, la aplicación
de la ingeniería de procesos al software. Fue el nacimiento de la Ingeniería del Software.

La primera estrategia de la Ingeniería del software (tesis) se ha basado en dos pilares:

 Ingeniería de procesos:
 Gestión predictiva:



El primero para aplicar el principio básico de calidad contrastado con éxito en los entornos de producción
industrial: “la calidad del resultado depende de la calidad de los procesos empleados”.

El segundo para garantizar el cumplimiento de agendas y presupuestos.

2005-2014 – ScrumManager - http://www.scrummanager.net



11





Scrum pragmático



Mientras esta disciplina evolucionaba y se perfeccionaba a través de diferentes modelos de procesos y
cuerpos de conocimiento para gestión de proyectos (MIL-Q9858, ISO9000, ISO9000-3, ISO 12207, SPICE,
SW-CMM…) en la industria del software surgían dudas y se cuestionaba esta estrategia.

¿La planificación predictiva es apropiada para cualquier proyecto? ¿Los criterios de éxito son siempre el
cumplimiento de fechas, costes y funcionalidades preestablecidas?

Empiezan a surgir proyectos cuya finalidad no es construir un sistema previamente definido y planificado en
su totalidad, y para los que no es realista trazar un plan cerrado desde el inicio. Proyectos en los que no
interesa saber si el sistema final tendrá 20 o 200 funcionalidades, ni conocer cómo serán éstas en detalle:
Su interés es poner una novedad en el mercado lo antes posible, y desde ese momento evolucionar la
visión y valor de forma continua.

Por otra parte también se cuestiona si el software se puede producir con patrones de procesos industriales,
y se empieza a aceptar que en la calidad del resultado puede ser más importante el conocimiento tácito de
la persona que lo realiza que el know-how aportado a través del proceso y la tecnología empleada.



Ilustración 2: Evolución de los primeros modelos de mejora



Desde los orígenes de la agilidad, a mediados de los 90, hasta 2005-2010 han sido habituales las posturas
radicales entre los defensores de los modelos de procesos y de los marcos ágiles, posiblemente más
enfocados en descalificar al otro que en revisar y depurar los propios métodos.

Algunos ejemplos de esta tensión:

"La diferencia entre un atracador de bancos y un teórico de CMM es que con el atracador se puede
negociar"…

"La evaluación en CMM depende más de una buena presentación en papel que de la calidad real del
producto de software. Tiene que ver más con el seguimiento a ciegas de una metodología que con el
desarrollo y p