Metodología Ágil – SCRUM (Proyecto de fundamentación – Parte V)

• ESTADO DEL ARTE

Desde la concepción de la idea de hacer equipos de desarrollo más ágiles y que tuvieran una retroalimentación durante ciertos lapsos de tiempo hasta la formalización del marco de trabajo, Scrum ha ido evolucionando en respuesta dinámica a las nuevas exigencias en los equipos de trabajo. Actualmente existen más de dos mil ScrumMasters certificados y la metodología ágil Scrum ha ayudado a miles de proyectos exitosamente., lo que ha permitido tener una visión de lo que puede aportar Scrum en actividades futuras. [7]

Una de las principales influencias que provocaron la creación del proceso de desarrollo Agile Scrum fue un documento de Harvard Business Review en el desarrollo de nuevos productos japoneses por Takeuchi y Nonaka [1]. Un componente clave de su presentación era un gráfico que muestra el desarrollo de productos en ciclos separados de trabajo (Tipo A), las fases se superponen ligeramente (Tipo B), y todas las fases de desarrollo se superponen (Tipo C). [7]

Takeuchi y Nonaka vieron el desarrollo del producto Tipo A tal como se aplica en la NASA como un proceso carrera de relevos anticuada. Fuji- Xerox abandonó el enfoque de la NASA para el tipo B que llamó “Sashimi” porque rebanadas de trabajo se superponen con la colaboración entre las fases. El Tipo C se llevó a cabo en el Canon y Honda. Takeuchi y Nonaka previeron Tipos B y C como un enfoque de Rugby donde múltiples fases de desarrollo de productos se realizan simultáneamente. Scrum es una formación de Rugby y se considera un proceso de “all- at-once ” lo más parecido a un equipo de rugby se extiende hacia el campo de pasar el balón hacia atrás y adelante. [7]

Después se discutieron los distintos tipos de Scrum con ScrumMasters certificados en talleres de la Scrum Alliance y con equipos de desarrollo de Microsoft, Yahoo, Ariba, Adobe, GE Healthcare, y otras empresas, y se llegó al consenso de que se puede aplicar a un mayor nivel que solo los tres tipos de Scrum descritos anteriormente.

En el Scrum tipo A, todo el desarrollo se produce en un incremento en el cuadro de tiempo de la iteración de Scrum llamada Sprint. La desventaja de este tipo de Scrum es el tiempo de inactividad entre las iteraciones cuando se reorganiza para el próximo Sprint. Sin embargo, si los Sprints son bien ejecutados pueden duplicar la productividad y ofrecer varias ocasiones los proyectos a tiempo, dentro del presupuesto, con la funcionalidad de un objetivo preciso a las demandas de los usuarios finales .

Agregando la definición de las tareas de los productos para el próximo Sprint en el Sprint actual, el sprint del tipo B permite que el trabajo fluya sin problemas de un Sprint a otro Sprint. Los requerimientos pendientes para el próxima Sprint se desarrollan en el Sprint actual. Esto ha permitido a algunas organizaciones de desarrollo ofrecer más trabajo de productos que ventas, marketing. De esta forma el cuello de botella de desarrollo es eliminado y la empresa puede adoptar nuevas estrategias y crear nuevos productos que antes eran imposibles de entregar.

El Sprint del Tipo C puede ser concebido como la superposición de Sprints ejecutando versiones de software a través del mismo equipo Scrum y al mismo tiempo. Esto requiere equipos Scrum experimentados, arquitectura de producto bien diseñada, y la automatización de productos y Sprints pendientes. El rendimiento puede ser mejorado para ofrecer decenas de nuevas versiones de software de la empresa anualmente. Los competidores pueden sentirse abrumados y dominio del mercado alcanzados.

Takeuchi y Nonaka observaron que colapsar las fases de desarrollo del producto mejora la innovación, el rendimiento, el tiempo de salida al mercado y la aceptación del producto. Como las presiones del mercado han evolucionado y cambiado, es posible colapsar Sprints Scrum para crear un dramático aumento en las oportunidades de negocios. [7]