En un mundo ágil, la definición de terminado es interesante. A veces, una característica se considera terminada, desde la perspectiva del desarrollador o del proceso de desarrollo, cuando se traslada a la columna de "Terminado". Ahora solo "necesita" ser probada y lanzada. Fácil y sencillo. No tan rápido.
Desglosemos esta afirmación en pequeños trozos y analicémosla uno por uno: solo así podremos comprender y formar una opinión sobre el porqué. Confíen en mí, hay muchos conceptos pequeños ocultos aquí.
En scrum, el equipo (en los mejores casos) establece una Definición de Terminado. Se trata de un "contrato" entre los miembros del equipo. Es importante definir esto porque, de lo contrario, no sabremos cuándo estamos terminados. Cuando una historia de usuario (o boleto) está "terminada" y se solicita en la rama de lanzamiento (una solicitud para agregar el código a la próxima versión), puede considerarse terminada. Este es solo un ejemplo. Les diré cuál es el problema con este enfoque.
La mayoría de los desarrolladores con los que he trabajado detestan ser incluidos tarde en el proceso de pensamiento de una historia de usuario (o boleto). La mayoría prefiere entender el problema y proporcionar una solución por sí mismos, en lugar de simplemente implementar la solución dada por un arquitecto o el Propietario del Producto (o reportero del boleto). Hasta aquí, todo bien. Entonces, ¿por qué los desarrolladores a veces hacen lo mismo? Es decir, lanzar cosas sobre la cerca en el sentido de que quieren estar terminados con su boleto una vez que se incluye en la rama de lanzamiento. ¿Y qué hay de las pruebas? ¿Y qué hay de informar al reportero? ¿Y qué hay de verlo en acción? ¿Y qué hay de la integración?
Lo peor que podemos hacer como miembros del equipo, líderes del equipo o gerentes es quitar a nuestro personal altamente capacitado del proceso de toma de decisiones, así como del proceso de lanzamiento. Me refiero a este escenario: Pat está trabajando en un boleto y una vez que está "terminada", se la pasa a la prueba del equipo de control de calidad. Encuentran montones de errores y descubren escenarios de ruptura del código (junto con otras cosas no relacionadas) que ningún desarrollador habría pensado nunca. Agregan mucho valor... ¿o están simplemente extrayendo la energía de Pat? Al asignar la responsabilidad de las pruebas a otra persona, estamos quitando la responsabilidad a los desarrolladores. Solo son una pequeña parte del proceso, una pieza del mecanismo. Nunca ven el proceso completo. En mi experiencia, se sienten menos involucrados e incluso pueden escribir código subóptimo porque saben que se probará más tarde de todos modos, y tendrán que arreglar los problemas. Por supuesto, los desarrolladores deben probar sus propias características.
Solo son una pequeña parte del proceso, una pieza del mecanismo.
Una alternativa a todo esto es establecer un proceso de desarrollo diferente. Uno que habilite a los desarrolladores. Es simple, pero complejo. Y mantiene al desarrollador responsable hasta el verdadero Terminado.
Un ejemplo de un proceso de desarrollo Kanban:
Lo anterior describe el proceso en el que el desarrollador es totalmente responsable desde «En progreso» hasta «Listo» sin áreas vagas como «Listo-Listo», «Liberado» o «Listo-Listo-Listo». Listo es cuando está listo, cuando está liberado y en producción y crea valor. Como en todos los flujos lean, todo el tiempo que gastamos es un desperdicio completo hasta que se entrega. No tiene valor alguno. Solo basura. Solo cuando está en producción, en el sitio web, en plena función es cuando crea (potencialmente) algún valor. Pero eso es otro post…
Ayudamos a las empresas con su tecnología, proporcionando servicios de CTO y gestión de productos. Confiados en nuestros servicios de CTO, trabajamos con tanto startups como empresas establecidas en los países nórdicos, Suiza y EE. UU.
Somos una Compañía Suiza (LLC) con sede en 
Suiza.