Agile software development antipatterns
•Descargar como PPTX, PDF•
5 recomendaciones•771 vistas
Presentación Agiles 2015
Recomendados
Más contenido relacionado
Similar a Agile software development antipatterns
Similar a Agile software development antipatterns (20)
Más de Federico Zuppa
Último
Último (20)
Agile software development antipatterns
- 1. agile software development & services Enterprise Agile Antipatterns Octubre 2015 @fzuppa o porque Agile falla en grandes organizaciones
- 2. La historia del manager que no quería Agile
- 3. Cual es la razón de que pasen las cosas?
- 4. COMPLEXITY
- 5. Disclaimer Cuan grande es tu problema?
- 7. El peso de la Metodología • Tamaño del problema • Criticidad • Precisión y exactitud
- 8. Peso de las metodología
- 10. Antipattern #1 Subequipos de diferentes organizaciones La historia del QA que solo quería comunicarse a través de Rally
- 11. Un Juego Cooperativo de Invención y Cooperación Cooperative & Goal Seeking Load Bearing Team Individuals with Talent Skill-sensitive Training Tools Resource Limited Plan Improvised Fun Challenging Dangerous
- 12. Antipattern #2 Objetivos desalineados Y que quería reportar todo también!
- 13. The Architecture Team Antipattern #3 La historia del equipo que no hizo tests automátizados
- 14. Pyramids Inside the Team Antipattern #4 No me preguntes a mi, preguntale a mi jefe!
- 15. Pyramids Inside the Team Antipattern #5 Reuniones con mucha gente (chickens!)
- 16. Miembros asignados % de tiempo Antipattern #6 La historia del QA que desaparecía
- 17. Entrenamiento inadecuado Antipattern #7 La historia del release plan
- 18. A tener más en cuenta…
- 19. Cual es la cultura de la organización
- 22. agile software development & services Preguntas
Notas del editor
- El objetivo de mi charla es contarles anecdotas extraídas de diferentes transiciones agiles en las que he colaborado en grandes organizaciones con grandes proyectos y grandes equipos! Cual es el tamaño de su equipo? Estas anecdotas por supuesto que las cuento desde mi punto de vista y desde mi expertise, que no tiene que ver con organizaciones, sino con desarrollo de software. Yo me especializo en cochear equipos cuando están empezando a trabajar con Scrum/XP/Kanban, ayudándoles a crear el backlog y en la ejecución del proyecto … En todas estas anecdotas identifiqué un síntoma. Un problema puntual que teníamos como equipo y que por supuesto, en su momento, nos llevo a grandes discusiones. En todas situaciones en particular, creo que existían razones más profundas, más estructurales que la complejidad, y después vamos a volver sobre este termino, escondía.
- Creo que el punto de este manager, viéndolo en retrospectiva, es que quería alejarse de la complejidad inherente que significaba desarrollar un proyecto dentro de su organización. Quería hacer este proyecto en un ambiente prístino, alejado de la politica y las políticas de su organización, evitando la burocracia. Dps. de haber participado en algunas transformaciones ágiles lo entiendo mejor.
- Porq les cuento esto? Simplemente para introducirlos en el tópico de la complejidad y de su importancia dentro de las organizaciones. Las organizaciones son sistemas complejos, donde cientos/miles de agentes inteligentes interactuan entre si para que la solución emerja.
- Obviamente cuando hablamos de empresas grandes, hablamos de problemas grandes, de equipos grandes. Uno de los conceptos que mas quedó del libro de Alistair Cockburn es el de peso de la metodología.
- Como definen la metodología? La definición q da Alistair es ‘All the shit we do to take the software out there’. Una metodología liviana es una metodología que tiene un número bajo de elementos de control (deliverables, standards, metricas de calidad) y baja ceremonia. Alistair Cockburn sugiere que la metodología debería ser liviana, tan liviana como el problema en cuestión lo necesite. jim Highsmith sugiere que la metodología debe ser ‘barely sufficient, a little bit less than just enough”
- Cuan grande es la ‘metodología’ depende de varios factores, que incluyen la precisión que necesitamos, la magnitud del problema que queremos resolver, la gravedad de cometer errores, etc.
- Les cuento porque me parece que no es un buena idea que existan estas situaciones: No es una buena idea simplemente porque yo quiero construir un equipo, es decir un grupo de personas que compartan un mismo objetivo y colaboren entre si en pos de lograrlo.
- Cooperativo y en búsqueda de un objetivo: Un equipo de escaladores de rocas trabajan juntos para lograr el objetivo. La medida primaria de éxito es haber alcanzado la cima Soportar carga: Los escaladores tienen que soportar su peso en sus manos y sus pies Equipo: Escalamiento en gral. se hacen en equipos. - Los escaladores en gral. necesitan cierta proficiencia. Escaladores novatos pueden subir solo ciertas cumbres
- Cuando trabajamos en sistemas complejos, debemos intentar entender las influencias que generamos en nuestra sistema. Cuando seseamos objetivos también. Los seres humanos, oh casuliadad, en gral. nos acomodamos para lograr nuestros objetivos y muchas veces, un objetivo mal pensado puede generar comportamientos disfuncionales que atentan contra el normal desarrollo del proyecto.
- Quizas es un poco fuerte.. quizas no. En realidad, el antipatron es depender de otras areas que no están alineadas con el proceso de nuestro equipo. Esto obviamente genera multiples problemas (blockers como los llamamos en Scrum).
- Creo que los mejores equipos son los equipos auto-organizados donde c/u intenta poner lo mejor de si para resolver el problema (es decir, para terminar con todas las stories)
- Gente que hace otras tareas dentro de la organización