Metodologías

 Ágiles  para  la  ges0ón  

de  proyectos  Web  
 
Metodologías  ágiles    
 
       vs    
         
   Metodologías  tradicionales  
 ¿Por  qué  suele  fracasar  un  proyecto?  
Informe  de  Standish  Group,  en  2004:  
 
•  Requerimientos  y  especificaciones  incompletas  
•  Cambios  frecuentes  en  los  requerimientos  y  especificaciones  
•  Incompetencia  tecnológica  
•  Falta  de  recursos  
•  ExpectaMvas  no  realistas  
•  ObjeMvos  poco  claros  
•  Cronogramas  irreales  
•  Nuevas  tecnologías  
Metodologías  tradicionales  
Modelo  en  cascada  
 
Análisis    
                   à  Diseño    
                                               à  Desarrollo    
                                           à  Pruebas  
                                   à  Mantenimiento  
 ¿Por  qué  suele  fracasar  un  proyecto?  
Informe  de  Standish  Group,  en  2004:  
 
•  Requerimientos  y  especificaciones  incompletas  
•  Cambios  frecuentes  en  los  requerimientos  y  especificaciones  
•  Incompetencia  tecnológica  
•  Falta  de  recursos  
•  ExpectaMvas  no  realistas  
•  ObjeMvos  poco  claros  
•  Cronogramas  irreales  
•  Nuevas  tecnologías  
Metodologías  Ágiles  (1)  
•  Individuos  e  interacciones  sobre  procesos  y  
herramientas  
•  So0ware  que  funciona  sobre  documentación  
exhaus0va  
•  Colaboración  con  el  cliente  sobre  negociación  
de  contratos  
•  Responder  ante  el  cambio  sobre  seguimiento  
de  un  plan  
Metodologías  Ágiles  (2)  
•  Esencia  del  agilismo:  adaptación  a  los  cambios  
•  Se  trabaja  por  obje1vos,  no  por  Mempo  (lo  cuál  
no  significa  que  no  haya  Mempos  de  entrega)  
•  Equipos  pequeños  (no  más  de  7).  En  proyectos  
grandes,  varios  equipos:  divide  y  vencerás.  
•  No  hay  análisis  exhausMvo  previo.  A  través  de  
diversas  iteraciones  se  pormenorizan  los  
requisitos.  
 Scrum  (1)  

Fuente:  h[ps://upload.wikimedia.org/wikipedia/commons/5/58/Scrum_process.svg    
 ¿Por  qué  suele  fracasar  un  proyecto?  
Informe  de  Standish  Group,  en  2004:  
 
•  Requerimientos  y  especificaciones  incompletas  
•  Cambios  frecuentes  en  los  requerimientos  y  especificaciones  
•  Incompetencia  tecnológica  
•  Falta  de  recursos  
•  ExpectaMvas  no  realistas  
•  ObjeMvos  poco  claros  
•  Cronogramas  irreales  
•  Nuevas  tecnologías  
 Agile  IncepMon  
Agile  Incep1on,  también  conocida  como  Incep0on  
Deck   o   simplemente   Incep0on,   es   un   conjunto   de  
dinámicas   orientadas   a   enfocar   a   todas   las  
personas   involucradas   en   un   proyecto   hacia   un  
mismo   obje1vo,   reduciendo   muchas   de   las  
incerMdumbres,   ayudando   a   explicitar   los   riesgos  
más   evidentes   y   poniendo   en   común   las  
expectaMvas  de  todos.  
¿Por  qué  estamos  aquí?  
Qué  queremos  hacer  y  por  qué  lo  vamos  a  hacer:  
•  Razón  de  peso  nº  1  
•  Razón  de  peso  nº  2  
•  Razón  de  peso  nº  3  
•  …  

#1  la  razón  más  importante  de  todas  

Fuente:  h[ps://agilewarrior.wordpress.com/2010/11/06/the-­‐agile-­‐incepMon-­‐deck/  
Fuente:  h[ps://agilewarrior.wordpress.com/2010/11/06/the-­‐agile-­‐incepMon-­‐deck/  
Elevator  Pitch  /  Valor  diferencial  
Elevator  pitch  
Para  [target  /  clientes  a  los  que  va  dirigido]  
…  que  buscan[oportunidad,  necesidad,  nicho  de  
mercado]  
…el  [nombre  de  nuestro  proyecto]  
…es  un    [categoría  del  producto]  
…que  [principales  beneficios,  razones  para  
comprarlo].  
…a  diferencia  de  [principales  compeMdores  ]  
…nuestro  proyecto  [factor  diferencial  principal]  
Product  box  

<nombre  del  producto>  

Imagen  de  portada  

<slogan>  

Si    el  producto  estuviera  ya  disponible  en  una  Menda,  ¿cómo  sería?  
El  objeMvo  en  este  punto  es  conseguir  algo  “que  entre  por  los  ojos”,  y  que  
 explique  al  cliente/inversor    visualmente  lo  que  se  quiere  crear.  
La  lista  del  NO  /  NOT  List  
•  Decir  sí  es  fácil.  Lo  complicado  es  decir  no.  
 
•  The  NOT  List  nos  hace  poner  los  pies  en  la  
Merra,  para  dejar  claro  qué  se  puede  esperar  
de  un  proyecto,  y  qué  no  se  puede  esperar.  
The  NOT  list  
IN   OUT  

UNRESOLVED  
La  comunidad  del  proyecto  
interactuar.  
…  todas  aquellas  personas  con  las  que  en  algún  momento  del  desarrollo  vamos  a  

<arMstas>  

<diseñadores>   El  núcleo  del  equipo     <programadores>  

Todos  los  demás…  

…publisher,  marke1ng,  prensa,  redes  sociales…  
…a  los  que  iremos  informando  en  el  momento  adecuado  de  la  evolución  del  proyecto  
Soluciones  técnicas  

Tecnologías:  
-­‐   <herramienta  de  desarrollo>   Danger!  
-­‐   <lenguajes  de  programación>  
-­‐   <tools>   ¿El  equipo  de  desarrollo  está  cómodo    
-­‐   <souware  adicional>   con  las  tecnologías  que  se  van  a  u1lizar?  
Riesgos  del  proyecto  
…lo  que  no  nos  deja  dormir  por  la  noche  

RIESGOS  ATAJABLES   RIESGOS  NO  ATAJABLES  

RIESGOS ATAJABLES! SOLUCIONES!

El  equipo  (esMmación)  
Nº   Rol   Competencias  /  ExpectaMvas  
1   Analista   Cómodo  con  el  just-­‐in-­‐Mme  analysis.  
Le  gusta  probar  /  testear  el  proyecto.  
Cómodo  con  el  desarrollo  iteraMvo.  
2   Programadores   HTML5,  Unity,  XML.  
Unidad  de  testeo,  refactorización,  integración  conMnua  
0.5   Project  manager   Facilitador  de  las  comunicaciones  entre  equipos  
Reporte  de  status,  alcance  del  proyecto,  control  del  
presupuesto  
3   ArMstas   Photoshop  
Concept  Art,  Animador  
RecepMvo  a  las  críMcas  /  a  los  cambios  
¿Cómo  de  grande  es  este  proyecto?  
Entregado!  
Proceso  1   Proceso  2   Proceso  3  
~3  meses    1  semana    1  semana  

Esto  es  una  es1mación,  no  un  compromiso  

Planificación  de  esfuerzos  y  costes    
Entregado!  
Proceso  1   Proceso  2   Proceso  3  
~3  meses    1  semana    1  semana  
~3months    1  wk    1  wk  

7  personas,  3  ½  meses,  $50K  

   
 El  precio  debe  ser  coherente  con  el  mercado  
Definición  de  expectaMvas  (Trade-­‐off)  
Las  4  básicas  
OFF   ON  
Alcance  
OFF   ON  
Coste  
OFF   ON  
Tiempo  de  desarrollo  
OFF   ON  
Calidad  

Otros  temas  importantes  

OFF   ON  
Usabilidad  
OFF   ON  
Gráficos  
OFF   ON  
Innovación  
OFF   ON  
<otras>  
Scrum  (2)  
 Scrum  (3)  

Autor:  Dr  Ian    Mitchel.  Fuente:  h[ps://en.wikipedia.org/wiki/Scrum_(souware_development)#/media/File:Scrum_Framework.png  

   
Scrum  (4)  
 Scrum  (5)  -­‐  Trello  

Fuente:  h[p://saascribe.com/wp-­‐content/uploads/2015/03/CXO-­‐Items-­‐Trello.png  
Para  saber  más  de  este  tema  
•  h[p://agilewarrior.wordpress.com  
•  Scrum  Primer  2.0:
h[p://www.scrumprimer.org/scrumprimer20.pdf  
•  Agile  manifesto  
h[p://agilemanifesto.org  
h[p://agilemanifesto.org/principles.html  
h[p://en.wikipedia.org/wiki/Agile_souware_development  
•  Jonathan  Rasmusson.  The  Agile  Samurai