Recomendações para formalizar o desenvolvimento e gerenciamento de software
Aplica-se a esta recomendação da lista de verificação do Azure Well-Architected Framework Operational Excellence:
| OE:03 | Formalize os processos de ideação e planejamento de software. Utilize como base padrões organizacionais e setoriais 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 do desenvolvimento. Os proprietários e gerentes de produtos devem poder 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ário 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 de forma eficaz, reduzindo o risco de confusão sobre metas e expectativas.
Principais estratégias de design
Formalize suas práticas de desenvolvimento de software para ajudar a garantir que os proprietários de produtos, gerentes de projeto e desenvolvedores entendam os objetivos de cada sprint e forneçam qualidade consistente às partes interessadas. Para revisar as diretrizes sobre práticas de desenvolvimento, consulte o guia de integração contínua.
Estabeleça padrões de colaboração e comunicação
Colaboração: O processo de definição das alterações propostas para a 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 mudança e como dividir as tarefas necessárias para realizar a mudança em itens de trabalho bem definidos, pois um grupo maior com experiência em todos os domínios será capaz de fornecer estimativas baseadas na experiência para o esforço necessário.
Comunicação: Defina os protocolos padrão para proprietários de produtos e gerentes de projeto para promover os próximos lançamentos interna e externamente. Por exemplo, você pode estabelecer um padrão para comunicações com terceiros sobre versões futuras. O padrão 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.
Revisão: Realize regularmente auditorias internas de suas práticas de desenvolvimento por meio de retrospectivas do ciclo de desenvolvimento e autópsias. A reflexão do processo deve ser irrepreensível 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 sobre a precisão das estimativas de tempo.
Relatórios: padronize relatórios para as partes interessadas que fornecem métricas úteis com foco na mudança. Concentrar-se na mudança permite que você acompanhe a aceleração e a desaceleração do produto. Métricas úteis podem incluir alterações em:
A taxa de crescimento mensal de 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.
Escolha ferramentas padrão do setor
Use ferramentas e processos estabelecidos e comprovados pelo setor, como quadros 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. A maioria dos engenheiros de DevOps e proprietários de produtos experientes está familiarizada com esses tipos de ferramentas e processos, portanto, a curva de aprendizado para adotá-los deve ser mínima. Da mesma forma, o processo de integração para novas contratações também se beneficiará do uso de ferramentas e processos padrão, pois é provável que eles já tenham um grau de exposição às mesmas ferramentas e processos.
Compensação: A metodologia ágil pode se tornar muito rígida se for excessivamente prescritiva. Esforce-se por um equilíbrio entre padrões bem definidos e inovação.
Adote um padrão para capturar cenários de usuário final
Histórias de usuários: padronize um modelo para histórias de usuários. Certifique-se de que cada história de usuário seja uma unidade discreta de trabalho, 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 as histórias de usuário independentes umas das outras evita qualquer confusão com a sobreposição de trabalho e ajuda a equipe a entender se o trabalho em uma determinada história de usuário depende do trabalho em outras, o que ajuda no agendamento e na priorização.
Cada história de usuário é negociável. As perspectivas do usuário final e dos membros da equipe de carga de trabalho são essenciais para capturar histórias de usuários realistas que podem ser realizadas em um curto período de tempo.
As histórias de usuários são valiosas para o usuário final. Quando você escreve histórias de usuários da perspectiva do usuário final, você captura as mudanças que eles estão interessados em ver e que agregarão 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 é estimável com um alto grau de confiança. Sem ser capaz de 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 perda de prazos aumenta, potencialmente causando efeitos em cascata em outros trabalhos planejados.
Histórias de usuários bem escritas são pequenas, para que possam ser concluídas em poucas semanas. Histórias com escopo menor ajudam a mantê-las estimáveis e gerenciáveis e ajudam a manter os itens de trabalho realizáveis.
As histórias de usuários devem ser testáveis. Sem poder testar se um recurso foi entregue, o usuário final não pode ter certeza de que a meta foi alcançada. 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: padronize um modelo para critérios de aceitação. Certifique-se de que os critérios de aceitação estejam relacionados especificamente à história do usuário e possam ser comprovados de forma inequívoca usando um ou mais testes de aceitação.
Padronizar as práticas de implantação
Implantação: planeje usar implantações pequenas e iterativas frequentes em vez de implantações grandes e pouco frequentes. Usar essa abordagem irá ajudar a manter histórias de usuário 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: padronize 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.
Rastreamento: Certifique-se de que o processo de desenvolvimento seja rastreável. Você deve rastrear claramente o estado de sua carga de trabalho de produção e o código associado até testes de garantia de qualidade, critérios de aceitação, histórias de usuários e recursos. O rastreamento detalhado também pode ser um requisito regulatório em alguns casos, como na área da saúde, por exemplo.
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. É 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 se integrar usando problemas e solicitações de pull no GitHub.
Links relacionados
Links da comunidade
Lista de verificação de Excelência Operacional
Consulte o conjunto completo de recomendações.