Durante los últimos años es cada vez mas habitual ,y aceptado como buena practica, el uso de SCRUM como metodología de organización de equipos de desarrollo de software.
Nosotros, en la fundación Symbian, usamos SCRUM en el equipo que genera los “kits” de desarrollo como el pdk. Por esta razón, recientemente he estado reflexionando sobre cual es la mejor metodología de dirección de equipos y proyectos si estas trabajando con plataformas Symbian.
Diseñado para el cambio
En mi opinión, una de las ventajas principales de SCRUM, sobre el método mas tradicional de “waterfall” (cascada), en la capacidad de reaccionar y acomodarse eficientemente al cambio.
La capacidad para el cambio de prioridades de trabajo es una de las directivas principales de SCRUM, en comparación con la lenta reacción y el alto coste de incorporación de cambios que se asocia típicamente con “warterfall”. Esto se convierte en una ventaja principal cuando se trabaja en un entorno que esta mas allá de nuestro control, como puede ser una comunidad de código abierto (open source).
Demostrando calidad continuada
El concepto SCRUM de un ritmo continuo para el desarrollo, integración y la validación de calidad ha sido incorporado dentro de la Fundación Symbian. Esto se refleja claramente en el plan de publicación de “kits” .
Por lo tanto, es más fácil sacar ventaja a las publicaciones de “kits” de Symbian y reaccionar a las contribuciones de la comunidad “open source” si se sigue un ritmo compatible con el de la Fundación Symbian (cada dos semanas).
Impacto de usar “waterfall”
No es imposible trabajar con las plataformas Symbian si usas una metodología “watefall” , pero si que hay un coste que se debe tener en cuenta.
Un equipo trabajando en “waterfall” es más propenso a no adaptar nuevas contribuciones de la comunidad frecuentemente, sino a mantener una configuración estable y solamente actualizarla cuando se vean forzados a ello. Esto crea un mayor coste de adopción de la nueva configuración y potencialmente puede llevar al equipo a una situación en la que se vean forzados a mantener ramas paralelas de código (o “fork“). Esto no tiene solamente como desventaja el incremento en el coste de mantenimiento, pero también reduce las posibilidades de colaboración con el resto de la comunidad.
Y tu que usas?
Si no os importa me gustaría entender ( de manera sencilla), que metodología usáis en vuestros equipos:
Victor Tuson Palau 