El proyecto en el que estoy trabajando terminó, pero me gustaría reflexionar sobre la gestión de una gran decisión experimental tomada por un desarrollador durante el desarrollo. Esto es lo que pasó:
Un desarrollador sintió fuertemente que algo no estaba bien con el diseño actual del proyecto. Debido a un conocimiento insuficiente, no pudo expresar lo que está mal. Como tenemos plazos, no podemos esperar, ni trabajar con él en su investigación, ya que no puede convencernos de lo que está mal.
Para ser constructivos, nos dijo que siguiéramos adelante mientras realizaba su investigación y experimentaba enormes trabajos de rediseño en su rama del SVN. Un par de semanas más tarde, nos presentó un proyecto funcional, enormemente rediseñado (y refactorizado) en el que confía y nos lo explicó todo. Estábamos convencidos.
Sin embargo, como estábamos cambiando y agregando funciones basadas en el diseño anterior, era tan bueno como si estuviéramos trabajando en 2 proyectos separados y la fusión de SVN se volvió imposible debido a la gran diferencia. Entonces teníamos 2 opciones.
Para trabajar en nuestra copia, tendríamos que rediseñar todas nuestras funciones según el nuevo estándar, así como identificar todos los elementos refactorizados.
Para trabajar en su copia, primero tendríamos que identificar las características modificadas e implementarlas correctamente en su diseño, seguido de las nuevas características.
Elegimos la primera opción, ya que la segunda todavía tendría que lidiar con muchos rediseños debido a las funciones modificadas que usan clases obsoletas y similares.
Se dedicó mucho tiempo y todo se sintió como un esfuerzo doble (o quizás triple). Aunque valió la pena (cumplimos el plazo con más esfuerzo), la pregunta es, dadas las circunstancias, ¿hay alguna metodología que hayamos pasado por alto que podría haber manejado mejor tal escenario? ¿O lo que estábamos haciendo era la decisión correcta y esto es algo normal/común en el desarrollo?
Tenga en cuenta que tampoco estaba tan seguro de lo que estaba haciendo, por lo que tuvo que terminar todo lo que estaba haciendo para que funcionara y confirmó su investigación antes de presentárnoslo. Es cierto que todos éramos desarrolladores aficionados, incluido él, pero instintivamente sabía lo que estaba mal, pero carecía de las terminologías y la experiencia / conocimiento de los estudios de casos para transmitirnos adecuadamente antes de su investigación. Existía la posibilidad de que sus instintos también pudieran estar totalmente equivocados.
Su pregunta toca muchos temas, incluidas áreas de arquitectura e ingeniería que no son preguntas de gestión de proyectos. Por lo tanto, limitaré principalmente mi respuesta a la perspectiva de la gestión de proyectos.
La respuesta corta es que casi siempre aprendes lecciones durante un proyecto que hacen que las elecciones iniciales anteriores sean sospechosas. La retrospectiva es 20/20, y esta es una consecuencia inevitable del Cono de Incertidumbre . Esta es la razón por la cual las metodologías iterativas de gestión y desarrollo de proyectos que aprovechan el diseño emergente son generalmente preferibles a la planificación en cascada, ya que el costo de un rediseño completo a menudo es insostenible para un proyecto típico.
En los casos en que se requiere un rediseño, no hay una respuesta canónica sobre cómo hacerlo; es un asunto que cada equipo y cada proyecto debe considerar en función de las circunstancias específicas. Más allá de eso, concéntrese en un software de trabajo que sea "suficientemente bueno" en lugar de idealizado, y asegúrese de incorporar las lecciones aprendidas en los procesos de su equipo.
No hay nada de malo con los picos de historia enmarcados en el tiempo , y la reelaboración y la refactorización son de rigor para el desarrollo iterativo. Sin embargo, el principio de YAGNI y la ingeniería "suficientemente buena" argumentan en contra de la remodelación a gran escala a menos que su producto no sea apto para su propósito o haya acumulado demasiada deuda técnica para ser modificado o mantenido.
Lo perfecto es enemigo de lo bueno. Si su software está funcionando y se ajusta a su propósito, no es una buena gestión de proyectos descartarlo en favor de algo mejor solo porque es mejor. Debe haber un impulsor comercial válido antes de que los recursos del proyecto se gasten en tal esfuerzo.
Si bien está marginalmente fuera del alcance, sugeriría que sus prácticas de desarrollo son subóptimas. Debe trabajar con el equipo técnico para impulsar mejores prácticas, como:
Esta no pretende ser una lista exhaustiva, ya que las buenas prácticas de ingeniería están fuera del alcance de la gestión de proyectos. Como gerente de proyecto, su trabajo es trabajar con el equipo para asegurarse de que tengan la capacitación, los recursos y los controles administrativos/técnicos para entregar el producto de manera efectiva, pero cómo lo hacen a nivel técnico no es su problema. .a menos que no estén funcionando con eficacia. Si ese es el caso, debe ayudar al equipo y a las partes interesadas a definir un proceso más eficaz.
Promiscuous Integration, lo que me hizo darme cuenta de que al menos podríamos tener el rediseño para llevar la bifurcación hacia nosotros para que siempre esté experimentando con las últimas actualizaciones. Technical debtTambién es otra cosa importante aprendida, que me hizo sonreír cuando el 80% de la lista de causas coincidía con nuestra situación.
Verde