Recomendações para formalizar o desenvolvimento e gestão de software
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 ideação e planeamento de software. Basear-se em padrões estabelecidos da indústria e da organização. Use uma lista de pendências comum e priorizada e especificações suficientemente detalhadas. Com base nos resultados, promova 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 claramente e articular com as partes interessadas o trabalho que os desenvolvedores estão fazendo a qualquer momento em um ciclo de desenvolvimento. Por outro lado, os desenvolvedores devem entender os objetivos 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 realizadas 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 rever as orientações sobre práticas de desenvolvimento, consulte o guia de integração contínua.
Estabelecer 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, já que um grupo maior com experiência em vários domínios será capaz de fornecer estimativas apoiadas pela experiência para o esforço necessário.
Comunicação: Definir 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. 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.
Revisão: realize regularmente auditorias internas de suas práticas de desenvolvimento por meio de retrospetivas e post-mortems do ciclo de desenvolvimento. A reflexão do processo deve ser irrepreensível e deve centrar-se na aprendizagem que pode ser aplicada como melhorias. Certifique-se de que a equipe reflita sobre a eficácia da história do usuário e das tarefas na definição das tarefas necessárias e na 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. O foco na mudança 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 treino.
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ã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 para novos contratados também se beneficiará do uso de ferramentas e processos padrão, pois é provável que eles já tenham um certo grau de exposição às mesmas ferramentas e processos.
Compensação: a metodologia ágil pode se tornar muito rígida se for excessivamente prescritiva. Procurar 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 de trabalho discreta, escrita a partir da perspetiva 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ários independentes umas das outras evita qualquer confusão com trabalho sobreposto e ajuda a equipe a entender se o trabalho em uma determinada história de usuário depende do trabalho em quaisquer outras, o que ajuda na programação e priorização.
Cada história de usuário é negociável. As perspetivas do usuário final e dos membros 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. Quando você escreve histórias de usuário da perspetiva do usuário final, você captura as mudanças que ele está interessado em ver e que 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 é estimável com um alto grau de confiança. Sem conseguir ter uma aproximação 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ário 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 confiança de que o objetivo foi alcançado. 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. Certifique-se de que os critérios de aceitação se relacionem especificamente com a 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 freqüentes em vez de implantações grandes e pouco frequentes. O uso dessa abordagem ajudará a manter as histórias de usuários e os itens de trabalho gerenciáveis do ponto de vista do gerenciamento de projetos e reduzirá o risco de problemas em grande 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: Garantir 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 rastreio detalhado também pode ser um requisito regulamentar em alguns casos, como os cuidados de saúde, por exemplo.
Facilitação do Azure
Os Painéis do Azure são um serviço baseado na Web que permite que as equipas planeiem, 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 integra-se usando problemas e solicitações pull no GitHub.
Ligações relacionadas
Ligações da comunidade
Lista de verificação de Excelência Operacional
Consulte o conjunto completo de recomendações.