Desenvolvimento Ágil de Software: uma abordagem com SCRUM e XP

10,843
-1

Published on

Este trabalho estuda duas metodologias ágeis para desenvolvimento de software com o intuito
de explorar os benefícios decorrentes da combinação entre elas. As metodologias estudadas,
Extreme Programming e Scrum, são caracterizadas pelo desenvolvimento de diversas
iterações. Cada iteração resulta em um software, que é aprimorado na iteração subseqüente.
Além disso, possuem propriedades complementares: Extreme Programming atenta
principalmente para o processo de desenvolvimento do software, enquanto Scrum volta-se
para o gerenciamento da equipe que o desenvolve. Com o intuito de demonstrar os benefícios
da combinação dessas metodologias, este trabalho: estuda os processos para desenvolvimento
de softwares, focalizando o desenvolvimento ágil, apresenta o Extreme Programming e o
Scrum, discutindo seus métodos e investiga métodos de combinação entre as duas
metodologias.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
10,843
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
336
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Desenvolvimento Ágil de Software: uma abordagem com SCRUM e XP

  1. 1. CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA DE MOCOCACURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA – ÊNFASE EM GESTÃO DE NEGÓCIOS Tiago Lucas Lopes de Oliveira DESENVOLVIMENTO ÁGIL DE SOFTWARE: UMA ABORDAGEM COM SCRUM E XP Mococa, SP 2º Semestre/2009
  2. 2. TIAGO LUCAS LOPES DE OLIVEIRADESENVOLVIMENTO ÁGIL DE SOFTWARE: UMA ABORDAGEM COM SCRUM E XP Monografia apresentada à Faculdade de Tecnologia de Mococa, como parte dos requisitos para a obtenção do título de Tecnólogo em Informática – Ênfase em Gestão de Negócios. Orientadora: Sandra Cristina Costa Co-orientador: Orlando Clínio Patriarcha Mococa, SP 2º Semestre/2009
  3. 3. TIAGO LUCAS LOPES DE OLIVEIRADESENVOLVIMENTO ÁGIL DE SOFTWARE: UMA ABORDAGEM COM SCRUM E XP Monografia apresentada à Faculdade de Tecnologia de Mococa, como parte dos requisitos para a obtenção do título de Tecnólogo em Informática – Ênfase em Gestão de Negócios. Orientadora: Profª Drª Sandra Cristina Costa Co-orientador: Orlando Clínio Patriarcha ASS. ______________________________________________________ 1º Examinador: Sandra Cristina Costa Instituição: Faculdade de Tecnologia de Mococa ASS. ______________________________________________________ 2º Examinador: Orlando Clínio Patriarcha Instituição: ASS. ______________________________________________________ 3º Examinador: Geraldo Instituição: Faculdade de Tecnologia de Mococa Nota: Mococa, dia 18 de Dezembro de 2009
  4. 4. Dedico este trabalho a todos aqueles quetornaram suas vidas inspiração para meusideais, deixaram um pouco de poesia erevolução não ao mundo, mas a todos quetem o desejo de sonhar.
  5. 5. AGRADECIMENTOS Após finalizar este trabalho, não pude deixar de aproveitar este espaço e agradeceraqueles que tornam minha vida uma batalha agradável a travar. Agradeço primeiramente a Deus, que por intercessão de sua mãe sempre me atendeu mesmo que não soubesse. Tenho tudo, todo o necessário e a certeza de que essa é a graça. A professora Sandra, que teve paciência e tranqüilidade em acreditar nesse trabalho. Agradeço pela boa vontade e tempo dedicado. Ao meu amigo e co-orientador Orlando, seu apoio foi determinante para a realização deste trabalho, agradeço também pela inspiração e indicações durante todo o desenvolvimento nessa etapa. A meus pais, Silvio e Elenita. Aprecio o quanto são determinados para criar e viver uma família. Sem eles nada seria possível. Esse amor é essencial em toda a minha formação. A minhas irmãs, Daniele, Caroline e Gabriela, acredito que elas merecem ser lembradas nesse momento, que possam ser inspiradas e assim lutar por todos os seus objetivos. A meus avós, Zezinho e Genésia, me orgulho muito em ser neto deles, todos os dias agradeço a Deus pela família que tenho, sinto falta, amo e torço por todos. A minha namorada, Ana Flávia, são mais de dois anos juntos, assim lutamos por nossos ideais e estamos conquistando mais um objetivo, obrigado por tudo. Todas as horas de trabalhos e estudos valem a pena quando se tem ao lado pessoas tão preciosas. A meus amigos, padre Ilsinho, padre Elviro, Luciana, João Paulo, Bruno e Graziela só tenho a agradecer por todo apoio e parceria durante muitos dos bons e maus momentos de minha vida.
  6. 6. Não são as espécies mais fortes quesobrevivem, nem as mais inteligentes, masaquelas mais sensíveis à mudanças.(DARWIN, apud KOSCIANSKI, 2007)
  7. 7. RESUMOEste trabalho estuda duas metodologias ágeis para desenvolvimento de software com o intuitode explorar os benefícios decorrentes da combinação entre elas. As metodologias estudadas,Extreme Programming e Scrum, são caracterizadas pelo desenvolvimento de diversasiterações. Cada iteração resulta em um software, que é aprimorado na iteração subseqüente.Além disso, possuem propriedades complementares: Extreme Programming atentaprincipalmente para o processo de desenvolvimento do software, enquanto Scrum volta-separa o gerenciamento da equipe que o desenvolve. Com o intuito de demonstrar os benefíciosda combinação dessas metodologias, este trabalho: estuda os processos para desenvolvimentode softwares, focalizando o desenvolvimento ágil, apresenta o Extreme Programming e oScrum, discutindo seus métodos e investiga métodos de combinação entre as duasmetodologias.Palavras-chave: Software; Ágil; Metodologias; Desenvolvimento; Iteração.
  8. 8. ABSTRACTThis paper studies two agile methodologies to software development to explore the benefits ofcombining them. The methodologies studied, Extreme Programming and Scrum, arecharacterized by the development of iterations, each resulting in a software program, which istuned in the subsequent iteration. Besides, both methodologies have complementary features:Extreme Programming turns mainly to software development process, while Scrum focuseson management of the team developing the software. In order to explore the combination ofthese two methodologies, this paper studies software development processes, focusing onagile development, then it presents Extreme Programming and Scrum, discussing theirmethods and, finally, it investigates methods of combinations between them.Keywords: Methodologies. Development. Iterations. Process. Agile.
  9. 9. LISTA DE FIGURASFigura 1 – Modelo em Cascata – Ciclo de Vida ............................................................... 17Figura 2 – Sistema de Incremento ..................................................................................... 19Figura 3 - Prototipação ...................................................................................................... 20Figura 4 – Modelo em Espiral .......................................................................................... 21Figura 5 – A realimentação e a adaptação iterativa levam ao sistema desejado.A instabilidade dos requisitos diminuem com o tempo ...................................................... 23Figura 6 – Termos relativos ao cronograma em PU .......................................................... 24Figura 7 – Disciplinas em PU ............................................................................................ 25Figura 8 – Tipos de conclusão de projetos ........................................................................ 27Figura 9 – Ciclo de vida do XP ......................................................................................... 44Figura 10 – Variáveis do Sprint ......................................................................................... 49Figura 11 – Modelo Sprint Backlog .................................................................................. 50Figura 12 – Exemplo Sprint Backlog ................................................................................ 51Figura 13 – Modelo de Sala de Equipe .............................................................................. 52
  10. 10. LISTA DE SIGLASAOO – Análise Orientada a ObjetosPOO – Programação Orientada a ObjetosPU – Processo Unificado (Unified Process)RUP – Rational Unified ProcessUML – Unified Modeling LanguageXP – Extreme ProgrammingPDCA – Plan, Do, Check and Act.
  11. 11. SUMÁRIO1. INTRODUÇÃO ............................................................................................................. 122. PROCESSOS DE SOFTWARE E DESENVOLVIMENTO ÁGIL ......................... 142.1 PROCESSOS DE SOFTWARE ................................................................................... 142.1.1 Modelo em Cascata .................................................................................................. 162.1.2 Modelo Incremental ................................................................................................. 172.1.3 Prototipação ............................................................................................................. 182.1.4 Modelo em Espiral ................................................................................................... 202.2 PROCESSO UNIFICADO ........................................................................................... 212.2.1 RUP ........................................................................................................................... 252.3 DESENVOLVIMENTO ÁGIL .................................................................................... 253. EXTREME PROGRAMMING ................................................................................... 303.1 CLIENTE PRESENTE ................................................................................................. 303.2 JOGO DO PLANEJAMENTO ..................................................................................... 333.2.1 Responsabilidades .................................................................................................... 333.2.2 Estimativas de Estórias ........................................................................................... 343.2.3 Releases ..................................................................................................................... 353.2.4 Iterações .................................................................................................................... 363.3 STAND UP MEETING ................................................................................................ 373.4 PROGRAMAÇÃO EM PAR........................................................................................ 383.5 REFACTORING .......................................................................................................... 393.6 DESENVOLVIMENTO GUIADO POR TESTES ...................................................... 393.7 CÓDIGO COLETIVO .................................................................................................. 403.8 CÓDIGO PADRONIZADO ......................................................................................... 403.9 DESIGN SIMPLES ...................................................................................................... 413.10 METÁFORA .............................................................................................................. 423.11 RITMOS SUSTENTÁVEL ........................................................................................ 423.12 INTEGRAÇÃO CONTINUA..................................................................................... 433.13 CICLO DE VIDA DO XP .......................................................................................... 434. SCRUM .......................................................................................................................... 454.1 PRODUCT BACKLOG, PRODUCT OWNER E PRIORIZAÇÃO DE ESTÓRIAS . 454.2 PLANEJAMENTO DO SPRINT ................................................................................. 474.3 SPRINT BACKLOGS .................................................................................................. 494.4 SALA DA EQUIPE ...................................................................................................... 514.5 REUNIÕES DIÁRIAS ................................................................................................. 524.6 APRESENTAÇÃO DE SPRINTS................................................................................ 52
  12. 12. 4.7 RETROSPECTIVA DE SPRINTS ............................................................................... 524.8 COMBINAÇÃO ENTRE EXTREME PROGRAMMING E SCRUM ....................... 534.8.1 Programação em Par ............................................................................................... 534.8.2 Desenvolvimento Orientado a Testes (TDD) ......................................................... 544.8.3 Design Incremental .................................................................................................. 554.8.4 Integração Contínua ................................................................................................ 554.8.5 Propriedade Coletiva do Código ............................................................................ 564.8.6 Ambiente de Trabalho Informativo ....................................................................... 564.8.7 Padrão de Codificação ............................................................................................. 564.8.8 Ritmo Sustentável e Trabalho Energizado ............................................................ 575. ESTUDO DE CASO ..................................................................................................... 585.1 O PROJETO ANCAR2GO ........................................................................................... 585.2 ASPECTOS POSITIVOS DO PROJETO .................................................................... 595.2.1 Integração Contínua ................................................................................................ 595.2.2 Deployment Automatizado...................................................................................... 605.2.3 Testes ......................................................................................................................... 605.2.4 Programação em Par ............................................................................................... 615.3 DESAFIOS TÉCNICOS ............................................................................................... 625.4 PREVAYLER ............................................................................................................... 645.5 RELACIONAMENTO DE TI COM A ORGANIZAÇÃO .......................................... 655.6 PRECISA MELHORAR............................................................................................... 665.7 RELACIONAMENTO COM OS SHOPPINGS .......................................................... 665.8 EXTREME PROGRAMMING E SCRUM NO SGSC ................................................ 676. CONSIDERAÇÕES FINAIS ....................................................................................... 68REFERÊNCIAS ................................................................................................................ 70
  13. 13. 121 INTRODUÇÃO A Engenharia de Software traz consigo diversos modelos para o processo dedesenvolvimento de software, muitos deles foram criados com um pensamento que não cabe aessa forma de trabalho. Alguns modelos como, por exemplo, o modelo em cascata, sãobaseados em modelos da fabricação industrial, os quais não parecem adequados aodesenvolvimento de software que, sendo um trabalho do conhecimento, não poderia seguiresse esquema. Por esse e outros motivos, a maioria dos softwares desenvolvidos não chegamnem a ser entregues, e quando atingem a conclusão tem grande probabilidade de falhar. Uma alternativa para o modelo em cascata é o desenvolvimento ágil de software, oqual trabalha baseado em equipes e iterações curtas. Ao fim de cada iteração é entregue aocliente um software pronto, funcionando, porém, apenas com uma parte de suasfuncionalidades implementadas. A equipe busca desenvolver segundo as prioridades docliente, agregando valor ao produto entregue. Uma das vantagens desse método é suafacilidade em se adaptar a mudanças e a facilidade quanto a manutenção. Os métodos dedesenvolvimento ágil têm características próprias que contribuem de forma eficaz para que odesenvolvimento seja ágil, com qualidade. Um dos métodos ágeis, o Extreme Programming, acontece com equipes pequenas emédias, trabalha com poucos requisitos e torna imprescindível a presença do cliente durantetodo o desenvolvimento. A programação é feita em pares e seu maior foco é a qualidade doproduto e do seu código de forma que ao final sua facilidade de ser adaptado a mudanças serásatisfatória. O Scrum, não está direcionado à criação o software propriamente, mas a gerenciar oprojeto e a equipe de forma que sejam rápidos e atinjam os seus objetivos. Essas metodologias de desenvolvimento podem dar crédito às equipes que trabalhamna criação de softwares, e apoiá-las para que atinjam as expectativas do cliente, possibilitandoque ele saiba o valor do desenvolvimento e tenha consciência de todas as funcionalidadesdesenvolvidas. O objetivo dessa monografia é apresentar uma combinação entre as principais práticasdesses dois modelos. Para isto, está organizada da seguinte maneira: Capítulo 2: Consiste em apresentar os principais modelos de processos de software daEngenharia de Software. Depois dessa apresentação, introduz o conceito de desenvolvimento
  14. 14. 13ágil, tal como descreve suas diferenças em relação às formas tradicionais de desenvolvimento,seus valores e importância para os negócios atualmente. • Capítulo 3: Apresenta o Extremming Programming, descrevendo todas as suas etapas, especificando suas funções de forma detalhada e como são desenvolvidas. • Capítulo 4: Como no capítulo anterior, porém, com o Scrum é apresentado todas as fases em como esse método funciona e detalhes que o compõe e o torna uma das metodologias mais usadas no mundo atual. Estuda uma seleção das fases mais importantes para unir o XP e o Scrum, tornando-se assim, uma maneira ainda melhor para o desenvolvimento de softwares. • Capítulo 5: Faz análise de um estudo de caso que demonstra as vantagens, desvantagens do uso de Scrum e XP na prática do dia-a-dia de uma empresa. Dessa forma, essas metodologias de desenvolvimento poderão dar crédito às equipesque trabalham na criação de softwares, atingindo todas as expectativas esperadas pelo cliente,possibilitando que ele saiba o valor do desenvolvimento, tenha consciência de todas asfuncionalidades desenvolvidas, com qualidade e de forma ágil.
  15. 15. 142 PROCESSOS DE SOFTWARE E DESENVOLVIMENTO ÁGIL Este capítulo apresenta o software, tal como seus processos e métodos dedesenvolvimento, a fim de apresentar o desenvolvimento ágil e seus métodos comocontribuintes de melhorias no desenvolvimento com o objetivo de alcançar umaprimoramento contínuo na criação de softwares. A Engenharia de Software visa sistematizar a produção, a manutenção, a evolução e a recuperação de produtos intensivos de software, de modo que ocorra dentro de prazos e custos estimados, com progresso controlado e utilizando princípios, métodos, tecnologia e processos em contínuo aprimoramento. (FIORINI, 1998 apud, REZENDE, 2005). A principal preocupação nessa atividade é desenvolver atingindo todos os objetivoscitados por Rezende, a realizar a produção de um software que cumpra todo o esperado pelocliente com qualidade de forma que seja adaptável a mudanças.2.1 PROCESSOS DE SOFTWARE Tonsig declara que a Engenharia de Software utiliza a Ciência da Computação eMatemática para atingir seus objetivos quanto às práticas de desenvolver software. É precisosaber sobre a necessidade do software para os negócios e a necessidade de sua flexibilidade amudanças contando com todas as mutações do mundo dos negócios. O software não é uma entidade corpórea, trata-se de uma entidade lógica e não física; portanto, não se desgasta, ou seja, pelo uso ou tempo não sofre nenhum tipo de corrosão decorrente de sua própria atividade. O usuário não vê um software em execução (tal qual não vê o movimento dos elétrons), mas poderá verificar ou sentir os efeitos da sua existência, além de poder enxergar e interagir com sua interface caso exista. (TONSIG, 2003, p. 54). Dessa forma, o software, resultado da engenharia, é o grande objetivo, com qualidade,eficiência e viabilidade. Segundo Tonsig (2003), “o software como um conjunto decomponentes abstratos encapsulados na forma de procedimentos, funções, módulos, objetos
  16. 16. 15ou agentes.” A partir disso, a principal função da engenharia é propor modelos e processosquais apresentem os melhores métodos e ferramentas para o planejamento e gerenciamentodos projetos de desenvolvimento de software. Segundo Pressman o processo é uma das camadas que formam a engenharia desoftware e é tido como apoio, alicerce. É o responsável pela união de todas as camadas datecnologia e favorece a criação eficiente e oportuna de softwares. Os processos de software formam a base para o controle gerencial de projetos de software e estabelecem o contexto no qual os métodos técnicos são aplicados, os produtos de trabalho (modelos, documentos, dados, relatórios, formulários etc.) são produzidos, os marcos são estabelecidos, a qualidade é assegurada e as modificações são adequadamente geridas. (PRESSMAN, 2006, p. 17). Assim, a Engenharia de software fornece métodos e ferramentas que auxiliam naprodução de softwares. Os métodos são definidos como técnicas para o desenvolvimento e asferramentas que definem a base de qualquer projeto de software. Um framework1 de processoé o esqueleto, o alicerce do projeto, onde é aplicada uma série de trabalhos co-relacionadosque tem como resultado um produto da engenharia de software. Nele existem algumasatividades que podem ser usadas na maioria dos projetos de softwares, são elas: - Comunicação: levantamento dos requisitos através de boa comunicação e cooperaçãocom os clientes. - Planejamento: Descrição das tarefas técnicas, cronograma de trabalho, riscos,recursos, e produtos finais. - Modelagem: Modelos que permitem ao cliente ter uma noção de como será osoftware, através disso os requisitos são reavaliados e são feitas as últimas alterações antes deimplementação (construção). - Construção: Manipulação dos códigos e revisão de erros. - Implantação: Entrega do produto, seja inteiro ou em partes (incremento), onde ocliente avalia e faz o feedback2 para que possa ser alterado e melhorado.1 FRAMEWORK: um framework ou arcabouço é uma abstração que une códigos comuns entre vários projetosde software provendo uma funcionalidade genérica. Um framework pode atingir uma funcionalidade específica,por configuração, durante a programação de uma aplicação. Ao contrário das bibliotecas, é o framework quemdita o fluxo de controle da aplicação, chamado de Inversão de Controle.2 FEEDBACK: é o procedimento que consiste no provimento de informação à uma pessoa sobre o desempenho,conduta ou eventualidade executada por ela e objetiva reprimir, reorientar e/ou estimular uma ou mais açõesdeterminadas, executadas anteriormente [
  17. 17. 16 Esses cinco tópicos são usados como base em qualquer projeto de software, visto deforma global têm-se a impressão de que a receita será a mesma, porém isso não acontece poiscada projeto tem características e detalhes próprios. A aplicação de modelos de processo tem como objetivo melhorar o gerenciamento e aqualidade dos projetos, isso é, estabelecer medidas como datas de entregas e previsão decustos de forma que não corra riscos e os custos da produção não sejam afetados. Segundo Pressman os modelos ágeis priorizam a gestão do desenvolvimento, seadéquam facilmente a vários tipos de projeto e são extremamente úteis à aplicações Web.Assim, esses projetos, seguindo seus princípios acontecem com uma abordagem maisinformal, porém, efetiva e busca obter maior agilidade em seus processos de forma a levarqualidade e satisfação ao cliente.2.1.1 Modelo Cascata Nesse modelo de desenvolvimento, a partir da análise de viabilidade do projeto aevolução se dá de forma seqüencial, ou seja, uma etapa por vez, em cascata. Esse modelo éinspirado nos modelos de produção industrial que é marcado por três princípios:determinismo, especialização e foco na execução. A Figura 1 mostra as sete etapas que formam o modelo em cascata: análise deviabilidade, análise de requisitos, projeto, implementação, testes, implantação e manutenção. Engenharia de Sistemas Análise Projeto Codificação Teste ManutençãoFonte: Livro Engenharia de Software. PRESSMAN, 1995. Figura 1 - Modelo Cascata - Ciclo de vida Clássico.
  18. 18. 17 Na avaliação de viabilidade de desenvolvimento parte-se de três pontos distintos parater garantia de que haverá recursos para o projeto. O primeiro avalia as condições dedesenvolvimento em hardware, software, licenças, banco de dados, entre outros. O segundo éverificar a viabilidade econômica através de uma análise e uma previsão de todos os custos doprojeto, de forma que em sua aprovação, seja possível cobrir todos os recursos dodesenvolvimento. Por fim, o terceiro é verificar a viabilidade operacional, onde é feita aprevisão de todas as alterações e adaptações necessárias ao projeto, como mudança emprocedimentos e choques à normalidade da empresa. A partir do momento em que o projeto é aprovado por sua viabilidade, é feita a análisede requisitos, que é uma avaliação que determina quais serão as necessidades dos processos einformações, de forma que sejam determinados quais serão as funções do software. Essa faseé feita em conjunto do cliente, pois o projeto deve atender todas as suas especificações. Inicia-se então a fase de projeto, na qual é desenvolvida a documentação do software,interfaces para os usuários, banco de dados, etc. Na fase seguinte, a implementação vai seguirtoda a documentação criada na fase anterior e codificar, realizando-se testes para verificar se oprojeto se comporta como o especificado. Esses testes são realizados individualmente e emconjunto, pois os erros podem ser revelados de diversas formas. A fase de implantação é a fase na qual o software está concluído e livre parautilização. Inicia-se com o treinamento dos usuários para que haja eficiência no seu uso, etodas as ferramentas implementadas estão à disposição. Enfim, a fase da manutenção, ocorreem todos os projetos de software, o usuário verifica erros ao longo do tempo, necessita denovas funcionalidades, ajustes requeridos pelos usuários, entre outros.2.1.2 Modelo Incremental É uma modificação do modelo em cascata dividindo-se a fase de projeto lógico efísico. A partir da divisão, esses projetos podem ser decompostos e executados paralelamente.
  19. 19. 18 Definir Atribuir Projetar esboço requisitos arquitetura dos aos do sistema requisitos incremento s Desenvolver Validar Integrar Validar incrementos incremento incremento Sistema do sistema Sistema Final Fonte: Livro Engenharia de Software. PRESSMAN, 2000. Figura 2 – Sistema Incremental. “O modelo incremental combina o modelo em cascata com um aplicação iterativa,porém, e oferece um produto operacional a cada incremento realizado. Tem como objetivodiminuir o trabalho no desenvolvimento e entregar um produto finalizado a cada incremento”(PFLEEGER, 2004). Na figura 2, o cliente resume suas especificações e demonstra sua prioridade ou partedos requisitos necessários. Dessa forma, a implementação é feita em iterações, cada iteração éentregue de forma que o cliente possa perceber novos requisitos ou alterar os existentes eestes possam ser implementados em novas iterações. O diferencial desse modelo dedesenvolvimento é que essas iterações devem ser feitas de forma que em cada entrega ocliente receba um aplicativo executável e livre para integração com outras iterações. Assim,enquanto o software é desenvolvido, o cliente tem a possibilidade de usar algumasfuncionalidades do sistema.2.1.3 Prototipação Este modelo faz com que o usuário tenha melhor compreensão do software epossibilite melhorias no tempo do desenvolvimento. O usuário pode ver como serão os
  20. 20. 19aspectos visuais do software e suas saídas devidas à interação e assim pode colaborar com odesenvolvimento conforme seu crescimento. Com isso, ele torna-se parte da equipe dedesenvolvimento, um colaborador e também um dos responsáveis do êxito do software. Para Tonsig (2003, p. 62), a prototipação é como um desenvolvimento de softwareque inicialmente cuida apenas das características de interface com o usuário, resguardandopara uma segunda etapa os demais procedimentos internos de checagem e manipulação dosdados. Isso acontece porque o usuário tem uma premissa das respostas de um software aindaque inacabado, é como um rascunho do que é esperado para o produto final, porém estásujeito a correções e modificações.RequisitosProjeto PROJETO CODIFICAÇÃO TESTE MANUTENÇÃOCodificaçãoTeste Protótipo Produto (manutenibilidade, qualidade)Análise derequisitos.Fonte: Livro Engenharia de Software. PRESSMAN, 1995. Figura 3 – Prototipação. Como pode-se observar na Figura 3, Pressman coloca que a Prototipação tem comoopção fazer parte do Modelo em Cascata, como uma forma de auxiliar a ligação entre clientee equipe de projeto em definições de requisitos. O desenvolvimento tem início com a coleta de dados que é usado como apoio nadefinição dos requisitos. Os primeiros objetivos a serem definidos são os objetivos globais, osquais levam em conta tudo que é indispensável para o projeto. A equipe desenvolve oprimeiro protótipo, o qual dará a oportunidade de ver como seria a interface do software, semqualidade, e que tenha como foco o objetivo global definido entre equipe e cliente. Após aavaliação de todos, deve-se determinar com maior sutileza os requisitos de forma queobtenham maior detalhamento.
  21. 21. 202.1.4 Modelo Espiral O modelo em Espiral foi desenvolvido por Berry Boehm, com o objetivo de atingirmelhorias quanto aos modelos anteriores. Trata-se de uma espiral, onde os trabalhosprincipais partem do centro, e conforme é executado o projeto percorre para o sentido de forada espiral.Fonte: Livro Engenharia de Software, PRESSMAN, 1995. Figura 4 – Modelo Espiral. Pressman (1995) divide o modelo em Espiral em quatro partes: - Planejamento: é a busca das definições de riscos, objetivos e restrições; - Análise de Riscos: busca-se como resolver os problemas e os melhores caminhospara alcançar os objetivos do software; - Engenharia é a parte de desenvolvimento do produto; - Avaliação pelo Usuário: é o resultado para o cliente, a avaliação do trabalho.
  22. 22. 212.2 PROCESSO UNIFICADO Através dos modelos de software convencionais o Processo Unificado seleciona suasmelhores ferramentas e modelos, de forma que possa implementar o desenvolvimento ágil desoftwares. Entre as décadas de 1980 e 1990, as metodologias e linguagens orientadas a objetosganharam impulso na engenharia de software. Em todas as inovações que chegaram juntocom a Engenharia de Software tanto em relação à AOO quanto POO, não houve concórdiaquanto aos métodos a serem utilizados. No início da década de 1990 James Rumbaugh, GradyBooch e Ivar Jacobson desenvolveram um “método unificado” (PRESSMAN, 2006, p. 52) oresultado desse trabalho foi a UML. Segundo Larman (2004, p. 34) “UML é uma linguagempara especificar, visualizar, construir e documentar os artefatos de sistemas de software, bemcomo para modelar negócios e outros sistemas que não sejam de software.” Para Neto (2008) “a UML foi projetada para auxiliar aqueles que participam daatividade de desenvolvimento de software a construir modelos que permitam visualizar osistema, especificar a estrutura, especificar o comportamento, construir o software edocumentar as decisões tomadas”. Através da UML pode-se ter acesso a diversas ferramentas no apoio à engenharia desoftware em OO, porém não tem o mesmo apoio quanto a equipes de aplicação da tecnologia.A partir disso Jacobson, Booch e Rumbaugh criaram o Processo Unificado (PU), passou a sero esqueleto, a armação por trás da engenharia de software orientada a objetos e que usa aUML. Larman (2004, p. 38) define o PU como “uma combinação das melhores práticas, taiscomo um ciclo de vida iterativo e o desenvolvimento orientado pelos riscos, em uma única ebem documentada descrição”. Neto (2008) explica que o PU encaixa-se na definição de processo: um conjunto deatividades executadas para transformar um conjunto de requisitos do cliente em um sistema desoftware. Para ele o PU também é uma estrutura genérica de processo que pode ser customizadoadicionando-se ou removendo-se atividades com base nas necessidades específicas e nosrecursos disponíveis para o projeto.
  23. 23. 22 A maior característica do PU é o desenvolvimento iterativo, que é marcado por aceitarmudanças e também por sua adaptabilidade. Nesse modelo deve-se dividir o projeto em váriosminiprojetos, os quais terão seu tempo de duração determinado e serão consideradas iterações,cada uma delas torna-se um projeto independente no qual há análise de requisitos, projeto,implementação e teste. Toda iteração resulta em um sistema finalizado, testado, integrado eexecutável. As iterações são rápidas, pois exigem apenas uma pequena quantidade de requisitos.No início as escolhas dos requisitos podem não parecer ao certo o esperado do processo,porém no PU, os projetos necessitam de um reabastecimento que é adquirido a partir dosusuários, desenvolvedores e testes. Portanto a idéia principal desse tipo de abordagem é aprogressão, mas não de forma que force o projeto a tomar novas direções e sim de forma queseja conseqüência do amadurecimento dos requisitos.Fonte: LARMAN, Craig; 2004. Figura 5- A realimentação e a adaptação iterativas levam ao sistema desejado. A instabilidade dos requisitos e do projeto diminuem com o tempo. O PU é dividido em quatro fases técnicas: - Concepção: geralmente o modelo de casos de uso é usado como ferramenta, é comosimulações do sistema por usuários que não tiveram contato algum com o software. Osresultados obtidos e a partir disso é definida uma série de condições e ações do software. Estafase tem como objetivo obter uma visão geral do projeto, definições sobre os riscos donegócio e do projeto e uma melhor definição dos requisitos.
  24. 24. 23 - Elaboração: nessa fase é desenvolvido o modelo de análise do PU. Funciona comoum aperfeiçoamento da AOO, uma análise de projeto. Ambas melhoram a evolução doprojeto de arquitetura do software, revisam os riscos e os requisitos do projeto de forma quetragam garantias à sua elaboração. A conseqüência desta fase é uma elaboração refinada dosrequisitos práticos e os que não foram compreendidos no modelo de casos de casos de uso. - Construção: são necessárias três ferramentas para a execução dessa fase. Através deum modelo de implementação é adquirida a manifestação das classes do projeto que passam aser transformada para finalizar o sistema. O modelo de implantação organiza todos oscomponentes para o ambiente físico de computação. O modelo de teste transmite osresultados dos testes e garantem sua eficácia no projeto criado. - Transição: é a finalização de um incremento, ou seja, como o PU divide um projeto ediversas partes, e cada uma é integrada a um sistema final, é realizado o feedback paraalterações e melhorias na qualidade do projeto.Fonte: LARMAN, Craig, 2004. Figura 6- Termos relativos ao cronograma em PU. As descrições de cada ocupação no PU são conhecidas como disciplinas, elasdemonstram como elaborar ou executar uma determinada atividade de forma que esta estejaorganizada, até que alcance ao longo das iterações o seu ideal. O enfoque passa a ser diferentecom o tempo, a princípio é maior, até que o projeto esteja estável por conseqüência darealimentação e os requisitos melhor atendidos.
  25. 25. 24 As ações e ferramentas no PU são opcionais, devem ser vistos como um tipo decomplemento, aos quais de acordo com a necessidade do projeto são usados como solução.Porém, algumas práticas e regras são constantes, pode-se citar o desenvolvimento iterativo eorientado ao controle de riscos e a variação contínua da qualidade. Entre alguns conflitos surge o PU ágil, tratam-se também alguns métodos ágeis comoos processos pesados e preditivos. O primeiro trata quando um projeto engloba muitosdetalhes no planejamento, preparação e necessita de longo prazo, sem flexibilidade econtrolável e que não aceite mudanças, seja definitivo. Os processos preditivos projetam esupõem como será o projeto e como serão usados os recursos com antecedência. Tem umciclo de vida em cascata ou seqüencial, definem-se todos os requisitos, um projeto minuciosoe por fim faz-se a implementação. Quando o PU foi criado não houve intenção alguma de usarprocessos como os pesados e preditivos, ele foi feito para ser usado em um processo ágil quetem como objetivo ser leve e adaptável, fácil de estabelecer mudanças, e obter resultados.Fonte: Larman, Craig, 2004. Figura 7 – Disciplinas do PU.
  26. 26. 252.2.1 Rational Unified Process O RUP (Rational Unified Process), é uma estrutura condensada para os processos decriação de software. Como o PU tem fortes características do desenvolvimento em espiral,pelo seu processo iterativo e utiliza a UML (Unified Modeling Language), para o projeto edocumentação. Tem como objetivo inicial demonstrar a estrutura do sistema, com sua arquitetura efuncionalidade, de forma que essa união resulta no sucesso na entrega do produto. É divididoem trinta e nove papéis que ajudam na personalização do software, cada membro da equipeincorpora vários papéis, não é obrigatória a utilização de todos. Aquele que assume um papelé responsável pelo seu cumprimento. Como na figura 7, seu ciclo é muito parecido com o formato do PU, é formado porquatro fases essenciais: - Iniciação; - Elaboração; - Construção; - Transição. Algumas de suas principais características são marcadas pelo desenvolvimentoiterativo, pela sua forma de administrar os requisitos, modelagem visual, qualidade efacilidade a modificações.2.3 DESENVOLVIMENTO ÁGIL Qual a importância em ser ágil ao fabricar softwares para o mercado e empresas dedesenvolvimento? Segundo Bueno (2008) ágil é o mesmo que ligeiro, leve, rápido. Sabe-seque o mercado está em constante mudança, e é necessário tomar determinadas medidas paraacompanhar e suprir todas as suas necessidades. Em meio ao desenvolvimento atual de software a palavra ágil tem sido sinônimo demodificações, essas que estão presentes nos requisitos para o desenvolvimento, produção de
  27. 27. 26software, equipes de desenvolvimento, adaptações às novas tecnologias e orientações domercado, etc. Pressman (2006) ainda acrescenta à agilidade significados que levam à melhorcomunicação entre todos que interagem na produção e clientes que são inseridos na equipe dedesenvolvimento e que retornam o feedback de forma instantânea aos desenvolvedores,enfim, à entrega mais rápida do software. Teles (2006) atribui o termo “Desenvolvimento Tradicional” aos modelos dedesenvolvimento em cascata que ainda são os mais usados atualmente. Como foi citado nocapítulo anterior, esse modelo é a produção de softwares de forma seqüencial, ou seja, seudesenvolvimento se dá de forma que suas etapas acontecem sucessivamente, onde uma utilizao resultado da anterior. Critica ainda esse modelo por ser extremamente falho e ter um altoíndice de fracassos e produtos que não atendem o especificado na análise de requisitos, comomostra o gráfico: Tipo 1 Tipo 3 16% 31% Tipo 1 Tipo 2 Tipo 3 Tipo 2 53%Fonte: TELES, 2006.Figura 8 – Tipos de Conclusão de Projetos. Pesquisa do Standish Group sobre a conclusão de projetos de software (1994). - Tipo 1 ou Projeto bem sucedido: aquele que atende todas as expectativas, comotempo, custo e todas as funcionalidades especificadas funcionando. - Tipo 2 ou Projeto desafiado: onde há entrega do software, porém, não comocombinado anteriormente, ultrapassa o prazo e orçamento, além de não cumprir com todas asfuncionalidades especificadas no início do projeto. - Tipo 3 ou Projeto fracassado: quando o projeto é cancelado durante odesenvolvimento. Teles (2006) aponta que em um novo estudo com dados do ano de 2002, o StandishGroup apontou avanços quanto à conclusão de projetos. A taxa de sucesso passou de 16,2%
  28. 28. 27para 24%, os fracassados de 31,1% para 15% e os desafiados praticamente mantiveram seuíndice por volta dos 51%. Sendo que a maioria dos projetos pesquisados são dodesenvolvimento tradicional que confirma numericamente sobre as falhas do modelo emcascata. Toda a evolução do desenvolvimento tradicional junto ao modelo em cascatacomprova a sua ineficácia. Teles utiliza das teorias de Drucker para explicar as duascategorias de trabalho: trabalho manual e trabalho do conhecimento e coloca odesenvolvimento de software na segunda categoria, como especifica nesse trecho: O desenvolvimento de software é um trabalho executado basicamente por trabalhadores do conhecimento. Entretanto, as premissas em que se baseiam o desenvolvimento tradicional somente são válidas para o trabalho manual. Logo existe um problema: o desenvolvimento tradicional se baseia em premissas que não são válidas para o tipo de trabalho que ele envolve. (TELES, 2006, p. 38). Teles (2006), ainda coloca em foco que o desenvolvimento tradicional tem trêscaracterísticas que segundo Taylor regem a fábrica: determinismo, especialização e foco naexecução. Ele parte do princípio de que esse tipo de desenvolvimento é seqüencial, ou seja,segue todas etapas de forma linear. Assim, o determinismo trata as transformações dasmatérias-primas, a especialização é a divisão do processo de fabricação e por fim agrupandoas duas anteriores têm-se o foco na execução. Não existe criatividade nesse processo defabricação, ele existe e o trabalhador a executa, como em uma máquina onde ele é apenas umapeça. O determinismo é importante no desenvolvimento tradicional de forma que diminui asfalhas e excesso de tempo, a especialização realiza a divisão de papéis à equipe e, portanto,com os dois anteriores, possibilita exclusivamente o foco na execução das tarefas pelosdesenvolvedores. O Desenvolvimento Ágil é uma alusão ao processo em espiral, uma forma dedesenvolvimento iterativo, onde cada fase é executada diversas vezes. Cada iteração temcomo objetivo um software concluído, pronto para o uso, porém, com menos funcionalidades,dado que no desenvolvimento ágil o projeto é dividido em várias iterações, onde sãoespecificadas algumas funções a ser desenvolvidas e ao final de todas as iterações tem-se umsoftware completo que atenda ao máximo possível as exigências do cliente sem que tenhapassado os limites de tempo e orçamento. Ser incremental é uma das maiores características desse modo de desenvolvimento, deforma que toda a equipe é integrada à criação do projeto e fases do desenvolvimento que
  29. 29. 28acontecem ao mesmo tempo. O cliente participa da criação do sistema e aprende com ele,descobre todos os procedimentos técnicos, dá soluções de determinados problemas à equipe,requisita alterações ao longo do projeto e também recebe idéias de funcionalidades parasolucionar seus problemas pela equipe. O desenvolvimento ágil foi criado com a expectativa de eliminar os problemas daEngenharia de Software tradicional, ele fornece diversos benefícios e tem como objetivo oproduto final em um período abaixo do estimado no desenvolvimento tradicional e qualidadede forma que atenda aos requisitos esperados pela empresa. Em 2001, Kent Benck junto a uma equipe onde outros 16 desenvolvedores, produtorese consultores de software assinaram o Manifesto Ágil que leva a, seguinte declaração: Estamos descobrindo melhores maneiras de desenvolvimento de software fazendo- o e ajudando outros a fazê-lo. Por meio desse trabalho passamos a valorizar: - Indivíduos e iterações em vez de processos e ferramentas. - Software funcionando em vez de documentação abrangente. - Colaboração do cliente em vez de negociação dos contratos. - Resposta a modificações em vez de seguir plano. Isto é, ainda que haja valor nos itens à direita, valorizamos mais os itens à esquerda. (Beck et al, 2009). No desenvolvimento ágil, o processo de software deve ter quatro valores fundamentaisque determina e contribui de forma eficiente ao sucesso na conclusão de um projeto. A primeira é o feedback, ao tratar esse elemento deve-se usar o termo realimentação,essa palavra é pela resposta do cliente ao desenvolvimento fazendo com que a equipe melhoresempre a cada iteração e o contrário também deve acontecer quando a equipe dá novas opçõesem funcionalidades no software de forma que dê melhorias aos processos de controle daempresa. A segunda é a comunicação, a responsável por gerar o feedback, o processo ágil tem aparticipação contínua do cliente junto à equipe, isso nem sempre acontece pelos clientes nãoconseguirem dispor de tempo para participar do desenvolvimento, porém, caso isso aconteçadeve-se negociar ao menos um período diário ou mesmo que a equipe se desloque até ocliente. É importante que dividam o mesmo espaço, assim, acontece a troca de informaçõesem tirar a dúvida de ambos quanto ao projeto e funcionalidades, além da comunicaçãoindireta como conversas paralelas que também podem auxiliar em obter novas idéias emelhorias no desenvolvimento. A terceira é ser simples, é necessário apenas que a equipe desenvolva o que o clientenecessita, não é preciso que o desenvolvimento seja embasado por teorias futuras de
  30. 30. 29funcionalidades que não estão inclusas no projeto, ou seja, a equipe não deve assumirpossibilidades incertas, e todas as dúvidas devem acabar através do cliente. Caso isso não sejapossível, ele assume a forma mais razoável para implementar o software. Teles especifica quea idéia da simplicidade é evitar o trabalho dispensável, de forma que possa enxugar o tempode desenvolvimento e o custo do produto com teorias incertas, assim pode-se dizer que nodesenvolvimento pode-se exercer trabalhos incorretos e incabíveis de forma que trás a soluçãoem simplificar e eliminar tarefas desnecessárias à produção ágil. A quarta e última característica necessária a esse tipo de desenvolvimento, ouprodução de software é a coragem, a diferença entre os processos tradicional e ágil são bemconsideráveis, portanto, é necessária que haja coragem para promover o desenvolvimento ágilno ambiente de produção de software.
  31. 31. 303 EXTREME PROGRAMMING (XP) Segundo Teles (2006), o XP é um método de desenvolvimento de software que éfocado em mudanças constantes em projetos com poucos requisitos especificados, orientaçãoa objeto, equipes de até doze integrantes e por fim, o desenvolvimento iterativo. O XP é um processo de desenvolvimento que busca assegurar que o cliente receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno de um conjunto de valores e práticas que atuam de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software. (TELES, 2006, p. 21). Como citado no capítulo anterior o XP é embasado nos quatro valores dodesenvolvimento ágil de software, feedback, comunicação, simplicidade e coragem. Ofeedback é a realimentação tanto da equipe que o desenvolve, quanto o cliente que ampliaseus conceitos quanto às funcionalidades necessárias e participa na melhoria do projeto.Comunicação tem sua essência nessa forma de desenvolver a fim de atender o software comexclusividade, assim pode resolver seus problemas e propor melhorias de forma ágil. Sersimples é seguir somente a direção especificada no projeto. E por fim a coragem, que éenfrentar todos os desafios para implementar as etapas do desenvolvimento ágil, de forma queseja segura em garantir sua qualidade com segurança e agilidade.3.1 CLIENTE PRESENTE No desenvolvimento em cascata o cliente participa da análise de requisitos de formaque especifica todas as funcionalidades necessárias ao software, na maioria das vezes não éeficaz e muito menos eficiente, pois, ele não compreende toda extensão das funcionalidades.É preciso que o cliente participe do projeto contribuindo pela realização dos valores do XP,como a simplicidade, de forma que o andamento do projeto seja marcado com pequenosajustes para sua melhoria e evitar grandes mudanças ao longo do desenvolvimento, assim, elepode contribuir de forma eficaz para o sucesso do projeto.
  32. 32. 31 Essa fase é de suma importância, a partir de sua excelência pode-se atingir o seusucesso. A comunicação direta e indireta no ambiente de desenvolvimento entre equipe ecliente, pode levar a ajustes, adaptações e inovações que são fundamentais em um processoágil. O projeto é dividido em diversas estórias3, elas são características breves defuncionalidades do projeto descritas em cartões. A partir disso, a comunicação passa a seressencial, cliente e desenvolvedor destacam os detalhes da estória de forma que possam terpontos de vista abrangentes e assim determinar as melhores formas de desenvolvimento. Existem diversas formas para que o cliente possa contribuir para que o projeto sejamais ágil, a primeira ao esclarecer a estória a ser implementada, a segunda se dá com osurgimento de dúvidas durante a implementação da funcionalidade e a terceira ao contribuirque o desenvolvedor não inclua premissas em seu trabalho, de forma que possa levar o projetoa mudar seu foco e perder tempo. Existem outros motivos para a participação do cliente, comoo surgimento de idéias e dúvidas em uma comunicação paralela e também ao finalizar odesenvolvimento de uma funcionalidade o cliente poderá ver se é a forma esperada ou se hánecessidade de mudanças. Com a presença do cliente no desenvolvimento do sistema há o favorecimento darealimentação, ou seja, o feedback é executado de forma que a equipe terá todas asinformações necessárias sobre as principais iterações e o esperado pelo cliente, poderámostrar ao cliente soluções e problemas não especificados anteriormente, e por outro lado eletambém saberá o quanto estará pagando por cada parte do sistema a ser implementada, pois osoftware não pode ser manipulado, de forma que é mais difícil saber seu valor real. Através daconfiança entre as duas partes na participação contínua do cliente no desenvolvimento, eleterá a percepção do custo e tempo de desenvolvimento, de forma que entenderá o valor a serpago pelo produto, ou seja, pelo tempo gasto no desenvolvimento, por conhecimentoacrescido ao sistema e pelo trabalho da equipe. Nessa fase Teles (2006), aponta como maior dificuldade um cliente realmentedisponível para participar do projeto, porém ele pode ser muito atarefado de forma que nãopossa estar integrado ao desenvolvimento. Para resolver isso ele coloca duas situações: ocliente presente e o cliente totalmente afastado, mas o segundo não garante em nada o projetode forma que no mínimo se possa obter um cliente que saiba dividir suas tarefas com a suapresença no projeto, e caso isso não possa acontecer, a equipe também pode se deslocar até o3 ESTÓRIA: são cartões contendo as descrições das funcionalidades a ser implementadas no projeto.
  33. 33. 32local de trabalho do cliente, de forma que possam dividir o mesmo ambiente e assim, garantira qualidade e agilidade do processo. No desenvolvimento do sistema o cliente poderá concluirseus afazeres, a diferença é que vão dividir a mesma sala, e assim, podem trocar todas asinformações necessárias, isso pode ser considerado como um detector de erros, onde o clienteirá informar a equipe o caminho certo em todas as dúvidas, e ambos terão conversas informaisde forma que terão a chance de criar novas idéias e terem um melhor ponto de vista emrelação ao sistema como um todo, ou mesmo de uma determinada funcionalidade, a esta salaonde cliente e equipe de desenvolvedores dividem o mesmo espaço dá-se o nome de sala deguerra. Quando não se pode ter a presença contínua do cliente no projeto o ideal é criar umaagenda, onde cliente e equipe devem se encontrar algumas vezes ao longo do dia, dessa formaeles não irão dividir o mesmo espaço perdendo a comunicação informal e a resolução dasdúvidas de forma mais rápida, porém ainda existe um bom nível de confiança, comunicação,feedback e o cliente pode continuar suas obrigações normalmente. Outra situação é quando ocliente não pode acolher a equipe por falta de espaço, a solução é que a equipe se instale emum lugar próximo ao cliente para que possam se encontrar algumas vezes no dia. Caso aempresa possa acolher a equipe o cliente ou seu representante deve ser deslocado para a salaem que a equipe irá trabalhar. Sem a presença do cliente perde-se a confiança no projeto e o feedback e arealimentação também são extintos, pode-se saber a principal causa através de DeMarco: Trata-se de um problema central: o afastamento entre cliente e equipe é uma das causas essenciais dos fracassos nas iniciativas de software. Os grandes problemas desta indústria são sobretudo sociais e pouco tem a ver com a tecnologia (DeMarco, 1987, p.4). Não são questões técnicas, mas sim reflexos das estruturas e dos relacionamentos humanos envolvidos no projeto. (DEMARCO, 1987 apud TELES, 2006). É necessário criar uma reorganização dos processos e incluir o cliente de forma que oobjetivo seja alcançado de forma eficaz. Ao desenvolver o XP, o primeiro desafio requerido éa inclusão do cliente no ambiente de desenvolvimento, esta ferramenta deve ser muito bemusada, de forma corajosa, para que o projeto obtenha sucesso. É preciso também mudar adivisão de responsabilidades, onde o cliente paga e os fins alcançados em um sistema sãointeiramente responsabilidade da equipe de desenvolvimento. A participação do cliente emum sistema é de suma importância, pois, por ele não ter todo o conhecimento técnico em
  34. 34. 33relação ao desenvolvimento de software não poderá especificar todas as funcionalidadesesperadas em uma análise de requisitos.3.2 JOGO DO PLANEJAMENTO3.2.1 Responsabilidades A fase do jogo do planejamento, segundo Teles, é usado no XP de forma que osdesenvolvedores estejam sempre implementando as prioridades dos clientes, ela acontece aolongo de todo o projeto, de forma que qualquer alteração no percurso esteja dentro doplanejamento feito pela equipe. A divisão das responsabilidades se dá na divisão dos papéis, onde negócios sãodirigidos ao cliente e a questão técnica é incorporada pela equipe. Com base nessa divisãotêm-se o direito de cada parte. São direitos do cliente: - Ter um plano geral com informações sobre possibilidades, tempo e preço; - Receber todo o valor do trabalho semanal da equipe; - Acompanhar o desenvolvimento do projeto com um sistema executável, pronto parao uso, que passe nos testes especificados pelo cliente; - Mudar os requisitos e funcionalidades, sem ter que pagar um preço muito alto; - Se informados sobre mudanças no projeto de forma que possa decidir manter oescopo ou alterá-lo para cumprir o tempo determinado. Cancelar o projeto e ficar com osistema desenvolvido e investido até a data do cancelamento. E direitos da equipe: - Saber as necessidades e prioridades do cliente quanto ao sistema; - Trabalhar de forma que o resultado seja de qualidade permanente; - Pedir ajuda a colegas e cliente; - Criar e atualizar as expectativas; - Escolher a estória a ser desenvolvida sem imposição.
  35. 35. 34 A estória é um pequeno cartão, funciona na verdade como um convite a uma conversaonde cliente e desenvolvedor poderão entrar num consenso sobre a funcionalidade a serdesenvolvida, ela deve ser escrita pelo cliente em poucas palavras de maneira que especifiquea funcionalidade da forma mais simples possível, transmitindo apenas o que é esperado.Assim ele terá de raciocinar sobre o que estará escrevendo e terá uma melhor amplitude doque deseja. Para Teles (2006), existe um vínculo psicológico entre o cliente e a estória por váriosfatores como o fato de que o cliente é responsável pelo que é requisitado no cartão, para que ocliente possa entender o valor de cada especificação feita, fazendo assim que ele possademonstrar suas prioridades de acordo com o custo de cada funcionalidade solicitada. Este émais um fator que reforça o item anterior, cliente presente, por ele ter consciência do custo deum projeto de software. Geralmente o desenvolvedor escolhe a estória que deseja implementar, estasgeralmente tem a duração de um dia. De acordo com o tamanho do projeto, essas estóriaspodem ser transformadas em tarefas, em outros cartões para ser desenvolvidos por todos osdesenvolvedores como estórias e a duração podem variar em um tempo maior.3.2.2 Estimativas de Estórias “O XP utiliza o conceito de dia ideal de desenvolvimento, que representa um dia noqual o desenvolvedor só trabalha na implementação de funcionalidades, sem ter que sepreocupar com nenhuma atividade extra.” (TELES, 2006, p. 73). O valor do projeto depende das estimativas feitas em cada estória, elas são medidasatravés do tempo que cada desenvolvedor irá consumir em sua produção. Assim pode-se dizerque no XP todas as estimativas são feitas com base do dia ideal, cabe ao desenvolvedor saberquanto tempo irá usar para implementar uma funcionalidade sem ser interrompido portelefone, reuniões, etc. Cada dia ideal de desenvolvimento para dois programadores é considerado um ponto,pode-se usar outro significado a ele de acordo com o projeto, mas no XP o usual é esse. Serádemonstrado nas próximas etapas que nessa forma de desenvolvimento costuma-se usar a
  36. 36. 35programação em par. Esses pontos são registrados na estória de forma que possa fazer comque o cliente saiba o quanto estará pagando por cada funcionalidade. As estimativas devem ser feitas por comparação, em equipe e cliente reunidos, usandoestimativas realizadas no passado e que sejam parecidas de forma que possam chegar o maispróximo possível da quantidade de pontos realmente usada no desenvolvimento e com apresença do cliente de forma que seja feita com todo o esclarecimento possível e cuidandopara que ele não force diminuir o tempo estimado (cliente), o mínimo de sentimentos possívele o máximo de conhecimento técnico possível (equipe).3.2.3 Releases Como visto anteriormente, o desenvolvimento ágil acontece de forma incremental,sendo que cada incremento é entregue um sistema pronto, executável, porém com menosfuncionalidades. No XP um release é um grupo de funcionalidades que tem um valordeterminado para o cliente, geralmente são pequenos de forma que o cliente tenha acesso àssuas funcionalidades o mais rápido possível. Segundo Teles (2006), no início de um projeto em XP, cliente e equipe devem dividiro projeto em releases, pequenos e parecidos, devem priorizar quais levam mais valor aocliente e após essa divisão, as estórias são distribuídas entre eles. As estórias são desenvolvidas ao longo do projeto, após utilizar o sistema criado noprimeiro release, o cliente terá uma noção melhor em como o sistema e seu desenvolvimentoacontece e poderá melhorar as futuras estórias. Porém, é indicado ao cliente que se preocupeapenas com a estória que está sendo usada e conforme o avanço do projeto ele irá identificarnovas estórias necessárias ao seu sistema. Durante todo o projeto ele poderá criar novas estórias conforme identifique novasprioridades e também remover aquelas que não serão mais necessárias. Isso se dá pelo seuaprendizado com o avanço do projeto, assim, poderá identificar melhor suas necessidades etambém receber indicações por parte da equipe para melhorias do sistema. O fim de um release acontece com a conclusão de todas as iterações determinadas aela, seguido da implantação do sistema desenvolvido para o cliente, e por fim, há o feedback,
  37. 37. 36de forma que haverá realimentação de informações para a equipe e assim, nos releasesseguintes haverá maior possibilidade de que a equipe possa suprir as necessidades do cliente.3.2.4 Iterações “Um release, mesmo que seja pequeno, representa um tempo muito longo para odesenvolvimento em XP. Por essa razão, cada release é dividido em unidades de tempomenores, conhecidas como iteração.” (TELES, 2006, p. 79). Para ele, a iteração é uma parte de um release, um pequeno prazo dedicado aodesenvolvimento de um grupo de estórias. O prazo médio de um release são duas semanas deforma que contribua com o feedback e obtenha aprendizagem necessária. A reunião de planejamento de iteração faz uma estimativa de tempo através dos pontosdas estórias conhecida como velocidade da iteração, determinar a quantidade de pontos queserão desenvolvidos pela equipe. O cálculo feito para saber quantos pontos serão implementados em uma iteração poruma determinada equipe é o seguinte forma, faz-se o cálculo do número de dias úteis, subtrai-se dois dias para reuniões de planejamento e encerramento da iteração, multiplica-se pelonúmero de desenvolvedores e por fim divide-se por dois, pois o XP é marcado pelodesenvolvimento em par, assim, é obtido o número de pontos necessários para criar umaiteração. “Em inglês, costuma-se usar o termo yesterday’s weather (o tempo do dia anterior)para nomear a estratégia usada pelo XP.” (TELES, 2006, p. 82). Sua função é prever aquantidade de pontos que a equipe suporta implementar, a partir disso esses pontos sãooferecidos ao cliente para que ele selecione de acordo com sua prioridade quais iteraçõesserão desenvolvidas. Essa previsão é feita com base no que foi implementado na últimaiteração, assim, os pontos são somados e dispostos ao cliente, quando a equipe ultrapassa ospontos no desenvolvimento ou não consegue cumpri-los a previsão é atualizada sempre combase na última iteração. Todavia não é aconselhável abrir exceções ao cliente, de maneira queele possa tentar levar os desenvolvedores a sempre aumentar os pontos para odesenvolvimento, isso pode gerar conflitos entre equipe e cliente por muitas vezes não
  38. 38. 37conseguir cumprir esses pontos no desenvolvimento, assim a preferência é que a equipeentregue sempre os pontos que suporta desenvolver. O indicado no XP é que a equipe siga a ordem de desenvolvimento desejada pelocliente, dessa maneira ele ficará satisfeito gerando mais valor ao desenvolvimento. Para isso aequipe precisa contar com sua criatividade e empenho para solucionar os problemas e atenderas prioridades do cliente. Quando não há sucesso em resolvê-los, a equipe precisa tornarexplícito ao cliente os motivos e criar uma nova ordem para seguir o desenvolvimento. Uma das maiores vantagens do XP é que o cliente pode estar sempre realizandomudanças nos releases, estórias, prioridades, ao pedir novas ou excluir funcionalidades, etc.Entretanto, não poderá pedir alterações em uma iteração, deverá esperar o fim de forma quenão atrapalhe o trabalho da equipe e o desenvolvimento deixa de ser ágil. O fim de uma iteração é marcado por uma reunião onde as funcionalidades sãotestadas no sistema e também de testes para verificar se o desenvolvimento cumpriu com daestória onde é verificado se foi realizado todo o trabalho corretamente.3.3 STAND UP MEETING Reunião em pé é uma das características do XP, onde, todos os dias, toda a equipe fazum reunião de aproximadamente dez minutos e relata todo o desenvolvimento do dia anterior,é destacado todos os desafios e como foram resolvidos, assim, pode-se ajudar aqueles quetenham problemas semelhantes, fazem avaliação e faz com que a equipe esteja ciente doandamento do trabalho. Também é definido nessa reunião como será o andamento do diacorrente, onde a equipe prioriza os cartões a ser desenvolvidos, de forma que evite os errosanalisados do dia anterior e garanta o resultado com qualidade e agilidade. Todos devemparticipar de forma ativa da reunião, mesmo que tenha pouco tempo para expor seu trabalho,idéias e problemas. Desta forma o que seria dúvida de uma parte do sistema, ou umdesenvolvedor, torna-se solução para o todo, ou seja, a equipe.
  39. 39. 383.4 PROGRAMAÇÃO EM PAR A programação em par, ou em inglês, pair programming, trás consigo várias soluçõespara tornar o desenvolvimento realmente ágil, pois reúne ao trabalho dos desenvolvedores oacúmulo de experiências de forma que eles encontrem soluções rápidas, criativas e simples etambém podem corrigir os pequenos erros de programação quase que instantaneamente. A programação em par pressupõe uma comunicação contínua entre os desenvolvedores que formam o par. Através da conversa, eles discutem as melhores alternativas, corrigem erros, analisam cenários, enfim, discutem as melhores idéias para a resolução de cada problema. Portanto, é absolutamente incorreto acreditar que um trabalha enquanto o outro fica parado. Ambos estão trabalhando o tempo todo. (TELES, 2006, p. 91) Portanto, dois programadores desenvolvem suas atividades em conjunto e em umamáquina, geralmente um trabalha com o teclado, segundo Teles este é conhecido como“condutor” e o outro é o “navegador”, é como um estrategista para melhorar odesenvolvimento acompanhando o trabalho do condutor. Teles (2006) ainda coloca que não existem muitos estudos dirigidos à produtividadeem equipes que desenvolvem em par e aquelas que o fazem individualmente, porém destacaalgumas vantagens que em um projeto maior podem ser claramente explícitas: o códigopraticamente não apresenta problemas, pois durante sua elaboração é imediatamente revisadoe os problemas são resolvidos de forma mais simples, isso melhora sua manutebilidade. Apesar de expor essas duas vantagens, em um ponto de vista mais amplo pode-seperceber que a maior melhoria nesse procedimento é a agilidade. Pois, evita a perda de tempocom revisões e simplicidade do código. Durante a implementação muitos se deparam com diversas distrações, a programaçãoem par contribui em criar uma determinada pressão para que isso não ocorra, ela é chamadano XP de pair pressure, ou pressão do par. Assim, um sempre irá cobrar o outro de forma queo foco não seja perdido. As trocas de par e de funções são de extrema importância no XP, a cada iteraçãodevem-se trocar os pares, para que não se torne um círculo vicioso podendo trazer danos aotrabalho. Em relação às funções, os pares devem revezar durante o dia as funções de condutore navegador, mas essa troca deve ser natural, deve ser decidida pelo cansaço de digitar, oumesmo por não agüentar ficar sem fazer nada, entre outros motivos.
  40. 40. 39 Existem alguns desafio quanto essa prática, o escritório deve ser adaptado a doisusuários por computador, o gerenciamento da equipe deve deixar de lado as práticasindustriais, os desenvolvedores devem ser seguros e abertos ao aprendizado e não pode havercompetição entre a dupla, para que o ambiente possa ser de complementação de experiênciase conhecimentos técnicos e assim, atingir os objetivos esperados.3.5 REFACTORING O refactoring tem o objetivo de dar maior legibilidade ao código, assim faz com que asua leitura seja mais rápida, contribui caso haja necessidade de futuras modificações nosistema e também melhor manutebilidade. Teles (2006), destaca que é uma forma de modificar o código, sem mudar o que éimplementado. Faz o uso de testes para que sua manipulação não condene os seus resultados. Como visto anteriormente, umas das principais vantagens do desenvolvimento ágil é afacilidade de modificar, incluir ou excluir uma funcionalidade, o refactoring contribui tambémcom possíveis manutenções, de forma a garantir a compreensão do código diminuindo as suasbarreiras para a manutenção. O refactoring torna possíveis os objetivos do desenvolvimento ágil, ele não podeexistir sem essa fase, possibilita as modificações e criação de novas funcionalidades. Levarisco a falhas por alterações nos códigos, porém, tem como solução os testes, que torna essafase segura a garantir todas as expectativas da equipe e cliente.3.6 DESENVOLVIMENTO GUIADO PELOS TESTES A programação guiada por testes tem por principal objetivo diminuir o tempo dedepuração de um projeto. Relata as falhas de desenvolvimento à equipe, contribuindo deforma ágil para a resolução dos problemas.
  41. 41. 40 Os principais testes usados são determinados por Beck (2000), da seguinte maneira: - Teste de unidade: analisa os resultados das funcionalidades para verificar se estãocorretos. São usados quando não houver clareza na interface, detectar situações incomuns,detectar e isolar erros de código. Seu objetivo é contribuir com o refactoring e tornar o códigoclaro e sem erros. - Teste de aceitação: torna seguro o funcionamento correto do sistema, analisa orelacionamento das estórias. Acontece como um simulador do sistema e a partir do resultadofaz a comparação com o esperado. O teste desenvolvido pelo cliente, a partir disso, emboraseja grande a dificuldade, esses testes devem gradualmente ser automatizados no sistema.3.7 CÓDIGO COLETIVO O código coletivo é extremamente ligado ao refactoring e ao desenvolvimento guiadopelos testes. Para executá-lo é necessário que o desenvolvedor tenha coragem quandoprograma pois seu código poderá ser alterado por outros programadores e ao alterar umcódigo já desenvolvido de forma que deverá garantir a continuidade do funcionamento docódigo. Essa fase também garante a agilidade no desenvolvimento. No XP, não existe divisãode trabalho, todos trabalham no código e todos podem alterá-lo sem problema algum. O maiorbenefício atingido nessa fase é a revisão de código, ou seja, mais uma aplicação derefactoring.3.8 CÓDIGO PRADRONIZADO O código é uma das melhores formas de comunicação em uma equipe dedesenvolvimento. Isso é alcançado através do código padronizado.
  42. 42. 41 Cada programador tem uma forma diferente de desenvolver o código, através dessasdiferenças torna-se um tanto complicada essa forma de comunicação, pois o código pode ficarilegível. Assim, é indicado que a equipe tenha um padrão de codificação, esse padrão permiteque a equipe tenha mais facilidade ao ler o código sem preocupação em ter de decifrar ocódigo alheio. Dessa forma, o indicado é que a equipe adote um padrão ao iniciar o projeto, podehaver diversas dificuldades quanto a conseguir chegar a um padrão, porém, a equipe devechegar a um consenso.3.9 DESIGN SIMPLES No XP, é determinado que a equipe assuma o design mais simples possível e que façauma funcionalidade passar nos testes criados para a mesma. No desenvolvimento tradicional, ao surgir problemas em um software desenvolvido, ocusto para manutenção e alterações cresce exponencialmente com o tempo. Assim, a equipebusca criar soluções genéricas para não levar o software a ter problemas maiores com asmudanças. Existe uma certa incapacidade ao lidar com mudanças nesse modo dedesenvolvimento. No XP, o princípio do custo com alterações é um tanto diferente do desenvolvimentotradicional. O custo cresce em menor proporção e ao longo do tempo chega a ser praticamentelinear ao custo do desenvolvimento do software Ao longo das iterações, o design evolui, sempre com simplicidade de forma que aequipe possa fazer alterações no software a qualquer momento, com facilidade. Por estarazão, o refactoring tem um papel fundamental no design do XP.
  43. 43. 423.10 METÁFORA O XP utiliza a metáfora para demonstrar o que se passa no projeto. É uma forma deentender os problemas de forma mais consciente, até mesmo quanto a seus resultados. Dessaforma equipe e cliente terão maior ciência dos objetivos do sistema e poderão melhorar suacomunicação. Teles (2006), aponta a metáfora, como um relacionamento entre as coisas maisabsurdas ao seu projeto. Para criar uma metáfora é preciso ter uma idéia, ela é o resultado deum complexo processamento no subconsciente, de suma importância para o desenvolvimentode software. Para isso a mente deve estar oxigenada e descansada. A metáfora é relacionada ao ritmo sustentável descrito a posteriormente. Assim osdesenvolvedores devem estar descansados todos os dias e independente da motivaçãohumanista, existe uma motivação econômica muito forte que pode ser notada. Com as pessoasdescansadas a produção é maior e com mais qualidade, eficácia em suas idéias, maior atençãoe agilidade no desenvolvimento.3.11 RITMO SUSTENTÁVEL O ritmo sustentável no XP é importante porque viabiliza à equipe cumprir o tempoplanejado para finalizar o projeto. Nesse método de desenvolvimento não se usa a hora extrapara que o ritmo não seja alterado e o desenvolvedor tenha todas as motivações descritasanteriormente em relação a estar descansado. Como em outras práticas do XP, adotar o ritmo sustentável é um desafio a ser travado.No mundo todo, várias equipes têm adotado esta prática e colhem seus frutos. Seus projetossão mais ágeis, as pessoas convivem de forma mais harmoniosa e, sobretudo, não precisam tersacrifícios fora do trabalho.
  44. 44. 433.12 INTEGRAÇÃO CONTÍNUA Existem duas ferramentas de suma importância para realizar a integração contínua: Aferramenta de build, compila o sistema e executa outras atividades que sejam necessárias paraque o sistema seja executado, levando o desenvolvimento a ter agilidade gerando um sistemae o Sistema de controle de versão, conhecido como repositório, sua função é armazenar oscódigos fonte do sistema e mantém a sua versão. Ao integrar uma funcionalidade ao sistema ela afeta outras já incorporadas a ele,assim, ao desenvolver a funcionalidade o par deve integrá-la ao sistema diversas vezesdurante o dia, e também deve ser testada, dessa forma atingirá sucesso ao integrá-la. Com o código coletivo, a equipe avança com maior velocidade, porque, assim não énecessário esperar por outra pessoa para que o problema seja resolvido. O código permanecemais claro, pois é revisado por diversos programadores e eles não precisam contornar áreasproblemáticas do sistema.3.13 CICLO DE VIDA DO XP No XP, a equipe implementa as funcionalidades mais importantes de acordo com asprioridades do cliente, assim, poderá gerar valor, alto e ágil. As quatro fases principais do XP, são demonstradas na figura 9: PLANEJAMENTO PROJETO CODIFICAÇÃO TESTEFonte: Engenharia de Software, PRESSMAN, 2006. Figura 9: Ciclo de Vida do XP
  45. 45. 44 A equipe no XP é composta pelo Gerente de Projeto que é o responsável pelosassuntos administrativos do projeto, o Coach que cuida da questão técnica do projeto, oAnalista de Teste, é o responsável por ajudar o cliente a escrever os testes de aceitação, oRedator Técnico, contribui para que a equipe de desenvolvimento documente o sistema e oDesenvolvedor, que analisa, projeta e codifica o sistema. As atividades do XP trazem resultados rapidamente na forma de um software testado,que cumpre todos os requisitos e expectativas do cliente em relação a custo e qualidade. Aocombinar as técnicas do XP e eliminar as atividades que tornam o desenvolvimentoredundante leva a equipe a cumprir seus prazos e trabalhar sem ultrapassar seus limiteshumanos. Enfim, diminui os riscos dos projetos, desenvolve software de forma iterativa ereavalia as prioridades dos clientes.
  46. 46. 454 SCRUM Ratuchenei (2008) especifica que Scrum não é um processo, mas uma metodologiaque funciona como gestor e estrategista em desenvolvimento de softwares. Para Kniberg (2007) Scrum não é um método, e sim um framework, ou seja, umaferramenta no auxílio de projetos de software. No Scrum existem três tipos de papéis, o primeiro é o Scrum máster, o responsável portodo o projeto e pela concretização dos outros papéis. O segundo é o Product Owner, eledefine as finalidades do produto a ser criado, cria prioridades de forma que as primeirasfuncionalidades a ser implantadas não sejam as mais fáceis, e sim aquelas que podem gerarmais valor ao cliente. E o terceiro é a equipe, que trabalha nos moldes definidos pelo ScrumMaster e Product Owner.4.1 PRODUCT BACKLOG, PRODUCT OWNER E PRIORIZAÇÃO DE ESTÓRIAS No Scrum o Product Backlog é um conjunto de itens, estórias que definem o que ocliente espera em um sistema, assim a equipe irá determinar o desenvolvimento. Oresponsável pelo Product Backlog é o Product Owner, sua principal função é definir asestórias, priorizá-las na Sprint Planning Meetings, no entanto não precisa saber comoimplementá-las, apenas a função de cada uma. Através de sua formação, o product owner tem a possibilidade de criar estórias que oauxiliem no desenvolvimento, de forma que o seu foco seja gerar valor para o cliente criandoas funcionalidades prioritárias a ele. Outros integrantes da equipe também podem acrescentarestórias, porém a função de priorizá-las é estritamente do product owner. Um pouco diferente do que foi visto no XP, uma estória em Scrum tem as seguintescaracterísticas: - ID: Apenas uma forma de identificar a estória caso o nome seja alterado. Pode serformado por auto-incrementos. - Nome: a estória necessita de um pequeno nome com sua descrição
  47. 47. 46 - Importância: No Scrum, é usual uma pontuação para destacar a importância daestória, quanto mais pontos maior sua importância. - Estimativa inicial: Como no XP, são usados pontos para estimar (tempo xdesenvolvedor) o desenvolvimento fazendo comparações entre estórias com funcionalidadessemelhantes. - Como demonstrar: Ao apresentar o sprint é demonstrado como acontece a estória, deforma linear é destacado o que é feito e os resultados. - Notas: Espaço reservado a observações extras. (fontes, informações, entre outros).Fonte: KNIBERG, 2007. Quadro 1 - Modelo Product Backlog (exemplo). As estórias podem ser alteradas por qualquer desenvolvedor, geralmente o productowner é o responsável por ela, porém, através de esclarecimentos e alterações, o documentopode, e deve ser sempre atualizado. Além dos itens descritos anteriormente em uma estória ainda pode-se acrescentarnovas informações para apoiar as decisões do product owner ao priorizar as estórias. - Track: uma forma de dividir as estórias por categoria. - Componentes: Usada para definir os componentes técnicos usados nodesenvolvimento da estória
  48. 48. 47 - Solicitante: Para gerar feedback esse campo registra o solicitante da estória, seja ocliente ou algum stakeholder. - Id do bug: Para rastrear a estória com seus defeitos. O product backlog só pode ser fechado para a criação de sprints após ter a certeza deque as estórias foram priorizadas corretamente e bem distribuídas.4.2 PLANEJAMENTO DO SPRINT Sprints são o mesmo que iterações, porém elas seguem o ciclo PDCA4, e como no XPseu resultado é um sistema com menos funcionalidades, pronto para ser utilizado pelo cliente. O ciclo PDCA, faz parte da gestão da qualidade em Administração, e segue osseguintes passos: - Plan (Plano): Identifica o problema, analisa e então, elabora planejamentos pararesolve-lo. - Do (Execução): Segue o plano definido. - Check (Verificação): Monitora e avalia os resultados de forma periódicaconfrontando com o plano inicial. - Act (Ação): Age de acordo com os resultados obtidos. Determina meios de melhoriasdo processo como forma de obter melhor qualidade. Dessa forma, o sprint segue as mesmas fases do ciclo PDCA, começa por uma reuniãoque planeja o sprint, sendo que essa fase não tolera erros, pode levar o sprint a ser mal feito. O product owner deve confiar em sua equipe e deixar que realizem seu trabalho,portanto nessa reunião discute-se as melhores formas de deixar que a equipe trabalhar poralgumas semanas sem distrações que a levem a atrasos. De forma mais clara, essa reunião discute o objetivo do sprint, a equipe, um sprintbacklog, a data de apresentação e por fim local e horário das reuniões diárias. Assim, são apresentadas na figura 10, três variáveis destacadas em um planejamentode sprint, por essa razão equipe de desenvolvimento e product owner devem trabalhar emconjunto pelo sucesso do projeto.4 PDCA: É um ciclo de desenvolvimento que tem como foco a melhoria contínua.
  49. 49. 48Fonte:KNIBERG, 2007. Figura 10 – Variáveis do Sprint. Como já foi visto no XP, a comunicação é um dos valores do desenvolvimento ágil,com o Scrum não é diferente, equipe e product owner definem da melhor forma possível asvariáveis do sprint. O Escopo e a Importância são definidos pelo product owner, ele destaca a prioridade eo fim esperado para cada estória. A Estimativa é definida pela equipe, o tempo é estimado, de forma que deve ser feitoem ordem decrescente de acordo com a prioridade de cada uma. O resultado dessa estimativapode fazer com que o product owner mude de idéia e altere a prioridade das estórias. Kniberg (2007) ainda exclui da figura 10 um quarto elemento, qualidade, essa variávelé dividida em dois âmbitos, são eles: - Qualidade interna: Tem mais relação à questão técnica, questões das quais o clientenão tem idéia em como resolver, e que pode levar benefícios futuros quanto à manutebilidadee alterações do sistema. - Qualidade externa: Questões ligadas diretamente ao usuário, como por exemplo umaboa interface que o leve a ter fácil aprendizado para usar o sistema. O tamanho do sprint é definido para permitir a agilidade do projeto, assim, sãodefinidas as vantagens de um sprint curto e longo: - Sprints curtos: O feedback é mais freqüente, de forma que passará a entregá-los maisrápido - Sprints longos: Suas vantagens são maior facilidade para correção de erros dedesenvolvimento e mais tempo para a equipe alcançar um bom ritmo.
  50. 50. 494.3 SPRINT BACKLOGS Após a reunião de planejamento e antes da reunião diária, é função do Scrum Mastercriar um sprint backlog. Existem muitos formatos a ele, como: Jira, Excel e um quadro naparede, do qual segundo Kniberg, é o mais indicado a ser usado. Esse quadro deve ser montado em uma parede livre de pelo menos 2 m², como édemonstrado na figura 11.Fonte: KNIBERG, 2007. Figura 11 – Modelo de Sprint Backlog. Esse quadro é descrito a seguir de acordo com cada etapa: - Não iniciado: são os itens do backlog dos quais ninguém está trabalhando ainda. - Iniciado: itens do backlog que estão sendo desenvolvidos no dia corrente. - Pronto: itens dos quais não serão mais necessários para o trabalho. - Depois: quando os itens são concluídos antes do fim do prazo para o sprint sãoincluídos novos itens para o desenvolvimento.
  51. 51. 50 - Gráfico de Burndown: Demonstra se a equipe está estimando corretamente e o maisimportante, se está cumprindo todos os pontos estimados. Dessa forma, quanto mais próximoda linha pontilhada melhor está o desenvolvimento, quanto mais longe, maior o tempo usadoacima do estimado e o custo também é maior.Fonte: KNIBERG, 2007. Figura 12 – Exemplo de Sprint Backlog. Na figura 12, é apresentado um exemplo de sprint backlog, uma forma simplespara a organização do que ocorre no desenvolvimento de cada sprint. As vezes pode chegar aparecer uma bagunça, mas na verdade é através dele que o desenvolvimento dos sprints sãoguiados e organizados.
  52. 52. 514.4 SALA DA EQUIPE Chamado por Kniberg por “Canto de Design” é uma sala onde a quipe fará as suasreuniões diárias visando o quadro de tarefas, um computador público, cadeiras extras, espaçopara as reuniões em pé e a parede de design que é um quadro branco, onde a equipe podeescrever suas observações de design e esboços de documentações. O ideal é que a equipe esteja sempre junta para o desenvolvimento, isto significa quedevem ficar a uma distância onde não sejam incomodados por outras equipes, possam terplena visão do quadro de tarefas e entre os desenvolvedores e possam conversar sem precisargritar. A presença do product owner é essencial para a equipe, mas não é necessária a suapresença na sala da equipe, para que não haja intromissão no desenvolvimento, pois a equipedeve deixar que o seu trabalho flua naturalmente.Fonte: KNIBERG, 2007. Figura 13 – Modelo de Sala da Equipe. Na figura 13, é apresentado um exemplo de sala da equipe, ainda falta a inclusão dadisposição das mesas de forma que seja feita de acordo com as possibilidades de cada equipe,desde que siga o conjunto de regras já especificadas anteriormente.
  53. 53. 524.5 REUNIÕES DIÁRIAS As reuniões diárias, conhecidas em inglês como daily scrum, devem ser diárias, sematrasos e no mesmo lugar de preferência diante do quadro de tarefas. A equipe deve estar empé, para que a reunião não perdure por muito tempo, geralmente o máximo de tempo é quinzeminutos. A equipe apresenta o que foi feito no dia anterior e aproveita para atualizar o quadrode tarefas.4.6 APRESENTAÇÕES DE SPRINTS Existem diversos pontos positivos em uma apresentação de sprint, como motivação àequipe pela conclusão do trabalho e reconhecimento externo, feedback de stakeholders,interação entre equipes e a finalização real do sprint, pois, sem a apresentação há o risco deser entregue “quase” pronto. A apresentação força a equipe em querer melhorar odesenvolvimento para não correr o risco de se constranger em sua apresentação.4.7 RETROSPECTIVAS DE SPRINTS As retrospectivas são muito importantes, e para Kniberg (2007), o segundo eventomais importante do Scrum, o primeiro é a reunião de planejamento. É uma forma de percebererros e buscar melhorias nos próximos sprints. Uma reunião de retrospectiva deve contar com a presença de toda a equipe, o productowner e o Scrum máster. Escolhe-se um secretário, é feito um resumo do sprint backlog,todos expõem suas opiniões quanto ao desenvolvimento do sprint, é feita uma comparação do

×