Scrum: Uma aplicação em uma software house Diego Brunhera 1, Alexandre Lazaretti Zanatta 2 Instituto de Ciências Exatas e Geociências Universidade de Passo Fundo (UPF) Caixa Postal 611 99.052-900 Passo Fundo RS Brasil brunhera@gmail.com 1 ; zanatta@upf.br 2 Resumo. Atualmente as empresas estão buscando mais rapidez e produtividade no desenvolvimento de seus produtos. Neste trabalho inicialmente é apresentado o método ágil Scrum, a seguir é exposta e discutida uma análise do modelo de desenvolvimento criado pela organização, e é aplicado este modelo em um projeto de desenvolvimento demonstrando a sua atuação. Assim conclui-se que muitas vezes o gerenciamento dos trabalhos à partir de uma metodologia, torna a produtividade ainda maior, fazendo com que os objetivos da organização sejam alcançados de forma satisfatória. Introdução Hoje em dia num mundo cada vez mais competitivo as empresas buscam maior produtividade e rapidez em atingir seus objetivos. Velocidade e flexibilidade são essenciais para que isso ocorra. A busca destas necessidades faz com que as empresas procurem algo que lhes proporcione diferencial competitivo. Dentro deste caminho de busca, existem os métodos de desenvolvimento de software, os quais orientam esta linha de necessidades, sendo dois: Processos definidos, como cascata e espiral; e Processos empíricos, tais como Scrum e XP. O processo de desenvolvimento pode ser definido como um conjunto de atividades e resultados associados que levam à produção de um produto. (Sommerville, 2003, pg. 36). Este trabalho tem como objetivo principal auxiliar a organização em adaptar-se com o método ágil à partir da análise realizada na documentação desta empresa. Avaliando as práticas de engenharia adotada, propondo uma implantação da metodologia de desenvolvimento Scrum. O presente trabalho está organizado da seguinte forma: A seção 1 apresenta o método ágil Scrum com suas práticas e conceitos. A seção 2 um estudo dos processos da organização, identificando suas práticas e processo de desenvolvimento. A seção 3 descreve o estudo de caso da empresa seguindo as práticas do Scrum. Por fim, a seção 4 apresenta as considerações finais do presente trabalho. 1 Métodos Ágeis Esta seção apresenta resumidamente como surgiram os métodos ágeis, também define as práticas, conceitos e o ciclo de vida do Scrum que servirão para um embasamento do desenvolvimento da metodologia estudada. A origem desta metodologia surgiu devido aos problemas encontrados nos metodos conhecidos como tradicionais, que se dizia serem previsíveis e planejáveis com regras bem definidas, porém demonstrava-se na prática o contrário, ambientes de
desenvolvimento caóticos, sofrendo mudanças constantes, muitas vezes com grandes impactos no projeto. Assim, os métodos ágeis surgiram da necessidade de haver um software funcional em pequenos intervalos de tempo, promovendo mais comunicação com os envolvidos e menos documentação. Este método auto denominado ágil surgiu depois que um grupo de especialistas em processos de desenvolvimento de software definiram alguns conceitos. Este encontro foi denominado como Manifesto Ágil. Os métodos existentes denominados ágeis mais conhecidos são: Extreme Programming; Crystal; Feature Driven Development e Scrum. Todas estas metodologias adotaram os conceitos definidos neste manifesto. 1.1 Scrum Scrum é baseado em processos empíricos, ou seja, que não requerem conhecimentos detalhados e completos, ele baseia-se pela experimentação. O foco principal é planejamento e gerenciamento de projetos. Sendo uma metodologia que se organiza em equipes, destaca-se por ter uma grande interação entre seus integrantes. Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantar no desenvolvimento de software em todo o mundo. O ciclo de vida do Scrum é organizado em quatro práticas, sendo: Product Backlog, Sprint Backlog, Sprint, Product Increment. Entre estas práticas está o gerenciamento e o planejamento dos trabalhos que são fundamentais no desenvolvimento de um projeto. A seguir será apresentado as práticas e conceitos adotadas por esta metodologia de desenvolvimento. Scrum Master É o responsável em garantir o sucesso do Scrum (Schwaber e Beedle, 2002), tem conhecimento profundo nas práticas desta metodologia; assume também um papel de facilitador nas reuniões de Sprint; mantém o contato com o cliente e com a equipe; normalmente é o gerente de projeto ou líder técnico. Product Owner Representa e defende os interesses do cliente, é conhecedor do negócio, é ele que irá priorizar o Product Backlog a ser seguido pela equipe de desenvolvimento; garante que os requisitos não irão mudar dentro do Sprint, mas não impede que nos intervalos estes sofram alterações. Scrum Team É responsável direto pela execução do projeto, é uma equipe multidisciplinar auto gerenciada, ou seja, tem autonomia para tomar iniciativas que garantam a conclusão do projeto, assumem a responsábilidade pelas estimativas de tempo de desenvolvimento, manifestam ao Scrum Master os impedimentos que surgiram no decorrer do projeto. Task Bord Consiste em um quadro de tarefas, com os itens que serão trabalhados dentro de um Sprint. Este quadro contém três status que representam o estado atual do item, que são: não iniciado, fazendo e pronto. São fixados no quadro pequenos Post-it que são dispostos conforme a montagem do quadro que podem movimentar-se da esquerda para a direita até atingir o status de pronto. Sendo assim possível acompanhar cada mudança de status do projeto.
Product Backlog - Considerada uma das mais importantes práticas do Scrum, tem por objetivo, criar uma lista onde será definido os requisitos funcionais e não funcionais que o sistema desenvolvido necessitará. Contudo para que este documento seja elaborado o Scrum Master, irá fazer a coleta destas informações com todos os envolvidos do projeto. Sprint Backlog - Ligada entre o Product Backlog e o Sprint esta é a lista de funcionalidades, atividades e tarefas que serão executadas durante um Sprint. É de total responsabilidade da equipe em manter esta lista organizada, para atender os objetivos na próxima interação. Qualquer um da equipe pode escolher a tarefa que irá desempenhar. Sprint - Considerada a prática mais importante, pode durar entre duas a quatro semanas, neste período são realizadas tarefas e atividades para que sejam entregue parte ou um incremento funcional do produto para o cliente. Segundo (Abrahamsson, 2002) o Sprint inclui as fases tradicionais do desenvolvimento de software: requisitos, análise, projeto e entrega. É neste momento que prováveis inconsistências são verificadas. Assim, com o processo em andamento apenas os desenvolvedores poderão fazer mudanças nas atividades, adaptações que visam melhorar o trabalho a ser realizado. O resultado final do Sprint é conhecido como Product Increment onde serão entregue uma parte funcional do software. Daily Scrum Meeting - Este é o momento das reuniões rápidas em que a Scrum Team tem para tratar assuntos sobre o trabalho, falando sobre o que foi feito e que se pretende fazer até a próxima reunião. Estas reuniões não devem durar mais do que 15min, o Scrum Master tem a tarefa de garantir que o tempo não seja ultrapassado. Product Increment - O esforço desempenhado dentro do ciclo de um Sprint é o resultado obtido neste momento, sendo a entrega de parte do software executável e a sua documentação, estes serão analisados pelo usuário, a fim de verificar as funcionalidades desenvolvidas. Após a entrega, inicia-se novamente um novo ciclo do Scrum, redefinindo requisitos, gerando alterações no Product Backlog e também modificações no Sprint Backlog. A Figura 1 reproduz o ciclo do Scrum, nela observamse as quatro práticas descritas. Fonte: www.mountangoatsoftware.com/scrum Figura 1. Ciclo de vida do Scrum
2 Os Processos da Software House Nesta seção serão apresentadas todas as fases do modelo de desenvolvimento da organização, todos os processos têm artefatos de entrada e saída, entre estes têm atividades que são necessárias para gerar as saídas, com a finalidade de homologar a primeira etapa e seguir para a próxima. Na figura 2 estão representados todos os processos da organização. Fonte: Modelo de Desenvolvimento da organização. Figura 2. Modelo próprio de desenvolvido criado pela organização O presente trabalho foi realizado em uma software house, localizada na cidade de Passo Fundo, atende a segmentos ligados a prestação de serviços, instituições de ensino e pesquisa e cooperativas de trabalho. Buscando sempre atender seus clientes de forma rápida e eficiente, com serviços qualificada, oferecendo-lhes os melhores produtos e soluções. Os serviços que a empresa oferece são: software sob encomenda e soluções em servidores, baseados em sistemas operacionais linux. 2.1 Conhecer Conhecer o cliente e saber oque ele precisa é o primeiro passo do processom, para isso ele entra em contato por um canal de comunicação com a empresa, por telefone, e-mail ou carta, solicita um orçamento para desenvolver um sistema que atenda as suas necessidades. O representante da empresa faz a visita em um momento combinado, a fim de fazer a captação destas necessidades, para assim, serem gerados os documentos que iniciarão o processo de um novo projeto. 2.1.1 Artefatos de Entrada Uma ação é necessária para iniciar o artefato, uma ligação, e-mail ou carta sendo um destas a entrada inicla do projeto que ficará armazenada na pasta do cliente, será criado um documento que terá informações quanto a este possível cliente como: Nome
(contato), endereço, bairro, cidade, e-mail, telefone, data agendada da visita e observações pertinentes relacionadas ao contato. 2.1.2 Atividades oriundas do artefato de entrada Cria-se uma pasta com as informações iniciais do contato com a finalidade de documentar todas as atividades relacionadas ao cliente. Assim, marca-se uma visita levando um rascunho da REQ01, com o propósito de anotar todas as informações que sejam relevantes ao projeto. Deixando previamente agendada com o contato a entrega da proposta. Com a REQ01 devidamente preenchida, é anexa à pasta juntamente com os outros documentos. Após a REQ01 é desenvolvida a modelagem do negócio, REQ02, que tratará de uma compreensão do problema do cliente, abordando tudo que tem de maior importância e interesse, ou seja, maior valor de negócio a fim de apontar soluções técnicas, cronológicas e financeiramente viáveis. 2.1.3 Artefatos de saída A conclusão das atividades resultou na produção de documentos de saída que irãoa dar continuidade ao processo. Os artefatos de saída são: REQ01 Ficha do cliente REQ02 Modelagem do negócio 2.2 Propor Ao propor o desenvolvimento ao cliente, será de grande importância uma análise detalhada dos requisitos para sua execução. As informações que esta etapa gera, terá grande impacto, seja futuramente ou imediatamente. Uma proposta mal elaborada pode gerar problemas de custo, planejamento, questões jurídicas e legais ao produto final. Portanto para propor um projeto é necessário avaliar todos os detalhes, como horas de trabalho, hardware, infra-estrutura, pessoal qualificado para desenvolvimento e pessoal disponível no cliente. 2.2.1 Artefatos de Entrada O resultado do processo anterior é necessário para a continuação deste processo, os artefatos de saída devem estar devidamente concluídos para dar início aos trabalhos. Os artefatos de entrada são: REQ01 Ficha do Cliente REQ02 Modelagem do negócio 2.2.2 Atividades oriundas do artefato de entrada Com os artefatos de entrada homologados, será confeccionado o Orçamento do Projeto (REQ03) a fim de identificar por meio de cálculos, o custo do projeto para a empresa, assim como margem de lucro, custos fixos, variáveis e tributos dando condições mais precisas de avaliar o valor do produto que será formalizado ao cliente.
Finalizada a REQ03, será desenvolvida a Proposta (REQ04), que tem por objetivo fazer a entrega das condições formalmente ao cliente. Assim que a proposta foi aceita pelo cliente, será elaborado o contrato. Por fim, com a elaboração do contrato de desenvolvimento e licença de uso do software (PRJ01) e de atualização do software (PRJ02) que tem implicações jurídicas quanto à execução, serviço e licença de uso, uma cópia deverá ser entregue ao responsável ou representante legal do cliente. 2.2.3 Artefatos de saída Com estas atividades concluídas será produzido os documentos que darão início as próximas etapas do projeto. Os artefatos de saída são: REQ03 Orçamento do Projeto REQ04 Proposta PRJ01 Contrato de desenvolvimento e licença de uso do software PRJ02 Contrato de Atualização do software 2.3 Projetar Planejar um projeto requer habilidades, estas geralmente atribuídas ao Scrum Master que tem como objetivo envolver, orientar e facilitar o que for necessário para a equipe (Scrum Team), então, é feita uma revisão do projeto, com todos os envolvidos (Stakeholders), assim será promovida uma análise aprofundada dos requisitos, iniciando neste momento a lista de necessidades do cliente (Product Backlog). O Product Backlog é um documento que descreve as necessidades do cliente, assim como é identificado para cada requisito, a sua importância, e a estimativa de tempo que a Scrum Team levará para desenvolver, é especificado neste documento também uma descrição de como demonstrar este requisito para deixá-lo mais claro o entendimento dos envolvidos. Este processo desencadeará uma série de eventos, os quais devem ser devidamente elaborados e documentados para que o trabalho tenha um andamento contínuo e sem interrupções que causem danos ao projeto. Os eventos são: Plano de Risco Modelo Entidade Relacionamento (MER) Cronograma de desenvolvimento Um comando irá disparar a criação do banco e a criação do projeto em uma linha de base. Configurações de servidor e banco na estrutura física do cliente. 2.3.1 Artefatos de Entrada O projeto só será iniciado após os artefatos da etapa anterior terem sido desenvolvidos e aprovados. Os artefatos de entrada são: PRJ01 Contrato de desenvolvimento e licença de uso do software assinado.
PRJ02 Contrato de Atualização do software assinado. 2.3.2 Atividades oriundas do artefato de entrada Com os contratos assinados, serão convocados para uma reunião todos os stakeholders para realizar uma apresentação do projeto, para assim ter uma análise aprofundada dos requisitos, dividindo estes em partes menores, com a finalidade de detalha-los para um melhor entendimento da equipe quanto as necessidades do cliente. É criado um plano de risco, um modelo de entidade relacional (MER), um diagrama de classe e um cronograma das atividades que serão contempladas neste projeto, estes estão disponíveis em diretórios da rede, documentos previamente padronizados e formatados que auxiliarão na criação destes arquivos. É preciso que o cliente já tenha uma conexão de internet disponível e um computador para instalação dos softwares, estes são necessários para implantação do sistema. O comprometimento do cliente e de toda a equipe é fundamental, para isso, será realizada uma reunião com os stakeholders validando todos os requisitos e o plano do projeto a fim de obter uma aprovação do cliente e do Product Owner. 2.3.3 Artefatos de saída Com as atividades desta etapa concluídas serão produzidos os documentos que darão início as próximas etapas do desenvolvimento. Os artefatos de saída são: Product Backlog Plano de Risco PRJ08 MER PRJ09 UML 1 Cronograma das atividades e dificuldades 2.4 Planejar aplicação Planejar é importante para um amplo entendimento de toda a equipe. No planejamento é detalhado toda e qualquer atividade que será desempenhada. Todos os stakeholders estão presentes a fim de envolverem todos no planejamento das atividades que iniciarão. 2.4.1 Artefatos de Entrada Com o inicio do projeto é necessário que todos os documentos exigidos para o desenvolvimento já estejam definidos. Os artefatos de entrada são: Product Backlog aceitos pelos Stakeholders Cronograma das atividades e dificuldades 2.4.2 Atividades oriundas do artefato de entrada A partir do Product Backlog serão discutidos quais requisitos irão fazer parte da interação (Sprint) que iniciará, também quanto tempo cada interação irá durar, 1 UML. É uma linguagem de modelagem não proprietária, cuja sigla significa Unified Modeling Language, auxilia na visualizaçao dos desenhos e a comunicação entre os objetos. (OMG 2009)
normalmente entre duas a quatro semanas. Será produzido um Sprint Backlog que terá a mesma característica estrutural do Product Backlog tendo apenas os requisitos que farão parte da interação. Neste Sprint, com duração estabelecida, será definido os dias de reuniões, diárias ou intermitentes, com horários pré estabelecidos. 2.4.3 Artefatos de saída Esta reunião de planejamento envolve principalmente as características que serão realizadas no decorrer do Sprint, definindo também os requisitos do Product Backlog que irão fazer parte desta interação. O artefato de saída é: Sprint Backlog inicial 2.5 Planejar módulo Este é o momento final que antecede o Sprint. Com os requisitos analisados e as aplicações planejadas, serão verificados os módulos que farão parte do desenvolvimento e suas complexidades, apontando padrões para o desenvolvimento que irão ser adotados. 2.5.1 Artefatos de entrada Na fase de planejamento dos módulos é importante que a Scrum Team esteja comprometida com o projeto, isso faz com que o documento resultante seja o mais próximo do esperado. O artefato de entrada é: Sprint Backlog inicial 2.5.2 Atividades oriundas do artefato de entrada Neste momento será criado o planejamento dos módulos, dependênciais e o layout. A equipe avaliará o que será realizado, levando em conta sua capacidade e desempenho, estimando cada um dos módulos, com o propósito de fazer um levantamento do custo em tempo que cada um irá ter com o trabalho comprometido. Serão discutidas as funcionalidades, a equipe irá transformar o Product Backlog em incremento, definindo no Sprint Backlog. 2.5.3 Artefatos de saída O planejamento deve estar estruturado até a presente etapa, isso faz com que o andamento do projeto seja o mais adequado possível, a fim de atender todas as expectativas do cliente e trazer excelentes resultados. O artefato de saída é: Sprint Backlog finalizado 2.6 Criar e verificar módulo Iniciado o ciclo do Sprint a Scrum Team irá assumir atividades que no final desta interação resultarão em um Product Increment, ou seja, um software funcional com os módulos planejados anteriormente. Através das reuniões diárias, Daily Scrum Meeting o Scrum Master estará sempre informado quanto o andamento do projeto, através de um quadro de tarefas denominado Task Board.
2.6.1 Artefatos de entrada Iniciada as atividades de desenvolvimento a Scrum Team irá manter sempre atualizado o quadro de tarefas, isso faz com que todos os envolvidos neste projeto vejam de forma ampla e atualizada em que ponto do projeto está o desenvolvimento. O artefato de entrada é: Sprint Backlog Finalizado 2.6.2 Atividades oriundas do artefato de entrada Cada integrante do Scrum Team irá assumir uma atividade nesta fase de desenvolvimento que terá duração de duas a quatro semanas, dependendo do que foi combinado com a equipe. Será atualizado o Product Backlog para manter sincronizado com o Task Board. Todos os dias será realizado as Daily Scrum Meeting com o objetivo de discutir sobre o andamento do projeto. Nestas reuniões terão duração máxima de 15 minutos. Serão abordados os problemas que foram encontrados, suas atividades desde a última reunião e quais serão as novas atividades até a próxima reunião. Cabe aqui ao Scrum Master remover os impedimentos que poderão aparecer, para que o trabalho siga seu fluxo normal. 2.6.3 Artefatos de saída A criação e verificação dos módulos consistem em uma das mais importantes etapas do desenvolvimento ágil, os artefatos aqui produzidos são de grande importância para determinar e informar como está o andamento do projeto. Os artefatos de saída são: Atualização do quadro Task Borad. Atualização do Product Backlog 2.7 Validar e entregar aplicação Ao avaliar oque foi feito nesta interação, é realizado uma apresentação dos resultados com o Sprint à partir dos objetivos definidos, assim como os itens do Product Backlog que o Scrum Team se comprometeu e os que foram feitos. Por fim será feita uma demonstração funcional do que foi produzido sendo solicitado um feedback completo da aplicação, para ter uma aprovação ou não do trabalho desenvolvido. 2.7.1 Artefatos de Entrada Esta etapa gera apenas atualização do Product Backlog para estar disponível, a toda equipe que fará o acompanhamento dos resultados. O artefato de entrada é: Documento Product Backlog atualizado 2.7.2 Atividades oriundas do artefato de entrada Com uma revisão do que foi feito dentro do Sprint com a finalidade de demostrar tudo que foi produzido é feito uma avaliação quanto ao objetivo do Sprint, a fim de ter uma aceitação formalizada de todos os envolvidos. Os envolvidos neste projeto que participam desta reunião são: Scrum Team, Scrum Master, Product Owner e Stakeholders.
2.7.3 Artefatos de saída Para continuação dos trabalhos é importante que seja aceito o produto desenvolvido. O artefato de saída é: Documento Sprint Backlog aprovado e aceito pelos envolvidos. 2.8 Incrementar aplicação A aceitação formal do cliente é importante para a melhoria continua, por isso é discutido o que ficou bom e o que poderá ser melhor em uma próxima interação. Participam desta reunião o Scrum Master e o Scrum Team, o Product Owner poderá participar caso seja convidado. 2.8.1 Artefatos de Entrada A etapa anterior tem que ser aceita para assim realizar uma análise do desempenho e documentar o que pode ser melhorado e o que ficou bom nesta interação. O artefato de entrada é: Documento Sprint Backlog aprovado e aceito pelos envolvidos. 2.8.2 Atividades oriundas do artefato de entrada Uma reunião é iniciada com o objetivo de identificar o que foi bom e o que pode melhorar a fim de refazer as estimativas e priorizar os requisitos para as próximas interações. Consequentemente tem-se uma melhoria contínua do produto final. 2.8.3 Artefatos de saída A aceitação formal do cliente é responsável por atividaedes que serão discutidas e analizadas, assim formalizando um documento de saida. O artefato de saída é: Atualização do Product Backlog. 2.9 Encerramento projeto Na finalização do Product Backlog onde todos os requisitos tenham sido atendidos, funcionais e não funcionais, serão realizadas às configurações finais como timbres, layout e acessos. O objetivo é finalizar o projeto e fazer a entrega final do produto ao cliente. 2.9.1 Artefatos de Entrada A finalização da etapa incrementar aplicação resulta em refazer as estimativas e priorizar os requizitos, assim nesta etapa de encerramento do projeto é obrigatorio que o artefato esteja finalizado. O artefato de entrada é: Product Backlog finalizado. 2.9.2 Atividades oriundas do artefato de entrada Com todos os requisitos do Product Backlog finalizados, incrementos verificados e aceitos, será entregue ao cliente o software. Antes da entrega final será desenvolvido um manual de utilização com a finalidade de auxiliar o usuário. Por fim é registrado no
contrato de entrega de software (PRJ05), observações sobre a apresentação formal do produto. Este contrato será assinado e será registrada a entrega formal. 2.9.3 Artefatos de saída O modelo de desenvolviemento da organização é finalizado neste momento, as atividades de encerramento do projeto geram artefatos que farão a finalização deste trabalho. O artefato de saída são: PRJ05 Contrato de Entrega de Software Manual do Produto 3 Estudo de Caso A organização enfrenta algumas dificuldades em gerenciar seus projetos. Foram várias tentativas de reverter este quadro, no entanto as soluções encontradas não atendiam a todas as necessidades e a realidade da empresa. Em busca de uma solução, a empresa resolveu desenvolver sua própria ferramenta para o gerenciamento e um modelo de desenvolvimento para seus projetos. O modelo desenvolvido atende suas necessidades, porém não orienta adequadamente o gestor do projeto. Seu modelo de desenvolvimento é próprio; dividido em nove macros etapas, estão definidas como: conhecer, propor, projetar, planejar aplicação, planejar módulo, criar e verificar módulo, validar e entregar aplicação, incrementar aplicação e finalizar. Com o estudo realizado na documentação da organização foi iniciado o processo para colocar em prática todas as etapas deste documento, a fim de demonstrar sua aplicabilidade. Este trabalho estava sob a coordenação do gerente da organização, este documento tem como objetivo verificar e adaptar o modelo de desenvolvimento da empresa com as práticas de gerenciamento do Scrum, conceitos e práticas, papéis e a utilização do quadro Task Board para gerenciar o andamento do projeto, demonstrando sua aplicação e comprovando o resultado desejado. Para colocar em prática o estudo realizado, era necessário executar em um projeto, como a empresa estava em fase inicial de negociação com um cliente, foi discutido a possibilidade de iniciar a aplicação desta teoria na pratica. O objetivo principal deste projeto em negociação era o desenvolvimento de um CMS que possa manter e gerenciar um Web Site. No projeto continha itens que visava criar um diferencial, como manter uma lista das empresas produtoras de pedras preciosas da cidade de Soledade, também criaria-se para cada empresa uma lista dos seus produtos em formato 3D e um sistema georreferencial, utilizando os recursos computacionais do software Google Earth 2. A seguir será apresentado cada um dos tópicos definidos no processo da empresa, demonstrando como foi o andamento das atividades desenvolvidas e como se comportou esta metodologia de trabalho. 2 GOOGLE EARTH. É um programa de computador desenvolvido e distribuido pela empresa americana google, com a função de mostrar modelo tridimencional do globo terrestre construído a partir de fotografias de satélites (GOOGLE EARTH, 2010).
3.1 Conhecer Nesta primeira etapa do projeto, as negociações de desenvolvimento do Portal Gemas já estavam em andamento, o gerente da organização relatou que os primeiros contatos foram estabelecidos ainda antes do ano de 2009, o cliente já tinha a idéia de desenvolver o portal, assim entrando em contato com o gerente da empresa para discutir a respeito do assunto. Com a realização do primeiro contato a organização criou o artefato REQ01 Ficha do cliente, já definiu o que o produto agregaria, elaborou uma modelagem do negócio REQ02, um dos artefatos de saída deste processo para dar continuidade aos trabalhos. Seguindo as etapas do modelo de desenvolvimento estes documentos foram criados e arquivados na pasta do cliente a fim de continuar o processo, ficando disponíveis ao alcance da equipe para auxiliar o desenvolvimento do projeto. 3.2 Propor Com a conclusão da etapa anterior, foram criados os artefatos que compõem este processo, contudo, o artefato PRJ02 - Contrato de Atualização do Software não foi criado por tratar-se de um projeto com prazo de duração, com início e fim, assim este artefato não fez parte do fechamento contratual deste projeto. Na empresa, existem duas pastas do projeto, uma com as informações necessárias para o desenvolvimento do projeto que fica disponível para a equipe de desenvolvimento e a outra que é de uso gerencial, os artefatos de saída desta etapa estão arquivados na pasta gerencial, são estes: REQ03 - Orçamento do Projeto, REQ04 - Proposta e PRJ01 - Contrato de desenvolvimento e licença de uso do software. 3.3 Projetar Antes de iniciar os trabalhos de desenvolvimento no projeto foi realizada a primeira reunião com todos os envolvidos. Estavam presentes, o gerente da organização, a equipe de desenvolvimento e o autor. Na reunião realizou-se uma abordagem geral sobre o Scrum, as práticas adotadas por esta metodologia e os papéis que o regem, esta reunião teve o objetivo de informar os integrantes sobre o início do projeto e de se ambientarem com esta metodologia de desenvolvimento. Apresentada aos participantes a lista de itens que já estava proposta para o cliente, a construção de um CMS 3 para gerenciar o Portal Gemas, dentro do portal iria haver a funcionalidade de um mini site das empresas associadas ao portal, estas terão descrição da empresa, uma lista dos produtos, a localização Georreferencial pelo Google Maps e a visita virtual. Foi discutido sobre os prazos de entrega e finalização deste trabalho que já estavam com datas pré-agendadas e definidas. Discutiu-se sobre um documento que foi elaborado contendo um estudo sobre as funcionalidades que os CMS disponíveis no mercado tinham e quais os itens do CMS que seriam desenvolvidos e que iriam conter para atender as necessidades do cliente, foi apresentado também outro documento que continha o diagrama de classe do portal e 3 CMS. Content Management Systems, é um sistema que integra ferramentas necessárias para criar, inserir e editar conteúdo em um web site em tempo real. O grande diferencial de um CMS é permitir que um web site possa ser modificado de forma rápida de qualquer computador conectado na internet (WIKIPÉDIA, 2010).
uma lista de itens que deveria conter, foram verificados item a item deste documento para que todos tivessem entendimento pleno do que estava sendo proposto e do que deveria ser desenvolvido. No dia 03 de novembro de 2009 seria confeccionado o primeiro Product Backlog com as importâncias e estimativas. Com o consenso do grupo as reuniões diárias iriam ser realizadas nas segundas-feiras, quartas-feiras e sextas-feiras, no horário das 8h e com duração de 15min no máximo, e os Sprints teriam duração de duas semanas. Entre os dias 03 de novembro a 09 de novembro foram realizadas uma série de diálogos por e-mail, a fim de acordar um dia específico para realizar o primeiro Product Backlog, os horários e tempo disponível do grupo não estavam sendo compatíveis, sendo necessário este tempo de contato por e-mail para iniciarem os trabalhos. Dia 09 de novembro de 2009 discutiu-se sobre o início dos trabalhos no Portal Gemas. O gerente apresentou como sugestão o uso do Sympal 4, um CMS que ligado ao Symfony 5 tornaria o desenvolvimento do portal bastante eficiente, assim foi identificado à necessidade de se fazer um estudo mais detalhado, com a finalidade de analisar e detalhar a ferramenta, para poder explorar todos os recursos disponíveis deste CMS. O Product Backlog continha itens para a criação de um CMS, por exemplo, realizar uma busca dentro da web site, criar e gerenciar blocos de conteúdo, gerenciador de usuários, mapa do site, gerenciador de link e outros, na figura 3 visualiza-se uma parte do Product Backlog descrito. Com o estudo realizado do Sympal, alguns itens do Product Backlog foram marcados como resolvidos, ou seja, itens que seriam desenvolvidos agora só precisavam serem ajustados e configurados para funcionar conforme o esperado. 4 SYMPAL. É um CMS que foi projetado para usar todos os recursos existentes dentro do Symfony, adaptado como um plug-in. 5 SYMFONY. É um framework que oferece aos desenvolvedores uma série de ferramentas e componentes para construir aplicações web.
Fonte: Primária. Figura 3. Parte do Product Backlog criado Com o término da etapa projetar, resultou na criação de cinco artefatos, que foram importantes para a continuação do projeto, estes artefatos são: Product Backlog Plano de Risco PRJ08 PRJ09 Cronograma de atividades e dificuldades. 3.4 Planejar Aplicação As primeiras semanas de planejamento foram fundamentais para a continuação dos trabalhos, pois auxiliaram a equipe a compreender melhor cada requisito e como iria ser o desenvolvimento do projeto. Os artefatos de entrada desta fase, Product Backlog e Cronograma das atividades e dificuldades, foram importantes para uma visão do projeto e auxiliaram a equipe em que rumo que se iniciaria para desenvolver o portal. O primeiro Sprint foi criado no dia 09 de novembro de 2009, e teve duração de duas semanas, terminando no dia 20 de novembro de 2009, com duas finalidades,
estudar e documentar o Sympal. Na figura 4 os itens que fizeram parte do primeiro Sprint Backlog. Fonte: Primária. Figura 4. Primeiro Sprint Backlog No decorrer da semana do Sprint Backlog foi possível perceber que uma orientação bem definida faz com que os objetivos sejam alcançados no prazo previsto, trazendo uma visão de maior controle sobre o projeto e um ótimo desempenho no desenvolvimento dos trabalhos. 3.5 Planejar módulos O estudo realizado para o Sympal foi muito importante, tornou o desenvolvimento do projeto mais rápido, itens do Product Backlog foram marcados como finalizados com este estudo, sendo possível direcionar o desenvolvimento diretamente para os itens que não foram contemplados com o CMS. Assim, foram marcados com outra cor no Product Backlog os itens finalizados com o estudo do Sympal. Com os itens que foram finalizados a partir do estudo do Sympal, os esforços foram direcionados para trabalhar nos itens que faltavam serem desenvolvidos. As estimativas de tempo e importância foram mantidas, pois à partir deste ponto seria necessário fazer item a item até finalizar o Product Backlog. 3.6 Criar e Verificar Módulos Nas reuniões diárias, Daily Scrum Meeting participava o Scrum Master e o Scrum Team, eventualmente quando abordado algum assunto específico era solicitada a presença do Product Owner, nestas reuniões discutia-se o desenvolvimento dos trabalhos até o próxima reunião. Desta maneira, era possível ter um monitoramento do ponto em que o projeto estava e para onde ele estava andando. No início do projeto o tempo de 15 minutos foi ultrapassado, pois a equipe não estava tendo um total envolvimento com o trabalho,
após solicitação de que a equipe mantivesse esse um controle do horário, o tempo da reunião manteve-se se sempre dentro do previsto. O quadro Task Board,, orientou a equipe e todos os envolvidos, colaborando para o monitoramento e acompanhamento do projeto, em qualquer momento cada membro do grupo poderia ia ter uma visão geral do status do projeto. Foi oi um diferencial que resultou em um bom rendimento do trabalho. trabalho O gerente da empresa esteve sempre informado quanto ao andamento do projeto, projeto mesmo sem dialogar com a equipe equipe, podendo analisar o rendimento da Scrum Team. Fonte: Primária. Figura 5. Task Boa Board com itens do primeiro Sprint O quadro foi dividido em cinco colunas, na figura 5 tem-se se uma visão ddo Task Board com um Sprint em andamento, a primeira coluna possuía um cartaz com o ciclo de vida do Scrum um segundo com dicas de boas práticas de uma reunião diária e um espaço para os itens que não foram planejados. Na segunda coluna, continham placas com título dos itens do Sprint, Sprint, uma descrição e a sua importância, elas eram dispostas de cima para baixo com om uma escala de importância do maior para o menor. Na terceira coluna ficavam os Post-it (pequeno papel), nesta continha uma breve descrição do item, que ainda não havia iniciado o trabalho. Na quarta coluna os Post-it que estavam em desenvolvimento no momento atual. Na quinta e última coluna os Post-it que foram finalizados. Não foi adotado um software para gerenciar os itens do Product Backlog e Sprint Backlog,, pois no decorrer do trabalho notou-se notou se que o quadro demonstrava demons ser eficiente, estando sempre atualizado no ponto em que o projeto estava. Foi utilizada uma planilha eletrônica disponibilizada no Google Doc s,, onde era atualizado constantemente o Product Backlog e Sprint Backlog,, estes arquivos foram compartilhados os para todos os integrantes da equipe, desta forma todos poderiam visualizar o documento e tirar dúvidas sempre que necessário.
3.7 Validar e Entregar Aplicação Ao final de cada Sprint realizou-se uma análise do que fora proposto na ficha do cliente e também no Product Backlog. Depois da validação, o Product Backlog e as planilhas dos Sprint Backlog eram atualizados no Google Doc s. Estes documentos não eram atualizados em tempo real como o Task Board, por isso serviam apenas de orientação do conjunto de todos os Sprints Backlog já realizados. A primeira avaliação foi quando o produto já estava com mais da metade do projeto desenvolvido, o cliente dava um feedback com um parecer dizendo se estava dentro do negociado ou não. A segunda avaliação com o cliente resultou em poucas mudanças e alterações mínimas no portal, a última avaliação foi realizada juntamente com todos os envolvidos no portal, foi formalizada por uma reunião a validação de todos os itens que o projeto deveria ter. O layout do portal não ficou pronto no tempo estimado, a equipe de designer, funcionários do cliente que trabalhavam em Soledade estavam muito envolvidos em um evento que realizaria-se na cidade, estava previsto o lançado do portal neste evento, assim foi adiado o desenvolvimento do layout adiando também o lançamento do portal. 3.8 Incrementar Aplicação Este cronograma não foi realizado em todos os momentos, pois os Sprints foram curtos com duração de uma semana, assim a aplicação do Portal Gemas teve intervalos entre duas a três semanas. Os envolvidos que participaram foram: Scrum Master, Scrum Team, Product Owner, o Produc Owner estava representado o cliente. 3.9 Encerramento Projeto No encerramento do projeto foi realizado uma reunião para validar cada um dos itens poposto no Product Backlog. Estavam presente nesta reunião todos os envolvidos no projeto, todos os itens foram avaliados e validados, porém foi constatado na reunião que faltara o desenvolvimento do layout do portal que o cliente comprometeu-se em desenvolver, o mesmo sinalizou que na próxima semana iria ser criado desenvolvido para aplicação no web site. Os resultados nesta etapa final do projeto foram satisfatórios, todos os itens planejados dentro do Product Backlog foram atendidos, porém o objetivo final do projeto não foi alcançado, fazer a entrega final, pois estava previsto o lançamento do portal em um evento na cidade de Soledade, contudo o cliente não consegiu criar o layout do portal a tempo pois estava sobrecarregado de trabalho, assim foi adiado o lançamento do portal para ser desenvolvido o layout com mais tempo, ficando assim para um outro momento oportudo a inauguração do Portal Gemas. 4 Considerações Finais Este artigo apresentou a metodologia ágil de desenvolvimento Scrum, as suas práticas e conceitos. Também foi apresentado um estudo realizado no método de desenvolvimento próprio da Software House. A importância de ter um método para gerenciar o desenvolvimento de um software está ligado com a busca continua de soluções para desenvolver formas
eficientes de criar software, aumentando assim, a competitividade das empresas por construirem software com qualidade e conseguir um ganho na produtividade. A metodologia ágil Scrum pode assim ser usada por empresas desenvolvedoras que usam processo manuais para desenvolver softwares. Porém vale destacar a importância de um estudo que oriente uma forma de chegar até os resultados desejados. Como trabalho futuro, além da execução do Scrum em conjunto com o modelo de desenvolvimento da organização, um estudo com PMI 6 ou CMMI 7 poderá ser feito. O PMI ou CMMI auxilia no gerenciamento da qualidade e no custo do produto. O estudo realizado no modelo de desenvolviment da organização em conjunto com o Scrum ajudo no desenvolvimento do produto com repidez e agilidade, porém não foi realizado uma análise profunda em relação ao custo do produto e qualidade contínua do software. Assim um trabalho poderá ser feito no futuro, a fim de comprovar os benefícios que o PMI ou CMMI poderá trazer para a organização. Referências ABRAHAMSSON, Pekka, SALO Outi. Agile Software Development Methods Review and Analysis. Espoo 2002, VTT Publications 478 107. SCHWABER, Ken, BEEDLE, Mike. Agile Software Development with SCRUM. Prentice Hall, 2002. SCRUM. Disponível em: <http://www.mountaingoatsoftware.com/scrum>. Acesso em: set 2003. SOMMERVILLE, Ian, Engenharia de Software, São Paulo: Addison-Wesley, 2003. OMG. Getting Started With UML. Disponível em: <http://www.uml.org/>. Acesso em: jun. 2010. GOOGLE. Google Earth. Disponível em: <http://earth.google.com/intl/pt/>. Acesso em: jun. 2010. WIKIPÉDIA. A enciclopédia livre. Disponível em: <http://pt.wikipedia.org/wiki/ Sistema_de_gerenciamento_de_conteúdo>. Acesso em: jun. 2010. SYMFONY. Web Framework. Disponível em: <http://http://www.symfony-project.org/>. Acesso em: jun. 2010. SYMPAL. Flexible Symfony Content Management System. Disponível em: <http:// www.sympalphp.org/>. Acesso em: jun. 2010. SOFTWARE ENGENEERING INSTITUTE. CMMI. Disponível em: <http://www.sei.cmu.edu/cmmi/>. Acesso em: jul. 2010. PROJECT MANAGEMENT INSTITUTE. PMI Disponível em: < http://www.pmi. org/>. Acesso em: jul. 2010. 6 PMI, Project Management Institute é uma entidade mundial sem fins lucrativos voltada para o gerenciamento de projetos, ajudando a gerenciar os prazos, controlar os custos e avaliar os riscos. 7 CMMI, Capability Maturity Model Integration é um modelo de referencia que contém práticas necessárias à maturidade em disciplinas específicas que procura estabelecer uma mátrica para o processo de melhoria continua, ou seja a qualidade nos software desenvolvidos.