Nuestra otra historia_de_waterfall_a_kanban_ - resumen

1,599 views

Published on

Esquema/resumen de la charla en AgileCyL en enero de 2012: http://agilecyl.org/2012/01/19/nuestra-otra-historia-de-waterfall-a-kanban-pasando-por-scrum/ . No es una documentación, sólo un guión, ¡así que si quieres saber más tendrás que contactar conmigo!

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,599
On SlideShare
0
From Embeds
0
Number of Embeds
333
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Nuestra otra historia_de_waterfall_a_kanban_ - resumen

  1. 1. N UESTRA ( OTRA ) HISTORIA DE W ATERFALL A K ANBAN PASANDO POR S CRUM G RANDES É XITOS ( Y F RACASOS)
  2. 2. Q UIENES SOMOS : JUANIGNACIOSL <ul><li>.:.: www.juanignaciosl.com ~ @juanignaciosl :.:. </li></ul>
  3. 3. Q UIENES SOMOS : L UCE IT .:.: www.luceit.com ~ @luceit ~ @lucemobility :.:.
  4. 4. Disclaimer <ul><li>Esta presentación es un esquemático resumen de la utilizada en la jornada en AgileCyL , así que no esperes claridad :_) </li></ul><ul><li>… pero … </li></ul><ul><li>¡Contacta con nosotros para lo que quieras! </li></ul><ul><li>[email_address] </li></ul><ul><li>[email_address] </li></ul>
  5. 5. S CRUM @ Luce IT '09 L A E DAD DE LA I NOCENCIA
  6. 6. S CRUM @ Luce IT <ul><li>Referencias (sin orden ni concierto) </li></ul><ul><li>  </li></ul><ul><ul><li>Manifiesto ágil </li></ul></ul><ul><ul><li>The Mythical Man-Month (Brooks) </li></ul></ul><ul><ul><li>Peopleware </li></ul></ul><ul><ul><li>Facts and Fallacies of Software Engineering </li></ul></ul><ul><ul><li>Scrum and XP from the Trenches </li></ul></ul>
  7. 7. S CRUM @ Luce IT <ul><ul><li>Qué hicimos: </li></ul></ul><ul><ul><li>Establecimos Scrum como metodología en el departamento de producción </li></ul></ul><ul><ul><li>Implantamos unas herramientas de trabajo básicas </li></ul></ul><ul><ul><li>Abordamos la formación </li></ul></ul>
  8. 8. S CRUM @ Luce IT <ul><ul><li>Qué aprendimos: </li></ul></ul><ul><ul><li>Las herramientas no son (tan) importantes  </li></ul></ul><ul><ul><li>Estimar en tiempo no es una buena idea </li></ul></ul><ul><ul><li>Trac no es una buena herramienta corporativa. Orientada a un proyecto </li></ul></ul><ul><ul><li>Sprint Review, como cualquier otra reunión, requiere dinámicas, no basta con un &quot;orden del día&quot; </li></ul></ul><ul><ul><li>¡Implantar TDD requiere MUCHÍSIMO más que una diapositiva!  </li></ul></ul><ul><ul><li>¡&quot;No tener miedo a refactorizar&quot; requiere MUCHÍSIMO más que una diapositiva!  </li></ul></ul><ul><ul><li>Comentar el código no es una idea tan buena  </li></ul></ul>
  9. 9. S CRUM @ Luce IT <ul><li>Conclusiones: </li></ul><ul><ul><li>No hay que buscar equivalencias entre roles &quot;tradicionales&quot; y &quot;ágiles&quot; </li></ul></ul><ul><ul><li>Ágil es hacer pocas cosas, pero no son sencillas de hacer y son fáciles de olvidar </li></ul></ul><ul><ul><li>La responsabilidad compartida no es responsabilidad. Necesario delimitar claramente roles y funciones </li></ul></ul><ul><ul><li>  Empower the team! </li></ul></ul><ul><ul><li>El PO es el eslabón más débil </li></ul></ul>
  10. 10. M ETODOLOGÍA C ORPORATIVA 2.0 '11 E STA V EZ S ERÁ P ERFECTO
  11. 11. M ETODOLOGÍA C ORPORATIVA 2.0 <ul><li>Referencias (estas tampoco están ordenadas): </li></ul><ul><li>  </li></ul><ul><ul><li>Kanban vs. Scrum - A Practical Guide, Henrik Kniberg </li></ul></ul><ul><ul><li>Kanban and Scrum - making the most of both, Henrik Kniberg & Mattias Skarin </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Agile Estimating and Planning </li></ul></ul><ul><ul><li>Agile Retrospectives </li></ul></ul><ul><ul><li>Scrum and XP from the Trenches </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Clean Code - A Handbook of Agile Software Craftmanship </li></ul></ul><ul><ul><li>Refactoring, Martin Fowler </li></ul></ul><ul><ul><li>Implementation Patterns, Kent Beck </li></ul></ul><ul><ul><li>The Pragmatic Programmer </li></ul></ul>
  12. 12. <ul><ul><li>Qué hicimos: </li></ul></ul><ul><ul><li>Implicamos (mucho) más a toda la organización </li></ul></ul><ul><ul><li>Generalizamos nuestro proceso hacia Kanban/Scrumban </li></ul></ul><ul><ul><li>Perseguimos visualizar al máximo </li></ul></ul><ul><ul><li>Comenzamos a abordar el problem solving </li></ul></ul><ul><ul><li>Dimos herramientas al equipo (“empower”, ¿recuerdas?) para gestionar mejor las (supuestas) urgencias y “bombas” </li></ul></ul>M ETODOLOGÍA C ORPORATIVA 2.0
  13. 13. M ETODOLOGÍA C ORPORATIVA 2.0 <ul><ul><li>Qué aprendimos: </li></ul></ul><ul><ul><li>Ojo con columnas del Kanban que no aportan nada  </li></ul></ul><ul><ul><li>Tabla de proyectos física: ¿para qué? ¿responsabilidad de quién? </li></ul></ul><ul><ul><li>Parar para arreglar no asegura arreglar nada </li></ul></ul>
  14. 14. L UCE IT - M ETODOLOGÍA 2012 ¡S IGAMOS MEJORANDO !
  15. 15. L UCE IT - M ETODOLOGÍA 2012 <ul><li>Referencias (no íbamos a ordenar las últimas): </li></ul><ul><li>  </li></ul><ul><ul><li>TDD by Example, Kent Beck </li></ul></ul><ul><ul><li>Growth Object Oriented Software Guided by Tests </li></ul></ul><ul><li>  </li></ul><ul><ul><li>The Toyota Way  </li></ul></ul><ul><ul><li>The Art of Lean Software Development </li></ul></ul><ul><li>  </li></ul><ul><ul><li>... y volver al Manifiesto Ágil </li></ul></ul><ul><li>  </li></ul>
  16. 16. L UCE IT - M ETODOLOGÍA 2012 <ul><li>Lo que no habíamos contado... </li></ul><ul><li>  </li></ul><ul><li>  ¡Somos débiles/personas! </li></ul><ul><ul><li>No sabemos decir no </li></ul></ul><ul><ul><li>Nos sentimos cómodos con excusas </li></ul></ul><ul><ul><li>Cedemos a la presión de los plazos </li></ul></ul><ul><ul><li>No nos gusta probar </li></ul></ul><ul><ul><li>Ni estamos cómodos tocando código existente </li></ul></ul><ul><ul><li>Queremos que nos solucionen problemas </li></ul></ul><ul><ul><ul><li>(no hacerlos desaparecer) </li></ul></ul></ul><ul><ul><li>La culpa es siempre de los otros  </li></ul></ul><ul><li>  </li></ul><ul><li>... y este año nuestro objetivo es pulir el proceso </li></ul><ul><li>para que nos ayude a superar estas debilidades </li></ul>
  17. 17. L UCE IT - M ETODOLOGÍA 2012 <ul><li>Qué tenemos preparado: </li></ul><ul><li>  </li></ul><ul><li>Eliminar waste de la metodología </li></ul><ul><li>Fundamentar la formación en senseis </li></ul><ul><li>Mejora continua mediante PDCA y 5 medidas S.M.A.R.T. </li></ul><ul><li>Mejorar el S2F (“Stop To Fix”) </li></ul><ul><li>Test, test, test. Testability. Testing. </li></ul>
  18. 18. L UCE IT - M ETODOLOGÍA 2013 ¡S IGAMOS MEJORANDO !
  19. 19. L UCE IT - M ETODOLOGÍA 2014 ¡S IGAMOS MEJORANDO !
  20. 20.
  21. 21. L UCE IT - M ETODOLOGÍA 2099 ¡S IGAMOS MEJORANDO !
  22. 22. Nuestra historia… <ul><li>Conclusiones: </li></ul><ul><ul><li>La clave es el equipo. Empower the team! </li></ul></ul><ul><ul><li>No hay bala de plata , pero Agile es el camino </li></ul></ul><ul><ul><li>¡No te excuses! ¡Hazlo! ¡Experimenta! </li></ul></ul><ul><ul><li>¡Ten siempre presente los grandes principios! </li></ul></ul><ul><ul><ul><li>Simplifica </li></ul></ul></ul><ul><ul><ul><li>Visualiza </li></ul></ul></ul><ul><ul><ul><li>Automatiza </li></ul></ul></ul><ul><ul><ul><li>Code smells </li></ul></ul></ul><ul><ul><ul><li>Prueba (y diseña para ello) </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul>

×