SCRUM funciona mejor con la Fundación Symbian

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:

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: