Capítulo 14: DST Systems gana con Scrum y la administración del ciclo de vida de vida de las aplicaciones

Capítulo 14: DST Systems gana con Scrum y la administración del ciclo de vida de vida de las aplicaciones

1.    ¿Cuáles fueron algunos problemas con el viejo entorno de desarrollo de software de DST Systems?

Uno de los problemas más importantes que tenía DST Systems era el atraso en las actualizaciones de sus sustema AWD.

 Tener metodos antiguos en sus sistemas como el metodo de “cascada” para diseñar, codificar, evaluar e integrar sus productos atrasaba sus procesos por lo que tuvo que enfocarse en otras alternativas viables.

La manera en la que los empleados trabajaban porque no utilizaban las herramientas que la empresa tenia, usaban otros software como Serena PVCS, Eclipse y otros. Además, se hablaba de métodos manuales e incluso que involucraran papel para poder realizar sus actividades.

 Que el Scrum no funcionara tan bien para DST al inicio, producia colapsos en los procesos pero no por culpa de Scrum sino de DST porque no se dejó proveer del máximo beneficio para la compañía.

 El sistema tan aburrido y poco atractivo que tenían DST perjudicaba mucho sus actividades.

2¿Cómo ayudó el desarrollo Scrum a resolver algunos de estos problemas?

    La compañía aceleró su ciclo de desarrollo de software de 24 a 6 meses.

    Aumentó la productividad de los desarrolladores un 20%

1.       ¿Qué otros ajustes hizo DST para poder usar Scrum de una manera más efectiva en sus proyectos de software? ¿Con qué aspectos de administración y tecnología hubo que lidiar?

 Implementaron SRUMMASTER.

Desarrollo ágil de software donde los proyectos progresan a través de una serie de interacciones conocidas como “sprints”.

 Estableció un equipo de evaluación de proyectos para identificar el entorno de desarrollo apropiado.

   DST se decidiò por TeamForge, el ofrecimiento de CollabNet para su plataforma de ALM.

  DST adoptó el producto Subversión de CollabNet para que ayudara con la administración y el control de los cambios en los documentos, programas y demás información de los proyectos almacenada en forma de archivos.

    Buscó la simpleza en vez de los ofrecimientos complicados que se hacen cargo de todo.

  Involucró a los desarrolladores en el proceso de toma de decisiones.

Y con respecto a los aspectos de administración, organización y tecnología que hubo que lidiar fueron:

   No tenían almacén unificado para mantener ahí toda la información, lo que provocaba que el gerente no tuviera la información necesaria para la toma de decisiones.

   Los procesos eran manuales y consumían mucho tiempo.

  Para los encargados no era fácil determinar cómo se asignaban los recursos, que empleados trabajaban en ciertos proyectos o el estado de ciertos activos específicos.

  Necesitaban algo mejor que el método de “cascada” para diseñar, modificar, codificar y evaluar sus productos.

   Su programa común de desarrollo era liberar una nueva versión una vez cada dos años, pero los competidores estaban liberando versiones mucho antes que eso.