Compartilhar via

Recomendações para formalizar práticas do gerenciamento de desenvolvimento de software

  • Artigo

Aplica-se a esta recomendação da lista de verificação de Excelência Operacional Bem Arquitetada: Power Platform

OE:03 Formalize o processo de ideação e planejamento do software, com base em padrões estabelecidos do setor e da organização. Use uma lista de especificações suficientemente detalhadas, comuns e de pendências priorizadas. Oriente melhorias contínuas no processo de planejamento com base nos resultados.

Este guia descreve as recomendações para gerenciar práticas de desenvolvimento da carga de trabalho de acordo com padrões estabelecidos. A capacidade da sua equipe de produzir software de alta qualidade depende de uma abordagem estruturada e colaborativa ao planejamento do desenvolvimento. As equipes de carga de trabalho devem entender e comunicar claramente às partes interessadas o trabalho que está sendo feito. Mais precisamente, as equipes de carga de trabalho devem ter uma visão clara do trabalho a ser feito em um ciclo de desenvolvimento e garantir que todas as partes interessadas estejam alinhadas sobre o "porquê" desse trabalho. Os padrões estabelecidos definem como as práticas de desenvolvimento devem ser realizadas e permitem à equipe de carga de trabalho colaborar efetivamente, reduzindo o risco de confusão em metas e expectativas.

Estratégias-chave de design

Formalize as práticas de desenvolvimento da carga de trabalho para ajudar a garantir um reconhecimento comum das metas e das expectativas.

Não trate as cargas de trabalho low-code como de baixa complexidade. Você ainda se beneficia da formalização do desenvolvimento e do geranciamento de cargas de trabalho low-code. Aprenda com outras equipes de desenvolvimento de software. Tenha uma matriz de decisão que determine o nível de formalização necessário com base na complexidade e criticidade da carga de trabalho.

Padrões do planejamento de desenvolvimento

Os padrões a seguir podem ajudar a você a projetar uma estratégia de planejamento de desenvolvimento abrangente.

  • Priorização: Planejar a ordem e o escopo do trabalho envolve entender o verdadeiro impacto e valor dos recursos da carga de trabalho no negócio. Isso também inclui a avaliação desses impactos em relação a outras solicitações de trabalho e o roteiro geral do produto ou do programa. Uma maneira de priorizar cargas de trabalho é avaliando o valor dos negócios de toda a carga de trabalho. Você também pode achar útil avaliar recursos da carga de trabalho individuais para o valor de negócios.

  • Categorização: Estabeleça processos que garantam que os aplicativos críticos tenham as proteções necessárias para suportá-los. Ao mesmo tempo, garanta que os cenários de produtividade não sejam desacelerados ou sufocados por muitos processos rigorosos.

  • Colaboração: O processo de definição de mudanças propostas na carga de trabalho deve ser um esforço colaborativo. A maioria das mudanças na carga de trabalho afeta diversas funções e componentes, portanto, envolver o maior número possível de membros da equipe de carga de trabalho ajuda a garantir que considerações importantes não sejam esquecidas e que todos estejam cientes do efeito 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 em itens de trabalho bem definidos. Um grupo maior com experiência em vários domínios é capaz de fornecer estimativas baseadas na experiência para o esforço necessário.

  • Ferramentas: Use ferramentas e processos estabelecidos e comprovados pelo setor, como Agile, Scrum e Quadros Kanban.

Compensação: A metodologia ágil pode se tornar muito rigorosa se for excessivamente prescritiva. Busque um equilíbrio entre padrões bem definidos e inovação.

  • Implantação: planeje usar implantações pequenas e iterativas frequentes em vez de implantações grandes e pouco frequentes.

  • 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 sucesso.

  • Comunicação: Defina os protocolos padrão para proprietários de produtos e gerentes de projeto para promover próximos lançamentos.

  • Histórias de usuários: Padronize um modelo para histórias de usuários. Histórias de usuário bem escritas devem seguir a abordagem INVEST:

    • I–Independente: cada história de usuário deve ser independente das outras, permitindo à equipe entregar em pequenas etapas incrementais.
    • N-Negociável: as histórias de usuário devem ser negociáveis e abertas a discussão e mudanças.
    • V–Valioso: As histórias de usuários devem fornecer valor ao cliente.
    • E–Estimável: as histórias de usuários devem ser estimáveis e ter uma definição clara do que é feito.
    • S–Pequeno: as histórias de usuário devem ser pequenas e concentradas em um único recurso.
    • T–Testável: as histórias de usuários devem ser testáveis e ter critérios de aceitação claros.

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

  • Rastreamento: Garanta que o processo de desenvolvimento seja rastreável. Você deve rastrear claramente o estado da carga de trabalho de produção e do código associado até os testes do controle 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 no setor de saúde.

  • Revisão: Realize regularmente auditorias internas de suas práticas de desenvolvimento por meio de retrospectivas e análises pós-ciclo de desenvolvimento. A reflexão do processo deve ser irrepreensível e se concentrar no aprendizado que pode ser aplicado como melhorias. Verifique se a equipe reflete sobre a eficácia da história e das tarefas de usuário 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 forneçam métricas úteis com foco na mudança. O foco na alteração permite a você acompanhar a aceleração e a desaceleração do produto. Entre as métricas úteis podem estar alterações em:

    • Taxa de crescimento mensal de adoção
    • Performance
    • Tempo de treinamento
    • Frequência de incidentes

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

Facilitação do Power Platform

Embora There não sejam Power Platform produtos que facilitem diretamente essa recomendação, você pode usar outras ferramentas na Microsoft pilha. O 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.

O GitHub Projects é uma ferramenta de geranciamento de projetos personalizável para organizar projetos e se integra aos seus problemas e solicitações de pull no GitHub.

Próximas etapas

Lista de verificação de excelência operacional