Cómo poner las lecciones aprendidas, las buenas prácticas, etc. en el “flujo de trabajo”

7

Como lo indica el título, me gustaría recibir algunas sugerencias sobre cómo poner en práctica el conocimiento.

Tenemos muchos requisitos adicionales relacionados con: desarrollo de funciones de codificación de prácticas (todas ellas o solo un subconjunto), proceso, etc. El problema es que tenemos problemas con la introducción de esas prácticas en nuevos proyectos y quiero ayudar a los desarrolladores y los revisores deben recordar esto, pero no quiero que tengan todo en sus cabezas, sino en algún tipo de base de datos que puedan usar fácilmente.

La lista de prácticas ya está definida en Excel. Me gustaría que todos los miembros del equipo apliquen estas prácticas en su trabajo, pero no sé cómo hacer que esa información sea fácil de encontrar. Cuando el desarrollador comienza a trabajar en una característica, debería poder encontrar fácilmente todas las prácticas que debería usar en esta característica.

Para ser claro con lo que quiero decir, estoy mostrando algunos ejemplos de la información que debemos aplicar:

  • (nueva solicitud de diseño) cada función debe generar registros (y no debe contener datos confidenciales);

  • (nueva solicitud de diseño) cada función debe tener una marca en la configuración que permita desactivarla;

  • (buena práctica) siempre actualice los documentos cuando la función esté lista;

  • (retroalimentación retrospectiva) El control de calidad debe probarse solo en el paquete de lanzamiento (no en modo de depuración);

  • (retroalimentación retroactiva) realice pruebas de estrés para cada nueva función implementada;

  • (tarea del líder) escriba notas de la versión después de cada sprint que incluya tareas completadas y errores abiertos;

  • (uso del diseño) todos los eventos de "ABCStoreManager" deben desconectarse después de ser invocado;

  • (uso del diseño) try-catch en todos los eventos. Invocar () llamada;

Pensé por un momento en un wiki, pero no sirve, porque no admite el etiquetado / categorías o la consulta, y me temo que todos lo ignorarán (la gente debe saber exactamente dónde buscar).

Mi pregunta se puede resumir en ¿cómo puedo mejorar la comunicación con nuestros desarrolladores acerca de las metodologías y prácticas de desarrollo requeridas que se mencionan arriba de manera fácil?

Observaciones:

  • esta pregunta no tiene que ver con problemas de seguridad o olores de código per se;

  • No estoy buscando ningún proceso pesado (como RUP) ni ningún otro proceso, lo que te obliga a ir paso a paso. Preferiblemente estoy buscando un enfoque ágil

  • Daniel Figueroa ha sugerido agregar requisitos adicionales a la" definición de hecho ". Y parece una buena manera. Pero el problema es que algunas características tienen, por ejemplo, 20 requisitos adicionales ("todas las características de la GUI"), algunas 10 ("todas las solicitudes del servidor"), etc. Me gustaría tener estas cosas agregadas en un solo lugar y solo usar enlaces ("ver: 'característica GUI'");

pregunta andrew.fox 16.02.2014 - 23:00

2 respuestas

3

Está bien, aquí está lo que creo.

Cuando se trata de su ejemplo con los registros, creo que realmente tiene la respuesta en su lista. Lo que se reduce a está en el definition of done . Si los desarrolladores están imprimiendo datos confidenciales en los registros y se supone que los probadores deben verificar que no haya datos confidenciales en los registros, entonces claramente esa función no está activada, lo que significa que el probador debe devolver esa función a In progress o lo que sea que estén haciendo para mantenerse al tanto del desarrollo.

Lo mismo ocurre con todo lo que tiene que ver con el código real, ahora no estoy promocionando la opinión de que los evaluadores deben teach los desarrolladores. Pero deben trabajar como un guardia de que la implementación está a la par con sus estándares. Cualquier desarrollador que valga la pena, debe tomárselo rápidamente en serio si cada vez que crea una nueva característica se devuelve porque no se adhirieron correctamente a algunas de sus reglas.

Otra cosa que creo que es realmente importante es lo que @Robert Harvey puso en el campo de comentarios, revisión de código. Eso podría ser cualquier cosa, desde la programación por pares hasta algo más formal. Si un fragmento de código solo ha tocado un par de ojos, creo firmemente que se debe hacer algo. Algo así como una descripción de alto nivel de lo que hace el código al mostrar el código real me ha hecho sonrojarme varias veces porque he encontrado problemas o cosas que me he perdido varias veces. Y, por lo general, solo se trata de errores tontos.

Para recapitular:

  • Una de las responsabilidades de los evaluadores es verificar que los desarrolladores sigan las reglas.
  • No dejes que los desarrolladores actúen como lobos solitarios, debería ser una actividad social (no siempre me gusta, pero es cierto).
  • Tenga una definición clara de "hecho" y no permita que el implementador sea el único que diga que ya está hecho.

Creo que esta es una pregunta sobre cultura, no sobre herramientas.

    
respondido por el Daniel Figueroa 16.02.2014 - 23:30
1

Usamos una wiki en un trabajo anterior, y funcionó bien. Cualquier cambio fue publicitado a los desarrolladores, y los líderes del equipo lo discutieron a intervalos regulares.

Parece que en su lista, tiene las mejores prácticas de programación y definiciones de procesos. Yo sugeriría primero escribir el proceso por el cual usted desarrolla software. Luego, puede agregar sub-políticas con respecto a las mejores prácticas o pautas específicas de idioma. La política principal debe referirse a ella y dejar claro que los desarrolladores deben seguir las pautas de las prácticas de estilo, a menos que no haya una buena razón también.

Tenga en cuenta que no estoy abogando por escribir páginas y páginas de documentos, solo lo suficiente para dejar en claro lo que se supone que debe hacer un desarrollador en cualquier punto en particular de un proyecto. Si no puede resumirlo fácilmente, sugeriría que el proceso actual en sí es vago.

    
respondido por el Rory Hunter 24.02.2014 - 15:06

Lea otras preguntas en las etiquetas