Prácticas Ágiles en entornos hostiles de desarrollo (Parte1)

1,055 views

Published on

Parte1: Mitos y Tendencias
De donde viene la complejidad en la ingeniería de software? / Por qué nos cuesta cambiar? / Complejidad, cambio e innovación.

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

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

No notes for slide
  • Motivación Frase de introducción... 5 Neal_Ford-Ceremony_vs_Essence-slides.pdf – Shortcut (Aquellos que no aprendan de la historia están condenados a repetirla Retos mentales, juegos Unir 9 puntos Escencial vs Ceremony Hemos hecho complejo el problema 5 Neal_Ford-Ceremony_vs_Essence-slides.pdf
  • Turkeys are incredibly stupid. If you want to catch a turkey, you put a leg in front of them. They turn around to go the other way. Put your other leg in front of their new direction. The turkey will just give up and sit down. “That’s it. Game over. I’m surrounded.” Programmers aren’t stupid (not as a rule, anyway). I can’t count the times I’ve said something like, “If you write automated tests, you’ll get more done every day.” “But we have too much to do. We don’t have time to write tests.” “No, no. You didn’t understand. You’ll get more done, not less.” “Yes, but we don’t have time for testing.” Now I don’t want to go on record as comparing programmers to turkeys, but the two stories do seem to have a suspiciously common thread. In both cases progress was possible, but in both cases the individual involved decided progress was impossible.
  • Lider o Seguidor renuente o reacio al CAMBIO. ReluctantLeaderReluctantFollower_KentBeck.pdf Zona de Conford
  • Lider o Seguidor renuente o reacio al CAMBIO. ReluctantLeaderReluctantFollower_KentBeck.pdf Zona de Conford
  • Lider o Seguidor renuente o reacio al CAMBIO. ReluctantLeaderReluctantFollower_KentBeck.pdf Zona de Conford
  • 1989 - Ooram: OO rol analysis Method. (precursor a UML) Inicio con BabyUML pero migró a Baby IDE porque estaba por fuera de la herencia de UML. BabyIDE: Es un entorno de desarrollo que permite visualizar cómo la aplicación utiliza el DCI. V1.0 BabyIDE: Construida sin aplicar el DCI, (código no legible). V2.0 BabyIDE: Aplicando DCI (claridad en el código)
  • Prácticas Ágiles en entornos hostiles de desarrollo (Parte1)

    1. 1. Prácticas Ágiles en entornos hostiles Parte 1: Complejidad y cambio Licenciado bajo: Creative Commons 2.5 Bogotá / Colombia Luis Raul Mulato [email_address]
    2. 2. Advertencia! <ul><li>Estos slides han sido elaborados como apoyo a una charla iniciada en Acis, como tal, reflejan muchas de mis opiniones, que fuera de contexto de la charla pueden ser mal interpretadas. No tienen la intención de documentar, detallar ó aclarar los temas mencionados, tan solo servir de apoyo en algunos aspectos relevantes al tema en cuestión. </li></ul>Luis M.
    3. 3. Agenda <ul><li>Motivación
    4. 4. Complejidad
    5. 5. Por qué nos cuesta cambiar?
    6. 6. Complejidad, cambio e innovación
    7. 7. Agilidad
    8. 8. Procesos Ágiles
    9. 9. Procesos y Prácticas Ágiles en el Ciclo de desarrollo </li></ul>
    10. 10. Aquellos que no aprendan de la historia están condenados a repetirla! Jorge Santayana, Filosofo Español
    11. 11. Tecnología Internet Web 2.0 Móviles Diseño Patrones Arquitectura Procesos Frameworks Componente Estándares Clientes Usuarios Stakeholders Gerentes de Proyectos Vendedores Propietarios Políticas Corporativas “Falta de Comunicación” “ Falta de Valores Comunes” Incompetencia Arrogancia Ego “Cultura de la culpa” Desarrollo de Software:
    12. 13. Si Ud le dice a la gente a donde ir, Pero no cómo llegar, Se sorprenderá con los resultados. General George S. Patton
    13. 14. Complejidad:
    14. 15. Complejidad <ul><li>Esencial: Inherente al problema. </li><ul><li>Si un usuario requiere un programa con 30 funcionalidades, éstas son esenciales y el programa debe cumplirlas. </li></ul></ul><ul><li>Accidental: Causada por la aproximación utilizada para resolver el problema. </li><ul><li>Bugs
    15. 16. Tecnologias/Frameworks
    16. 17. Relevancia
    17. 18. Clientes cambiantes
    18. 19. ... </li></ul></ul>Desde Aristoteles hasta Fred Brooks [2]
    19. 20. Complejidad <ul><li>El avance tecnológico y de procesos nos debería haber llevado a eliminar la Complejidad Accidental.
    20. 21. En los 80's Fred Brooks pensó que se iba a lograr con la masificación los lenguajes de alto nivel (ej: Fortran,C,...)
    21. 22. Siempre encontramos mejores formas de hacer Complicado lo que ya era simple. </li><ul><li>HTML: XML, XHTML, CSS, JavaScript, Flash, Java, VB, Ajax </li></ul></ul>
    22. 23. Pequeños errores impactan todo el sistema.
    23. 24. Complejidad <ul><li>Mitos y realidades: </li><ul><li>Ley de Brook: Adicionar mayor fuerza de trabajo a un proyecto atrasado solo hará que se atrase aún más.(The Mythical Man-Month, 1975) </li></ul><li>Los mitos de mí generación (1980-2000): </li><ul><li>Programación estructurada vs Programación OO.
    24. 25. Código Nativo vs Virtual Machines
    25. 26. Lenguajes interpretados vs Lenguajes Compilados
    26. 27. ... </li></ul></ul>
    27. 28. Complejidad <ul><li>Mitos y realidades: (2000-2010,...) </li><ul><li>Procesos Predictivos (RUP) vs Procesos Adaptativos (Ágiles)
    28. 29. Proyectos con pruebas unitarias son más costosos y no tenemos tiempo de hacerlo.
    29. 30. Generación automática de versiones? Eso aquí no es posible, no tenemos tiempo. Eso lo hace el líder en 2 minutos.
    30. 31. Aquí todos seguimos los estándares.
    31. 32. ... </li></ul></ul>
    32. 33. Por qué nos cuesta cambiar? <ul><li>El Mito del Cambio constante: </li><ul><li>El cambio no “es bueno”?
    33. 34. Cambiamos o trabajamos?
    34. 35. Es necesario asumir el cambio como un rio a su cauce: “Adaptándose a las rocas pero siempre fluyendo cuesta abajo.”
    35. 36. Queremos participar, queremos colaborar, pero no queremos ser los “responsables a cargo” .
    36. 37. Agile:Equipos auto-gestionados (liderazgo de equipo) </li></ul></ul>Reluctant Leader, Reluctant Follower, Kent Beck [4]
    37. 38. Por qué nos cuesta cambiar? <ul><li>La Zona de Confort/Seguridad: </li></ul>Reluctant Leader, Reluctant Follower, Kent Beck [3] Seguridad Confort Aprendizaje Confort Aprendizaje
    38. 39. Por qué nos cuesta cambiar? <ul><li>La Zona de Confort/Seguridad: </li><ul><li>Cuando la zona de seguridad está muy cerca a la zona de confort, no es posible el aprendizaje, el cambio ó el liderazgo.
    39. 40. El líder puede aprender tan rápido como sus seguidores lo hagan. Cuando la zona de seguridad de los seguidores es muy pequeña no es posible avanzar.
    40. 41. Tanto el líder como los seguidores deben crear espacios en la zona de seguridad antes de cualquier aprendizaje. </li></ul></ul>
    41. 42. Complejidad, Cambio e Innovación Curva de Adopción de la Innovación [4] Trying to convince the mass of a new idea is useless. Convince innovators and early adopters first.
    42. 43. S-Shapen Adoption Curve Complejidad, Cambio e Innovación
    43. 44. Complejidad, Cambio e Innovación
    44. 45. Complejidad, Cambio e Innovación <ul><li>Retrospectiva: </li><ul><li>La Complejidad (accidental) es causada por la aproximación utilizada para resolver el problema.
    45. 46. Las “modas” aumentan la Complejidad (accidental)
    46. 47. Solo cuando ampliamos la zona de seguridad es posible el aprendizaje, el cambio y el liderazgo.
    47. 48. Responsabilidad compartida (equipo, GP, cliente,...)
    48. 49. La velocidad en la adaptación al cambio (tecnológico), la calidad y la innovación son la tendencia predominante en las empresas de éxito (ej: Google, Facebook, Amazon,..). </li></ul></ul>
    49. 50. Preguntas?
    50. 51. Recursos Artículos: <ul><li>[1] Fred Brooks: The Mythical Man-Month (1975)
    51. 52. [2] Fred Brooks: No Silver Bullet - Essence and Accidents of Software Engineering (1986)
    52. 53. [3] Kent Beck, Reluctant Leader Reluctant Follower (2000)
    53. 54. [4] Rogers Adoption Innovation Curve http://suewaters.wikispaces.com/Rogers </li></ul>Recursos Gráficos: <ul><li>Atomic: http://ifoton.com/wp-content/uploads/2009/11/bomba-atomica-licorne.jpg
    54. 55. Magic Lamp: http://www.flickr.com/photos/30459150@N07/4255300330/
    55. 56. Containers: http://koti.kapsi.fi/anpurola/temp/1184318230469.jpg
    56. 57. Pregunta: http://www.flickr.com/photos/pimkie_fotos/2759061117/ </li></ul>
    57. 58. GRACIAS! Luis R. Mulato [email_address] <ul><li>Scrum Master
    58. 59. Agile Coach, ALM Coach
    59. 60. M.Sc Ingenieria de Sistemas / Construcción de Software. </li></ul>Ver más información en: http://www.slideshare.net/group/agile-practices Licenciado bajo: Creative Commons 2.5 Bogotá / Colombia

    ×