Hubo muchas conclusiones potenciales cuando aprendí Agile e intenté ponerlo en práctica, pero solo había una pareja que parecía realmente relevante para mi trabajo y lo que estaba tratando de hacer con mi equipo de desarrollo.
- Para cada ciclo de desarrollo, debe haber un acuerdo sólido entre el equipo de desarrollo y las partes interesadas del producto en términos de la duración del ciclo de desarrollo y el conjunto de características para el ciclo de desarrollo. Por lo tanto, desde el lado del producto / negocio, no hay arrastre de características y desde el lado del desarrollo, no hay arrastre de programación. Esos dos generalmente están interrelacionados. Pero desde mi experiencia previa, no mantener esos dos elementos fijos a menudo conduce a una difusión de la responsabilidad para ambas partes. Para mí, esta fue una gran idea de Agile.
- El ciclo de desarrollo debe ser lo suficientemente corto como para que la regla 1 sea viable. Para el producto / negocio, esto significa que si bien es posible que no puedan cambiar el conjunto de características de inmediato (ver la regla 1) porque el ciclo es corto, habrá una oportunidad de cambiarlo pronto (es decir, al final del ciclo actual). Desde la perspectiva del desarrollo, la estimación LOE es difícil. Un ciclo corto fuerza el esfuerzo de desarrollo en partes más pequeñas, lo que facilita la estimación precisa. Y los errores en la estimación son más fáciles de recuperar en un ciclo corto que en uno largo.
Habiendo dicho todo eso, es fácil ver por qué las personas recurren a frases como cuasiagil . La metodología Agile completa tiene mucho y, francamente, no todo es apropiado para cada tipo de esfuerzo de desarrollo. La mayor parte de nuestro desarrollo inicial fue móvil, y con el nivel de control de calidad requerido y el potencial proceso de aprobación de la tienda de aplicaciones, el ciclo de desarrollo ágil súper corto simplemente no funcionó para nosotros. En el último año, hemos estado haciendo mucho más desarrollo web y en esos esfuerzos, el ciclo más corto ha sido mucho más apropiado. Creo que muchos equipos están adaptando la metodología para que funcione para sus situaciones, por lo que supongo que muchos de ellos no se considerarían puramente ágiles.
- ¿Vale la pena invertir tiempo en una startup de origami?
- ¿Cuándo no deberían las startups con licencia completa comenzar a contactar proveedores y clientes potenciales?
- Cómo elegir un mercado de productos adecuado cuando tiene múltiples vías
- ¿Por qué falló Sonar?
- ¿Cómo fue el primer año de Behance?