El primer problema que veo es que el proceso de estimación se está ampliando un poco. Sí, los desarrolladores deberían poder opinar sobre la cantidad de trabajo que se espera que asuman. No, eso no significa que agregar un solo botón a un formulario web ahora sea una historia de dos semanas de desarrollador (sin importar muchos puntos que se igualen en el proceso de estimación de su negocio). Si ese es el estado actual de las cosas, entonces usted, como gerente del proyecto, debería estar haciendo algunas conjeturas.
En segundo lugar, escucho "desde el principio (diseño) hasta el final (implementación y pruebas unitarias)" y el primer pensamiento que me viene a la mente es "lo estás haciendo mal". Las pruebas unitarias son parte de su trabajo de diseño como equipo de desarrollo / desarrollo, y deben ocurrir primero; usted toma los requisitos básicos, los destila en una simple "lista de verificación" de "If ... When ... Then ..." - escriba oraciones, y luego convierta esas oraciones en una serie de pruebas básicas que afirman que el programa cumple con esos afirmaciones y por lo tanto los requisitos. Eso sucede antes de escribir una línea del código de producción que cumpla con las afirmaciones de las pruebas. Si sus pruebas unitarias son las últimas, después de que ya haya implementado el software, perderá varios aspectos clave de las pruebas unitarias; en general, sus desarrolladores no pueden "programar en verde",
En cuanto a que los desarrolladores "poseen" sus características, hay un sí y un no. En primer lugar, una sacudida bastante común de los "equipos autoorganizados" es la tendencia de los desarrolladores a partir en parejas o en tres y trabajar en las cosas que mejor conocen. Suponiendo que tiene un buen conjunto de experiencia de desarrollador de tal manera que el equipo puede cubrir todo el trabajo a realizar en cada iteración de esta manera, simplemente puede dejar que esto suceda; es bueno para la velocidad, ya que los desarrolladores se mantienen enfocados y familiarizados con las áreas de la base de código en las que han estado trabajando de iteración en iteración.
Sin embargo, un desarrollador que posee una característica de por vida es una mentalidad peligrosa, ya que reduce el "número de camión" de su equipo (definido muy francamente como "cuántas personas podrían ser golpeadas por un camión antes de que el equipo no pudiera funcionar, dado el el peor de los casos de personas específicas golpeadas y el conocimiento resultante perdido). Si el tipo al que le ha asignado la función "Importar archivos" de su software y que lo ha poseído durante 2 años se va de vacaciones durante tres semanas, toma un permiso extendido de FMLA, cambia puestos de trabajo, o en el extremo, realmente es atropellado por un camión y muere, ahora no tienes a nadie más que conozca esa característica porque esa área de la base de código ha sido el ámbito exclusivo de ese tipo durante años. Mientras que otra persona se familiariza con esta pieza particular de la base de código,va a perder una velocidad significativa, y también se abrirá a problemas adicionales con defectos, ya que el nuevo tipo que apenas está familiarizado con el funcionamiento de la base de código ahora puede permanecer lamentablemente ignorante de las cosas que puede y no puede cambiar dentro de él. .
En cambio, debe buscar cultivar una división del trabajo que mantenga el número de su camión al menos 2 o más, y en un equipo más grande (una docena o más) más cerca de 3 o 4. De esa manera, si un tipo no puede hacer el trabajo , por cualquier motivo, hay varias otras personas que pueden participar. A veces, los equipos simplemente se sacuden de esta manera, especialmente si incorporan algunas técnicas XP como programación en pareja o estilo dojo (un tipo escribe en una nueva afirmación basada en sobre los requisitos que el código no cumple; el siguiente individuo luego codifica para pasar esa prueba, luego agrega otra afirmación de requisito que falla y la pasa). Por definición, en estas situaciones, tiene múltiples ojos mirando el código, desarrollándolo y familiarizándose con él.
En general, la idea de Agile es promover el desarrollo "ligero". Su equipo parece estar empantanado en minucias de procesos y documentación, cuando el enfoque principal, según el Manifiesto Ágil, debe estar en los miembros del equipo y sus interacciones, y por supuesto en el código funcional y funcional. Los procesos inherentes a Agile son un medio para un fin, y no hay una sola forma de seguir a Agile; incluso los marcos de trabajo ágiles primarios como SCRUM son maleables en función de sus necesidades como empresa, equipo e incluso día a día (solo asegúrese de tener en mente las ideas básicas de los valores proporcionados por estos procesos al realizar tales cambios).