Gestion de Proyectos Notas de Proyectos

1. 1 Capacitando Nuestro Rol Como PO. .................................................................................... 2
1.1 Identificando nuestros sponsor ................................................................................... 2
1.2 Entendiendo diferencias en proyectos Tradicionalese Iterativos................................... 3
1.2.1 Tradicionales....................................................................................................... 3
1.2.2 Iterativos............................................................................................................ 3
1.2.3 Entendiendo y Aplicando el Pareto 80-20 como PO .............................................. 5
1.2.4 HDD - HYPOTHESIS-DRIVEN DEVELOPMENT.......................................................... 6
1.3 Entendiendo las Ceremonias y donde Actuar................................................................ 8
1.4 Planning....................................................................................................................10
1.5 Daily.........................................................................................................................11
1.6 Refinamiento del BackLog..........................................................................................13
1.6.1 De historias Épicas a Historias Detalladas............................................................13
1.7 Refinamiento de las historias de usuario hasta llegar a una definición de listo (DOR). ....16
1.8 Review......................................................................................................................17
Juan Gabriel Pérez Guerra.
Analista de Desarrollode Tecnología de Información
Gerencia de Tecnología de Información
Servicios Nutresa S.A.S.
Carrera 52 N 2-38 Medellín -Colombia
Tel:(574) 3655600 Ext. 5417
Correo Electrónico: jgperez@serviciosnutresa.com

2. 1 Capacitando Nuestro Rol Como PO.
1.1 Identificando nuestros sponsor
Los sponsors,patrocinadoresoauspiciantescorporativossonpersonasoempresasque colaboran
económicamente yestratégicamente.

3. EllosPuedenparticiparendistintosespacios,yenestodesde laorganizaciónse tieneque ser
creativoy flexibleparanegociaratravésde distintosacuerdosde qué manerapuedenformar
parte del proyecto.
1.2 Entendiendo diferencias en proyectos Tradicionales e Iterativos
1.2.1 Tradicionales
El triángulode hierro,larelaciónque existe entre los objetivosdel proyecto oproducto(alcance),
tiempoycoste,de maneraque cualquiermodificaciónenel algunode estosparámetrosimplicala
variaciónde otro. Implicaun control predictivoyplandel proyecto.
1.2.2 Iterativos
La planificación iterativa tomacomobase el control empíricode la construcciónde producto
(inspecciónyadaptación),porlocual:
Está basadoen OBJETIVOSDE PRODUCTO(implementación iterativoe incremental) priorizados
balanceandobeneficiosde negociorespectoasuscostesde en implementación.

4. ProcesoPlanificación:
1. Identificarlaverdaderanecesidad.
2. Inception
a. IdentificarlosObjetivosde Negocio
b. Entregables
i. PlanBase.
3. Estimaciónconexpertos
4. Cortar Alcance.
Fuente Adicional
https://proyectosagiles.org/2010/12/15/planificacion-agil-vs-planificacion-tradicional/

5. 1.2.3 Entendiendo yAplicando el Pareto 80-20como PO
Donde nuestrorol principal esidentificarlassemillas “Que construir”20% y donde sembrarpara
que impacte el 80%,
En más detalle estosignifica:
Que «el 80 % del esfuerzode del equipo (entiempoyrecursos) produce el 20% del código,
mientrasque el 80 % restante esproducidocontan soloun 20 % del esfuerzo».

6. Si hablamosde implementarel principioennuestrosproyectosesto nosdice que «el 80% de los
fallosde unsoftware esgeneradoporun20 % del códigode dichosoftware,mientrasque el otro
80 % generatan soloun20 % de losfallos».
Sesgodel Experto:Conoce del procesoperonode losclientes.
1.2.4 HDD - HYPOTHESIS-DRIVENDEVELOPMENT
Los pasosdel métodocientíficoson:
Hacer observaciones
Formularuna hipótesis
Diseñarunexperimentoparaprobarla hipótesis
Indicarlosindicadoresparaevaluarsi el experimentohatenidoéxito
Llevara cabo el experimento
Evaluarlos resultadosdel experimento
Aceptaro rechazar lahipótesis
Si es necesario,haceryprobar unanuevahipótesis.
En el mundodel Software
Tenemosque cuestionarel conceptode tenerrequisitosfijosparaunproductoo servicio.Los
requisitossonvaliososcuandolosequiposejecutanunafase muyconocido oentendidode una
iniciativa, puedenaprovecharlasprácticasbienconocidasparalograr el resultado.Sinembargo,
cuandose estáenuna fase exploratoria nueva,complejoe incierto esunbuenlugarparacrear
hipótesis.

7. El Negocioesel que piensa y'sabe'lo que escorrecto.El propósitodel equipode desarrolloes
ponerenpráctica lo que lesdicen.Perocuandose operaenun área de incertidumbrey
complejidad,todoslosmiembrosdel equipode desarrollodeben aletarse parar, pensary
compartirpuntosde vistasobre el problemaylas posiblessoluciones.Unequiposimplemente
recibirórdenesde unpropietariode negocionoestáutilizandotodoel potencial,laexperiencia y
la competenciade unequipomultidisciplinario.
Las hipótesisde encuadre
Se centra enla captura de los requisitosparaloque queremosconstruirypara quién, para
permitirque el usuariorecibaunbeneficiode valor:
Comoun…. <Función>
Yo quiero...<meta/ deseo>
Con el finde ...<recibirbeneficios>
Al visualizarel trabajocomounexperimento,el marcotradicional historiaesinsuficiente.
Entoncestenemosque declararlosindicadoresespecíficos(oseñales) que esperamosobservar
que proporcionanevidenciade que nuestrahipótesisesválida.
Creemos< estacapacidad>
¿Qué funcionalidadvamosadesarrollarparaponera pruebanuestrahipótesis?Mediante la
definiciónde unacapacidadde 'prueba'del productoo servicioque estamostratandode
construir,identificamoslafuncionalidadylahipótesisque queremosprobar.
Dará lugara < este resultado>
¿Cuál esel resultadoesperadode nuestroexperimento?¿Cuál esel resultadoespecífico
esperamosalcanzarmediante laconstrucciónde la 'prueba'?

8. Vamosa tenerconfianzaparaseguiradelante cuando< vemosunaseñal medible >
¿Qué señalesindicaráque lacapacidadque hemosconstruidoeseficaz?¿Qué métricas clave
mediremosparaproporcionarevidenciade que nuestroexperimentohatenidoéxitoynosdanla
confianzasuficiente parapasara la siguiente etapa.
El pasofinal es claro y visible Indicarlaexistenciade supuestosacercade nuestrahipótesis,para
crear un circuitode retroalimentaciónparael equipoparaproporcionarmáselementos,el debate
y la comprensiónde lascircunstanciasbajolascualesestamosllevandoacabo laprueba.¿Son
válidasytienensentidodesde el puntode vistatécnicoyde negocio?
HipótesiscuandoalineadoasuMVP puedenproporcionarunmecanismode pruebade su
productoo serviciode lavisión.Puedenprobarlaszonasmás inciertas de suproductoo servicio,
con el finde obtenerinformaciónymejorarlaconfianza.
1.3 Entendiendo las Ceremonias y donde Actuar

9. Nota:Los tiempospuedenvariarde acuerdoal proyectocomplejidadyladedicación
Las actividadesson:
 1) Maximizarel Valordel Productoydel Trabajo del Equipo(Al comienzo,Durante yal
FinalizarlaIteración) 3 horas.
 2) Crear y gestionarel ProductBacklog(listade necesidades) de acuerdoalasnecesidades
de negocio(ActividadDiaria1Hora)
 3) Participarde las ceremonias(Daily,Planning,Review,Refinement,Retrospective)
Daily – 15 Min o Menos Diario
Planning 3 horas,
Review3Horas,
Refinamiento2horas,
Retrospectiva2Horas,
 4) Escribirclaramente lashistoriasde usuario/requerimientosypresentarlasal equipo
antesdel iniciode sprint(1Hora Diaria)
·
 5) Resolverdudasdel equipode desarrollo(de 10a 15 MinutosDiario)

10.  6) Asegurarque loque se trabajaen el sprinteste alineadoconlasprioridadesdefinidas
(de 10 a 30 MinDiario)
 7) Revisary aprobarel trabajo realizadoporel equipo (de 10a 30 Min) Diario.
 8) GenerarDocumentaciónGeneral paraNutresa(1hora Diaria)
En total De tiempome Aproximadoporiteración
1) 3 Horas
2) 5 Horas
3) 10 Horas
4) 4 Horas
5) 1 Hora
6) 1 Hora
7) 1 Hora
8) 4 Horas
Total Horas: 30
1.4 Planning

11. La planningse puede resumiren2partes.
El QUE
Lo debe construirel POy el DevTeam acompañadosporel Unitymaster.
EL COMO
Se llevaa cabo unprocesode TASKINGPorHistoriasa su vezlaestrategiadadapor el DevTeam
para para abordar las historiasde usuario.
1.5 Daily
Dailyse resume en:
La reunión de laUNITY diariano se utilizacomounareuniónde resoluciónde problemasola
resoluciónde problemas.Cuestionesque se planteansontomadasfuerade líneaygeneralmente
tratados porel subgrupocorrespondiente,inmediatamente despuésde lareunión.Durante la
reunióndiaria,cadamiembrodel equiporesponde alastrespreguntassiguientes:

12. ¿Qué hiciste ayer?
¿Qué vas a hacer hoy?
¿Existenimpedimentosensucamino?
¿Qué lodejaría muyFeliz?
Al centrarse enlo que cada personallevaacabo ayery lograr hoy,el equipoobtieneunaexcelente
comprensiónde loque el trabajose ha hechoy loque quedade trabajo.
Cualquierimpedimentoque se planteanenlareuniónse conviertenenlaresponsabilidaddel
UNITY MASTER para resolverlomásrápidamente posible.impedimentostípicosson:
Mi ____ se rompióy necesitounonuevohoy.
Todavía no tengoel software pedíhace unmes.
Necesitoayudaparadepurarun problemacon______.

13. Estoy luchandoparaaprender______ y me gustaría emparejarconalguien .
No puedoconseguirgrupode soporte técnicodel proveedorparallamarme.
Nuestronuevocontratistanose puede iniciarporque nohaynadie aquípara firmarsu contrato.
No puedolograrque el grupo____ darme cualquiermomentoytengoque cumplirconellos.
El jefe me hapedidoque trabajarenotra cosa "por un día o dos."
1.6 Refinamiento del BackLog.
Videode Apoyo:
https://www.youtube.com/watch?v=b_WeHcZcx1w
https://www.scrumalliance.org/community/articles/2014/october/product-backlog-
refinement#sthash.a9lQ8V7l.dpuf
La actividadde refinamientose realizaconlaunityel POayudadosporel scrum masterse
construye el ProductBACKLOGa partir del Visual StoryMap.
loselementosdelbacklogdel productosonrevisados porlaunity,proporcionandomásdetalle
para asegurarque hayuna mayor claridadenlosrequisitosparaese artículo.
Que Refinar?
Prioridadal refinamientode loselementosdelbacklogdel productoque puedansertomadasenel
siguiente iteración.Estoaseguraráque lainformaciónsuficiente,paraque el planse genera
durante la planificaciónde laiteraciónencuantoa cómoel elementopilade producto
seleccionadopuede serentregado,yparapermitirque el equipoque se comprometanaentregar
ese y otrosartículos enlossiguientes.
1.6.1 DehistoriasÉpicas aHistoriasDetalladas

14. Antesde una sesiónde refinamientoyde planningespreferibletenerhistoriaspequeñas
detalladasymediblesapartirdel Visual Storymapse debensacar tantashistoriasseanposibles
para la iteracióndadoque porexperienciadurante el refinamientoyestimacióndelequipoes
posible que lashistoriastenganque serdivididaenmáspequeñaspartes.
(Guía para la creaciónde una historiaNoUsar enWord,Excel,Ppt,Se usa es laHerramientade
Gestióndel Proyectopreviamente parametrizadayacordadpor el proyecto)
# ID#### HistoriaPadre Épica
# ID#### Titulode la Historia
# Estadode lahistoria
New,Inspecification, Tobe scheduled,Inprogress,Developed, Intesting,Tested,Closed
# Impactoenobjetivos del Reléase/indicadores:
# VersiónoReléase vaenfocadalaHistoria:
# Puntaje /Peso(EstimaciónRelativa) Estaesdada por el equipo.
#Descripción:

15. Yo como:
Necesito:
Para:
#Criteriosde Aceptación:
Criterio1 :
Criterio2:
#Escenariosde Prueba:
Escenarios:
Escenariode Excepción:
# Prerrequisitos:
# Tareasde lahistoria (Las tareasson llenadasporel equipode desarrollose usaKANBAN)
[ ] Tarea 1
[ ] Tarea 2
[ ] Tarea 3
# Prioridad
# DocumentosAdjuntosde Apoyo
# Autor
# Responsable
=============================================================================

16. 1.7 Refinamiento de las historias de usuario hasta llegar a una definición
de listo (DOR).
La historiade usuarioestábiendefinida
El criteriode aceptaciónse entiendeyse comparte portodos
Las dependenciasde altonivel se conocenasícomolosriesgos
El equipotiene unaideaaaltonivel sobre laexperienciade usuarioactual ydeseable
La historiatiene untamañoasignado
El equipose siente confortable que realmente loque se estátratandode resolveresunproblema
para losObjetivosplanteadosenlaPrimeraIteración
Se han pasadopor al menos2 refinamientosde lahistoriaantesde unaiteración

17. 1.8 Review
La reviewesorganizadaporel POcon el objetivode evidenciarlosresultadosdurante laiteración,
obtenerinformaciónque permitamejorarel productoydefinirestrategiageneralparalas
siguientesiteraciones:
EvidenciarDonde estamos
Evidenciar el Objetivode laIteración ylas Historiascomprometidas.
Aspectosa Destacar
Riesgosidentificados
CalificarHistoriasde Usuarioconla retroalimentaciónde losusuariosystake holders.
Estrategiapara lassiguientesIteraciones.
EJEMPLO PRESENTACION

18. 11_Review Iteracion
02.pptx
1.9 Retrospectiva
La retrospectivase puederealizarpara2 focos1 para productoy otra para equipo.
1.9.1 Para el Equipo
La retrospectivade equipose enfocaenlossiguientesaspectos
Que me disgusta

19. Que me entristece
Que me hace feliz
Y Se expone atodoel equipo
Luegose procede a ayudar al equipoaidentificaraactividadespuedenintentarseoexperimentar
para la siguiente iteración.
Que se debe mantenerparalasiguiente iteración.
Que se debe cambiar.

20. 1.10 Para el Producto

21. La retrodel productose debe abordaren untime Line identificandoque se vaabordardurante la
siguiente iteración,fijarlosobjetivosde laiteración e identificarque elementosde Reléase se
puedenadelantaryredefinirel BackLogyretandoal equipoamejorarel esfuerzo.