Metodología Scrum Grupo S2 Ariel Amantea 81968 Assefi, Ershad80670 Giachini, Andres82096...
Preview:
Citation preview
- Diapositiva 1
- Diapositiva 2
- Metodologa Scrum Grupo S2 Ariel Amantea 81968 Assefi,
Ershad80670 Giachini, Andres82096 Victoriano, Oscar 81713 Taller de
Desarrollo de Proyectos II 2 Cuatrimestre 2008
- Diapositiva 3
- Esta presentacin no pretende vender nada, simplemente exponer
nuestra forma de realizar un proyecto asimilando una metodologa
diferente para nosotros hasta el momento. No solo no esperamos que
todo est correcto, sino que creemos que hay errores, queremos
corregirlos y esperamos que as sea.
- Diapositiva 4
- Diapositiva 5
- Product Backlog Sprint Backlog User Stories UAT Casos de Prueba
Planilla de administracin de riesgos Minuta de Reunin Sprint Review
Sprint Retrospective Etc.
- Diapositiva 6
- Aplicacin Web PHP Diseo en capas Framework MVC (iOnix) Apache
HTTP Server MySQL
- Diapositiva 7
- Diapositiva 8
- Diapositiva 9
- Diapositiva 10
- La administracin de riesgos fue quizs, uno de los puntos mas
dbiles de la administracin. Dificultad para identificarlos (al
principio no eran del todo claros) Fue uno de los documentos que
menos vari en el transcurso del proyecto y no creemos que esto sea
del todo representativo.
- Diapositiva 11
- Utilizamos como expresamos en la primer exposicin, el MSN
(chat) para realizar las reuniones diarias. Los llamados telefnicos
personales se incrementaron de forma notoria al final de cada
sprint mientras se estabilizaba la versin que sera presentada en la
revisin. Al comienzo del proyecto los mails de apoyo con
instrucciones acerca de las herramientas utilizadas (principalmente
el Framework) o detallando los problemas encontrados y las
soluciones aplicadas fueron de gran utilidad (esto se vio
potenciado por la incapacidad de encontrarnos cara a cara a la hora
de desarrollar el aplicativo)
- Diapositiva 12
- Se especific un esquema de trazabilidad acorde a nuestras
necesidades, logrando trazabilidad entre: Especificaciones vs.
Cdigo Asociando cada commit a una tarea (ticket) de assembla (las
cuales a su vez hacan referencia a una US y Sprint)
Especificaciones vs. Pruebas Asociando cada caso de prueba y UAT a
su US y Sprint correspondiente Especificaciones vs. Diseo Asociando
cada seccin del documento de diseo a la US correspondiente.
- Diapositiva 13
- Mtodo de estimacin > Wideband Delphi Valor = optimista +
4*mas probable + pesimista / 6 Cada integrante estimaba y luego se
refinaba hasta llegar a tener valores similares. Planificacin de
tareas > creacin de tickets en assembla Permiti llevar un
control del estado de las tareas, fechas de vencimiento, etc.
Planificacin por sprint (Al principio de cada sprint se
planificaban las tareas a realizar)
- Diapositiva 14
- Sprint Burndown Chart Product Burndown Chart Team Velocity
- Diapositiva 15
- A travs del sistema de tickets de assembla Por cada bug, se
generaba un ticket asociado a una tarea. Permiti controlar los
defectos, llevar estadsticas de bugs sin resolver, revisiones de
sus estados, etc.
- Diapositiva 16
- El control de cambios se llev a cabo a travs de la
implementacin de un comit de cambios, con un aprobador y varios
analistas de cambios. El proceso fue el siguiente: 1 Se solicitaba
el cambio al product owner del equipo 2 El product owner presentaba
el cambio solicitado al aprobador a travs de la carga de un nuevo
ticket en Assembla 3 El aprobador analizaba el cambio, discuta con
el resto del equipo el impacto que poda llegar a tener y el costo
para realizarlo. 4 Si el cambio se aprobaba, se lo planificaba para
un sprint prximo, sino quedaba sujeto a una lista de priorizacin a
futuro (los cambios no se desechaban). 5 Se informaba al
solicitante la decisin adoptada.
- Diapositiva 17
- Diapositiva 18
- La realizacin de la misma un lunes agregaba dos das de
distensin en el equipo en el ritmo de trabajo, provocando olvidos y
percepciones diferentes a las que se obtendran por ejemplo al
realizarla un viernes (luego de todo el trabajo de la semana)
Dificultad para respetar los tiempos de presentacin de situaciones
y el anlisis de las mismas. Nos veamos tentados a analizar o
cuestionar un tem al momento de presentarse el mismo. Propusimos
que cada miembro lleve una bitcora personal de tems durante el
sprint para evitar el olvido de las situaciones pasadas en los
primeros das del sprint.
- Diapositiva 19
- Se presentaron dificultades al intentar evitar el
encasillamiento de tareas por parte de los miembros a la hora de
tomar tems. Si bien cada uno toma el que prefiera (respetando la
prioridad de ser posible), generalmente cada uno tomaba las que mas
conoca para agilizar el transcurso del sprint y no retrasarnos.
Hubiera sido de gran ayuda el compartir el espacio fsico a la hora
de realizarse el proyecto (pair programing, revisiones de cdigo,
comentarios verbales, etc.), por lo cual recomendamos fuertemente
que los miembros del equipo, de ser posible, compartan la misma
habitacin (a la hora de trabajar) y que todos tengan contacto
visual con todos.
- Diapositiva 20
- Encontramos en las primeras reuniones falta de preparacin para
las review. Predomin una falta de fluidez, la cual, de alguna u
otra manera, daba una imagen de timidez ante el cliente (algo para
nada recomendable) y que perjudicaba el normal desenvolvimiento de
la misma. Ante diferencias de opiniones entre los miembros del
equipo, el cliente tenda a desconfiar de lo que se le presentaba y
de la veracidad de nuestras respuestas.
- Diapositiva 21
- A pesar de no estar familiarizados con la metodologa y las
restricciones presentadas por ser un proyecto acadmico, SCRUM
demostr ser efectiva. El cliente estuvo constantemente informado y
satisfecho (en mayor y menor medida ). Se logr en poco tiempo
adquirir las costumbres que hacen a las bases de la metodologa e
incorporar otras que son propias del proyecto dndole as
flexibilidad y una customizacin que sera imposible con una
estructura rgida e invariante de trabajo. Pero este es nuestro
punto de vista, deberamos ahora preguntarles nosotros a nuestro
cliente y a los presentes si desde su punto de vista
- Diapositiva 22
- Diapositiva 23
- Se logr un buen trabajo a partir de la utilizacin de User
Stories y User Acceptance Test, herramientas que el equipo de
trabajo nunca haba utilizado antes, a pesar de que quedaron
cuestiones a mejorar en ese aspecto. Se logr un trabajo coordinado
y cohesivo con el uso de la metodologa Scrum, que permiti al equipo
cumplir con todos los entregables, contabilizando un nico rechazo
de una funcionalidad entregada en un sprint temprano. Dicho rechazo
nos permiti comprender que debamos dedicar un mayor esfuerzo a la
realizacin y ejecucin de los test de aceptacin, y sobre todo, a
realizar con mayor anticipacin la preparacin del ambiente de
aceptacin del producto. Cumplir siempre con lo pactado (incluso ms
en algunas oportunidades) ayud a asegurar la confianza de nuestro
cliente.
- Diapositiva 24
- A pesar de contar con un esquema de trazabilidad, el mismo
result complejo de utilizar, por lo cual debera tratar de
modificarse a futuro, a fin de hacerlo ms prctico y menos engorroso
para los integrantes del equipo. El mtodo de estimacin utilizado no
result de lo mas amigable para la metodologa utilizada. Debera
contemplarse la utilizacin de story points como unidad de medida a
futuro para una mayor compatibilidad con las herramientas de
control provistas por Scrum. Debido a la naturaleza del trabajo, no
pudo aplicarse Scrum en todo su amplio sentido. El ejemplo claro es
el de las daily meeting, que por cuestiones obvias no fueron
realizadas como la metodologa lo sugiere. Sin embargo, se ha
comprobado que la metodologa es realmente til a pesar de estos
detalles.
- Diapositiva 25
- Diapositiva 26
- Diapositiva 27