Estamos construyendo un proyecto de software (usando python Django y un montón de otras tecnologías de código abierto). El proyecto es bastante grande. Para dar una idea, tiene más de 50 plantillas.
Nuestro equipo está compuesto por personas sin experiencia en Django. Es el primer proyecto Django para todos nosotros. Como tal, cada vez que se desea una función, todos simplemente siguen el primer enfoque que les viene a la mente, sin apenas tener idea de sus consecuencias sobre lo que se ha hecho antes. Nadie mira el panorama general. Como resultado, las cosas que funcionaban en el pasado se descomponen con frecuencia.
Tenemos dos problemas importantes .
En la actualidad, de alguna manera hemos logrado terminar la mitad de nuestro proyecto (además, el proyecto se ha retrasado 1 año). Aún queda la mitad. Además, ha surgido un nuevo proyecto. Se me ha encomendado la tarea de identificar las causas fundamentales de los dos problemas anteriores y sugerir cómo minimizarlos . Si hacemos eso, el nuevo proyecto se desarrollaría de mejor manera.
La prueba de integración con pruebas automatizadas es una forma en la que puedo pensar para detectar los errores. Pero mi objetivo aquí es de alguna manera evitar que se creen en primer lugar, al menos minimizarlos.
¿Cómo puedo aumentar la robustez de nuestro código? En otras palabras, ¿cuáles son las mejores prácticas para los proyectos Django de nivel empresarial ?
¿Alguien, especialmente las personas con experiencia en la gestión de proyectos, puede sugerirme los enfoques correctos o indicarme la dirección correcta?
El orden de estos puede ser debatido, idealmente debería comenzar a hacerlos todos lo antes posible :-) Probablemente haya muchas más mejoras potenciales, pero creo que estas son las acciones clave que pueden ayudarlo a avanzar mucho.
Si desea comprender mejor los principios/frases utilizados anteriormente, es posible que desee leer sobre el desarrollo de software ágil y eficiente .
Es posible que se pierda sugerencias específicas de Python o Django; otros respondedores pueden (y con suerte lo harán) darle ese consejo. Mi percepción es que sus problemas no son específicos de Python o Django, sino problemas sistémicos, por lo que las soluciones también deben ser sistémicas.
Veo dos problemas, y usted mismo ha identificado uno de ellos: nadie tiene supervisión técnica del sistema en su conjunto. Las cosas se están rompiendo en la integración porque nadie está pensando en todo el sistema hasta ese momento. La otra es que su gente parece estar funcionando como una colección de desarrolladores individuales, en lugar de como un equipo.
La falta de familiaridad con Django es un poco una pista falsa. Un problema mayor es que su equipo no está lo suficientemente familiarizado con el código que ustedes mismos están escribiendo.
Sus desarrolladores no conocen las API que romperán las cosas si no se respetan, o las suposiciones en el diseño que romperán las cosas si se violan, o los enfoques que otras personas ya han tomado para resolver problemas similares o relacionados.
Documentación del programador
Los dos primeros se pueden documentar, en el propio código y/o en una guía para desarrolladores. Use una herramienta como Sphinx que puede generar automáticamente documentación a partir de cadenas de documentos con el formato adecuado.
Escribir pruebas que se centren en las API es un ejercicio práctico simple que comenzará a desarrollar ese conocimiento (si hace que todos lo hagan) y ayudará a prevenir algunos de los problemas de integración que está teniendo (si ordena ejecutar estas pruebas antes de cometer).
Reseñas de código
Para el tercero, necesita que todos vean más código que el suyo propio. Comience a solicitar revisiones de código para cualquier cambio que no sea trivial. Use una herramienta en línea como ReviewBoard o las solicitudes de extracción de GitHub que permiten a los revisores hacer comentarios en línea, así como comentarios generales. Asegúrese de que las personas publiquen el código para su revisión cuando esté en la etapa de "primer borrador" en lugar de "pulido y terminado", y centre la discusión en cómo y por qué las cosas se hicieron de cierta manera, los pros y los contras de los diferentes enfoques, en lugar de estilo y adherencia a los estándares de codificación. Establezca expectativas de que el resultado de la revisión puede incluir reescrituras significativas, si se identifica un mejor enfoque durante la revisión, y que los bloques de código que confunden a los revisores deben comentarse con explicaciones.
Es de esperar que su equipo se dé cuenta de que no tienen experiencia con la tecnología que están utilizando y quieran mejorar sus habilidades. Presente las revisiones de código como una forma eficiente de desarrollar y compartir conocimientos (y evite como la peste cualquier cosa que huela a competencia o vergüenza). Asegúrese de que entiendan que las revisiones regulares son parte de su trabajo como desarrolladores, no un complemento opcional. Si su gente está cobrando o rastreando el trabajo de cada función, deben cobrar el trabajo de revisión de la función que se está revisando: eso también ayudará con un sentido de propiedad del equipo sobre todo el producto. Eventualmente, debería comenzar a ver surgir algunos enfoques comunes para los problemas, ya que sus desarrolladores comienzan a reconocer que este problema es similar a eseuno que se implementó en la última compilación y se puede trabajar de manera similar.
Planificación de póquer
Te recomiendo que hagas algo similar desde el principio también. No dijiste nada sobre el proceso mediante el cual las funciones se asignan a los desarrolladores, pero incluye eso también en un proceso de equipo.
Mi equipo descubrió que Planning Poker es aún más valioso como estructura para la discusión técnica que para su propósito nominal de estimar el esfuerzo. Nos hace hablar sobre el alcance y la complejidad de cada tarea antes de intentar estimarla; luego, cuando las estimaciones varían, a menudo se debe a las diferencias de enfoque que se discuten. Esto ayudará con el problema de los desarrolladores individuales que implementan el primer enfoque que se les ocurre. También ayudará con las revisiones de código, porque todos sus desarrolladores habrán estado en la discusión técnica anterior.
Dado que su gente todavía no tiene experiencia con la tecnología que está usando, asegúrese de hacer circular la lista de tareas que se estimarán con una semana o dos de anticipación, para darles a las personas la oportunidad de familiarizarse con la solicitud de función y leer sobre posibles enfoques antes del juego.
Una vez que se han estimado todas las tareas, generalmente dejo que mi equipo divida el trabajo entre ellos, siempre que el esfuerzo y las tareas de alta prioridad se distribuyan de manera uniforme. (Por supuesto, podemos reasignar a medida que continúa el ciclo de desarrollo, si resulta que algún trabajo requirió más o menos esfuerzo de lo estimado). Nuevamente, evite cualquier cosa que huela a competencia o vergüenza.
Supervisión del sistema
Estas dos prácticas ayudarán gradualmente a sus desarrolladores a ser conscientes del panorama general y a realizar colectivamente la supervisión necesaria del sistema, pero llevará tiempo.
Mientras tanto, si es posible, consideraría identificar a una o dos personas en el equipo que sean buenas para pensar sistémicamente y cuya experiencia generalmente se respete, y encargarles que brinden supervisión del sistema: comprendan la arquitectura y las API, e identifiquen y seleccionen Aproximaciones a problemas comunes. Esta persona debe participar en todas las revisiones de código, si es posible; no como revisor principal (eso socavaría el objetivo de difundir el conocimiento y la responsabilidad), sino al menos como revisor final para plantear cualquier problema relacionado con el sistema que aún no se haya identificado.
El líder del equipo puede hacer esto si tiene tiempo; las personas que participaron en el diseño inicial también serían candidatos lógicos.
Si participa en revisiones de código y juegos de planificación en el nuevo proyecto desde el principio, es probable que haya menos necesidad de encargar explícitamente a alguien como arquitecto/curador del sistema. Por otro lado, dados los problemas que ha tenido en el pasado, podría valer la pena hacerlo de todos modos.
Ensayos y Retrospectivas
Definitivamente cree su equipo un conjunto estándar de pruebas, incluidas las pruebas de integración, que se ejecutan todas las noches y que cada desarrollador puede ejecutar de forma rutinaria mientras desarrolla. Establezca expectativas de que cada característica nueva debe entregarse junto con nuevas pruebas, y que los desarrolladores deben probar antes de comprometerse.
Las retrospectivas después de cada construcción/entrega/sprint son un elemento esencial de la mejora continua del proceso. Me gusta llevar golosinas a estos, para mostrar aprecio y crear un ambiente relajado. Como líder del equipo, empiezo haciendo preguntas generales: ¿Qué funcionó bien? ¿Qué no? ¿Qué queremos cambiar de nuestro proceso la próxima vez? Luego, principalmente tomo notas (en el proyector para que todos puedan ver) y facilito la discusión y las decisiones. Es importante identificar las cosas buenas y las malas, y está bien quejarse de las cosas que no salieron bien, siempre y cuando también obtenga algunas soluciones propuestas.
Hay enfoques más estructurados para las retrospectivas que no he probado, aunque parecen interesantes. Pero este enfoque muy básico ha funcionado bien para mi equipo.
(Por cierto, dirijo un pequeño equipo que desarrolló y mantiene una aplicación web Python Django mediana/pequeña. No teníamos experiencia con Django cuando empezamos. Hemos usado todo lo que he recomendado aquí).
Tiago Cardoso
Akash Gaurav