evento
Campeonato Mundial do Power BI DataViz
14/02, 16 - 31/03, 16
Com 4 chances de participar, você pode ganhar um pacote de conferência e chegar ao LIVE Grand Finale em Las Vegas
Mais informaçõesGovernaçã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.
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.
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.
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.
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.
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.
Ao adicionar uma história de utilizador típica poderá incorporar as seguintes informações:
- Título: Como <persona>, posso <do something> para que <impact/priority/value>
- 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.
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.
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:
- Abra um registo de tarefas pendentes de sprint. Em alternativa, crie um novo sprint.
- 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.
- 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.
- 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.
- 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.
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.
Importante
Durante o planeamento da versão, determine a estratégia para gerir as soluções no seu projeto. Utilize as soluções para gerir o seu projeto e encontrar facilmente componentes que tenha criado para, em seguida, distribuir por outros ambientes.
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.
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.
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.
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.
Nota
Utilize a ferramenta de verificação de PRs para automatizar o processo de verificação de pedidos de emissã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 equipe, sejam tarefas de integração, apresentações de revisão de história ou modelos de item de trabalho que ajudam a economizar tempo e fornecem orientação às equipes ao definir histórias de usuários, recursos, bugs ou tarefas—, se beneficiam da padronização e simplificação.
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.
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.
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:
- Fomenta um desenvolvimento de melhor qualidade, porque quem criou a aplicação sabe que tem de a suportar.
- Os criadores poderão encontrar e corrigir erros mais rapidamente do que uma equipa de terceiros, simplesmente porque conhecem melhor a aplicação.
- 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.
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.
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.
Recursos adicionais
Formação
Módulo
Transformar a criação de software de negócios com equipes de desenvolvimento de fusão - Training
Aumente a eficiência e a produtividade do desenvolvimento de software com equipes de desenvolvimento de fusão.
Certificação
Certificado pela Microsoft: Power Platform Developer Associate - Certifications
Demonstre como simplificar, automatizar e transformar tarefas e processos de negócios usando o Microsoft Power Platform Developer.