Uno de los nuevos requisitos de nuestro equipo de desarrollo establecido por el CTO / CIO es convertirse en un desarrollo impulsado por pruebas, sin embargo, no creo que el resto del negocio vaya a ayudar porque no tienen sentido de los ciclos de vida del desarrollo, y los requisitos se cumplen cambiado todo el tiempo dentro de un solo sprint. Lo que me frustra por perder el tiempo escribiendo 10 casos de prueba y será inútil mañana.
Hemos sugerido establecer procesos para esquivar esos cambios de requisitos y educar a la empresa sobre los ciclos de vida del desarrollo. ¿Qué pasa si el negocio no consigue la idea? ¿Qué harías?
Respuestas:
Su pregunta parece sugerir que TDD está sujeto a ciclos de vida de desarrollo. No estoy seguro de estar de acuerdo.
La respuesta a los requisitos flexibles y cambiantes es el desarrollo iterativo. TDD no tiene nada que decir sobre esto o sobre los programas de software; Es una herramienta para desarrollar software dentro de los requisitos y la programación que tenga. Si los requisitos cambian, también lo hace el software. Esto también se aplica a las pruebas unitarias.
TDD no desarrolla requisitos, aunque algunos proponentes sugieren que sí. Más bien, los requisitos conducen las pruebas de las unidades, que a su vez controlan el código que está escrito. No creces una arquitectura a partir de pruebas, ni desarrollas requisitos con pruebas. En cambio, las pruebas son un resultado de la arquitectura y los requisitos designados.
Si los requisitos están cambiando a nivel atómico (prueba de método / unidad) de desarrollo de software, entonces sugeriría que sus requisitos sean demasiado granulares. Los requisitos deben especificar qué hace el software, no cómo lo hace. La forma en que el software cumple con los requisitos es el dominio y la responsabilidad de los desarrolladores de software, no de los principales interesados.
Para decirlo de otra manera, no le digo al cliente o al dueño del negocio cómo administrar su empresa, y él no me dice cómo diseñar mis clases.
fuente
Cambiar los requisitos es algo normal, pero cuando cambian a diario y cambian los requisitos en medio de un sprint, este no es un entorno propicio para que el software se desarrolle de manera significativa y cualitativa. En otras palabras, TDD es el menor de sus problemas aquí, son más fundamentales.
Mencionas sprints, lo que significa que estás realizando algún tipo de desarrollo ágil, lo cual es algo bueno. Manejar el desarrollo en sprints cortos y rápidos funciona bien en proyectos para cuando las prioridades y los requisitos son volátiles y podrían cambiar en la mitad del proyecto. El problema grave es que tienes requisitos que cambian drásticamente en tus equipos de desarrollo y prueba en medio de un sprint.
Las prioridades del sprint no deberían cambiar una vez que el sprint ha comenzado. Se supone que el sprint es un acuerdo entre las partes interesadas y el equipo de desarrollo de que las siguientes características acordadas e historias de usuarios se entregarán y probarán en una fecha específica. Las partes interesadas no mantienen su final del acuerdo cuando comienzan a cambiar sus expectativas para el sprint después de que ha comenzado el desarrollo.
Por lo tanto, las partes interesadas no fueron cuidadosas ni pensaron en lo que pedían, por lo que cambiarán sus expectativas de inmediato. ¿Los desarrolladores tienen el lujo de adelantar la fecha de entrega de las funciones? A menudo no. En el mejor de los casos, las partes interesadas fueron negligentes o incompetentes y los desarrolladores pagan el precio en horas extras para cumplir con la fecha de todos modos. A veces, incluso las partes interesadas hacen esto a sabiendas de que pueden obtener más trabajo de sus desarrolladores asalariados.
Lo que debería suceder honestamente cuando los requisitos centrales cambian al punto en que el trabajo actual para el sprint sería inútil es detener inmediatamente el desarrollo del sprint hasta que se pueda planificar un nuevo sprint en función de los nuevos requisitos. Ciertamente, no hay ninguna razón para continuar durante la próxima semana y media desarrollando software que la empresa ya le ha dicho que de ninguna manera sería útil para ellos.
Lo que está sucediendo realmente es que las partes interesadas del negocio están fallando al equipo de desarrollo al no mantener o cumplir el compromiso de sprint. Demuestran una completa falta de competencia para determinar lo que quieren en el software o una total falta de respeto por el equipo de desarrollo y cómo se produce el software de calidad.
La única forma en que grupos empresariales como este se ganan el respeto de cómo funciona realmente el desarrollo de software es contratando una empresa consultora externa o un proveedor de software para desarrollar software para ellos y pagar por sprint. Una vez que pierdan dinero en unos pocos sprints de desarrollo que no pueden usar, comenzarán a apreciar lo importante que es mantener su compromiso como partes interesadas y ser muy cuidadosos y específicos con sus características y requisitos.
fuente
Sin entrar en una terminología ágil específica, parece que el problema fundamental es la falta de comprensión y / o compromiso con la responsabilidad del cliente durante una iteración: una vez que el conjunto de elementos implementables es elegido (por el cliente, acordado por los desarrolladores) para un iteración, el cliente acepta no cambiar de opinión hasta el final de la iteración.
Esto le da a los desarrolladores un objetivo estacionario por un corto tiempo.
Si los requisitos son tan inestables que no pueden sobrevivir solo un día, el proyecto tiene problemas mucho más allá de la metodología ... En ese caso, retroceda a los objetivos del proyecto y reconsidere las características propuestas.
fuente
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:
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.
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.
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.
fuente
Primero, parece que podría necesitar hacer más prototipos ficticios. Significa maquetas en las que se puede hacer clic y que no almacenan ni recuperan datos reales, pero que emulan cómo se comportaría el software. Entonces, para las aplicaciones web, esto significaría HTML / CSS / JavaScript completamente hecho que permite al usuario 'hacer clic' a través del software, a pesar de que haya hecho muy poca codificación. Quizás eso pueda ayudar a los usuarios a ver qué es lo que están pidiendo antes de invertir el trabajo en codificarlo.
A continuación, no depende del departamento de TI decidir cómo funciona el negocio. Y podría ser que la empresa valore la agilidad sobre la confiabilidad para sus necesidades de software. Por lo tanto, cambiar algo HOY es más valioso que asegurarse de que una característica determinada funcione el 100% del tiempo, en lugar del 95.5% del tiempo. Solo el negocio mismo puede decidir esto. A menos que su departamento sea criticado por problemas de calidad, tal vez debería considerar que el negocio está totalmente de acuerdo con los requisitos cambiantes y el código no controlado por pruebas. Su CTO / CIO dice que quiere que sea "sometido a pruebas", pero si los requisitos comerciales son rutinariamente "hacer este cambio antes de las 4 p.m.", entonces no puede tener ambos.
fuente