¿Cómo ganar práctica personal en metodologías de desarrollo de peso pesado?

Estoy en un nuevo trabajo donde el proyecto necesita cumplir con estrictos estándares de calidad, estar muy documentado, administrado con gran detalle, diagramas UML y todas esas cosas que son opuestas a la "codificación de vaqueros", donde la mayor parte de mi experiencia laboral anterior ha sido . Piense en la forma en que se desarrolla el software de dispositivos médicos o aeroespaciales a gran escala.

Me alegra dejar el caos de la codificación de vaqueros y tengo curiosidad por ver qué tan bien funcionan los métodos de ingeniería de peso pesado. Pero, ¿cómo se puede ganar experiencia rápidamente con los métodos pesados?

Además de simplemente estar en el trabajo durante algunos meses / años, eso es.

Con un simple lenguaje o una nueva API, uno puede hackear un programa de prueba de juguetes, leer, cometer errores deliberadamente para ver qué sucede, etc. Al igual que ser bueno para andar en bicicleta o tocar un instrumento musical, la práctica es esencial. Es fácil tomar una flauta y pasar media hora todos los días; No es necesario unirse a una orquesta o ser un consultor de flauta a tiempo completo. Pero, ¿cómo practicar actividades de ingeniería de software que sean grandes, complejas, involucren equipos, y gran parte de las cuales se trata de comunicarse y planificar, y evitar comunicaciones erróneas y exceder los límites de horario y presupuesto?

Esto no parece posible hacer solo. ¿Hay alguna manera de que un pequeño número de personas pueda simular la ingeniería de un gran proyecto completo a pequeña escala en poco tiempo (un día)?

¿Hay alguna manera de que un pequeño número de personas pueda simular la ingeniería de un gran proyecto completo a pequeña escala en poco tiempo (un día)?

Sí, esto es posible hasta cierto punto. Hace unos 10 años participé en un taller en la conferencia OOP en Munich donde a 16 personas se les dio la tarea de hacer un análisis y diseño generales para un software de pequeña empresa. La primera mitad del día se trató principalmente de encontrar una estructura de equipo para resolver la tarea con 16 personas, y la segunda mitad del día se centró en resolver la tarea con este equipo.

Durante la primera parte fuimos guiados para dividir a las 16 personas en grupos de cuatro. Cada equipo de cuatro personas tuvo que elaborar sugerencias para la estructura del equipo (bajo presión de tiempo), luego se aplicó un proceso de tiroteo para tomar una decisión sobre qué estructura del equipo podría ser la mejor y se debería utilizar para la segunda parte del taller. .

Desafortunadamente, durante la primera parte, cometimos el error de tratar de darle a cada una de las 16 personas un trabajo dentro de la estructura del equipo previsto. Ese error condujo al caos en la segunda mitad, porque 16 personas son demasiado para resolver esa tarea. Una solución de trabajo podría haber sido dividir a las 16 personas nuevamente en equipos más pequeños, o elegir 3 o 4 personas para hacer el trabajo principal, pero en el momento del momento no lo vimos.

Todavía tengo la impresión de que aprendí mucho sobre los problemas típicos que uno puede enfrentar en organizaciones de proyectos más grandes ese día. No sé dónde puede visitar este tipo de taller en algún lugar cercano a usted, o quién ofrece tal cosa hoy en día, pero si tiene la oportunidad, le recomiendo que asista.

Comience con una lista de verificación . (Sabía que ese era el primer paso, ¿verdad?)
Asegúrese de que la lista de verificación enumere toda la documentación estándar para su proyecto actual. es decir. Diagrama UML, especificaciones funcionales, diseños de alto y bajo nivel, etc. El ingeniero de sistemas en mí sugerirá usar un RTVM (matriz de verificación de trazabilidad de requisitos)

Elija un programa de muestra para trabajar. Si no puede encontrar uno, busque "code katas" en Google o consulte el archivo de desafíos codejam de Google. O simplemente construye una calculadora. :-)

Cree la especificación funcional para su programa de muestra. Luego pase al diseño de alto nivel, diagrama UML, etc. Compílelo según las especificaciones. Pruébalo. Cada vez que encuentre un defecto significativo en su especificación (según lo definido por sus prácticas de trabajo actuales), debe retroceder a esa etapa del SDLC y revisar antes de avanzar nuevamente.

Para su primera ronda, siga adelante y manténgalo pequeño. Recorrer el proceso es más importante que exagerar en cualquier etapa en particular. Para rondas posteriores, agregue las características que dejó. Seguimiento, registro, análisis de rendimiento, andamio de prueba, etc. Lo que desee agregar dependerá de lo que su empleador espere para su trabajo real.

Después de haber iterado varias veces por el ciclo de diseño / construcción / prueba / repetición, habrá acumulado habilidades y experiencia en los componentes de "peso pesado" que ahora le preocupan. Las iteraciones también le mostrarán la interconexión entre las diversas etapas y la documentación generada. La valiosa lección que se muestra allí es cómo un cambio de código de 5 minutos puede tener un efecto dominó de varias horas en otros lugares debido a las actualizaciones de documentos y los requisitos de prueba.

La experiencia con prácticas de "peso pesado" solo proviene de hacer lo real. No hay forma de practicarlo efectivamente de manera aislada. Sin embargo, puedes estudiarlo. Hay muchos estudios de casos y fuentes que puede estudiar y reflexionar.

Sin embargo, no todas las prácticas que ve o estudia son necesariamente positivas. El desarrollo de software es algo fluido, y lo que parece duro y estricto hoy puede parecer tonto y redundante mañana. Esto sucede tanto a través de nuevas herramientas como de experiencia experimental que brota de nuevas empresas a organizaciones más conservadoras.

Básicamente, la gestión de cambios y riesgos parece tener una forma única para cada organización. Su mejor opción es mantener una mente abierta, pero no lleve demasiadas suposiciones de un equipo a otro.