Patrocinado por docxpresso.com

Modelo de contrato
para desarrollo informático

Envía tu curriculum
y te avisamos cuando se descarga

Propuesta de desarrollo
para web coporativa

Portada > Artículo | 13-03-2010 - Cesar Martin

Scrum aplicado

Resumen: Una de las mejores ideas del Drupal Camp 2010 fue el ver la exposición sobre Scrum (Scrum significa melé de rugby en inglés). El Scrum es una metodología de trabajo que quita algunas ideas viejas sobre como hacer funcionar una empresa. En César y Justina aplicamos esta metodología y te contamos como lo hacemos.

Valoración media: 2,90 | Votos: 3148 | Lecturas: 21947

Simplifica

Las estructuras predefinidas de las empresas han de cambiar. Los departamentos y la estructura departamental ha de cambiar.

El equipo ha de estar unido en torno al cliente / producto / servicio. No tiene sentido que un cliente reciba comunicaciones de marketing que los de sistemas desconocen y que no se han aplicado o que los requisitos de la gente de producto sean una amenaza para los de operaciones y que las guerras internas entre departamentos pongan en riesgo desarrollos que tienen como objetivo hacer que la empresa sea mejor y que los clientes estén mejor atendidos.

Este concepto de "departamentos" que acaban generando reinados de taifas dentro de las empresas ha de cambiar. Los equipos de trabajo han de estar enfocados a generar una solución para el cliente. Cualquier otro foco (mis objetivos, mis resultados, mis...) hace que la empresa pierda energías en procesos internos que el cliente le son totalmente ajenos.

¿Qué sentido tienen los departamentos?

Esta claro que hay departamentos que tienen que existir y que pueden ser "independientes" al core de la empresa. Pero todos aquellos que tengan que ver con el "core" del negocio, tienen que estar unidos y trabajar como un equipo. El concepto de Scrum viene un poco de esa idea de melé de jugadores del rugby. Como una piña. Juntar las manos y decir "team work" no es suficiente. O estamos unidos o perdemos.

Equipo

Cuando se juzga un trabajo, no se juzga a las personas, se juzga al equipo. Si el equipo lo hace mal, el equipo tiene que solucionarlo. No hay que buscar a los culpables de los problemas por departamentos (en programación o en contenidos o en diseño). Si el producto falla, el equipo es culpable.

Evidentemente no se pide a un programador que diseñe o un diseñador que escriba, pero si se pide a todo el equipo que sea responsable del producto en su conjunto. No vale eso de "yo solo programo" o "yo solo diseño". Cada persona que se integra en el equipo ha de velar por el producto en su conjunto y es responsabilidad de todos que el producto salga bien.

Esto no es fácil y lleva tiempo, formación, pero es vital. Ya no vale el programador que solo programa o el diseñador que solo diseña. Todos han de tener en su visión el producto y el cliente.

Entregables y producción

Lo normal hoy en día es el típico documento de especificaciones donde se detalla todo lo que se necesita al detalle y cualquier cambio sobre ese documento genera reuniones y revisiones y nuevos plazos...

Este proceso lo hemos eliminado. Partimos de la idea que hay cambios y que esos cambios han de estar enfocados en la mejora del producto y en conseguri mejores resultados. Partimos de la idea que se definen unos mínismo pero no hay máximos.

Por lo general no hay objetivos o público objetivo. Hay metas. Esas metas suelen ser entregas. Esas entregas son productos reales que se pueden utilizar. No papeles.

Esos productos reales deben responder a unos criterios mínimos, pero los máximos están por definir y son cambiantes. El producto se ha de modificar, adaptar y crecer para acometer nuevos requisitos. Es parte del ciclo de vida del diseño.

Eso exige que el producto esté sujeto a una constante evolución y mejora. No hay entrega final. No hay documentación. La aplicación tiene que ser fácil de utilizar, estandar y compatible.

Este cambio de mentalidad es importante porque se adapta a la realidad del cliente. El cliente muchas veces desconoce las implicaciones de sus deciones y no podemos hacerle pagar por una decisión tomada sin tener toda la información. Es mejor acompañar al cliente y asesorarle de forma proactiva.

Las reuniones breves y operativas. Pero mejor, evítalas a toda costa

Como organizar reuniones operativas.

  1. Haz reuniones para resolver cosas. No para presentar cosas.
  2. Envía todo lo que se vaya a tratar en la reunión por adelantado. Exige más trabajo, pero es necesario.
  3. En las reuniones ten conexión a internet y en lo posible corrige los documentos que puedas en ese mismo momento.
  4. Lleva un acta predefinida y tan solo escribe las conclusiones. Este documento debe estar a la vista de todo el mundo y todo el mundo debe estar de acuerdo con lo que pone antes de salir de la sala.
  5. En lo posible que la gente lleve un ordenador, no una libreta.

La comunicación tiene que ser más ágil. El correo es la vida. Los correos tienen que ser la herramienta. Hay que fomentar la seguridad en el equipo delegando y evitando el comité para decisiones que deben ser tomadas por cada uno. Evidentemente llegar a este punto requiere ajuste y formación, pero es necesario que el equipo sea autónomo el 80% del tiempo.

Scrum no es serio. No sirve para una gran empresa

Por lo general ante este tipo de filosofía, el rechazo suele ser frontal. No puede ser, no es posible. Pero esta filosofía de trabajo fue la que se aplicó en Japón y que dio lugar a su desarrollo en los 80-90. No estamos aplicando nada nuevo. Estamos aplicando una metodología ya probado y que en la vieja Europa es más necesaria que nunca.

La vieja Europa lleva mucho tiempo sin pensar y sin renovar estructuras. Ahora toca. Toca definir empresas, procesos y metodología. Si queremos salir de esta, el cambio es necesario. No vamos a salir de esta volviendo a hacer lo mismo de la misma forma.

No es estrictamente Scrum

Lo comentado en este artículo no es estrictamente Scrum pero es la filosofía de César y Justina y al escuchar la metodología de Scrum vimos muchos puntos en común.

Contenido sobre Scrum en Google.

Puntúa este artículo 1 punto 2 puntos 3 puntos 4 puntos 5 puntos


Artículos más leidos en Alzado.org

Qué es un problema. Metodología para el diseño

Bájate estos documentos ejemplo de propuesta web

Philip Kotler: los 10 principios del Nuevo Marketing

Fuentes, tipos de letra y recursos tipográficos


© Alzado.org | Algunos derechos reservados. Licencia Creative Commons