Executando o SCRUM com o JIRA: Guidelines para Times Ágeis de Desenvolvimento

Executando o S CRUM com o J IRA: Guidelines para Times ´ Ageis de Desenvolvimento Claudio Matsuoka1 , Glauco Gomes1 , Thiago Garrett1 1

CITS – Centro Internacional de Tecnologia de Software Rua do Semeador, 702 - CEP 81270-050 - Curitiba - Paran´a - Brasil {cmatsuoka,glaucogomes,thgarrett}@gmail.com

Abstract. S CRUM is one of the most popular frameworks for implementing agile where products are built in a series of fixed-length iterations. There are four pillars that bring structure to this framework: sprint planning, stand ups (also called daily scrums), sprints, and retrospectives. J IRA Software comes with a comprehensive set of agile tools that help scrum teams to perform these events with ease. Scrum is so popular, in fact, that many people think scrum and agile are the same thing. They’re not. Many frameworks can be used to implement agile, such as K ANBAN for example, but S CRUM has a unique flavor because of the commitment to short iterations of work. K ANBAN methodology is based on the idea of continuous releases. Work is tracked using a kanban board that displays the statuses of work in columns and lanes. J IRA Software can run K ANBAN with scrum teams. Resumo. O S CRUM e´ um dos frameworks mais populares para implementar desenvolvimento a´ gil, onde os produtos s˜ao constru´ıdos em iterac¸o˜ es de comprimento fixo. Existem quatro pilares que sustentam o framework: planejamento de sprint, stand ups (tamb´em chamado reuni˜oes di´arias), sprints e retrospectivas. O J IRA disponibiliza um conjunto abrangente de ferramentas a´ geis que ajudam os times de desenvolvimento a realizar esses eventos com facilidade. O S CRUM e´ t˜ao popular, na verdade, que muitas pessoas pensam que S CRUM e ´ s˜ao a mesma coisa. Eles n˜ao s˜ao. Muitos frameworks podem ser utilizados Agil para implementar a´ gil, como o Kanban por exemplo, mas o S CRUM tem uma caracter´ıstica u´ nica por causa do compromisso dos times com iterac¸o˜ es curtas de trabalho. A metodologia K ANBAN e´ baseada na ideia de lanc¸amentos cont´ınuos. O trabalho e´ rastreado usando um quadro (chamado de kanban) que exibe os status do trabalho em colunas e faixas. O J IRA disponibiliza um quadro kanban eletrˆonico para times que executam o S CRUM como framework a´ gil.

1. Introduc¸a˜ o Este documento tem como objetivo servir como um guia para a utilizac¸a˜ o da ferramenta J IRA1 dentro de uma execuc¸a˜ o a´ gil de desenvolvimento de software utilizando o S CRUM2 . Este guia n˜ao deve ser tomado como absoluto. Cada time de desenvolvimento deve adapta-lo a` s suas pr´oprias necessidades e preferˆencias. J IRA e´ um software comercial desenvolvido pela empresa Australiana Atlassian. E´ uma ferramenta que permite o monitoramento de tarefas e acompanhamento de projetos garantindo o gerenciamento de todas as suas atividades em u´ nico lugar. 2 O S CRUM e´ um framework iterativo e incremental utilizado para o desenvolvimento a´ gil. 1

Este documento est´a organizado da seguinte forma: a sec¸a˜ o 2 descreve as configurac¸o˜ es necess´arias, tanto as globais como as do projeto; a sec¸a˜ o 3 descreve cada est´agio do K ANBAN, suas respectivas atribuic¸o˜ es e workflow dentro do J IRA; a sec¸a˜ o 4 resume as convenc¸o˜ es adotadas pelo time de desenvolvimento; a sec¸a˜ o 5 conclui o documento.

2. Configurac¸o˜ es do J IRA Esta sec¸a˜ o descreve as configurac¸o˜ es do J IRA necess´arias para a execuc¸a˜ o de sprints no formato definido pelo time de desenvolvimento. S˜ao necess´arias configurac¸o˜ es globais do J IRA (Issue Types e workflow Schemes, por exemplo) e configurac¸o˜ es espec´ıficas para cada projeto (criar um K ANBAN3 , por exemplo). As subsec¸o˜ es seguintes descrevem as configurac¸o˜ es globais e de projeto, respectivamente. 2.1. Configurac¸o˜ es Globais As sub-subsec¸o˜ es seguintes definem as configurac¸o˜ es globais do J IRA, ou seja, configurac¸o˜ es que s˜ao utilizadas por todos os projetos. E´ necess´ario acesso administrativo no J IRA para realizar estas configurac¸o˜ es. 2.1.1. Issue Types No J IRA, issues s˜ao “unidades de trabalho”, ou seja, um trabalho a ser realizado, como tickets em um sistema de rastreio de bugs. Um issue pode representar uma tarefa, uma est´oria, um e´ pico, um bug, etc. A configurac¸a˜ o Issue Types define tipos de issues. Definimos os seguintes Issue Types: • Story: representa uma est´oria; • Task: representa uma tarefa. Este tipo deve ser marcado como sub-task, para que seja poss´ıvel subordina-lo a uma Story; • Unplanned Task: representa uma tarefa n˜ao planejada. Deve ser marcado como sub-task da mesma forma que o tipo Task; • Epic: representa um e´ pico; • Bug: um bug reportado pelo QA. Os demais Issue Types presentes no J IRA n˜ao ser˜ao utilizados. 2.1.2. Issue Type Scheme Um Issue Type Scheme agrupa todos os Issue Types. Portanto deve ser criado um scheme com todos os tipos que ser˜ao usados no projeto: Story, Epic, Task, Unplanned Task e Bug. 2.1.3. Statuses Esta configurac¸a˜ o define os estados que as issues poder˜ao assumir no workflow. Cada estado ser´a mapeado posteriormente com uma coluna do K ANBAN. Definimos os seguintes statuses: 3

K ANBAN e´ uma metodologia de sinalizac¸a˜ o para controle de fluxo de operac¸a˜ o aplicada em ind´ustrias de forma geral. No setor de TI, K ANBAN e´ uma ferramenta visual de gest˜ao de fluxo de desenvolvimento.

• • • • •

TODO: tasks a serem feitas; WIP: tasks sendo feitas; Review: tasks esperando revis˜ao ou com a revis˜ao em progresso; QA: tasks esperando teste ou com testes em progresso; Integration: tasks esperando para serem integradas no trunk ou com a integrac¸a˜ o em progresso; • Done: tasks prontas; • Impediment: tasks paradas por algum impedimento. Os demais statuses presentes no J IRA n˜ao ser˜ao utilizados.

2.1.4. Resolutions Esta configurac¸a˜ o define os poss´ıveis estados finais de uma issue. Definimos apenas um, que deve ser marcado como padr˜ao (default): • Done: task documentada, revisada, testada e integrada. As demais resolutions presentes no J IRA n˜ao ser˜ao utilizadas. 2.1.5. Fields E´ poss´ıvel definir campos personalizados para as issues. Estes campos podem ser adicionados a todas as issues (global) ou para tipo(s) espec´ıfico(s) (story, epic, task, unplanned task e/ou bug). Um campo que deve ser criado para as issues Bug, Task e Unplanned Task e´ o RCA (Root Cause Analysis), com tipo texto livre. Neste ponto e´ necess´ario definir quais campos ser˜ao obrigat´orios em cada tipo de issue e remover os restantes. 2.1.6. Priorities E´ poss´ıvel definir quais prioridades as issues podem assumir. Estas prioridades n˜ao s˜ao usadas pelo plugin de S CRUM do J IRA, mas podem ser utilizadas internamente pelo time (para definir ordem de resoluc¸a˜ o das atividades durante uma sprint, por exemplo). Neste ponto as prioridades que ser˜ao utilizadas s˜ao definidas. 2.1.7. Screens E´ poss´ıvel definir quais campos (fields) ser˜ao exibidos nas telas de criac¸a˜ o, edic¸a˜ o e visualizac¸a˜ o de issues. Uma tela de transic¸o˜ es do workflow deve ser criada com o campo Assignee. Esta tela ir´a aparecer sempre que uma atividade passar de uma coluna para outra do K ANBAN, possibilitando que a mesma seja desatribu´ıda ou atribu´ıda a algu´em. As telas de criac¸a˜ o, edic¸a˜ o e visualizac¸a˜ o de issues devem ser personalizadas apenas com os campos que ser˜ao utilizados.

2.1.8. Workflow O workflow define as poss´ıveis transic¸o˜ es de estados que as issues poder˜ao sofrer. Pode ser visto como uma “m´aquina de estados” de atividades. Na pr´atica, restringe a movimentac¸a˜ o das tasks dentro do K ANBAN, por exemplo: se no workflow existe uma transic¸a˜ o do estado TODO para o estado WIP, ser poss´ıvel mover a task entre as colunas correspondentes a estes estados. Caso esta transic¸a˜ o n˜ao exista, n˜ao ser poss´ıvel mover a task. A cada transic¸a˜ o deve ser associada a screen de transic¸a˜ o criada anteriormente. O workflow definido encontra-se na figura 1.

Figura 1. Workflow implementado no J IRA

2.1.9. Workflow Scheme No Workflow Scheme e´ necess´ario mapear(assign) todos os Issue Types (story, epic, task, unplanned task e bug) com o workflow que ser´a utilizado. 2.2. Configurac¸o˜ es do Projeto As sub-subsec¸o˜ es seguintes definem as configurac¸o˜ es necess´arias em cada projeto do J IRA. 2.2.1. Configurac¸o˜ es Gerais As seguintes opc¸o˜ es devem ser alteradas conforme as configurac¸o˜ es globais descritas na subsec¸a˜ o anterior: • Project Lead: e´ o Scrum Master / l´ıder t´ecnico do time; • Issue Types: usar o Issue Type Scheme correto; • Workflows: usar o Workflow e Workflow Scheme corretos;

• Screens: usar o Screen Scheme correto; • Fields: usar o Field Configuration Scheme correto; • Roles: um Project Leader como Administrator e os outros como Developers. E´ necess´ario permiss˜ao de administrador no J IRA para estas configurac¸o˜ es. 2.2.2. Agile As configurac¸o˜ es da parte Agile s˜ao feitas pelo administrador do projeto (quem det´em o Project Lead) e n˜ao necessitam de permiss˜ao de administrador no J IRA. O administrador do projeto deve criar um board associado ao seu projeto e selecionar a pr´e-configurac¸a˜ o “Scrum” (cont´em as configurac¸o˜ es para story points e outros aspectos do S CRUM). As configurac¸o˜ es do board que devem ser alteradas s˜ao: • Card Colours: a cor de cada tipo de issue: – Story: amarelo; – Task: amarelo; – Unplanned Task: roxo; – Bug: vermelho. • Colunas: as colunas do K ANBAN: – TODO: mapear com estado TODO; – WIP: mapear com estado WIP; – Review: mapear com estado Review; – QA: mapear com estado QA; – Integration: mapear com estado Integration; – Done: mapear com estado Done. – Impediment: mapear com estado Impediment. 2.2.3. Criando est´orias e atividades As est´orias devem ser adicionadas na aba Plan com o Issue Type Story ou epic. A prioridade das est´orias e´ ditada pela ordem em que est˜ao no backlog. A ordem pode ser alterada clicando e arrastando com mouse. Para criar as atividades, selecione uma est´oria e, na tela de visualizac¸a˜ o da est´oria na direita, clique no bot˜ao Create sub-task. Esta task deve ser criada unassigned, ou seja, n˜ao designada para ningu´em. 2.2.4. Criando uma Sprint Para criar uma sprint clique em Create Sprint e informe a data de comec¸o e fim. Apos isto, arraste as est´orias desejadas do backlog para a sprint, informando os story points de cada est´oria no campo a direita da descric¸a˜ o da mesma. Lembre-se de criar as atividades de cada est´oria antes de iniciar a sprint. Atividades criadas apos o in´ıcio da sprint ser˜ao n˜ao-planejadas e, portanto dever˜ao ser criadas com o Issue type Unplanned task. Como ser´a descrito na sec¸a˜ o 4, e´ necess´ario criar duas est´orias adicionais em cada sprint: est´oria de in´ıcio (criac¸a˜ o de reposit´orio, etc., quando aplic´avel) e est´oria final

(usada para conferir a meta). Al´em disso, e´ necess´ario criar uma atividade de “teste de aceitac¸a˜ o” para cada est´oria.

3. K ANBAN Esta sec¸a˜ o descreve o K ANBAN definido pelo time de desenvolvimento dentro do J IRA, assim como sua utilizac¸a˜ o ao longo da sprint. As colunas e suas respectivas caracter´ısticas s˜ao: • TODO: atividades a serem desenvolvidas – Qualquer pessoa pode pegar para si atividades unassigned; – No caso de atividades assigned, somente a pessoa para qual a atividade est´a designada pode pegar a atividade; – Para pegar uma atividade a pessoa deve movˆe-la para a coluna WIP, fazer um assign para si e colocar um coment´ario na atividade dizendo que comec¸ou o desenvolvimento da mesma. • WIP: atividades em desenvolvimento – Ao iniciar uma atividade, deve ser criado um branch do trunk no reposit´orio S VN. Todo o desenvolvimento e´ feito dentro deste branch. Mais detalhes na sec¸a˜ o 4; – O c´odigo deve ser comentado usando JAVADOCS; – Ao t´ermino do desenvolvimento a tarefa deve ser movida para a coluna Review, um coment´ario deve ser adicionado informando que o desenvolvimento est´a pronto e por fim a atividade deve ser alterada para unassigned; – O desenvolvedor deve criar os testes unit´arios referentes ao que foi feito na atividade; – Uma atividade que n˜ao requer revis˜ao, testes e integrac¸a˜ o deve ser movida direto para a coluna Done. • Review: atividades esperando para serem revisadas, ou atualmente em revis˜ao – As atividades dispon´ıveis para revis˜ao devem estar unassigned; – Para iniciar a revis˜ao de uma atividade o desenvolvedor deve fazer assign da atividade para si e adicionar um coment´ario na mesma informando que iniciou a revis˜ao; – Atividades designadas para uma pessoa (assign) devem ser revisadas apenas por esta pessoa; – Em caso de modificac¸o˜ es triviais (coment´ario, pequeno bloco de c´odigo) o revisor deve manter a atividade na coluna Review, fazer assign da atividade para o desenvolvedor original da atividade e avisa-lo para que revise as modificac¸o˜ es feitas pelo revisor; – Em caso de modificac¸o˜ es(ou sugest˜oes) complexas o revisor deve conversar com o desenvolvedor original da atividade para decidirem o que ser´a feito; – Ao t´ermino da revis˜ao o revisor deve mover a atividade para a coluna QA, um coment´ario deve ser adicionado informando que a revis˜ao est´a pronta e por fim a atividade deve ser alterada para unassigned. • QA: atividades esperando pelo QA, ou atualmente em processo de QA – As atividades dispon´ıveis para QA devem estar unassigned; – Para iniciar o processo de QA o testador deve fazer assign da atividade para si e adicionar um coment´ario na mesma informando que iniciou;

– Caso seja encontrado algum defeito na atividade, ela deve ser movida para a coluna TODO, um coment´ario deve ser adicionado explicando o defeito (descric¸a˜ o e passos para reproduzir) e deve ser feito assign da atividade para o desenvolvedor original, para que ele corrija o problema. – Ao t´ermino do processo de QA, sem defeitos, a atividade deve ser movida para a coluna Integration, um coment´ario deve ser adicionado informando que o processo de QA foi finalizado com sucesso e por fim a atividade deve ser alterada para unassigned. • Integration: atividades esperando para serem integradas, ou atualmente sendo integradas – As atividades dispon´ıveis para integrac¸a˜ o devem estar unassigned; – Para iniciar a integrac¸a˜ o o desenvolvedor deve fazer assign da atividade para si e adicionar um coment´ario na mesma informando que iniciou a integrac¸a˜ o; – Para efetuar a integrac¸a˜ o e´ necess´ario primeiramente atualizar o branch da atividade fazendo um merge do trunk para o branch, o que chamamos de sync. Os conflitos s˜ao resolvidos e ent˜ao e´ feito um reintegrate (um tipo de merge) do branch para o trunk; – Em caso de conflitos simples, o integrador deve resolvˆe-los e completar a integrac¸a˜ o; – Em caso de conflitos complexos, o integrador tenta resolve-los e ent˜ao conversa com o desenvolvedor original da atividade para que ele revise e/ou retrabalhe a atividade – Ao t´ermino da integrac¸a˜ o a atividade deve ser movida para a coluna Done e um coment´ario deve ser adicionado contendo um resumo de todas as pessoas que trabalharam na atividade: “Signed-off by:”, “Reviewed by:”, “Tested by:”, “Integrated by:”. • Done: atividades finalizadas – Uma atividade finalizada significa que ela foi apropriadamente documentada, revisada, testada e integrada. • Impediment: atividades bloqueadas por algum impedimento – Uma atividade nesta coluna est´a bloqueada devido a algum impedimento. O Scrum Master deve resolver o impedimento o mais r´apido poss´ıvel e passar a atividade para a coluna TODO.

4. Convenc¸o˜ es Esta sec¸a˜ o descreve as convenc¸o˜ es adotadas pelo time de desenvolvimento. 4.1. Ambiente O ambiente de desenvolvimento ser´a composto de: • A DT: E CLIPSE integrado com o SDK do A NDROID; • Plugin S VN para E CLIPSE: plugin S VN para o E CLIPSE. Este ser´a utilizado apenas para commits e merges de arquivos dentro do projeto do E CLIPSE, por limitac¸a˜ o do pr´oprio plugin; • Cliente S VN externo: cliente S VN externo para trabalhar com os arquivos fora do projeto do E CLIPSE (documentac¸o˜ es, design, etc); • Reposit´orio S VN: reposit´orio S VN com trunk, branches e tags; • J ENKINS: servidor de integrac¸a˜ o cont´ınua J ENKINS, configurado para executar os testes a cada commit feito no trunk.

4.2. Projeto de Testes Al´em de um projeto de desenvolvimento do E CLIPSE dever´a ser criado tamb´em um projeto de testes, utilizando A NDROID JU NIT. Cada desenvolvedor e´ respons´avel por criar os testes unit´arios da atividade em que est´a trabalhando. Estes testes ser˜ao executados pelo servidor de integrac¸a˜ o cont´ınua. 4.3. Est´oria inicial Cada sprint dever´a ter uma est´oria inicial contendo as atividades de inicializac¸a˜ o aplic´aveis, como por exemplo: • • • •

Criar reposit´orio S VN; Instalar servidor de integrac¸a˜ o cont´ınua J ENKINS; Criar projeto do E CLIPSE no trunk; Criar projeto de testes do E CLIPSE (A NDROID JU NIT) no trunk.

4.4. Est´oria final Cada sprint dever´a ter uma est´oria final contendo as atividades de finalizac¸a˜ o aplic´aveis, como por exemplo: • Testar o software como um todo; • Verificar se a meta foi atingida. 4.5. Testes de aceitac¸a˜ o Cada est´oria deve conter uma atividade de teste de aceitac¸a˜ o. Esta atividade consiste em verificar se o crit´erio de aceitac¸a˜ o da est´oria foi atingido. Falhas neste teste resultar˜ao na criac¸a˜ o de atividades n˜ao-planejadas para corrigir os problemas encontrados. 4.6. Idiomas As convenc¸o˜ es de idioma s˜ao: • C´odigo, com coment´arios e documentac¸a˜ o, em inglˆes; • Est´orias, atividades e respectivos coment´arios, no J IRA, em portuguˆes; • Coment´arios no S VN em portuguˆes; 4.7. Documentac¸a˜ o do c´odigo A documentac¸a˜ o do c´odigo ser´a feita utilizando JAVADOCS. O revisor do c´odigo n˜ao deve mover a atividade para QA se julgar que a documentac¸a˜ o do c´odigo n˜ao est´a suficiente. 4.8. Coment´arios S VN Os coment´arios de cada commit no S VN devem seguir padr˜ao a seguir, onde TASK-ID e´ o identificador da atividade no J IRA: [TASK-ID] Resumo ˜o do que foi feito. Descric ¸a

4.9. Branches e Integrac¸a˜ o Ao iniciar uma atividade, o desenvolvedor deve criar um branch a partir do trunk. O nome deste branch deve ser o identificador da atividade para a qual o mesmo foi criado. Todo o desenvolvimento, revis˜ao e testes s˜ao feitos dentro deste branch, mantendo o trunk limpo de qualquer c´odigo pass´ıvel de erros. Ao t´ermino do QA o branch deve ser reintegrado no trunk. Para isso, primeiramente e´ necess´ario atualizar o branch com todas as modificac¸o˜ es feitas no trunk. Isto e´ feito atrav´es de um merge do trunk para o branch (´e necess´ario estar trabalhando dentro do branch para esta operac¸a˜ o). Neste passo poder˜ao ocorrer conflitos, que devem ser resolvidos dentro do branch. Ap´os resolvidos os conflitos deve-se fazer um reintegrate, que e´ um tipo de merge do branch para o trunk (´e necess´ario estar trabalhando dentro do trunk para esta operac¸a˜ o). 4.10. Pair programming Caso haja desenvolvedores ociosos, devido a n˜ao existirem atividades a fazer ou as que est˜ao dispon´ıveis dependem de outras serem conclu´ıdas primeiro, uma poss´ıvel estrat´egia e´ o Pair programming, ocupando os desenvolvedores ociosos e melhorando a qualidade e produtividade das atividades em progresso.

5. Conclus˜ao Este documento apresentou um guia para a execuc¸a˜ o do framework a´ gil S CRUM dentro da ferramenta J IRA. Foram descritas todas as configurac¸o˜ es (globais e de projeto) definidas para os times a´ geis. O documento tamb´em descreveu o K ANBAN e como ele ser´a utilizado no decorrer do projeto. Todas as convenc¸o˜ es adotadas pelos times de desenvolvimento tamb´em foram apresentadas neste documento.

Referˆencias [Atlassian(2013)] @online Atlassian. Learn scrum with jira software, Marc¸o 2013. URL https://br.atlassian.com/agile/ how-to-do-scrum-with-jira-software. [Scrum Alliance(2013)] @online Scrum Alliance. Learn about scrum, Marc¸o 2013. URL https://www.scrumalliance.org/why-scrum.