No creo que el resto del negocio vaya a ayudar porque no tienen sentido de los ciclos de vida del desarrollo, y los requisitos cambian todo el tiempo en un solo sprint.
Una cosa que las empresas generalmente escuchan es cualquier cosa que tenga un impacto en el presupuesto. Si los requisitos de cambio constante se realizan frívolamente, entonces querrá crear un argumento con ejemplos detallados para mostrar cómo dicho cambio impacta la eficiencia del equipo, crea un trabajo superpuesto y le cuesta dinero a la compañía. Si, por otro lado, los cambios son necesarios y podrían resultar en una pérdida para la compañía si no se hace, entonces simplemente debe usarlo y encontrar una manera de lidiar con los requisitos en constante cambio.
Sin embargo, según mi experiencia, cuando las cosas están cambiando a un ritmo tan alto como usted ha sugerido, puede ser por las siguientes razones:
- El concepto es experimental, en cuyo caso es posible que desee agregar todos estos cambios en lugar de implementarlos directamente en el código de producción.
- El concepto no se ha analizado a fondo, lo que sugiere que el producto no se ha pensado realmente y el requisito es codificar el producto mientras se está pensando.
- El mercado constante y las presiones competitivas resultan en un cambio rápido
- Una mala relación entre los impulsores del proyecto, los gerentes y el equipo de implementación, en términos de la capacidad de todas las partes interesadas de comunicarse libremente sobre la necesidad de cambio.
- Priorización deficiente de las tareas, y esto puede ser un error tanto del personal de administración como de implementación.
A veces, los propietarios de proyectos realmente no saben cómo se supone que debe funcionar el producto, porque tienen un concepto básico en mente, sin embargo, sienten que necesitan ver cómo funciona primero antes de decidirse. Esto puede deberse a que el dominio del problema no se comprende muy bien o porque realmente no han pensado cómo una función empresarial se traducirá en una solución basada en software. La creación de prototipos puede ser beneficiosa en tales casos. Puede crear prototipos de GUI fácilmente con objetos simulados si los cambios son cosméticos, o puede usar pruebas unitarias como un medio para probar y ajustar cambios que son algorítmicos. Sin embargo, la clave es garantizar que los cambios se apliquen de la manera más sistemática posible, a fin de mantener el proceso relativamente ágil y menos costoso.
Hemos sugerido establecer procesos para esquivar esos cambios de requisitos y educar a la empresa sobre los ciclos de vida del desarrollo.
Este es un buen comienzo y le permite un medio para comprometerse con la gerencia para tratar de lograr resultados positivos de una manera medida y estructurada. La educación es el método más efectivo para tratar problemas donde los desarrolladores y la administración no están sincronizados ideológicamente. Sin embargo, para obtener el mayor beneficio, la educación debe ser bidireccional, al igual que la comunicación. Deben enseñarse a sí mismos y a la administración para comunicar sus necesidades y ayudarse mutuamente para comprender las motivaciones que impulsan esas necesidades. Decir que es "demasiado difícil" o "mucho trabajo" o "una pérdida de tiempo" solo parecerá quejarse y ser "flojo". Tu razonamiento debe ser claro, y en un lenguaje que muestre que está trabajando para lograr resultados positivos para la empresa y el producto en el que está trabajando, y que sus motivos están teniendo en cuenta estos intereses. Del mismo modo, es posible que deba aprender a aceptar las razones que le dan los trajes por las cuales siente la necesidad de cambiar las cosas tan rápidamente. Quizás entre ustedes puedan encontrar un buen término medio viable cuando ambas partes puedan entender el punto de vista del otro.
¿Qué pasa si el negocio no consigue la idea? ¿Qué harías?
Si no logra el resultado que espera, quizás el momento no sea el correcto. Quizás sus argumentos deben hacerse de manera diferente. Quizás lo tenga todo mal y necesite aprender más sobre lo que piensa la otra parte. En última instancia, si su enfoque particular falla, depende de usted decidir qué tan importante es para usted haber tratado. Sin embargo, en lugar de preocuparse por lo que puede o no suceder, piense positivamente y simplemente decida qué puede hacer hoy. Los problemas del mañana no están necesariamente garantizados y no valen la pena preocuparse hasta que realmente ocurran.
Un último punto a considerar. Su CTO posiblemente esté preocupado por muchos de los mismos problemas que usted tiene. Ciertamente, tener un decreto para adoptar TDD me sugiere que este podría ser el caso dado que TDD es altamente efectivo en situaciones donde el código a menudo está sujeto a cambios. En un escenario de prueba primero, las pruebas no se vuelven inútiles al día siguiente porque le proporcionan una red de seguridad para trabajar, lo que le permite aplicar cambios de forma rápida y segura. Sin embargo, aún necesitará encontrar una manera de gestionar las expectativas de las personas que solicitan cambios para ayudar a gestionar el cambio de manera eficiente.