Governação de codesenvolvimento

Estabelecer uma arquitetura de governação de codesenvolvimento eficaz é uma parte importante de assegurar a consistência e a repetibilidade em projetos definidos por criadores e em equipas de fusão. Este artigo descreve uma abordagem para definir um fluxograma de governação.

Definir o processo de ponto a ponto

Pode utilizar o processo que se segue como exemplo e personalizá-lo de acordo com as melhores práticas da sua organização. Não é necessário concluir cada um dos passos, desde que alcance o resultado necessário.

Adicionar caraterísticas ao registo de tarefas pendentes

Os registos de tarefas pendentes permitem-lhe planear o projeto adicionando caraterísticas que impulsionam a experiência global. O registo de tarefas pendentes também fornece o mapa de objetivos global que a empresa pretende fornecer.

Quando adiciona uma nova caraterística ao registo de tarefas pendentes, o objetivo é descrever o âmbito geral. Cada caraterística define o valor de negócio, escreve títulos de histórias de rascunho, âmbito e alteração ao modelo de dados que impulsionam os esforços de desenvolvimento de código.

Além disso, ao adicionar uma caraterística essencial para o negócio, recomendamos que identifique quaisquer cenários críticos para automatizar os testes. Depois de adicionar a(s) caraterística(s), pode agendar a sua Reunião de Alinhamento de Âmbito.

Reunião de alinhamento de âmbito

O foco desta reunião deverá ser limitado a rever cada nova caraterística proposta e, em seguida, verificar se existem aplicações, cenários ou modelos de dados que já forneçam esta funcionalidade para evitar a duplicação de esforços. Esta reunião também fornece a oportunidade de debater o impacto noutras aplicações. Por último, deve verificar se esta caraterística necessita de uma Revisão de Experiência.

Adicionar dados e guião gráfico ao registo de tarefas pendentes

Após a reunião de alinhamento de âmbito, é possível adicionar quaisquer títulos de rascunho de história do utilizador sob a caraterística. Neste momento, não são necessários detalhes e o estado da história do utilizador é "Nova". Pode ver histórias na vista do quadro ou registo de tarefas pendentes.

A figura que se segue mostra um história de utilizador de amostra adicionada a um registo de tarefas pendentes.

Nesta altura, é essencial manter a qualidade organizando o trabalho por fluxo de trabalho e aplicação. Esta abordagem ajuda a manter os itens de trabalho relacionados juntos e permite que os especialistas em cada fluxo de trabalho desenvolvam e mantenham um conhecimento profundo da funcionalidade e utilização de dados em cada aplicação.

Revisão da experiência

As Revisões da Experiência devem focar-se na experiência de utilizador final e garantir que a sua equipa segue as melhores práticas organizacionais. Esta consistência assegura que todas as suas aplicações proporcionam uma experiência dependente e repetível para utilizadores finais e equipas de suporte.

Adicionar detalhes da história

Ao adicionar uma história de utilizador típica poderá incorporar as seguintes informações:

1. Título: Como <persona>, posso <do something> para que <impact/priority/value>
2. Descrição: a descrição inclui (embora não se limite a) determinados detalhes-chave, tais como:
   • Breve descrição do cenário que resume o resultado pretendido
   • Narrativa – descreve as ações que os utilizadores irão efetuar para navegar e conseguir o cenário
   • Narrativa alternativa – descreve outras formas de os utilizadores poderem conseguir o mesmo resultado
   • Notas de Design – regista os campos de entidade, as vistas, os ecrãs de maquetas e as regras de negócio associados à história do utilizador
   • Direitos de Segurança Afetados – lista todos os direitos de utilizador afetados ou que são relevantes para a história do utilizador.

Depois de adicionar todos estes detalhes, o utilizador mudaria o estado da história do utilizador para "Pronta para Revisão". Na maioria dos casos, a equipa de caraterísticas e a equipa de negócio (se aplicável) são quem revê as histórias do utilizador.

Revisão da história

Normalmente, as Revisões de História ocorrem dentro da equipa de fusão, de forma a garantir que todos os detalhes são mencionados na história e que não existe ambiguidade. Após a conclusão de todas as revisões, a recomendação é atribuir a história de utilizador a um membro da equipa. Certificar-se de que a sua equipa permanece alinhada durante o processo de desenvolvimento é essencial para alcançar os seus objetivos globais.

Adicionar tarefas e testar casos

Depois de rever as histórias, os membros da equipa criam tarefas no Azure DevOps. O processo global para adição de tarefas e testes de casos é o seguinte:

1. Abra um registo de tarefas pendentes de sprint. Em alternativa, crie um novo sprint.
2. Adicione itens de trabalho existentes ao sprint. Se já tiver adicionado itens de trabalho que não apareçam no sprint, deverá verificar a área deles e os percursos de iteração. Lembre-se de atribuir quaisquer tarefas não hierarquizadas aos itens de trabalho relevantes.
3. Adicione tarefas a itens de registo de tarefas pendentes. Se não tiver itens de registo de tarefas pendente atribuídos ao sprint, faça-o agora. Defina também as datas de início e de fim do sprint.
4. Preencha o formulário de tarefas. Como regra geral, as tarefas não deverão demorar mais de um dia a concluir. As tarefas superiores a esta escala temporal devem ser dividas.
5. Monitorize ou integre quaisquer tarefas não hierarquizadas. Pode monitorizar tarefas não hierarquizadas tal como outras tarefas ou arraste-as para um item de registo de tarefas pendente existente para as hierarquizar.

Depois de adicionar tarefas e casos de teste, pode definir a capacidade de sprint.

Para mais informações sobre a adição de tarefas, consulte Adicionar tarefas a itens de registo de tarefas pendentes para suportar o planeamento de sprint.

Preparar soluções

Um aspeto importante para o co-desenvolvimento com êxito é um processo de gestão de lançamentos estruturado. As soluções são o mecanismo de implementação da gestão do ciclo de vida das aplicações (ALM); são utilizadas soluções para distribuir componentes nos ambientes através de atividades de exportação e importação. Um componente representa um artefacto utilizado na sua aplicação e algo que pode personalizar potencial. Tudo o que pode ser incluído numa solução é um componente, como tabelas, colunas, aplicações de tela e condicionadas por modelos, fluxos do Power Automate, chatbots, gráficos e plug-ins.

Implementações

Os componentes podem implicar vários sprints até serem concluídos, dependendo da complexidade e da velocidade da equipa. Os componentes devem ser adicionados a uma solução num ambiente de desenvolvimento à medida que as tarefas são concluídas. Em seguida, as soluções são importadas para um ambiente de produção depois de testadas. Recomendamos também a manutenção de um ambiente de teste para e execução de testes ponto a ponto e tente a implementação da solução antes de ir para produção.

Ambientes do Power Platform

Os ambientes são um espaço para armazenar, gerir e partilhar os dados de negócio, as aplicações e os processos de negócio da sua organização. Também servem como contentores para aplicações separadas 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 com várias equipas onde cada uma desenvolve as suas próprias soluções, é importante coordenar a duração dos sprints e das versões. Os sprints não têm de ter um comprimento consistente ao longo de uma linha cronológica do projeto e podem variar de acordo com a duração entre equipas, de acordo com as preferências de cada grupo. No entanto, a cadência da versão não pode ser inferior à duração de sprint mais curta em todas as equipas.

Controlo de origem

Considere a adoção de um sistema de controlo de código de origem como o Azure DevOps. O Azure DevOps fornece serviços de programadores para equipas de suporte para planear trabalho, colaborar no desenvolvimento de código e criar e implementar aplicações.

Exportar uma solução a partir do ambiente de desenvolvimento que contém as suas aplicações e personalizações, desempacotar a solução e armazenar os componentes no sistema de controlo de origem.

Tópico avançado: Solicitar revisões de pedidos (PR)

Só deve criar PR para histórias que estão ativas e que tenham as funcionalidades revistas e aprovadas. Deverá certificar-se de que a aplicação de controlo de versões da solução é precisa seguindo as orientações de desenvolvimento e sprint definidas em Implementar práticas de Scrum para a sua equipa no Azure Boards. Os resultados de teste do PR podem ser capturas de ecrã ou vídeos que descrevem a funcionalidade que está a ser criada.

A automatização do processo de governação de PRs ajuda a garantir a qualidade do código sem necessitar de uma revisão manual de verificações básicas, tais como versões de solução.

Modelos e padronização

Os modelos e a padronização proporcionam eficácia, ajudando a promover a consistência dentro da equipa. Todos os aspetos das operações da equipa – quer sejam tarefas de inclusão, apresentações de revisão de histórias ou modelos de itens de trabalho que ajudam a poupar tempo e fornecem orientação às equipas quando definem histórias de utilizador, caraterísticas, erros ou tarefas – beneficiam da padronização e simplificação.

Implementar um modelo de suporte eficaz

Um modelo de suporte eficaz é essencial para o êxito a longo prazo de uma aplicação após a sua implementação, como é realçado na secção anterior sobre a geração de uma matriz de suporte. Os erros e as interrupções de serviço são inevitáveis, pelo que é essencial que a equipa tenha uma abordagem estruturada para lidar com estas ocorrências, sendo que a matriz de suporte fornece a arquitetura necessária.

Criar o contrato de nível de serviço

Um fator-chave em qualquer modelo de suporte é a definição do Contrato de Nível de Serviço (SLA). O SLA deverá ser um documento formal que a equipa prepara que contém secções que abrangem os seguintes itens:

• Interrupções de serviço – que nível de interrupção de serviço é aceitável, quem informar, que ações tomar, confirmação da retoma do serviço e as ações para impedir uma repetição. Todos os procedimentos de teste automatizados que a equipa utilize têm de estar em alinhamento com a tolerância de interrupção de serviço esperada e com o SLA aplicável.
• Erros – quem pode notificar, atribuição de níveis de gravidade, classificação, ações sobre a deteção, quem é responsável por resolver e assinar.
• Escalamentos – níveis de escalamento, atribuição de pessoal a níveis, responsabilidades a cada nível, listas de distribuição para cada nível, e assim por diante.

O SLA deverá ser armazenado no portal de documentação da equipa e atualizado conforme necessário.

Fornecer suporte a aplicações

A melhor abordagem para fornecer o suporte a aplicações especificado no SLA é a equipa que criou a aplicação também ser a responsável pelo seu suporte. As vantagens deste sistema são:

1. Fomenta um desenvolvimento de melhor qualidade, porque quem criou a aplicação sabe que tem de a suportar.
2. Os criadores poderão encontrar e corrigir erros mais rapidamente do que uma equipa de terceiros, simplesmente porque conhecem melhor a aplicação.
3. Delegar a correção de software potencialmente crítico para o funcionamento para outro grupo pode ser desmoralizador e demorado para esse grupo. Tal como com outras fases da criação, desenvolvimento e implementação de aplicações, a sua equipa de fusão deverá ter uma parceria com o TI para obter assistência quando necessário.

Monitorizar a satisfação e capacidade de utilização da aplicação

A parte final do esforço de suporte é a monitorização e a avaliação da satisfação e da capacidade de utilização da aplicação implementada. As métricas são úteis aqui, juntamente com métodos mais tradicionais, como consultas e questionários. Para mais informações sobre a monitorização da capacidade de utilização da aplicação, consulte Análise de Administração para o Power Apps.

Em última análise, se os clientes não utilizarem uma aplicação publicada, essa aplicação não está a satisfazer o seu propósito. As reuniões regulares de revisão podem verificar estas métricas de satisfação e capacidade de utilização para criar um ciclo de comentários positivo que pode alterar ou adicionar histórias ao registo de tarefas pendentes para gerar e implementar uma versão atualizada da aplicação.

Resumo

O desenvolvimento de ferramentas sem código e de pouco código, como o Power Apps tem opções expandidas para tecnólogos de negócio ou criadores para criarem, desenvolverem e implementarem aplicações. Este desenvolvimento funciona melhor num ambiente de equipa de fusão, o qual incluí um proprietário de produto, um especialista de domínio, um programador profissional e um administrador, com esta equipa a trazer outros recursos conforme necessário.

A integração de abordagens de scrum e desenvolvimento ágeis e dinâmicas em equipas de fusão resulta num desenvolvimento mais rápido das aplicações e numa maior probabilidade de implementação com êxito com um conjunto de caraterísticas que faz uma diferença significativa no negócio. Ao aplicar estas melhores práticas, orientações e recomendações, a sua equipa de fusão poderá utilizar o Power Apps para abordar os desafios de transformação digital da sua organização.