Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil Roberto Costa Araujo Orientador: Cristiano T. Galina Sistemas de Informação Universidade do Vale do Rio dos Sinos (Unisinos) São Leopoldo RS Brasil betopac@yahoo.com.br Resumo: Este artigo apresenta um resumo bibliográfico, referente ao estudo e aplicação da combinação de P, SCRUM e Lean Software Development para definição de escopo, estimativa de tamanho do backlog de produto e valor do projeto, a partir da análise preliminar. 1. Introdução Baseando-se em uma realidade onde os prazos são cada vez mais curtos, onde cada correção de erro deduz um valor considerável em projetos, busca-se nas metodologias ágeis tais como: P, SCRUM e Lean Software Development, maneiras de agilizar o processo de desenvolvimento de software. No produto do trabalho da compreensão do que o cliente deseja que seja desenvolvido (COURAGE e BATER, 2005) e entendendo sua necessidade, deseja-se convergir para o caminho de menos retrabalho, minimizando assim a possibilidade de erros no desenvolvimento. Deseja-se uma participação efetiva do usuário, seja o solicitante ou outro que domina o processo de negócio durante o desenvolvimento, para compor-se uma estrutura de equipe comprometida com a conclusão do projeto no tempo previsto, priorização dos casos de uso e uma metodologia de desenvolvimento e entregas onde se propicia uma rápida correção de erros no desenvolvimento (POPPENDIECK, 2006). 1.1. Motivação Dentre os diversos fatores críticos no desenvolvimento de software, atualmente, pode-se citar: prazos para determinar o valor do projeto extremamente reduzido, dificuldade para determinar o tempo de duração do mesmo, identificação e correção de erros no final do desenvolvimento acarretando custo elevado para solução dos mesmos, mudanças de escopo no decorrer do desenvolvimento, trabalho da equipe de desenvolvimento em funções que não agregam valor considerável ao mesmo.
Partindo de um cenário onde a TI (tecnologia da informação) é base estratégica das empresas, mas carrega com ela o estigma de não respeitar prazos e demandar mais recursos do que foi inicialmente previsto, busca-se a convergência no uso de diversas metodologias de desenvolvimento (P, SCRUM e Lean Software Development) para compor um método simples e eficiente de solucionar estes paradigmas. Citam-se também exemplos bem sucedidos, como o Sistema Toyota de Produção, aqui focados no desenvolvimento de software, buscando diminuir, por exemplo, a incidência de erros no desenvolvimento (POPPENDIECK, 2006). O trabalho de equipes distintas e sincronizadas constitui o panorama ideal para cumprir o que é proposto na metodologia SCRUM, evitando o conceito apresentado por COHN: a ideia de cozinhar a pizza e guardar para entregar depois. 1.2. Objetivos Tem-se como objetivo, através do presente trabalho, estudar práticas de SCRUM, P e Lean Software Development, propor uma metodologia para mensurar a complexidade de partes decompostas de um caso de uso (COHN, 2004), definir escopo e criar a Estrutura Analítica de Projeto somente baseado no modelo de temas e estórias do usuário, realizar o aprofundamento do método de desenvolver cronograma e estimar custos de um projeto com base no desempenho da equipe e propor um método de trabalho baseado em entregas contínuas. 2. SCRUM Inicialmente o SCRUM foi concebido para gerenciamento de projetos de fabricação de automóveis e de produtos de consumo, por Takeuchi e Nonaka no artigo The new product development game, em janeiro-fevereiro de 1986, pela Universidade de Harvard. Neste artigo, Takeuchi e Nokada notaram que em projetos com equipes pequenas e multidisciplinares produziam melhores resultados, e associaram isto a formação Scrum do Rugby. Em 1995, o SCRUM teve sua definição formalizada por Ken Schwaber, que trabalhou para consolidá-lo como método de desenvolvimento de software por todo o mundo. 2.1. Entregas Contínuas A metodologia proposta pelo modelo SCRUM aplica um sistema de entregas contínuas. Nesta metodologia com os backlogs definidos (que são os requisitos funcionais do sistema), um sprint programado (tempo prédeterminado no qual será dividido o trabalho para efetuação de uma entrega, tendo como padrão o prazo dentre uma a duas semanas), reuniões diárias (de 10 minutos para acompanhar se o projeto está de acordo com o planejamento) e, ao
final de cada sprint, uma reunião de retrospectiva e planejamento do próximo sprint 1. Como ilustração do método traz-se a figura 1 onde mostra a aplicação em um ambiente de desenvolvimento de software. Figura 1 Processo de entrega contínua, Metodologias ágeis para desenvolvimento de software, PARZIANELLO 2008. 2.2. Planejando as interações (entregas) Na metodologia SCRUM para se planejar uma interação (uma entrega como ilustra a figura) deve-se seguir a seguinte seqüência de atividades, segundo COHN: Discutir uma estória; Decompor uma estória em tarefas; Um desenvolvedor aceita a responsabilidade por cada tarefa; Após todas as estórias terem sido discutidas e todas tarefas aceitas, os desenvolvedores individualmente estimam as tarefas aceitas para ter 1 [PARZIANELLO 2008] PARZIANELLO, Luiz Cláudio. Seminário sobre Metodologias Ágeis para desenvolvimento de software, Porto alegre, 2008.
certeza de que eles não estão se comprometendo com algo que não podem cumprir. 2.3. Desempenho da equipe O desempenho da equipe será definido com base no histórico de entregas e conclusões de projetos anteriores, ações que irão definir o quanto em pontos a equipe consegue atingir. Caso seja o início da implementação do SCRUM no setor de desenvolvimento de software, este sprint inicial deve ser o referencial para se medir a velocidade da equipe. Através da observação da equipe a qual está sendo proposto o trabalho na ThyssenKrupp Elevadores, percebe-se que cada desenvolvedor atinge em média 20 pontos por sprint de duração de duas semanas. Tal desempenho pode ser afetado por diversos fatores, os quais que devem ser trazidos para discussão na reunião de retrospectiva e planejamento. Nesta reunião, abordar-se-á a apresentação de problemas e gargalos encontrados, buscando assim resoluções para os mesmos, resultando em melhorias no processo de desenvolvimento de software e conseqüentemente na velocidade de conclusão dos próximos sprints 2. 3. P Extreme Programming O P (Extreme Programming), nascido nos anos 90 nos Estados Unidos, foi composto para ajudar a desenvolver software com qualidade. Esta abordagem nasce a partir de um período onde o desenvolvimento de projetos levava mais tempo que o planejado, estourava os orçamentos propostos e entregava em média apenas 67% das funcionalidades prometidas, conforme estudo efetuado por Standish Group, no ano de 1994, chamado The Chaos Report 3. 3.1. Planejamento iterativo O planejamento iterativo do P confronta a estrutura do modelo cascata, ilustrado na figura 2, propondo planejamento de sprints, no qual cada iteração entrega um software que agrega valor para o solicitante. 2 [GOLDRATT e CO] GOLDRATT Eliyahu M. e CO Jeff. A meta: um processo de melhoria contínua. Nobel, 2003. 3 [TELES] TELES Vinícius Malhães. Um estudo de caso da adoção das práticas e valores do Extreme Programming, Universidade Federal do Rio de Janeiro, 2005.
Este planejamento iterativo aproxima o usuário para validações de cada entrega e priorização do que será desenvolvido no projeto. O P caracteriza-se também por resolver os problemas e/ou erros de desenvolvimento assim que os mesmos aparecem, evitando que o custo da resolução destes seja multiplicado ao final do projeto. 4 Figura 2 [Fonte:http://www.improveit.com.br/download/TDC2008-Extreme-programming.pdf] 3.2. Estória do usuário As estórias dos usuários são escritas pelos próprios usuários, conforme a metodologia do P (ilustrada pela figura 3), e estas estórias, segundo COHN 5 : Têm valor para o cliente ou usuário São independentes umas das outras São testáveis Do tamanho ideal 4 [POPPENDIECK 2006] POPPENDIECK, Tom and Mary. Implementing Lean Software Development from Concept to Cash. Addison Wesley Professional, 2006. [TELES] TELES Vinícius Malhães. Um estudo de caso da adoção das práticas e valores do Extreme Programming, Universidade Federal do Rio de Janeiro, 2005. 5 [COHN 2004] COHN, Michael W. User Story Applied. Addison-Wesley, 2004.
Figura 3 [Fonte: http://www.improveit.com.br/download/tdc2008-extreme-programming.pdf] As estórias são escritas tradicionalmente em cartões com o intuito de realmente privar o usuário de se estender ao escrever e direcionando-o a ser o mais sucinto possível. Diz-se que as estórias são testáveis, pois assim serão transportadas para servir como testes de aceitação. O desenvolvedor as utilizará para validar uma implementação e também servirá, tal anotação, para mostrar ao usuário ou cliente que o que ele solicitou foi testado, conforme o que ele mesmo colocou no papel. 4. Cronograma O cronograma está seguindo conforme o planejado. Atividade/Mês Elaborar os objetivos Preparação da Proposta Levantamento bibliográfico Análise da Literatura Análise de padrões e técnicas Avaliar os processos atuais da empresa Compor os pontos para comparação com o método proposto e o questionário de avaliação Escrita do Relatório de Andamento Entrega/Apresentação do Relatório Definir as práticas propostas pelo SCRUM Definir as práticas propostas pela P Mar Abr Mai Jun Jul Ago Set Out Nov Dez
Propor as alterações no processo de teste Apresentar o resultado da comparação dos dois métodos Elaborar a apresentação Apresentar o TCC 5. Considerações finais A pesquisa tem sido mais que satisfatória até o momento, pois o tema é rico em publicações, páginas e discussões na internet. Como trata-se de um tema novo no cenário brasileiro e uma abordagem de desenvolvimento diferente da usual (cascata) motiva a pesquisa deste novo método de produzir software. 6. Referências [COHN 2004] COHN, Michael W. User Story Applied. Addison-Wesley, 2004. [POPPENDIECK 2006] POPPENDIECK, Tom and Mary. Implementing Lean Software Development from Concept to Cash. Addison Wesley Professional, 2006. [PARZIANELLO 2008] PARZIANELLO, Luiz Cláudio. Seminário sobre Metodologias Ágeis para desenvolvimento de software, Porto alegre, 2008. [COCKBURN 2000] COCKBURN, Alistair. Writting Efective Use Cases. Addison Wesley, 2000. [NASCIMENTO 2008] NASCIMENTO, Humberto. Scrum distribuído, Levantamento das práticas e modelos das ferramentas utilizadas pelo mercado de desenvolvimento distribuído, 2008. [GOLDRATT e CO] GOLDRATT Eliyahu M. e CO Jeff. A meta: um processo de melhoria contínua. Nobel, 2003. [SCHWABER] SCHWABER Ken. SCRUM Development Process, 1995. [TAKEUCHI e NONAKA] TAKEUCHI Hirotaka e NONAKA Ikujiro. The new new product development game, Harvard Business Review, 1986. [JEFFRIES] JEFFRIES Ron, Programming.com na Agile Software Development Resource, disponível em: http://xprogramming.com/blog/needles/how-should-user-stories-bewritten.htm Acesso em: 04 mai. 2009.
[JEFFRIES] JEFFRIES Ron, Programming.com na Agile Software Development Resource, Disponível em: http://www.xprogramming.com/xpmag/expcardconversationconfirmation.htm Acesso em: 04 mai. 2009. [TELES] TELES Vinícius Malhães. Extreme Programming, Novatec, 2004. [TELES] TELES Vinícius Malhães. Um estudo de caso da adoção das práticas e valores do Extreme Programming, Universidade Federal do Rio de Janeiro, 2005.