O básico
Nosso DevOps está acessível de qualquer lugar através da URL https://ubcbr.visualstudio.com/. Lá podemos conferir nossos projetos de desenvolvimento online, com todos os nossos repositórios Git e nossos quadros do Scrum (Agile Taskboards), que na verdade têm muito do Kanban.
Os quadros kanban utilizados no scrum servem para definir tarefas, quem as faz e em que etapa estão. Na maioria dos casos utiliza-se TO DO para definir o que fazer, DOING para definir que tarefa está em andamento e DONE para tarefas concluídas.
Exemplo de um quadro de Kanban
A Microsoft está sempre mudando (nem sempre inovando, mas eles tentam), então, fica difícil fazer algo definitivo a respeito de algum produto deles, principalmente um tutorial. Mas hoje a tela inicial do nosso DevOps é esta:
Passando o cursor sobre um dos itens na lista, surgem alguns ícones. Utilizaremos muito os ícones de cor verde (Work items) e vermelha (Repos), que são os quadros e os repositórios, respectivamente.
Criando Projetos
Vamos voltar para a tela inicial e vamos criar um projeto. Talvez este não seja seu caso, pois é bem provável que você vá trabalhar em um projeto já existente, mas vamos aprender mesmo assim como é criado o projeto dentro do Azure DevOps. Nosso projeto estará dentro do DevOps para posterior consulta e testes.
Clique no botão “New project”:
Preencha com os dados necessários, deixe o projeto como privado e adote os padrões Git e Scrum:
Ao criar um novo projeto, automaticamente, é criado um time, cujo nome é sempre [Nome do Projeto] Team, com todos os desenvolvedores responsáveis por ele. Por costume e boa prática, é criado um time (equipe) com o mesmo nome do projeto no Microsoft Teams para comunicação do Product Owner (P.O., geralmente o Coordenador da equipe ou Gerente de TI ou Gerente de Desenvolvimento) e do Scrum Master (geralmente um Tech Leader) com toda a equipe.
Work items
Ao abrir esta tela, teremos uma lista com todas as tarefas, bugs e itens de backlog. Podemos fazer filtros nessa tela, mas não será o nosso foco nesse tutorial. Do seu lado esquerdo está uma barra lateral com ícones, passe o cursor sobre o verde e veja o menu que surge:
Das opções listadas vamos usar muito:
- Boards, que é onde criaremos as Features (não confundir com Feature do GitFlow) e seus respectivos Baklog Items;
- Backlogs, que vai nos dar a mesma visão dos Boards, mas de uma forma diferenciada, em lista com filtros e mais opções;
- Sprints, que é nada mais nada menos que um conjunto de tarefas de um determinado período, nos dá a visão dos Itens de backlog e Bugs a serem entregues em um determinado Sprint. Ao final do sprint, sempre é feita uma entrega, portanto, considere o sprint como uma etapa a ser concluída no projeto.
Vamos explicar cada um, mas antes vamos entender como, hierarquicamente, funcionam a Feature, o Backlog Item e a Task.
Entendendo os tipos de quadros
Um quadro criado no Azure DevOps pode ser do tipo:
Feature
Pense neste quadro como um recurso do sistema, algo importante que precisa ser implementado e entregue ao final. Por exemplo, seu sistema precisa enviar uma lista de titulares recém cadastrados via JSON para um Webservice, então o nome da sua feature pode ser “Enviar titulares para a Empresa X”.
Seu sistema pode ter vários recursos, então você terá vários quadros do tipo Feature. Exemplos:
- Autenticação
- Log de históricos de autenticação
- Atendimento ao cliente via chat
- Envio de titulares para sociedades estrangeiras
- Rotinas de Backup
- Logout seguro
Um Feature deve logicamente ter um ou mais itens de backlog.
Backlog Item
O item de backlog é nada mais nada menos que um item na fila para ser feito, cuja prioridade provavelmente ainda não foi definida. Ele fica dentro de uma Feature e deve, logicamente, possuir uma ou mais tarefas. Exemplos:
- Autenticação (Feature)
- Tela de login (Item de backlog 1)
- Entidades (Item de backlog 2)
- Controller (Item de backlog 3)
- Regras de negócio (Item de backlog 4)
Bug
Um quadro do tipo Bug é um quadro que trata de um erro do sistema, portanto, não precisa necessariamente ficar atrelado a uma Feature como o Backlog Item deve ficar. Mas também deve, logicamente, possuir uma ou mais tarefas atreladas a ele. Portanto, se durante a execução do projeto você detectar um erro, mesmo que a origem dele pertença a um sprint passado, crie um quadro do tipo Bug e dentro dele inclua as tarefas necessárias para corrigi-lo. Exemplo:
- Erros no sprint 3
- Erro na autenticação
- Erro na comunicação com webservice da sociedade ABC
Task
É uma tarefa que pertence a um item de backlog ou a um bug. A tarefa deve refletir as execuções rotineiras do desenvolvedor. Exemplos:
- Autenticação (Feature)
- Tela de login (Item de backlog 1)
- Estilizar tela com CSS (task)
- Escrever javascript (task)
- Escrever HTML (task)
- Entidades (Item de backlog 2)
- Criar ViewModel de autenticação (task)
- Criar Entidade LOGIN com mapeamento da tabela ADAWEB.LOGIN (task)
- Controller (Item de backlog 3)
- Criar index (task)
- Realizar submit do form com HTTP Post (task)
- Validar as regras de submit (task)
- Criar permissões (task)
- Regras de negócio (Item de backlog 4)
- Criar SQL para consulta do titular e autenticá-lo (task)
- Criar repositório (task)
- Salvar dados (task)
- Tela de login (Item de backlog 1)
Criando os quadros
Independente do sprint, vamos criar as Features pensando em tudo o que foi ensinado acima. Vá até o ícone “Backlogs”, que é a tela onde poderemos adicionar todas as features necessárias:
Próximo ao topo da página, do lado direito, há um menu. Mude de “Backlog items” para “Features”:
Agora você pode incluir uma feature:
A partir da sua nova feature, já podemos criar itens de backlog e bugs clicando no ícone “+”. Vamos criar um item de backlog clicando em Product Backlog Item:
Informe o título do item e descreva-o:
Note que quase ao final do formulário, há um quadro que indica a que feature este item estará atrelado:
Clique em “Save & Close”.
A seguir, clicando no ícone “+” ao lado do item de backlog, podemos criar uma tarefa:
Dê um nome para sua tarefa e descreva-a. Note que, no campo Iteration, a tarefa automaticamente irá para um Sprint (sempre o próximo):
A seguir informe quem será o responsável pela execução dela:
Note que ela ficará atrelada ao item de backlog que selecionamos antes:
Depois é só clicar em “Save & Close”.
Organizando seus Sprints
No menu lateral, selecione o ícone “Sprints” como explicado anteriormente:
A visão inicial será “Taskboard” e é justamente essa que vamos usar, pois ali estarão os quadros kanban que movimentaremos entre os estados TO DO (a fazer), IN PROGRESS (fazendo) e DONE (concluído). Todos os quadros que criamos, com a exceção das Features, aparecerão ali:
Adicionalmente, recomendo clicar no ícone “View options” e marcar a opção “Planning” para visualizar todos os sprints sem precisar sair da tela:
Feito isto, sua tela deverá estar assim:
Note que as Features NÃO aparecem nesta tela, somente itens de backlog, bugs e tarefas. Features não pertencem a nenhum sprint, pois estão um nível acima do backlog em nosso scrum.
Ao criar sprints, lembre-se sempre de definir um intervalo de data, que será o intervalo de trabalho deste sprint:
Geralmente ele vale por uma ou duas semanas, que é quando é feita a entrega de uma etapa:
Observe que ao definir um intervalo, o painel do lado direito mudará:
Mudando o estado de uma tarefa
Seus quadros podem ser movimentados livrementes pela tela, tanto o de tarefas (para TO DO, IN PROGRESS ou DONE) quanto os itens de backlog e bugs (para outros sprints, movendo-os para o painel do lado direito):
Podemos mudar também o colaborador responsável pela tarefa sem precisar sair da tela:
Podemos criar uma nova tarefa ali mesmo também clicando no ícone “+” de New Item:
Podemos continuar a mover os quadros e a definir colaboradores responsáveis:
E encerrar tudo ali mesmo, concluindo as tarefas e concluindo o item de backlog (desde que todas as tarefas estejam concluídas):
Podemos até mesmo criar novos sprints:
Finalizando...
Todos os analistas do setor de desenvolvimento estão adicionados como administradores do projeto Tutorial para fazer testes de forma livre.