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.
SO es muy propia S. Lott ha escrito sobre algo similar en su artículo "La cascada de que no trabaja - incluso un cliente lo digo" (http://homepage.mac.com/s_lott/iblog/architecture/ C551260341/E20080211062302/index.html). Está hablando de eso desde una perspectiva de consultoría, pero algunas de las ideas deberían ser transferibles a un equipo interno que pelea las mismas batallas. –