Governança de desenvolvimento em conjunto
Estabelecer uma estrutura de governança de desenvolvimento em conjunto eficaz é uma parte importante para garantir consistência e capacidade de repetição em projetos definidos pelo criador e equipes de fusão. Este artigo descreve uma abordagem para definir um fluxograma de governança.
Definindo o processo de ponta a ponta
Você pode usar o processo a seguir como exemplo e personalizá-lo de acordo com as melhores práticas da sua organização. Não é necessário concluir todas as etapas, desde que você alcance o resultado desejado.
Adicionar recursos à lista de pendências
As listas de pendências permitem que você planeje seu projeto adicionando recursos que impulsionam a experiência geral. A lista de pendências também fornece o roteiro geral que a equipe pretende entregar.
Ao adicionar um novo recurso à lista de pendências, a meta é descrever o escopo geral. Cada recurso define o valor comercial, os títulos das histórias de rascunho, o escopo e as alterações no modelo de dados que impulsionam os esforços de desenvolvimento de código.
Além disso, ao adicionar um recurso crítico para os negócios, é recomendável identificar todos os cenários críticos para automatizar seus testes. Depois de adicionar os recursos, você pode agendar a Reunião de Alinhamento de Escopo.
Reunião de alinhamento de escopo
O foco dessa reunião deve se limitar a revisar cada novo recurso proposto e, em seguida, verificar se há aplicativos, cenários ou modelos de dados existentes que já fornecem essa funcionalidade para evitar a duplicação de esforços. Essa reunião também oferece a oportunidade de discutir o impacto em outros aplicativos. Por fim, você deve verificar se esse recurso requer uma Revisão de Experiência.
Adicionar histórias e storyboard à lista de pendências
Após a reunião de alinhamento do escopo, qualquer título de história em rascunho do usuário pode ser adicionado ao recurso. Nesse ponto, os detalhes não são necessários e o status da história do usuário é "Novo". Você pode exibir as histórias na lista de pendências ou na exibição de quadro.
A figura a seguir mostra uma história de usuário de amostra adicionada a uma lista de pendências.
Nesse ponto, é vital manter a qualidade organizando o trabalho por aplicativo e fluxo de trabalho. Essa abordagem ajuda a manter os itens de trabalho relacionados juntos e permite que os especialistas em cada fluxo de trabalho desenvolvam e mantenham uma compreensão profunda da funcionalidade e do uso de dados em cada aplicativo.
Revisão de experiência
As Revisões de Experiência devem se concentrar na experiência do usuário final e garantir que sua equipe siga as melhores práticas organizacionais. Essa consistência garante que todos os seus aplicativos forneçam uma experiência confiável e repetível para usuários finais e equipes de suporte.
Adicionar detalhes da história
Adicionar uma história de usuário típica pode incorporar as seguintes informações:
- Título: Como um(a) <persona>, eu posso <do something> de modo a <impact/priority/value>
- Descrição: A descrição inclui determinados (entre outros) detalhes importantes, como:
- Breve descrição do cenário que resume o resultado desejado
- Narrativa – descreve as ações que os usuários executarão para navegar e realizar o cenário
- Narrativa alternativa – descreve outras maneiras pelas quais os usuários podem alcançar o mesmo resultado
- Notas de Design – registra a entidade, os campos, as exibições, as telas de modelo e as regras de negócios associados à história do usuário
- Direitos de Acesso Afetados – lista todos os direitos de acesso afetados ou que são relevantes para a história do usuário.
Depois de adicionar todos esses detalhes, é possível alterar o estado da história do usuário para "Pronto para revisão". Na maioria dos casos, a equipe de recursos e a equipe de negócios (se aplicável) revisam as histórias do usuário.
Revisão da história
As Revisões de História geralmente ocorrem dentro da equipe de fusão para garantir que todos os detalhes sejam destacados na história e que não haja ambiguidade. Após a conclusão de todas as revisões, a recomendação é atribuir a história do usuário a um membro da equipe. Garantir que sua equipe permaneça alinhada durante o processo de desenvolvimento é essencial para atingir as metas gerais.
Adicionar tarefas e casos de teste
Depois de revisar as histórias, os membros da equipe criam tarefas no Azure DevOps. O processo geral para adicionar tarefas e casos de teste é o seguinte:
- Abra uma lista de pendências do sprint. Se desejar, crie um novo sprint.
- Adicione itens de trabalho existentes ao sprint. Se você já adicionou itens de trabalho que não aparecem no sprint, verifique sua área e caminhos de iteração. Lembre-se de atribuir quaisquer tarefas órfãs aos itens de trabalho relevantes.
- Adicione tarefas aos itens da lista de pendências. Se você não tiver itens da lista de pendências atribuídos ao seu sprint, faça isso agora. Além disso, defina as datas de início e término do sprint.
- Preencha o formulário da tarefa. Como regra geral, as tarefas devem ser concluídas em um dia. As tarefas que precisarem ultrapassar essa escala de tempo devem ser divididas.
- Acompanhe ou integre todas as tarefas órfãs. Você pode rastrear tarefa órfãs, assim como outras tarefas, ou arrastá-las para um item da lista de pendências existente para atribuir um pai a elas.
Depois de adicionar tarefas e casos de teste, você pode definir a capacidade do sprint.
Para obter mais informações sobre como adicionar tarefas, confira Adicionar tarefas aos itens da lista de pendências para dar suporte ao planejamento do sprint.
Preparar soluções
Um aspecto importante para o co-desenvolvimento bem-sucedido é um processo estruturado de gerenciamento de versões. As soluções são o mecanismo para implementar o gerenciamento do ciclo de vida de aplicativos (ALM). Você as usa para distribuir componentes entre ambientes por meio de atividades de exportação e importação. Um componente representa um artefato usado em seu aplicativo e algo que você pode potencialmente personalizar. Qualquer coisa que possa ser incluída em uma solução será um componente, como tabelas, colunas, telas e aplicativos baseados em modelo, fluxos do Power Automate, chatbots, gráficos e plug-ins.
Importante
Durante o planejamento da liberação, determine a estratégia para gerenciar soluções no seu projeto. Use soluções para gerenciar seu projeto e encontre facilmente os componentes que você criou para distribuir para outros ambientes.
Implantações
Os componentes podem levar vários sprints para serem concluídos, dependendo da complexidade e da velocidade da equipe. Os componentes devem ser adicionados a uma solução em um ambiente de desenvolvimento à medida que as tarefas são concluídas. As soluções são então importadas para um ambiente de produção após serem testadas. Recomendamos que você também mantenha um ambiente de teste para realizar testes de ponta a ponta e experimentar a implantação da solução antes de entrar em produção.
Ambientes do Power Platform
Ambientes são espaços para armazenar, gerenciar e compartilhar dados corporativos, aplicativos e processos empresariais da organização. Eles também servem como ambientes para separar aplicativos que podem ter diferentes funções, requisitos de segurança ou públicos-alvo.
Se a sua organização tiver uma configuração de fusão de várias equipes em que cada equipe está desenvolvendo suas próprias soluções, é importante coordenar a duração dos sprints e versões. Os sprints não precisam ter uma duração consistente ao longo do cronograma do projeto e podem variar em duração entre as equipes, de acordo com as preferências de cada grupo. No entanto, a cadência de lançamento não pode ser inferior à duração mais curta do sprint em todas as equipes.
Controle do código-fonte
Adote um sistema de controle de código-fonte como o Azure DevOps. O Azure DevOps oferece serviços do desenvolvedor para que as equipes de suporte planejem o trabalho, colaborem no desenvolvimento do código, além de criar e implantar aplicativos.
Exporte uma solução do seu ambiente de desenvolvimento contendo seus aplicativos e personalizações, descompacte sua solução e armazene os componentes em seu sistema de controle de origem.
Tópico avançado: Revisões de solicitação de pull (PR)
Você só deve criar PRs para histórias que estão ativas e tiveram recursos revisados e aprovados. Você deve garantir que o controle de versão da solução seja preciso, seguindo as diretrizes de sprint e desenvolvimento estabelecidas em Implementar práticas de Scrum para sua equipe no Azure Boards. Os resultados do teste do PR podem ser capturas de tela ou vídeos que retratem a funcionalidade que está sendo desenvolvida.
Automatizar o processo de governança de PR ajuda a garantir a qualidade do código sem exigir uma revisão manual de verificações básicas, como versões de solução.
Observação
Use a ferramenta Verificador de PR para automatizar o processo de verificação da solicitação de pull.
Modelos e padronização
Os modelos e a padronização proporcionam eficiência, ajudando a promover a consistência dentro da equipe. Todos os aspectos das operações da equipe— sejam tarefas de integração, apresentações de revisão de histórias ou modelos de itens de trabalho que ajudam a economizar tempo e fornecem orientação às equipes ao definir histórias de usuários, recursos, bugs ou tarefas— beneficie-se da padronização e simplificação.
Implementando um modelo de suporte eficaz
Um modelo de suporte eficaz é essencial para o sucesso de longo prazo de um aplicativo após sua implantação, conforme destacado na seção anterior sobre a geração de uma matriz de suporte. Bugs e interrupções são inevitáveis, por isso é essencial que a equipe tenha uma abordagem estruturada para lidar com essas ocorrências e que a matriz de suporte forneça a estrutura necessária.
Criando o contrato de nível de serviço
Um fator chave em qualquer modelo de suporte é a definição do SLA (Contrato de Nível de Serviço). O SLA deve ser um documento formal elaborado pela equipe que contém seções que abrangem os seguintes itens:
- Interrupções – que nível de interrupção do serviço é aceitável, a quem informar, quais ações tomar, confirmação da retomada do serviço e ações para evitar uma repetição. Quaisquer procedimentos de teste automatizados que a equipe use precisam estar alinhados à tolerância de interrupção esperada e ao SLA aplicável.
- Bugs – quem pode notificar, atribuição de níveis de gravidade, classificação, ações de detecção, quem é responsável pela resolução e aprovação.
- Escalonamentos – níveis de escalonamento, atribuição de pessoal aos níveis, responsabilidades em cada nível, listas de distribuição para cada nível e assim por diante.
O SLA deve ser armazenado no portal de documentação da equipe e atualizado conforme necessário.
Fornecendo suporte a aplicativos
A melhor abordagem para fornecer o suporte ao aplicativo especificado no SLA é que a equipe que criou a solução também seja responsável por dar o suporte. As vantagens desse sistema são:
- Incentiva o desenvolvimento de melhor qualidade, porque quem criou o aplicativo sabe que terá que dar suporte.
- Os criadores poderão encontrar e corrigir bugs mais rapidamente do que uma equipe terceirizada, simplesmente porque conhecem melhor o aplicativo.
- Delegar a correção de software de missão potencialmente crítica a outro grupo pode ser desmoralizante e demorado para esse grupo. Assim como em outras fases de criação, desenvolvimento e implantação de aplicativos, a equipe de fusão deve fazer parceria com a TI para obter assistência quando necessário.
Monitorando a satisfação e a usabilidade do aplicativo
A parte final do esforço de suporte é monitorar e avaliar a satisfação e a usabilidade do aplicativo implantado. As métricas são úteis aqui, juntamente com métodos mais tradicionais, como sondagens e questionários. Para obter mais informações sobre como monitorar o uso do aplicativo, confira Análise de administrador para Power Apps.
Por fim, se os clientes não estiverem usando um aplicativo publicado, esse aplicativo não estará cumprindo sua finalidade. Reuniões regulares de revisão podem verificar essas métricas de satisfação e usabilidade para criar um loop de comentários positivos que podem alterar ou adicionar histórias à lista de pendências de modo a gerar e implantar uma versão atualizada do aplicativo.
Resumo
O desenvolvimento de ferramentas sem código ou pouco código, como o Power Apps, ampliou as opções de criação, desenvolvimento e implantação de aplicativos para criadores ou tecnólogos de negócios. Esse desenvolvimento funciona melhor em um ambiente de equipe de fusão, composto por um proprietário de produto, um especialista de domínio, um desenvolvedor profissional e um administrador, trazendo outros recursos conforme a necessidade.
A integração de abordagens de desenvolvimento ágil e scrum nas equipes de fusão resulta em desenvolvimento de aplicativos mais rápido e maior probabilidade de implantação bem-sucedida com um conjunto de recursos que faz uma diferença significativa para os negócios. Ao aplicar essas melhores práticas, diretrizes e recomendações, sua equipe de fusão poderá usar o Power Apps para enfrentar os desafios de transformação digital da sua organização.