UNIVERSIDADE DO PLANALTO CATARINENSE DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE SISTEMAS DE INFORMAÇÃO (BACHARELADO) RARUANA MACEDO DE FREITAS ESTUDO E APLICAÇÃO DE MODELOS ÁGEIS LAGES (SC) 2011
RARUANA MACEDO DE FREITAS ESTUDO E APLICAÇÃO DE MODELOS ÁGEIS Trabalho de Conclusão de Curso submetido à Universidade do Planalto Catarinense para obtenção dos créditos de disciplina com nome equivalente no curso de Sistemas de Informação - Bacharelado. Orientação: Prof(ª). Sabrina Bet Koerich M.Sc. LAGES (SC) 2011
RARUANA MACEDO DE FREITAS ESTUDO E APLICAÇÃO DE MODELOS ÁGEIS ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO, DO 8º. SEMESTRE, OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE: BACHAREL EM SISTEMAS DE INFORMAÇÃO Lages (SC), 07 de Dezembro de 2011 Prof. Sabrina Bet Koerich, M.Sc. Orientador BANCA EXAMINADORA: Prof. Sérgio Murilo Schütz, M.Sc. UNIPLAC Prof. Madalena Pereira da Silva, M.Sc. UNIPLAC Prof. Sabrina Bet Koerich, M.Sc. Professor de TCC Prof. Sabrina Bet Koerich, M.Sc. Coordenador de Curso
LISTA DE ILUSTRAÇÕES FIGURA 1 - Principais papéis da modelo FDD... 21 FIGURA 2 - Demonstração das duas fases e dos cinco processos do FDD.... 22 FIGURA 3 - Demonstração do ciclo baseado em práticas do Crystal Family.... 25 FIGURA 4 - Demonstração do ciclo do ASD composto por três fases.... 27 FIGURA 5 - O ciclo de vida dos projetos XP.... 40 FIGURA 6 - Caso de uso - acompanhamento/avaliação/banca.... 48 FIGURA 7 - Caso de uso - fluxo de avaliação: projeto.... 49 FIGURA 8 - Caso de uso - fluxo de avaliação: TCCI.... 49 FIGURA 9 - Caso de uso - fluxo de avaliação: TCCII.... 50 FIGURA 10 - Sistema web proposto.... 51 FIGURA 11 - O ciclo de vida de uma iteração XP.... 54 FIGURA 12 - O ciclo de vida do desenvolvimento XP... 54 FIGURA 13 - Um dia típico de um desenvolvedor XP.... 55 FIGURA 14 - Layout do site.... 56 FIGURA 15 - Página de cadastro de professor.... 57 FIGURA 16 - Página de cadastro de turma.... 58 FIGURA 17 - Página de cadastro de aluno.... 59 FIGURA 18 - Página de cadastro por áreas de pesquisa.... 60 FIGURA 19 - Página de cadastro de projetos.... 61 FIGURA 20 - Página de cadastro do acompanhamento da orientação.... 62 FIGURA 21 - Página de cadastro de critérios de avaliação.... 63 FIGURA 22 - Página de cadastro de atividades no calendário.... 63 FIGURA 23 - Página inicial do sistema... 67 FIGURA 24 - Página com a lista dos professores cadastrados.... 67 FIGURA 25 - Página inicial do cadastro do parecer do professor de TCC.... 68 FIGURA 26 - Página com a lista dos alunos cadastrados.... 68 FIGURA 27 - Página com a lista das áreas de pesquisa cadastradas... 69 FIGURA 28 - Página de pesquisa dos projetos cadastrados.... 69 FIGURA 29 - Página de cadastro de sugestões de projeto de TCC... 70 FIGURA 30 - Página de consulta das sugestões de projeto de TCC cadastradas.... 70 FIGURA 31 - Página de exclusão de sugestões de projeto de TCC.... 71 FIGURA 32 - Página de acompanhamento de orientação.... 71 FIGURA 33 - Página com a lista das atividades cadastradas no calendário.... 72 FIGURA 34 - Modelo conceitual do banco de dados.... 73
FIGURA 35 - Modelo lógico do banco de dados.... 74 FIGURA 36 - Scrum of Scrums.... 80 FIGURA 37 - Ciclo Scrum.... 83 FIGURA 38 - Processo completo para o Sprint no Scrum.... 85 FIGURA 39 - Exemplo de Product Backlog... 89 FIGURA 40 - Exemplo de Sprint Backlog... 91 FIGURA 41 - Exemplo de Burndown Chart... 92 FIGURA 42 - Sprint Burndown (no prazo)... 92 FIGURA 43 - Sprint Burndown (atrasado)... 93 FIGURA 44 - Sprint Burndown (adiantado).... 93 FIGURA 45 - Sprint Overview.... 94 FIGURA 46 - Product Backlog Composition.... 95 FIGURA 47 - Sprint... 100 FIGURA 48 - Sprint Burndown... 101 QUADRO 1 - Sumário executivo... 43 QUADRO 2 - Descrição das histórias de usuário 1... 44 QUADRO 3 - Descrição das histórias de usuário 2... 44 QUADRO 4 - Descrição das histórias de usuário 3... 44 QUADRO 5 - Descrição das histórias de usuário 4... 45 QUADRO 6 - Descrição das histórias de usuário 5... 45 QUADRO 7 - Descrição das histórias de usuário 6... 45 QUADRO 8 - Descrição das histórias de usuário 7... 46 QUADRO 9 - Descrição das histórias de usuário 8... 46 QUADRO 10 - Descrição das histórias de usuário 9... 46 QUADRO 11 - Estimativa para implementação... 52 QUADRO 12 - Descrição das histórias de usuário 10... 64 QUADRO 13 - Descrição das histórias de usuário 11... 64 QUADRO 14 - Descrição das histórias de usuário 12... 64 QUADRO 15 - Descrição das histórias de usuário 13... 64 QUADRO 16 - Descrição das histórias de usuário 14... 65 QUADRO 17 - Descrição das histórias de usuário 15... 65 QUADRO 18 - Descrição das histórias de usuário 16... 65 QUADRO 19 - Descrição das histórias de usuário 17... 65 QUADRO 20 - Descrição das histórias de usuário 18... 66 QUADRO 21 - Descrição das histórias de usuário 19... 66 QUADRO 22 - Descrição das histórias de usuário 20... 66 QUADRO 23 - Product Backlog... 97 QUADRO 24 - Papéis Scrum (equipe)... 97 QUADRO 25 - Funcionalidades do Product Backlog selecionadas para o Sprint 1... 98 QUADRO 26 - Sprint Backlog... 98 TABELA 1 - Critério para análise comparativa entre os modelos ágeis... 104 TABELA 2 - Justificativa princípio 1... 105
TABELA 3 - Justificativa princípio 2... 105 TABELA 4 - Justificativa princípio 3... 106 TABELA 5 - Justificativa princípio 4... 106 TABELA 6 - Justificativa princípio 5... 107 TABELA 7 - Justificativa princípio 6... 107 TABELA 8 - Justificativa princípio 7... 108 TABELA 9 - Justificativa princípio 8... 108 TABELA 10 - Justificativa princípio 9... 109 TABELA 11 - Justificativa princípio 10... 109 TABELA 12 - Justificativa princípio 11... 110 TABELA 13 - Justificativa princípio 12... 110 TABELA 14 - Resumo da comparação dos modelos ágeis.... 111
LISTA DE ABREVIATURAS E SIGLAS ASD DSDM FDD IRUF PO RAD ROI SGTCC TCC UNIPLAC XP - Adaptative Software Development - Dynamic Systems Development Method - Feature Driven Development - Requisitos Iniciais Antecipados - Product Owner - Rapid Application Development - Return On Investiment - Sistema de Gerenciamento de TCC - Trabalho de Conclusão do Curso - Universidade do Planalto Catarinense - Extreme Programming
RESUMO Devido à demanda da sociedade a indústria de software vem crescendo significativamente nos últimos anos, com isso problemas relacionados ao processo de desenvolvimento do software como problemas de manutenção, complexidade, alto custo de implementação e a falta de qualidade se tornaram muito mais evidentes. Devido a esses problemas a Engenharia de Software se preocupou em trazer melhorias significativas nesses processos. Essas melhorias vêm aumentando cada vez mais dentro da Engenharia de Software, pois foi na mesma que surgiram os modelos ágeis com o intuito de trazerem melhorias no processo de desenvolvimento de software. Esses modelos ágeis se destacam por ocasionarem resultados mais diretos e por realizarem um processo de desenvolvimento de software muito mais qualificado. Com a intenção de melhorar o processo, neste trabalho é realizado um estudo aprofundado e a aplicação dos modelos ágeis Extreme Programming e o Scrum, com o objetivo de realizar uma análise comparativa entre os mesmos em cima dos doze princípios dos modelos ágeis no processo de desenvolvimento de software de um Sistema de Gerenciamento de TCCs. Com isso foi concluído que ambos os modelos ágeis foram satisfatórios. O XP é mais focado em práticas de Engenharia de Software, já o modelo ágil Scrum dá uma ênfase maior em aspectos de gerência e organização de toda a equipe no decorrer do processo de desenvolvimento do software. Palavras-chave: Modelos Ágeis; Análise Comparativa; Extreme Programming; Scrum.
ABSTRACT Due to society demand, the software industry has grown significantly on the recent years. Knowing this, problems related to the software development process as maintenance problems, complexity, high cost of implementation and lack of quality became more evident. Because of these problems the Software Engineering bothered to bring significant improvements in these processes. These improvements have increased more on the Software Engineering because they were the same agile models that arose with the concept of software engineering in order to bring improvements on the software development process. These agile models highlight themselves by direct results and because they perform a much more software development qualified process. Proposing better results on the process, on this paper was done thorough study and the application of the agile models Scrum and Extreme Programming, in order to perform a comparative analysis between them based on the twelve principles of the agile methods on the software development process of a TCCs Management System. With that, we concluded that both agile models were satisfactory. XP is focused on software engineering practices, on the other hand Scrum gives a greater emphasis on management aspects and organization of the entire Team during the software development process. Keywords: Agile Models, Comparative Analysis, Extreme Programming, Scrum.
SUMÁRIO 1 INTRODUÇÃO... 12 1.1 Apresentação... 12 1.2 Descrição do problema... 13 1.3 Justificativa... 13 1.4 Objetivo geral... 14 1.5 Objetivos específicos... 14 1.6 Metodologia... 15 2 MODELOS NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE.. 16 2.1 Processos para desenvolvimento de software... 16 2.2 Modelos Tradicionais... 17 2.3 Modelos Ágeis... 17 2.3.1 FDD (Feature Driven Development)... 20 2.3.2 DSDM (Dynamic Systems Development Methodology)... 23 2.3.3 Família Crystal de Modelo (Crystal Family Of Methodologies)... 24 2.3.4 ASD (Adaptative Software Development Desenvolvimento Adaptável de Software)... 26 2.3.5 Extreme Programming (XP)... 27 2.3.6 Scrum... 28 2.4 Conclusão... 31 3 EXTREME PROGRAMMING (XP)... 33 3.1 Valores XP... 33 3.2 Princípios XP... 35 3.3 Práticas XP... 37 3.4 Modelagem ágil ao longo do ciclo de vida XP... 39 3.5 Fase da exploração... 40 3.5.1 Requisitos iniciais antecipados (IRUF)... 41 3.5.2 Metáforas, arquiteturas e bases... 42 3.5.3 Estabelecimento da fundação do projeto... 42 3.6 Modelagem da fase da exploração... 43 3.7 Fase de planejamento... 51 3.8 Modelagem da fase de planejamento... 51 3.9 Fase de iteração... 52 3.10 Modelagem da fase de iteração... 55 3.11 Fase de produção... 75 3.12 Modelagem da fase de produção... 75
3.13 Conclusão... 75 4 SCRUM... 77 4.1 Preparação... 77 4.2 Papéis Scrum... 79 4.2.1 Product Owner (PO)... 79 4.2.2 Team Members... 79 4.2.3 ScrumMaster... 80 4.3 Processo... 81 4.3.1 Planejando o Sprint... 82 4.3.2 Sprint... 84 4.3.3 Reunião diária do Scrum... 85 4.3.4 Revisão do Sprint... 86 4.3.5 Retrospectiva do Sprint... 88 4.4 Artefatos... 88 4.4.1 Product Backlog... 89 4.4.2 Sprint Backlog... 90 4.4.3 Burndown Chart... 91 4.4.4 Relatórios... 94 4.5 Preparação... 95 4.5.1 Product Backlog... 96 4.6 Papéis... 97 4.6.1 Processo... 97 4.6.2 Sprint... 100 4.6.3 Reunião diária do Scrum... 101 4.6.4 Revisão do Sprint... 101 4.6.5 Retrospectiva do Sprint... 102 4.7 Conclusão... 102 5 ESTUDO COMPARATIVO ENTRE OS MODELOS ÁGEIS EXTREME PROGRAMMING E SCRUM... 104 5.1 Análise... 104 5.2 Considerações... 112 5.3 Conclusão... 113 6 CONSIDERAÇÕES FINAIS... 114 REFERÊNCIAS BIBLIOGRÁFICAS... 117 APÊNDICES... 119
12 1 INTRODUÇÃO 1.1 Apresentação A sociedade vem necessitando cada vez mais da indústria de software, consequentemente os vários problemas relacionados ao processo de desenvolvimento de software ficam mais evidentes. Problemas de manutenção, alto custo de implementação, atrasos de cronograma e a falta de qualidade são alguns dos muitos problemas encontrados em um processo de desenvolvimento de software (LUDVIG & REINERT, 2007). Portanto a necessidade de melhorias nesses processos vem aumentando significativamente na Engenharia de Software (LUDVIG & REINERT, 2007). Dentro da Engenharia de Software surgiram os modelos ágeis com o intuito de melhorar o processo de desenvolvimento de software. Adotar esses processos mais simplificados, como os modelos ágeis vêm despertando cada vez mais o interesse de empresas em utilizá-los e consequentemente realizando um processo de desenvolvimento de software muito mais qualificado. O conteúdo deste trabalho está destinado ao estudo geral dos modelos ágeis disponíveis no mercado e um estudo voltado a dois modelos ágeis bem como a aplicação deles no processo de modelagem do Sistema de Gerenciamento de TCCs, visando à melhoria no processo de desenvolvimento de software. Além deste capítulo o trabalho está organizado da seguinte forma. O capítulo 2º apresenta um estudo geral dos modelos ágeis apresentando suas características gerais e dentre os diversos identificados foram escolhidos e detalhados dois modelos
13 ágeis sendo realizado um estudo aprofundado e detalhado dos mesmos. No capítulo 3º e no capítulo 4º foi realizada a aplicação desses dois modelos ágeis em uma modelagem de um software. Enfim no 5º capítulo foi realizada uma análise comparativa entre os dois modelos ágeis aplicados, e com o resultado desta análise foi concluído qual o modelo mais adequado para a modelagem do software. 1.2 Descrição do problema Problemas relacionados ao processo de desenvolvimento de um software, como atrasos no cronograma, falhas no desenvolvimento e falta de qualidade podem levar a não realização de um software ou um software com baixa qualidade e com vários erros. Para evitar tantos problemas é necessário melhorar o processo, adotando um modelo adequado. 1.3 Justificativa Projetos sempre estão sujeitos a riscos como: atrasos de cronograma, mudança de requisitos e a falta de qualidade. Cada vez mais é essencial a qualidade em um desenvolvimento de software, mas para isso ser concretizado não é suficiente uma equipe de desenvolvedores com qualidade profissional, mas sim das técnicas que são empregadas, como o uso de modelos adequados a cada tipo de projeto (LUDVIG & REINERT, 2007). Dentre os modelos podem-se destacar os modelos ágeis que surgiram para realizar melhorias no desenvolvimento de software. Muitas empresas não utilizam esses modelos ágeis muito pelo fato de não terem o conhecimento dos mesmos. Desta forma, realizam a programação sem se preocupar com a modelagem. A consequência são projetos mal-sucedidos e clientes insatisfeitos (AMBLER, 2004). Já os alunos de cursos de Sistemas de Informação também sentem dificuldade pela falta de apresentação de novas práticas de desenvolvimento de
14 software, principalmente dos modelos ágeis. Quando existe essa apresentação, muitas vezes vêem como algo difícil de usar e que pode até implicar em mais trabalho do que benefícios ao processo de desenvolvimento. É necessária então a desmistificação deste fato, pois um dos princípios dos modelos ágeis resume-se em simplicidade (BECK et al., 2001). Atualmente existem vários modelos ágeis que estão trazendo sucesso aos projetos que adotam os mesmos, atendendo aos requisitos necessários das empresas. Dentre os mais conhecidos estão SCRUM (SCHWABER e BEEDLE, 2001) e Extreme Programming ou XP (Wells, 2009). Podem-se citar outros como Crystal Family, FDD (Feature Driven Development), DSDM (Dynamic Systems Development Method), ASD (Adaptative Software Development), cada um atendendo aos requisitos necessários de cada projeto. Explorar esses modelos ágeis e apresentá-los é uma primeira etapa para o processo de desmistificação, contudo existem muitos documentos sobre os modelos ágeis focando a parte teórica, já os documentos explicando e mostrando a aplicação desses modelos ágeis são poucos, quase inexistentes. 1.4 Objetivo geral Apresentar um estudo prático do uso de modelos ágeis no processo de modelagem de um Sistema de Gerenciamento de TCCs. 1.5 Objetivos específicos a) Identificar os modelos ágeis e apresentar suas características gerais; b) Selecionar e detalhar dois modelos ágeis dentre os diversos identificados; c) Modelar um estudo de caso utilizando os modelos ágeis selecionados; d) Comparar os modelos ágeis aplicados.
15 1.6 Metodologia O desenvolvimento deste trabalho começou com a elaboração do projeto, o problema, os objetivos e a justificativa. Posteriormente foi realizado um estudo geral sobre os modelos ágeis destacando a estrutura de cada um, vantagens, desvantagens entre outros, esse estudo foi realizado utilizando trabalhos concluídos, livros e a Internet. Foram escolhidos dois modelos ágeis dentre os diversos identificados o Extreme Programming (XP) e o Scrum sendo realizado um estudo aprofundado e uma descrição detalhada dos mesmos. Para realizar este estudo também foram utilizados trabalhos concluídos, livros e a Internet. Concluída esta fase foi realizada a modelagem de um Sistema de Gerenciamento de TCCs utilizando esses dois modelos ágeis definidos. Por fim, foi realizada uma análise comparativa entre os dois modelos aplicados, levando-se em consideração o desempenho relacionado a medidas qualitativas e quantitativas. Dentre a análise quantitativa, um dos itens a ser analisado refere-se à quantidade de artefatos envolvidos e tempo para o desenvolvimento de cada um, porém a mesma não foi realizada, pois foi preciso estudar detalhadamente os dois modelos ágeis, consumindo bastante tempo para estudar os mesmos, não podendo ser definido quanto tempo levou para cada artefato, sendo assim não foi possível realizar esta análise. Já a análise qualitativa, foi realizada em cima dos doze princípios dos modelos ágeis, de forma subjetiva, baseado na experiência que foi obtida com a aplicação dos modelos ágeis, ou seja, qual gerou melhores resultados prático.
16 2 MODELOS NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE O objetivo deste capítulo é realizar uma apresentação geral dos modelos ágeis no processo de desenvolvimento de software, identificando suas características gerais, dentre elas vantagens e desvantagens de cada modelo. Posteriormente são definidos e apresentados dois modelos ágeis dentre os diversos identificados o Extreme Programming (XP) e o Scrum, sendo realizado um estudo aprofundado dos mesmos. 2.1 Processos para desenvolvimento de software Processo de software é um conjunto de atividades que auxiliam na produção de um software com qualidade (SOARES, 2004). Existem vários processos para o desenvolvimento de software, mais também existem atividades fundamentais comuns a todos eles (SOMMERVILLE, 2003): Especificação de software: Definição dos requisitos e das restrições do software. Uma fase onde é decidido o que o sistema deverá fazer sendo realizada uma conversa com o cliente juntamente com o desenvolvedor; Projeto e implementação de software: O software é produzido, nesta fase é realizada a implementação; Validação de software: O software é validado com o objetivo de verificar e garantir que as funcionalidades que foram implementadas estão de acordo com o que foi especificado anteriormente; Evolução de software: O software evolui para continuar atendo as necessidades dos clientes.
17 Atualmente existem vários processos de software dentro da própria Engenharia de Software trazendo melhorias nos processos. Podem-se citar os modelos tradicionais e os modelos ágeis, os modelos ágeis vêm sendo bastante utilizados e trazendo excelentes resultados para as empresas. Muitas das organizações não utilizam nenhum processo, pelos motivos de os modelos tradicionais não serem adequados, por não possuírem recursos suficientes para adotar certos processos. A consequência disso é o projeto de software com baixa qualidade (SOARES, 2004). 2.2 Modelos Tradicionais Esses modelos surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros (ROYCE, 1970). Na época para se fazer alterações e correções o custo era alto demais, pois não existiam ferramentas modernas de apoio ao desenvolvimento do software, sendo assim o software primeiramente era planejado e depois documentado para depois ser implementado. Esses modelos também são conhecidos como pesados ou orientados a documentação. Têm como característica marcante dividir o processo de desenvolvimento em etapas e/ou fases bem definidas (SOARES, 2004). 2.3 Modelos Ágeis O termo Modelos Ágeis ficou popular no ano de 2001 quando um grupo de dezessete especialistas em processos de desenvolvimento de software estava representando alguns métodos, eles estabeleceram princípios comuns compartilhados por todos esses métodos, criando a Aliança Ágil e o estabelecimento do Manifesto Ágil. Os principais conceitos do Manifesto Ágil são (LUDVIG & REINERT, 2007): Indivíduos e interações ao invés de processos e ferramentas: Em uma equipe as
18 pessoas trabalham juntas, as equipes precisam de programadores, analistas, gerentes de projeto e clientes para a construção do software, essas pessoas são muito importantes quando tem um bom conhecimento de sua função, sendo assim não bastam somente excelentes ferramentas e um bom processo se não souber executá-los, esses processos e ferramentas são importantes, mais as pessoas trabalhando juntas são bem mais importantes; Software executável ao invés de documentação: Muitas vezes é mais simples para o cliente analisar o sistema vendo o seu funcionamento do que através de diagramas. Não se trata de abandonar o processo de documentação, mas apenas de utilizar a ferramenta certa para transmitir a informação desejada no momento (SANTOS et al, 2003); Colaboração do cliente ao invés de negociação de contratos: O cliente é quem decide o que o sistema irá fazer, mesmo ele realizando mudanças no sistema, pelo fato que o cliente nem sempre consegue explicar exatamente o que quer, e somente conseguindo isso ao longo do tempo quando começa ver o funcionamento do software. É muito importante se ter um contrato com o cliente definindo as responsabilidades e direitos, mas o contrato não será um substituto para a comunicação, ou seja, a comunicação entre cliente e desenvolvedor continua existindo e sendo muito importante; Respostas rápidas a mudanças ao invés de seguir planos: Em todo projeto é traçado um plano a ser seguido, mas isso não significa que não ocorreram mudanças no decorrer do projeto. Todo projeto tem que ter um plano traçado, mas ele deve ser flexível as mudanças que podem ocorrer no desenvolvimento do software para assim não se tornar irrelevante. Para auxiliar as pessoas a compreenderem o enfoque do desenvolvimento ágil, aconteceu um refinamento das filosofias contidas em seu manifesto em uma coleção de doze princípios realizados pelos membros da Aliança Ágil, os modelos ágeis de desenvolvimento de software devem se adequar a esses doze princípios (FAGUNDES, 2005). Estes princípios são (COCKBURN, 2000): 1. A prioridade é satisfazer ao cliente através de entregas de software de valor contínuo e freqüentes.
19 2. Receber bem as mudanças de requisito, mesmo em uma fase avançada, dando aos clientes vantagens competitivas. 3. Entregar software em funcionamento com frequência de algumas semanas ou meses, sempre na menor escala de tempo. 4. Equipes de negócio e de desenvolvimento devem trabalhar juntas diariamente durante todo o projeto. 5. Manter uma equipe motivada fornecendo ambiente, apoio e confiança necessária para a realização do trabalho. 6. A maneira mais eficiente da informação circular dentro da equipe é através de uma conversa face a face. 7. Ter o software funcionando é a melhor medida de progresso. 8. Processos ágeis promovem o desenvolvimento sustentável. Todos envolvidos devem ser capazes de manter um ritmo de desenvolvimento constante. 9. Atenção contínua a excelência técnica e um bom projeto aumentam a agilidade. 10. Simplicidade é essencial. 11. As melhores arquiteturas, requisitos e projetos provêm de equipes organizadas. 12. Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais eficazes e então se ajustar e adaptar seu comportamento. A idéia dos modelos ágeis é ter o enfoque nas pessoas e não nos processos. Uma característica também dos modelos ágeis é que eles são adaptativos, ou seja, se adaptam a novos fatores no decorrer do desenvolvimento do projeto, não precisando analisar tudo que poderá ocorrer no desenvolvimento do projeto. Os modelos ágeis não rejeitam os processos, a documentação, as ferramentas, apenas mostram que esses fatores têm uma importância menor se comparado com os indivíduos e interações, com a colaboração dos clientes, as respostas rápidas a mudanças e alterações, o software estando executável entre outros fatores (SOARES, 2004). Podem-se citar alguns modelos ágeis que são bem conhecidos e utilizados também por empresas e organizações como Extreme Programming ou XP (Wells,
20 2009), SCRUM (SCHWABER e BEEDLE, 2001), Crystal Family, FDD (Feature Driven Development), DSDM (Dynamic Systems Development Method) e ASD (Adaptative Software Development) cada um atendendo aos requisitos necessários de cada projeto. 2.3.1 FDD (Feature Driven Development) FDD surgiu entre 1997 e 1999 em um projeto em Cingapura, por Peter Coad a partir do método Coad (um modelo completo para Análise, Desenho e Programação Orientados por Objetos, que foi desenvolvido) por Jeff De Luca um gerente de projetos australiano. É um modelo para o gerenciamento e desenvolvimento de software que combina as principais vantagens de outros modelos ágeis com as técnicas centradas no modelo, que podem ser utilizados para equipes e em projetos maiores. Também se caracteriza pela ênfase que se da à qualidade durante todo o processo de desenvolvimento do projeto. No FDD tudo é orientado a funcionalidades sendo assim possível saber quantas funcionalidades já foram desenvolvidas e quantas faltam ser desenvolvidas. Combina as melhores práticas do gerenciamento ágil de projetos juntamente com uma abordagem completa para Engenharia de Software orientada por objetos, assim conquistando os três principais públicos de um projeto de software: gerentes, clientes e desenvolvedores. Tem como vantagens priorizar o que o cliente prioriza, é recomendado para qualquer tipo de desenvolvimento e também possui requisitos mais formais. Tem como principais papéis: Gerente de projeto (Project Manager), Arquiteto líder (Chief Architect), Gerente de desenvolvimento (Development Manager), Programador líder (Chief Programmer), Proprietário de classe (Class Owner), Especialista do domínio (Domain Experts), Gerente do domínio (Domain Manager) (SANTOS & LUZ, 2003).
21 FIGURA 1 - Principais papéis da modelo FDD. Fonte: Cibelly et al, 2009. O lema do FDD é "Resultados freqüentes, tangíveis e funcionais." Algumas características do FDD: Aproximadamente a cada duas semanas resultados úteis; Dentro dos primeiros 10% de um projeto já se sabem se o plano e a estimativa são sólidos; Planejamento detalhado; Blocos bem pequenos de funcionalidade chamados de features que são valorizados pelos clientes; Monitoramento detalhado, ou seja, resumos de alto nível para clientes e gerentes, em termos de negócio; Relatórios com incrível precisão e rastreabilidade. FDD possui somente duas fases, pois é um modelo muito objetivo (figura 2): Concepção & Planejamento: Pensar um pouco antes de fazer (tipicamente de uma a duas semanas); Construção: Fazer de forma iterativa (tipicamente em iterações de duas semanas). FDD possui cinco processos bem definidos (figura 2): DMA (Desenvolver um modelo abrangente): Envolve o desenvolvimento de
22 requisitos, análise orientada por objetos e também outras técnicas do domínio de negócio que estiver em questão. O resultado é um modelo de objetos de alto nível, com isso a equipe será guiada durante os ciclos de construção; CLF (Construir a lista de funcionalidades): Ocorre a decomposição funcional do modelo de domínio em três camadas: áreas de negócio, atividades de negócio e os passos automatizados da atividade que seriam as funcionalidades. Terá como resultado várias funcionalidades que representam o produto a ser construído; PPF (Planejar por funcionalidade): Abrange estimativas de complexidade e dependências das funcionalidades. O resultado é um plano de desenvolvimento com pacotes de trabalho apropriados para a construção; DPF (Detalhar por funcionalidade): A equipe detalha os requisitos e outros artefatos para serem codificados, incluindo testes. O projeto é inspecionado e o resultado é um modelo de domínio mais detalhado preenchendo também os esqueletos dos códigos; CPF (Construir por funcionalidade): Todos os esqueletos são preenchidos e testados. O resultado é um incremento do produto integrado ao repositório principal do código com qualidade que poderá ser usado pelo cliente. FIGURA 2 - Demonstração das duas fases e dos cinco processos do FDD. Fonte: França et al, 2008.
23 2.3.2 DSDM (Dynamic Systems Development Methodology) DSDM foi desenvolvido na Inglaterra por um consórcio de vendedores e peritos no campo de Sistemas de Informação, nos anos 90 e aplicado pela primeira vez em 1995. Foi criado apoiando-se no método RAD (Rapid Application Development). É um modelo de apoio ao desenvolvimento de software e é focado em projetos de Sistemas de Informação (TEIXEIRA et al, 2005). Visa desenvolver aplicações com qualidade sem ultrapassar limites de orçamentos e prazos, focando-se na interação com o cliente, entrega freqüente de protótipos, equipes autônomas de desenvolvimento entre outros. Suas principais características são: o envolvimento ativo com o usuário, entrega frequente, teste integrado ao ciclo de vida e o poder de decisão da equipe. Tem como principais cargos e responsabilidades: Desenvolvedores (Developers), Desenvolvedores Sêniores (Senior Developers), Coordenador Técnico (Technical Coordinator), Usuário Embaixador (Ambassador User), Usuário Consultor (Adviser User), Visionário (Visionary), Executivo responsável (Executive Sponsor), Especialista do domínio (Domain Experts), Gerente do domínio (Domain Manager) (SANTOS & LUZ, 2003). Os princípios fundadores desse modelo são (KIOSKEA, 2009): Uma implicação dos utilizadores; Um desenvolvimento iterativo e incremental; Uma frequência de entrega elevada; A integração dos testes em cada etapa; A aceitação dos produtos entregues depende diretamente da satisfação das necessidades. O ciclo de vida do modelo envolve (TEIXEIRA et al, 2005): Estudo de viabilidade: A viabilidade de utilização é examinada, ou seja, determina se o projeto é factível e se a modelo DSDM é adequada. As técnicas mais importantes e utilizadas nesta fase são os workshops. São preparados o Relatório e o Protótipo de Viabilidade e também incluídos um registro de risco que identifica
24 os riscos mais importantes no projeto; Estudo do negócio: São determinados os requisitos primários; Iteração para o Modelo Funcional e Iteração para Desenvolvimento: Neste nível ocorre o desenvolvimento em si. É necessário entregar ao cliente o Modelo e o Protótipo Funcional que representam as funcionalidades realizadas nesta iteração que estão prontas para serem testadas; Implementação: Neste nível o sistema é entregue juntamente com a documentação, instalado e pronto para ser utilizado. 2.3.3 Família Crystal de Modelo (Crystal Family Of Methodologies) Esse modelo inclui um grande número de métodos diferentes, esses métodos são selecionados de acordo com as várias características do projeto que irá ser desenvolvido. No Crystal Family a complexidade dos projetos é identificada através de cores que indicam à intensidade dos métodos, quanto mais escura a cor, maior será sua complexidade. Crystal Family possui algumas características: possui o foco na comunicação e cooperação das pessoas, os projetos sempre usam ciclos de desenvolvimento (tempo máximo de quatro meses), não há limitações de práticas de desenvolvimento como ferramentas, produtos de trabalho entre outros. O ciclo do Crystal Family é baseado em práticas, as quais podem ser vistas na figura 3 (SANTOS et al, 200?): Staging: É realizado o planejamento do próximo incremento do sistema e a equipe faz uma seleção dos requisitos que serão implementados na iteração e também o prazo para a sua entrega; Edição e revisão: É realizada a construção, demonstração e uma revisão dos objetivos do incremento; Monitoramento: Monitoramento do processo com relação ao progresso e a estabilidade da equipe; Paralelismo e fluxo: Diferentes equipes podem operar na Crystal Orange com os máximos paralelismos através do monitoramento da estabilidade e também da
25 sincronização existente entre as equipes; Inspeções de usuários: Normalmente devem ser realizadas duas a três inspeções feitas pelos usuários a cada incremento; Workshops refletivos: São reuniões ocorridas antes e depois de cada iteração com o intuito de analisar o progresso do projeto; Local matters: São procedimentos futuramente aplicados e que variam de acordo com cada tipo de projeto; Work products (Produtos de Trabalho): Modelos de objetos comuns, seqüência de lançamento, manual do usuário. Para o Clear: casos de uso e descrição das funcionalidades e para o Orange: documento de requisitos; Standards (padrões): Formatação, padrões de notação, convenções do produto e a qualidade usada no projeto; Tools: Seriam as ferramentas utilizadas. Para o Crystal Clear: compiladores, gerenciadores de versão e configuração, programação, testes, comunicação. FIGURA 3 - Demonstração do ciclo baseado em práticas do Crystal Family. Fonte: Santos et al, 200?.
26 2.3.4 ASD (Adaptative Software Development Desenvolvimento Adaptável de Software) Foca-se no cliente, em empresas que desenvolvem softwares, atua principalmente em sistemas completos, estimula seu desenvolvimento com repetições e também uma constante prototipação (FRANÇA et al, 2008). Seus sistemas são grandes e complexos, o cliente sempre esta presente. Suas propriedades são: orientado a missões, baseado em componentes, iterativo, prazos préfixados, tolerância a mudanças, orientado a riscos. Seus principais cargos são: Executivo responsável (Executive Spons), Facilitador (Facilitator) Liderar e planejar as sessões, Escriba (Scribe) Efetuar anotações, Cliente (Customer) Sempre presente, Gerente de Projetos (Project Manager), Desenvolvedores (Developers) (SANTOS & LUZ, 2003). ASD possui como características (S.I Engenharia, 2009): Enfoque na missão: É uma maneira que faz com que a equipe obtenha os seus objetivos, para assim poder ter decisões com maior clareza; Tolerante a mudanças: Incorpora mudanças que surgem no decorrer do projeto, com o objetivo que o sistema obtenha um maior valor do cliente. É composto por um ciclo de três fases (figura 4): Especulação: É utilizada no lugar do planejamento, onde se fixa prazos e os objetivos; Colaboração: Realça a importância do trabalho de equipe; Aprendizado: São realizadas revisões de qualidade, demonstração das funcionalidades desenvolvidas. Os requisitos podem mudar durante o decorrer do desenvolvimento do projeto e também é necessário reconhecer as decisões erradas e a maneira como reagir com elas;
27 FIGURA 4 - Demonstração do ciclo do ASD composto por três fases. Fonte: Santos & Luz, 2003. 2.3.5 Extreme Programming (XP) É um modelo ágil com o foco em qualidade dos projetos e agilidade das equipes que vem trazendo sucesso nas empresas que o utilizam, por ajudar a criar sistemas de melhor qualidade em um tempo menor e também de uma forma mais econômica. É indicado para equipes pequenas e médias de desenvolvimento de software para requisitos vagos e que sofrem constantes mudanças. Existe a preocupação de se gastar menos tempo com a documentação e mais tempo com a resolução do problema, gerando produtos com melhor aceitação e qualidade (IMPROVEIT, 2007). O modelo é um conjunto bem definido de práticas e valores. Começou a ser desenvolvido em 1996 por Kent Beck no departamento de computação da montadora de automóveis DaimlerChrysler. Segundo Kent Beck (2000), O XP desenvolve software enfatizando o seu desenvolvimento rápido de maneira eficiente, visando satisfazer o cliente e também realizando o cumprimento de estimativas. As práticas e os valores do XP proporcionam para os seus seguidores um agradável ambiente de desenvolvimento, conduzidos por quatro valores: comunicação, simplicidade, feedback e coragem.
28 O XP coloca seus princípios em um nível extremo, por esse motivo o nome extreme. Baseia-se nos seguintes princípios (BORBOREMA, 2007): Feedback rápido, simplicidade presumida, mudanças incrementais, aceitação das mudanças, alta qualidade, ensinar aprendendo, investimento inicial pequeno, jogar para ganhar, experimentação concreta, comunicação honesta e franca, trabalhar a favor dos instintos do pessoal e não contra eles, aceitação das responsabilidades, adaptação local, viajar com pouca bagagem, métricas genuínas. As práticas do XP é um conjunto de atividades que as equipes tem com base para o desempenho, há muita confiança nas práticas XP, pelo fato que os pontos fracos de uma são compensados na outra pelos pontos fortes. Baseia-se em 12 práticas de desenvolvimento do software (SOARES, 2004): Planejamento, entregas frequentes, metáfora, projeto simples, testes, refatoração, programação em pares, propriedade coletiva, integração contínua, 40 horas de trabalho, cliente presente, código padrão. Esse modelo ágil é um processo de desenvolvimento que assegura ao cliente a sua participação dia-a-dia no projeto. É difícil encontrar um cliente que possa estar todos os dias presente ao longo do desenvolvimento do software, mas busca-se que o cliente esteja presente o suficiente para atender as necessidades das equipes com eficiência. Apesar do desenvolvimento do software se tornar mais ágil, o cliente também contribui para um resultado final de melhor qualidade e que atenda todas as suas expectativas (TELES, 2004). 2.3.6 Scrum Em 1993 Jeff Sutherland aplicou a primeira concepção do Scrum na Easel Corporation, por volta de 1995, Ken Schwaber refinou esse modelo ágil com base na sua própria experiência no desenvolvimento de sistemas e processos. Segundo Ken Schawaber (2001), o Scrum é um modelo extremamente flexível e ágil, com o objetivo de definir um processo de desenvolvimento iterativo e incremental que pode ser aplicado em qualquer produto e também no gerenciamento de qualquer atividade complexa.
29 O Scrum pode ser aplicado em projetos pequenos e projetos grandes. Baseiase no desenvolvimento incremental das aplicações centrado na equipe com ciclos de iteração curtos. Sua idéia principal é que o desenvolvimento de softwares envolve muitas variáveis técnicas e do ambiente, pode-se citar os recursos e tecnologia, os requisitos que podem mudar durante o processo de desenvolvimento. Com isso, o processo se torna imprevisível e complexo, consequentemente necessitando de flexibilidade para que se possam acompanhar as várias mudanças que podem ocorrer. O resultado do processo tem que ser o software realmente útil para o cliente (SOARES, 2004). O Scrum é baseado em princípios que são semelhantes aos do XP: requisitos pouco estáveis e desconhecidos, equipes pequenas e iterações curtas. As dimensões do Scrum são diferentes do XP. Estabelece um conjunto de regras e de práticas com o objetivo de garantir o sucesso nos projetos, realiza trabalhos em equipes, melhorando a cooperação e a comunicação dos mesmos. Também são realizadas reuniões diárias de acompanhamento do projeto, essas reuniões normalmente são curtas (aproximadamente 15 minutos) são discutidas as dificuldades encontradas, soluções, o que foi feito desde a última reunião até a atual reunião e o que será realizado posteriormente. Segundo (FERREIRA, 2005), as principais características do Scrum são: É um processo ágil para gerenciar e controlar o desenvolvimento de projetos; É um wrapper para outras práticas de Engenharia de Software; É um processo que controla o caos resultante de necessidades e interesses conflitantes; É uma forma de aumentar a comunicação e maximizar a cooperação; É uma forma de detectar e remover qualquer impedimento que atrapalhe o desenvolvimento de um produto; É escalável desde projetos pequenos até grandes projetos em toda empresa. O vocabulário que é utilizado no Scrum (BISSI, 2007): Backlog: É uma lista de todas as funcionalidades que devem ser desenvolvidas durante o projeto completo, deve ser bem definido e detalhado no início do
30 trabalho e também listado e ordenado por prioridade de execução; Sprint: Período de 2 à 4 semanas onde o projeto ou funcionalidades do mesmo são desenvolvidos. Sprint Planning Meeting: Reunião de planejamento; Sprint Goal: Disparo dos objetivos e metas; Sprint Review Meeting: Revisão da reunião; Sprint Backlog: É o trabalho a ser desenvolvido num Sprint, criando um produto para mostrar ao cliente. Seu desenvolvimento deve ser de forma incremental, relativa ao Backlog anterior se o mesmo existir; Dayling Scrum: Reunião diária; Scrum: Reunião diária sendo avaliados os progressos do projeto e as dificuldades/barreiras encontradas durante o seu desenvolvimento; Scrum Meeting: É um protocolo a seguir de modo a realizar uma reunião Scrum; Scrum Team (TeamMembers): É a equipe de desenvolvimento de um Sprint; Scrum Master: É o elemento da equipe que tem como responsabilidade a gestão do projeto bem como liderar as Scrum Meetings, os mesmos são normalmente engenheiros de software ou da área de sistemas. O fato de ser gestor não significa que tem propriamente autoridade sobre os demais membros de sua equipe; Product Backlog: Produção do trabalho executado; Product Owner: Proprietário do produto. O ciclo de vida do Scrum é dividido em três fases principais (SOARES, 2004): Pré-planejamento: Os requisitos são descritos em um documento chamado de Backlog, depois eles são priorizados e também realizada estimativas de esforço para cada requisito no seu desenvolvimento. O planejamento inclui várias atividades dentre elas os possíveis riscos do projeto e as necessidades de treinamentos. Finalmente é proposta uma arquitetura de desenvolvimento. As alterações ocorridas nos requisitos que foram descritas no Backlog são identificas juntamente com os possíveis erros;
31 Desenvolvimento: As variáveis técnicas e do ambiente são observadas e também controladas durante o desenvolvimento. No Scrum o controle de se considerar as variáveis é realizado continuamente, aumentando a flexibilidade para acompanhar mudanças. Nesta fase o software é desenvolvido em ciclos e novas funcionalidades são adicionadas. Cada ciclo é desenvolvido realizando primeiramente a análise e em seguida o projeto, implementação e os testes, com duração de aproximadamente uma semana a um mês; Pós-planejamento: Nesta fase são realizadas as reuniões com o objetivo de analisar o progresso do projeto demonstrando o software atual aos clientes. São realizados os testes finais e a documentação. 2.4 Conclusão Os modelos ágeis trazem muitos benefícios para empresas que os utilizam, pois os mesmos se preocupam muito com os indivíduos e as interações ao invés de ferramentas e processos, se preocupam em satisfazer o cliente, o mesmo sempre presente quando possível, participando do projeto e especificando o que quer exatamente em seu sistema. É um processo adaptativo que responde facilmente a mudanças no sistema. Nesse capítulo foram abordados os seguintes modelos ágeis: FDD (Feature Driven Development), DSDM (Dynamic Systems Development Methodology), Família Crystal de Modelo (Crystal Family of Methodologies), ASD (Adaptative Software Development), Extreme Programming (XP) e o Scrum, cada um com seus métodos de aplicação, funcionalidades, regras, práticas, princípios, valores entre outros, e cada um atendendo os requisitos necessários de cada projeto. Esses modelos possuem em comum o fato de os mesmos serem aplicados em projetos não muito complexos, pois utilizam curtos ciclos iterativos, tolerância a mudanças, cliente presente entre outros fatores. Os modelos ágeis reúnem práticas, gerenciamento de processos, princípios, valores entre outros, assim produzindo softwares com qualidade pelas as empresas que os utilizam, consequentemente deixando os seus clientes satisfeitos com o software.
32 A seguir são apresentados os dois modelos ágeis que foram escolhidos para realizar um estudo aprofundado e para realizar a modelagem do Sistema de Gerenciamento de TCCs. Foi escolhido primeiramente o modelo ágil Extreme Programming (XP) e posteriormente o Scrum. O motivo de escolha desses dois modelos ágeis foi por serem mais conhecidos e utilizados atualmente pelas empresas, sejam empresas grandes, médias ou pequenas e também pelo fato de estarem trazendo grande sucesso para as empresas que aplicam os mesmos.
33 3 EXTREME PROGRAMMING (XP) É um modelo ágil destinado á equipes pequenas e médias que desenvolvem softwares baseados em requisitos vagos e que se modificam rapidamente. Começou a ser desenvolvido em 1996 por Kent Beck no departamento de computação da montadora de automóveis DaimlerChrysler. Esse modelo visa o desenvolvimento rápido do projeto, garantindo a satisfação do cliente e cumprindo as estimativas, possuindo valores, princípios e práticas. O objetivo deste capítulo é descrever mais detalhadamente o modelo Extreme Programming (XP), explicando seus valores, princípios e as suas práticas, explicando a Modelagem Ágil ao longo do ciclo de vida do XP e demonstrando como o mesmo funciona, realizando a aplicação da modelagem do Sistema de Gerenciamento de TCCs do curso de Sistemas de Informação da Universidade do Planalto Catarinense (UNIPLAC) dentro desse modelo XP, demonstrando como são realizadas na prática. É utilizado para a modelagem do sistema o sumário executivo, as histórias de usuários, fluxos básicos de informação, versões de telas do Sistema de Gerenciamento de TCCs, modelo conceitual de banco de dados e modelo lógico de banco de dados. 3.1 Valores XP O XP tem como objetivo o desenvolvimento rápido do projeto satisfazendo o cliente. Possui quatro valores (BORBOREMA 2007): Retorno (feedback): Acontece um retorno constante aonde o programador terá as informações do código do cliente. Essa informação de código é dada pelos testes
34 que vai indicar os erros que podem ser individuais ou do software integrado (SOARES, 2007). O sistema é entregue ao cliente o mais breve possível para poder dar um retorno rápido ao cliente, para estar seguindo assim o desenvolvimento do software (NAPHTA, 2007); Comunicação: Procura-se o máximo possível realizar a comunicação pessoalmente com o cliente. Através dessa comunicação são realizados os detalhes do projeto que irá ser feito com agilidade, proporcionando e buscando um relacionamento entre clientes e desenvolvedores. O principal valor do XP é a comunicação, pois a maioria das práticas está baseada na comunicação para que não ocorram problemas de atrasos no desenvolvimento (NAPHTA, 2007); Simplicidade: A equipe deve entender essa importância, pois assim é possível simplificar o sistema, reduzindo número de programadores, tempo para implementação, consequentemente reduzindo o valor do projeto. Para o XP é melhor realizar algo simples hoje com um desenvolvimento rápido, gastando um pouco mais futuramente para realizar modificações necessárias, ao invés de implementar algo complicado hoje que acabe não sendo utilizado (NAPHTA, 2007). Segundo Beck (2000), existe uma relação de suporte mútuo entre a simplicidade e a comunicação, pois quanto melhor a comunicação se observa mais claramente o que precisa ser realizado, tendo mais certeza do que não precisa ser realizado; Coragem: O sistema é desenvolvido de forma incremental, a equipe sempre realiza manutenção de software e também adicionando novas funcionalidades. Pode acontecer de precisar alterar algo que estava funcionando corretamente, gerando falhas então. Nesse ponto a equipe precisa ter coragem acreditando nas práticas e
35 valores do XP que o software irá ser desenvolvido de maneira segura, correta e ágil, é necessário ter coragem para lidar com esse fator, no XP se traduzem em confiança em seus mecanismos de proteção. A comunicação oferece suporte à coragem abrindo possibilidades para experiências de alto risco e também altas recompensas. A simplicidade dá suporte à coragem, sistemas simples trazem mais segurança na questão de erros no sistema. O feedback também da suporte a coragem, pelo fato de termos a confiança para experimentar algo extremo no código, obtendo resultados positivos nos testes, ou não (BECK, 2000). 3.2 Princípios XP O XP possui alguns princípios (BORBOREMA, 2007): Feedback rápido: O tempo decorrido entre uma ação e o feedback é fundamental para o progresso do projeto e para o aprendizado da equipe, por isso o cliente deve fornecer esse feedback o mais rápido possível, assim podendo interpretá-lo e aplicar no sistema o mais rápido possível. Programadores aprendem uma melhor maneira para projetar, testar e implementar o sistema, realimentando o que já se foi aprendido em segundos e minutos (BECK, 2000); Simplicidade presumida: Devem-se tratar os problemas de uma forma mais simples o possível, no XP recomenda-se que os desenvolvedores confiem mais em suas habilidades e que os trabalhos do dia sejam resolvidos no mesmo dia; Mudanças incrementais: Dificilmente dará certo certa ocorrência de várias mudanças de uma só vez em um projeto, pois no XP o projeto é alterado em seu tempo de desenvolvimento. Toda mudança deve ser planejada e também estudada para não atrapalhar o funcionamento do sistema, o XP precisa ser realizado em pequenos passos (BECK, 2000); Aceitação das mudanças: No XP existe a aceitação das mudanças. É importante existir essa aceitação das mudanças, pois elas trazem aprendizado e o amadurecimento da equipe de desenvolvimento de software;
36 Alta qualidade: No XP a qualidade é prioridade em seus projetos sempre buscando a excelência; Ensinar aprendendo: O objetivo é ensinar estratégias para aprender, em relação a todas as coisas que devem ser realizadas (BECK, 2000); Investimento inicial pequeno: Projetos com recursos supérfluos tendem a ser um desastre, é importante ter somente os requisitos necessários. Quando o orçamento é apertado acaba forçando programadores e também os clientes a cortarem requisitos, com a concentração gerada a consequência é a realização de um bom trabalho; Jogar para ganhar: Maioria das equipes de desenvolvimento segue procedimentos em reuniões, para poderem se guardar se ocorrer futuramente falhas no projeto, pois se no final do projeto não for bem sucedido a equipe seguiu os procedimentos. O XP acredita que o desenvolvimento do software jogado para ganhar ajuda o time a chegar a excelência dos seus projetos (BECK, 2000); Experimentação concreta: Toda decisão abstrata deve ser testada, pois quanto mais se realiza testes, mais os riscos diminuem, toda decisão não testada vai existir uma grande probabilidade que esta decisão esteja errada, consequentemente deixando o cliente insatisfeito (BECK, 2000); Comunicação concreta: É um fator muito importante, pois esse princípio permite que o programador tenha a liberdade de conversar um com o outro sobre problemas nos códigos, comunicando esses problemas a gerência e clientes; Trabalhar a favor dos instintos do pessoal e não contra eles: As pessoas gostam de aprender, de interagir com as outras pessoas e de estar no controle e que as outras pessoas confiem nelas. Os desenvolvedores gostam de sempre realizar um bom trabalho para que seus softwares funcionem. O XP deve trabalhar com os interesses de curto prazo pessoal, caso contrário estará destinado ao fracasso dos modelos; Aceitação das responsabilidades: A cooperação do time depende das responsabilidades quanto as suas tarefas. A responsabilidade deve ser aceita e não sendo impostas, as necessidades do time devem ser atendidas por uma pessoa voluntária do time, por pior que ela seja (BECK, 2000);