GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE
SOFTWARE COM MÉTODOS ÁGEIS
Jeandro Maiko Perceval 1 Carlos Mario Dal Col Zeve2 Anderson Ricardo Yanzer Cabral ²
RESUMO
Este artigo apresenta conceitos sobre métodos ágeis para desenvolvimento de software e gestão do conhecimento. O objetivo principal para o desenvolvimento desse trabalho é realizar uma pesquisa para descobrir processos e/ou ferramentas utilizadas para gestão do conhecimento nas empresas para com elas auxiliar em projetos de desenvolvimento de software em equipes que optam por utilizar metodologias ágeis, principalmente SCRUM, assim proporcionando uma melhor aquisição e gerenciamento dos conhecimentos adquiridos e aprendidos ao longo do ciclo de vida do desenvolvimento.
Palavras-chave: Metodologias Ágeis, SCRUM, Extreme Programming, Gestão do Conhecimento.
ABSTRACT:
This article present concepts about agile methods to develop software and knowledge management. It is intended to realize the process and tools which are used in knowledge management by companies that develops software projects, in order to assist the teams that work with this agile methods, mainly SCRUM, to afford a better acquisition and manage the knowledge learned in the course of the software development life cycle.
Key-Words: Agile Methodologies, SCRUM, Extreme Programming, Management of the Knowledge.
INTRODUÇÃO
Modelos tradicionais de desenvolvimento muitas vezes estão incompatíveis com a realidade de empresas ou com a necessidade do projeto. Exigem um número maior de colaboradores, pois focam em muita análise e documentação. Projetos comumente tornam-se
1
Acadêmico Autor do Artigo.
excessivamente demorados, pois em muitos casos, ao serem redefinidos os requisitos, a documentação deve ser reformulada para atender as novas especificações, aumentando assim o tempo do desenvolvimento do projeto, gerando incapacidade para cumprimento de prazos além de resultar em um custo maior. Quando finalizados, ocorrem de já não serem capazes de suprir as necessidades do cliente, pois essas possivelmente já foram alteradas.
Modelos baseados em métodos ágeis são principalmente úteis em casos onde há grande variação de requisitos por parte do cliente, pois pregam que o sistema deve ir se adaptando conforme exigências que são verificadas ao longo do ciclo de desenvolvimento. Em muitos casos o cliente não entende a colaboração real que um sistema pode vir a dar a seu negócio. Conhecimento que pode ser adquirido ao utilizar diferentes versões de um sistema até alcançar sua ferramenta ideal.
Em projetos guiados por Metodologias Ágeis, a informação retida ao final do projeto é pouca, restringindo-se quase que somente ao produto final em si. O que leva a poder dizer que, em projetos de desenvolvimento de software, a maior parte da informação e do conhecimento armazenado está nos códigos e em seus comentários deixados pelos desenvolvedores.
Acredita-se fazer necessário estudar maneiras para armazenar e melhor gerenciar conhecimentos e lições aprendidas no uso de métodos ágeis de desenvolvimento de software.
METODOLOGIAS ÁGEIS
Metodologias Ágeis possibilitam à equipe de desenvolvimento concentrar-se no software somente, ao invés de em seu projeto e documentação. Geralmente, contam com uma abordagem iterativa para especificação, desenvolvimento e entrega de software, e foram criadas principalmente para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento (SOMMERVILLE, 2007). Complementando, o autor ainda cita que “destinam-se a entregar um software de trabalho rapidamente aos clientes, que podem então propor novos requisitos e alterações a serem incluídos nas iterações posteriores do sistema”.
Para Martin Fowler (FOWLER, 2003) as metodologias ágeis tentam criar um equilíbrio entre nenhum e muito processo. O autor considera que a diferença mais evidente dessas metodologias para as tradicionais é que metodologias ágeis são menos centradas em documentação, normalmente enfatizando uma quantidade menor de documentos para uma dada tarefa.
Existem diversas metodologias baseadas nos princípios ágeis, porém esse trabalho foca apenas em SCRUM e Extreme Programming.
ORIGEM
O surgimento dessas metodologias deu-se pelo fato de seus idealizadores, por terem grande experiência em desenvolvimento de software, e, por isso, terem presenciado um grande número de projetos que não tiveram um retorno esperado ou que muitas vezes acabou sendo cancelado, tentarem definir maneiras para acabar com o “caos” que alguns projetos de software acabam se tornando. Para isso eles identificaram as principais causas de fracasso de projetos e buscaram maneiras e práticas, muitas já conhecidas, para elaborar uma nova maneira para gerenciar projetos de software.
MANIFESTO ÁGIL
Em 2001, um grupo de pesquisadores auto denominados de Aliança Ágil (Agile Alliance), entre eles Martin Fowler, Alistair Cockburn, Jim Highsmith, Kent Beck, Mike Beedle e outros, motivados pela suas experiências em desenvolvimento de software, iniciaram uma discussão sobre como desenvolver software de forma mais rápida e eficaz, orientado principalmente à simplicidade (ZANATTA, 2004). Esta discussão resultou no chamado Manifesto Ágil, que em síntese aponta:
“Desejamos descobrir melhores caminhos para desenvolver software fazendo e ajudando outros a fazerem. Valorizamos os indivíduos e interações através de processos e ferramentas; O desenvolvimento de software deve possuir uma documentação compreensiva; A colaboração do cliente e respostas às mudanças através de um plano específico” (AGILE, 2008).
SCRUM
Ken Schwaber (SCHABER, 2008), desenvolvedor dos processos do SCRUM junto com Jeff Sutherland, define SCRUM como sendo um processo Ágil que pode ser utilizado para gerenciar e controlar o desenvolvimento de softwares, produtos e qualquer projeto usando iteração e práticas incrementais.
Para Zanatta, (ZANATTA, 2004), o SCRUM é um método para gerenciar o processo de desenvolvimento de software não definindo técnicas nem ferramentas, apenas define como equipes devem trabalhar em ambientes onde requisitos mudam constantemente, sofrendo
alterações constantes, oposto ao que ocorre normalmente em uma indústria de manufatura qualquer, onde os processos são repetíveis e muitas vezes bem definidos.
Para Schwaber (SCHWABER, 2008), o gerenciamento é atingido e verificado com as reuniões diárias do SCRUM. Durante essas reuniões pode-se observar o espírito do time, a participação de cada integrante e a interação entre eles e ainda problemas no andamento do projeto. O autor complementa dizendo que tudo é visível - o que deverá ser feito, como o trabalho está progredindo e aquilo que já foi realizado. SCRUM apóia decisões relativas à gestão dos custos, tempo, qualidade e funcionalidade. Além disso, a gestão diária está ciente do que pode fazer para ajudar o desenvolvimento - quais decisões são necessárias, e que está ficando no caminho.
PAPÉIS EM UM PROJETO SCRUM
Em SCRUM existem três diferentes papeis conduzindo o projeto. Que são eles:
Product Owner. Representa o interessado no resultado do projeto. Pode ser o próprio cliente ou um representante. É responsável por definir e priorizar o que necessita, além de avaliar o resultado de cada iteração, pois sabe as reais necessidades do produto e seu verdadeiro valor de retorno.
Scrum Master. Para Schwaber (SCHWABER, 2004), o Scrum Master é o responsável pela realização das tarefas (valores e práticas) e pelo sucesso direto do Scrum. É seu dever conhecer as regras e práticas do SCRUM para auxiliar o Team e o Product Owner.
Scrum Team. A Equipe Scrum, através de encontros com o Scrum Master, é responsável pelas ações para atingir os objetivos de cada Sprint (ZANATTA, 2004). No SCRUM, o time deve se autogerenciar para atingir melhores resultados possíveis. Podem executar as tarefas prioritárias de cada sprint da maneira que desejarem.
ARTEFATOS E FASES DO SCRUM
A seguir serão descritos os artefatos e fases de um projeto SCRUM, tendo como base o livro do Schwaber (Schwaber, 2004).
Product Backlog. É uma lista com os requisitos do software ou produto que será desenvolvido no projeto. É responsabilidade do Product Owner fornecer as informações do produto, disponibilizá-las e priorizá-las.
Sprint Backlog. É composto por tarefas do Product Backlog definidas pela Equipe, Scrum Master e Product Owner a ser desenvolvida no Sprint atual.
Sprint. É onde as tarefas do Sprint Backlog são executadas pela equipe. Em projetos de software, é onde o código é gerado, é a fase de desenvolvimento em si. Deve durar aproximadamente trinta dias.
Daily Scrum. Devem ser realizadas, preferencialmente, diariamente com duração entre quinze e trinta minutos. Nelas é possível identificar obstáculos ou impedimentos ao projeto. É dever do Scrum Master perguntar a cada integrante do Scrum Team o que ele realizou desde a última reunião, o que realizará até a próxima e que problemas ele esta tendo para a realização do seu trabalho.
Sprint Planning Meeting. É dividido em duas partes de quatro horas cada. Na primeira, o Product Owner apresenta suas prioridades do Product Backlog para o Team, que deve questioná-lo para esclarecer-lhes suas dúvidas sobre o que esta sendo solicitado. Na segunda, o Team deve definir como executará as tarefas priorizadas pelo Product Owner, tarefas que agora compõem o Sprint Backlog.
Sprint Review Meeting. Reunião realizada ao final de cada Sprint onde será apresentado ao Product Owner o resultado alcançado, ou seja, a nova funcionalidade implementada, caso o projeto seja de desenvolvimento de software, é apresentada aos interessados.
EXTREME PROGRAMMING (XP)
Para Kent Beck, um dos criadores da XP (BECK, 2000), define XP como sendo uma metodologia leve para times de tamanho pequeno a médio, que desenvolvem software em face de requisitos vagos que se modificam rapidamente.
Martin Fowler (FOWLER, 2003) informa que as raízes do XP estão principalmente ligadas a colaboração estreita entre Kent Beck e Ward Cunningham no final da década de 1980. Ambos refinaram suas práticas em diversos projetos durante a década de 90, estendendo suas idéias para uma abordagem de desenvolvimento de software que fosse tanto adaptativa, quanto orientada a pessoas.
Tendo como base seus valores (comunicação, simplicidade, feedback e coragem), a XP especifica 12 práticas para sua implementação. Em sua maioria, essas praticas não foram “inventadas” pelos idealizadores da XP, mas sim os mesmos buscaram técnicas esquecidas que até mesmo não deram certo no passado. Porém, afirmam que unidas, é possível agregar o valor de cada e ainda uma complementar e reforçar as outras em seus pontos fracos.
Para Turban (TURBAN, 2004), a Gestão do Conhecimento (GC) é um processo que ajuda as empresas a identificar, selecionar, organizar, distribuir e transferir informação e conhecimento especializado que fazem parte da memória da empresa e que normalmente existem dentro delas de forma não-estruturada. O autor complementa dizendo que a gestão do conhecimento é basicamente um processo de extrair, transformar e difundir o conhecimento por toda a empresa, de forma que possa ser compartilhado e, portanto, reutilizado.
A Gestão do Conhecimento visa definir formas para melhorar o acesso à informação de uma organização, pois através de maneiras fáceis e bem definidas para sua obtenção no momento adequado, poderá ser (e provavelmente será) um grande fator para auxiliar a empresa em suas tomadas de decisões.
PROCESSO DE GESTÃO DO CONHECIMENTO
Em um bom sistema de GC, o conhecimento nunca está terminado, pois, com o tempo, o ambiente muda e ele precisa ser atualizado de modo a refletir essas mudanças. Com base nessa afirmação, Turban (TURBAN, 2004) propõe um ciclo para melhor gerenciar a informação dentro de uma empresa, onde o conhecimento deve ser criado, capturado, depurado, armazenado, administrado e difundido.
FERRAMENTAS PARA CONTROLE DE TAREFAS
Com o decorrer das pesquisas, ferramentas para auxiliar o gerenciamento de tarefas e para melhor auxiliar a comunicação entre integrantes de projetos ágeis foram descobertas. Como normalmente são ferramentas simples e com um único propósito (melhorar comunicação entre integrantes das equipes), foi verificado uma possibilidade de estudar maneiras para a essas ferramentas, que já são utilizadas em projetos de softwares ágeis, propor melhorias para também obter-se melhor gerenciamento dos conhecimentos.
Não foram realizados testes de comparação entre ferramentas. Para a realização do trabalho, decidiu-se utilizar a ferramenta AgilePlanner. A proposta será analisar funções ausentes na ferramenta, para após definir melhoramentos ou ferramentas que poderiam ser pesquisadas ou desenvolvidas para seu melhor aproveitamento.
AGILE PLANNER
O AgilePlanner auxilia à disponibilizar imediatamente o planejamento estabelecido em reunião, fornecendo uma maneira para criar, organizar e editar eletronicamente os cartões
de tarefas do projeto. A alteração realizada por uma equipe será imediatamente vista por integrantes do projeto onde quer que estejam, sejam eles integrantes da equipe que alterou, ou membros de outra equipe do projeto que esta localizada em outro país (PLANNER, 2008).
As metodologias ágeis buscam sempre deixar disponível para todos o que esta sendo, o que já foi, e o que deverá ser realizado. Para isso, comumente as equipes trabalham com cartões de histórias e tarefas, onde cada contém uma tarefa a ser realizada. O AgilePlanner possibilita que esses “cartões” estejam on-line para maior facilidade de acesso e possibilita a integração e visualização entre equipes separadas geograficamente.
SOLUÇÃO PROPOSTA
O trabalho pretende aprofundar os estudos na ferramenta AgilePlanner. O objetivo de tal estudo será o de entender sua utilização e contribuição para projetos de desenvolvimento de software que utilizam a Metodologia Ágil SCRUM. Com isso, será possível definir pontos onde serão propostos melhorias ao sistema, para com ele, melhorar a Gestão do Conhecimento em projetos de desenvolvimento de software que utilizam Metodologias Ágeis.
CONCLUSÃO
Através dos estudos realizados foi possível obter um melhor esclarecimento sobre o estado da arte das metodologias ágeis, constatou-se que se faz necessário estudar maneiras para apoiá-las através da utilização de técnicas e ou ferramentas para gestão do conhecimento. Definiu-se por realizar uma melhor análise sobre a ferramenta AgilePlanner, podendo assim propor melhorias para utiliza-la também para a retenção e gerenciamento dos conhecimentos adquiridos e aprendidos durante o ciclo de desenvolvimento de software.
BIBLIOGRAFIA
MARTINS, José Carlos Cordeiro, Gerenciando projetos de desenvolvimento de software. 2.ed. Rio de Janeiro: Brasport, 2005.
TURBAN, Efraim; McLEAN, Efraim; WETHERBE, James. Tecnologia da Informação para Gestão. Porto Alegre. Bookman, 2004.
SOMMERVILLE, Ian, Engenharia de Software 8.ed. Pearson 2007
BECK, Kent, Programação Extrema (XP) Explicada. Acolha as mudanças. São Paulo. Bookman, 2000
AGILE, Manifesto. Site oficial dos criadores das metodologias ágeis. Visitado em 10/06/2008. Disponível na internet via WWW. URL: http://agilemanifesto.org/
SCHWABER, Ken. Site oficial do Scrum. Visitado em 11/06/2008. Disponível na internet via WWW. URL: http://www.controlchaos.com/about/
SCHWABER, Ken. Agile Project Management with Scrum. Microsoft Press, 2004
ZANATTA Lazaretti, Alexandre. xScrum: uma proposta de extensão de um Método Ágil para Gerência e Desenvolvimento de Requisitos visando adequação ao CMMI Florianópolis, 2004. Dissertação (Mestrado em Ciência da Computação) - Curso de Pós-Graduação em Ciência da Computação, Universidade Federal de Santa Catarina. Disponível em www.tede.ufsc.br/teses/PGCC0651.pdf.
JEFFRIES, Ron. Site sobre XP. O autor é um dos pioneiros na utilização da metodologia junto com Kent Beck, no projeto C3 da Chrysler. Visitado em 22/06/2008. Disponível na internet via WWW. URL: http://www.xprogramming.com/xpmag/whatisxp.htm
WELLS, Don. Site sobre XP. O autor é um dos pioneiros na utilização da metodologia junto com Kent Beck, no projeto C3 da Chrysler. Visitado em 22/06/2008. Disponível na internet via WWW. URL: http://www.extremeprogramming.org/what.html
PLANNER. Site do Agile Planner. Visitado em 20/06/2008. Disponível na internet via WWW. URL: http://ebe.cpsc.ucalgary.ca/ebe/index.php/AgilePlanning/Home
CHAPIEWSKI, Guilherme. Como estamos indo com a adoção de Scrum na Globo.com.
Visitado em 09/06/2008. Disponível na internet via WWW. URL:
