Como ganhar prática pessoal em metodologias de desenvolvimento de peso pesado?

Estou em um novo emprego em que o projeto precisa atender a rígidos padrões de qualidade, ser fortemente documentado, gerenciado com grande detalhe, diagramas UML e todas as coisas que são opostas à "codificação de cowboy", onde a maior parte da minha experiência profissional anterior foi . Pense na maneira como o software aeroespacial ou de dispositivos médicos em larga escala é desenvolvido.

Fico feliz em deixar o caos da codificação de cowboys e estou curioso para ver como os métodos de engenharia dos pesos pesados ​​vão. Mas como se pode ganhar rapidamente experiência com os métodos pesados?

Além de simplesmente estar no emprego por alguns meses / anos, isso é.

Com uma mera linguagem, ou uma nova API, é possível hackear um programa de teste de brinquedos, ler, deliberadamente cometer erros para ver o que acontece etc. Como se tornar bom em andar de bicicleta ou tocar um instrumento musical, a prática é essencial. É fácil pegar uma flauta e passar meia hora todos os dias; não há necessidade de ingressar em uma orquestra ou ser um consultor de flauta em tempo integral. Mas como praticar atividades de engenharia de software que são grandes e complexas, envolvem equipes, e grande parte delas é sobre comunicação e planejamento, além de evitar falhas de comunicação e exceder os limites de cronograma e orçamento?

Isso não parece possível fazer solo. Existe uma maneira de um pequeno número de pessoas simular a engenharia de um grande projeto inteiro em pequena escala em um curto período de tempo (um dia)?

Existe uma maneira de um pequeno número de pessoas simular a engenharia de um grande projeto inteiro em pequena escala em um curto período de tempo (um dia)?

Sim, isso é possível até certo ponto. Há cerca de dez anos, participei de um workshop na conferência OOP em Munique, onde 16 pessoas tiveram a tarefa de fazer uma análise e design aproximados para um software para pequenas empresas. A primeira metade do dia foi principalmente sobre encontrar uma estrutura de equipe para resolver a tarefa com 16 pessoas, e a segunda metade do dia focada em resolver a tarefa com essa equipe.

Durante a primeira parte, fomos orientados a dividir as 16 pessoas em grupos de quatro. Cada equipe de quatro pessoas teve que elaborar sugestões para a estrutura da equipe (sob pressão de tempo); depois, um processo de desempate foi aplicado para tomar uma decisão sobre qual estrutura da equipe seria a melhor e deveria ser usada para a segunda parte do workshop. .

Infelizmente, durante a primeira parte, cometemos o erro de tentar dar a cada uma das 16 pessoas um emprego dentro da estrutura de equipe pretendida. Esse erro levou ao caos no segundo semestre - porque 16 pessoas são demais para resolver essa tarefa. Uma solução de trabalho poderia ter sido dividir as 16 pessoas novamente em equipes menores, ou escolher 3 ou 4 pessoas para fazer o trabalho principal, mas no calor do momento que perdemos de ver isso.

Ainda tenho a impressão de que aprendi muito sobre problemas típicos que podemos enfrentar em organizações de projetos maiores naquele dia. Não sei onde você pode visitar esse tipo de oficina em algum lugar perto de você, ou quem oferece uma coisa dessas hoje em dia, mas se você tiver uma chance, eu recomendo participar.

Comece com uma lista de verificação . (Você sabia que esse era o primeiro passo, certo?)
Verifique se a lista de verificação lista toda a documentação padrão do seu projeto atual. ie Diagrama UML, especificação funcional, projetos de alto e baixo nível, etc. O engenheiro de sistemas em mim sugerirá o uso de um RTVM (matriz de verificação de rastreabilidade de requisitos)

Escolha um programa de amostra para trabalhar. Se você não conseguir criar um, "codifique katas" do Google ou consulte o arquivo de desafios do Google Codejam. Ou apenas construa uma calculadora. :-)

Crie a especificação funcional para o seu programa de amostra. Em seguida, passe para o design de alto nível, diagrama UML, etc ... Crie-o conforme as especificações. Teste-o. Toda vez que você encontrar uma falha significativa em suas especificações (conforme definido pelas práticas atuais de trabalho), precisará voltar ao estágio do SDLC e revisar antes de avançar novamente.

Para sua primeira rodada, vá em frente e mantenha-a pequena. Andar de bicicleta pelo processo é mais importante do que um exagero em qualquer estágio específico. Nas rodadas subsequentes, adicione os recursos que você parou. Rastreamento, registro, análise de desempenho, andaime de teste, etc. O que você deseja adicionar dependerá do que o empregador espera do seu trabalho real.

Depois de percorrer o ciclo de design / construção / teste / repetição várias vezes, você terá habilidades e experiência acumuladas nos componentes "pesados" que o preocupam agora. As iterações também mostrarão a interconexão entre os vários estágios e a documentação gerada. A lição valiosa que está sendo mostrada mostra como uma alteração de código de 5 minutos pode ter um efeito cascata de várias horas em outros lugares devido a atualizações de documentos e requisitos de teste.

A experiência com práticas "pesadas" vem apenas de fazer a coisa real. Não há como praticá-lo isoladamente. Você pode, no entanto, estudá-lo. Existem muitos estudos de caso e fontes que você pode estudar e ponderar.

Porém, nem todas as práticas que você vê ou estuda são necessariamente positivas. O desenvolvimento de software é uma coisa fluida, e o que parece hardcore e estrito hoje pode parecer tolo e redundante amanhã. Isso acontece tanto por meio de novas ferramentas quanto pela experiência experimental que vai das startups às organizações mais conservadoras.

Basicamente, o gerenciamento de mudanças e riscos parece ter uma forma única para cada organização. Sua melhor aposta é manter a mente aberta, mas não carregue muitas suposições de equipe para equipe.