UFSC-CTC-INE 2010 MODELOS GEIS Os modelos geis de desenvolvimento de software seguem uma filosofia diferente dos modelos prescritivos. Ao invs de apresentar uma receita de bolo com fases ou tarefas a serem executados, eles focam fases ou tarefas a serem executados, eles focam em valores humanos e sociais. MANIFESTO GIL Ns estamos descobrindo formas melhores de desenvolver software fazendo e ajudando outros a fazer. Atravs deste trabalho chegamos aos seguintes valores: Indivduos e interaes esto acima de processos e ferramentas. Software funcionando est acima de documentao Software funcionando est acima de documentao compreensvel. Colaborao do cliente est acima de negociao de contrato. Responder s mudanas est acima de seguir um plano. Ou seja, enquanto forem valorizados os itens esquerda, os itens direita valero mais. PRINCPIOS DO MANIFESTO GIL Nossa maior prioridade satisfazer o cliente atravs da entrega rpida e contnua de software com valor. Mudanas nos requisitos so bem vindas, mesmo nas etapas finais do projeto. Processos geis usam a mudana como um diferencial competitivo para o cliente. Entregar software freqentemente, com intervalos que viam de Entregar software freqentemente, com intervalos que viam de duas semanas a dois meses, preferindo o intervalo mais curto. Administradores (business people) e desenvolvedores devem trabalhar juntos diariamente durante o desenvolvimento do projeto. Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte e confie que eles faro o trabalho. O meio mais eficiente e efetivo de tratar a comunicao entre e para a equipe de desenvolvimento a conversa face a face. PRINCPIOS DO MANIFESTO GIL Software funcionando a medida primordial de progresso. Processos geis promovem desenvolvimento sustentado. Os financiadores, usurios e desenvolvedores devem ser capazes de manter o ritmo indefinidamente. Ateno contnua excelncia tcnica e bom projeto melhora a agilidade. melhora a agilidade. Simplicidade a arte de maximizar a quantidade de trabalho no feito essencial. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas. Em intervalos regulares a equipe reflete sobre como se tornar mais efetiva e ento ajusta seu comportamento de acordo. SCRUM Scrum um modelo gil para gesto de projetos de software. No Scrum um dos conceitos mais importantes o sprint, que consiste em um ciclo de desenvolvimento, usualmente de duas semanas a desenvolvimento, usualmente de duas semanas a um ms. PERFIS O Scrum master, que no um gerente no sentido dos modelos prescritivos. O Scrum master no um lder, j que as equipes so auto- organizadas, mas um facilitador (pessoa que conhece bem o modelo) e resolvedor de conflitos conhece bem o modelo) e resolvedor de conflitos O product owner, ou seja, a pessoa responsvel pelo projeto em si. O product owner tem, entre outras atribuies, a de indicar quais so os requisitos mais importantes a serem tratados em cada sprint. O product owner o responsvel pelo ROI (Return Of Investment), e tambm por conhecer e avaliar as necessidades do cliente. SCRUM TEAM a equipe de desenvolvimento. Essa equipe no necessariamente dividida em papeis como analista, projetista e programador, mas todos interagem para desenvolver o produto em conjunto. em conjunto. Usualmente so recomendadas equipes de 6 a 10 pessoas. No caso de projetos muito grandes possvel aplicar o conceito de Scrum of Scrums, onde vrios Scrum teams trabalham em paralelo e cada um contribui com uma pessoa para a formao do Scrum of Scrums, quando ento as vrias equipes so sincronizadas. PRODUCT BACKLOG As funcionalidades a serem implementadas em cada projeto (requisitos) so mantidas em uma lista chamada de product backlog. Um dos princpios das metodologias geis usado aqui: adaptao ao invs e planejamento. aqui: adaptao ao invs e planejamento. O product backlog no precisa ento ser completo no incio do projeto. Pode-se iniciar apenas com as funcionalidades mais evidentes para depois, medida que o projeto avana tratar novas funcionalidades que vo sendo descobertas. SPRINT No incio de cada sprint feito um sprint planning meeting, no qual a equipe prioriza os elementos do product backlog a serem implementados e transfere estes elementos do product backlog para o sprint backlog, ou seja, a product backlog para o sprint backlog, ou seja, a lista de funcionalidades a serem implementadas no ciclo que se inicia. A equipe se compromete a desenvolver as funcionalidades e o product owner se compromete a no trazer novas funcionalidades durante o mesmo sprint. Se novas funcionalidades forem descobertas, sero abordadas em sprints posteriores. SPRINT BACKLOG Pode-se dizer que os dois backlogs tm naturezas diferentes: O product backlog apresenta requisitos de alto nvel, bastante voltados s necessidades diretas do cliente. J o sprint backlog apresenta uma viso desses J o sprint backlog apresenta uma viso desses requisitos de forma mais voltada maneira como a equipe vai desenvolv-los. Durante o sprint, cabe ao product owner manter o sprint backlog atualizado, indicando as tarefas j concludas e as ainda por concluir, preferencialmente mostradas em um grfico atualizado diariamente e vista de todos. atualizado diariamente e vista de todos. REVIEW Ao final de cada sprint a equipe deve fazer um sprint review meeting (retrospectiva) para verificar o que foi feito e a partir da partir para uma nova sprint. O sprint review meeting avalia o sucesso do plano. O sprint review meeting avalia o sucesso do plano. DAILY SCRUM Mais importante ainda, o modelo sugere que a equipe realize uma reunio diria, chamada daily scrum, onde o objetivo que cada membro da equipe fale sobre o que fez no dia anterior, o que vai fazer no dia que se segue e, se for o caso, o que o impede de prosseguir. Essas reunies devem ser rpidas. Essas reunies devem ser rpidas. Por isso, se sugere que sejam feitas com as pessoas em p e em frente a um quadro de anotaes. Alm disso, recomenda-se que sejam feitas logo aps o almoo, quando os participantes estaro mais imersos nas questes do trabalho (longe dos problemas pessoais), alm de ser uma boa maneira de dissipar o cansao que atinge os desenvolvedores no incio da tarde. MODELO SCRUM SPRINT DEVEM SEGUIR A FILOSOFIA PDCA Plan: planejar uma meta ou identificar um problema que esteja impedindo o progresso, analisar o fenmeno ou os dados relacionados ao problema, analisar o processo, ou as causas fundamentais do problema, elaborar um plano de ao para atingir o objetivo ou resolver o problema. Do: executar as atividades previstas no plano de ao. Do: executar as atividades previstas no plano de ao. Check: avaliar e monitorar periodicamente os resultados. Avaliar os processos utilizados. Produzir relatrios, se necessrio. Act: agir de acordo com os planos ou melhorar os planos e processos se necessrio. ORIGENS A concepo inicial do Scrum deu-se na indstria automobilstica (Takeuchi & Nonaka, 1986), e o modelo pode ser adaptado a vrias outras reas diferentes da produo de software. Na rea de desenvolvimento de software, Scrum Na rea de desenvolvimento de software, Scrum deve sua popularidade inicialmente ao trabalho de Schwaber. Uma boa referncia para quem deseja adotar o mtodo o livro de Schwaber e Beedle (2001), que apresenta o mtodo de forma completa e sistemtica. XP EXTREME PROGRAMMING um modelo gil inicialmente adequado a equipes pequenas e mdias que baseado em uma srie de valores, princpios e regras. XP surgiu no final da dcada de 1990, nos Estados Unidos. Estados Unidos. VALORES Simplicidade Respeito Comunicao Feedback Coragem Coragem SIMPLICIDADE Segundo o Chaos Report (Standish Group, 1995) mais da metade das funcionalidades introduzidas em sistemas nunca so usadas. XP sugere como valor a simplicidade, ou seja, a equipe deve se concentrar nas funcionalidades equipe deve se concentrar nas funcionalidades efetivamente necessrias e no naquelas que poderiam talvez ser necessrias, mas que ainda no se tem evidncia de que so essenciais. RESPEITO Respeito entre os membros da equipe e entre a equipe e o cliente um valor dos mais bsicos, que d sustentao a todos os outros. Sem respeito a comunicao falha e o projeto afunda. afunda. COMUNICAO Em desenvolvimento de software a comunicao essencial para que o cliente consiga dizer o que realmente precisa. XP preconiza comunicao de boa qualidade, preferindo encontros presenciais ao invs de preferindo encontros presenciais ao invs de videoconferncias, videoconferncias, ao invs de telefonemas, telefonemas ao invs de emails e assim por diante. Ou seja, quanto mais pessoal e expressiva a forma de comunicao melhor. FEEDBACK O projeto de software reconhecidamente um empreendimento de alto risco. Cientes disso, os desenvolvedores devem buscar obter feedback o quanto antes para que eventuais falhas de comunicao sejam corrigidas o mais falhas de comunicao sejam corrigidas o mais rapidamente possvel antes que os danos se alastrem e o custo da correo seja alto. CORAGEM Pode-se dizer que a nica coisa constante no projeto de um software a necessidade de mudana. Para os desenvolvedores XP necessrio confiar nos mecanismos de gerenciamento da mudana nos mecanismos de gerenciamento da mudana para ter a coragem de abraar as inevitveis modificaes ao invs de simplesmente ignor- las, por estarem eventualmente fora do contrato formal, ou por serem muito difceis de acomodar. PRINCPIOS SO DEFINIDOS A PARTIR DOS VALORES Priorizao de funcionalidades mais importantes de forma que, se o trabalho no puder ser todo concludo, pelo menos as partes mais importantes tero sido. Mudanas incrementais, feedback rpido, e Mudanas incrementais, feedback rpido, e considerar a mudana como algo positivo, que deve ser considerado parte do processo. Qualidade: pequenos ganhos a curto prazo pelo sacrifcio da qualidade no so compensados pelas perdas a mdio e longo prazo PRTICAS Jogo de planejamento Metfora Equipe coesa Reunies em p Projeto simples Desenvolvimento orientado a testes Refatorao Integrao contnua Projeto simples Verses pequenas Ritmo sustentvel Posse coletiva Programao em pares Padres de codificao Testes de aceitao JOGO DE PLANEJAMENTO (PLANNING GAME) Semanalmente a equipe deve se reunir com o cliente para priorizar as funcionalidades a serem desenvolvidas. Cabe ao cliente identificar as principais necessidades e equipe de desenvolvimento necessidades e equipe de desenvolvimento estimar quais podem ser implementadas no ciclo semanal que se inicia. Ao final da semana essas funcionalidades so entregues ao cliente. Esse tipo de modelo de relacionamento com o cliente adaptativo, em oposio aos contratos rgidos usualmente estabelecidos. METFORA (METAPHOR) preciso conhecer a linguagem do cliente e seus significados. A equipe deve aprender a se comunicar com o cliente na linguagem que ele compreende. EQUIPE COESA (WHOLE TEAM) O cliente faz parte da equipe de desenvolvimento. REUNIES EM P (STAND-UP MEETING). Como no caso de Scrum, reunies em p tendem a serem mais objetivas. PROJETO SIMPLES (SIMPLE DESIGN) Isso implica em atender a funcionalidade solicitada pelo cliente sem sofisticar desnecessariamente. Deve-se fazer o que o cliente precisa, no o que o desenvolvedor gostaria que ele precisasse. desenvolvedor gostaria que ele precisasse. Por vezes, projeto simples pode ser confundido com projeto fcil. Nem sempre o projeto simples o mais fcil de implementar. O projeto fcil pode no atender s necessidades, ou pode gerar problemas de arquitetura. VERSES PEQUENAS (SMALL RELEASES) A liberao de verses pequenas do sistema pode ajudar o cliente a testar as funcionalidades de forma contnua. XP leva ao extremo este princpio, sugerindo verses ainda menores do que as de outros verses ainda menores do que as de outros processos incrementais como UP. RITMO SUSTENTVEL (SUSTAINABLE PACE). Trabalhar com qualidade um nmero razovel de horas por dia (no mais do que 8). Horas extras s so recomendadas quando efetivamente trouxerem um aumento de produtividade, mas no podem ser rotina. produtividade, mas no podem ser rotina. POSSE COLETIVA (COLLECTIVE OWNERSHIP) O cdigo no tem dono e no necessrio pedir permisso a ningum para modific-lo. PROGRAMAO EM PARES (PAIR PROGRAMMING) A programao sempre feita por duas pessoas em cada computador. Usualmente trata-se de um programador mais experiente e um aprendiz. O aprendiz deve usar a mquina enquanto o mais O aprendiz deve usar a mquina enquanto o mais experiente o ajuda a evoluir em suas capacidades. Com isso, o cdigo gerado ter sempre sido verificado por pelo menos duas pessoas, reduzindo drasticamente a possibilidade de erros. PADRES DE CODIFICAO (CODING STANDARDS) A equipe deve estabelecer e seguir padres de codificao, de forma que parecer que o cdigo foi todo desenvolvido pela mesma pessoa, mesmo que tenham sido dezenas. TESTES DE ACEITAO (CUSTOMER TESTS) So testes planejados e conduzidos pela equipe em conjunto com o cliente para verificar se determinados requisitos foram atendidos. DESENVOLVIMENTO ORIENTADO A TESTES (TEST DRIVEN DEVELOPMENT) Antes de programar uma unidade deve-se estabelecer os testes pelos quais ela dever passar. REFATORAO (REFACTORING) No se deve fugir da refatorao quando necessria. Ela permite manter a complexidade do cdigo em um nvel gerencivel. um investimento que traz benefcios a mdio e um investimento que traz benefcios a mdio e longo prazo. INTEGRAO CONTNUA (CONTINUOUS INTEGRATION) Nunca esperar at ao final do ciclo para integrar uma nova funcionalidade. Assim que estiver vivel ela deve ser integrada ao sistema para evitar surpresas. REGRAS XP Wells (2009) vai mais alm das prticas XP apontando um conjunto sucinto e bastante objetivo de regras para XP. Ele divide as regras em 5 grandes grupos: Planejamento Planejamento Gerncia Projeto Codificao Teste REGRAS XP DE PLANEJAMENTO Escrever histrias de usurio O planejamento de entregas cria o cronograma de entregas Faa entregas pequenas freqentes O projeto dividido em iteraes O projeto dividido em iteraes O planejamento da iterao inicia cada iterao ESCREVER HISTRIAS DE USURIO Servem ao mesmo propsito de casos de uso, mas no so a mesma coisa. So usadas no lugar do documento de requisitos. Devem ser escritas pelos usurios como sendo as coisas que eles precisam que o sistema faa para coisas que eles precisam que o sistema faa para eles. Podem ser usadas para definir os testes de aceitao. ESCREVER HISTRIAS DE USURIO A equipe deve estimar se a histria pode ser implementada em uma, duas ou trs semanas. Tempos maiores do que este significam que a histria deve ser subdividida em duas ou mais histrias. histrias. Menos de uma semana significa que a histria est em um nvel de detalhe muito alto e precisa ser combinada com outras. Como as histrias so escritas pelo cliente, espera-se que no sejam contaminadas com aspectos tcnicos e de interfaces. O PLANEJAMENTO DE ENTREGAS CRIA O CRONOGRAMA DE ENTREGAS feito um encontro de planejamento de entregas para delinear o projeto como um todo. importante que os tcnicos tomem as decises tcnicas e os administradores as decises de negcio. negcio. Deve-se estimar o tempo de cada histria de usurio em termos de semanas de programao ideais e priorizar as histrias mais importantes do ponto de vista do cliente. Uma semana de programao ideal aquela em que uma pessoa trabalha todas as horas da semana unicamente em um projeto, dedicando-se apenas a ele. O PLANEJAMENTO DE ENTREGAS CRIA O CRONOGRAMA DE ENTREGAS As histrias so agrupadas em iteraes, que s so planejadas pouco antes de iniciarem. Essa priorizao pode ser feita com histrias impressas em cartes que so movidos na mesa ou num quadro para indicar prioridades. ou num quadro para indicar prioridades. FAA ENTREGAS PEQUENAS FREQENTES Algumas equipes entregam software diariamente, mas no pior caso, deveria acontecer a cada uma ou duas semanas. A deciso de colocar a entrega em operao ou no do cliente. no do cliente. O PROJETO DIVIDIDO EM ITERAES Prefira iteraes de uma a duas semanas. No planeje as atividades com muita antecedncia. Deixe para planejar a iterao pouco antes de ela iniciar. iniciar. Planejamento just-in-time uma forma de estar sempre sintonizado com as mudanas de requisitos e arquitetura. No tente implementar coisas que viro depois. Leve os prazos a srio. O PROJETO DIVIDIDO EM ITERAES Acompanhe a produtividade. Se perceber que no vai vencer o cronograma, convoque uma nova reunio de planejamento de entregas e repasse algumas entregas para outros ciclos. ciclos. Concentre-se em completar as tarefas, e no em deixar vrias coisas inacabadas. O PLANEJAMENTO DA ITERAO INICIA CADA ITERAO No planejamento, que inicia cada iterao seleciona-se as histrias de usurio mais importantes a serem desenvolvidas e partes de sistema que falharam em testes de aceitao, os quais so quebrados em tarefas de programao. quais so quebrados em tarefas de programao. As tarefas sero escritas em cartes, assim como as histrias de usurio. Enquanto as histrias de usurio esto na linguagem do cliente, as tarefas de programao esto na linguagem dos desenvolvedores. O PLANEJAMENTO DA ITERAO INICIA CADA ITERAO Cada desenvolvedor que seleciona uma tarefa estima quanto tempo ela levar para ser concluda. Tarefas devem ser estimadas em um, dois ou trs dias ideais de programao. dias ideais de programao. Um dia ideal de programao uma jornada de trabalho normal em que uma pessoa dedique-se unicamente ao projeto. REGRAS XP DE GERENCIAMENTO D equipe um espao de trabalho aberto e dedicado Defina uma jornada sustentvel Inicie cada dia com uma reunio em p A velocidade do projeto medida A velocidade do projeto medida Mova as pessoas Conserte XP quando for inadequado D EQUIPE UM ESPAO DE TRABALHO ABERTO E DEDICADO importante eliminar barreiras fsicas entre os membros da equipe para melhorar a comunicao. Sugere-se colocar os computadores em um espao central para a programao em pares e mesas central para a programao em pares e mesas nas laterais da sala para que pessoas que precisem trabalhar a ss no se desconectem do ambiente. Inclua uma rea para as reunies em p com um quadro branco e uma mesa de reunies DEFINA UMA JORNADA SUSTENTVEL Trabalhar alm da jornada normal desgastante e desmoralizante. Se o projeto atrasa melhor reprogramar as tarefas em uma release planning meeting. Descubra a velocidade ideal para sua equipe e Descubra a velocidade ideal para sua equipe e atenha-se a ela. No tente fazer uma equipe trabalhar na velocidade de outra. Faa planos realistas. INICIE CADA DIA COM UMA REUNIO EM P Em uma reunio tpica nem sempre todos contribuem, mas pelo menos ouvem. Mantenha o mnimo de pessoas o mnimo de tempo em reunies. As reunies em p no so perda de tempo, mas As reunies em p no so perda de tempo, mas uma forma rpida de manter a equipe sincronizada, pois cada um dir o que fez ontem, o que vai fazer hoje e o que o impede de prosseguir. A VELOCIDADE DO PROJETO MEDIDA Conta-se ou estima-se quantas histrias de usurio e tarefas de programao so desenvolvidas em cada iterao. A cada encontro de planejamento de iterao os clientes podem selecionar um nmero de clientes podem selecionar um nmero de histrias de usurio igual estimativa de velocidade do projeto. O mesmo vale para os programadores em relao s tarefas de programao. Isso permite que a equipe se recupere de eventuais iteraes difceis. Aumentos e diminuies de velocidade so esperadas. MOVA AS PESSOAS Mobilidade de pessoas em projetos importante para evitar perda de conhecimento e gargalos de programao. Ficar na dependncia de um nico funcionrio perigoso. perigoso. Deve-se evitar criar ilhas de conhecimento porque elas so susceptveis a perda. Se precisar de conhecimento especializado, contrate um consultor por prazo determinado. CONSERTE XP QUANDO FOR INADEQUADO No hesite em mudar aquilo que no funciona em XP. Isso no significa que se pode fazer qualquer coisa. Segue-se as regras at que se perceba que elas Segue-se as regras at que se perceba que elas precisam ser mudadas. Todos os desenvolvedores devem saber o que se espera deles e o que eles esperam dos outros. A existncia de regras a melhor forma de garantir isso. REGRAS XP DE PROJETO (DESGIN) Simplicidade Escolha uma metfora de sistema Use Cartes CRC durante reunies de projeto Crie solues afiadas para reduzir risco Nenhuma funcionalidade adicionada cedo Nenhuma funcionalidade adicionada cedo Use refatorao sempre e onde for possvel SIMPLICIDADE Um projeto simples sempre executado mais rpido do que um projeto complexo. Porm, simplicidade subjetiva e difcil de ser medida. Ento a equipe que deve decidir o que Ento a equipe que deve decidir o que simples. Uma das melhores formas de obter simplicidade em um projeto levar a srio o Design Pattern Alta Coeso (Wazlawick, 2004). QUALIDADES PARA OBTER SIMPLICIDADE Testabilidade Browseabilidade Compreensibilidade e Explicabilidade TESTABILIDADE Pode-se escrever testes de unidade para verificar se o cdigo est correto. O sistema deve ser quebrado em unidades testveis. BROWSEABILIDADE Pode-se encontrar os elementos quando se precisa deles. Bons nomes e uso de boas disciplinas como polimorfismo, herana e delegao ajudam nisso. COMPREENSIBILIDADE E EXPLICABILIDADE Compreensibilidade uma qualidade subjetiva porque um sistema pode ser bastante compreensvel para quem est trabalhando nele, mas difcil para quem est de fora. Ento essa propriedade pode ser definida em Ento essa propriedade pode ser definida em termos de quo fcil explicar o sistema para quem no participou do desenvolvimento. ESCOLHA UMA METFORA DE SISTEMA Uma boa metfora de sistema ajuda a explicar seu funcionamento a algum de fora do projeto. Deve-se evitar que a compreenso sobre o sistema resida em pilhas de documentos. Nomes significativos e padres de nomeao de Nomes significativos e padres de nomeao de elementos de programa devem ser cuidadosamente escolhidos e seguidos para que fragmentos de cdigo sejam efetivamente reusveis. USE CARTES CRC DURANTE REUNIES DE PROJETO Trata-se de uma tcnica para encontrar responsabilidades e colaboraes entre objetos. A equipe se rene em torno de uma mesa e cada membro recebe um ou mais cartes representando instncias de diferentes classes. representando instncias de diferentes classes. Uma atividade (operao ou consulta) simulada e a medida que ela ocorre os detentores dos cartes anotam responsabilidades do objeto no lado esquerdo do carto e colaboraes do objeto no lado direito. A documentao dos processos pode ser feita com diagramas de seqncia ou de comunicao da UML. CRIE SOLUES AFIADAS PARA REDUZIR RISCO Em face de riscos importantes de projeto deve-se explorar o risco de forma definitiva e exclusiva, ou seja, uma soluo afiada ou spike para o problema identificado. Um spike ento um desenvolvimento ou teste projetado especificamente para analisar e possivelmente resolver um risco. possivelmente resolver um risco. Caso o risco se mantenha, deve-se colocar um par de programadores durante uma ou duas semanas exclusivamente trabalhando para examinar e mitigar este risco. A maioria dos spikes no sero aproveitados no projeto, podendo ser classificados como uma das formas de prototipao (throw-away). NENHUMA FUNCIONALIDADE ADICIONADA CEDO Deve-se evitar a tentao de adicionar funcionalidade desnecessria s porque seria fcil fazer isso agora e deixaria o sistema melhor. Apenas o necessrio feito no sistema. Desenvolver o que no necessrio jogar tempo Desenvolver o que no necessrio jogar tempo fora. Manter o cdigo aberto a possveis mudanas futuras tem a ver com simplicidade de projeto, mas adicionar funcionalidade ou flexibilidade desnecessria, sempre deixa o projeto mais complexo. Requisitos futuros s devem ser considerados quando estritamente exigidos pelo cliente. USE REFATORAO SEMPRE E ONDE FOR POSSVEL Refatore sem pena. XP no recomenda que se continue usando design antigo e ruim s porque ele funciona. Deve-se remover redundncias, eliminar funcionalidades desnecessrias e rejuvenecer funcionalidades desnecessrias e rejuvenecer designs antiquados. REGRAS XP PARA CODIFICAO DE PROGRAMAS O cliente est sempre disponvel O cdigo deve ser escrito de acordo com padres aceitos Escreva o teste de unidade primeiro Todo o cdigo produzido por pares Todo o cdigo produzido por pares S um par faz integrao de cdigo de cada vez Integrao deve ser freqente Defina um computador exclusivo para integrao A posse do cdigo deve ser coletiva O CLIENTE EST SEMPRE DISPONVEL XP necessita que o cliente esteja disponvel preferencialmente pessoalmente ao longo de todo o processo de desenvolvimento. Entretanto, devido ao longo tempo de um projeto, a empresa cliente pode ser tentada a associar um funcionrio pouco experiente ou estagirio ao projeto. Ele no serve. pouco experiente ou estagirio ao projeto. Ele no serve. Deve ser um especialista. Ele dever escrever as histrias de usurio, bem como prioriz-las e negociar sua incluso em iteraes. Pode parecer um investimento alto em tempo de funcionrios, mas compensado por ser desnecessrio um levantamento de requisitos detalhado ao incio, bem como pela no entrega de um sistema inadequado. O CDIGO DEVE SER ESCRITO DE ACORDO COM PADRES ACEITOS Padres de codificao mantm o cdigo compreensvel e passvel de refatorao por toda a equipe. Alm disso, cdigo que se parece encoraja a posse coletiva do mesmo. coletiva do mesmo. ESCREVA O TESTE DE UNIDADE PRIMEIRO Usualmente, escrever o teste antes do cdigo ajuda a escrever o cdigo melhor. O tempo para escrever o teste e cdigo passa a ser o mesmo que se gastaria para escrever apenas o cdigo. apenas o cdigo. TODO O CDIGO PRODUZIDO POR PARES Embora parea contra-sensual, duas pessoas trabalhando em um computador produzem tanto cdigo quanto duas pessoas trabalhando separadamente, mas com mais qualidade. Embora seja recomendado que haja um Embora seja recomendado que haja um programador mais experiente, a relao no deve ser de professor/aluno, mas de iguais. S UM PAR FAZ INTEGRAO DE CDIGO DE CADA VEZ A integrao em paralelo pode trazer problemas de compatibilidade imprevistos, pois duas partes do sistema que nunca foram testadas juntas acabam sendo integradas sem serem testadas. Deve haver verses claramente definidas do Deve haver verses claramente definidas do produto. Ento, para que equipes trabalhando em paralelo no tenham problemas na hora de integrar seu cdigo ao produto, elas devem esperar a sua vez. Deve-se estabelecer turnos de integrao que sejam obedecidos. INTEGRAO DEVE SER FREQENTE Desenvolvedores devem estar integrando cdigo ao repositrio a cada poucas horas. Postergar integrao pode agravar o problema de todos estarem trabalhando em verses desatualizadas do sistema. desatualizadas do sistema. DEFINA UM COMPUTADOR EXCLUSIVO PARA INTEGRAO Este computador funciona como uma ficha de exclusividade (token) para a integrao. A existncia dele no ambiente de trabalho permite que toda a equipe veja quem est integrando funcionalidade e qual a funcionalidade. O resultado da integrao deve passar nos testes de unidade, de O resultado da integrao deve passar nos testes de unidade, de forma que se obtm estabilidade em cada verso e localidade nas mudanas e possveis erros. Se os testes de unidade falharem, a unidade deve ser depurada. Se a atividade de integrao levar mais do que cerca de dez minutos, porque a unidade ainda precisa de alguma depurao adicional antes de ser integrada. Neste caso, a integrao deve ser abortada, retornando o sistema ultima verso estvel, e a depurao da unidade deve seguir sendo feita pelo par. A POSSE DO CDIGO DEVE SER COLETIVA No devem ser criados gargalos pela existncia de donos de cdigo. Todos devem ter autorizao para modificar, consertar ou refatorar partes do sistema. Para isso funcionar os desenvolvedores devem Para isso funcionar os desenvolvedores devem sempre desenvolver os testes de unidade juntamente com o cdigo, seja novo ou modificado. Desta forma existe sempre uma garantia de que o software satisfaz as condies de funcionamento. No ter um dono de partes do sistema tambm diminui o impacto da perda de membros da equipe. REGRAS XP PARA TESTE DE SOFTWARE Todo o cdigo deve ter testes de unidade Todo cdigo deve passar pelos testes de unidade antes de ser entregue Quando um erro de funcionalidade encontrado, testes so criados testes so criados Testes de aceitao so executados com freqncia e os resultados so publicados TODO O CDIGO DEVE TER TESTES DE UNIDADE Esta uma das pedras fundamentais do XP. Inicialmente o desenvolvedor XP deve criar ou obter um framework de teste de unidade. Depois ele deve testar todas as classes do sistema, ignorando usualmente os mtodos bsicos triviais como getters e setters. getters e setters. Testes de unidade favorecem a posse coletiva do cdigo porque protegem o cdigo de ser acidentalmente danificado. Um bom local para baixar frameworks para testes de unidade para vrias linguagens http://www.xprogramming.com/software. Alm disso, em http://www.junit.org/ pode-se encontrar o JUnit, que vem se tornando um padro para desenvolvimento dirigido por testes em Java. TODO CDIGO DEVE PASSAR PELOS TESTES DE UNIDADE ANTES DE SER ENTREGUE Exigir que o cdigo passe por todos os testes de unidade antes de ser integrado ajuda a garantir que sua funcionalidade est corretamente implementada. Os testes de unidade tambm favorecem a Os testes de unidade tambm favorecem a refatorao, porque protegem o cdigo de mudanas indesejadas de funcionalidade. A introduo de nova funcionalidade dever provocar a adio e mais testes no teste de unidade especfico. QUANDO UM ERRO DE FUNCIONALIDADE ENCONTRADO, TESTES SO CRIADOS Um erro de funcionalidade identificado exige que testes de aceitao sejam criados para proteger o sistema. Assim, os clientes explicam claramente aos desenvolvedores o que eles esperam que seja desenvolvedores o que eles esperam que seja modificado. TESTES DE ACEITAO SO EXECUTADOS COM FREQNCIA E OS RESULTADOS SO PUBLICADOS Testes de aceitao so criados a partir de histrias de usurio. Durante uma iterao, as histrias de usurio selecionadas sero traduzidas em testes de aceitao. aceitao. Estes testes so do tipo caixa preta e representam uma ou mais funcionalidades desejadas. Testes de aceitao devem ser automatizados, de forma que possam ser executados com freqncia. BIBLIOGRAFIA Beck, K. et al. (2001). Manifesto for Agile Software Development. Disponvel em: http://agilemanifesto.org/. Consultado em: 08/03/2010. Standish Group (1995). Chaos Report. Acessvel em: http://www.projectsmart.co.uk/docs/chaos-report.pdf. Consultado em: 10/03/2010. Consultado em: 10/03/2010. Takeuchi, H., Nonaka, I. (1986). The new product development game. Harvard Business Review 137-146. January-February. Wazlawick, R. S. (2004). Anlise e Projeto de Sistemas de Informao Orientados a Objetos. Rio de Janeiro: Elsevier. Wells, D. (2009). The Rules of Extreme Programming. Disponvel em: http://www.extremeprogramming.org/rules.html. Acessado em 10/03/2010.