Scrum em Aplicações Móveis

ISSN 2316-2872 T.I.S. São Carlos, v. 2, n. 3, p. 211-219, set-dez 2013 Tecnologias, Infraestrutura e Software Resumo: A metodologia ágil Scrum foi criada para o gerenciamento de projetos de desenvolvimento de software onde pode ser utilizada por equipes menores em projetos desenvolvidos em um curto espaço de tempo. O Scrum tornou-se um sucesso devido à rapidez no processo de desenvolvimento e entrega do produto, podemos citar alguns pontos que influenciaram diretamente para alcançarmos estes resultados, como a redução na documentação, a entrega de funcionalidades do projeto já desenvolvidas e testadas, o feedback diário entre os desenvolvedores e a comunicação sempre constante entre o cliente e equipe de desenvolvimento. Para aplicações móveis, o Scrum apresenta-se como uma das melhores metodologias para o desenvolvimento destas aplicações, resultante dos fatores essenciais em que o Scrum é um sucesso, como no desenvolvimento em curto prazo de aplicações que não apresentem funcionalidades complexas. O objetivo deste artigo é a utilização de uma metodologia que se mostre eficaz para o desenvolvimento de aplicações móveis, sempre em um curto espaço de tempo, com uma equipe reduzida e ao mesmo tempo utilizando a documentação somente para armazenar o que o produto possui de essencial. A proposta citada no texto é baseada no método Scrum que define práticas simples, mas que permitem mudanças em qualquer fase do desenvolvimento. Com a implementação dessa metodologia permitiu-se o desenvolvimento da aplicação móvel necessária no prazo desejável sem maiores transtornos. Palavras Chave: aplicações móveis, metodologia ágil, scrum Scrum in mobile applications Abstract: The agile Scrum methodology was created for managing software development projects which can be used by smaller teams in projects developed in a short time. The Scrum has become a success because of the speed in process development and product delivery. We can mention a few points that directly influenced to achieve these results, as the reduction of documentation, delivery of the project requirements already developed and tested, the daily feedback among the developers and the constant communication between the client and development team. For mobile applications development, Scrum represents one of the best methodologies, due to essential and successful Scrum characteristics, as the development of applications in a short time without complex features. The purpose of this article is the implementation of a methodology that proves to be effective for developing mobile applications, in a short time, with a small team and simultaneously using the documentation only to store the essential definitions ofthe product. A proposal ofthe text is based on Scrum methods that defines simple practices, but allow changes at any stage of development. With the application of this methodology, it was possible the development ofmobile application required within the desirable schedule, without major preoccupations. Keywords: mobile application, agile methodology, Scrum I. INTRODUÇÃO Em um mercado global onde o avanço da tecnologia e a concorrência cada vez maior entre fabricantes de dispositivos móveis, a necessidade de aplicações que suportem esses dispositivos nunca foi tão exigida como nos dias de hoje. Com o desenvolvimento desordenado dessas aplicações, percebeu-se que o processo poderia ser melhorado com metodologias capazes de aperfeiçoar o processo de desenvolvimento, que são as metodologias ágeis, que representam métodos eficientes e rápidos que buscam minimizar os riscos de desenvolvimento em curtos períodos. Além da metodologia Scrum, outras metodologias ágeis também podem ser utilizadas, todas seguindo os mesmos processos fundamentais já citados no resumo, porém cada uma com suas características especificas. Os métodos mais utilizados, Crystal, XP Extreme Programming, Lean Software Development e Feature Driven Development podem ser vistos a seguir. Estes métodos terão uma apresentação rápida, e não detalhada de cada processo, para mostrar que os mesmos também possuem suas particularidades e semelhanças em vários processos com o Scrum que iremos detalhar neste artigo II. TRABALHOS CORRELATOS Em um estudo sobre o espaço de trabalho informativo e o Departamento de Computação - Universidade Federal de São Carlos (UFSCar) Caixa Postal 676 13.565-905 São Carlos SP Brasil Autor para correspondência: william.jandoza@gmail.com, prado@dc.ufscar.br

acompanhamento de equipes ágeis de desenvolvimento de software, OLIVEIRA, Renan de Melo (2012) realizou um estudo onde o mesmo acompanhou equipes de desenvolvimento ágeis, a fim de obter resultados sobre a utilização de métodos mistos sequencias, foi observado que a abordagem permitiu dados mais completos para extrair resultados ainda melhores sobre o tema abordado. Renan elaborou um questionário fechado de questões quantitativas, pois sem ela ele não teria dados para justificar a utilidade das heurísticas levantadas. Ele observou também que essa metodologia pode ser pesquisada também em ambientes comercias. Na tese de mestrado, LUIZ BASSI FILHO, Dairton(2008) realiza varias pesquisas com equipes de desenvolvimento ágil. O mesmo conclui que os fatores motivacionais e psicológicos possuem um peso muito maior independente da metodologia ágil utilizada. Ele diz que enquanto a execução do software é uma tarefa precisa o desenvolvimento do software não é, pois a execução é feita por uma maquina enquanto o desenvolvimento é realizado por pessoas. E esta diferença é ignorada por métodos que se baseiam em esforços no processo como se fossem responsáveis pela produção do software. Como vimos nas pesquisas citadas acimas, todas tratam somente o desenvolvimento independente de aplicações, visando somente o resultado na diferença e fatores de uma metodologia a outra. Neste artigo além de citarmos e especificarmos algumas metodologias, temos o foco voltado para o desenvolvimento de uma aplicação em dispositivo móvel, onde o desenvolvimento tem de ser realizado de uma forma rápida e abrangente, visto que existem vários dispositivos móveis com sistemas operacionais e componentes distintos, onde a evolução e atualização dos mesmos são constantes. Isso torna a pesquisa do artigo diferenciada com resultados também diferenciados. A linguagem Android que utilizamos para o desenvolvimento da aplicação móvel também não é citada em nenhum dos estudos analisadas, que de modo geral vem ganhando um enorme espaço do mercado mundial de dispositivos móveis III. CONCEITOS E TECNOLOGIAS Esta seção apresenta os principais conceitos e tecnologias relacionadas com o tema deste projeto, bem como as mais utilizadas. Assim temos exemplos de metodologias ágeis, que podem vir a serem utilizadas em projetos como este que será citado neste artigo e posteriores a este. A. Extreme Programming XP Essa metodologia é a que mais possui adeptos, ela foi difundida em 1999 através do livro Extreme programming Explained: Embrace Change, de Kent Beck, que foi o criador do método juntamente com Ward Cunningham entre outros. Nessa metodologia são apresentados cinco valores: simplicidade, coragem, comunicação, feedback e respeito. Dentre vários controles que o XP possui, a mudança no processo mais marcante é o escopo do projeto onde se orienta a priorização de funcionalidades mais importantes para o negócio, fazendo isso caso seja necessária à diminuição do escopo, serão descartadas as funcionalidades de menor valor. Para a aplicação dos valores durante o processo de desenvolvimento, o XP mostra varias praticas, formando uma sinergia entre elas, mostrando alguns pontos fortes e outros pontos fracos que veremos a seguir. Programação em par Programação em par ou programação pareada consiste entre o desenvolvimento de dois programadores em um micro computador, assim gerando um único código fonte, essa pratica é pouco utilizada, porém muito defendida por varias pessoas. A grande responsabilidade da não utilização desta prática fica com os gestores, gerentes, supervisores, etc., que não acreditam que o resultado obtido seja vantajoso. Já seus defensores alegam que apesar do custo maior, o resultado é compensatório devido à baixa correção tanto de erros, quanto a correção de design em interfaces. Desenvolvimento orientado a testes Beck, diz que no XP, duas mudanças fazem a diferença para testes. A primeira é que o código de teste deve ser realizado antes da implementação, configurando as possíveis entradas e saídas, após esta etapa o processo desenvolvimento é iniciado, lembrando que o processo de testes é mantido até o final do projeto. A segunda e não menos importante mudança que sem dúvidas é mais utilizada, é o processo de testes pelo usuário/cliente para o desenvolvimento, onde são eles que apontam os testes a serem realizados, e caso ocorra algum erro, o mesmo é corrigido prontamente devido a ser um erro em um local especifico do software. Essa prática traz benefícios notáveis, porém exige um treinamento especial para que o programador que realizará o teste possa realmente codifica-lo de acordo com a especificação do usuário. Integração contínua Essa prática é realizada quando existem implementações que estavam fora do escopo inicial do projeto e precisam ser implementadas ao projeto inicial. A integração deve-se ser implementada e o teste deve ser realizado tanto nas funcionalidades novas quanto nas funcionalidades que já haviam sido testadas anteriormente, para que assim não prejudique também o que já foi desenvolvido. A recomendação é que haja apenas um micro computador com o projeto inicial, conforme as novas funcionalidades são desenvolvidas, as mesmas são implementadas apenas em um computador, para que não aconteça a modificação de código em caso de integrações simultâneas. Código coletivo No XP, qualquer programador pode modificar qualquer trecho do código fonte, seja ele o autor ou não, o propósito 212

para essa autonomia é que o código da aplicação seja cada vez mais otimizado e para que o desenvolvedor tenha o conhecimento global da aplicação. Os possíveis erros ocorridos devido à modificação podem ser revistos com os testes, devido à aplicação ser 100% testada. Refatoração A refatoração é a alteração do código no sentido de que fique mais otimizado, de fácil leitura e de forma mais organizada, podendo ser utilizados em outras partes do projeto. B. Crystal Essa metodologia prega que os procedimentos devem ser adaptar a equipe e não o inverso. Com isso CockBurn e Highsmith criaram um novo método ágil, onde não se trata de apenas uma metodologia e sim de varias metodologias formando um grupo chamado de Crystal, onde cada cristal possui um nível de cor e dureza exatamente como o nome propõe. Os métodos começam com o Clear, por ser o mais fácil, com a quantidade de exigências menores e o grau de risco ser baixo. Em seguida temos o Yellow, Orange, Red, etc.. Sempre acrescentando mais rigidez devido a sua cor, isso quer dizer que conforme a cor é aumentada o nível de desenvolvimento e risco é mais complexo do que o anterior como podemos ver na Figura 1. Nessa figura podemos verificar o grau de complexidade, o risco e o número necessário de pessoas para realizarem o método escolhido. Crystal é um método muito interessante e hoje possui poucos adeptos, apesar de ser um método inovador e diferente de ser implementado. O livro publicado contempla apenas o Clear, os outros Yellow, Orange Web e Red já foram devidamente divididos porem não existe publicação sobre eles. Figura 1: Método Crystal por criticidade e números de pessoas Fonte: Cockburn (2003) encontrado com defeito a produção é parada. A ideia geral de Lean é a otimização dos processos com redução de custos e aumento de qualidade. O método Lean possuiu sete princípios, sendo que a eliminação do desperdício é o principal deles. C. Lean Software Development No começo da década de 50, quando a empresa Toyota ainda era considerada pequena, a empresa teve a chance de entrar no mercado de automóveis desde que criasse veículos baratos e com qualidade. Com esta ideia em mãos, dois gestores da empresa começaram o processo de diminuição de gastos na linha de montagem de veículos da Toyota. A principal orientação as todos da empresa era eliminar qualquer tipo de desperdício, desde a matéria prima, até a entrega final do produto. Eles conseguiram implementar duas técnicas extraordinárias que são: Just-in-time que acabou com o estoque e Stop-the-line que toda vez que um produto é Elimine o desperdício Eliminar o desperdício vale para todos os pontos de vista, sendo eles (dinheiro, mão de obra, tempo de desenvolvimento e espaço utilizado). É citado várias formas de desperdício como o desenvolvimento de funcionalidades incompletas que geram 213

um custo para serem iniciadas, por estar incompleta alguém não finalizou e nem a finalizará tornando a funcionalidade sem qualquer valor agregado ao produto. Há também o desperdício na quantidade excessiva de processos no projeto, o que ocasiona um custo maior em termos de tempo e dinheiro. A antecipação de fases do projeto também é um desperdício visto que aumenta a dificuldade, aumenta a quantidade de códigos gerados e consequentemente um esforço e tempo maior dedicado para testes. Não poderíamos deixar de falar dos defeitos, pois ele é um dos maiores vilões no que se refere ao desperdício, pois todo trabalho tem de ser analisado, corrigido e testado novamente. Amplifique o trabalho Com todo o conhecimento e experiência adquirida com o desenvolvimento, compartilhe com a equipe o aprendizado de forma ao amadurecimento da equipe como um todo. Deixando em aberto que todo o processo pode ser alterado e melhorado de forma a sempre amplificar o conhecimento da equipe. Adie comprometimentos Lean diz que se deve sempre manter a flexibilidade para alterações no projeto. Pois como existem projetos novos a complexidade das tecnologias e dificuldades podem não ser totalmente previstas. Com o decorrer do projeto a equipe adquiriu mais conhecimento e confiança, podendo eliminar algumas funcionalidades desnecessárias ou alterar a tecnologia utilizada, para melhor desempenho e ganho com o tempo do projeto. Entrega rápida Este principio propõe que o software seja desenvolvido o mais rápido possível, encurtando seu ciclo de desenvolvimento. Com as funcionalidades entregues, fica mais fácil saber o que o cliente realmente precisa e quer mudar, para que o conjunto final e a troca de informações entre o cliente e a equipe de desenvolvimento fiquem atraentes e satisfatórios para todos.... entregue o que foi pedido tão rápido que os clientes não tenham tempo de mudar de idéia. (Mary Poppendieck) Valorize a equipe Quanto mais valorizada a equipe, mais empenho e dedicação dela você terá, ou seja, um produto final sempre com qualidade. Não trate sua equipe como simples funcionários, quanto mais ela se sentir bem com o reconhecimento do trabalho, mais benefícios seu produto terá. Segurança do Software Os integrantes da equipe devem desenvolver métodos que os deixem mais seguros de que estão construindo um produto de qualidade. Sempre utilizando uma arquitetura completa, com o máximo de testes realizados e conservando sempre a posição de que a qualquer momento alguma funcionalidade pode seguir outro caminho, e deixando em aberto a alteração da mesma. Otimize o todo A criação de grandes sistemas envolvem soluções integradas que devem prover bons resultados perante uma análise global do software. Os pontos de vistas dos clientes e dos usuários equivalem a visões de alto nível do sistema. Otimização ma-cro canalizam os esforços para aumentar a satisfação dos usuários finais através de um produto consistente. Otimiza-ções pontuais nem sempre são sinérgicas quando precisam funcionar simultaneamente. Para resolver problemas busque e elimine suas causas, não os seus sintomas. (LUIZ BASSI FILHO, Dairton, Experiências com desenvolvimento ágil, 2008.). A recomendação é que sempre escolham métricas de alto nível que sejam visíveis a evolução. Tais métricas devem considerar a qualidade e satisfação do cliente. D. Feature Driven Development - FDD Esta metodologia teve inicio em Cingapura, entre os anos de 1997 á 1999, tendo como base o método Coad (metodologia de análise, desenho e programação orientada a objetos criada por Peter Coad.).Juntamente com o australiano gerente de projetos Jeff de Luca. Seu principal foco era voltado para resultados frequentes, funcionais e tangíveis. O propósito do FDD é divido em cinco fases que incorporam toda modelagem e implementação do software são elas: Criação de um modelo abrangente Este item consiste em desenvolver um modelo de alto nível para guiar a equipe em todo desenvolvimento do projeto. Para isso são praticados vários métodos como a elaboração de requisitos, análise orientada a objetos, criação de vários modelos de dados e orientações sobre a regra de negocio do software que será desenvolvido. Construir a lista de funcionalidades Com os requisitos já criados, modelos já elaborados e analise já realizada na fase anterior, há uma reunião com o consultor de negócios para o levantamento da lista completa de funcionalidades a serem desenvolvidas, abrangendo todo o escopo do projeto. Ao final o cliente realiza a validação do projeto, este item tem uma grande semelhança com o product backlog do Scrum. Planejamento por funcionalidade O projeto precisa de um pacote inicial de funcionalidades para que possam iniciar o projeto, para isso, o chefe da equipe de desenvolvimento e a equipe definem uma lista de planos de funcionalidades iniciais a serem desenvolvidas neste pacote, sempre visando à necessidade e prioridade do cliente. Modelagem por funcionalidade 214

Com os planos criados, inicia-se o detalhando de itens a serem desenvolvidos por plano, formando um conjunto de tarefas para desenvolvimento, o tempo médio que cada conjunto dura pode variar de um dia a duas semanas. Implementação po r funcionalidade Os itens das funcionalidades são desenvolvidos testados e o código é avaliado, somente após o chefe da equipe autorizar, a funcionalidade é agrupada no projeto principal. E. Scrum O nome Scrum vem de uma formação utilizada por equipes de Rugby, onde oito jogares de cada equipe se reúnem para que o jogo recomece de maneira rápida após um falta ou outra infração. Essa metodologia é um framework dentro do qual, pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. Scrum é: Leve Simples de entender Extremamente difícil de dominar (Scrum guide, Ken Schwaber e Jeff Sutherland). Scrum é um framework estrutural que está sendo usada para gerenciar o desenvolvimento de produtos complexos desde o início de 1990. Scrum não é um processo ou uma técnica para construir produtos; em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa clara a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las. (Scrum guide, Ken Schwaber e Jeff Sutherland). Existem quatro maneiras formais para a adaptação e inspeção do que está sendo desenvolvido, são elas: Reunião para o planejamento do Sprint, Reunião diária (Daily Scrum), Reunião para revisões do Sprint e para a retrospectiva do Sprint. Time Scrum Os integrantes do time Scrum são compostos por: Product Owner, a Equipe de Desenvolvimento e o Scrum Master. O time é auto-organizável e gerenciável, Com essas funções, não dependem de gestores que não fazem parte da equipe para tomar decisões sobre o projeto. Product Owner O Product Owner (Dono do Produto) é o responsável por gerenciar o Backlog do projeto. Ele pode delegar esta função para outro membro da equipe, porém sempre será o responsável por qualquer alteração. Para que haja sucesso no desenvolvimento é essencial que todos respeitem a decisão do Product Owner. Scrum Master Este é um dos membros mais importantes do Scrum é ele quem coordena a equipe de desenvolvimento para que o projeto siga a linha imposta pelo Product Owner e tenha sucesso no final do desenvolvimento. Na maioria das vezes onde o Product Owner delega o Backlog, é o Scrum Master que assume essa tarefa. Eventos Scrum Os eventos são pré-definidos para que não haja reuniões desorganizadas e sem prazos. A maneira utilizada é a Timeboxed, onde toda reunião tem um prazo máximo a ser definido. Sprint Sem dúvida o diferencial do Scrum, o Sprint dura em torno de um mês, onde a versão funcional do produto é entregue. Após o termino do primeiro Sprint, o segundo Sprint já é iniciado automaticamente, com novas estórias a serem desenvolvidas para a entrega do Sprint no final do novo período. Durante o período do Sprint não são feitas mudanças que afetem o objetivo final do Sprint. O Sprint também não pode ser definido em um longo prazo para que não dê a possibilidade de mudança de foco, não aumente a complexidade e não aumente o risco no que será entregue no final do Sprint. Ele também pode ser cancelado ou antecipado, mas somente o Product Owner tem autoridade para realizar tal cancelamento. Reunião diária A reunião diária dura 15 minutos para que a equipe possa trocar ideias de modo a organizar o que será feito ao longo do dia e rever o que foi feito no dia anterior. Revisão do Sprint Ao termino do Sprint, é realizada uma reunião onde é decidido se o que foi proposto no inicio foi realmente cumprido, verificar quais pontos foram essenciais para conclusão do Sprint e também analisar os pontos negativos que ocorreram. A reunião dura em média quatro horas e o responsável pela avaliação do Sprint é o Product Owner. Backlog do produto O Backlog é tudo aquilo que foi especificado para ser realizado ao longo de todos os Sprints, é a lista de tudo que deve ser feito independente de Sprint, o responsável pela criação deste Backlog é o Product Owner. Normalmente ele é ordenado por valor e risco como sendo um diferencial para a implementação no Sprint, ou seja, quanto maior o valor, ele será implementado o quanto antes e entregue nos primeiros Sprints. Destacando também que sempre que houver um risco maior o mesmo deve ser o mais detalhado possível. Praticas de monitoramento Há varias praticas de monitoramento do Sprint, como o Burndown que utilizamos em nossa aplicação e outros 215

métodos gráficos e praticas de estimativas que conseguem monitorar com sucesso o andamento das tarefas ao longo do Sprint. Backlog do Sprint Este Backlog é composto por uma seleção de itens do Backlog do produto. São esses itens que serão realizados pela equipe de desenvolvimento ao longo do Sprint. E também é de responsabilidade dela qualquer adição de um novo item no Sprint. Sempre que um item é concluído, o mesmo é atualizado no Backlog pela equipe. F. Computação Móvel A computação móvel é a forma de ter acesso à informação de qualquer lugar a qualquer hora. Ela se resume em três pontos para que isso possa acontecer que são: a mobilidade, o processamento dos dados e a comunicação a distancia sem qualquer meio físico interligando-a. Para a computação móvel, o tamanho é extremamente importante, visto que teremos de carrega-lo sempre onde estamos, neste quesito, a tecnologia tem ajudado muito, no sentido de que os componentes que formam os dispositivos sejam cada vez menores e sempre aumentando a capacidade de armazenamento. Podemos citar alguns exemplos de dispositivos móveis como: celulares, smartfones, navegadores GPS, sensores, etc... Todos sempre seguindo as características citadas acima. Devido aos motivos de: tamanho, peso e energia, os dispositivos apresentam limitações se comparados com equipamentos que não são móveis, isso se deve a maior capacidade de processamento, taxa de transferência e energia abundante, visto que eles não possuem a limitação dos componentes e podem ser interligados via cabos. G. KanBan com Scrum Kanban é uma palavra japonesa que significa literalmente registro ou placa visível. O mesmo termo voltado para a administração de processos significa um cartão de sinalização voltado para o transporte e produção em uma empresa. Os cartões são distribuídos em peças do setor, indicando a entrega de uma determinada quantidade. Quando todas as peças são terminadas, os cartões são levados de volta ao ponto de partida. 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.(Wikipédia) O sistema Kanban é uma das variantes mais conhecidas do JIT. (Lopes dos Reis, 2008, p.191) Apesar de não ser muito divulgado, o kanban é utilizado tanto para o Scrum como para outras metodologias ágeis como Extreme Programming, Crystal, etc... O conceito do Kanban é mostrar visualmente para o desenvolvedor aquilo que ele têm para fazer (To Do), o que esta em progresso ou em processo de desenvolvimento (In Progress) e por ultimo o que esta feito ou já realizado (Done). Tudo isso de forma interativa, onde a tarefa (Task) é mudada constantemente de coluna, até chegar na coluna (Done). Como tudo é visual, toda a equipe de desenvolvedores e o Scrum Master, tem acesso facilitado a acompanhar o andamento da equipe, podendo monitorar o que poderá estar em atraso, como podemos visualizar na Figura 2. Figura 2: Fases do Kanban IV. S CRUM EM APLICAÇOES MÓVEIS Para implantação dessa metodologia, temos de se orientar através das fases do Scrum que descreveremos a seguir, onde a Figura 3 mostra o ciclo completo de um Sprint, onde cada fase nos mostra detalhadamente o porque o Sprint é tão necessário no desenvolvimento com a metodologia ágil Scrum. A. Product Backlog Para criação de um produto a ser desenvolvido no Sprint, deve-se definir quem será o Scrum Master e realizar a reunião com o P.O, para que seja definido o que será realizado e o que é prioritário neste Sprint, esclarecendo também possíveis dúvidas relacionadas aos itens especificados. B. Sprint Backlog Com os itens especificados, devemos então se reunir com a equipe de desenvolvimento, que é composta pelo Scrum Master e todos desenvolvedores envolvidos. Na reunião, definimos as estórias as serem implementadas, logo após jogamos o Planning Poker para definirmos o grau de dificuldade de cada estória. Para concluir o Sprint Backlog definirmos as tasks de cada estória e realizamos a divisão entre os desenvolvedores. 216

C. Daily Scrum Meeting (reunião diária) A reunião diária é de vital importância para que o Sprint seja um sucesso. Ela dura em torno de 15 minutos, dentro deste período é discutido o andamento das tasks e possíveis dúvidas que os desenvolvedores venham ter. Ela também é importante para a sincronização entre os membros da equipe. D. Potentially Shippable Product Increment (Incremento do Produto) Com o final do ciclo do Sprint que dura em torno de duas a seis semanas, obtém-se finalmente o incremento do produto com as funcionalidades especificadas desenvolvidas e testadas, ou seja, pronta para ser incrementada. Após o fim do primeiro Sprint, dá-se inicio a um novo Sprint e todo ciclo (Figura 3) é realizado novamente até termos o produto completo desenvolvido Figura 3: Fases de um Sprint Fonte: Mountain Goat Software V. ESTUDO DE CASO Com base na revisão bibliográfica sobre métodos ágeis e computação móvel este projeto explora o uso do método Scrum no desenvolvimento de aplicações móveis. A implementação da metodologia Scrum em aplicações móveis proposta neste artigo foi realizada na Universidade Federal de São Carlos, participando deste projeto cinco alunos do curso de pós-graduação em Desenvolvimento Web. A ideia do projeto foi de desenvolver uma aplicação móvel na linguagem Android, para a integração com a aplicação Web feita em Java. O projeto, como um todo, é o de uma Rede social para a aproximação de estudantes, professores, funcionários e visitantes de diversos cursos e departamentos da UFSCAR. O projeto foi orientado conforme ciclo do Sprint da Figura 3 e teve inicio em uma reunião com o P.O (Product Owner), para o entendimento do que seria necessário para realização das funcionalidades da aplicação e a integração com a aplicação Web, podendo assim esclarecer as possíveis dúvidas e a criação das estórias com um grau de importância maior. Após a reunião, com o Backlog do produto já em mãos, a equipe se reuniu definindo quem seria o Scrum Master, e assim começamos a analisar o grau de dificuldade para cada estória jogando o Planning Poker. Com as estórias devidamente definidas, iniciamos o processo de criação e divisão das tarefas (Tasks) para o desenvolvimento da aplicação no prazo desejável para a entrega do primeiro Sprint. Iniciamos o processo de desenvolvimento das tarefas com alguns débitos técnicos em virtude da tecnologia nova, que foi prontamente corrigida pela equipe e conseguimos completar o Sprint no prazo desejável sem grandes dificuldades como podemos visualizar nas Figuras 4 e 5. 217

Figura 4: Exemplo de Sprint Backlog Figura 5: Exemplo de Burndown Gráfico do Sprint diária onde poderia ser debatido tudo que havíamos VI. CONCLUSÃO O desenvolvimento da aplicação em dispositivos móveis desenvolvido no dia anterior e o que desenvolveríamos no dia. Outro fator que podemos recomendar nesta metodologia, com a metodologia Scrum foi um sucesso. Apesar dos débitos são os Sprints. Sem duvida a melhor forma para o técnicos que citamos nos textos anteriores. É impossível planejamento do desenvolvimento de funcionalidades em prever tais situações de dificuldade por vários fatores, desde o curto prazo, e com uma entrega rápida para o cliente. O fator humano de quem esta desenvolvendo até as novas beneficio do Sprint, é a satisfação do P.O com a entrega de tecnologias implementadas no projeto. Logicamente que por parte do produto já em funcionamento, e a opção da ser o primeiro projeto com essa metodologia, encontramos modificação ou melhoria no produto, visto que ainda pode ser inúmeras dificuldades que não teríamos nos próximos modificado, porém com projetos a serem implementados. implementação da mudança com um menor risco, visto que A metodologia Scrum mostrou-se eficaz em varias fases do o que foi desenvolvido foram só algumas funcionalidades, desenvolvimento, desde o que foi planejado, aos imprevistos não tendo que modificar a aplicação inteira para atender a que aconteceram ao longo do projeto. Um dos fatores que necessidade nova do P.O. podemos citar como diferencias do Scrum é o da reunião A metodologia ágil permitiu-se aos desenvolvedores que 218

trocassem experiências e buscassem novas tecnologias ao longo de todo projeto. Fazendo assim uma equipe cada vez mais preparada para os desafios que o projeto apresentava. Os resultados obtidos comprovam que os níveis de qualidade e de risco são melhores comparados com outras metodologias. Para dispositivos móveis a metodologia Scrum mostrou-se eficaz e altamente recomendada, pois como podemos ver no desenvolvimento do projeto, temos muitos mais pontos benéficos que agregam um valor ao produto final muito maior e com um custo beneficio e tempo muito menor comparado a outras metodologias. Com estes resultados obtidos conseguimos presumir que a tendência para as metodologias utilizadas em equipes de desenvolvimentos para criação em aplicações móveis seja o Scrum. Essa informação de crescimento já pode ser sentida em grandes empresas que estão aderindo esta metodologia ao mercado de aplicações em Android. VII. TRABALHOS F UTUROS A pesquisa de uma metodologia ideal ainda é muito complexa e vaga, por este motivo estarei pesquisando formas tanto de otimização quanto de inclusão de novos itens em metodologias existentes a fim de unirmos o que há de bom em cada uma delas. Também desenvolverei projetos utilizando a metodologia XP- (Extreme Programming) e Crystal, para melhor conhecimento destas metodologias. Como continuidade busca-se novas formas motivacionais e psicológicas no desenvolvimento da aplicação, visto que o sucesso do projeto não depende somente da metodologia e sim das pessoas envolvidas, pois o fator humano é extremamente importante, senão o mais importante, pois a metodologia sozinha não consegue desenvolver a aplicação. Testes com outras metodologias e em outras linguagens de programação e com numero de equipes variadas, podem ser realizadas para aferir resultados distintos, a fim de maximizarmos a produtividade com a metodologia utilizada. O desenvolvimento de tasks e estórias de um Sprint também podem ser variados, para medirmos a produtividade da equipe no projeto. REFERÊNCIAS B IBLIOGRÁFICAS IMPROVEIT, 2012. Modelo de interação SCRUM. Disponível em: < http://improveit.com.br/scrum> Acesso em: Agosto de 2012 PRESSMAN, Rogers S. Engenharia de Software. São Paulo, McGraw-Hill Interame, 2002. SCHWABER, Ken; BEEDLE, Mike. Agile Software Development with SCRUM. Prentice Hall,2002. SCHWABER, Ken, SUTHERLAND, Jeff Scrum Guide Disponível em : <http://www.scrum.org/scrum-guides> Acesso em: Agosto de 2012. IMPROVEIT, 2012. Modelo de interação XP. Disponível em: < http://improveit.com.br/xp> Acesso em:julho de 2012 BECK, Kent, Planning extreme programming, 2001. BECK, Kent, Extreme programing explained : embrace change, 2008. COCKBURN, Alistair, The Crystal Methods or How to Make a Methodology Fit, Agile Development Conference, 2002 LUIZ BASSI FILHO, Dairton, Experiências com desenvolvimento ágil, 2008. OLIVEIRA, Renan de Melo, Um estudo sobre o espaço de trabalho informativo e o acompanhamento em equipes ágeis de desenvolvimento de software, 2012. TAIICHI, Ohno. Toyota Production System: Beyond LargeScale Production. Productivity Press, 1988. GUERREIRO, Cristian. Scrum com Kanban. Disponível em: <http://blog.tecnologiaqueinteressa.com/2012/07/fisl-13scrum-com-kanban-pequenos.html> Acesso em: Setembro de 2012. 219