Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Postmortem reviews:

No description
by

on 30 June 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Postmortem reviews:

Aprendizaje
Postmortem reviews:
Purpose and approaches in software engineering

Gestión del Conocimiento

Aprendizaje mediante participación: comunidades de practica
Aprendizaje: proceso de conversión del conocimiento tácito a explicito

El proyecto en su ámbito de aprendizaje
Revisiones
Postmortem

Qué es Postmortem?
Revisiones postmortem en Ingeniería de Software
Métodos para conducir una revisión postmortem
1) Neal Whitten
2) Collison y Parcell
(Organizar una reunión de retrospectiva)
Método KJ
Pasos para la reunión Postmortem
(1) Introducción

(2) Sesión 1 Método KJ

(3) Sesión 2 Método KJ

(4) Análisis de causas
Caso Postmortem en una compañía mediana
Una compañía de software Satélite
El proyecto
Postmortem
Resumen
y
Discusión

Requerimientos para un buen proceso Postmortem
Quién invitar?
Con o sin tarea?
El Facilitador
Con o sin gestión?
Cual debe ser el resultado?
Conocimiento tácito o explícito?
Conclusiones
FIN
Preguntas?

Introducción
Temario
Introducción
Revisiones Postmortem
Caso Postmortem en una compañía mediana
Resumen y discusión
Conclusiones
Aprendizaje colectivo que puede ser organizado por proyectos tanto cuando se cumple una fase o se termina el proyecto.

El resultado físico es un reporte

Se llaman también: reuniones retrospectivas, análisis postmortem, revisiones, etc
Combinación de aprendizaje a través de socialización (escuchar a otros) y externalización (reflejar y compartir experiencia personal con otros). (Segun Nokata y Takeuchi).


Aprender de revisiones post - proyecto está visto como una de las practicas mas prometedoras para ganar ventaja competitiva.


Solo 1 de 5 proyectos tienen revisiones post-proyecto

Postmortem es sencillo: se basa en el dialogo y discusión como elemento centrar de transferencia de conocimiento.


Criticas: las personas no tienen memoria precisa luego de que se termina el proyecto. Se aconseja recolectar informacion durante el proyecto
Diseñar un estudio del proyecto
Colectar información de los objetivos del proyecto
Reunión informativa
Una historia del proyecto día a día
Publicación de resultados
Esfuerzo en escribir un reporte Postmortem:
Contiene discusiones como:

Que funcionó bien en el ultimo proyecto?
Qué no funcionó bien?
Qué debe hacer el equipo para mejorar?

5 post its por persona
Pizarrón con "issues"
Se agrupan las notas y a cada grupo de notas se le asigna un nombre
Grabar sesiones
Estudio en 19 Compañías de Europa demuestran que:

Las personas no tienen tiempo para reuniones post proyecto

Las personas son reasignadas rápidamente

no encuentran satisfacción con el método Postmortem
Se detecta necesidad de ayudar a empresas de software a elegir métodos más simples para conducir Postmortem
El beneficio de conducir revisiones Postmortem es que proveen un foro de aprendizaje con discusiones relevantes sobre el proyecto y la compañía
Tener un líder especializado que fomentar el diálogo abierto y evite criticas entre participantes
Buena atmósfera: todos hicieron lo mejor que pudieron, destacando habilidades de los demás


Tiempo ideal de la reunión?

Depende del tamaño del proyecto: a mayor tamaño, mayor tiempo de reunión
Personas del proyecto: planificación, desarrollo, testing, usabilidad.


Personas de proyectos similares como miembros clave.

Diferentes puntos de vista:

Tarea en casa estimula la reflexion personal (Whitten)

No hacen enfasis en tareas en casa (Collison y Parcell, Birk)
Todos los métodos recomiendan un facilitador

El Project Manager está muy involucrado con el proyecto, y puede generar presión a los participantes (siempre los está evaluando).

Puede ser alguien externo al proyecto o externo a la Compañía.

El facilitador debe estar correctamente entrenado
Los gerentes no deben formar parte de las

revisiones Postmortem, ya que su intención es

evaluar a los empleados y la intención de estas

revisiones es el aprendizaje
Whitten sugiere una lista de recomendaciones para asegurar el aprendizaje en otros proyectos
Collison y Parcell sugieren una guía para el futuro, incluyendo historias ilustrativas y nombres de personas involucradas.
Birk sugiere un reporte con la descripción del proyecto, qué estuvo bien, qué estuvo mal, y sus respectivas causas
Compañías chicas deben enfocarse en compartir conocimiento tácito

Compañías grandes deben codificar el conocimiento, invirtiendo en documentación
Los métodos varían en distintas dimensiones:
Quien invitar
Como prepararse
Como facilitar la reunión
Como estructurar debates
Cual es el resultado de la reunión
De acuerdo a la estrategia de gestión del conocimiento, las empresas deben elegir el método a utilizar en las revisiones Postmortem
Consejo general:
El facilitador debe ser una persona externa al proyecto
Organización de Aprendizaje
Organización experta en crear, adquirir y transferir conocimientos y modificar su comportamiento para reflejar nuevos conocimientos y perspicacia. [Gravin]

Aprendizaje
Es una cuestión de mantenimiento de las comunidades interconectadas de la práctica a través de la cual una organización sabe lo que sabe. [Wenger]

Para adquirir conocimiento o habilidad en el estudio de, instrucción o experiencia, para informarse o conocer o para memorizar
En ingeniería de software

Una organización de aprendizaje en software tiene que crear una cultura que promueve el aprendizaje continuo y fomenta el intercambio de experiencias. [Feldmann]

Una organización de software que promueve acciones de mejora a través de un mejor conocimiento y comprensión. [Dyba]

2 modelos de transferencia de conocimiento
Aprendizaje a través de la participación: comunidades de práctica.
Aprendizaje como un proceso de conversión entre el conocimiento táctico y explícito.

Una comunidad de práctica desarrolla sus propias:
Practicas
Rutinas
Rituales
Objetos
Símbolos
Convenciones
Cuentos
Historias
Wenger define el aprendizaje como
Personas: se lleva a cabo en participar y contribuir a la comunidad.
Comunidades: es refinar la práctica.
Organizaciones: es para sostener comunidades interconectadas de práctica.

Explica el éxito de las empresas japonesas por su esfuerzo en la "creación de conocimiento organizacional"

El conocimiento es transformado constantemente de tácito a explícito y viceversa, ya que pasa a través de una organización. [Nonaka y Takeuchi]

4 modos de conversión
Socialización
significa transferir el conocimiento tácito a tácito a través de la observación, la imitación y la práctica, denominada formación "en el trabajo"

Combinación
es ir de explícito a conocimiento explícito. Combinar y sistematizar el conocimiento de diferentes fuentes. Ej.: documentos, reuniones, conferencias telefónicas, etc.

Internalización
es tomar conocimiento externalizado y convertirla en conocimiento tácito individual en forma de modelos mentales o conocimientos técnicos. Ej.: documentos y manuales.

Externalización
significa pasar de tácito a conocimiento explícito. El conocimiento explícito puede tomar forma de metáforas, analogías, conceptos, hipótesis o modelos. Ej.: dialogo o reflexión colectiva.
Fábrica de experiencia: entidad de la organización independiente con la responsabilidad de capturar y reutilizar la experiencia.

La experiencia se obtiene de los proyectos de desarrollo de software, se almacena en una base de experiencia

La compañía de SW y HR para las estaciones que reciben datos de los satélites de observación meteorológica y de la Tierra.



Posee:
60 personas
Personal estable y altamente calificado.
Cultura de la ingeniería.
Problemas:
Estimaciones erróneas
Falta de transferencia de conocimiento.
Informes de cierre no utilizados.
Sistema para un satélite que graba datos medioambientales.
Desarrolla un módulo de análisis de datos del satélite, desde especificaciones de la Agencia Espacial Europea.

Características
Proyecto Crítico
Duración 36 meses
Personal:
4 en fase de análisis
8-12 en fase de diseño
5-9 en fase de pruebas
47000 horas de trabajo.

Breve introducción.
Sesión de lluvia de ideas KJ para identificar temas que salieron bien.
Resultados de la sesión KJ.

Los participantes expresaron lo siguiente:
Los cambios de requerimientos durante el proyecto hicieron tomar decisiones que redujeron la calidad del software.
Los requerimientos pocos claros del cliente hicieron perder tiempo en discusiones.
Luego se usó la espina de pescado para un nuevo análisis sobre los requisitos.
La causa no era solo la definición por parte del cliente sino que se encontró que los documentos relacionados a los requerimientos no fueron bien gestionados por la empresa.

Sobre problemas que aparecieron en el proyecto.
Fueron los que agrupan el post-it cambio de requerimientos.
Opinión de los participantes luego de finalizar la reunión.
Obtuvieron nuevos puntos de vista.
Visualizaron los problemas desde otras perspectivas.
Revisión Postmorten interesante porque no era habitual
Full transcript