Recomendações para formalizar o desenvolvimento e a gestão de software

  • Artigo

Aplica-se a esta recomendação de lista de verificação de Excelência Operacional do Azure Well-Architected Framework:

OE:03 Formalizar processos de planeamento e ideais de software. Desenhe a partir de normas da indústria e organizacionais estabelecidas. Utilize um registo de tarefas pendentes com prioridades comuns e especificações suficientemente detalhadas. Com base nos resultados, impulsione melhorias contínuas no seu processo de planeamento.

Este guia descreve as recomendações para gerir as práticas de desenvolvimento de software de acordo com as normas estabelecidas. A capacidade da sua equipa de produzir software de alta qualidade depende de uma abordagem estruturada e colaborativa para o planeamento do desenvolvimento. Os proprietários e gestores de produtos têm de conseguir compreender e articular claramente aos intervenientes o trabalho que os programadores estão a fazer em qualquer altura num ciclo de desenvolvimento. Por outro lado, os programadores têm de compreender os objetivos do ciclo de desenvolvimento através de funcionalidades bem escritas, histórias de utilizador e critérios de aceitação. As normas estabelecidas definem a forma como as práticas de desenvolvimento devem ser executadas e permitem que a equipa de cargas de trabalho colabore eficazmente, reduzindo o risco de confusão em termos de objetivos e expectativas.

Principais estratégias de conceção

Formalize as suas práticas de desenvolvimento de software para ajudar a garantir que os proprietários de produtos, gestores de projetos e programadores compreendem os objetivos de cada sprint e fornecem qualidade consistente aos intervenientes. Para rever as orientações sobre as práticas de desenvolvimento, veja o guia de integração contínua.

Normas para o planeamento do desenvolvimento

  • Colaboração: o processo de definição de alterações propostas à carga de trabalho deve ser um esforço de colaboração. A maioria das alterações à carga de trabalho afetará várias funções e/ou componentes, pelo que envolver o maior número possível de membros da equipa de cargas de trabalho ajudará a garantir que não são perdidas considerações importantes e que todos estão cientes do impacto no seu domínio específico. A colaboração também ajuda a definir claramente o âmbito de uma alteração e como dividir as tarefas necessárias necessárias para realizar a alteração em itens de trabalho bem definidos, uma vez que um grupo maior com conhecimentos em domínios poderá fornecer estimativas com experiência para o esforço necessário.

  • Ferramentas: utilize ferramentas e processos estabelecidos e comprovados pela indústria, como quadros Ágil, Scrum e Kanban. Desenvolver as suas próprias ferramentas e processos é uma tarefa significativa, tendo tempo e ciclos de desenvolvimento que, de outra forma, poderiam ser gastos na sua carga de trabalho. A maioria dos engenheiros e proprietários de produtos do DevOps mais experientes estão familiarizados com estes tipos de ferramentas e processos, pelo que a curva de aprendizagem na sua adoção deve ser mínima. Da mesma forma, o processo de integração de novas contratações também beneficiará da utilização de ferramentas e processos padrão, uma vez que é provável que já tenham um certo grau de exposição às mesmas ferramentas e processos.

Compromisso: a metodologia ágil pode tornar-se demasiado rigorosa se for excessivamente prescritiva. Esforce-se por um equilíbrio entre normas bem definidas e inovação.

  • Implementação: planeie a utilização de implementações pequenas e iterativas frequentes em vez de grandes implementações pouco frequentes. A utilização desta abordagem ajudará a manter as histórias de utilizador e os itens de trabalho geríveis do ponto de vista da gestão de projetos e reduzirá o risco de problemas em grande escala quando as implementações falham.

  • Termos: uniformize a sua definição de ciclos de desenvolvimento concluídos para ajudar a garantir que as funções de suporte, incluindo as funcionalidades de teste, documentação e acessibilidade, são concluídas com êxito.

  • Comunicação: defina os protocolos padrão para proprietários de produtos e gestores de projetos promoverem lançamentos futuros interna e externamente. Por exemplo, pode estabelecer uma norma para comunicações com entidades externas sobre lançamentos futuros. A norma pode ditar que a comunicação deve ser enviada duas semanas antes do lançamento e um lembrete deve ser enviado 24 horas antes do lançamento.

  • Histórias de utilizador: uniformize um modelo para histórias de utilizador. Certifique-se de que cada história de utilizador é uma unidade de trabalho discreta, escrita na perspetiva do utilizador final. As histórias de utilizador bem escritas devem ter as seguintes características:

    • Cada história de utilizador deve ser totalmente independente uma da outra. Manter as histórias de utilizador independentes umas das outras evita qualquer confusão com trabalho sobreposto e ajuda a equipa a compreender se o trabalho numa determinada história de utilizador depende do trabalho de outras pessoas, o que ajuda no agendamento e na atribuição de prioridades.

    • Cada história de utilizador é negociável. As perspetivas dos membros da equipa de utilizadores finais e cargas de trabalho são essenciais para capturar histórias de utilizador realistas que podem ser realizadas durante um curto período de tempo.

    • As histórias de utilizador são valiosas para o utilizador final. Quando escreve histórias de utilizador a partir da perspetiva do utilizador final, captura as alterações que estão interessadas em ver e que irão acrescentar valor à sua experiência. Manter este foco à medida que a história do utilizador é dividida em itens de trabalho ajuda a garantir que cada implementação proporciona uma experiência melhorada.

    • O esforço necessário para uma história de utilizador é estimável com um elevado grau de confiança. Sem poder ter uma aproximação aproximada das horas necessárias para uma determinada história de utilizador, o planeamento será difícil e o potencial de falta de prazos aumenta, potencialmente causando efeitos em cascata noutros trabalhos planeados.

    • As histórias de utilizadores bem escritas são pequenas, para que possam ser concluídas dentro de algumas semanas. Histórias de âmbito mais pequenas ajudam a mantê-las estimáveis e geríveis e ajudam a manter os itens de trabalho exequíveis.

    • As histórias de utilizador devem ser testáveis. Sem conseguir testar se uma funcionalidade foi fornecida, o utilizador final não pode ter a confiança de que o objetivo foi alcançado. Mesmo que ainda não tenha sido escrito um teste para uma determinada história de utilizador, deve haver uma compreensão clara de como um teste pode ser desenvolvido para provar a entrega da funcionalidade.

  • Critérios de aceitação: uniformize um modelo para critérios de aceitação. Certifique-se de que os critérios de aceitação se relacionam especificamente com a história do utilizador e que podem ser provados de forma inequívoca através de um ou mais testes de aceitação.

  • Rastreio: certifique-se de que o processo de desenvolvimento é rastreável. Deve rastrear claramente o estado da carga de trabalho de produção e o código associado para testes de garantia de qualidade, critérios de aceitação, histórias de utilizador e funcionalidades. O rastreio detalhado também pode ser um requisito regulamentar em alguns casos, como os cuidados de saúde, por exemplo.

  • Revisão: efetue regularmente auditorias internas às suas práticas de desenvolvimento através de retrospetivas e pós-morte do ciclo de desenvolvimento. A reflexão do processo deve ser irrepreensida e deve concentrar-se na aprendizagem que pode ser aplicada como melhorias. Certifique-se de que a equipa reflete sobre a eficácia da história e das tarefas do utilizador na definição das tarefas necessárias e na precisão das estimativas de tempo.

  • Relatórios: uniformize relatórios para intervenientes que fornecem métricas úteis focadas na alteração. Concentrar-se na alteração permite-lhe controlar a aceleração e a desaceleração do produto. As métricas úteis podem incluir alterações em:

    • A taxa de crescimento mensal da adoção.

    • Desempenho.

    • Tempo de preparação.

    • A frequência dos incidentes.

    Os relatórios não devem ser utilizados como uma ferramenta para avaliar o trabalho de indivíduos, por isso evite métricas como pontos de história ou linhas de código para cada engenheiro.

Facilitação do Azure

O Azure Boards é um serviço baseado na Web que permite que as equipas planeiem, controlem e discutam o trabalho em todo o processo de desenvolvimento. É adequado para práticas de desenvolvimento baseadas em Ágil.

O GitHub Projects é uma ferramenta de gestão de projetos personalizável que pode organizar projetos e integra-se com problemas e pedidos Pull no GitHub.

Lista de verificação de Excelência Operacional

Veja o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional