Share via

Recomendações para formalizar o desenvolvimento e o gerenciamento 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 planejamento e ideação de software. Extraia dos padrões organizacionais e do setor estabelecidos. Use uma lista de pendências comum e priorizada e especificações suficientemente detalhadas. Com base nos resultados, impulsione melhorias contínuas em seu processo de planejamento.

Este guia descreve as recomendações para gerenciar práticas de desenvolvimento de software de acordo com os padrões estabelecidos. A capacidade de sua equipe de produzir software de alta qualidade depende de uma abordagem estruturada e colaborativa para o planejamento de desenvolvimento. Os proprietários e gerentes de produtos devem ser capazes de entender e articular claramente aos stakeholders o trabalho que os desenvolvedores estão fazendo a qualquer momento em um ciclo de desenvolvimento. Por outro lado, os desenvolvedores devem entender as metas do ciclo de desenvolvimento por meio de recursos bem escritos, histórias de usuários e critérios de aceitação. Os padrões estabelecidos definem como as práticas de desenvolvimento devem ser executadas e permitem que a equipe de carga de trabalho colabore efetivamente, reduzindo o risco de confusão em metas e expectativas.

Principais estratégias de design

Formalize suas práticas de desenvolvimento de software para ajudar a garantir que proprietários de produtos, gerentes de projeto e desenvolvedores entendam as metas de cada sprint e forneçam qualidade consistente aos stakeholders. Para examinar as diretrizes sobre as práticas de desenvolvimento, consulte o guia de integração contínua.

Padrões para planejamento de desenvolvimento

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

  • Ferramentas: use ferramentas e processos estabelecidos e comprovados pelo setor, como placas Agile, Scrum e Kanban. Desenvolver suas próprias ferramentas e processos é uma tarefa significativa, levando tempo e ciclos de desenvolvimento que, de outra forma, poderiam ser gastos em sua carga de trabalho. Os engenheiros e proprietários de produtos mais experientes do DevOps estão familiarizados com esses tipos de ferramentas e processos, portanto, a curva de aprendizado na adoção deles deve ser mínima. Da mesma forma, o processo de integração de novas contratações também se beneficiará do uso de ferramentas e processos padrão, pois eles provavelmente já terão um grau de exposição às mesmas ferramentas e processos.

Compensação: a metodologia Agile pode se tornar muito rigorosa se for excessivamente prescritiva. Esforce-se por um equilíbrio entre padrões bem definidos e inovação.

  • Implantação: planeje usar implantações pequenas e iterativas frequentes em vez de grandes implantações pouco frequentes. O uso dessa abordagem ajudará a manter histórias de usuários e itens de trabalho gerenciáveis do ponto de vista do gerenciamento de projetos e reduzirá o risco de problemas em larga escala quando as implantações falharem.

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

  • Comunicação: defina os protocolos padrão para proprietários de produtos e gerentes de projeto promoverem versões futuras interna e externamente. Por exemplo, você pode estabelecer um padrão para comunicações com partes externas sobre as próximas versões. O padrão pode determinar que a comunicação deve ser enviada duas semanas antes da versão e um lembrete deve ser enviado 24 horas antes da versão.

  • Histórias de usuário: padronizar um modelo para histórias de usuário. Verifique se cada história de usuário é uma unidade de trabalho discreta, escrita da perspectiva do usuário final. Histórias de usuário bem escritas devem ter as seguintes características:

    • Cada história de usuário deve ser totalmente independente uma da outra. Manter histórias de usuários independentes umas das outras evita qualquer confusão com o trabalho sobreposto e ajuda a equipe a entender se o trabalho em uma determinada história de usuário depende do trabalho de qualquer outra pessoa, o que ajuda no agendamento e na priorização.

    • Cada história de usuário é negociável. As perspectivas do usuário final e da equipe de carga de trabalho são essenciais para capturar histórias de usuário realistas que podem ser realizadas em um curto período de tempo.

    • As histórias de usuário são valiosas para o usuário final. Ao escrever histórias de usuário da perspectiva do usuário final, você captura as alterações que ele está interessado em ver e isso agregará valor à sua experiência. Manter esse foco à medida que a história do usuário é dividida em itens de trabalho ajuda a garantir que cada implantação forneça uma experiência aprimorada.

    • O esforço necessário para uma história de usuário é estimado com um alto grau de confiança. Sem poder ter uma aproximação próxima das horas necessárias para uma determinada história de usuário, o planejamento será difícil e o potencial de falta de prazos aumenta, potencialmente causando efeitos em cascata em outros trabalhos planejados.

    • As histórias de usuários bem escritas são pequenas, para que possam ser concluídas dentro de algumas semanas. Histórias com escopo menor ajudam a mantê-las estimadas e gerenciáveis e ajudam a manter os itens de trabalho realizaveis.

    • As histórias de usuário devem ser testáveis. Sem poder testar se um recurso foi entregue, o usuário final não pode ter confiança de que a meta foi cumprida. Mesmo que um teste ainda não tenha sido escrito para uma determinada história de usuário, deve haver uma compreensão clara de como um teste pode ser desenvolvido para provar a entrega do recurso.

  • Critérios de aceitação: padronizar um modelo para critérios de aceitação. Verifique se os critérios de aceitação estão relacionados especificamente à história do usuário e podem ser inequívocamente comprovados usando um ou mais testes de aceitação.

  • Rastreamento: verifique se o processo de desenvolvimento é rastreável. Você deve rastrear claramente o estado da carga de trabalho de produção e o código associado de volta ao teste de garantia de qualidade, aos critérios de aceitação, às histórias do usuário e aos recursos. O rastreamento detalhado também pode ser um requisito regulatório em alguns casos, como serviços de saúde, por exemplo.

  • Revisão: execute regularmente auditorias internas de suas práticas de desenvolvimento por meio de retrospectivas e postmortems do ciclo de desenvolvimento. A reflexão do processo deve ser irrepreensa e deve se concentrar no aprendizado que pode ser aplicado como melhorias. Certifique-se de que a equipe reflita sobre a eficácia da história e das tarefas do usuário na definição das tarefas necessárias e na precisão das estimativas de tempo.

  • Relatórios: padronizar relatórios para stakeholders que fornecem métricas úteis com foco na alteração. O foco na alteração permite acompanhar 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 treinamento.

    • A frequência dos incidentes.

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

Facilitação do Azure

Azure Boards é um serviço baseado na Web que permite que as equipes planejem, acompanhem e discutam o trabalho em todo o processo de desenvolvimento. Ele é adequado para práticas de desenvolvimento baseadas em Agile.

O GitHub Projects é uma ferramenta de gerenciamento de projetos personalizável que pode organizar projetos e integra-se usando problemas e solicitações de pull no GitHub.

Lista de verificação de Excelência Operacional

Consulte o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional