Mantenerse ágil en una cascada

Question

Tenemos una gran aplicación empresarial en la que los proyectos se diseñan con un objetivo y finalmente se codifican mediante un proceso formal en cascada. A menudo me dan cambios de código para iniciativas no relacionadas solo porque están en la misma sección de código. Todas las iniciativas deben ser entregadas al mismo tiempo. El equipo de desarrollo también tiene poca influencia sobre el alcance o la línea de tiempo de entrega. No podemos hablar con los usuarios, debemos pasar por un grupo de recopiladores de requisitos que no conocen el negocio.

¿Alguien tiene algún consejo sobre cómo implementar incluso las más pequeñas de las técnicas ágiles para un entorno tan arraigado.

Answer 1

Al menos podría comenzar a escribir pruebas unitarias, o incluso, en la medida en que las circunstancias lo permitan, probar usted mismo el desarrollo (posiblemente difundir las ideas entre sus compañeros codesarrolladores también). Puedes cambiar mucho sin que la administración note nada ;-)

Por supuesto, en un lugar promedio o mejor, las personas en la administración no son completamente estúpidas. Con el tiempo, cuando haya logrado crear conciencia sobre estos temas entre el equipo de desarrollo, usted (como el equipo, en conjunto) también puede hablar con la alta gerencia y convencerlos de que den pasos en la dirección correcta. Comience poco a poco, obtenga resultados concretos, y amplíese en ellos, y desarrolle influencia buscando aliados tanto en el equipo de desarrollo como (en la medida de lo posible) entre la administración y los usuarios.

Muy a menudo se siguen ciertos procesos solo porque "siempre solíamos hacerlo así". Si puede mostrarle a la gente que hay mejores maneras, y probarlo con argumentos convincentes, tiene muchas posibilidades de triunfar. Tenga en cuenta que la administración y los usuarios necesitan argumentos bastante diferentes a los desarrolladores. Puede intentar hacer cálculos aproximados de costo-beneficio (o google: estoy bastante seguro de que hay muchas cosas en la red sobre esto). También recuerdo que hay un buen material sobre esto en Kent Beck's first XP book. También puede recopilar estadísticas de errores que con el tiempo (con suerte) muestran que las características desarrolladas de forma ágil tienen defectos notablemente menores en fases posteriores (prueba de integración o producción). (Para esto necesita un sistema de seguimiento de defectos, si aún no tiene uno).

Otra herramienta útil es hacer preguntas. Si tiene algo, un documento, una forma de hacer las cosas, no entiende, atrévase a hacer preguntas:

• ¿Por qué hacemos esto como nosotros?
• ¿Hay una manera mejor?
• ¿De verdad necesitamos esta cosa?
• ¿Quién necesita este documento?
• ¿Qué información necesita realmente de ella?
• ¿Contiene la información correcta para ella?
• ¿Está actualizado?
• ¿Quién la actualiza?

A menudo las personas simplemente toman las cosas como "dadas", pero cuando comienzas a preguntar por las causas, puedes encontrar muchas cosas interesantes ... e ideas para mejorar.

Una herramienta ágil muy útil es retrospectives.Después de cada iteración (lo que se llama en el proceso real) el equipo se reúne y una lluvia de ideas acerca

• lo que salió mal en esta iteración, y cómo asegurarse de que no vuelva a ocurrir (o al menos mejorarla hasta cierto punto)
• lo que salió bien y cómo asegurar que continuará así

Esto puede ser bastante fácil de ser aceptado por la administración, y es una buena manera de empezar a cambios positivos. Lo más importante es despertar y activar a las personas para que todos se den cuenta de que el éxito o el fracaso del proyecto está (al menos en cierta medida) en sus propias manos, que puede hacer algo para mejorar la situación.

Answer 2

Agile se trata de romper esas paredes de cascada. BDUF; lanzamiento simultáneo de componentes múltiples; falta de comunicación entre los desarrolladores y los propietarios de los procesos de negocios; iteraciones planeadas: todas estas se interponen en su camino en el proceso de cascada.

En mi posición, hemos desglosado muchas de estas paredes, y comenzó con obteniendo acceso directo al cliente. Cuando eso sucedió, el cliente obtuvo un mejor producto. Eso llevó a clientes más felices. Eso alejó cosas como BDUF, etc.

Todavía no tenemos verdaderas iteraciones/sprints, integración continua, etc., pero estamos llegando allí. (Los viejos hábitos, y todo eso.)

Answer 3

Usted como el equipo de desarrollo todavía podría coordinar internamente usando métodos ágiles (desarrollo basado en pruebas, la programación en parejas, tarjetas de historia, CI, lenguaje común, etc.)

agilidad en Tengo la idea de poder confiar en los cambios del software y evitar grandes inversiones erróneas en funciones que nadie necesita a tres pasos de la ruta de la cascada. Las pruebas y refactorizaciones y evitar la sobreingeniería son clave aquí.

Answer 4

Dependiendo de su dominio, las pruebas automáticas y la integración continua deben ser factibles.

Además, considere la posibilidad de crear su propia lista de niveles de granulación (columnas) para sus tareas actualmente asignadas. Debería ayudar a que las estimaciones de su trabajo sean más predecibles y facilitarle la explicación de cualquier retraso en el cronograma y tareas no planificadas.

En general, realice un seguimiento de algunas métricas en su sistema. Si puede mostrar alguna técnica ágil que agregue valor (tiempo de ciclo reducido, menor tasa de defectos, etc.), debería ser fácil vender su liderazgo en esa técnica.

... dependiendo del administrador, puede evitar el uso de la palabra "Agile", especialmente si solo está buscando una pequeña victoria al usar una técnica.

Answer 5

Para mí, el problema no parece ser que estés usando Waterfall en lugar de Agile. Es que la implementación de su cascada tiene grandes problemas. Lo más obvio:

Requisito recoge que no conocen el negocio

cascada puede y de hecho funciona bien si se hace correctamente. Creo que parece que algunas de las personas involucradas y cómo hacen las cosas están mal, no el proceso conceptual.

Answer 6

En mi experiencia, las grandes empresas se preocupan por el RIESGO, LA PREDECIBILIDAD Y LOS RESULTADOS MEDIBLES. Tendrá un tiempo más fácil (aunque tal vez no sea fácil) para presentar Agile si muestra cómo se alinea con esas métricas mejor que las prácticas existentes.

1. Que sea posible para enviar a menudo, incluso si no lo hace todavía: herramientas de apalancamiento CI y scripts de construcción automatizados para construir y empaquetar la aplicación. De esta forma, está preparado para capitalizar cualquier oportunidad de lanzar incrementalmente el nuevo código que pueda surgir.

2. , mida su productividad ahora para que tenga una línea de base: Cuanto más se puede medir mejor.

   1. Promedio de horas de programador por "función".
   2. Promedio de tiempo entre la comprobación del código y el descubrimiento de defectos en relación con ese código.
   3. Período de tiempo promedio entre el descubrimiento de defectos y la resolución de defectos en la producción.
   4. Promedio de tiempo necesario para identificar, resolver e implementar soluciones a anomalías.
   5. etc.

3. Proyecto los cambios en estos parámetros en virtud de un proceso ágil: Por ejemplo, en la mayoría de los casos, cuanto antes nos encontramos con un error más fácil/costoso es para corregir, por lo que se beneficia de TDD y las liberaciones rápidas a QA deberían ser fáciles de cuantificar.

4. Comience pequeño: Es posible que tenga un calendario de cascada entregado a usted, pero aún puede dividirlo en iteraciones, hágalo. Obtenga sus prácticas de ingeniería en su lugar, luego comience a tratar de ajustar el proceso. Vea si puede probar Agile en un pequeño proyecto auxiliar como una prueba de concepto.

5. encontrar un patrocinador: tratar de convencer a alguien más alto en la jerarquía que no sea usted de los méritos de ágil. Involucrar a su ayuda en la elaboración de los argumentos "Agile vs. Waterfall" en términos familiares para los tomadores de decisiones.

6. Sea paciente ... puede tomar tiempo para ver resultados.

7. ... o no. Si está profundamente interesado en Agile y recibe soporte cero, busque un nuevo trabajo. Sí, es gratificante realizar un cambio desde el vientre de la bestia, pero también es gratificante trabajar con personas que comparten sus ideas sobre la creación de software.