FACULDADE 7 DE SETEMBRO FA7 CURSO DE ESPECIALIZAÇÃO EM DESENVOLVIMENTO ÁGIL DE SOFTWARE TÁSSSIO GUERREIRO ANTUNES VIRGÍNIO

Transcrição

1 FACULDADE 7 DE SETEMBRO FA7 CURSO DE ESPECIALIZAÇÃO EM DESENVOLVIMENTO ÁGIL DE SOFTWARE TÁSSSIO GUERREIRO ANTUNES VIRGÍNIO FIRST STEP IN AGILE: UMA FERRAMENTA DE GESTÃO ÁGIL PARA EQUIPES INICIANTES FORTALEZA 2013

2 TÁSSSIO GUERREIRO ANTUNES VIRGÍNIO FIRST STEP IN AGILE: UMA FERRAMENTA DE GESTÃO ÁGIL PARA EQUIPES INICIANTES Monografia apresentada à Faculdade 7 de Setembro como requisito parcial para obtenção do título de especialista em Desenvolvimento Ágil de Software. FACULDADE 7 DE SETEMBRO FA7 CURSO DE ESPECIALIZAÇÃO EM DESENVOLVIMENTO ÁGIL DE SOFTWARE Orientador: Prof. Joaquim Pedro C. Oliveira, Ms FORTALEZA 2013

3

4 Agradecimentos Agradeço a Deus por ter me dado a oportunidade de aprender e crescer nessa existência, por me guiar, colocando pedras e flores no meu caminho, para que possa aprender e ser feliz. Agradeço aos meus pais por terem me criado e me ensinado da melhor forma que existe. Pelo exemplo de pessoas que são e que um dia sonho em ser, obrigado por tudo. Aos meus familiares por acreditarem no meu sucesso, mesmo distantes, sei que sempre torceram por mim. A Renata Felix por ter estado sempre ao meu lado me apoiando, ajudando e incentivando. Sem a qual esse curso não seria possível. Por quem vou ser eternamente grato por ter me acompanhado nessa etapa da minha vida. Aos professores do curso, que me repassaram os seus conhecimentos de forma exemplar, os quais tenho certeza que irei usar na minha vida profissional. Ao meu orientador por ter tido a paciência e tempo disponível para me guiar nas linhas desse trabalho. E agradeço aos meus colegas de curso entre os quais tenho um agradecimento especial a Avelar Leão, Juliana Magalhães e Luana Pires. Que estavam tão empolgados quanto eu no desenvolvimento do curso, e que me deram força para que pudesse terminar o mesmo.

5 Eu vejo o futuro repetir o passado, eu vejo um museu de grandes novidades, o tempo não para. Cazuza

6 Resumo Atualmente as metodologias ágeis estão sendo cada vez mais adotadas, nos mais variados tipos de projetos e empresas. Existem várias metodologias de desenvolvimento, cada uma com escopo específico, dentre as quais se destacam: Iconix, SCRUM, XP, FDD, DSDM, ASD e Crystal. Com o aparecimento das metodologias surgiram ferramentas com o foco em ajudar a informatizar determinados processos, mesmo as metodologias ágeis sendo de certa forma fáceis de aprender e utilizar, sem necessidade de um sistema de computador, existem várias opções de ferramentas para esse fim. Na maior parte dos casos elas são complexas e tem o pré-requisito dos usuários já terem familiaridade com a metodologia. Faremos a análise de algumas dessas ferramentas, e apresentaremos uma nova proposta de ferramenta mais simples, com processos enxutos, poucas configurações e opções, baseada em alguns conceitos do Scrum, XP e Kanban, podendo ser utilizada para gerenciar projetos de forma completa, mas onde o foco são equipes iniciantes, sem experiência e que querem aprender uma metodologia ágil. O diferencial da ferramenta é um guia que vai explicar passo a passo as etapas do processo, onde os integrantes da equipe poderão aprender alguns conceitos básicos e praticá-los de forma real em seus projetos. Palavras-chaves: Aplicativo, Aprendizado, Ágil, Scrum, XP.

7 Abstract Currently agile methodologies are increasingly being adopted, in various types of projects and companies. There are several development methodologies, each with specific scope, among the which stand out : Iconix, SCRUM, XP, FDD, DSDM, ASD and Crystal. With the emergence of methodologies suggest tools with a focus on helping to computerize certain processes, even agile methodologies being somewhat easy to learn and use, without the need of a computer system, there are several choices of tools for this purpose. In most cases, they are complex and have the prerequisite of the users having already familiar with the methodology. Do the analysis some of these tools, and present a new proposal for simpler tool, with lean processes, few configurations and options based on some concepts of Scrum, XP and Kanban, so that can be used to manage projects form complete, but where the focus is on beginner teams with no experience is who want to learn an agile methodology. The differential of the tool is a guide that will explain step by step process steps, where team members can learn some basics and practice them a real way in their projects. Key-words: Application, Learning, Agile, Scrum, XP.

8 Lista de ilustrações Figura 1 O ciclo do Scrum Figura 2 Protótipo Tela de Login Figura 3 Protótipo Tela Principal Figura 4 Protótipo Tela de Projetos Figura 5 Protótipo Tela de Backlog Figura 6 Protótipo Tela de Atividades Figura 7 Protótipo Tela de Sprints Figura 8 Protótipo Tela de Backlog Sprints Figura 9 Protótipo da Tela do Kanban Figura 10 Validação com o usuário Figura 11 Validação com o usuário Figura 12 Diagrama de Classe das Entidades Figura 13 Camadas da aplicação Figura 14 Tela de Login Figura 15 TimeBox Figura 16 Tutorial Figura 17 Janela de Gerenciamento dos Projetos Figura 18 Janela do Backlog Figura 19 Janela das Atividades Figura 20 Janela de Cadastro dos Sprints Figura 21 Janela do Sprint Backlog Figura 22 Janela do Kanban Figura 23 Tela de Login Figura 24 Janela de Gerenciamento dos Projetos Figura 25 Janela do Backlog Figura 26 Janela das Atividades Figura 27 Janela de Cadastro dos Sprints Figura 28 Janela do Sprint Backlog Figura 29 Janela do Kanban

9 Lista de tabelas Tabela 1 Análise das Funcionalidades

10 Sumário 1 Introdução Motivação Objetivos Objetivo Geral Objetivos Específicos Estrutura do Trabalho Visão Geral dos Métodos Ágeis Metodologias Ágeis Scrum Programação Extrema (Extreme Programming XP) Lean Desenvolvimento Lean de Software Kanban Análise das Ferramentas de Gestão Ágil Ferramentas XPlanner Firescrum Icescrum Agilefant Comparativo A Aplicação First Step In Agile Técnicas e Ferramentas Utilizadas Histórias Protótipos de baixa fidelidade Validação com Usuário Práticas Ágeis Selecionadas para o Sistema Quadro kanban Histórias de Usuário (User Story) Atividades Sprint Time-Box Demonstração On-line no Heroku O Desenvolvimento da Aplicação First Step In Agile Visão Geral

11 5.2 Desenvolvimento da Aplicação Java Wicket Hibernate Spring Arquitetura da Aplicação Diagrama de Classe Camadas da Aplicação Principais Funcionalidades Tela de Login Time-Box View Tutorial Janela Projetos Janela Backlog Janela das Atividades Janela dos Sprints Janela Sprint Backlog Janela do Kanban Ciclo de Um Projeto (Descrição do Fluxo) Referências APÊNDICE A Telas do Sistema APÊNDICE B Conteúdo dos Tutoriais B.1 Projeto B.2 Backlog B.3 Atividades B.4 Sprints B.5 Backlog Sprints B.6 Quadro kanban

12 11 1 Introdução No contexto atual as metodologias ágeis tem se mostrado eficazes para o gerenciamento de vários tipos de projetos, dando bons resultados (BASTOS, 2013) (VISIONONE, 2013), e com isso aumentando sua confiabilidade. Por terem o objetivo de minimizar os riscos dos projetos, propondo o foco no desenvolvimento em períodos curtos de tempo, mantendo processos leves com poucas etapas, com a produção de artefatos somente necessários entre outras ideias (GOMES, 2013). Existem várias opções de metodologias ágeis, tais como ICONIX (ICONIX, 2014), SCRUM (SABBAGH, 2013), XP (BECK, 2005), FDD (FDD, 2013), DSDM (DSDM, 2013), ASD (ASD, 2013) e família de metodologias Crystal (COCKBURN, 2004), cada uma com escopo e foco diferente, umas mais conhecidas que outras, com níveis diferentes de aprendizado. Com isso equipes iniciantes tem dificuldades na escolha da metodologia, quais práticas da metodologia começar a utilizar. Além disto, um outro fator de dificuldade para equipes iniciantes é na escolha de qual ferramenta utilizar, existindo várias opções, elas são geralmente muito complexas, fornecendo muitas funcionalidades, focadas para equipes já treinadas na metodologia abordada, ou com uma pessoa para guia-las (GOMES, 2013). Como proposta, foi elaborada uma nova ferramenta de gerenciamento, cujo papel principal é ensinar as etapas da metodologia Scrum, instrumento de grande utilidade para equipes iniciantes. A ideia precursora deste estudo foi o desenvolvimento de uma ferramenta que viabilizasse fazer o mínimo possível para se ter um gerenciamento completo, tirando opções avançadas, fluxos detalhados, propriedades demasiadas. Dessa forma, estaria comprovado que com poucos passos é possível controlar e ter toda a perspectiva do fluxo da metodologia, mesmo com poucos recursos de uma aplicação. Serão abordadas todas as etapas principais da metodologia, seu funcionamento, aplicabilidade, princípios, vantagens e como deve ser trabalhada pela equipe. Com uma proposta de ser direcionada para equipes que não tem conhecimento das metodologias ágeis, a aplicação desenvolvida terá um tutorial, que guiará a equipe nas etapas da metodologia escolhida. Sendo uma proposta dessa forma de um ponto de partida para introdução das práticas ágeis, podendo a equipe introduzir outras práticas, na medida em que for evoluindo. 1.1 Motivação As dificuldades enfrentadas por equipes iniciantes, especificamente quanto ao controle das atividades, levantamento de requisitos, falta de comunicação entre os membros da equipe e destes com o cliente, foram alguns dos fatores preponderantes na escolha do

13 Capítulo 1. Introdução 12 tema do presente estudo. Também foi considerada a praticidade da metodologia Scrum (SABBAGH, 2013) na solução eficaz, uma vez que se caracteriza por etapas simples e de fácil aprendizado, a utilização de alguns conceitos da Programação Extrema (KNIBERG, 2007) e da ferramenta Kanban (KNIBERG, 2013). A partir desses critérios e considerando as demais vantagens das metodologias ágeis, foi possível elaborar um fluxo de atividades que poderia, facilmente, ser seguido por uma equipe, de forma que agilizasse o aprendizado dos princípios relacionados às citadas metodologias e ferramentas. 1.2 Objetivos Antes de iniciar o desenvolvimento da aplicação, foi de suma importância definir os objetivos desejados ao término do mesmo. São eles: Objetivo Geral Desenvolver uma ferramenta de aprendizado e gerenciamento de equipes, no intuito de atender às equipes que desejam utilizar as metodologias ágeis. O desenvolvimento da ferramenta valeu-se dos conceitos do Scrum (SABBAGH, 2013), XP (KNIBERG, 2007) e do Kanban (KNIBERG, 2013), com base em análise de ferramentas já existentes no mercado Objetivos Específicos a) Estudar os frameworks ágeis selecionados; b) Elaborar um comparativo das ferramentas existentes com a ferramenta proposta; c) Apresentar as práticas selecionadas; d) Desenvolver o projeto da aplicação; e) Entregar a aplicação. 1.3 Estrutura do Trabalho Para alcançar os objetivos definidos e para um melhor fluxo das ideias aqui defendidas, a presente monografia foi dividida em cinco capítulos. Inicialmente são abordados os fundamentos teóricos dos métodos ágeis. O capítulo seguinte é feita uma análise de 4 ferramentas atuais para o gerenciamento ágil, fazendo um comparativo entre elas e a solução proposta. O capítulo quatro trata sobre o desenvolvimento da aplicação, quais as práticas ágeis selecionadas para o sistema, explicitando o porquê da sua escolha e como serão usadas. O quinto capítulo apresenta a aplicação First Step in Agile, apresentando

14 Capítulo 1. Introdução 13 o aplicativo em linhas gerais, como se deu processo de desenvolvimento do mesmo, suas telas, as tecnologias utilizadas, principais funcionalidades e como ele pode ajudar novas equipes a entrar no mundo do desenvolvimento ágil de software. Ao final, são feitas algumas considerações sobre o tema escolhido e sobre os trabalhos futuros.

15 14 2 Visão Geral dos Métodos Ágeis Para uma melhor compreensão sobre as metodologias ágeis, torna-se indispensável recordar seus fundamentos teóricos. Dessa forma, neste capítulo serão apresentadas, em linhas gerais, algumas dessas metodologias, suas características, conceitos e etapas. 2.1 Metodologias Ágeis A engenharia de software sempre procurou maneiras melhores para desenvolver os requisitos dos clientes, prova disso é a existência de vários modelos e processos de desenvolvimento de software, por exemplo o Cascata, Espiral e RUP (PRESSMAN, 2010). Em Fevereiro de 2001, em uma estação de esqui em Utah, EUA, 17 profissionais que já vinham praticando, publicando e divulgando metodologias rotuladas como "leves", se reuniram para declarar os pontos em comum. Nesse momento surgiu o Manifesto Ágil que declarou uma nova forma de entender projetos que lidam diariamente com imprecisão e imprevisibilidade, características inerentes ao processo de desenvolvimento de software e tecnologia (AGILE, 2013). Dentro desse processo de melhoria surgiram os métodos ágeis como resposta aos métodos já existentes, que eram caracterizados por uma pesada regulamentação nos seus processos (GOMES, 2013). Existem inúmeros frameworks de processos para desenvolvimento de software, os quais podem ser classificados como adaptativos ou preditivos. As metodologias ágeis são adaptativas, ou seja, buscam a adaptação rápida a mudanças da realidade. Quando os requisitos mudam, por exemplo, a equipe se adapta rapidamente a essa mudança. Por outro lado, esses métodos tem dificuldade de predizer o que farão a longo prazo. Como exemplos de metodologias ágeis, podemos destacar o Scrum (SABBAGH, 2013), o Crystal Clear (COCKBURN, 2004), e a Programação Extrema (BECK, 2005). Os métodos preditivos tem como base descrever todos os passos do início ao fim do projeto. Para uma equipe preditiva é fácil dizer o que farão em todas as etapas do processo, porém tem dificuldades em lidar com mudanças, pois qualquer mudança nos requisitos desencadeará mudanças em todo o planejamento feito para o projeto (PHAM, 2011) (SBROCCO, 2012). A maioria dos métodos ágeis tenta minimizar o risco através do desenvolvimento do software em curtos períodos de tempo, chamados de iteração, que duram tipicamente entre uma e quatro semanas. Cada iteração é como um projeto de software completo em miniatura, o que inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação.

16 Capítulo 2. Visão Geral dos Métodos Ágeis 15 Em um processo convencional cada etapa não está focada em adicionar um novo conjunto significativo de funcionalidades. Por exemplo, no Modelo Cascata (PRESSMAN, 2010), para se ter inicio ao desenvolvimento da aplicação teria que passar pelas fases de Comunicação, Planejamento, Modelagem e só depois a fase de Construção, ou seja, não se tem ao final de cada fase nada que o cliente já possa usar. Em um projeto de software ágil o que se deseja é a capacidade de entregar uma nova versão do software ao fim de cada iteração. Métodos ágeis enfatizam comunicações em tempo real, preferencialmente face a face, em detrimento aos documentos escritos. A maioria dos componentes de uma equipe ágil, de preferência, devem estar agrupados em uma mesma sala. Isso inclui todas as pessoas necessárias para desenvolver o software. Ou seja, os programadores e seus clientes (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou realmente os clientes). Também podem se encontrar nessa sala os testadores, designers, gerentes, entre outros. É de conhecimento geral que os métodos ágeis também enfatizam entrega de software como uma medida primária de progresso. Combinado com a comunicação face a face, métodos ágeis produzem pouca documentação em relação a outros métodos. É recomendada a produção de documentação que realmente será útil (PHAM, 2011). 2.2 Scrum O Scrum é um framework iterativo e incremental para gerenciamento de projetos. Scrum não descreve o que fazer em cada situação. Ele é usado para trabalhos complexos nos quais é impossível predizer tudo o que ocorrerá (SABBAGH, 2013). Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo por Takeuchi e Nonaka no artigo "The New Product Development Game" (TAKEUCHI; NONAKA, 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby. Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo (SABBAGH, 2013). A seguir, apresentamos, de forma resumida, as principais características, papéis, artefatos e cerimônias da metodologia. a) Características; Equipes auto-organizadas e multidisciplinares;

17 Capítulo 2. Visão Geral dos Métodos Ágeis 16 O produto evolui em uma série de iterações de 2 a 4 semanas, denominadas Sprints; Os requisitos são listados em uma Lista de Funcionalidades do Produto (Product Backlog); Os Sprints representam um Time-Box, é um período de tempo bem definido e imutável, que faz parte do compromisso da equipe com suas metas, faz com que as iterações ocorram, a equipe fique centrada no objetivo da iteração e, com isso, diminua a dispersão. b) Papéis; Dono do Produto (Product Owner): Dono ou Responsável pelo produto, responsável em priorizar e levantar as atividades que compõem o Product Backlog. Equipe de Desenvolvimento (Team): Equipe de desenvolvimento, sem divisões de papéis internamente, todos trabalham em conjunto para entregar as funcionalidades. Scrum Master: Responsável pela fluidez das etapas do Scrum, tirando os impedimentos que aparecem. c) Artefatos; Lista de Funcionalidades do Produto (Product Backlog): Conjunto de funcionalidades desejadas para o produto, que sempre deve se manter priorizada mediante as estratégias de negócio do Product Owner. Lista de Funcionalidades do Sprint (Sprint Backlog): Lista de atividades selecionadas a serem desenvolvidas em um Sprint. Lista de Funcionalidades da Versão (Release Backlog): Lista de atividades selecionadas a serem entregues em um release. Gráfico de Acompanhamento (Burndown chart): Gráfico utilizado durante um Sprint para exibir a velocidade da equipe. d) Cerimônias: As cerimônias Scrum são eventos que acontecem dentro de um Sprint. Cada cerimônia prepara a equipe para a próxima etapa dentro do Sprint. As cerimônias que fazem parte do fluxo do Scrum são as seguintes: Reunião de Planejamento da Sprint (Sprint Planning Meeting): Reunião de planejamento onde o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que será capaz de fazer durante o Sprint.

18 Capítulo 2. Visão Geral dos Métodos Ágeis 17 Reunião Diária (Daily Scrum): Reunião diária para atualização da equipe nas atividades que estão sendo elaboradas pelos membros. Identificando as atividades que foram feitas no dia anterior, identificando impedimentos e levantando próximas atividades. Reunião de Revisão da Sprint (Sprint Review Meeting): Reunião para apresentação das funcionalidades entregues no Sprint para o Product Owner. Reunião de Retrospectiva da Sprint (Sprint Retrospective): A equipe levanta pontos positivos, melhorias e ações que devem ser tomadas nos próximos Sprints, visando a melhoria constante da equipe. Essas etapas podem ser identificadas na figura 1. Figura 1 O ciclo do Scrum Fonte: (SABBAGH, 2013) 2.3 Programação Extrema (Extreme Programming XP) O processo ágil extreme Programming (BECK, 2005) resultou da experiência no projeto C3 Payroll na empresa Chrysler. Este projeto consistia da implementação de um sistema de folha de pagamento. Após o sucesso nesse projeto, XP começou a despontar no meio acadêmico e empresarial e se tornou alvo de inúmeras pesquisas e discussões, além de ser adotado em diversas empresas de software e apoiado por grandes nomes da área como Kent Beck, Ron Jeffries, Martin Fowler e Grady Booch (KNIBERG, 2007). O XP tem práticas já comprovadas de desenvolvimento de software, e por esse motivo é bem aceito e utilizado em todo mundo. Ele é baseado em valores e princípios

19 Capítulo 2. Visão Geral dos Métodos Ágeis 18 básicos. Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas. O XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo (KNIBERG, 2007) (IMPROVEIT, 2013). a) Valores e princípios: Valores são critérios gerais e abstratos usados para justificar o que se vê, pensa ou faz. Princípios servem de ponte entre os Valores e as Práticas. Valores representam a essência daquilo que gostamos ou não a respeito de alguma coisa. Ter os valores explícitos é importante porque sem valores, as práticas rapidamente perdem o sentido e tornam-se atividades feitas por fazer, sem qualquer propósito ou direção. Valores trazem propósito às práticas. Comunicação: O XP é orientado a comunicação face a face entre as pessoas, com o mínimo de documentação. Simplicidade: Priorizando a solução mais fácil que posso ser desenvolvida, com isso o custo de mudanças é mais baixo no futuro. O objetivo é não antecipar o desenvolver de funcionalidades que podem não ser usadas. Feedback: O retorno rápido de informações tanto para o próprio desenvolvedor com os testes, quanto para o cliente, com isso podemos visualizar mudanças antecipadamente. Coragem: Possivelmente o principal valor do XP, pois é necessário durante todo o uso da metodologia. Um exemplo é na mudança de código existente funcionando, mudança de arquitetura, mudança de framework entre outros. Respeito: É um valor que dá sustentação aos demais. Membros de uma equipe só irão se preocupar em comunicar-se melhor, por exemplo, se importarem uns com os outros. Respeito é o mais básico de todos os valores. Se ele não existir em um projeto, não há nada que possa salvá-lo. Saber ouvir, saber compreender e respeitar o ponto de vista do outro é essencial para que um projeto de software seja bem-sucedido. Além dos valores o XP define um conjuntos de princípios que servirão para tomadas de decisões durante um projeto (IMPROVEIT, 2013). Humanidade: Balancear as necessidades pessoais com as necessidades da equipe.

20 Capítulo 2. Visão Geral dos Métodos Ágeis 19 Economia: Evite o risco do Sucesso Técnico. Tenha certeza que o sistema cria valor para o negócio. Beneficio Mútuo: Todas as atividades devem trazer benefício a todos os envolvidos. Auto-Semelhança: Tente aplicar a estrutura de uma solução em outros contextos, até em diferentes escalas. Melhoria: Valorize atividades que começam agora e se refinam ao longo do tempo. Diversidade: Equipes devem ser formados por uma variedade de habilidades, atitudes e perspectivas. Reflexão: Reflexão vem após a ação. O aprendizado é o resultado da reflexão sobre a ação. Fluxo: Entregue um fluxo contínuo de software que agregue valor. Oportunidade: Enxergue os problemas como uma oportunidade para mudança. Redundância: Resolva os problemas difíceis de várias formas diferentes. Falha: Se estiver com problemas em obter sucesso, falhe. Qualidade: Sacrificar a qualidade nunca é um meio efetivo de controle. Passos Pequenos: A execução em passos pequenos diminui o risco de uma grande mudança. Aceitação da Responsabilidade: Responsabilidade não pode ser imposta, deve ser aceita. b) Práticas do XP Práticas são úteis porque são objetivas e indicam ações concretas. Práticas são claras e concretas; ou se escreve um teste antes de mudar o código ou não. Também indicam ações que normalmente são específicas para certos contextos; refatoração é aplicada somente a trechos de código que estão funcionalmente corretos. Além disso, são úteis porque dão um lugar para começar; pode-se começar escrevendo os testes e ganhar os benefícios de se fazer assim, muito antes de entender o desenvolvimento de software de um modo mais profundo. Da mesma maneira que valores trazem propósito às práticas, práticas trazem responsabilidades aos valores. As práticas do XP são divididas em primárias e corolárias, as práticas primárias podem ser adotadas imediatamente, sendo a ordem de adoção definida através da necessidade. As práticas corolárias devem ser adotadas após adotar as primárias, pois tem maior dificuldade a

21 Capítulo 2. Visão Geral dos Métodos Ágeis 20 sua implantação e dependem que determinadas práticas primárias estejam bem estabelecidas (BECK, 2005) (IMPROVEIT, 2013). Práticas Primárias: São práticas que você pode começar a adotar imediatamente de forma segura para melhorar seu esforço de desenvolvimento de software. Qual você deve adotar primeiro depende inteiramente de seu ambiente e o que você entende como sendo sua maior oportunidade de melhoria. Ambiente Informativo: O ambiente de trabalho de uma equipe XP deve ser um reflexo do projeto. Alguém que entre na sala da equipe deve conseguir obter, em poucos segundos, uma noção clara de como está o andamento do projeto. Build de Dez Minutos: Assegure que seja possível executar o build e todos os testes automatizados do projeto em até dez minutos. Ciclo Semanal: O software é desenvolvimento de modo iterativo e incremental em projetos XP. Ou seja, uma vez por semana os desenvolvedores se reúnem com o cliente para priorizar um pequeno conjunto de funcionalidades que possam ser implementadas e testadas completamente naquela semana. Ciclo Trimestral: O planejamento geral de um projeto XP é dividido em trimestres. No início de cada trimestre a equipe se reúne com o cliente e demais interessados no projeto para estabelecer o tema ou os temas que serão implementados ao longo dos próximos três meses. Temas são conjuntos de funcionalidades que solucionam as necessidades de um ou mais processos de negócios da organização. Desenvolvimento Orientado a Testes: Técnica que se baseia em um ciclo curto de repetições, primeiro é escrito o caso de teste, depois é produzido o código que faça o teste passar, ao final é feita a refatoração do código. Tem como um de seus objetivos antecipar a identificação e correção de falhas durante o desenvolvimento. Design Incremental: O design de uma aplicação surge de forma iterativa e incremental em projetos. O objetivo é criar a solução mais simples possível que seja suficiente para implementar as funcionalidades de cada iteração. Equipe Integral: Equipes XP devem ser formadas não apenas por desenvolvedores, mas também por clientes e quaisquer outras pessoas que devam ser ouvidas ao longo do desenvolvimento. Folga: Equipes XP devem estabelecer um nível de folga em seus planejamentos. Isso pode ser feito, por exemplo, incluindo-se atividades em um

22 Capítulo 2. Visão Geral dos Métodos Ágeis 21 ciclo semanal que não são tão importantes e, portanto, podem ser deixadas de lado caso a equipe esteja em risco de não conseguir implementar as funcionalidades mais importantes da iteração. Histórias: Equipes XP planejam utilizando histórias escritas em pequenos cartões. As histórias normalmente são escritas pelo próprio cliente. Os cartões não têm a pretensão de armazenar todas as informações sobre uma história. Desenvolvedores em uma equipe XP utilizam o diálogo presencial com o cliente para aprender o máximo possível sobre os detalhes de cada história. Dessa forma, o registro da história feito no cartão acaba servindo basicamente como um lembrete do diálogo. Integração Contínua: Integração contínua consiste em integrar o trabalho diversas vezes ao dia, assegurando que a base de código permaneça consistente ao final de cada integração. Programação em Par: Programação em par é uma das práticas mais conhecidas e mais polêmicas utilizadas pelos que adotam o Extreme Programming. Ela sugere que todo e qualquer código produzido no projeto seja sempre implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado. Sentar-se Junto: Membros de uma equipe XP procuram se sentar juntos em uma sala aberta, na qual todos possam trabalhar em conjunto e se comunicar da forma mais rápida e eficaz possível. Evite cubículos e trabalhe com áreas de uso comum em quem os desenvolvedores possam se agrupar para trabalhar em par e discutir os mais diversos assuntos de forma eficiente. Trabalho Energizado: Projetos XP seguem a filosofia de que o mais importante não é trabalhar mais e sim trabalhar de forma mais inteligente, em um período de tempo semanal que as pessoas sejam capazes de sustentar sem ficarem esgotadas e sem prejudicarem o trabalho com o déficit de atenção decorrente da fadiga. Práticas Corolárias: As práticas corolárias são difíceis ou perigosas de serem implementadas antes de se adotar as práticas primárias. Se você começar a implantar o software diariamente, por exemplo, sem baixar a taxa de defeitos para algo muito próximo de zero (com programação em par, integração contínua e desenvolvimento orientado a testes), você terá um desastre nas mãos (BECK, 2005) (IMPROVEIT, 2013). Análise da Raiz do Problema: Diante de um problema, perguntamos por que ele ocorreu cinco vezes, dessa forma, conseguimos passar do sintoma à

23 Capítulo 2. Visão Geral dos Métodos Ágeis 22 raiz do problema. Base de Código Unificada: Deve haver apenas uma base de código. Você pode desenvolver em um ramo temporário, mas nunca o deixe sobreviver mais que apenas algumas horas. Código Coletivo: Em um projeto XP, os pares se revezam, as pessoas se revezam na formação dos pares e todos têm acesso e autorização para editar qualquer parte do código da aplicação, a qualquer momento. Ou seja, a propriedade do código é coletiva e todos são igualmente responsáveis por todas as partes. Com isso, os desenvolvedores ganham tempo, pois não precisam esperar a autorização de um colega para editar uma área do código e há maior disseminação de conhecimento. Código e Testes: Mantenha apenas código e testes como artefatos permanentes. Gere outros documentos que se façam necessários a partir do código e dos testes. Continuidade da Equipe: Preserve equipes eficazes. Há uma tendência em grandes organizações de abstrair as pessoas em lugar de coisas, unidades de programação compatíveis no estilo plug-and-play. Valor em software é criado não apenas pelo que as pessoas sabem e fazem, mas também por seus relacionamentos e pelo que as pessoas são capazes de alcançar juntas. Ignorar o valor dos relacionamentos e da confiança para simplificar o problema de agendamento é uma economia falsa. Contrato de Escopo Negociável: Projetos XP, como quaisquer outros na área de software, possuem um escopo que define o que deve ser feito. Tal escopo existe antes de o projeto ser iniciado e continua a existir ao longo do projeto até que ele seja encerrado. Entretanto, ao contrário do que é usual, este escopo não é fixado em contrato. Ou seja, caso o cliente perceba a necessidade de fazer ajustes no escopo para que o software leve em conta seu aprendizado ao longo do projeto, ou mudanças nas circunstâncias, ele pode. Em projetos XP, o escopo é revisado frequentemente para garantir que equipe dedique seus esforços ao que é mais prioritário em cada etapa do projeto. Envolvimento do Cliente Real: A prática equipe integral sugere que haja requerentes participativos na equipe, representando os mais diversos pontos de vistas dos usuários. Mas, isso não é suficiente. A prática de envolvimento do cliente real vai além. Ela sugere que os usuários finais sejam envolvidos diretamente no processo de desenvolvimento. Equipes que Encolhem: À medida que uma equipe aumenta a sua capacidade de produção, mantenha a carga de trabalho constante, mas

24 Capítulo 2. Visão Geral dos Métodos Ágeis 23 gradualmente reduza o tamanho da equipe. Isso libera as pessoas para formarem outras equipes. Implantação Diária: Coloque novas funcionalidades em produção toda noite. Qualquer diferença entre o que está no computador do programador e o que está em produção é arriscado. Um programador fora de sincronia com o software em produção se arrisca a tomar decisões sem receber feedback preciso sobre suas decisões. Implantação Incremental: Quando estiver substituindo um sistema legado, gradualmente e desde o início do projeto, implante as partes do novo sistema que forem ficando prontas, para serem usadas paralelamente com o sistema atual ou substituindo a parte equivalente. Com essa proteção se tem uma segurança na substituição do sistema. Pagar Por Uso: Em sistemas pay-per-use, você cobra por cada vez que o sistema é utilizado. Dinheiro é o feedback máximo. Não apenas é concreto, como você também pode gastá-lo. Conectar o fluxo de dinheiro ao desenvolvimento de software provê informação precisa e em tempo que pode ajudar a direcionar o desenvolvimento. c) Papéis Os papéis em XP não são rígidos nem fixos. O objetivo é fazer com que todos possam contribuir com o máximo que tiverem para oferecer para o sucesso da equipe. No início, papéis fixos podem ajudar no aprendizado de novos hábitos, com os papéis técnicos tomando as decisões técnicas e os papéis de negócio tomando as decisões de negócio. Uma vez que os relacionamentos entre os integrantes da equipe estiverem sedimentados, e que haja respeito entre eles, os papéis fixos começam a interferir no objetivo de que cada um faça o melhor que puder para ajudar o projeto. Abaixo apresentamos uma breve descrição dos papéis dentro do XP (BECK, 2005) (IMPROVEIT, 2013): Analistas de Teste: Analistas de teste em um projeto XP têm um papel proativo. No início de cada iteração, eles ajudam clientes e desenvolvedores a escrever testes para as histórias, antes mesmo que elas sejam implementadas. Além disso, trabalham com os desenvolvedores ao longo da iteração, ajudando-os a automatizar os testes. Quando a equipe não consegue automatizar alguns testes, os analistas de teste os executam manualmente. Arquitetos: Arquitetos de software em um projeto XP ajudam os desenvolvedores no dia-a-dia através da programação em par. Além disso, utilizam

25 Capítulo 2. Visão Geral dos Métodos Ágeis 24 seus conhecimentos para ajudar a equipe a fazer refatorações em larga escala, em passos curtos e seguros. Designers de Interação: Designers de interação trabalham próximo aos clientes em um projeto XP. Eles os ajudam a escrever histórias e escolher metáforas consistentes para o projeto. Além disso, ajudam a criar a interface e a refiná-la continuamente ao longo do tempo. Designers de interação também avaliam o uso das funcionalidades pelos clientes à medida que vão sendo entregues no final de cada ciclo semanal. Executivos: Executivos ajudam na definição do escopo do projeto. Eles comunicam os objetivos do projeto dentro do contexto geral da organização e asseguram que as histórias estejam alinhadas com tais objetivos. Além disso, ajudam a comunicar o progresso da equipe para as demais áreas da organização. Gerentes de Projeto: Gerentes de projeto servem de ponte entre a equipe, os clientes e eventuais fornecedores. Ele assegura que as pessoas certas dialoguem dentro da equipe e fora dela. Nesse sentido, age como um facilitador no fluxo de comunicação do projeto. Seu propósito não é controlar a informação, mas assegurar que as pessoas consigam se comunicar prontamente. Gerentes de Produto: Gerentes de produto procuram definir histórias (no planejamento do ciclo semanal e temas (no planejamento do ciclo trimestral) que ajudem o produto a tomar um corpo coerente e harmônico. Eles ajudam a definir prioridades e esclarecem aspectos das histórias ao longo do desenvolvimento. Finalmente, gerentes de produto ajudam a reduzir o escopo quando a equipe está atrasada por alguma razão. Programadores: Programadores em uma equipe XP trabalham em pares implementando histórias. Eles também estimam as histórias durante o planejamento e automatizam tarefas repetitivas. Também são responsáveis por criar testes automatizados para tudo o que produzem. Isso é feito com a prática de desenvolvimento orientado a testes. Além de criarem novas funcionalidades, também refatoram o sistema permanentemente para aprimorar a arquitetura, eliminar duplicações e tornar o código mais claro. Recursos Humanos: Projetos XP afetam as práticas de recursos humanos de uma organização, em particular no que se refere a contratações e avaliações periódicas dos funcionários. O fato de os programadores trabalharem em pares, por exemplo, leva à necessidade de pessoas que não apenas tenham boas habilidades técnicas, mas também saibam interagir socialmente com naturalidade. Portanto, a contratação não pode se basear apenas em

26 Capítulo 2. Visão Geral dos Métodos Ágeis 25 critérios técnicos e as avaliações individuais se tornam complexas porque é difícil isolar o rendimento do trabalho individual quando se trabalha em par a maior parte do tempo. Redatores Técnicos: Redatores técnicos ajudam a equipe a criar e manter a documentação do projeto. Redatores técnicos asseguram que a documentação evolua de forma iterativa. Em vez de investirem em documentar o projeto, extensivamente, desde o início de cada iteração, redatores técnicos atualizam os documentos mais perto do fim das iterações. Usuários: Usuários em uma equipe XP ajudam a escrever e selecionar histórias e tomam decisões relativas ao domínio do negócio durante o desenvolvimento. Sua participação é tão valiosa quanto for seu conhecimento sobre o domínio do negócio. É ainda melhor quando os usuários têm experiência com sistemas semelhantes no passado (BECK, 2005) (IMPROVEIT, 2013). 2.4 Lean As origens do Lean Manufacturing remontam ao Sistema Toyota de Produção (também conhecido como Produção Just-in-Time). O Sistema Toyota de Produção surgiu no Japão, na fábrica de automóveis Toyota, logo após a Segunda Guerra Mundial. Naquela época a indústria japonesa tinha uma produtividade muito baixa e uma enorme falta de recursos, o que a impedia de adotar o modelo da produção em massa. A criação do Sistema Toyota de Produção se deve, principalmente, a quatro pessoas: O fundador da Toyota e mestre de invenções, Sakichi Toyoda, seu filho Kiichiro Toyoda, primo de Eiji Toyoda que participou como o executivo impulsionador do nascimento do STP (Sistema Toyota de Produção) e o engenheiro chefe da Toyota Motors Company, o chinês Taiichi Ohno. O sistema objetiva aumentar a eficiência da produção pela eliminação contínua de desperdícios. O sistema de produção em massa desenvolvido por Frederick Taylor e Henry Ford no início do século XX predominou no mundo até a década de 90. Procurava reduzir os custos unitários dos produtos através da produção em larga escala, especialização e divisão do trabalho. Entretanto, este sistema tinha que operar com estoques e lotes de produção elevados. Dentre as filosofias do Lean está a redução dos sete tipos de desperdícios identificados por Taiichi Ohno: defeitos (nos produtos), excesso de produção de mercadorias desnecessárias, estoques de mercadorias à espera de processamento ou consumo, processamento desnecessário, movimento desnecessário de pessoas, transporte desnecessários (de mercadorias) e espera (dos funcionários pelo equipamento de processamento para finalizar o trabalho ou por uma atividade anterior) (JONES, 1992).

27 Capítulo 2. Visão Geral dos Métodos Ágeis 26 são: As principais ferramentas usadas para colocar em prática os princípios do Lean Mapeamento do Fluxo de Valor; Métricas Lean; Kaizen; Kanban; Padronização; 5S; Redução de Setup; TPM (Total Productive Maintenance); Gestão Visual; Poka-Yoke (Mistake Proofing) Desenvolvimento Lean de Software Em 2003 Mary e Tom Poppendieck identificaram alguns princípios e práticas atrelados à abordagem lean de melhoria do desempenho operacional, que foi inicialmente disseminada no contexto de manufatura, como base para os métodos de desenvolvimento ágeis de software (POPPENDIECK; POPPENDIECK, 2011). Assim, foi introduzido o conceito de desenvolvimento de software lean e desde então, a comunidade ágil tem cada vez mais olhado em sua direção. Dentre as ferramentas citadas descreveremos um pouco mais o Kanban no próximo tópico. Vamos utilizar de algumas ideias da metodologia para fazer o nosso quadro kanban, por ser simples e fácil de ser aprendida. Além disto, o Kanban contempla um dos requisitos necessários para o projeto, que é o de melhorar a visualização do que a equipe está fazendo. 2.5 Kanban Kanban é uma palavra japonesa que significa literalmente registro ou placa visível. Em Administração da produção significa um cartão de sinalização que controla os fluxos de produção ou transportes em uma indústria. O cartão pode ser substituído por outro sistema de sinalização, como luzes, caixas vazias e até locais vazios demarcados. Coloca-se um Kanban em peças ou partes específicas de uma linha de produção, para indicar a entrega de uma determinada quantidade. Quando se esgotarem todas as

28 Capítulo 2. Visão Geral dos Métodos Ágeis 27 peças, o mesmo aviso é levado ao seu ponto de partida, onde se converte num novo pedido para mais peças. Quando for recebido o cartão ou quando não há nenhuma peça na caixa ou no local definido, então deve-se movimentar, produzir ou solicitar a produção da peça. O Kanban permite agilizar a entrega e a produção de peças. Pode ser empregado em indústrias montadoras, desde que o nível de produção não oscile em demasia. Os Kanbans físicos (cartões ou caixas) podem ser Kanbans de Produção ou Kanbans de Movimentação e transitam entre os locais de armazenagem e produção substituindo formulários e outras formas de solicitar peças, permitindo enfim que a produção se realize Just in time - metodologia desenvolvida e aperfeiçoada por Taiichi Ohno e Sakichi Toyoda conhecida como Sistema Toyota de Produção (KNIBERG, 2013). Existem três regras básicas para implementar o Kanban: Fluxo de Trabalho Visível. Limitar o Trabalho em Progresso (Limit Work in Progress - WIP). Medir e melhorar o fluxo. Para o uso do sistema, será desenvolvido um quadro kanban com algumas das técnicas da metodologia, ele ajudará na visualização do fluxo de trabalho, da equipe e individualmente. E com a visualização das atividades vai ficar melhor medir e melhorar o fluxo das mesmas.

29 28 3 Análise das Ferramentas de Gestão Ágil Este capítulo apresenta as ferramentas web opensource ou freeware mais conhecidas do mercado, descrevendo suas características de modo geral, e seus pontos fortes e fracos. No final, desenvolvemos uma tabela comparativa, onde colocamos os pontos básicos do fluxo do Scrum e o Kanban como pontos positivos, e colocamos funcionalidades adicionais como pontos negativos. Esse modo de pontuação fica de acordo com a filosofia da ferramenta proposta de ter o mínimo possível para um fluxo completo, facilidade no aprendizado, e não ser uma ferramenta com vários recursos, e sim um primeiro passo na filosofia ágil. 3.1 Ferramentas XPlanner O XPlanner é uma ferramenta de código livre utilizada para auxiliar no planejamento e acompanhamento de projetos de software, podendo ser utilizada em processos de desenvolvimento tradicionais e ágeis. Suas principais características são as iterações, histórias de usuários (users stories) e as tarefas, referentes ao projeto de software, que podem ser planejadas e posteriormente acompanhadas, dando maior visibilidade à equipe quanto a evolução das atividades. Criada por volta de 2004, é implementado usando Java (ARNOLD GOSLING, 2006), JSP (JSP, 2013), Struts (STRUTS, 2013), Hibernate (HIBERNATE, 2013) e MySQL (MYSQL, 2013). Alguns dos recursos descritos na página da aplicação: Modelo de planejamento simples, Cartões Virtuais, Suporte para o acompanhamento de projetos, iterações, histórias de usuários e tarefas, Continuação inteligente de histórias inacabadas, Token de integração distribuídos, Controle de tempo on-line e geração de folha de tempo individual / equipe de nível, Geração de Métricas, Gráficos de velocidade iteração, Scrum Burn Down, Capacidade para anexar notas às histórias e tarefas, Iteração com a estimativa visível, Página que mostra o status da tarefa e história para os desenvolvedores individuais e clientes, Exportação de projeto e informações iteração para XML (XML, 2013), MPX (MPX, 2013), PDF (PDF, 2013), e formatos ical, Interfaces SOAP (SOAP, 2013) para integração, Suporte para os idiomas Inglês, Espanhol, Francês, Alemão, Italiano, Português Brasileiro, dinamarquês, russo, chinês e japonês. Atualmente o projeto se encontra parado, com sua última versão em 2006, e sem uma versão estável (XPLANNER, 2012).

30 Capítulo 3. Análise das Ferramentas de Gestão Ágil Firescrum Firescrum é uma ferramenta de código aberto desenvolvido para apoiar a gestão de projetos ágeis sob a metodologia SCRUM. Tem características RIA (Rich Internet Application) (RIA, 2013). Desenvolvido dentro de uma Tese de Mestrado do CESAR.EDU (CESAREDU, 2013), atualmente faz parte do INES (Instituto Nacional de Ciência e Tecnologia para Engenharia de Software) (INES, 2013). Abordando como foco em equipes distribuídas, acompanhamento do projeto pelo cliente e querem manter a visibilidade das atividades sem ter que manter um quadro físico. O desenvolvimento da aplicação se encontra parado, sua última versão é de 6 de abril de 2011, é desenvolvido usando Java (ARNOLD GOSLING, 2006), Flex (FLEX, 2013), Red5 (RED5, 2013) e BlazeDS (BLAZEDS, 2013) (FIRESCRUM, 2012) Icescrum IceScrum é um aplicativo web com foco no Scrum, se utiliza de algumas outras premissas ágeis como Kanban, também tem o foco em equipe distribuídas, mantendo o espírito de um espaço de trabalho colaborativo. Desenvolvido em Java (ARNOLD GOS- LING, 2006) e JSP (JSP, 2013), tem uma comunidade bem ativa, e o seu desenvolvimento está constante. Em desvantagem possui uma versão paga kagilum, não existe versão em português e é focado em equipes que já conhecem o ágil. Alguns recursos citados no seu site: Product Backlog; Sprint plan; Dashboard; Actors; Team; Release Plan; Sandbox; Timeline; Features; Indicators (ICESCRUM, 2012) Agilefant AgileFant é uma ferramenta web livre para o gerenciamento e desenvolvimento ágil de software. Ela foi desenvolvida por Software Business and Engineering Institute (SOBERIT, 2013) da Universidade de Tecnologia da cidade de Helsínquia na Finlândia. Tem como objetivo ser o mais simples possível. Implementa algumas ferramentas ágeis, deixando o quadro Kanban de fora. Desenvolvida na linguagem Java (ARNOLD GOSLING, 2006). Dentre as suas características podemos citar: Timesheets e o gerenciador de Backlog (AGILEFANT, 2012). 3.2 Comparativo A tabela 1 apresenta uma análise comparativa das funcionalidades relevantes entre as ferramentas analisadas e a ferramenta proposta. Como a proposta da aplicação é ter um fluxo de controle de atividades completo, utilizando o mínimo de etapas possíveis, sem adicionar controles ou fluxos desnecessários, as quais, podem em um sistema de

31 Capítulo 3. Análise das Ferramentas de Gestão Ágil 30 aprendizado complicar o aprendizado dos conceitos. Desse modo a tabela descreve com o caractere (+) pontos positivos na proposta explicada e pontos negativos com o caractere (-). As funcionalidades básicas obrigatórias foram selecionadas através dos protótipos gerados com os usuários, onde através desses se pode ter um fluxo completo do gerenciamento das atividades, sendo desse modo o foco inicial do desenvolvimento do sistema. As características básicas estão sublinhadas, e as aplicações que as implementam ganham um ponto positivo. Qualquer atividade adicional como proposta da aplicação é um ponto negativo. Tabela 1 Análise das Funcionalidades Funcionalidades XPlanner Firescrum Icescrum Agilefant First Step in Agile Gerenciador de Produto Gerenciador de Iteração Quadro de Atividades Gerenciador de Usuário Report and Analytics BurnDown - - Planning Poker - Sistema de Aprendizado + Desktop Agent - Sendo assim, podemos verificar que as ferramentas citadas não se enquadram na proposta da First Step in Agile, ou por falta de funcionalidades básicas, ou por conter funcionalidades adicionais que podem dificultar a apresentação das metodologias ágeis para pessoas iniciantes. Dentre as funcionalidades citadas da tabela podemos notar que First Step in Agile é a única que tem o sistema de aprendizado, ressaltando o foco da ferramenta. Temos que ressaltar que a proposta do sistema é ser o primeiro passo no caminho do desenvolvimento ágil, e dar uma visão dos benefícios que o mesmo pode ocasionar, não sendo desenvolvido para suprir uma metodologia completamente.

32 31 4 A Aplicação First Step In Agile Este capítulo aborda as práticas e ferramentas usadas na aplicação proposta, sua descrição e os motivos pelos quais foram selecionados. Também serão apresentadas as técnicas utilizadas na definição e elaboração da ferramenta proposta. Nos protótipos se teve o foco justamente na questão da simplicidade e na ferramenta guia. Como seria a interação do usuário com essas ideias. De acordo com a proposta da aplicação de ter etapas simples e exibir um guia para equipes iniciantes. Foi utilizada a técnica de prototipagem em papel para simular interfaces e seus comportamentos, um dos tipos menos custosos de protótipos conhecidos. Uma enorme quantidade de informação pode ser adquirida através do uso de protótipos em papel, podendo até revelar, entre os membros da equipe, aspectos graves ou o mau comportamento de tarefas (LEWIS, 1994). O uso dos modelos em papel favorece rapidez à qual já se propõem os protótipos de uma maneira geral. Embora a teoria e prática desta técnica sejam essencialmente simples, uma grande quantidade de feedback pode ser adquirida em testes de usabilidade, figurando assim como uma ferramenta frequentemente utilizada por especialistas em usabilidade (SNYDER, 2003). Nesta pesquisa, essa técnica foi utilizada para elaborar as principais telas do sistema. Identificando antes da implementação o fluxo principal e novos requisitos. O uso dessa ferramenta desvia o foco da tecnologia para a experiência humana, onde o usuário expressará o que achou da experiência, considerando seus aspectos físicos, emocional, cognitivo e cultural. Dessa forma, a observação do usuário em contexto é que fornecerá as especificações, conceitos e a solução integrada final. Por essa razão, o uso de protótipos é tão valioso. Eles que proporcionarão a oportunidade de demonstrar como poderia ser a interação de uma equipe ágil através de uma aplicação que permita: O desenvolvimento do tutorial interno da ferramenta; O levantamento de requisitos; Seleção das atividades para o ciclo de desenvolvimento; Gerenciamento das tarefas (kanban); Entrega do pacote de atividades no final do ciclo; Comunicação entre membros da equipe.

33 Capítulo 4. A Aplicação First Step In Agile Técnicas e Ferramentas Utilizadas da aplicação. Este tópico trata sobre as ferramentas e técnicas utilizadas para o desenvolvimento Histórias Para o desenvolvimento da aplicação foram selecionadas determinadas histórias, elaboradas a partir do fluxo do Scrum e das necessidades de gerenciamento do controle de acesso da aplicação web proposta. A partir dessa seleção foram elaboradas as histórias necessárias e que serão descritas abaixo: 1. Como um visitante, eu quero fazer meu cadastro de usuário, para poder ter acesso ao sistema ; 2. Como um usuário, eu quero poder acessar o sistema com um login e senha 3. Como um usuário, eu quero cadastrar um projeto, e poder convidar outros usuários para fazer parte do mesmo ; 4. Como um dono do produto, eu quero cadastrar uma nova história para que possa colocá-la no backlog do projeto ; 5. Como um participante da equipe, eu quero elaborar as atividades de uma história para que eu possa desenvolvê-la. 6. Como um iniciante em metodologias ágeis, eu quero ter um acompanhamento dos passos que devo seguir e o porquê, para que eu possa aprender a metodologia, entendendo cada etapa e quais as suas vantagens. ; 7. Como um participante da equipe, eu quero poder ver as atividades de um Sprint no Kanban e assim verificar o efetivo desenvolvimento do Projeto pela equipe. ; 8. Como um participante da equipe, eu quero poder saber quantos dias faltam para terminar o Sprint de forma fácil 9. Como um participante da equipe, eu quero poder criar um Sprint, especificando sua data de inicio, data fim, nome e descrição. 10. Como um participante da equipe, eu quero poder selecionar quais as histórias que farão parte do Sprint Backlog. 11. Como um participante da equipe, eu quero poder gerenciar minhas atividades através do Kanban de forma simples, para que eu não perca tempo com fluxos desnecessários.

34 Capítulo 4. A Aplicação First Step In Agile Protótipos de baixa fidelidade Nesta etapa, a partir do uso de protótipos de baixa fidelidade, é verificado o fluxo das funcionalidades da aplicação. Nesse trabalho foram elaborados os seguintes protótipos: Figura 2 Protótipo Tela de Login Figura 3 Protótipo Tela Principal

35 Capítulo 4. A Aplicação First Step In Agile 34 Figura 4 Protótipo Tela de Projetos Figura 5 Protótipo Tela de Backlog Figura 6 Protótipo Tela de Atividades

36 Capítulo 4. A Aplicação First Step In Agile 35 Figura 7 Protótipo Tela de Sprints Figura 8 Protótipo Tela de Backlog Sprints Figura 9 Protótipo da Tela do Kanban Com esses protótipos poderemos testar as funcionalidades da aplicação antes do seu desenvolvimento.

37 Capítulo 4. A Aplicação First Step In Agile Validação com Usuário Os protótipos em papel estão sendo utilizados para uma melhor definição dos requisitos e a interface com o usuário. As figuras 10 e 11 mostram exemplos de protótipos em papel da tela do Kanban. Figura 10 Validação com o usuário 1 Figura 11 Validação com o usuário 2 Com a utilização dos protótipos podemos recolher novos requisitos, melhorar a interface, entre outros benefícios. Entre esses podemos citar: Substituição de um menu dinâmico para acesso as janelas por abas de acesso rápido e sequencial. Necessidade de adicionar a entidade "Projeto"ao sistema, pois os usuários viram a necessidade de centralizar o projeto de várias equipes em um único sistema. Criar um sistema de convites para acessar os Projetos.

38 Capítulo 4. A Aplicação First Step In Agile 37 Mudar o local onde ficava o tutorial, do canto esquerdo para o direito, e fixar o tutorial. Adicionar o Time-box do Sprint na barra superior. Poder adicionar as cores as atividades. Várias melhorias da interface. 4.3 Práticas Ágeis Selecionadas para o Sistema Quadro kanban No sistema, foi utilizado um quadro "kanban", com algumas ideias da metodologia Kanban, de modo mais simplificado, com apenas quatro etapas para as atividades selecionadas para um Sprint. A escolha de algumas funcionalidades da metodologia Kanban foi devido a suas características descritas na seção 2.5, dentre elas a capacidade de melhorar a visibilidade das atividades que a equipe está desenvolvendo. Além disso, o Kanban é um sistema de fácil gerenciamento. As etapas selecionadas para o quadro kanban da aplicação foram as mais usuais no desenvolvimento de software, onde foram selecionadas apenas as seguintes etapas: Parado: Etapa onde as atividades estão a disposição para serem feitas; Fazendo: As atividades estão sendo desenvolvidas; Teste: Estão para teste; Feito: As atividades foram testadas e concluídas. Além das etapas, o quadro mostrará as prioridades das atividades, sendo as que tiverem mais acima as de maior prioridade. Posteriormente será adicionada a funcionalidade de limitar o trabalho em progresso por etapas (Work-In-Progress - WIP) Histórias de Usuário (User Story) Por sua simplicidade e fácil aprendizado as Histórias de Usuário (User Story) serão utilizadas no sistema para o levantamento de requisitos e através delas serão geradas as atividades. As Histórias de Usuário são mais fáceis de serem desenvolvidas e isso facilita novas equipes no aprendizado de levantamento de requisitos. No sistema teremos uma tela onde poderemos cadastrar e exibir as Histórias de Usuário. As propriedades de cada História são:

39 Capítulo 4. A Aplicação First Step In Agile 38 Nome nome de forma a ficar fácil a sua identificação; Descrição descrição com todas as informações necessárias para sua elaboração; Valor valor da história, o tipo do valor fica a critério da equipe; Cor para facilitar a identificação, podem ser utilizadas cores como label para bugs, novas funcionalidades entre outras. Ficando a critério da equipe a necessidade do seu uso; Criador quem criou a história. Será a pessoa que terá as informações em caso de dúvidas; Executor o desenvolvedor que está executando a História Atividades As atividades são a base do sistema, geradas a partir da quebra das Histórias de Usuário, servindo para o desenvolvimento em etapas das mesmas. O fluxo do Kanban será focado nas atividades e não nas histórias. As propriedades das Atividades são: Nome identificador da atividade; Descrição descreve todas as informações necessárias para a sua elaboração; Valor - valor da atividade. O tipo do valor fica a critério da equipe; Sprint É um período acordado com a equipe de 1 a 4 semanas, que tem uma lista de histórias a serem desenvolvidas e entregues no final para o cliente. A data limite não pode ser ultrapassada. Dentro do Sprint existem algumas cerimônias: Reunião de Planejamento da Sprint (Sprint Planning Meeting), dividida em duas etapas: Após as histórias estarem priorizadas no Product Backlog, a equipe define quais histórias serão realizadas em um determinado Sprint. Logo após quebra as histórias em atividades. Reunião Diária (Daily Scrum); Reunião de Revisão da Sprint (Sprint Review Meeting); Reunião de Retrospectiva da Sprint (Sprint Retrospective). Dentro do sistema teremos uma janela onde será possível o cadastro das Sprints e seu gerenciamento, podendo colocar e retirar Histórias. Na Sprint teremos os seguintes campos:

40 Capítulo 4. A Aplicação First Step In Agile 39 Nome nome do Sprint. Objetivo objetivo ou tema da Sprint. Data Início data de início do Time-Box da Sprint. Data Final data final do time box da Sprint. Sprint Fechado marcador que informa que a Sprint foi fechada. Lista de Histórias lista de histórias que serão desenvolvidas na Sprint Time-Box Conceito primordial do Scrum (SABBAGH, 2013), o Time-Box é um período de tempo bem definido e imutável, que faz parte do compromisso da equipe com suas metas. O time box faz com que as iterações ocorram, a equipe fique centrada no objetivo da iteração e, com isso, diminua a dispersão. O Time-Box dentro do sistema será exibido no centro da barra superior do sistema. Sendo calculado a partir da data de entrega do Sprint vigente. 4.4 Demonstração On-line no Heroku Heroku é uma plataforma de serviço em nuvem que suporta várias linguagens de programação. Ele foi uma das primeiras plataformas de nuvem, já está em desenvolvimento desde junho de 2007, quando suportava apenas a linguagem de programação Ruby, mas, desde então, adicionou suporte para Java, Node.js, Scala, Clojure, Python e PHP. O sistema operacional de base é Debian (HEROKU, 2014). O Heroku foi utilizado para instalar uma versão de demonstração sistema, o qual pode ser acessado pela url: <

41 40 5 O Desenvolvimento da Aplicação First Step In Agile 5.1 Visão Geral Esse capítulo visa a apresentação das tecnologias utilizadas para o desenvolvimento da aplicação First Step in Agile, as práticas selecionadas e seu fluxo de trabalho. 5.2 Desenvolvimento da Aplicação A aplicação foi desenvolvida na linguagem Java, utilizando os Frameworks Wicket (WICKET, 2013), Hibernate (HIBERNATE, 2013) e Spring (SPRING, 2013) na sua estrutura base. Na camada de visualização utilizou-se HTML (HTML, 2013), CSS (CSS, 2013) e JavaScript (JAVASCRIPT, 2013). Foi utilizado o controle de versionamento de código Git (GIT, 2013), e seu código fonte sendo armazenado no Github (GITHUB, 2013), onde se encontra como um projeto de código aberto Java Java é uma linguagem de programação orientada a objeto desenvolvida na década de 90 pelo programador James Gosling, na empresa Sun Microsystems (SUN, 2013). Diferentemente das linguagens convencionais, que são compiladas para código nativo, ou seja, o código é compilado para rodar somente para aquele sistema operacional, a linguagem Java é pré-compilada, e o resultado é um bytecode que será interpretado pela Máquina Virtual Java (ARNOLD GOSLING, 2006). A Máquina Virtual Java está disponível para os principais sistemas operacionais do mercado, sendo assim Java não é uma linguagem compilada nem interpretada e sim pré-compilada. Java é uma linguagem híbrida, um dos motivos é seus tipos primitivos de variáveis. Outra característica é sua tipagem estática e forte, ou seja, quando se é criado um objeto no código fonte ele não poderá mudar mais seu tipo. O Java que tem sua sintaxe e tipos primitivos herdados da linguagem C++ (GCC, 2013). O Java teve sua explosão a partir dos seus aplicativos para internet, que rodavam dentro dos navegadores. Os Applets se tornaram sinônimo de dinamismo das páginas web de todo o planeta (ARNOLD GOSLING, 2006). Com essa versatilidade desses pequenos aplicativos acabou aumentando a curiosidade de vários desenvolvedores, crescendo para se tornar a linguagem mais utilizada no desenvolvimento mundial (TIOBE, 2013). Hoje o Java possui uma vasta biblioteca de recursos, sendo utilizada para desenvolvimento

42 Capítulo 5. O Desenvolvimento da Aplicação First Step In Agile 41 de Aplicativos para internet, desktop, celulares, cartões, eletrodomésticos entre outros (ARNOLD GOSLING, 2006) Wicket O Apache Wicket é um framework orientado a componentes para desenvolvimento de aplicações Web baseado em Java (ARNOLD GOSLING, 2006) e que teve sua primeira versão lançada em 2005, sob os cuidados da Apache Software Foundation. O conceito de separar a lógica de programação e código HTML facilita o desenvolvimento de aplicações com um poderoso mecanismo de reutilização de componentes. A separação entre código HTML (HTML, 2013) e lógica de programação permite também a divisão de responsabilidades. Com isso, uma equipe de arte visual fica responsável pela criação das páginas HTML, sem a necessidade de que o grupo entenda algo sobre o framework, enquanto o programador fica responsável pela lógica e funcionalidades do sistema. Em outras palavras, essa divisão, propõem além de possibilitar que cada área cuide daquilo em que é especialista, também acelera o processo de desenvolvimento (WICKET, 2013) Hibernate O Hibernate é um framework para o mapeamento objeto-relacional escrito na linguagem Java. Este framework facilita o mapeamento dos atributos entre uma base tradicional de dados relacionais e o modelo objeto de uma aplicação, mediante o uso de arquivos XML (XML, 2013) ou anotações Java. É um software livre de código aberto distribuído com a licença LGPL. As questões relacionadas para o gerenciamento de transações e na tecnologia de acesso à base de dados são de responsabilidade de outros elementos na infraestrutura do programa. Hibernate foi criado por desenvolvedores Java, espalhados ao redor do mundo, e liderado por Gavin King. Posteriormente, JBoss Inc contratou os principais desenvolvedores do programa para fazer o seu suporte (HIBERNATE, 2013) Spring O Spring é um framework open source para a plataforma Java criado por Rod Johnson. Trata-se de um framework não intrusivo, baseado nos padrões de projeto inversão de controle (IoC) e injeção de dependência. No Spring o container se encarrega de instanciar classes de uma aplicação Java e definir as dependências entre elas através de um arquivo de configuração em formato XML (XML, 2013), inferências do framework, o que é chamado de auto-wiring ou ainda anotações nas classes, métodos e propriedades. Dessa forma o Spring permite o baixo acoplamento entre classes de uma aplicação orientada a objetos.

43 Capítulo 5. O Desenvolvimento da Aplicação First Step In Agile 42 O Spring possui uma arquitetura baseada em interfaces e POJOs (Plain Old Java Objects), oferecendo aos POJOs características como mecanismos de segurança e controle de transações (SPRING, 2013). 5.3 Arquitetura da Aplicação Nessa seção apresentaremos a arquitetura da aplicação utilizada no seu desenvolvimento, apresentando seu diagrama de classe e sua separação em camadas Diagrama de Classe Na figura 12 está o diagrama de classe das entidades de negócio do sistema, utilizadas por todas as camadas da aplicação. Figura 12 Diagrama de Classe das Entidades Camadas da Aplicação Na figura 13 podemos ver a separação das camadas da aplicação, exibindo dentro de uma arquitetura MVC (M.DASHORST, 2008) onde atua cada framework utilizado. 5.4 Principais Funcionalidades Nesse capítulo são apresentadas as principais funcionalidades e fluxos do sistema através das suas telas, cujas histórias foram descritas no capítulo 4. Uma lista completa

44 Capítulo 5. O Desenvolvimento da Aplicação First Step In Agile 43 Figura 13 Camadas da aplicação das telas em tamanho maior pode ser encontrada no Apêndice A Tela de Login Essa tela será a tela de Login e de apresentação do sistema, referente a história 2 e o protótipo da figura 2, descritos no capítulo 4. Figura 14 Tela de Login Time-Box View O sistema exibe um contador mostrando quantos dias faltam para terminar o Sprint atual. Lembrando a equipe o tempo acordado para a entrega das histórias selecionadas. De acordo com a história 8 e do protótipo da figura 3 no capítulo 4.

45 Capítulo 5. O Desenvolvimento da Aplicação First Step In Agile 44 Figura 15 TimeBox Tutorial Entre as funcionalidades do sistema, o tutorial interno se destaca como sendo o principal foco da aplicação. O tutorial tem como finalidade guiar o usuário no aprendizado da metodologia Scrum, utilizando as ideias selecionadas. Cada etapa do sistema tem um tutorial que se encontra do lado direito da tela. Assim que for acessado, ele exibe as informações referentes à tela que se encontra no momento, como mostra a figura 16. Funcionalidade desenvolvida de acordo com a história 6 e do protótipo da figura 3 do capítulo 4.Uma lista completa dos tutoriais pode ser encontrada no Apêndice B. Figura 16 Tutorial Janela Projetos Na janela dos projetos, mostrada na figura 24 podemos fazer o cadastro dos projetos, e visualizar quais os projetos que somos convidados, e podemos selecionar qual o projeto

46 Capítulo 5. O Desenvolvimento da Aplicação First Step In Agile 45 de trabalho atual, essa janela foi elabora de acordo com a história número 3 e do protótipo da figura 4 do capítulo 4. Figura 17 Janela de Gerenciamento dos Projetos Janela Backlog Na janela das histórias, mostrada na figura 25 podemos fazer o cadastro das mesmas, editar, deletar e gerenciar suas prioridades com os controles laterais, de acordo com a história número 4 e do protótipo da figura 5 do capítulo 4. Figura 18 Janela do Backlog Janela das Atividades Na janela das Atividades teremos as opções de editar, criar, excluir e selecionar uma história para a exibição das suas atividades, que serão mostradas no painel da direita.

47 Capítulo 5. O Desenvolvimento da Aplicação First Step In Agile 46 Também estão disponíveis as seguintes opções: editar, criar e excluir as atividades da história selecionada. Janela elabora de acordo com a história 5 e do protótipo da figura 6 do capítulo 4. Figura 19 Janela das Atividades Janela dos Sprints De acordo com a história 9 e do protótipo da figura 7 do capítulo 4, elaboramos a tela dos Sprints que pode ser vista na figura 27 descrevendo como é feita a criação dos Sprint, cadastrando seu nome, descrição, data de inicio e fim. E temos a opção de selecionar o Sprint atual. Figura 20 Janela de Cadastro dos Sprints

48 Capítulo 5. O Desenvolvimento da Aplicação First Step In Agile Janela Sprint Backlog De acordo com a História 10 e do protótipo da figura 8 do capítulo 4, na figura 28 podemos ver como é feita a seleção das histórias para o sprint atual. Temos as seguintes opções: editar, criar, deletar e selecionar uma história para o sprint atual, onde suas histórias serão exibidas no painel à direita. Figura 21 Janela do Sprint Backlog Janela do Kanban Janela que pretende ser a mais utilizada do sistema, onde todos os integrantes da equipe poderão ver as atividades das histórias e controlar seu fluxo nas etapas selecionadas para as atividades, que são: Parada, Fazendo, Teste e Feito. Nessa janela temos a opção de editar, excluir a história, de editar, excluir, mudar a prioridade e controlar o estado da atividade. Janela elabora de acordo com a história número 11 e do protótipo 9 do capítulo 4. Figura 22 Janela do Kanban