¿Qué herramientas y técnicas deben introducirse primero al comenzar con Agile/Scrum?

Scrum es probablemente el más difícil de implementar desde cero. Esto es lo que sugeriría:

Primera Fase: Preparación

1) Dedique algún tiempo a preparar y priorizar su cartera de pedidos. La clave aquí es dividir los elementos de la cartera de pedidos en partes lo suficientemente pequeñas. La mayoría de los nuevos equipos de Scrum fallan temprano porque no pueden entregar el software al final de un sprint, y eso generalmente se debe a que sus elementos pendientes (historias de usuarios) son demasiado grandes.

2) Haga que su equipo lea sobre el proceso Scrum y repase con ellos el plan de implementación. Obtenga sus comentarios y sienta dónde está recibiendo rechazo. Hable con ellos sobre TDD / BDD .

Segunda Fase: Sprint 1

3) Configura tu primer sprint. Por lo general sugiero 3 semanas. Si después de 2 sprints, su equipo tiene dificultades para entregar software que funcione, acorte la duración de su sprint a 2 semanas . Esto lo obligará a dividir los elementos de su cartera de pedidos en partes más pequeñas. Aumentar la longitud del sprint suele ser un agujero negro del que nunca saldrás.

4) Implementar todas las reuniones requeridas, incluido el standup diario.

Tercera Fase: Automatización

5) Si aún no los tiene, ahora es el momento de configurar sus compilaciones de CI y trabajar en el flujo de trabajo diario de su desarrollador. Anímelos a usar el flujo obtener más reciente > compilar > código > compilar > obtener más reciente > compilar > registrar .

6) Si su proyecto aún no tiene extensas pruebas automatizadas, ahora es el momento de realmente comenzar a alentar su creación. Sus sprints serán más productivos y su código de trabajo será más "funcional" si puede lograr una buena cobertura de código para sus compilaciones de CI. Considere una política de registro que requiera un aumento en la cobertura del código para un registro exitoso. Esto se puede abandonar más adelante, una vez que todos estén acostumbrados a escribir pruebas unitarias para su nuevo código.

Si llega tan lejos y no ha tenido una revolución en sus manos, ahora puede comenzar a hablar sobre la configuración de implementaciones automatizadas, impulsar TDD/BDD, implementar una política de revisión de código y formalizar un proceso de entrada/retroalimentación con el propietario del producto. eso es mas continuo. La última parte puede ser bastante difícil. La mayoría de los equipos terminan con lo que llamamos Water-Scrum-Fall, donde los propietarios del producto actúan más como una cascada y solo quieren participar en los puntos inicial y final. Cuanto más en la organización pueda impulsar la agilidad, más beneficios verá.

En cuanto a las tecnologías, recomiendo TFS 2012. He escrito una descripción bastante decente de su potencia en stackoverflow aquí . En resumen, combina prácticamente todo lo que necesitará tanto del lado del PM como del lado del desarrollador bajo un mismo paraguas.

En una nota final: es posible hacer esto casi exactamente en el orden inverso, excepto para arreglar su trabajo pendiente (que casi siempre debería ser lo primero). Puede optar por concentrarse en desarrollar los hábitos diarios de los miembros de su equipo antes de implementar la estructura de Scrum. Haga que aumenten su cobertura de código con pruebas automatizadas, presente una compilación de CI y (con suerte) primero configure implementaciones automatizadas, luego cree la estructura de sprint en torno a eso. Hable con su equipo y vea cuál preferirían. Scrum tiene que ver con la entrega continua de valor lograda a través de la automatización y la comunicación continua. Obtenga la opinión de su equipo en todo momento, pero si recibe algún rechazo, es posible que deba imponer alguna estructura. Con suerte, después de algunos sprints, verán los beneficios.

Editar

Después de algunas discusiones con mis colegas, creo que dejé algo importante. Mencioné TDD/BDD, pero no enfaticé la importancia de integrar las pruebas en sus sprints. Debe incluir suficientes pruebas (unidad, integración, aceptación) dentro de sus sprints para garantizar que su software "en funcionamiento" realmente funcione y satisfaga las necesidades del propietario del producto. Descubrí que una de las formas más efectivas de lograr esto es a través de equipos multidimensionales. Ponga uno o dos probadores en sus equipos. La programación en pareja con un probador y un desarrollador puede ser increíblemente exitosa si pueden trabajar en un acuerdo de colaboración.

Antes de mirar Scrum/Kanban, tenga en cuenta una cosa: es una asociación con el negocio. si no tiene un miembro de la empresa que pueda priorizar (puede ser una persona, un grupo, un comité, etc.), entonces no va a funcionar.

Cuando presenté Scrum por primera vez, tuve que trabajar muy duro para convencer a la empresa de que participara. Sospechaban profundamente de Scrum e inicialmente no vieron el beneficio del tiempo que tendrían que dedicar al proceso.

Entonces, olvídese de la automatización de pruebas unitarias y los elementos técnicos de esto. Aquí hay algunas preguntas que usted y el equipo de desarrollo deben hacerse:

1. Al seguir la ruta de Scrum, le está entregando la priorización a su propietario del producto. Por lo general, para que Scrum tenga éxito, debe ser alguien en el negocio. ¿Estás feliz de hacer esto?
2. Tendrá que preparar y gestionar el backlog. Esto significa hacer que el equipo proporcione estimaciones para el trabajo que su propietario del producto le exigirá. ¿El equipo está dispuesto a pasar un tiempo razonable estimando y está dispuesto a cumplir con sus estimaciones?
3. El equipo tendrá mucho más contacto con el negocio a través de Priorización y demostraciones con el negocio. A algunas personas les gusta esto y a otras no. ¿Con ellos?
4. Scrum es increíblemente transparente. Solíamos enviar a nuestro Propietario de producto nuestro gráfico de trabajo pendiente todos los días, por lo que si estábamos atrasados, era obvio para el día 4. Olvídese de esconder cosas debajo de la alfombra: si tiene problemas, deberá ser honesto con el negocio antes. en lugar de más tarde para conservar la credibilidad. ¿Está dispuesto a compartir sus informes de estado diarios?
5. Una vez que realmente entregues, el negocio tendrá una luna de miel rápida (cantarán tus alabanzas), pero pronto se acostumbrarán a la entrega constante. ¿Estás feliz de hacer esto?

No importa las cosas técnicas. ¿El negocio y el equipo están listos para Scrum? No se limite a "declarar" que lo está haciendo, hable de lo que quiere hacer con el negocio. Háblalo con tu equipo y asegúrate de que entiendan en qué se están metiendo.

Y luego envíe a alguien a un curso de ScrumMaster.

No recomiendo introducir Agile o Lean, porque uno de ellos es atractivo para sus desarrolladores.

Les encanta probar cosas nuevas por naturaleza, y está completamente bien, pero usted, como gerente de proyecto, es responsable del proyecto y, si no tiene ningún proceso, debe analizar la demanda en lugar de verificar los procesos .

Descubre qué quieren tus clientes, cuáles son los momentos clave en la vida de los proyectos y conoce la visión . Por lo general, cuando no hay proceso, significa que no hay visión.

Supongamos que presenta Scrum, pero sus clientes no quieren participar en demostraciones y no quieren entregas periódicas. Gastó mucho tiempo y su dinero en un proceso que no encaja. Primero viene la demanda y luego la oferta .

Aquí hay una lista posible para usted:

1. demanda del cliente
2. visión
3. idea de proceso que encaja en la visión y la demanda
4. piloto de proceso interno
5. validación de la idea con el cliente (si no encaja, vaya al paso 1)
6. proceso de educacion
7. trabajar