¿Utiliza SCRUM en una empresa que impone un gobierno estricto en el proceso de desarrollo?

Question

Nuestra empresa debe cumplir estrictos protocolos SOX/Cobit. Esto significa que hay un gran rastro de papel detrás de todo lo que hacemos, y nadie puede comenzar a codificar hasta que se haya cerrado la documentación correcta. Esto significa que debe esperar a que se hayan firmado las especificaciones de cambio, la especificación de software y los documentos de arquitectura (al menos) antes de poder comenzar a codificar. El mismo proceso sigue a cualquier mejora (que es una parte natural del desarrollo de software). Claramente esto no encaja bien con la idea detrás de SCRUM.

Actualmente seguimos el SDLC como se define en el Rational Unified Process (RUP). También abarca un proceso iterativo (Inception/Elaboration/Construction/Transition/Repeat), pero queremos tratar de reemplazar ese proceso con SCRUM.

¿Es factible que una empresa con un gobierno estricto cambie a SCRUM? ¿Alguien tiene un estudio de caso que muestra cómo se ha implementado con éxito en un entorno similar?

Answer 1

he trabajado para una empresa se tambalea al borde de la locura SOX, manteniendo un proceso de desarrollo bastante ágil. Tener gerentes bien informados que estuvieran dispuestos a trabajar en el papeleo ayudó mucho.Hicimos varias cosas para convencer a los auditores de SOX de que nuestros procesos electrónicos no solo eran sustitutos sino también mejores que su documentación.

• Hemos bloqueado el acceso al repositorio de código utilizando una característica especial de SSH para que sólo el administrador podría llegar a los archivos RAW. Esto evitó que los desarrolladores hicieran cualquier manipulación de repositorio panky para ocultar un cambio. Si bien no nos preocupaba que eso ocurriera, los auditores de SOX estaban contentos y aceptaron el sistema de control de versiones como un registro de cambios seguro en lugar de hacernos presentar diferencias (no bromas) en papel.

• Delegamos la mayoría de los trámites al departamento de control de calidad que solía realizar tareas repetitivas a mano. :)

• Se aumentó la seguridad en nuestro administrador de tareas en línea. Cada cambio tenía que tener una tarea asociada. Las tareas en nuestro administrador de tareas no pudieron ser trabajadas hasta que uno de un grupo de gerentes "cerró sesión" dentro del sistema. En la práctica, esto significó que un administrador de IMM marcara una casilla en un formulario web.

• Movimos la autoridad para llevar los cambios de la etapa de producción al departamento de control de calidad. Nuevamente, en la práctica, esto significa decirle a alguien en QA que ejecute un guión. Como efecto secundario, ayudó a que nuestro proceso de producción fuera mucho más rápido y simple.

• Mediante el uso de desarrollo, puesta en escena y las ramas de producción que podían trabajar libremente en las ramas de desarrollo y puesta en escena, ya que no tienen acceso a las bases de datos de producción, que sólo requiere todo el papeleo para estar en su lugar para los cambios que se alcanzó la producción.

Vale la pena señalar que, si bien hubo algunas cosas que hicimos debajo de la mesa para conseguir nuestros trabajos realizados, en su mayor parte hicimos la gente a cargo del cumplimiento de SOX saber cuánto de un impacto que estaba teniendo en hacer trabajo y trabajar con ellos para equilibrar su paranoia SOX y nuestra eficiencia. Descubrimos lo que realmente querían y ofrecimos alternativas más eficientes (como el control de versión segura en lugar de diffs de papel). En lugar de trabajar en torno a un sistema roto y crear un campo de batalla entre los desarrolladores y el control de calidad, trabajamos para mejorar el sistema.

Answer 2

He tenido éxito en proyectos en ese entorno haciendo las cosas de forma un poco más encubierta. En proyectos que manejaba, en entornos como este, por lo general trato de enganchar a un interno para usarlo a tiempo completo. El trabajo del pasante era completar toda la papelería y basura burocrática, dando la ilusión de que estábamos siguiendo un proceso, mientras que en el fondo mantenía a mis desarrolladores trabajando y avanzando en el proyecto. Internamente, utilicé una metodología estricta basada en scrum. Mis proyectos terminaron con una tasa de éxito del 100%, mientras que el promedio corporativo para proyectos exitosos fue alrededor del 20-30%.

Utilice mis opiniones desordenadas bajo su propio riesgo.

En cuanto al cumplimiento de SOx BS, ¿no lo han descartado aún?

Answer 3

no pude ver por qué cree que la documentación y el proceso formal no funcionan bien con el ágil.

Si sabe cómo hacerlo correctamente RUP es aún más fácil para que usted pueda hacer SCRUM, como usted ya tiene suficiente disciplina para ser ágil sin ser vaquero.

Nadie dijo que no se puede hacer la documentación adecuada cuando se hace SCRUM. Estos documentos DO agregan algo de valor, simplemente no son exactamente necesarios cuando se sigue un proceso ágil y por lo tanto, la mayoría del equipo no los hace.

Si considera que los documentos son sus entregables, agréguelos al alcance de la iteración, escriba cosas importantes para que sean útiles para su equipo; son una sobrecarga pero también tienen valor especialmente en un proyecto a largo plazo , o cuando tienes un equipo grande y/o distribuido.

Las iteraciones de RUP no imponen un modelo de cascada: son solo pautas para el énfasis en ciertas disciplinas dentro de ellas, pero una iteración adecuada en RUP tiene todas las actividades mezcladas. P. ej. Considere la fase de Elaboración como una fase Agile normal con algunos picos y no podrá notar la diferencia.

La forma en que trabajó para nosotros con los documentos era utilizar Wiki para información como esta y exportar su contenido a los archivos de Word que podría ser firmados más tarde fuera.

Los documentos podrían pasar la revisión, pero no tienen que ser mantenidos y el equipo vaya a Wiki para su información.