Resumo—Em ambientes de desenvolvimento com poucos recursos é sempre um grande desafio implantar um processo devido as suas peculiaridades. Muitos processos de renome são baseados em grandes organizações o que torna ainda mais difícil sua implantação nestes ambientes. Modelos e ferramentas de processos como Scrum e Kanban surgem como alternativas viáveis a estes ambientes, por serem flexíveis o suficiente para se a adaptarem a eles. Neste artigo será apresentada uma proposta de processo baseado em Scrum e Kanban adaptados para uma empresa de telecomunicações.
Palavras chave—kanbam, metodologias agéis, processos, scrum, telecomunicação.
Abstract—In development environments with limited resources is always a challenge to deploy a process due to its peculiarities. Many well-known processes are based in large organizations which makes its implementation more difficult in these environments. Models and tools for processes such as Scrum and Kanban emerge as viable alternatives to these environments because they are flexible enough to adapt to them. In this article we shall propose a process based on Scrum and Kanban adapted for a telecommunications company.
Keywords—agile, kanbam, processes, scrum, telecommunication. I. INTRODUÇÃO
Projetos atrasados, mudança de escopo e insatisfação por parte dos clientes, estes são problemas comuns vividos nas empresas de desenvolvimento de software. Boa parte destes problemas se deve a falta de um processo definido para o desenvolvimento ou a impraticabilidade de um determinado processo.
Falta de recursos, acúmulo de papéis, fluxo não constante de projetos e manutenção de produtos existentes são problemas comuns vividos por muitas pequenas e médias empresas de desenvolvimento o que torna o dia a dia da gerência de projetos ainda mais difícil.
Diversos modelos, processos e metodologias se propõem a L. A. C. Garcia ([email protected]) e A. C. Soares ([email protected]) pertencem ao Centro de Ensino Superior em Gestão, Tecnologia e Educação – FAI. Av. Antônio de Cássia, 472 Santa Rita do Sapucaí – MG – Brasil – 37540-000
atender às necessidades destes cenários complexos e dinâmicos. Porém, boa parte deles não conseguem resultados satisfatórios por supor que estes cenários podem ser totalmente definidos, estimados e medidos [8].
Ao longo deste artigo serão abordados o modelo e a ferramenta de processo Scrum e Kanban; suas principais práticas e a maneira com que eles gerenciam o desenvolvimento de software. Será proposto um modelo de processo baseado nessa combinação para ambientes com poucos recursos e diversos projetos, incluindo manutenção.
II. SCRUM
Scrum é um modelo de processo ágil de desenvolvimento de software [5] constituído por um conjunto de práticas e regras utilizadas para gerenciar e controlar todo o desenvolvimento. O processo se dá de forma empírica tendo por base três pilares: transparência, inspeção e adaptação. Isso faz com que todos os envolvidos no processo conheçam seus aspectos e façam as adaptações necessárias para atingir seus objetivos. O Scrum utiliza em sua estrutura conceitos do modelo espiral, onde cada ciclo da espiral de desenvolvimento seria equivalente ao que no Scrum é conhecido como Sprint (Iteração) [6]. No início de cada Sprint, o time seleciona as tarefas que ele acredita terminar durante a Sprint. Após esta etapa, o time se concentra no trabalho, decidindo qual será a melhor maneira para se realizar todas estas tarefas. Durante a Sprint são feitos acompanhamentos constantes para identificar possíveis problemas que possam impedir a realização do trabalho. No final da Sprint é entregue um incremento do trabalho para análise dos responsáveis.
A arquitetura Scrum é composta por três papéis, cinco regras e três artefatos.
1. Os três papéis são: Product Owner1 (Proprietário do
produto), ScrumMaster [sic] e o time. Aqui não há referência direta com os papéis convencionais como 1 Optou-se pela utilização dos termos em inglês por serem amplamente
utilizados na literatura.
Proposta de processo baseado em Scrum e Kanban
para uma empresa de telecomunicações
Luís Augusto Cândido Garcia
Centro de Ensino Superior em Gestão, Tecnologia e Educação – FAI
Afonso Celso Soares
Centro de Ensino Superior em Gestão, Tecnologia e Educação – FAI
por exemplo Gerente de Projeto ou Arquiteto de Projeto, estes estão “diluídos” nos papéis citados, cada um com sua função específica.
2. As cinco regras são: Sprint Planning Meeting (Reunião de Planejamento da Iteração), Daily Scrum Meeting (Reunião Diária do Scrum), Sprint, Sprint Review Meeting (Reunião de Revisão da Iteração) e Sprint Retrospective Meeting (Reunião de Retrospectiva da Iteração). Nessas regras está o “coração” do Scrum, onde é feito todo o controle e adaptação necessários para alcançar o sucesso na realização do trabalho.
3. Os três artefatos são: Product Backlog (Lista de funcionalidades do produto), Sprint Backlog (Lista de funcionalidades para a iteração) e Burndown Chart (Gráfico de acompanhamento). Estes artefatos são utilizados para priorizar e acompanhar o trabalho. A. Os papéis
No Scrum exitem apenas três papéis para gerência e execução de todo o processo, ao contrário dos processos tradicionais onde existe toda uma hierarquia e definição detalhada de cada papel.
O Scrum exige que exista uma pessoa que tenha uma visão de negócio do produto e que esteja focado no retorno do investimento [7]. Essa pessoa é o Product Owner. Ele é o responsável por direcionar o trabalho do time a cada Sprint e por manter os interesses da empresa.
O time por sua vez é o responsável por desenvolver e gerenciar o desenvolvimento do produto. No Scrum o time é composto por volta de 5 a 10 integrantes auto organizados, decidindo pela melhor forma de realizar o trabalho durante a Sprint.
E por último para facilitar a comunicação entre o Product Owner e o time e garantir que as práticas do Scrum sejam seguidas existe a figura do ScrumMaster. O papel do ScrumMaster é a de um facilitador do processo, sendo sua responsabilidade remover todo bloqueio encontrado durante o trabalho e gerenciar as regras do Scrum.
B. Os artefatos
Os artefatos são ferramentas do Scrum que permitem organizar e acompanhar o trabalho de forma simples e direta. O Product Backlog é uma lista com as funcionalidades desejáveis do produto, sendo gerenciada pelo Product Owner. O Product Owner prioriza os itens dessa lista de acordo com o valor de negócio de cada item. Em seguida, o time monta a Sprint Backlog que conterá os itens mais prioritários do Product Backlog a serem desenvolvidos durante a Sprint. Durante a Sprint o acompanhamento será feito pelo Burndown Chart, que é um gráfico mostrando o andamento do Sprint, devendo ser atualizado durante as Daily Scrum Meetings. C. As regras
O Scrum tem nas suas regras a chave do seu sucesso, o seu
“coração”. Através das reuniões os envolvidos no processo conseguem identificar os bloqueios e os riscos do projeto e realizar adaptações para um trabalho mais rápido e mais organizado.
No início de cada Sprint, durante a Sprint Planning Meeting, o Product Owner de posse do Product Backlog, prioriza cada item para que sirva de referência para o time trabalhar no desenvolvimento do produto. Em seguida, com base em prioridades, o time seleciona as funcionalidades que ele acredita ser capaz de realizar durante uma Sprint, formando assim o Sprint Backlog.
Após a Sprint Planning Meeting o time se concentra na Sprint. O período de uma Sprint varia entre 2 a 4 semanas, onde o time reserva para trabalhar nas funcionalidades da Sprint Backlog. Após definido o tamanho da Sprint, o time pode alterar a quantidade de funcionalidades contidas na Sprint Backlog, sendo que a data final da Sprint deve continuar a mesma [6].
Para acompanhamento e gerência da Sprint são realizadas as Daily Scrum Meetings, que são as reuniões diárias. Através dessas reuniões é possível identificar possíveis riscos e impedimentos do projeto. Essas reuniões são rápidas, durando aproximadamente 15 minutos.
No final da Sprint é realizada a Sprint Review Meeting. Nessa reunião, o time apresenta ao Product Owner e outros interessados o resultado do trabalho. Nesse ponto, o produto deve estar funcional, ele já passou por todas as etapas do desenvolvimento: projeto, implementação e testes.
Após a Sprint Review Meeting, é realizado a Sprint Retrospective Meeting. O objetivo dessa reunião é reunir ideias para melhorar o processo. Segundo Kniberg [3] essa pode ser considerada depois da Sprint Planning Meeting o evento mais importante pois, é a hora de rever todo o processo e adaptá-lo para que a próxima Sprint seja ainda melhor.
III. KANBAN
Kanban é uma ferramenta de processo [4] criada como parte do Sistema de Produção Toyota (TPS – Toyota Production System) [1]. Seu principal objetivo é minimizar o trabalho em andamento, evitando assim os gargalos em determinadas fases do processo e os desperdícios da superprodução [1].
Para esse controle o Kanban utiliza 3 regras básicas: visualizar o fluxo de trabalho; minimizar o trabalho em andamento e calcular o tempo médio para conclusão de uma tarefa [4]. Para visualizar o fluxo do trabalho, o Kanban utiliza um quadro onde são feitas divisões que correspondem as etapas do fluxo do trabalho. Nesse quadro são fixados cartões que correspondem as tarefas a serem executadas. Parte da tarefa é executada em cada etapa do fluxo e após a sua conclusão o cartão é movido para a próxima etapa. Ao passar pela última etapa do fluxo, a tarefa deverá estar concluída.
Para evitar os desperdícios com a superprodução e os gargalos no processo, o Kanban limita o número de tarefas em cada etapa do fluxo. Ao terminar a execução de uma tarefa em uma determinada etapa, ela só pode ser encaminhada para a
próxima se esta ainda não atingiu seu limite, garantindo-se assim um fluxo constante de tarefas em execução [1].
Após determinar o limite de cada etapa do fluxo, é possível medir o tempo médio de conclusão de uma tarefa. Isso é de fundamental importância na negociação de prazos. O ideal é que este tempo médio seja o menor e mais previsível possível, ajudando a definir prazos mais realistas [4].
IV. PROCESSO PROPOSTO
A empresa, alvo do estudo, pertence ao ramo de telecomunicações onde o trabalho do desenvolvimento é composto por desenvolvimento de hardware, software embarcado e software aplicativo. A equipe2 de software
aplicativo, foco do processo proposto, é composta por nove desenvolvedores e um supervisor. O trabalho da equipe se divide em desenvolvimento de novos produtos, manutenção dos produtos já existentes e gerência de configuração. Muitas vezes, o mesmo desenvolvedor atua tanto no desenvolvimento, quanto na manutenção.
Manter a mesma equipe tanto no desenvolvimento quanto na manutenção impede que o time se comprometa durante um determinado período apenas ao desenvolvimento, pois não é possível prever quando surgirá uma nova manutenção e em alguns casos quanto tempo será gasto nessa manutenção. Isso pode fazer com que o time pare com o desenvolvimento para realizar uma manutenção por ser de maior prioridade [4]. Outra questão são os impedimentos que surgem durante o trabalho. Com apenas uma pessoa responsável por resolver esses impedimentos, no caso o supervisor, o trabalho torna-se lento algumas vezes, além de provocar sobrecarga na responsabilidade do supervisor.
Kniberg e Skarin [4] apresentam um estudo de caso de uma empresa onde o trabalho da equipe de desenvolvimento também era divido em desenvolvimento de novos produtos e manutenção de produtos já existentes. A empresa havia implantado Scrum no desenvolvimento e com isso vários impedimentos foram resolvidos e o desempenho da equipe cresceu. Porém, a imprevisibilidade das manutenções e a necessidade de priorização constante das tarefas tornavam o sistema de sprints do Scrum inviável.
Para esta empresa Kniberg e Skarin [4] implantaram um processo baseado no Scrum e Kanban, onde as principais mudanças foram a substituição das sprints pelo fluxo do trabalho do Kanban e a Sprint Planning Meeting passou a ser realizada semanalmente permitindo-se uma priorização constante das tarefas. Desta forma a empresa conseguiu conciliar o desenvolvimento e a manutenção na mesma equipe.
Embora o cenário da empresa descrita pelos autores seja parecido com o da empresa foco do estudo, em nenhum momento os autores relatam problemas como falta de recursos e fluxo variável de projetos, problemas estes vividos pela empresa foco do estudo.
2 Equipe são todas as pessoas que compõem uma divisão do desenvolvimento e time são as pessoas que pertencem a um projeto.
Portanto, será proposto um processo também baseado em Scrum e Kanban, mas com as adaptações necessárias a este cenário de poucos recursos e fluxo variável de projetos. A. Divisão dos papéis
A divisão dos papéis segue o modelo proposto pelo Scrum. Porém, na divisão dos times, o Scrum sugere de cinco a dez desenvolvedores e um ScrumMaster. Neste caso, como toda a equipe é composta por dez desenvolvedores, formam-se times com dois desenvolvedores ou até mesmo um único. Neste caso, devido a limitação de recursos apresentada no item I, propõe-se um ScrumMaster para times com 4 ou mais integrantes onde um dos integrantes seria o ScrumMaster. E um único ScrumMaster para times com 3 ou menos integrantes onde o ScrumMaster seria o próprio supervisor do departamento. A Figura 1 ilustra esta distribuição. Espera-se que o arranjo proposto traga maior agilidade e por conseguinte aumento de produtividade dos times. Não encontrou-se, na literatura pesquisada, nenhuma abordagem relacionada à sobrecarga de papéis, embora seja uma situação típica das pequenas e médias empresas de tecnologia.
A empresa possui o cargo de Gerente de Produtos que é quem analisa o mercado e traz as informações necessárias para o desenvolvimento dos produtos. Esta pessoa assumiria o papel de Product Owner dentro do desenvolvimento do produto, participando das cerimônias quando sua presença for necessária. Porém, a equipe de software aplicativo algumas vezes também desenvolve produtos para uso interno de outros departamentos da empresa. Neste caso, a pessoa responsável por este produto no outro departamento assumiria o papel de Product Owner, participando das cerimônias quando sua presença for necessária.
B. Os artefatos
Para acompanhamento e controle das atividades será utilizado um quadro do Kanban e os cartões usados seguirão o modelo da Figura 2.
Descrição dos campos do cartão:
• Código: é um número que identifica a funcionalidade
no Product Backlog;
• Projeto: é o nome do projeto que a tarefa pertence;
• Tamanho: é o tamanho da tarefa estimado em pontos
[3];
• Entrada: é a data em que a tarefa entrou no quadro
para ser feita;
• Finalizada: é a data em que a tarefa foi finalizada;
• Descrição: é uma breve descrição do que é para ser
feito nesta tarefa;
• Como demonstrar: segundo Kniberg [3] este campo
descreve como esta tarefa será demonstrada na Sprint Review Meeting e também pode ser utilizado para implementação dos testes.
Os campos Tamanho, Entrada e Finalizada serão utilizados para calcular a velocidade do time. Por exemplo, se uma tarefa entrou no quadro dia 20/06/2010 e foi finalizada dia 25/06/2010 e seu tamanho é 10 pontos, significa que o time demorou 5 dias para concluí-la dando uma média de 2 pontos por dia. Essa estimativa será utilizada na negociação de prazos.
Para identificar as tarefas de desenvolvimento e manutenção serão utilizados cartões de cores diferentes, como mostrado na Figura 3.
Estes cartões serão fixados em um quadro Kanban, onde todos visualizarão as tarefas e o fluxo que as tarefas seguirão dentro do processo. O quadro será montado conforme ilustrado na Figura 4.
O fluxo do processo no quadro segue da esquerda para a direita. No topo de cada coluna está o nome da etapa e a quantidade máxima de tarefas da etapa.
Toda tarefa nova será colocada na primeira coluna (A fazer), podendo ser tanto de desenvolvimento quanto de manutenção. A prioridade entre elas é de cima para baixo, onde tarefas do topo possuem maior prioridade, sendo que as tarefas de manutenção são mais prioritárias que as de desenvolvimento. A segunda coluna (Análise) será utilizada para as tarefas que
necessitem de uma análise prévia antes de serem executadas. Por exemplo, no caso das tarefas de manutenção, nem sempre é possível determinar a causa de um problema num projeto, requerendo primeiro uma análise. Após a análise, a tarefa é encaminhada para a etapa de Transferência, Execução ou
Finalizada caso não exista nenhuma manutenção a ser feita.
Como mencionado no início do capítulo, a empresa em estudo também desenvolve hardware e software embarcado e existe uma integração entre estes sistemas e os softwares aplicativos. Muitas vezes acontece de os problemas de um sistema refletirem no outro. Neste caso, quando uma tarefa de manutenção ao passar pela análise e for constatado que o problema é devido a outro sistema, esta será encaminhada para a coluna Transferência. Isso quer dizer que a tarefa está em análise por outra equipe e aguardando resposta. Após a resposta da outra equipe esta tarefa será encaminhada para a coluna Finalizada, caso o problema seja realmente da outra equipe, ou será encaminhada para Análise novamente ou
Execução caso o problema seja realmente do software
aplicativo.
Na coluna Execução ficam todas as tarefas que estão sendo trabalhadas naquele momento, sejam elas de desenvolvimento ou manutenção.
Após a tarefa ter sido executada, será encaminhada para a coluna Teste, onde um outro desenvolvedor fará os testes necessários. Neste ponto, o campo Como demonstrar do cartão pode servir de partida para os testes [4]. Se a tarefa passar pelos testes, irá para coluna Finalizada, encerrando-se o fluxo. Caso contrário ela volta para a coluna Execução para as correções necessárias e passar novamente pelos testes. Se em qualquer uma das etapas surgir algo que impeça o andamento da tarefa, ela será encaminhada para a coluna
Bloqueada. O desenvolvedor informa ao ScrumMaster que
existe um impedimento e ele fica responsável por removê-lo. Cada etapa do processo possui um limite de tarefas. Como este artigo trata de uma proposta e a empresa em estudo nunca utilizou nenhuma técnica parecida no desenvolvimento, estes limites não puderam ser baseados em informações históricas. Estes valores foram baseados no número de desenvolvedores da equipe, já apresentados no item IV.
Para o número máximo de tarefas da coluna Execução, utiliza-se a expressão 2n-1 (n – número de desenvolvedores) proposta por Kniberg e Skarin [4], considerando no caso 10 desenvolvedores. Isso significa que nove desenvolvedores podem trabalhar em duas tarefas simultâneas e o décimo estará com apenas uma. Caso precise trabalhar numa segunda tarefa, terá que esperar o término de alguma ou ajudar algum desenvolvedor a terminar uma de suas tarefas. O propósito dessa estratégia é aumentar a colaboração entre os desenvolvedores.
Ilustra-se na Figura 5 um exemplo de preenchimento do quadro Kanban e na Figura 6 o preenchimento de um cartão de manutenção e outro de desenvolvimento.
C. As regras
Como visto no Item II, o Scrum prescreve cinco regras. Estas
regras serão mantidas para a empresa em estudo, porém com algumas adaptações. A principal mudança será a substituição das Sprints pelo fluxo do trabalho do Kanban. Num time onde o trabalho se divide em desenvolvimento e manutenção, o time não está cem porcento comprometido com o desenvolvimento, que é um requisito do Scrum na Sprint. Portanto, a utilização de Sprints torna-se inviável num cenário como este [4].
Figura 3 - Cartões de manutenção (esquerda) e desenvolvimento (direita)
Figura 6 - Cartões ampliados (superior de manutenção e inferior de desenvolvimento) Figura 5 - Exemplo de um quadro Kanban (os cartões mais escuros são de manutenção e os mais claros de desenvolvimento)
Para conciliar desenvolvimento e manutenção num mesmo time é necessário um controle maior, fazendo com que as tarefas tenham que ser priorizadas constantemente evitando-se que o desenvolvimento ou a manutenção sejam deixados de lado. Desta forma, tomando-se como base as experiências de Kniberg e Skarin [4] e Kinoshita [2], realiza-se semanalmente a Sprint Planning Meeting. Com relação ao dia ideal para realização desta reunião, Kinoshita [2] sugere que seja uma quarta ou quinta-feira pois, iniciando as atividades numa segunda-feira poderia provocar horas extras desnecessárias no fim de semana para finalizar algumas tarefas pendentes. No mesmo dia logo após a Sprint Planning Meeting é feita a Sprint Retrospective Meeting. Neste caso, como a equipe toda é pequena, não há necessidade de se fazer uma retrospectiva para cada time. Reúnem-se os times, os ScrumMasters e os Product Owners. A presença dos Product Owners é opcional [7].
Todos se reúnem numa sala fora do ambiente de trabalho, para que se evite interrupções durante a reunião [3] e debatem sobre duas perguntas: “O que funcionou bem no processo desde a última retrospectiva?” e “O que deveria ser melhorado?” [7]. O supervisor anota as opiniões de todos e no fim da reunião a equipe prioriza as mudanças para a próxima semana, isso faz com que o processo esteja sempre em melhoria contínua.
Nos casos de desenvolvimento, após as Sprint Planning Meetings o Product Owner avalia se as funcionalidades implementadas até aquele momento são suficientes para compor um produto utilizável. Caso já se tenha, é agendada a Sprint Review Meeting onde o time, o ScrumMaster, o Product Owner e as áreas da empresa interessadas avaliam o produto desenvolvido até ali.
Durante a reunião, o time apresenta as funcionalidades implementadas desde a última Sprint Review Meeting e anotam as observações e comentários feitos. Estas anotações serão utilizadas na próxima Sprint Planning Meeting, onde o Product Owner decidirá quais delas irão para o Product Backlog.
Durante a semana, no início de cada manhã, o time e o ScrumMaster se reúnem para realizar a Daily Scrum Meeting. Nesta reunião os times atualizam o quadro Kanban e respondem a três perguntas feitas pelo ScrumMaster: “o que foi feito desde a última reunião?”; “existe algum impedimento?”; e “o que será feito até a próxima reunião?” [7]. O objetivo é encontrar o mais rápido possível os bloqueios do projeto, tudo aquilo que impeça o avanço do desenvolvimento.
O supervisor fará uma reunião individual com cada time. Espera-se com isso maior aproveitamento da reunião já que todos estarão focados em um único projeto.
V. CONCLUSÃO
Devido as dificuldades da implantação de processos tradicionais, modelos e ferramentas de processo vêm ganhando cada vez mais espaço dentro das organizações. Em
ambientes onde exitem poucos recursos e exigem respostas rápidas para as mudanças, estes modelos e ferramentas podem-se tornar elementos chaves para o sucesso da organização.
Este artigo apresentou uma proposta de processo baseado no modelo de processo Scrum e da ferramenta de processo Kanban onde a principal característica é a melhoria contínua e a resposta rápida às mudanças. Devido as peculiaridades da empresa estudada, foram feitas algumas mudanças nos modelos originais propostos pelo Scrum e Kanban, objetivando assim melhor adaptação à empresa estudada. Espera-se que esta proposta seja utilizada em organizações onde o cenário seja parecido com o da empresa estudada. E que os resultados obtidos por meio de estudo de caso sejam relatados em trabalhos futuros.
REFERÊNCIAS
[1] K. Hiranabe, (2010, Jun) Kanban Applied to Software Development: from Agile to Lean [Online]. Disponível: http://www.infoq.com/articles/hiranabe-lean-agile-kanban.
[2] F. Kinoshita, “Practices of an Agile Team”, IEEE Computer Society, Toronto, pp. 373-377, Aug. 2008. [3] H. Kniberg, (2010, Jan) Scrum and XP from the Trenches:
How we do Scrum [Online]. Disponível: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches.
[4] H. Kniberg, M. Skarin, (2010, Feb) Scrum and Kanban: making the most of both [Online]. Disponível:
http://www.infoq.com/minibooks/kanban-scrum-minibook.
[5] R. Pressman, Engenharia de Software. (6. ed.) São Paulo: McGraw-Hill, 2006.
[6] L. Rising, N. Janoff, “The Scrum Software Development Process for Small Teams”, IEEE Software, New York, pp. 26-32, July 2000.
[7] K. Schwaber, Agile Project Management with Scrum. Redmond: Microsoft Press, 2004.
[8] K. Schwaber, (2010, Jun) SCRUM Development Process
[Online]. Disponível:
https://wiki.state.ma.us/confluence/download/attachments /16842777/Scrum+Development+Process.pdf.
