Home

agile - desenvolvimento de software com entregas frequentes e foco

1. A programa o em par cria um espa o para aprendizado cont nuo dentro da equipe 60 O trabalho em par tamb m pode ser mais eficiente para disseminar conhecimento do que documenta es uma vez que n o se limita ao que est escrito e porque h troca de conhecimento entre ambas as partes importante por m diferenciar programa o e par de mentoria 1 a rela o da programa o n o de estudante e professor mas em vez disso uma rela o 85 4 10 Revis o de C digo Casa do C digo de duas pessoas trabalhando juntas Se h uma diferen a muito elevada no n vel de conhecimento de dois profissionais trabalhando em par provavelmente o que vai acontecer que um deles ir ensinar o outro na maior parte do tempo criando assim uma rela o que caracterizaria mais mentoria do que com programa o em par A mentoria tamb m sem d vida uma pr tica muito v lida e importante em uma equipe de desenvolvimento de software mas importante separar um conceito do outro e estar ciente de que a mentoria geralmente n o resulta na mesma pro dutividade da programa o em par e que muitas vezes um investimento mais de longo prazo comparado com a programa o em par Em suma os principais ben ficos da programa o s o melhor qualidade equipe mais motivada mais confian a e trabalho em equipe dissemina o de conheci mento e aprendizado cont nuo 33 Miro SEM PROGRAMA O EM PAR
2. 33 3 1 Disseminando a Vis o do Projeto Casa do C digo Muitas equipes mant m uma breve descri o da vis o como por exemplo a res posta das tr s perguntas acima em um wiki ou portal interno ou at mesmo im presso e anexado ao quadro da equipe O importante que esteja ao alcance de todos Os vision rios devem estar presentes nos momentos de tomada de decis o nas reuni es de planejamento nas apresenta es de demonstra o das itera es ou reu ni es de revis o Se isso n o acontecer provavelmente a equipe n o entender o prop sito do produto que est o desenvolvendo Poder amos comparar isso a um m dico que faz uma cirurgia que n o sabe de que mal est tentando livrar o paci ente Equipes de desenvolvimento de software tomam milhares de pequenas decis es todos os dias e sem uma boa vis o geral e contexto do que est sendo constru do muito dif cil tomar boas decis es Como grande parte das equipes geis adotam um nico representante da vis o do produto de agora em diante o vision rio ser referido como Product Owner ou PO SER QUE TODOS EST O NA MESMA P GINA Marc Benioff CEO da Salesforce com conta que um certo dia esta vam no elevador um testador um engenheiro e um desenvolvedor de sua empresa De repente algu m de outro conjunto entrou no elevador e per guntou a eles o que exatamente a Salesforce com faz Para a surpresa do CEO cada um deu uma resposta difer
3. poss vel responder rapidamente s mudan as e realizar as adapta es que forem necess rias para que o software seja entregue com o m ximo grau de qualidade e efici ncia Nos m todos geis os projetos s o divididos em itera es curtas que geralmente t m uma ou algumas poucas semanas de dura o A cada itera o realizada uma reuni o de planejamento para definir o que ser feito durante a itera o O seu ob jetivo identificar junto ao cliente o que poder agregar mais valor ao neg cio O processo de planejamento no m todo XP chamado de Jogo do Planeja mento no Scrum simplesmente de Planejamento O objetivo do jogo do planeja mento garantir que o m ximo de valor poss vel ser gerado no dia a dia de trabalho atrav s da criatividade e das habilidades da equipe O planejamento da itera o acontece em uma reuni o no in cio de cada itera o importante que nesta reuni o estejam presentes a equipe de desenvolvimento e o cliente Assume se que o cliente tem toda a informa o necess ria no que diz res peito ao que agrega valor ao software e que a equipe de desenvolvimento tem toda a informa o necess ria em rela o a quanto custa para agregar tal valor A grande sacada minimizar os custos e maximizar o valor agregado Atra v s da estimativa os desenvolvedores podem dizer quanto custa em outras pala vras quanto tempo leva para desenvolver determinada funcionalidade e atrav s da p
4. e C digo dentro dos padr es de codifica o e C digo revisado ou feito em par e C digo integrado no sistema de controle de vers o Documenta o de arquitetura atualizada 80 Casa do C digo Cap tulo 4 Entregando Valor e Testes de unidade realizados e Testes de aceita o realizados Testes explorat rios realizados Nenhum defeito conhecido pendente e PO aceitou na hist ria e Manual do Usu rio atualizado importante que essa defini o seja escrita e que fique dispon vel e vis vel para todos Isso evita que por exemplo uma hist ria de usu rio seja dada como pronta mas a documenta o para o usu rio final n o tenha sido escrita ainda e que ent o esse trabalho pendente seja empurrado de uma itera o para a outra por m n o seja considerado nas estimativas fazendo com que um falso senso de baixa produtividade permeie o ambiente Al m disso a defini o tamb m importante para que haja um mesmo enten dimento do significado de pronto para todos os membros do time e para que nada de importante seja esquecido ou deixado de lado A mesma ideia pode ser aplicada para al m das hist rias de usu rios tamb m para itera es e releases Geralmente entende se que uma itera o est pronta ao fim de um intervalo de tempo predefinido mas pode ser interessante que determinadas atividades sejam realizadas antes de se dar uma itera o como pronta como por exemplo fazer deploy em u
5. realizado no produto interessante reunir todos os envolvidos no projeto para uma reuni o de demonstra o Nessa reuni o a equipe apresenta o que h de novo no produto demonstrando as novas funcionalidades No Scrum essa reuni o chama Sprint Review Meeting Nas Reuni es de Demonstra o apresenta es de Power Point n o s o recomen dadas 18 em vez disso apresenta se o software em funcionamento Funcionalida des que n o est o prontas n o devem ser demonstradas Durante a reuni o os interessados no produto podem fazer coment rios ob serva es e manifestar desejos de mudan as nas funcionalidades apresentadas tudo isso pode ser anotado e tratado posteriormente pelo Product Owner Para uma itera o de 1 m s Ken Schwaber recomenda um tempo maximo de 1 hora de prepara o e 4 horas de dura o 55 O Product Owner n o precisa necessariamente aguardar at a reuni o de de monstra o para ver o incremento a ser feito no software e dar feedback a equipe Algumas equipes tem a pr tica de Just in Time Reviews 46 isso assim que a hist ria ficar pronta a equipe se re ne com o Product Owner para uma r pida de monstra o 5 4 MELHORIA CONT NUA COM RETROSPECTIVAS Cada equipe nica e possui caracter sticas diferentes nenhum processo perfeito e raramente cobrir todas as necessidades de uma equipe ou projeto Por essa ra z o necess rio trabalhar continuamente na melhori
6. 64 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio EXEMPLO DE INJE O DE FUNCIONALIDADE Para aumentar o n mero de visitantes no meu site como um publici t rio e aqui entram as op es Para aumentar o n mero de visitantes no meu site como um publici t rio eu quero integrar nosso site com o Facebook Para aumentar o n mero de visitantes no meu site como um publici t rio eu quero publicar not cias diariamente Para aumentar o n mero de visitantes no meu site como um publici t rio eu quero otimizar o site para mecanismos de buscas Note que o valor permanece mas a funcionalidade pode mudar Por isso im portante que o time foque em obter o valor de neg cio e n o a funcionalidade 3 Encontre Exemplos Agora preciso encontrar as vari veis que podem afetar o resultado ou seja expandir o escopo e com a Inje o de Funcionalidades Isso feito atrav s de exem plos trabalhar com exemplos uma tima forma de verificar se as premissas dos requisitos s o de fato v lidas Comece com os exemplos mais simples depois parta para os mais espec ficos e complicados Busque exemplos espec ficos e n o generalizados Procure por cen rios por casos reais horas de buscar os quandos os ses os naquele caso os em particular etc Pe a exemplos reais para as pessoas de neg cio A Inje o de Funcionalidade permite que voc n o se comprometa cedo demais como uma
7. Albert Einstein Enquanto muitos de n s passa a vida reclamando que as coisas n o s o da forma como gostar amos que fossem que os pol ticos s o corruptos que a empresa chata que o mercado est dominado por mercen rios ou seja l o que for que n o est bem Mahatma Gandhi foi um verdadeiro exemplo deixando nos essa filosofia Seja a mudan a que voc quer ver no mundo Agilidade tem a ver com Melhoria Cont nua E nada melhora se permanecer como est As coisas melhoram quando mudam Ent o para melhorar pessoas times e organiza es precisam melhorar continuamente para evitar falhas e evoluir sempre A Gest o 3 0 traz uma abordagem sist mica para Gest o 3 0 que consiste em 10 1 Considerar o sistema Uma rede social complexa e adaptativa Ela vai se adaptar s suas a es e voc tamb m deve se adaptar rede social como dan ar com o sistema 2 Considerar os indiv duos Saiba que as pessoas s o a parte crucial do sistema social e que elas s o diferentes umas das outras N o h uma abordagem nica que sirva para todos Simplesmente pedir para que as pessoas mudem raramente suficiente A diversidade o que faz sistemas complexos funcionarem e por isso que trabalhar com uma diversidade de m todos crucial para lidar com as pessoas 3 Considerar as intera es Um comportamento se espalha atrav s de um sistema complexo Em uma rede social tudo gira em torno de indiv duos
8. COMMITTED BUT YOU D ONLY BE INVOLVED DON T KNOW WHAT WOULD WE CALL IT 8y Clark amp Vizdos E 2006 implementingscrum com Figura 3 2 Porcos e Galinhas A galinha diz para o Porco Ei Porco eu estava pensando N s dever amos abrir um restaurante juntos O porco responde N o sei n o Qual seria o nome A galinha responde Que tal Ovos com Bacon O porco responde N o obrigado Eu estaria comprometido e voc estaria apenas en volvida No Scrum todos as atividades de gest o do projeto s o dividas entre os pap is de Scrum Master Product Owner e Time essas s o as pessoas comprometidas como o projeto O Scrum defende que aqueles que est o comprometidos devem ter autonomia para fazer o que for preciso para o sucesso do projeto e que aqueles que est o apenas envolvidos n o fa am interven es desnecess rias Na reuni o di ria por exemplo no Scrum as galinhas n o podem falar fazer observa es fazer caretas ou intervir se quiserem participar devem ficar na periferia apenas com ouvintes Isso permite que o time fique focado no que importante sem explica es ou debates desneces s rios 3 5 Limitando o Trabalho em Progresso Casa do C digo 3 5 LIMITANDO O TRABALHO EM PROGRESSO Pare de come ar e comece a Terminar Sterling Mortensen Discutimos anteriormente que estoque em desenvolvimento de software re presentado por trabalho que foi come
9. N O H AGILIDADE Martin Fowler uma das personalidades mais respeitadas no mundo do desenvolvimento de software escreveu um artigo em 2006 levantando alguns dos principais enganos sobre programa o em par Fowler esclarece em seu artigo que n o necess rio programar em par para estar praticando um processo gil 29 nem mesmo se pode di zer que para aplicar Extreme Programming voc obrigado a programar em par O m ximo que se pode dizer que algu m que quer aprender XP deve tentar programar em par e ver se funciona em seu caso em par ticular A programa o em par n o nem mesmo citada no manifesto gil por m uma pr tica altamente recomendada para que se alcance os princ pios geis 4 10 REVIS O DE C DIGO A revis o de c digo consiste em um ou mais desenvolvedores lerem o c digo fonte com o objetivo de assegurar a qualidade do c digo e aprender no processo Especi almente na implementa o de hist rias que n o foram desenvolvidas com progra ma o em par recomenda se a pr tica de revis o de c digo A revis o de c digo melhora sua qualidade e reduz a taxa de defeitos 31 As revis es s o oportunidades n o apenas de se prevenir erros no c digo mas tamb m 86 Casa do C digo Cap tulo 4 Entregando Valor de compartilhar e disseminar o conhecimento entre os integrantes do time Ao revi sar o c digo algu m pode descobrir boas pr ticas que n o conhecia ou e
10. O bom relacionamento entre os membros da equipe considerado crucial e por isso a agilidade do ambiente estimula o trabalho em equipe a colabora o e a comu nica o constante As equipes geralmente s o formadas por pessoas com diferentes pap is que se responsabilizam juntas pelo resultado do trabalho que realizam Processos s o realizados por pessoas e as ferramentas s o utilizadas por pessoas Se a intera o entre elas n o estiver flu da e bem equilibrada provavelmente a efic cia dos processos e ferramentas ser comprometida Por isso nos m todos geis as pessoas est o em primeiro lugar Outro fator importante que excelentes ferramen tas e processos sem pessoas excelentes envolvidas muito provavelmente produzir o um resultado med ocre em vez de excelente 19 Por outro lado importante ressaltar que as ferramentas tamb m s o impor tantes apenas n o s o mais importantes do que as pessoas Essa l gica vale para todos os valores do manifesto o elemento da esquerda mais importante do que o da direita por m o da direita tamb m importante e relevante O segundo valor software em funcionamento mais que documenta o abran gente uma resposta a projetos tradicionais em que por serem realizados por fases costumava se passar meses produzindo apenas documenta o que por si s n o agrega muito valor ou talvez nenhum valor ao cliente Casa do C digo Cap tulo 1 Introdu o M
11. algo bin rio tratar como dessa forma aliena as outras pessoas 121 61 A Gest o pode ser gil Casa do C digo que consideram n o ter autoridade de se responsabilizar pelos problemas da orga niza es j que n o minha responsabilidade Devemos escolher o n vel certo de empoderamento 1 2 3 4 5 6 7 Contar N vel 1 Voc o gerente toma a decis o e anuncia s pessoas Vender N vel 2 Voc toma a decis o mas tenta ganhar o compromisso das pes soas vendendo sua ideia para as pessoas Consultar N vel 3 Voc ouve as opini es das pessoas e depois toma uma deci Sao Concordar N vel 4 Voc convida as pessoas para uma discuss o e entra em um acordo com elas chega a um consenso Neste n vel sua voz igual a dos outros Aconselhar N vel 5 Voc tenta influenciar as pessoas dizendo a elas sua opini o mas deixa a elas a responsabilidade de tomar uma decis o Questionar N vel 6 Voc permite que as pessoas decidam antes mas depois pede a elas que vendam a decis o a voc Delegar N vel 7 Voc permite que as pessoas tomem uma decis o sem qualquer n vel de envolvimento da sua parte Al m de definir os n veis de empoderamento importante tamb m deixar ex pl cito para que todos saibam onde podem pisar Jurgen Appelo desenvolveu uma forma simples e eficiente de tornar a delega o transparente atrav s do Quadro de Del
12. dia veja na figura 5 4 97 5 2 M tricas geis Casa do C digo O Velocidade por Itera o O Velocidade M dia 60 pontos 45 pontos 30 pontos 15 pontos 0 pontos Itera o Itera o 2 Itera o 3 Itera o 4 Figura 5 4 Gr fico de Velocidade A velocidade o escopo pendente entregue e o trabalho em progresso s o as m tricas mais acompanhadas por equipes geis mas n o s o as nicas Por isso agora estudaremos os tipos de m tricas e quais outras podem trazer visibilidade e feed back para a equipe e os interessados no projeto Tipos de M tricas Jurgen Appelo e Mike Cohn recomendam que se use dois tipos de indicadores 8 20 Indicadores Indutores e Indicadores de Resultado Indicadores Indutores leading indicators ajudam a detectar um aumento na probabilidade ou na gravidade de um evento antes que apare am nos indicadores de resultado Quando um indicador indutor muda significa que voc pode estar no caminho para atingir um objetivo ou meta Por exemplo aumentar a cobertura de testes ou a quantidade de testes criados pode indicar mais qualidade no produto Voc pode ter diversos objetivos em uma equipe de desenvolvimento de software como por exemplo aumento na qualidade aumento na produtividade produ o de melhores estimativas redu o do custo do desenvolvimento maior previsibilidade do cronograma aumento na satisfa o do usu rio releases mais frequentes etc Para cada ob
13. digo Cap tulo 3 Foco em Valor para o Neg cio Todos os dias em um hor rio preestabelecido geralmente no in cio do dia a equipe se re ne por mais ou menos 15 minutos para sincronizar o estado do projeto e manter todos informados sobre os ltimos acontecimentos e como as coisas est o ou n o evoluindo Atrav s da reuni o di ria todos os membros da equipe ficam cientes do anda mento do projeto e podem aproveitar a oportunidade para apresentar suas dificul dades e pedir ajuda aos outros membros No Scrum por exemplo cada membro do time responde a tr s perguntas na reuni o di ria 1 O que eu fiz desde a ltima reuni o ontem 2 O que farei at a pr xima reuni o at amanh 3 Que problemas est o me impedindo de progredir Tim Ottinger sugere outras 4 perguntas que t m um foco maior em entrega aprendizagem e colabora o 44 e Que hist rias voc ajudou a terminar desde a ltima reuni o di ria e Que hist ria voc ajudar a terminar hoje e Como o resto do time pode a ajudar a empurrar uma hist ria para pronto e O que voc aprendeu de novo Um fator importante que deve ser considerado para uma boa comunica o o n mero de integrantes da equipe quanto mais pessoas mais dif cil se torna a co munica o Por isso equipes geis geralmente s o compostas por um n mero de membros que varia de cinco a nove pessoas No cap tulo 6 abordaremos com mais profundidade algumas boas pr
14. es com mais qualidade e eleg ncia 83 4 9 Programa o em Par Casa do C digo Programa o em Par e Aprendizado z A Aprender a nica coisa de que a mente nunca se cansa nunca tem medo e nunca se arrepende Leonardo da Vinci Trabalhando em par o conhecimento do time ser rapidamente disseminado en tre os membros do time ajudando na elimina o de ilhas de conhecimento Para que isso aconte a de forma eficiente importante que haja um revezamento constante entre os pares de forma que todos tenham oportunidades de trabalhar com todos 84 Casa do C digo Cap tulo 4 Entregando Valor A PIR MIDE DOS PARES Uma ferramenta interessante para incentivar o revezamento entre os pares e tonar vis vel quem est pareando com quem ao longo de uma itera o a Pir mide dos Pares ou Pair amid 44 Trata se basicamente de uma matriz que cruza todos os membros do time e desconsidera os cruzamentos repetidos e os cruzamentos de in div duo com ele mesmo veja na figura 4 4 Figura 4 4 Pir mide dos Pares No exemplo acima podemos ver que at agora o Robson e o Luiz nunca parearam e que o Robson pareou 3 vezes com a Carol e 2 vezes com a Aline Se a pir mide dos pares ficar vis vel no quadro do time tornar se uma ferramenta til para incentivar a programa o em par e o reve zamento dos pares resultando em maior compartilhamento de conheci mento entre os membros do time
15. es de neg cio e decis es t cnicas Ao fim da reuni o de planejamento a equipe come a a trabalhar nas tarefas res peitando as prioridades fazendo sempre primeiro as tarefas mais importantes que representam maior valor para o produto de acordo com o Product Owner Todos os dias realizada uma reuni o para que a equipe converse sobre o andamento do sprint Posteriormente apresentaremos em mais detalhes as reuni es Ao longo da Sprint a equipe mant m sempre em mente a sua meta e quando o andamento das coisas foge do que foi previsto ela pode negociar o escopo com o Product Owner de forma que n o comprometa a meta 59 13 1 6 Excel ncia T cnica com XP Casa do C digo TIMEBOXES O Scrum refor a a ideia de que todas as cerim nias do time preci sam ter um timebox tempo definido e que muito importante que es ses tempos sejam respeitados para se manter um ritmo sustent vel Se as Sprints por exemplo tem dura o de duas semanas importante que n o sejam estendidas Se a reuni o di ria dura 15 minutos importante que a reuni o n o seja estendida Os timeboxes das outras reuni es va riam de acordo o timebox da Sprint e e podem variar tamb m de acordo com cada contexto da equipe Os tempos sugeridos para um Sprint de 30 dias s o 59 e Reuni o Planejamento 8 horas e Reuni o de Revis o Demonstra o 4 horas e Reuni o de Retrospectiva 3 horas Ao fim do sprint mais duas r
16. es foram muito importantes para melhorar a gest o de nossas organiza es po r m estes ainda partem do mesmo princ pio de que as organiza es operam de cima para baixo atrav s de uma hierarquia A gest o 3 0 tr s uma abordagem sist mica que trata a organiza o como sistema vivo que est constantemente em processo de aprendizagem e adapta o A grande dificuldade que temos em lidar com sistemas complexos se deve s nossas mentes lineares que preferem causalidade complexidade N s procuramos prop sito e causa em todas as coisas buscamos por causa e efeito em tudo Estamos acostumados a estudar e aprender de forma linear a contar hist rias e dessa forma que enxergamos o mundo como um lugar repleto de eventos f ceis de serem expli cados atrav s de simples efeitos e causas Gerald Weinberg chamou isso de Fal cia da Causalidade A gest o gil tem suas bases na complexidade por isso o foco da gest o gil deve estar na adaptabilidade ao inv s de previsibilidade uma vez que se aceita que muitos fatores em projetos s o imprevis veis Para entender melhor a gest o 3 0 vamos entender melhor o que a Gest o 1 0 e a 2 0 a final de contas esse 3 0 n o poderia ser apenas Marketing Gest o 1 0 Focada em hierarquias esta vers o da gest o ficou mundialmente conhecida atrav s do modelo comando e controle Poder na m o de poucos em uma estrutura de decis es top down Aqui foi criado aquele conhecido jarg o m
17. pria Em certa altura da minha vida percebi que mais ainda do que ler eu gostava de comprar livros Mantenha sua lista de livros e v comprando medida que for terminando de ler o livros que j tem Eventos e M dia Participe de eventos e confer ncias sobre tecnologias e assun tos do seu interesse troque informa es com outros profissionais e construa uma rede de relacionamentos Hoje em dia temos uma grande riqueza de material em udio e v deo dispon veis online Screencasts Podcasts V deos al m disso muitas confer ncias gravam suas palestras e disponibilizam online para a comunidade Use tudo isso a seu favor Coding Dojo Coding Dojo uma reuni o de desenvolvedores com o objetivo de trabalhar em um desafio de programa o Eles se divertem e se engajam para trabalhar na solu o do problema ao passo que desenvolvem suas habilidades 2 A premissa b sica que o aprendizado de habilidades de codifica o um pro cesso cont nuo que desenvolvedores devem se dar a oportunidade de codificar com o objetivo de treinar N o importa qual o n vel t cnico dos desenvolvedores todos participam e aprendem juntos A primeira ideia de sess es de pr tica de programa o individuais e fora do hor rio de trabalho foi proposta por Dave Thomas 62 posteriormente Laurent Bossavit prop s Coding Dojos com mesmo objetivo por m com a participa o de um grupo de programadores 14 O ambiente de um coding dojo est
18. rio como esses comum que algu m desempenhe o papel Product 129 6 4 Forma o das Equipes Casa do C digo Manager ou que haja uma comunidade de pr tica de Product Owners para coorde nar alinhar e lidar com esses requisitos de mais alto n vel que s o organizados e priorizados em um Program Backlog Para organizar muitos programas trabalha se com portf lios onde se trata dos requisitos de mais alto n vel os picos Nesse n vel realizada a gest o de todos os investimentos da organiza o que ser o realizados atrav s de programas e projetos Assim teremos uma hierarquia formada por Portif lios Programas e Projetos em que cada projeto ser desenvolvido por uma pequena equipe gil 6 4 FORMA O DAS EQUIPES Uma premissa importante do desenvolvimento gil s o as equipes cross funcionais ou seja equipes que possuem pessoas com todas as habilidades necess rias para en tregar as hist rias de usu rio do in cio ao fim Elas s o geralmente chamadas de equipes de feature teams ou funcionalidades diferente das equipes funcionais que geralmente eram formadas nos proces sos tradicionais com base na fun o por exemplo equipe de programadores equi pes de analistas equipes de testadores etc Em organiza es que utilizam esses pro cessos tradicionais geralmente o trabalho passa de uma equipe para a outra at que fique pronto resultando muitas vezes em burocracia e problemas de comunica o A f
19. ser mais f cil de questionar e identificar o que pode mudar para melhor Alinhar Restri es O que medido gerido Peter Drucker A Gest o 3 0 nos apresenta o empoderamento como um investimento que faze mos nas pessoas preciso compreender que ser preciso tempo para que as pessoas 123 6 1 A Gest o pode ser gil Casa do C digo ganhem experi ncia e adquiram conhecimento para que possam fazer determinadas coisas t o bem quanto quem as delegou capaz de fazer Alinhar restri es auto organiza o pode n o funcionar para diminuir esta possibilidade d s pessoas um prop sito claro e metas compartilhadas A auto organiza o pode levar a qualquer resultado bom ou ruim faz parte do papel do gestor dar s pessoas uma meta compartilhada para que possam se auto organizar de uma forma que produza valor para a organiza o O objetivo desta meta compartilhada dar s pessoas uma dire o a seguir Nos ltimos anos temos repetido que nossas metas devem ser SMART Espe c ficas Mensur veis Ating veis Realistas e Oportunas por m do ponto de vista da complexidade podemos entender que metas com objetivos espec ficos possuem caracter stica diferente umas das outras Por exemplo se a sua meta aproveitar as f rias na Noruega como voc vai medir isso Contar seu n mero de sorrisos por dia Al m disso necess rio ter m tricas diferentes para os diferentes interessados do p
20. sitos de cada pessoa e o prop sito da organiza o importante notar que pessoas diferentes s o motivadas por desejos intr nsecos diferentes tais como compet ncia aceita o curiosidade honra idealismo e pro p sito independ ncia e autonomia ordem poder status social relacionados sociais etc Por isso os gestores precisam estar atentos e devem dedicar se a conhecer a cada pessoa individualmente para entender como pode motiv las Empoderar times Times devem se auto organizar mas para isso precisam empoderamento auto riza o e confian a da gest o Apesar de os gestores ainda deterem o poder de contratar e demitir pessoas em ambientes de trabalho que em conhecimento algo crucial os trabalhadores do co nhecimento possuem os trabalhos geralmente cr ticos e nesse cen rio o gestor pode ser visto como um l der facilitador que empodera os profissionais para que possam tomar as decis es necess rias para realizar o trabalho que s o bons em realizar Delegar ato de transferir responsabilidades para outra pessoa geralmente mantendo se respons vel pelo resultado Empoderar mais que delegar ou di zem alguns delargar para empoderar preciso considerar o desenvolvimento das pessoas assumir riscos e em muitas organiza es preciso mudar a cultura A teoria da complexidade nos diz que os problemas devem ser resolvidos o mais pr ximo poss vel do n vel em que eles acontecem Empoderar n o
21. 5 Utilidade Toda funcionalidade de um sistema precisa ser til para seus usu rios Quando uma funcionalidade deixa de ser necess ria cria se desperd cio em mant la em muitos casos melhor elimin la 4 3 C DIGO LIMPO Robert C Martin um dos criadores do Manifesto gil conhecido na comunidade como Uncle Bob defende com afinco a ideia de que ao longo do tempo a base de c digo de um projeto vai se tornando mais bagun ada e dif cil de se entender im pactando fortemente na produtividade da equipe que tende a zero ou seja a ponto de em um determinado momento a equipe n o conseguir mais evoluir e incluir no vas funcionalidades no software 41 De fato muitos softwares chegam a um tal ponto que precisam ser reescritos do zero para que possam continuar a ser evolu dos Algumas caracter sticas de c digo limpo s o Elegante f cil de se compreender e agrad vel de se ler Simples e direto e Segue princ pios de programa o e Sem duplicidade e Bem testado Par metros M todos Fun es Classes e Vari veis possuem nomes significa tivos 76 Casa do C digo Cap tulo 4 Entregando Valor e C digo autoexplicativo sem necessidade de coment rios para compreender o c digo e C digo bem formatado poss vel ler o c digo sem precisar utilizar a barra de rolagem e M todos e Classes devem ter uma nica responsabilidade princ pio da res ponsabilidade nica Trabalh
22. Esse o quarto n vel de flu ncia falaremos sobre o alinhamento da organiza o como um todo os valores geis e pr ticas geis assim como os objetivos da orga niza o e de como a agilidade pode impactar de forma sistem tica a performance da organiza o al m do time A teoria do pensamento sist mico nos ensina que um sistema consiste de partes interdependentes que interagem entre si por um mesmo prop sito Um sistema n o apenas a soma de suas partes mas tamb m o produto de suas intera es As melhores partes n o necessariamente fazem o melhor sistema de forma que a habilidade de um sistema de atingir o seu prop sito depende de qu o bem suas partes trabalham juntas e n o apenas de como atuam individualmente Em projetos de desenvolvimento de software not vel que exista uma tend ncia de se medir o progresso do projeto atrav s de tr s m tricas escopo prazo e custo A contrassenso mesmo otimizando cada uma dessas m tricas nem sempre o projeto ser bem sucedido pois elas n o levam a qualidade e nem mesmo a satisfa o do cliente em considera o Para n o ser pego de surpresa Tom e Mary Poppendieck 6 1 A Gest o pode ser gil Casa do C digo sugerem aplicar uma m trica de mais alto n vel que considere o resultado de forma mais ampla o retorno sobre o investimento E complementam Se voc otimizar o que realmente importa os outros n meros tomar o conta de si mesmos 48 Por isso de
23. Evite documenta es burocr ticas que n o ser o lidas por ningu m e n o agre gar o valor ao produto e concentre se em documentar somente o que for necess rio 112 Casa do C digo Cap tulo 5 Otimizando Valor Cuidado por m para n o levar essa ideia ao extremo N o deixe de documentar o que for importante Larry Burns 16 d algumas dicas para evitar desperd cios com documenta o e N o produza documenta o que n o ser lida Evite produzir documenta o que n o ser atualizada a menos que seja deli beradamente produzida para satisfazer um requisito tempor rio como aten der uma licita o por exemplo e N o documente coisas bvias triviais redundantes ou informa es que po dem facilmente ser obtidas em outras fontes e A documenta o deve estar dispon vel e poder ser facilmente acessada pelos interessados importante encontrar um equil brio saud vel e discernir entre o que deve e o que n o deve ser documentado Desperd cio por falta de foco De acordo com o livro Peopleware de Tom DeMarco e Timothy Lister toda vez que algu m interrompido durante a execu o de uma tarefa para trabalhar em outra ou ajudar algu m em algum assunto de contexto diferente do que estava fazendo um tempo significativo gasto para se concentrar na nova tarefa e voltar ao estado de produtividade anterior 39 Logo quanto mais interrup es houver maior ser o desperd cio Por essa me
24. How to Build a Successful Application Using Agile Without Sacrificing Data Management Technics Publications 2011 i 17 Alistair Cockburn Agile Software Development The Cooperative Game Second Edition Addison Wesley Professional 2006 18 Mike Cohn User Stories Applied For Agile Software Development Addison Wesley Professional 2004 19 Mike Cohn Agile Estimating and Planning Prentice Hall 2005 20 Mike Cohn Succeeding with Agile Software Development Using Scrum Addison Wesley Professional 2009 21 Ward Cunningham Technical debt http c2 com cgi wiki TechnicalDebt 22 Diana Larsen Esther Derby Agile Retrospectives Pragmatic Bookshelf 2006 23 Eric Evans Domain Driven Design Tackling Complexity in the Heart of Soft ware Addison Wesley Professional 2003 24 Michael Feathers Working Effectively with Legacy Code Prentice Hall 2004 25 Neal Ford The Productive Programmer O Reilly Media Inc 2008 YP D Wikimedia Foundation Miss o da wikimedia http wikimediafoundation org wiki Mission 27 Wikimedia Foundation Vis o da wikimedia http wikimediafoundation org wiki Vision 148 Casa do C digo Refer ncias Bibliogr ficas 28 Kent Beck Martin Fowler Planning Extreme Programming Addison Wesley Professional 2000 29 Martin Fowler Pair programming misconceptions http martinfowler com bliki PairProgrammingMisconceptions html 30 Olav Maassen Ch
25. Op es Reais em ingl s Real Options Apesar de n o ser exatamente a mesma coisa do que as op es do mercado fi nanceiro stock options h uma rela o entre os conceitos As op es do mercado financeiro conferem ao titular o direito e n o obriga o compromisso de comprar um determinado ativo a o t tulo ou bem qualquer por um valor determinado enquanto o vendedor obrigado a concluir a transa o Quando voc compra um ingresso para o cinema por exemplo para voc uma op o porque mesmo tendo comprado o ingresso voc pode ou n o ir ver o filme j para o cinema isso mais um compromisso porque ele j te vendeu o bilhete e agora precisar passar o filme no hor rio determinado Vai depender do ponto de vista de cada um dos lados da rela o Muitas vezes n s vemos e encaramos as coisas como compromissos em situa es que poder amos encarar como op es Op es que podemos ou n o exercer O pensamento de op es reais consiste em enxergar e avaliar todas essas op es ao seu redor e comprometer apenas de forma deliberada Caso contr rio sempre se deve deixar para assumir o compromisso no ltimo momento poss vel ou seja quando voc tem as informa es que precisa para tomar a decis o de comprometer se de verdade Uma op o uma escolha uma decis o de escolher uma estrat gia em vez da outra de escolher um caminho em vez do outro de comprar um produto em vez do 6 3 12 Manten
26. PRECISAR DISSO N o pague o pre o da complexidade a menos que voc realmente precise Neal Ford O princ pio YAGNI You Ain t Gonna Need It ou Voc n o vai precisar disso muito disseminado na comunidade gil defende a ideia de que voc deve evitar especula es no desenvolvimento de software 25 Isso ocorre naquelas situa es em que se pensa Eu acho que vamos precisar disso no futuro ent o vou aproveitar e j fazer Dessa forma adiciona se complexidade desnecessariamente no projeto e quando mais complexidade mais dif cil de se alterar torna se o software Procure fazer apenas aquilo que realmente preciso agora 4 7 DEFININDO O SIGNIFICADO DE PRONTO A Defini o de Pronto em ingl s Definition of Done referenciado com o acr nimo DoD basicamente um checklist do que deve ser feito antes que uma hist ria possa ser considerada potencialmente entregavel N o h um checklist oficial que deva ser usado por todas as equipes geis do mundo porque considerando a complexidade do desenvolvimento de software cada equipe nica e est resolvendo um problema dentro de um contexto nico Por isso cada equipe dever descobrir o que deve fazer parte de sua defini o de pronto de acordo com seu contexto ou seja levando em considera o a natureza do produto a tecnologia que est sendo utilizada as necessidades dos usu rios etc Alguns itens comuns s o e C digo refatorado
27. Scrum Kanban 120 13 9 3 5 Adaptativo Figura 1 2 M todos Mais e Menos Prescritivos por isso que m todos geis s o menos expl citos em termos de pap is ativida des e artefatos do que m todos tradicionais prescritivos Para se ter uma ideia o 1 3 Compreendendo os Valores geis Casa do C digo RUP possui mais de 120 prescri es o XP 13 o Scrum 9 e Kanban apenas 3 34 Quanto mais prescritivo um m todo for mais espec fico para um determinado tipo de contexto ele ser Em contrapartida quanto mais adaptativo maior ser sua ader ncia e flexibilidade para que seja otimizado com maior efici ncia em diferentes contextos Em regra geral ao utilizar um m todo prescritivo como RUP por exemplo voc possivelmente precisar encontrar muito mais do que realmente precisa e j com m todos menos prescritivos como Scrum voc precisar incluir tudo aquilo que estiver faltando para que o processo seja eficiente em seu contexto 1 3 COMPREENDENDO OS VALORES GEIS Conforme citado anteriormente o Manifesto gil formado por quatro valores fun damentais que agora vamos explorar em mais detalhes O primeiro valor que diz indiv duos e a intera o entre eles mais que proces sos e ferramentas trata de entender que uma equipe formada por pessoas e que cada uma diferente e nica e possui pontos fortes e fracos e n o s o vistas apenas recursos homog neos e substitu veis
28. Usu rio Casa do C digo mar por isso deve se tomar os devidos cuidados para mant las sempre curtas e quando necess rio quebr las em hist rias menores Para ilustrar melhor imagine a seguinte hist ria Um usu rio pode realizar compras na loja virtual Ela pode envolver muitas funcionalidades que est o impl citas e por isso pode gerar diferen tes interpreta es e levar os desenvolvedores ao erro Em casos como este podemos quebrar a hist ria grande em outras hist rias menores Um usu rio pode adicionar produtos ao seu carrinho de compras Ao finalizar a compra o usu rio deve esco lher a forma de pagamento Para compras acima de R 100 00 o frete dever ser gratuito etc 6 Hist rias devem ser test veis preciso ter crit rios de aceita o bem defini dos para que um desenvolvedor possa saber quando uma hist ria est ou n o con clu da Uma boa pr tica ao usar cart es para escrever as hist rias pedir ao cliente que escreva alguns crit rios de aceita o no verso do cart o Para que a hist ria seja test vel preciso que o cliente escreva crit rios objetivos e concretos Por exemplo O relat rio deve ser intuitivo um exemplo de crit rio dif cil testar porque o conceito de intuitivo abstrato e subjetivo pode possuir significados diferentes para cada pessoa Ao inv s disso o relat rio deve possuir um rodap com a soma dos valores ou o t tulo das colu
29. da agili dade entregas frequentes respeito s pessoas comprometimento colabora o co munica o etc 3 Ri Neste ltimo est gio a pr tica j se torna parte de quem est aprendendo e apesar de ainda seguir algumas regras mesmo aquelas que foram quebras e reinven tadas 4 tudo parece ser natural e o aprendizado vem da pr tica e da experi ncia importante notar que uma equipe pode estar em est gios diferentes depen dendo da refer ncia por exemplo um time pode estar no est gio Ri em se falando de entregas frequentes mas pode estar no est gio Shu em rela o programa o em par Uma li o importante deste modelo que h um momento certo de maturidade para se quebrar as regras adaptar e improvisar Um aluno iniciante no est gio Shu de artes marciais que tentar mudar os movimentos ensinados pelo mestre poder facilmente fazer algo errado e se machucar j um aluno intermedi rio no est gio Ha provavelmente estar mais preparado para encontrar seu pr prio estilo sem correr altos riscos O mesmo ocorre com uma equipe que est utilizando m todos geis se num momento precoce tentar adaptar ou quebrar as regras antes de ter compreendido mais profundamente os princ pios corre o risco de estar fazendo alguma outra coisa qualquer e as continuar chamando de m todos geis 2 2 ORDEM CAOS E COMPLEXIDADE Assim como h muitos tons de cinza entre o preto e o branco entre o caos de sordem
30. da implementa o 3 7 MAPEANDO HIST RIAS DE USU RIOS Mapeamento de hist rias uma t cnica que consiste basicamente em decompor ati vidades de usu rio de alto n vel em um workflow que pode ser decomposto poste riormente em um conjunto de hist rias de usu rio A t cnica que foi popularizada por Jeff Patton centrada na perspectiva do usu rio 53 Primeiramente temos os picos representando requisitos de alto n vel depois temos as funcionalidades e finalmente as hist rias 3 5 Mais Priorit rio Menos Priorit ri id id q di pi Figura 3 5 Mapa de hist rias OMBJMOLd SOUS lt Dependendo da abordagem os nomes dos niveis de requisitos podem mudar Na abordagem original de mapeamentos de hist rias Patton usa Atividades Tarefas e Subtarefas em vez de picos e funcionalidades e hist rias Outras fontes entendem 51 3 7 Mapeando hist rias de usu rios Casa do C digo que picos s o maiores que temas por exemplo mas isso n o importa muito uma vez compreendida a ess ncia da pr tica voc pode escolher a sem ntica que for mais adequada ao seu contexto Note que tudo est priorizado em dois eixos tanto da esquerda para a direita que representa a prioridade entre diferentes picos e diferentes funcionalidades quanto de baixo para cima que representa a prioridade entre diferentes hist rias de usu rio Depois de pronto e priorizado voc pode utilizar
31. dife rentes pessoas para saber exatamente em que voc pode melhorar poss vel H uma ferramenta conhecida como Feedback 360 graus O feedback pode ser contextualizado em compet ncias que o time julgar ne cess rias para que possam atingir suas metas entregar resultados de qualidade e atender as expectativas dos clientes e manter um bom relacionamento e ambiente de trabalho Pode se avaliar tanto compet ncias como comunica o colabora o como coisas mas espec ficas como conhecimentos em tecnologias ou boas pr ticas de desenvolvimento Como toda ferramenta pode ser bem ou mal utilizada Infelizmente alguns ge rentes a utilizam para realizar avalia es tradicionais no estilo de cima para baixo 8 em que apenas gerentes avaliam subordinados e subordinados avaliam gerentes importante evitar fazer uma rela o direta do resultado do feedbacks com pro mo es demiss es puni es b nus etc para n o perder a confian a das pessoas e criar um clima de tens o na equipe importante preparar as pessoas e explicar o objetivo do feedback para que n o se torne uma sess o de fogo para todo lado em que cr ticas destrutivas s o trocadas pelos membros da equipe resultando apenas em egos feridos A ess ncia do feedback 360 graus de um ponto de vista gil que voc possa dar feedback para todos os membros do seu time receber feedback de todos e em alguns casos inclusive se autoavaliar com objetivo de q
32. e a ordem h tamb m alguns n veis 8 Quando tentamos trazer nossas organiza es para o extremo da ordem para que possamos tornar as coisas mais previs veis e manter tudo sob controle criamos uma s rie regras e enrijecemos o sistema tornando o pouco adaptativo e burocr tico Por outro lado quando n o h nenhuma regra nenhuma restri o nenhum l der o sistema se encontra no que chamamos de caos sem nenhuma previsibilidade e voc n o consegue ter a menor ideia do que est acontecendo ou para aonde as coisas est o caminhando 26 Casa do C digo Cap tulo 2 Flu ncia gil Para ilustrar a diferen a entre a Ordem e o Caos imagine que voc est indo com sua fam lia passar o final de semana na praia Voc tem dois filhos pequenos e danados um menino e uma menina Seu c njuge foi fazer um caminhada e voc ficou respons vel pelas crian as Se voc optar pelo Caos extremo n o dir nada para as crian as e as deixar completamente livres para fazerem aquilo que quiserem n o as advertir n o haver limites nem restri es nem regras Liberdade total tudo poss vel Nem preciso falar que a probabilidade de uma crian a se afogar e a outra entrar no meio de um jogo de futebol e tomar uma bolada bem alta Agora se voc optar pela ordem extrema dir a seus filhos Sentem se aqui na minha frente brinquem de fazer castelo com 500 metros de altura e duas torres usem o balde e as pazinhas n
33. e das intera es entre eles Comportamentos se espalham de forma viral e estimular a rede social pode ajudar a vencer a resist ncia s mudan as e a transformar uma organiza o por completo 125 6 2 Feedback Casa do C digo 4 Considerar o ambiente As pessoas sempre se organizam dentro do contexto de um ambiente O ambiente determina como o sistema pode se auto organizar e voc deve ser capaz de ajustar o ambiente Isso porque o comportamento das pessoas depende do ambiente e se voc mudar o ambiente voc tamb m muda as pessoas No livro Como Mudar o Mundo Gest o de Mudan as 3 0 Jurgen Appelo des creve em detalhes como voc pode aplicar cada uma dessas abordagens para se tornar um agente de mudan as bem sucedido 6 2 FEEDBACK N o toa que um dos valores de XP Feedback 13 A constante mudan a do mundo nossa volta cria a necessidade de darmos e receber feedback com frequ n cia Desenvolvedores precisam receber feedback sobre as altera es que fizeram no software precisam receber feedback a cada altera o para que saibam se os testes de regress o continuam passando por isso utilizam integra o cont nua e TDD Al m disso precisam saber se o c digo que escrevem est leg vel do ponto de vista de seus pares O Product Owner precisa de feedback dos usu rios o time precisa de feedback da gest o e a gest o de feedback do time Os ciclos de feedback s o importantes e necess rios em di
34. esse papel De fato recomend vel que cada reuni o de retrospectiva possua um facilitador diferente de modo que todos possam exercitar esse papel e treinar as habilidades por ele exigidas O facilitador deve permanecer neutro em discuss es mesmo quando houver for tes opini es a respeito do tema em discuss o Se ele estiver engajado na discuss o provavelmente n o conseguir fazer um bom trabalho na lideran a da retrospectiva O facilitador deve evitar que ocorram conversas em paralelo e deve assegurar que todos sejam devidamente ouvidos Contudo ele deve ainda cortar as discuss es quando estiverem propensas a estourar o tempo da reuni o ou impedir que todos os 103 5 4 Melhoria Cont nua com Retrospectivas Casa do C digo t picos importantes sejam abordados essencial que todos tenham oportunidade de falar e que os mais faladores n o dominem a reuni o O facilitador deve estar sempre atento s pessoas que falam demais ou de menos e incentivar pessoas com maior dificuldade de expressar seus pensamentos em grupo a falarem Outra responsabilidade do facilitador da retrospectiva lidar com comporta mentos inadequados ao longo da reuni o Larsen e Debby aconselham evitar chamar a aten o das pessoas individualmente buscando sempre chamar aten o do grupo enquanto for poss vel enfatizando o comportamento e n o a pessoa Al m disso deve se evitar que as pessoas utilizem a retrospectiva para apontar culpados
35. fato talvez torne se uma funcionalidade importante do produto o que interessa que o aprendizado trazido da experi ncia poder ser por si s muito recompen sador Hackathons s o oportunidades para que as pessoas possam aprender experi mentar e inovar S o eventos motivadores que permitem que a equipe quebre a ro tina e experimente coisas que em um contexto normal talvez fossem arriscadas ou teriam baixa prioridade 6 7 COMUNIDADES DE PR TICA Organiza es precisam harmonizar pr ticas processos e ferramentas e diversos ti mes e departamentos al m disso as pessoas precisam compartilhar conhecimento e desenvolverem se al m dos limites das organiza es 9 Para esse objetivo cultivar comunidades de pr tica pode ser de grande ajuda Equipes geis geralmente s o cross funcionais ou seja profissionais com pa p is e interesses semelhantes est o distribu dos entre diversos times Nesse cen rio formar comunidades de pr ticas para criar oportunidades de compartilhamento e aprendizado para esses profissionais pode alavancar consideravelmente o desenvol vimento das pessoas Imagine uma organiza o com 10 times de Scrum cada time possui um Scrum Master e pelo menos dois testadores alguns designers e alguns desenvolvedores A cria o de comunidades de pr tica nessa organiza o permitiria que em momentos oportunos todos os Scrum Masters se reunissem para tratar de assuntos relevantes para todos eles assim com
36. geis trazem de dife rente O que tem despertado tanto interesse nesses grandes players do mercado de tecnologia Para compreender melhor vejamos como tudo come ou No in cio da d cada de 90 no intuito de desburocratizar os processos de de senvolvimento de software novas abordagens chamadas de processos leves como Scrum Extreme Programming XP e Feature Driven Development FDD para citar algumas come aram a emergir mostrando se mais bem sucedidas do que ten tativas anteriores 1 1 O MANIFESTO GIL Devido ao grande n mero de refer ncias a esses processos leves que emergiam como resposta aos constantes fracassos de projetos utilizando abordagens tradicionais em fevereiro de 2001 um grupo de profissionais extraordin rios do desenvolvimento de software reuniu se em um Resort de Ski em Wasatch Range para discutir melhores maneiras de desenvolver software Esse encontro deu origem ao manifesto gil uma declara o com os princ pios que regem o desenvolvimento gil 64 Casa do C digo Cap tulo 1 Introdu o M todos Ageis O MANIFESTO GIL Estamos descobrindo maneiras melhores de desenvolver software fazendo o n s mesmos e ajudando outros a faz lo Atrav s desse tra balho passamos a valorizar e Indiv duos e a intera o entre eles mais que processos e ferra mentas Software em funcionamento mais que documenta o abrangente e Colabora o com o cliente mais que negocia o contr
37. mero de pontos de estimativa que se pode esperar para a pr xima itera o Essa soma de pontos conhecida como velocidade da equipe H quem utilize uma m dia das velocidades das itera es passadas para definir quantos pontos de complexidade ser o inseridos na nova itera o e h quem prefira utilizar apenas a velocidade da ltima itera o Para inserir as hist rias na itera o preciso que elas estejam estimadas em com plexidade e priorizadas segundo o valor de neg cio o que provavelmente j ter sido 38 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio feito no planejamento de release Dessa forma selecionar as hist rias para a itera o geralmente algo r pido O cliente verifica hist ria por hist ria e as inclui na nova itera o de acordo com a prioridade A somat ria de pontos das hist rias selecio nadas idealmente n o deve ser maior do que a definida seja com base na itera o passada ou na m dia das anteriores Depois de selecionadas quais hist rias ser o implementadas na nova itera o preciso explic las equipe Nesse momento importante que o PO ou pessoas de neg cio possa estar presentes para que possam esclarecer aos desenvolvedores suas d vidas de neg cio permitindo que ao final da reuni o os desenvolvedores estejam preparados para implementar estas hist rias Se a equipe conseguir entregar todas as hist rias antes do fim da itera o pre ciso solicit
38. mo a que havia passado 8 meses tra balhando em um projeto para um grande banco Ela e sua equipe passaram todo esse tempo apenas fazendo levantamento de requisitos e documentando suas des cobertas at que descobriram que o problema que o software a ser desenvolvido se propunha a resolver j havia sido solucionado por uma ferramenta trazida de uma fus o com outro banco h dois anos atr s e j n o era mais um problema O projeto foi cancelado O resultado de 8 meses de trabalho de uma equipe mais o investimento do tempo de diversos interessados que colaboraram com informa es para o projeto se resu miu a um bolo de documenta o que agora provavelmente nunca mais ser se quer lida por ningu m Joana estava frustrada com sua ltima experi ncia e prova velmente quem quer que estivesse pagando por esse projeto tamb m A experi ncia de Joana n o um caso isolado Na verdade muitos e muitos projetos tiveram e infelizmente ainda ter o destinos semelhantes a esse Mas por qu Ser que h uma forma melhor de gerenciar e desenvolver software que evite 11 O Manifesto gil Casa do C digo tanto desperd cio A boa not cia que h M todos geis s o uma vacina contra o desperd cio Por isso nos ltimos anos os m todos geis v m ganhando mais e mais popula ridade e grandes empresas como Google Yahoo Microsoft IBM Cisco Symantec e Siemens os t m utilizado 66 Mas afinal o que os m todos
39. notifica o caso o build tenha sido quebrado porque por exemplo algum teste tenha falhado Muitos servidores de integra o cont nua tamb m possuem extens es que per mitem que sejam gerados relat rios de cobertura de testes identifica o de defeitos bvios no c digo atrav s de ferramentas de an lise est tica entre outras coisas in teressantes Se voc ainda n o usa nenhuma ferramenta eu sugiro que comece verificando o Jenkins jenkins ci org e o CruiseControl cruisecontrol sourceforge net 82 Casa do C digo Cap tulo 4 Entregando Valor 4 9 PROGRAMA O EM PAR A programa o em par uma t cnica na qual dois programadores trabalham em um mesmo problema ao mesmo tempo e em um mesmo computador Enquanto uma pessoa o condutor assume o teclado e digita os comandos que far o parte do programa a outra o navegador a acompanha fazendo um trabalho de estrat gia 60 A revis o de c digo na programa o em par acontece em tempo real Enquanto um desenvolvedor est codificando o outro est revisando o c digo Pequenos er ros que poderiam ser extramente dif ceis de se corrigir posteriormente podem ser facilmente identificados e corrigidos nesse momento Os antigos j diziam que duas cabe as s o melhores do que uma e a programa o tamb m se beneficia disso Dois desenvolvedores com um conjunto de conheci mento e experi ncia diferentes s o em regra geral capazes de resolver um pr
40. o N o associe metas a recompensas financeiras pesquisas apontam que isso pode destruir a colabora o e tirar o foco das pessoas do que realmente importa 47 importante que a realiza o da meta seja a pr pria recompensa para o time importante que as metas sejam comunicadas e permane am sempre expl citas e vis veis para o time De que vale uma meta se as pessoas que precisam realizar o trabalho para que elas sejam atingidas n o a conhe am Metas s o ferramentas e como qualquer outra ferramenta podem ser bem ou mal utilizadas Quando bem usadas podem unir e direcionar o time quando mal usadas podem dividir as pessoas quebrar a colabora o e desmotivar Fa a bom uso de metas 94 Casa do C digo Cap tulo 5 Otimizando Valor 5 2 M TRICAS GEIS Tudo que pode ser contado n o necessariamente conta Tudo que conta n o necessariamente pode ser contado Albert Einstein M tricas podem ser teis para ajudar o time a compreender onde est o e ajud los a comparar com o estado em que querem estar Assim como as metas as m tricas tamb m devem estar sempre expl citas e vis veis para o time O Scrum por exemplo sugere que as equipes utilizem burndown charts para que todos possam ter feedback de como est o andamento da itera o estado atual em rela o ao planejamento estado desejado Na figura 5 1 podemos ver um exemplo de burndown em que a equipe n o con seguiu entregar tudo o q
41. os extremos s o inefici entes No artigo Your Path to Agile Fluency Diana Larsey e James Shore 57 afirmam que o turnover a principal causa da perda de flu ncia em uma equipe gil e que quando uma equipe ganha ou perde membros enfrenta problemas para sustentar aquilo que j havia sido aprendido Em 1977 Bruce Tuckman criador da teoria das din micas de grupos publicou uma artigo chamado Est gios de Tuckman que descreve esse processo de maturi dade em quatro est gios Forma o Confronto Normatiza o e Performance veja na figura 2 1 23 21 Evolu o e Maturidade de uma Equipe gil Casa do C digo SY Performance lt Normatiza o P Figura 2 1 Est gios de Tuckman Cada um dos est gios citados anteriormente possui algumas caracter sticas pr prias 1 Forma o Este o primeiro est gio pelo qual uma equipe rec m formada passar o momento em que os membros da equipe come am a conhecer uns aos outros procuram entender quais s o as habilidade de cada um e as tend ncias de comportamento de cada pessoa Nesse est gio tamb m se estabelecem os primeiros objetivos coletivos e completam se algumas tarefas mas a nfase das pessoas ainda mais individual do que coletiva 2 Confronto Conflitos aparecem medida que diferentes ideias para atingir objetivos v o surgindo e as metas coletivas identificadas no est gio de forma o s o questionadas Alguns me
42. poss vel no contexto em que est inserida Em uma abordagem gil o trabalho do gestor n o criar regras na organiza o mas certificar se de que as pessoas podem criar suas pr prias regras juntas e jus tamente esse esfor o conjunto que permite que o sistema alcance a beira do caos 8 Nessa vis o a gest o ocupa se apenas com algumas restri es de alto n vel O resto pode ser definido pela pr pria equipe e nesse cen rio que a auto organiza o acontece porque ela tem liberdade para criar suas pr prias regras e tomar decis es Quando todas as decis es v m de cima para baixo n o h auto organiza o Auto organiza o requer empoderamento e empoderamento requer confian a A gest o precisa fazer um investimento de autonomia para que equipe possa tomar decis es e se organizar da forma mais eficiente para atingir os objetivos da organi za o 28 Casa do C digo Cap tulo 2 Flu ncia gil Outro ponto importante que a auto organiza o por si s n o boa nem ruim e pode levar a qualquer resultado Por isso essencial que a equipe se auto organize em torno de um objetivo de metas importantes para o sucesso como se a gest o apontasse aonde a organiza o quer chegar e qual a dire o a seguir mas a equipe tivesse autonomia suficiente para decidir qual a melhor forma de se chegar at l 2 3 E AGORA O QUE EU FA O AMANH Fa a um levantamento do turnover da sua eq
43. possibilidades analisar causas e efeitos e permitir que a equipe colaborativamente alcance a melhor solu o Brainstorming uma t cnica interessante para instigar a equipe a ter insights A t cnica consiste em dar equipe um tempo para pensar expor e construir ideias sobre outras ideias anteriormente propostas Depois de levantado um n mero suficiente de propostas para resolver problemas ou alcan ar melhorias a equipe deve definir filtros e aplic los para reduzir o n mero de ideias e ent o lev las pr xima etapa para efetivamente decidir o que fazer Uma t cnica interessante para resolver isso a vota o por pontos figura 5 5 Imagine que h 20 proposta Escreva cada uma em um cart o e d a cada membro 107 5 4 Melhoria Cont nua com Retrospectivas Casa do C digo da equipe 5 pontos Ent o cada membro pode investir seus pontos em nos cart es Tanto faz se quiser investir os 5 pontos em um nico cart o ou 1 ponto em 5 cart es diferentes Os cart es com maior n mero de pontos ser o os escolhidos Enviar exceptions por e Usar ferramenta de mail para os mebros da profiling para descobrir equipe pontos de lentid o Escolher um respons vel semanal por olhar o log e registrar erros Figura 5 5 Vota o por Pontos Outra ferramenta poderosa para obten o de insights a t cnica dos 5 porqu s Com dados e fatos em m os a equipe pode realizar essa atividade para melhor com pree
44. rios importantes para o sucesso do produto e a melhorar o entendimento a comunica o e a tomada de decis o do time sobre os diferentes usu rios de forma a otimizar suas funcionalidades para o perfil do usu rio final e garantir que as necessidades de diferentes perfis sejam bem atendidas pelo produto em desenvolvimento Veja uma exemplo de persona na figura 3 7 53 3 8 Conhecendo os Usu rios atrav s de Personas Casa do C digo Roberto Descri o Trabalha como comprador em um supermercado de m dio porte tem 35 anos de e formado em administra o Tem mais de 10 anos de experi ncia e tem facilidade com inform tica Figura 3 7 54 Atividades Faz Pedidos de Compra Altera Pre os Inclui e Remove Fornecedores Objetivos Ampliar Margens de Lucro das Vendas Evitar Falta de Produtos nas Gondolas Persona Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio MODELO PARA CRIA O DE PERSONAS N o h uma forma certa ou errada de se desenvolver personas mas essas s o algumas caracter sticas comuns que podem ajudar o time a compreender um perfil de usu rio Voc pode escolher algumas dessas para come ar a desenvolver as personas de seu produto e Nome e Papel e Valores e Objetivos e Problemas e Necessidades e Desejos e Expectativas e Prefer ncias e Padr es de Comportamento e Casos de Uso e Atividades Depois de criadas as person
45. script preestabelecido e o testador vai muito al m do bvio criando e adaptando sua abordagem ao longo do processo Lidando com C digo Legado sem Cobertura de Testes muito comum que uma equipe que n o trabalhava com m todos geis e passa por uma transi o se depare com um projeto para evoluir que n o possui testes au tomatizados porque na cultura anterior testar e automatizar n o era uma pr tica dis seminada dentre os membros do time Fazer altera es em um sistema que n o possui um bom conjunto de testes auto matizados muito dif cil O maior risco que voc pode facilmente quebrar alguma funcionalidade sem que ningu m perceba Por isso Michael Feathers e muitos outros agilistas consideram que c digo sem cobertura de testes c digo legado n o importa se foi escrito oito anos ou oito horas atr s 24 Uma das op es para mudar essa cen rio melhorar a cobertura de testes pouco a pouco a cada itera o Para isso Henrik Kniberg sugere o seguinte processo 35 1 Liste seus casos de testes 2 Classifique cada teste por risco o custo de se testar manualmente e o esfor o para automatizar o teste veja na figura 4 3 3 Ordene por prioridade 4 Automatize alguns testes a cada itera o come ando pelos casos de maior prio ridade 73 4 2 Simplificando o C digo com Refatora o Casa do C digo Custo de Custo de Caso de Teste Risco i Emitir Nota Fiscal 20 pontos Cancelar Nota Fisca
46. ticas para forma o de equipes importante que todos tenham oportunidade de falar na reuni o di ria nos primeiros dias importante que algu m atue como facilitador geralmente algu m com papel de scrum master para assegurar que ningu m domine a reuni o e fale sozinho durante os 15 minutos ou que algu m deixe de falar Para criar essa disciplina algumas equipes utilizam alarmes que tocam de 2 em 2 minutos por exemplo para evitar que algu m fale demais Outras passam um bola de m o em m o at que todos a bola volte a pessoa que falou primeiro na reuni o Ao 41 3 4 A Reuni o Di ria Casa do C digo passo que a equipe compreende os benef cios de uma boa reuni o di ria esse tipo de ferramenta geralmente torna se desnecess ria mas pode ser til para come ar Ken Schwaber ressalta que importante que a reuni o di ria seja realizada em um local conhecido por todos 55 e que se deve evitar entrar em discuss es que fujam do contexto das tr s perguntas principais como por exemplo discutir sobre problemas abordagens de design as not cias do jornal do dia etc Se um problema que requer discuss o for identificado se necess rio deve se marcar com os interes sados uma reuni o para se discutir ap s a reuni o di ria ou em outro momento 42 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio PORCOS E GALINHAS HEY PIG WAS THINKIN WE SHOULD OPEN A RESTAURANT NO THANKS I D BE
47. todos Ageis A natureza iterativa dos m todos geis permite que software em funcionamento seja entregue ao cliente em curtos per odos de tempo dessa forma agregando va lor maior em curto espa o de tempo claro que uma vez que a documenta o importante para o projeto a cada entrega ela poder ser devidamente produzida e entregue junto com o software em funcionamento A colabora o com o cliente mais valorizada do que negocia o contratual justifica se porque o objetivo da equipe gil entregar um produto que agregue valor e para isso preciso estar sempre pronto a adaptar se s mudan as que geralmente ocorrem no mundo dos neg cios e consequentemente afetam uma ideia de escopo inicial que o cliente tinha do projeto a ser desenvolvido Contratos geralmente s o necess rios mas muitos s o protecionistas demais e procuram fechar o escopo do projeto desde o in cio reduzindo assim as oportu nidades de colabora o e descoberta junto com o cliente ao longo do processo de desenvolvimento resultando em produtos que muitas vezes n o atendem neces sidade de quem est pagando O importante que o contrato mantenha o m ximo de op es abertas para que o projeto possa mudar na medida do necess rio e dessa forma o projeto seja adapt vel e realmente gere valor ao cliente Al m disso essencial a colabora o e participa o do cliente durante o desen volvimento M todos geis procuram tra
48. website que ajuda a criar o Discurso do Elevador para seu produto al m de fazer uma an lise com sugest es para que voc possa melhorar seus discurso 54 De acordo com a HBS seu discurso deve contem plar os seguintes itens 1 Quem O que voc mais quer que seu ouvinte se lembre a respeito de sua organi za o ou produto 2 O qu De que forma seu produto agregar valor e trar resultados ou impactar o neg cio de seu ouvinte 3 Por qu Quais s o os benef cios exclusivos os diferenciais que seu produto ofe rece 4 Objetivo O que voc espera que o ouvinte fa a Criar um discurso do elevador para seu produto pode ser uma forma divertida e r pida para desenvolver uma mensagem objetiva e convincente ideal para apresentar seu produto para toda a sua organiza o e para potenciais clientes 3 2 PLANEJAMENTO E DESENVOLVIMENTO ITERATIVO O planejamento permite entender a expectativa do cliente em rela o ao projeto e tra ar estrat gias para atend las o momento de entender as ideias e necessidades do cliente e descobrir as funcionalidades que o software precisar oferecer 35 3 2 Planejamento e Desenvolvimento Iterativo Casa do C digo No desenvolvimento gil de software o time inteiro est envolvido em definir requisitos otimiz los implement los test los integr los e entreg los aos cli entes 37 Al m disso em um ambiente gil planejar uma atividade constante Dessa forma
49. zando um produto para que ele tivesse m xima performance e escalabilidade cons truindo sempre com tecnologia de ponta mas a primeira frase do cliente ao ver o produto funcionando N o era bem isso que estava querendo Todo produto de software representa de alguma forma valor para algu m e esse o principal motivo da exist ncia do software mas apesar de parecer algo bvio muitas vezes o perdemos de vista e acabamos construindo um produto que pode at ser tecnicamente fant stico mas que n o agrega o valor de que o cliente precisa por isso que m todos t m foco em valor de neg cio e o primeiro est gio da flu ncia gil diz respeito a agregar valor de neg cio ao cliente e a melhorar a visibi lidade do trabalho da equipe 57 O objetivo aprender a deixar de planejar apenas em termos t cnicos e preocupar se em planejar levando em conta o valor de neg cio que o software de senvolvido poder agregar ao cliente assim como refletir e decidir sobre quais as Casa do C digo melhores maneiras de potencializ lo Para dar suporte a esse objetivo as equipes geis fazem uso de ferramentas como backlogs itera es e quadros kanban Os principais benef cios alcan ados neste est gio s o a transpar ncia que per mite que o progresso ou a falta de progresso do time seja facilmente visualizado por todos inclusive pela gest o a melhoria cont nua para se agregar a cada itera o mais e mais valor e um
50. 30 pessoas muitas vezes che gando em extremos de mais de 100 As opini es quanto a tamanho ideal de uma equipe gil podem variar mas geralmente s o equipes pequenas que variam de 5 a 12 integrantes Quanto mais pessoas envolvidas mais fr gil se torna a comunica o do time mais coordena o se torna necess ria e geralmente menor a produtivi dade 66 importante levar em considera o como discutimos no cap tulo 5 que as pes soas precisam trabalhar juntas por um tempo para que sejam uma equipe de verdade e n o apenas um grupo de trabalho Por isso importante que elas possam perma necer por algum tempo na mesma equipe embora de tempos em tempos pequenas mudan as rotacionando membros de um equipe para a outra podem ser positivas para disseminar o conhecimento dentre as equipes CONTRATA O COLABORATIVA Algo que sem d vida influencia na forma o de equipes s o os novos membros que s o contratados ao longo do tempo A contrata o colabo rativa uma pr tica que basicamente consiste em permitir que as pessoas da equipe da qual possivelmente o candidato far parte possa participar do processo de contrata o fazendo perguntas e criando desafios para o candidato claro que essa pr tica requer confian a da gest o e maturidade da equipe mas dessa forma al m de o time colaborar para selecionar pes soas mais aderentes cultura e s necessidades da organiza o as equi pes tendem a
51. 5 8 13 21 34 55 89 144 ou uma sequ ncia simplificada o 1 2 3 5 8 13 20 40 100 Assim utiliza se apenas os valores dentro da sequ ncia para representar o esfor o necess rio para a implementa o da hist ria 56 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio No Scrum utiliza se o Planning Poker ou Poker de Planejamento Nesta t c nica cada membro da equipe recebe um conjunto de cartas com os valores de uma sequ ncia como as descritas anteriormente Em seguida todas as hist rias s o anali sadas separadamente e cada membro da equipe coloca uma carta sobre a mesa com o n mero de pontos que considera que a hist ria consumir Quando houver grandes diferen as as pessoas que jogaram as cartas de maior e menor valor explicam suas raz es para escolher aquele valor e ent o com base nas explica es as cartas s o jogadas novamente at que um consenso seja encontrado e a estimativa seja definida Na realidade n o importa qual t cnica sua equipe utiliza o importante que todos os membros da equipe participem e que seja definido um valor de esfor o ou custo para que seja poss vel medir a velocidade da equipe para fundamentar o planejamento de releases e dar uma certa previsibilidade para os interessados stakeholders 3 10 DEFININDO ENTREGAS COM O PLANEJAMENTO DE RE LEASES O objetivo das reuni es de planejamento de releases definir quando novos incre mentos do projeto se
52. AN Taiichi Ohno criador do Toyota Production System TPS definiu o como um sis tema de gerenciamento para a elimina o absoluta de desperd cios e disse que o que deve ser feito uma linha do tempo entre o momento que o cliente faz um pedido at o momento em que recebe o produto e paga por ele ou seja o processo completo Depois de identificar todas as etapas dessa linha do tempo deve se reduzi la removendo tudo o que n o agrega valor ou seja deve se eliminar todo o desperd cio Em suma qualquer atividade que consuma tempo ou dinheiro e n o agrega valor desperd cio 5 5 Eliminando Desperd cios com Lean Casa do C digo Desperd cio com Trabalho Parcialmente Pronto Para ind strias em geral acumular estoque considerado desperd cio O esto que precisa ser movimentado de um lado para o outro armazenado rastreado pode ser perdido roubado ficar obsoleto quebrar etc por isso que o ideal ter o m nimo de estoque poss vel Voc deve estar se perguntando qual a rela o de estoque com software Esto que na perspectiva de software para Poppendieck representa trabalho parcialmente pronto trabalho que pode ficar obsoleto pode ser perdido 48 Trabalho parcialmente pronto pode ser por exemplo requisitos especificados com excesso de detalhes antes do desenvolvimento ser iniciado Lembre se que re quisitos podem mudar e tornar se obsoletos ou ainda hist rias de usu rios desen volvidas a
53. Agile Desenvolvimento de software com entregas frequentes e foco no valor de neg cio Casa do C digo ANDRE FARIA GOMES Casa do C digo Todos os direitos reservados e protegidos pela Lei n 9 610 de 10 02 1998 Nenhuma parte deste livro poder ser reproduzida nem transmitida sem auto riza o pr via por escrito da editora sejam quais forem os meios fotogr ficos eletr nicos mec nicos grava o ou quaisquer outros Casa do C digo Livros para o programador Rua Vergueiro 3185 8 andar 04101 300 Vila Mariana S o Paulo SP Brasil Casa do C digo Agradecimentos Escrever este livro foi um grande desafio para mim e passar por esse desafio foi um grande lembrete do qu o valiosos s o meus familiares amigos colegas de trabalho e de comunidade Sem eles esse livro n o teria se tornado realidade Agrade o Editora Casa do C digo nas pessoas de Paulo Silveira e Adriano Al meida pela oportunidade que me foi concedida e pela confian a para escrever sobre um assunto t o importante nos dias de hoje como o desenvolvimento gil de sofware Agrade o Bluesoft e a todos os seus colaboradores que sempre me apoiam e ins piram para buscar melhores pr ticas e abordagens no desenvolviemento de software e na gest o Em uma das vezes que foi entrevistado Steve Jobs sugeriu que devemos nos ex por s melhores coisas que seres humanos j fizeram suas obras seus trabalhos e ent o tentar t
54. Quando ele ten tou subir a escada para pegar as bananas tamb m apanhou dos outros Outro ma caco foi substitu do e o mesmo epis dio se repetiu por diversas vezes e inclusive os novos macacos aprenderam a bater nos outros que tentavam pegar as bananas Depois de algum tempo todos os macacos foram substitu dos por m o h bito permaneceu e mesmos os macacos que nunca viram o jato d gua continuavam ba tendo naqueles que tentavam subir para pegar bananas Se fosse poss vel perguntar a algum deles porque eles batiam em quem tentasse Casa do C digo subir a escada com certeza a resposta seria algo do tipo N o sei mas as coisas sempre foram assim por aqui Voc j viu alguma coisa desse tipo acontecer nas empresas em que trabalhou Alguma regra que j n o faz mais sentido mas que por m continua sendo utilizada por todos mesmo sem que saiba o motivo Infelizmente isso n o t o incomum e inclusive equipes geis podem cair nesse engano M todos geis ganharam bastante popularidade e atualmente v m sendo utili zados por grande parte das organiza es que desenvolvem software mas essa popu laridade tamb m trouxe alguns problemas Muitos passaram a se interessar por m todos geis apenas porque grandes players do mercado est o utilizando por m n o buscaram entender a ess ncia co labora o agregar valor de neg cio entregas frequentes etc e ficaram apenas na forma quadros na parede estimat
55. SCREVENDO HIST RIAS DE USU RIO Hist rias de usu rio s o descri es simples e curtas de funcionalidades que dever o ser implementadas no software As Hist rias s o geralmente escritas pelo pr prio Product Owner com suas pr prias palavras e ent o s o registradas em cart es que posteriormente s o anexadas ao quadro da equipe As hist rias cont m apenas uma breve descri o que representa uma necessi dade do cliente por m apesar da simplicidade da hist ria o cliente deve possuir o conhecimento necess rio para disponibilizar informa es de neg cio para que a equipe possa transformar sua necessidade em software Por exemplo imagine uma hist ria cuja funcionalidade seja desenvolver um relat rio de balan o cont bil ser necess rio que o cliente possua o conhecimento de neg cio necess rio isso saiba o que um balan o cont bil e quais s o suas caracter sticas para que assim ele possa explicar equipe o que precisa ser feito 45 3 6 Escrevendo Hist rias de Usu rio Casa do C digo Toda hist ria de usu rio deve possuir um crit rio de aceita o tamb m defi nido pelo cliente que permite equipe identificar quando ela est implementada por completo e com sucesso Ao escrever uma hist ria o cliente assume responsabi lidade sobre ela As hist rias de usu rio t m car ter de neg cio por isso instalar o servidor de integra o cont nua ou atualizar a vers o da biblioteca
56. a coaching desenvolvimento de carreira confian a feedback e oportuni dade para reportar o status do trabalho Tothman e Derby recomendam que os gerentes fa am reuni es one on ones se manalmente Na Bluesoft n s as fazemos a cada tr s meses e sem d vidas podemos dizer que elas trazem bons resultados DICAS PARA REUNI ES ONE ON ONES e Ritmo Encontre as pessoas no mesmo dia e por volta do mesmo hor rio isso cria ritmo e faz com que as pessoas venham prepara das e Presen a n o permita que a reuni o seja interrompida por liga es e mails etc e Compromisso cancelar ou desmarcar por qualquer raz o de monstra que voc n o se importa e Consist ncia Procure manter um formato semelhante em diferen tes encontros e Adaptabilidade Adapte a frequ ncia formato ao momento e cir cunstancias do time 127 6 2 Feedback Casa do C digo N o se engane com a ideia de que o gestor n o deveria passar tanto tempo com as pessoas para n o perder o foco da gest o porque isso faz parte da gest o Aprender sobre as pessoas faz parte Saber em que elas s o boas e quais s o seus pontos a melhorar importante Aprender sobre seus desejos e aspira es tamb m faz parte Feedback 360 Feedback essencial para o amadurecimento e evolu o das pessoas Precisamos saber se estamos indo bem e em que precisamos melhorar Imagine se voc pudesse receber feedback de diversos pontos de vista de
57. a e adapta o do processo As reuni es de retrospectiva s o uma excelente forma para faz lo As retrospectivas s o naturais afinal todo final de ano voc provavelmente faz a sua lista de desejos para o ano novo e uma reflex o sobre tudo que conquistou no ano que est acabando De forma semelhante ao final de cada itera o as equipes 101 5 4 Melhoria Cont nua com Retrospectivas Casa do C digo se re nem para uma retrospectiva que visa levantar todos os acontecimentos impor tantes da itera o e refletir sobre o que foi bom o que deve ser mantido e o que pode ser melhorado Nessas reuni es todos os membros da equipe t m a oportunidade de falar sobre o que est ou n o funcionando bem sugerir novas pr ticas tecnologias e apresen tar outras ideias em geral dessa forma todos podem contribuir para a melhoria do processo Outro ponto muito importante das retrospectivas o levantamento dos acon tecimentos mais significantes da itera o quando a equipe apresenta as principais li es aprendidas que ser o levadas para o futuro As retrospectivas n o t m como foco apenas quest es voltadas ao lado t cnico do desenvolvimento de software mas v o al m e devem tratar tamb m do lado humano e do relacionamento entre as pessoas envolvidas no projeto Isso segundo Esther Derby e Diana Larser duas das maiores especialistas no assunto s o quest es t o desafiadoras quanto ou mais desafiadoras do que as quest e
58. a uma dessas atividades possa ter sua pr pria cad ncia para melhor se ajustar realidade e necessidade que o processo demanda Cad ncias s o repeti es que se sucedem em intervalos regulares Este um con ceito do m todo Kanban que determina o ritmo de um determinado tipo de evento Prioriza o entregas retrospectivas e qualquer evento recorrente podem ter sua pr pria cad ncia M todos geis no geral controlam cad ncias atrav s das itera es que geral mente duram de uma a quatro semanas Dentro de cada itera o realiza se planeja mento desenvolvimento testes revis es retrospectivas etc Tudo isso dentro de um per odo pr definido J com Kanban o processo um fluxo cont nuo e n o preciso que todo o tra balho planejado esteja conclu do para que uma entrega seja realizada No momento 16 Casa do C digo Cap tulo 1 Introdu o M todos geis da entrega algumas tarefas estar o prontas e outras em progresso as que estiverem prontas far o parte da entrega e as que n o estiverem ficar o para a pr xima Em meados de 2007 Rick Garber e David J Anderson apresentaram nas confe r ncias o Lean New Product Development e Agile 2007 os resultados prelimina res do uso de Kanban na Corbis uma empresa que vende imagens e clips de v deo fundada por Bill Gates da Microsoft Desde ent o o Kanban vem ganhando mais e mais for a na comunidade de desenvolvimento de software e mais em
59. a vez por todas ou simplesmente aplicaram um paliativo para aliviar os sintomas do problema temporariamente Que tal marcar uma primeira rodada de one on ones Procure um assunto de interesse de sua equipe e proponha a forma o de um Clube do Livro para fomentar a discuss o e aprendizado Marque um primeiro coding dojo com seu time Fa a uma apresenta o sobre esse cap tulo e marque uma Brown Bag Sessions para apresentar o que voc tem aprendido Converse com sua equipe sobre ideias de projetos melhorias que sempre quise ram ver nos produtos da sua organiza o ou experimentos que gostariam de fazer Que tal propor um Hackathon para criar uma oportunidade de colocar essas ideias em pr tica Existe algum assunto tecnologia pr tica que lhe interessa no contexto da sua organiza o Voc acha que outras pessoas tamb m poderiam estar interessadas em discutir e evoluir esse tema na sua organiza o Que tal formar uma comunidade pr tica em cima disso Proponha gest o da sua organiza o a cria o de um quadro de autoridade para deixar a autonomia do seu time transparente dentre as diversas reas de decis o chave do seu projeto 141 CAP TULO 7 E Agora Agora al m de conhecer um pouco mais sobre m todos ageis voc ja tem um boa ideia de muitas praticas e t cnicas interessantes as quais pode aplicar no seu dia a dia O aprendizado n o acaba nunca e utilizar um m todo gil s o come o C
60. abalho n o realizado essencial e As melhores arquiteturas requisitos e designs emergem de equipes auto organiz veis e Em intervalos regulares a equipe reflete sobre como se tornar mais eficaz e ent o refina e ajusta seu comportamento de acordo Os profissionais que deram origem ao manifesto gil foram Kent Beck Mike Be edle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Ma rick Robert C Martin Steve Mellor Ken Schwaber Jeff Sutherland e Dave Thomas Ao longo desse livro n s estudaremos como esses valores e princ pio s o coloca dos em pr tica nas atividades e no dia a dia das equipes geis 1 2 M TODOS GEIS O Manifesto gil o embasamento filos fico de todos os m todos geis e diversos m todos de desenvolvimento de software est o alinhados a ele A maioria deles se utiliza de ciclos curtos que s o chamados de itera es e normalmente t m dura o de poucas semanas dessa forma garantindo feedback frequente e respostas r pidas s mudan as Cada itera o cont m todas as etapas necess rias para que se realize um incre mento no produto ou seja no software planejamento an lise design codifica o testes e documenta o Em m todos n o geis tamb m conhecidos como m todos tradicionais geralmente se encontra um processo em cascata em que todas as eta pas citadas s o executadas uma n
61. aceitar melhor o novo membro dado que participaram ativamente do processo de contrata o e sele o e concordar o que o novo membro tem as caracter sticas que consideram importantes para a equipe 6 5 PR TICAS DE APRENDIZAGEM Sejamos claros Sua carreira sua responsabilidade seu empregador n o sua M e Robert C Martin 133 6 5 Pr ticas de Aprendizagem Casa do C digo H um antigo ditado que diz que como na natureza ou voc est verde e cres cendo ou maduro e apodrecendo Na rea de tecnologia da informa o a taxa de mudan a e inova o muito alta e n s profissionais n o podemos parar de apren der Jurgen Appelo afirma que a educa o dos colaboradores n o a principal ativi dade da organiza o Por outro lado esperar que as pessoas se desenvolvam sozinhas nem sempre uma abordagem bem sucedida Eu acredito que a maioria das pes soas quer aprender por m n o sabe como ou acabam focando em coisas irrelevantes Defina restri es no ambiente para que as pessoas aprendam coisas relevantes 11 Alguns profissionais infelizmente n o se responsabilizam por seu pr prio de senvolvimento profissional e como em organiza es tamb m n o h incentivo esses acabam ficando improdutivos e desatualizados com o tempo Em seu livro Clean Code Robert Martin enfatiza a import ncia de que todos os profissionais se responsabilizem por suas carreiras 42 algumas org
62. ada time cada organiza o cada projeto diferente e ser uma experi ncia nica e um desafio nico Muito do que conheceu nesse livro poder te ajudar a descobrir formas melhores de enfrentar esses desafios e de buscar ideias para otimizar o seu processo para cada um dos cen rios que encontrar Procure dar mais import ncia sempre para os princ pios e valores geis do que para as pr ticas em si as pr ticas poder o e dever o mudar mas os valores devem permanecer Para que possamos discutir sobre m todos geis existe um grupo de discuss es no Google Groups l voc poder interagir comigo e com outros leitores do livro Acesse em https groups google com d forum livro agile Casa do C digo Fique vontade para entrar em contato comigo nas redes sociais Para acessar os links de todas as redes sociais que participo acesse http contato andrefaria com Aproveito tamb m para convid lo a ler os artigos que escrevo em http blog andrefaria com Por fim mais uma vez agrade o voc Obrigado 144 CAP TULO 8 Ap ndice A Ferramentas de Apoio essencial para equipes distribu das ou equipes que possuem membros que traba lham em regime de home office trabalhar remotamente de casa possuir um soft ware que os ajude a manter a visualiza o do fluxo de trabalho e mesmo para times que trabalhem colocados um software pode ser de grande ajuda embora n o seja essencial Uma das principais
63. ado por m ainda n o foi terminado e de acordo com o pensamento lean isso desperd cio e deve ser eliminado Existe uma rela o entre o trabalho em progresso WIP e o lead time uma rela o linear proporcional isso quer dizer que o lead time cresce medida que o tra balho em progresso cresce e diminui a media que o trabalho em progresso diminui Essa rela o conhecida na industria como a lei de little 50 Definimos o limite do trabalho em progresso no quadro adicionando limites ex pl citos que definem quantos itens podem estar em progresso em cada estado do fluxo de trabalho ou seja cada coluna do quadro Veja na figura 3 3 PARA FAZER DESENVOLVIMENTO TESTES DEPLOY Figura 3 3 Quadro com WIP Reduzir o trabalho em progresso reduz tamb m o lead time permitindo que se entregue com mais frequ ncia Para isso importante definir se ser ou n o permi tido que cada membro trabalhe em mais de uma tarefa ao mesmo tempo Trabalhar paralelamente em duas tarefas pode levar a problemas como interrup es falta de foco desperd cio de tempo na mudan a de contexto ou at mesmo na mudan a de ambiente de desenvolvimento coisas que levam perda de produtivi dade Experimentos emp ricos devem ser feitos em cada equipe para verificar o que funciona melhor 44 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio Os limites podem ser definidos inicialmente com um pouco mais do que a quan
64. afirmaram ter alcan ado melhor produtividade depois da transi o para m todos geis Equipes mais Motivadas M todos geis promovem ritmos sustent veis de trabalho s o muitos os casos em que organiza es reportaram uma diminui o significativa nas horas extras e madrugadas trabalhadas depois da transi 10 Casa do C digo Cap tulo 1 Introdu o M todos geis o para m todos geis 20 A promo o do ritmo sustent vel de uma cul tura de qualidade de constante comunica o e trabalho em equipe s o alguns dos fatores que contribuem para equipes mais motivadas e satisfeitas com seu ambiente de trabalho Melhor Disciplina na Engenharia e Melhor Qualidade Interna A utiliza o de pr ticas geis como redu o de d vida t cnica melhorar a qualidade interna do produto refactoring desenvolvimento orientado a testes e progra ma o em par unido ao mindset de qualidade estimulado de pelos m todos geis contribuem para a entrega de produtos com melhor mantenabilidade extensibilidade e com menos defeitos Processo de Desenvolvimento Simplificado Os m todo geis s o em re gra geral menos prescritivos do que os m todos tradicionais definem menos pap is e menos artefatos S o mais facilmente compreendidos pela equipe e oferecem maior margem para otimiza o e adapta o para a maior efici ncia no contexto da organiza o em que est sendo aplicado e Redu o de Risco O plan
65. al oa oben ae 81 49 Programa em Par 2 6 sso cee bbe as eis ERE RH SER kay 83 410 Revis o de C digo x ig scs oe kOe SERRE HE O44 EER SS 86 dit Divida T ecnics ses ea 66d mad bet ww oa he bo wee os 87 4 12 Agilidade Expl cita com Mural de Praticas 90 4 13 E agora o que eu fa o amanh ks a hw oe ee ERS 91 5 Otimizando Valor 93 1 Direcionando a Equipe occo inpatti tiae a a bb ees 93 ya Ma s neci se ma aaor RU DA ER eR aed 95 5 3 Apresente o Resultado em Reuni es de Demonstra o 101 5 4 Melhoria Continua com Retrospectivas 0 101 5 5 Eliminando Desperd cios com Lean 0 111 56 E agora o que eu fa o amanh se cc ee ee we edt ee ee 114 6 Otimizando o Sistema 117 Ga A Gest o pode ser gil a Keg a eee CREE EAR dA 118 62 Feedback eae ade oa Ghee Bo Dal ood E RE ROG eke De 126 6 3 Escalando gil com Programas e Portf lios 4 129 6 4 Forma o das Equipes 00 eee eee eee 130 65 Protease Aprendizagem lt ee ce eb Sw ee ew AE Oe Ho 133 viii Casa do C digo Sum rio 66 Hackathon ss dos genes bbe bi o SE aoe be Pee Sad US EAD 138 6 7 Comunidades de Pr tica csssasama ma 6 dos peca EUA aa 139 6 8 E agora o que eu fa o amanh sussa pas res da eeu s 141 7 E Agora 143 8 Ap ndice A Ferramentas de Apoio 145 Bibliografia 151 CAP TULO 1 Introdu o M todos geis Na semana passada entrevistei Joana uma
66. anda quem pode obedece quem tem ju zo Podemos dizer sem possibilidade de erro que ainda o modelo de gest o mais utilizado na pr tica Gest o 2 0 Focada em t cnicas esta vers o procura corrigir alguns dos pro blemas da primeira vers o de gest o mas mantendo a mesma estrutura top down o que n o surpreendentemente resolve muito pouco Poder amos dizer que uma Gest o 1 0 turbinada por Balanced Scorecards Six Sigma TQM e outros add ons Gest o 3 0 Focada na complexidade esta gest o encara as organiza es como 119 6 1 A Gest o pode ser gil Casa do C digo redes e n o como hierarquias e nessas redes as pessoas e seus relacionamentos de vem estar no foco da gest o mais do que os departamentos e seus lucros A Gest o 3 0 sugere que a gest o trabalhe com seis vis es N o toa essas vi s es s o representadas por um modelo um pouco diferente dos conhecidos c rculos flechas e ret ngulos de desenhos organizacionais veja na figura 6 1 algo bem mais pr ximo do que muitas das organiza es se parecem monstros Alinhar Restri es Desenvolver Compet ncias Empoderar Times Estruturar Energizar as Pessoas Melhorar Tudo Figura 6 1 Martie O Modelo de Gestao 3 0 Desenho por Jurgen Appelo Energizar pessoas Uma pessoa com paix o melhor que quarenta pessoas simplesmente interessadas E M Forster Romancista Ingl s Pess
67. ando uma Itera o Casa do C digo uma conversa criem hist rias de usu rio que representam as funcionalidades a se rem implementadas no software Ao decorrer deste cap tulo o conceito de hist rias de usu rio ser mais ampla mente explorado mas antes disso explicaremos um pouco mais o que se faz em um planejamento de itera o 3 3 PLANEJANDO UMA ITERA O O planejamento de itera es permite estruturar as atividades do dia a dia da equipe Um release pode conter v rias itera es figura 3 1 de forma que as hist rias que precisam ser entregues no release s o inclu das em uma ou mais itera es Durante a itera o as hist rias s o desenvolvidas e no final se tem um software desenvolvido e testado e ao terminar uma itera o uma nova itera o iniciada li itera o 1 Itera o 2 Itera o 3 Itera o 4 aa d Release 1 Release 2 Figura 3 1 Releases e Itera es As itera es geralmente t m periodicidade semanal por m tanto o tempo das itera es como dos releases podem ser definidos de acordo com a necessidade de cada organiza o O tamanho ideal para uma itera o o menor tempo poss vel que seja necess rio para que a equipe consiga entregar algo de valor com qualidade para o cliente Ao planejar uma nova itera o importante ter em m os o resultado da itera o passada isto a soma das estimativas das hist rias que foram desenvolvidas Esse o n
68. aniza es in centivam o aprendizado e criam um ambiente repleto de recursos para que as pessoas naturalmente estejam sempre aprendendo algo novo Isso fant stico mas se sua organiza o n o der espa o para atividades de aprendizagem n o desanime por isso afinal a responsabilidade ainda sua Nesse t pico abordaremos algumas pr ticas que voc e seu time podem utilizar para estimular o aprendizado de todos O ambiente faz diferen a A equa o de Lewin desenvolvida pelo psicologo Kurt Lewin defende que o comportamento de uma pessoa uma fun o de sua personalidade e de seu ambiente 45 Isso significa que ao mudar o ambiente voc pode mudar o comportamento de algu m Para ilustrar imagine que voc um desenvolvedor que acabou de ser contratado por uma nova empresa Em seu primeiro dia de trabalho notou que todos os seus colegas t m o h bito de ler e estudar bastante h livros por toda a parte espalhados nas mesas das pessoas ao ouvir uma conversa sobre tecnologia no caf voc por um momento pensou que as pessoas estavam falando em grego Scala Big Data Clojure Crystal Dataware house Business Intelligence Hadoop Kernel Na verdade era apenas uma conversa normal sobre tecnologia com uma s rie de palavras chave que voc nunca tinha ouvido falar antes Em um ambiente como esse h uma grande probabilidade de que voc chegar em casa e naturalmente come ar a estudar e buscar equipara o com s
69. ar ao cliente mais hist rias Ent o o cliente escolhe quais dever o ser adicionadas itera o considerando o tempo restante e sua prioridade Na pr xima itera o o cliente poder incluir um n mero maior de pontos considerando que a velocidade da equipe melhorou Isso geralmente acontece medida que a equipe vai amadurecendo e ganhando mais dom nio sobre a tecnologia utilizada no projeto e nos conceitos de neg cio Um problema muito comum que pode afetar a ordem de desenvolvimento das hist rias s o as depend ncias t cnicas entre elas poss vel que o cliente determine que uma hist ria espec fica tenha prioridade em rela o outra por m tecnica mente pode ser mais vi vel fazer o contr rio Nesses casos importante que a equipe seja sincera com o cliente em rela o s dificuldades t cnicas e apresente a ele os be nef cios de implementar as hist rias na ordem inversa Entretanto sempre reco mendado que a equipe permita que o cliente escolha o que ele quer que seja entregue primeiro e se esforce ao m ximo para entregar de acordo com a prioridade determi nada por ele Em se falando de XP e Scrum n o recomendado adicionar novas hist rias a uma itera o que j tenha sido iniciada comum que ao longo de uma itera o o cli ente solicite que alguma nova hist ria seja adicionada com urg ncia Atender a este tipo de solicita o emergente e n o planejada pode impactar negativamente no anda mento
70. ar para manter o c digo sempre limpo al m de uma atitude profissional do desenvolvedor muito eficiente em termos de custos para a organiza o uma vez que a mantenabilidade do software ser sustent vel a m dio e longo prazo Para Uncle Bob desenvolvedores profissionais escrevem c digo como profissio nais e c digo escrito por profissionais c digo limpo 4 4 PROPRIEDADE COLETIVA DO C DIGO A Propriedade Coletiva do C digo uma das pr ticas de XP e consiste na ideia de que o time respons vel por todo o reposit rio de c digo em vez de os indiv duos serem respons veis apenas pelo c digo que eles mesmos escreveram Essa pr tica faz com que manter e garantir a qualidade do c digo seja responsa bilidade de todos os membros do time Qualquer um pode realizar as altera es que forem necess rias em qualquer parte do sistema 66 Nessa abordagem quando um desenvolvedor precisar alterar determinada parte do c digo n o precisar pedir permiss o para o desenvolvedor que o escreveu e ter total autonomia de fazer o que precisa ser feito Essa pr tica funciona muito melhor quando em conjunto com revis es de c digo programa o em par e integra o cont nua Al m de melhorar a qualidade tamb m ajuda na elimina o de ilhas de conhecimento Voc j viu uma situa o em que determinada parte de um projeto precisa ser alterada mas a nica pessoa do time que escreveu compreende e conhece aquele c digo e
71. arede que faz da sua equipe uma equipe gil O fil sofo grego Arist teles que viveu h mais de 300 A C j reconhecia que n s somos frutos dos nossos h bitos das nossas a es frequentes e constantes Nessa linha de pensamento voc n o pode dizer que uma pessoa caridosa s porque uma vez na vida fez uma doa o para uma causa beneficente n o pode dizer que uma pessoa aventureira se quando tinha 17 anos de idade pulou de bungee jump no parque de divers es Voc tamb m n o pode dizer que sua equipe gil s porque 1 dos 25 desenvol vedores do seu time uma vez tentou aplicar desenvolvimento guiado por testes em seu tempo livre e nem pode dizer que sua organiza o tem uma cultura de apren dizagem s porque h um espa o para palestras uma vez no ano De jeito nenhum Arist teles sabia bem do que estava falando O ponto que n s podemos dizer que somos geis porque n s estamos frequen temente utilizando pr ticas geis e n s podemos dizer que nossa organiza o tem uma cultura de aprendizagem porque estamos aprendendo algo novo todos os dias Quanto mais eu treino mais sorte eu tenho Tiger Woods A pergunta quais s o as pr ticas que fazem de n s uma equipe gil E uma ferramenta muito simples para ajudar as equipes a se fazerem essa pergunta com frequ ncia o mural de pr ticas que consiste basicamente em tornar expl citas to das as pr ticas de uma equipe atrav s de pe
72. argalos e problemas de trabalho parado Seu time est mantendo as op es abertas No que voc s est o se comprome tendo cedo de demais sem saber o porqu Voc e seu time sabem o qual o valor de neg cio que est por tr s de cada uma das funcionalidades que est o desenvolvendo Ser que voc s podem ajudar o PO a encontrar formas mais eficientes e baratas se conquistar o valor de neg cio que est sendo perseguido 66 CAP TULO 4 Entregando Valor Este o segundo n vel de flu ncia gil no qual os benef cios predominantes s o a alta produtividade e a melhoria na qualidade externa do produto um momento oportuno para investimento nas capacidades t cnicas da equipe e por isso agora ser o apresentadas algumas t cnicas e pr ticas de engenharia utili zadas por equipes geis Equipes neste n vel de flu ncia t m a habilidade de manter seus produtos sempre ou quase sempre em um estado de pronto para entrega permitindo assim que o produto seja atualizado com a velocidade e frequ ncia que o mercado exige Capacitar uma equipe para alcan ar um alto n vel de habilidade t cnica requer tempo esfor o e muita pr tica Cursos treinamentos contrata o de desenvolvedo res experientes para ensinar os menos experientes podem ser importantes para se atingir esse objetivo 57 O aprendizado de t cnicas mais avan adas e o pagamento da d vida t cnica cri ada pela falta de experi ncia e c digo legado podem
73. as coisas possam caminhar conforme o plane jamento Outros tipos de demandas n o planejadas podem surgir ao longo da itera o Um exemplo muito comum s o os indesej veis defeitos Por maiores que sejam as atitudes preventivas da equipe para manter a qualidade do software com testes e in tegra o cont nua comum que defeitos se apresentem aqui ou ali Nesses casos pode ser necess rio que a equipe pare o trabalho e tome provid ncias para sanar o problema A l gica simples se uma determinada funcionalidade j est em produ o significa que ela era mais importante do que as outras que ficaram pendentes por isso foi priorizada e desenvolvida antes das outras Caso um defeito surja e e essa pare de funcionar provavelmente ser mais importante corrigir o defeito do que entregar algo que tinha menos prioridade Vale a pena acompanhar as demandas de trabalho n o planejado que surgem durante uma itera o Se for muito frequentes fique atento algo provavelmente est errado ou talvez seja mais interessante avaliar trabalhar com fluxo cont nuo em vez de itera es 3 4 A REUNI O DI RIA Estabelecer uma comunica o eficiente entre os membros da equipe extremamente importante As reuni es di rias conhecidas no XP como Stand Up Mettings Reu ni es em P e no Scrum como Daily Scrum Scrum Di rio s o pr ticas muito efi cazes para que todos estejam sempre a par do status atual do projeto 40 Casa do C
74. as do produto interessante associ las s hist rias de usu rio para que o time saiba quem o usu rio interessado na hist ria a ser desenvolvida poss vel fazer isso tornando a persona explicita na descri o da hist ria Como um contador eu gostaria de buscar os ltimos lan amentos Como um gerentes de contas eu gostaria de atualizar o saldo Como um consumidor eu gostaria de 55 3 9 Melhorando a Previsibilidade com Estimativas Casa do C digo 3 9 MELHORANDO A PREVISIBILIDADE COM ESTIMATIVAS A estimativa permite que a equipe me a a produtividade e saiba quanto tempo ser necess rio para concluir o desenvolvimento das hist rias do projeto al m de ajudar o cliente a entender qual o custo do desenvolvimento de cada hist ria e qual a m dia de tempo que ser necess rio para que a funcionalidade seja desenvolvida e entregue Estimativas s o complexas e n o s o precisas Uma s rie de fatores devem ser levados em considera o entre eles a maturidade da equipe em rela o ao projeto e s tecnologias aplicadas nele comum que no in cio do projeto funcionalidades de complexidades semelhan tes levam mais tempo para serem implementadas do que no final do projeto Isso ocorre porque a equipe ganha produtividade medida que aprende mais sobre o ne g cio e sobre a tecnologia utilizada Assumindo essa premissa poss vel concluir que a estimava de uma determinada hist ria pode mudar ao lon
75. ase para entrega Quanto menores forem os ciclos de release mais r pido o cliente poder se beneficiar do produto e oferecer feedback para que ele possa ser melhorado Para tra ar um planejamento de releases preciso estabelecer per odos fixos de entrega Recomenda se que seja um curto espa o de tempo Com a vis o do produto em mente necess rio estabelecer quais s o as funcionalidades que podem agregar maior valor ou seja as que possuem maior valor de neg cio e ser o inclu das mais rapidamente nos releases Tendo em m os a velocidade do time poss vel ter uma ideia de quantas fun cionalidades podem ser inclu das em um determinado per odo de tempo e ent o dividir as funcionalidades em releases N o planeje para prazos muito longos Quanto mais longo o prazo maior a in certeza N o necess rio e nem recomend vel escrever e analisar todas as hist rias no in cio do projeto Da mesma forma que a equipe aprende e aprimora suas t c nicas de desenvolvimento a cada release o cliente utiliza o software e novas ideias surgem bem como ideias antigas podem ser deixadas de lado por isso que n o interessante tentar prever futuros muito distantes quanto mais distante maior a incerteza Uma grande diferen a dos m todos geis em rela o aos tradicionais que os m todos geis n o tentam impedir o cliente de realizar mudan as no planejamento 59 3 11 Roadmap do Produto Casa do C digo Em vez d
76. atual e Responder a mudan as mais que seguir um plano Mesmo havendo valor nos itens direita valorizamos mais os itens esquerda Al m desses 4 valores o manifesto gil tamb m composto por 12 princ pios e Nossa maior prioridade satisfazer o cliente atrav s da entrega cont nua e adi antada de software com valor agregado e Mudan as nos requisitos s o bem vindas mesmo tardiamente no desenvol vimento Processos geis tiram vantagem das mudan as visando vantagem competitiva para o cliente Entregar frequentemente software funcionando de poucas semanas a poucos meses com prefer ncia menor escala de tempo e Pessoas de neg cio e desenvolvedores devem trabalhar diariamente em con junto por todo o projeto e Construa projetos em torno de indiv duos motivados D a eles o ambiente e o suporte necess rio e confie neles para fazer o trabalho e O m todo mais eficiente e eficaz de transmitir informa es para e entre uma equipe de desenvolvimento atrav s de conversa face a face e Software funcionando a medida prim ria de progresso 12 M todos geis Casa do C digo e Os processos geis promovem desenvolvimento sustent vel Os patrocinado res desenvolvedores e usu rios devem ser capazes de manter um ritmo cons tante indefinidamente e Cont nua aten o excel ncia t cnica e bom design aumenta a agilidade Simplicidade a arte de maximizar a quantidade de tr
77. azer ou seja que a es tomar neste momento que o foco da reuni o mudado do passado para o futuro isto da itera o anterior para a pr xima itera o importante que a equipe esteja comprometida com os itens que foram seleci onados para serem melhorados na itera o Um exemplo de a o a ser tomada em 109 5 4 Melhoria Cont nua com Retrospectivas Casa do C digo uma nova itera o Todos os membros da equipe trabalhar o em par dois dias por semana Evite a todo custo sair da retrospectiva sem uma lista clara de a es a serem to madas para alcan ar melhorias Mantenha sempre o foco em coisas que efetivamente podem ser melhoradas e evite investir muito tempo em quest es que n o dependem da equipe ou n o podem ser mudadas como mau tempo tr nsito etc importante que a responsabilidade de realizar as a es definidas na retrospec tiva seja compartilhada e dividida por toda a equipe N o permita que apenas um ou poucos membros da equipe constantemente tomem essa responsabilidade para si impedindo que outros colaborem Encerrando a Retrospectiva Finalmente no quinto passo a equipe deve definir como documentar o que foi decidido e aprendido na reuni o Para isso algumas equipes fotografam o que foi escrito na lousa outras elegem um membro da equipe para criar uma pauta outros escrevem todos os itens em cart es e os guardam isso fica a crit rio da equipe importante que as decis e
78. be que o design atual do sistema precisaria sofrer algumas altera es para que fosse poss vel criar testes de unidade para a alte ra o que est fazendo Voc agora precisa tomar uma decis o fazer um trabalho r pido e sujo para resolver o problema rapidamente mas deixando o c digo sem testes ou refatorar e alterar o design para que seja poss vel escrever testes de unidade Desenvolvedores precisam tomar decis es como essas diariamente e a cada tra balho r pido e sujo que fazem aumentam a d vida t cnica do projeto D vida t cnica uma met fora criada por Ward Cunningham que ilustra as con sequ ncias desses trade offs A ideia b sica por tr s do termo que diminuir a qua lidade aumenta o tempo de desenvolvimento a longo prazo Para Cunningham divida t cnica inclui coisas que voc escolhe n o fazer agora mas que impedir o desenvolvimento futuro se deixado de lado 21 Isso inclui 87 4 11 D vida T cnica Casa do C digo protela o de refatora o mas n o inclui protela o de funcionalidade a n o ser em casos que a entrega foi boa o suficiente por m n o satisfaz algum tipo de padr o de desenvolvimento D viDA T CNICA OU D BITO T CNICO No conte do sobre m todo geis da comunidade brasileira espe cialmente em blogs encontra se muito o termo d bito t cnico mas entende se que d vida uma tradu o mais correta para debt Em in gl s a pa
79. cios que os m todos geis podem oferecer E para que n o 22 Casa do C digo Cap tulo 2 Flu ncia gil fa amos como os macacos n s vamos buscar entender n o apenas a forma das pr ticas mas tamb m a ess ncia de cada uma delas 2 1 EVOLU O E MATURIDADE DE UMA EQUIPE GIL Unir se um bom come o manter a uni o um progresso e trabalhar em conjunto a vit ria Henry Ford Sempre que uma nova equipe formada naturalmente um processo de maturi dade acontece 51 not vel que um equipe que acabou de se formar n o trabalha com a mesma produtividade e dinamismo que uma equipe cujas pessoas j tiveram algum tempo para se conhecer os seus pontos fortes e suas dificuldades M todos geis requerem verdadeiras equipes n o apenas grupos 53 E verda deiras equipes geis s o formadas de pessoas com uma diversidade de habilidades que trabalham colaborativamente com uma vis o compartilhada para atingir deter minados objetivos As pessoas precisam trabalhar algum tempo juntas e passar por todos esses est gios por isso n o se deve mover pessoas de uma equipe para outra com alta frequ n cia como se fossem pe as de xadrez essa instabilidade toda pode destruir a integri dade do time Isso n o significa que de vez em quando n o seja interessante que as pessoas mudem de equipe para que possam diversificar suas experi ncias mas preciso encontrar um ponto de equil brio saud vel Ambos
80. critor e podcaster Escrevo artigos para revistas e portais de TI e mantenho meu blog andrefaria com Para entrar em contato comigo acesse http contato andrefaria com iii Casa do C digo Pref cio O ano era 2001 e eu estava prestes a abandonar a carreira de gerente de projetos de software Eu n o aguentava mais aquilo Era o escopo que sempre mudava O prazo e custo que sempre estouravam O cliente que nunca sabia o que queria A correria de fim de projeto Fins de semana e madrugadas trabalhando Conflitos Preju zo E a eterna esperan a de que no pr ximo seria diferente N o dava mais Naquele mesmo ano um amigo me emprestou um livro sobre uma tal FDD Feature Driven Development e ap s ler e ver sentido em muito do que estava ali decidi me dar mais uma chance e tentar novamente mas agora de uma forma dife rente afinal pensei se voc n o pode mudar uma situa o deve mudar sua atitude em rela o a ela Naquele momento abrindo minha mente s possibilidades abra cei Agile sem saber que aquilo era Agile e mudei completamente o meu destino profissional Depois do primeiro projeto conseguindo ter minha qualidade de vida e auto estima profissional recuperadas e vendo o sorriso no rosto do cliente decidi mergulhar de cabe a neste mundo N o haveria volta Hoje depois do que vi na pr tica nas trincheiras por todos esses anos eu afirmo a voc o resultado dos projetos de desenvolvimento de software qu
81. d vida t cnica ou seja uma lista de tarefas que podem ser realizadas para melhorar o c digo e essa lista pode ser priorizada pelo time e ent o pode se negociar com o Product Owner para que pouco a pouco esses itens sejam inclu dos nas itera es Poder amos ter itens como Refatorar M todo de 2000 linhas na Classe de Trans fer ncia Banc ria ou Atualizar Biblioteca POI para Vers o mais Recente para evitar 88 Casa do C digo Cap tulo 4 Entregando Valor Vazamento de Mem ria ou Aumentar Cobertura de Testes do M dulo de Empr s timos etc Alguns tipos de d vida t cnica podem ser deliberadamente deixados de lado por n o haver valor em resolv los Por exemplo em casos de produtos pr ximos ao t r mino de seu clico de vida ou de um prot tipo com objetivo nico de aprendizagem ou produtos com ciclos de vida muito curtos como projetos para campanhas de marketing pontuais por exemplo importante que o time foque naquilo que de fato trar benef cios para a produtividade do time e qualidade do produto E ent o Seu time est pronto para pagar suas d vidas Lembre se que assim como nas d vidas financeiras quanto mais tempo levamos para pagar mais dif cil porque paga se com juros NADA DE JANELAS QUEBRADAS Pesquisas no campo de criminalidade e decad ncia urbana descobri ram que uma janela quebrada pode rapidamente levar um pr dio limpo e intacto a se tornar um pr dio decadent
82. da ordem possui regras para tudo n o tem nenhuma liberdade para expressar sua criatividade ou para solucionar os problemas todos os hor rios est o definidos as tecnologias as linguagens de programa o o que se pode fazer o que n o se pode fazer H pouca ou nenhuma varia o 27 2 2 Ordem Caos e Complexidade Casa do C digo Os m todos geis s o uma resposta ao caos e ordem e prop em um cen rio que est justamente no meio termo a complexidade 8 veja na figura 2 3 Muitos autores chamam isso de a beira do caos Voc s precisa de um pouco ordem para que o sistema possa se auto organizar para atingir um determinado objetivo N o mais do que isso E essa ordem geralmente est presente nos m todos geis na forma de restri es Agilidade Figura 2 3 Complexidade Toda organiza o um sistema complexo adaptativo como um jogo em que as regras s o mudadas ao longo do curso e pelos pr prios participantes Jurgen Appelo Pense no Scrum como um exemplo A equipe precisa possuir de 5 a 9 membros Todos os dias o time deve fazer uma reuni o di ria de at 15 minutos Toda itera o tem como resultado um potencial incremento no produto etc Essas regras e restri es asseguram que a equipe trabalhe em um est gio intermedi rio entre a ordem e o caos Tudo aquilo que fica impl cito espa o para que ela possa se auto organizar e adaptar se para realizar o melhor trabalho
83. de inje o de depend ncias geralmente n o s o exemplos v lidos Podem at ser exemplos de tarefas mas n o de hist rias de usu rios Veremos a diferen a entre hist rias e tarefas mais adiante Alguns exemplos de hist ria de usu rios v lidas em um projeto de desenvolvi mento de um site de relacionamentos podem ser e Um usuario pode publicar suas fotos em seu perfil e Usu rios podem criar e participar de comunidades e Comunidades devem possuir moderadores Mike Cohn prop s um formato interessante que amplamente conhecido e uti lizado no mercado Eu como um papel quero funcionalidade para que valor de neg cio Se aplicarmos o modelo proposto nas hist rias citadas anteriormente elas fica riam da seguinte forma e Eu como um forista quero publicar minha foto em meu perfil para que os outros participantes possam me identificar mais facilmente e Eu como um usuario gostaria de criar uma comunidade para que eu possa reunir pessoas com interesses semelhantes aos meus Eu como um moderador gostaria aprovar ou rejeitar respostas a t picos do forum para evitar postagens inadequadas Investindo em Boas Hist rias Segundo Mike Cohn autor do livro User Stories Applied boas hist rias devem conter as seis caracter sticas seguintes 1 Hist rias devem ser independentes para evitar problemas de planejamento e estimativa Se duas hist rias possu rem depend ncia entre elas e uma tiver prio
84. do trabalho da equipe e como mencionado anteriormente pela mesma raz o n o recomendado alterar as hist rias de uma itera o em andamento Se houver muitos casos de mudan as de escopo dentro de uma itera o e isso realmente for importante para o neg cio talvez seja o caso de avaliar utilizar um m todo gil de fluxo cont nuo ao inv s de iterativo como Kanban por exemplo Alterar uma itera o em andamento pode significar trabalho perdido desgaste 39 3 4 A Reuni o Di ria Casa do C digo perda da concentra o e atrasos No entanto responder rapidamente s necessi dades de neg cio do cliente um valor gil e algo que deve ser sempre levado em considera o Em casos como este poss vel negociar com o cliente e depois de conscientiz lo da problem tica de alterar itera es em andamento incluir a hist ria emergente com a condi o de retirar da itera o outra hist ria com um valor de estimativa de esfor o igual ou pr ximo Deve se evitar claro retirar hist rias que j tenham seu desenvolvimento iniciado O cliente provavelmente ficar contente por sua solicita o emergente ter sido atendida e mais valor ter sido agregado ao seu neg cio Por m preciso ter cuidado para que essas emerg ncias n o se tornem algo constante e prejudicial Solicita es emergentes devem ser espor dicas preciso insistir para que o cliente tenha disci plina e respeite as itera es para que
85. e est com as regras de neg cio em mente ou descobrir posteriormente que o defeito existe porque n o passou pela qualidade ou ainda pior descobrir que o problema existe apenas quando o software j estiver em produ o A resposta claro muito bvia quanto mais cedo voc descobrir que o pro blema existe mais r pido e barato ser para resolv lo A mesma ideia aplicada na Toyota para defeitos em carros Ao longo desta se o estudaremos diversas t cnicas e abordagens diferentes para testes que combinadas podem ser teis e importantes para o desenvolver software com qualidade A pir mide de testes criada por Mike Cohn 20 um modelo interessante que al m de defender que diferentes tipos de testes podem ser combinados tamb m su gere uma propor o dentre os diferentes tipos como pode ser visto na figura 4 1 68 Casa do C digo Cap tulo 4 Entregando Valor Testes Explorat rios Manuais Testes de Ponta a Ponta Testes de Integra o API Service Testes de Unidade Figura 4 1 Pir mide de Automa o de Testes Diferentes tipos de testes t m objetivos distintos e seu custo de automa o e tempo de execu o tamb m diferem Testes de Unidade geralmente s o os mais r pidos se de automatizar e tamb m s o r pidos de executar por isso eles est o na base da pir mide e representam a maior parte dos testes propostos pelo modelo Em seguida temos os testes de integra o ta
86. e cada membro do time avalia objetivamente cada uma das compet ncias de todos os seus colegas atrav s de uma nota que pode ser de 1a 10 por exemplo Depois de todos terem avaliado os resultados s o consolidados e cada um recebe seus resultados assim como sua avalia o em rela o a m dia do time e sua pr pria autoavalia o Defina um timebox para o feeback para evitar que a sess o se torne cansativa e intermin vel Voc pode tentar diversos formatos at que encontre um que funcione melhor em sua equipe ou variar o formato a cada nova sess o de feedback O mais im portante ter em mente que o objetivo fomentar o feedback para que as pessoas melhorem 6 3 ESCALANDO GIL COM PROGRAMAS E PORTFOLIOS E quando uma equipe gil n o for suficiente E quando a organiza o tiver v rios produtos ou produtos grandes demais para uma nica equipe gil Como escalar a agilidade Como determinar quem trabalha no qu Essas s o perguntas comuns que nos fazemos ao nos deparar com situa es em que precisamos de diversas equi pes para atingir os objetivos da organiza o Desenvolvimento de sistemas de larga escala podem ser realizados atrav s de di versos times trabalhando paralelamente em um mesmo ciclo de releases geralmente com data e qualidade fixos por m com escopo vari vel 37 Esse n vel de desen volvimento em que h v rias equipes trabalhando com um objetivo final comum o n vel de Programa Em um cen
87. e e abandonado 68 A Teoria da Janela Quebrada afirma que uma janela quebrada se n o consertada por algum tempo transmite para as pessoas um senso que ningu m se importa com o pr dio 61 Ent o de repente outra janela quebrada lixo se acumula paredes s o pichadas em pouco tempo o pr dio fica t o prejudicado que o dono j n o consegue mais repar lo ent o o que antes era apenas um senso de abandono agora se torna realidade Da mesma forma quando um desenvolvedor deixa um c digo sem cobertura testes por exemplo o pr ximo desenvolvedor tem essa sen sa o que n o houve zelo por aquele c digo e cria um novo m todo deixando o sem testar tamb m Com o tempo ser poss vel notar uma grande queda na cobertura de testes tanto que talvez se torne muito dif cil para a equipe reverter o ce n rio O mesmo poderia valer para c digo deixado sem refatorar ou qualquer outra m pr tica de desenvolvimento Quando uma janela deixada quebrada outra ser quebrada e outra e outra Por isso n o deixe janelas quebrada se achar uma e nunca seja o primeiro a quebrar uma janela 89 412 Agilidade Expl cita com Mural de Pr ticas Casa do C digo 4 12 AGILIDADE EXPL CITA COM MURAL DE PR TICAS ys er ro a eer N s somos aquilo que fazemos com frequ ncia Excel ncia ent o n o um ato mas um h bito Arist teles Desculpe me mas eu tenho que dizer N o o quadro na p
88. e mais trabalho ou seja para que o processo seja alimentado Kanban dos m todos de desenvolvimento de software menos prescritivos que de acordo com Henrik Kniberg possui apenas tr s prescri es 34 1 Visualizar o fluxo de trabalho workflow 2 Limitar o trabalho em progresso 3 Gerenciar e medir o fluxo 17 1 8 Qual o Melhor M todo Casa do C digo Kanban incentiva a adapta o baseada em contexto Deste modo parte se da premissa que n o existe uma nica solu o que resolva todos os problemas de to dos os diferentes contextos e por isso h a necessidade de adapta o em que cada processo deve se adequar s necessidades do contexto a que pertence Kanban tamb m recomenda que se me a o lead time tempo m dio para se com pletar um item de forma que o processo deve ser continuamente otimizado para tornar esse tempo cada vez menor e mais previs vel 1 8 QUAL O MELHOR M TODO Kniberg define ferramenta como qualquer coisa que possa ser usada para atingir uma tarefa ou objetivo e processo como a forma que se trabalha 34 Para ele m todos como Scrum XP e Kanban s o ferramentas para processos e questionar qual o melhor deles o mesmo que comparar se um garfo melhor do que uma faca ou seja isso depende do contexto e do objetivo em quest o Nenhum m todo completo e nenhum perfeito por isso sinta se livre para combinar as ferramentas e aproveitar o que funcionar m
89. e relacionados a uma regra artefato ou ferramenta de um ou outro m todo gil Um verdadeiro livro sobre Agile deveria manter o foco de seus cap tulos na en trega de valor ao neg cio na otimiza o deste valor e na constru o de um novo ambiente de trabalho uma nova gest o Um verdadeiro livro de Agile tiraria os ho lofotes dos famosos m todos geis tais como Scrum XP e Kanban e os apresentaria apenas como um meio para se desenvolver da forma certa produtos que realmente agreguem valor a quem paga a conta nossos clientes Sendo assim n o exito em afirmar que este um verdadeiro livro de Agile o livro que voc deve ler caso queira construir um novo e melhor caminho para a sua carreira na rea de projetos de software Alexandre Magno Agile Expert e Fundador da Adapt Works vi Casa do C digo Sum rio Sum rio 1 Introdu o M todos geis 1 Rr ci PO RR O ORES Ww es 2 12 DI persas Hh bw eo Tea pa LES eGR E HS 4 13 Compreendendo os Valores Ageis 2 2 ee ee eee 8 1 4 Benef cios dos M todos geis Soha ao ae See eee aie 9 1 5 Agregando Mais Valor com Scrum 2 66 cs ee ve eee Re suas 12 1 6 Excel ncia T cnica com XP aoaaa ee 14 1 7 Fluxo Cont nuo com Kanban 00000 eee eee 16 1 8 Qual o Melhor M todo 0 0 0 00 eee eee 18 to Eagora o quesa ago amanh ssc escra pe baw een eae as 19 2 Flu ncia gil 21 21 Evolu o e Maturidade de uma Equipe gil 23 22 O
90. e utilizam m to dos geis muito superior se comparado s t cnicas mais tradicionais de gest o de projetos e engenharia de software E quando eu falo em melhor resultado n o es tou falando apenas de uma maior entrega de valor t pico brilhantemente abordado neste livro mas falo tamb m de aspectos que v o desde a gera o de produtos com qualidade t cnica constru o de um melhor ambiente de trabalho Estou certo de que em poucos anos nos lembraremos de Agile como um marco na nossa profiss o um marco para a rea de tecnologia Mas afinal de contas o que Agile uma metodologia Um processo Um conjunto de valores Um manifesto Ferramentas Pr ticas Um movimento Bem por incr vel que pare a esta uma pergunta dif cil de ser respondida Uma das raz es porque Agile pode n o ser nada do que citei e ao mesmo tempo pode Vv Casa do C digo compreender tudo aquilo muito dif cil explicar Agile sem mostrar a pr tica De fato frequentemente cito que a forma correta de explicar o que Agile deveria ser Ei venha aqui ver como estou fazendo E neste ponto que destaco o valor de cada uma das p ginas deste livro elas mostram o Agile do mundo real infestado de pragmatismo e de preciosas anota es de quem valoriza sim uma boa teoria m o n o antes de pratica la de v la realmente funcionando Um livro de verdade sobre Agile n o poderia ter cap tulos cujos t tulos fossem purament
91. edida que os encontros acontecem S o comum por exemplo reuni es semanais em que antes de cada reuni o l se um dos cap tulos para discuss o Numa organiza o em transi o para m todos geis por exemplo pode ser uma excelente ideia formar um clube do livro e escolher um livro sobre m todos geis para envolver toda a equipe no aprendizado que sem d vida ser muito til na tran si o Brown Bag Sessions Brown Bag Sessions s o reuni es durante a pausa para o almo o em que as pessoas fazem apresenta es e compartilham informa es Nos Estados Unidos comum que as pessoas levem seus lanches para o almo o em sacos de papel pardos brown bags como aqueles que as padarias costumam utilizar para p es aqui no Brasil da o nome Brown Bag Sessions Durante essas reuni es geralmente as pessoas comem enquanto assistem a uma apresenta o preparada por um dos membros do time uma forma f cil e r pida de se criar uma oportunidade para aprendizado uma vez que um hor rio que na maioria das vezes mais pessoas poder o participar do que antes ou depois do hor rio de trabalho Se voc gostaria que sua organiza o investisse em um tempo durante o hor rio de trabalho para esse tipo de atividade de aprendizado Brown Bag Sessions podem ser uma tima forma de se come ar porque n o afeta o tempo de trabalho da equipe Ao passo que as pessoas participam das reuni es e os resultados se mostra
92. ega o 12 veja na figura 6 2 122 Casa do C digo Cap tulo 6 Otimizando o Sistema Contratar Tot Definir Sal rios LO Priorizar Projetos Comprar Licen as Mary Formar Equipes Te Definir Tecnologia Te Figura 6 2 Quadro da Delega o No topo do quadro temos os 7 niveis de empoderamento e nas linhas temos as areas de delega o chave essas reas v o variar de acordo com o contexto esse apenas um exemplo Nas colunas nos temos a defini o de quem respons vel representado por uma pessoa um papel ou uma equipe Por exemplo no quadro da figura 6 2 sal rio est no n vel 2 e na responsabili dade de uma pessoa chamada Bill Isso quer dizer que Bill define os sal rios mas tenta vender para o time suas decis es sobre sal rios J o item comprar licen as est na responsabilidade da Mary no n vel 3 isso significa que apesar de ela ser respons vel por tomar essa decis o ela precisar pedir a opini o do time antes de decidir J o item definir tecnologia est na responsabilidade do time no n vel 7 o que significa que o time tem total autonomia para decidir sobre tecnologia e que n o h necessidade de consultar a gest o antes de decidir O quadro de autoridade uma tima forma para tornar transparente quem pode fazer o qu Identifique quais s o as reas de decis o chave na sua organiza o e procure definir os n veis de delega o de cada um Uma vez vis vel e transparente
93. eixado de lado nas discuss es sobre m todos geis que o manifesto gil n o foi uma rea o apenas aos m todos tradi cionais e burocr ticos mas tamb m foi uma rea o aos m todos ca ticos que resul Casa do C digo Cap tulo 1 Introdu o M todos geis tavam em produtos de baixa qualidade Os m todos geis representam justamente um meio termo entre m todos estruturados demais e m todos sem estrutura s o o meio termo entre a ordem e o caos 8 Com intuito de promover os m todos geis foi institu da a Alian a gil Agile Alliance que apoiou e realizou uma s rie de eventos e confer ncias ao redor do mundo Com o tempo mais e mais empresas e pessoas foram adotando m todos geis e atualmente milh es de pessoas consideram se praticantes desses m todos M todos Prescritivos e Adaptativos M todos geis s o adaptativos ao inv s de prescritivos por isso incentivam a melhoria cont nua implicando em um constante estado de mudan as e transfor ma o visando alcan ar um estado melhor atrav s de ciclos inspe o e adapta o Esse o motivo pelo qual m todos geis utilizam processos emp ricos em vez de prescritivos 36 Enquanto processos emp ricos s o apropriados para dom nios inst veis e com alto n vel de mudan as processos prescritivos s o indicados para atividades orde nadas que podem ser alcan as atrav s de uma sequ ncia de passos Prescritivo DO Oo RUP XP
94. ejamento iterativo e as releases frequentes permitem que as prioridades do projeto sejam reajustadas constantemente M todos geis possibilitam que as incertezas do projeto no n vel dos requi sitos ou no n vel t cnico sejam estimadas e distribu das de forma inteligente nos releases para manter o risco sempre balanceado Al m disso as entregas em prazos curtos oferecem maior visibilidade da velocidade do time ofere cendo maior previsibilidade do prazo necess rio para concluir o projeto e Redu o de Custos Equipes geis s o menos propensas a desenvolver fun cionalidades de baixa prioridade ou que se tornaram desnecess rias ao longo do tempo 20 Abordagens n o geis geralmente tendem a cair nesse pro blema devido ao grande espa o de tempo entre o levantamento dos requisitos e entrega do produto 11 1 5 Agregando Mais Valor com Scrum Casa do C digo 1 5 AGREGANDO MAIS VALOR COM SCRUM Reuni es 5 Cy 7 Sprint Te 2 n o OW p Product Sprint Produto Backlog Backlog Pontecilamente Entregr vel Figura 1 3 Scrum Scrum um dos m todos geis mais populares na atualidade e tem foco maior nos aspectos gerenciais do desenvolvimento de software Nele cada itera o chamada de sprint Geralmente cada sprint tem um per odo de m s que pode variar de poucos dias a algumas semanas As pessoas envolvidas no processo de desenvolvimento s o dividas no Scrum em tr s pap is pr
95. elhor para seu contexto ou seja considerando a cultura da sua organiza o as habilidades da sua equipe e as restri es de seu projeto comum por exemplo que se adote pr ticas de engenha ria de XP como programa o em par e integra o cont nua em times que utilizam Scrum Todo projeto de desenvolvimento de software diferente possui pessoas com habilidades diferentes n veis de experi ncia diferentes or amento prazo escopo e riscos diferentes Os valores da organiza o e suas metas tamb m s o espec ficos e com toda essa varia o sem d vida as restri es tamb m ser o diferentes Por tanto voc deve procurar compreend las de forma a explor las da melhor maneira poss vel visando atingir bons resultados Assim como as pr ticas os pap is em uma equipe gil podem variar de acordo com o m todo utilizado e contexto da equipe Fique atento para utilizar apenas pa p is que de fato agreguem valor e para n o incluir pap is conflitantes Cada novo m todo que voc estuda e conhece mais uma ferramenta para sua caixa de ferramentas a pergunta certa n o qual o melhor m todo mas qual o m todo mais adequado para esse contexto e ent o munido de sua caixa de ferra mentas voc ter condi es de escolher a melhor abordagem para cada desafio 18 Casa do C digo Cap tulo 1 Introdu o M todos Ageis 1 9 E AGORA O QUE EU FA O AMANH Revise os quatro valores
96. em estimados pela equipe o PO ter mais facilidade em priorizar o backlog e ter melhor previsibilidade do projeto 3 E Emergente O Product Backlog um artefato vivo isto deve mu dar frequentemente de acordo com as mudan as de neg cio Novos itens s o inclu dos itens antigos s o removidos ou modificados 4 P Priorizado Os itens do backlog devem estar priorizados do maior valor de neg cio para o menor valor de neg cio para que os itens mais importantes sejam detalhados e implementados antes dos menos im portantes Al m disso em abordagens tradicionais era muito comum que os requisitos fos sem transmitidos ao desenvolver apenas por escrito atrav s de um documento Em contrapartida a ess ncia da comunica o nos m todos geis a comunica o face a face De acordo com Alistair Cockburn a comunica o atrav s de papel fria e pobre porque n o h oportunidade para perguntas e respostas a comunica o entre pes soas face a face quente e muito mais rica porque oferece a oportunidade de itera o entre as partes 17 claro que isso n o torna de forma alguma a comunica o escrita irrelevante pelo contr rio ela tamb m importante mas n o suficiente e nem mais eficiente em todos os cen rios por isso que muitos m todos geis defendem a ideia de uma reuni o de pla nejamento em que a equipe e o Product Owner participem juntos e que atrav s de 37 3 3 Planej
97. ente 5 Depois deste evento Benioff tomou uma s rie de provid ncias para garantir que todos estivessem na mesma p gina e depois de algum tempo investindo em disseminar essa vis o al m de todos ganharem mais assertividade e conhecimento do que estavam fazendo todos os membros da equipe de tornaram potenciais marqueteiros e vendedo res do produto Quando o projeto possui uma vis o nica e coesa a tomada de decis o se torna muito mais f cil e todos os membros da equipe de posse da vis o podem partici par mais ativamente oferecer sugest es e realizar um trabalho mais produtivo e de melhor qualidade 34 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio O Discurso do Elevador Imagine que voc entrou no elevador e encontra ningu m menos do que aquele investidor que voc sempre sonhou que pudesse se interessar em seu produto Voc tem poucos segundos at que o elevador o deixe em seu andar e precisa aproveitar a oportunidade para falar sobre o que voc e sua equipe est o fazendo O que voc dir a ele A ideia por detr s do discurso do elevador encontrar uma forma de transmitir a ess ncia de uma ideia em um espa o muito curto de tempo 49 Fazer esse exerc cio o ajudar a trazer mais clareza e objetidade para sua vis o e ser til para pensar no produto sobre o ponto de vista do cliente e de que forma o produto agregar valor a ele A Harvard Business School criou um
98. euni es acontecem a reuni o de revis o e a reu ni o de retrospectiva Na reuni o de revis o a equipe apresenta ao Product Owner o trabalho que foi desenvolvido durante o sprint para que ele possa oferecer feedback e aprovar ou n o tudo o que foi produzido Na reuni o de retrospectiva os principais acontecimentos do sprint s o apresentados e discute se sobre as li es aprendidas e melhorias que podem ser aplicadas ao processo 1 6 EXCEL NCIA T CNICA COM XP O m todo gil Extreme Programming em portugu s Programa o Extrema mais conhecida simplesmente como XP foi criado e inicialmente divulgado por Kent Beck nos anos 90 e um dos m todos geis que melhor cobre aspectos t cnicos do de senvolvimento de software como codifica o design e testes veremos mais detalhes a seguir Segundo o XP durante o processo de desenvolvimento h quatro atividades b sicas a serem executadas Ouvir Desenhar Codificar e Testar preciso ouvir porque desenvolvedores nem sempre possuem o conhecimento 14 Casa do C digo Cap tulo 1 Introdu o M todos geis de neg cio necess rio para se construir o software O Planning Game uma reu ni o que acontece uma vez a cada itera o em que o principal objetivo decidir quais funcionalidades ser o desenvolvidas na itera o e aprender mais sobre elas O cliente escreve hist rias de usu rio em cart es que representam a necessidade de funcionalidade a ser desenv
99. eus colegas 134 Casa do C digo Cap tulo 6 Otimizando o Sistema e para acompanh los criar o h bito de manter se sempre atualizado Agora pense num cen rio diferente em que ao chegar em seu primeiro dia de trabalho voc percebe que as pessoas s o bem acomodadas que a tecnologia que a empresa est atualmente utilizando j est ultrapassada h muito tempo e que nin gu m parece se importar em estudar ou buscar novas abordagens Voc ter a mesma motiva o de estudar ao chegar em casa Provavelmente n o O que ocorre que n s temos uma grande tend ncia de nos conformarmos ao ambiente em que estamos inseridos por isso que um ambiente que facilita e promove o aprendizado muito impor tante para fomentar equipes tecnicamente excelentes A seguir voc ser apresentado a algumas pr ticas para ajud lo a criar um ambiente que facilita a aprendizagem Comprometa se com sua carreira Muitos de n s acredita que ao terminar a faculdade est formado mas na ver dade especialmente em uma rea t o vol til quanto a rea de tecnologia da infor ma o essa forma o deve durar a vida inteira para que voc continue sendo um profissional eficiente e relevante para o mercado de trabalho Quando est na faculdade voc dedica em m dia 4 horas do seu dia para sua forma o para estudar Depois que acaba a faculdade muitos infelizmente passam a dedicar zero horas importante que voc tenha um comprom
100. exto completo de uma hist ria de usu rio ou caso de uso Os testes de aceita o s o baseados em crit rios de acei ta o relacionados com regras de neg cio que podem ser especificadas pelo Product Owner poss vel realizar testes de aceita o manualmente ou automatiz los A reali za o de testes manuais pode reduzir drasticamente a velocidade do time por isso recomenda se a automa o dos testes Algumas ferramentas como o Selenium por exemplo permitem realizar a au toma o de testes de aceita o em aplica es web gravando a es do usu rio no navegador para que o cen rio possa ser reproduzido e os resultados verificados pos teriormente V al m de testes explorat rios Testes Manuais s o testes realizados por pessoas geralmente que t m o papel de testadores em um time de desenvolvimento de software Alguns testes manuais consistem basicamente na execu o de um script escrito de antem o que possui uma sequ ncia de passos a serem seguidos e um resultado a ser validado Esse tipo de teste pode ser facilmente automatizados 72 Casa do C digo Cap tulo 4 Entregando Valor H por m um segundo tipo de teste que realizado manualmente conhecido como testes explorat rios Eles se aproveitam de todos o potencial do testador para investigar e descobrir cen rios e possivelmente defeitos ou efeitos colaterais que n o haviam sido previstos anteriormente Para este tipo de testes n o h um
101. geis voc acredita que sua organiza o reflete esse valores Se n o o que poderia ser feito diferente para que isso melhorasse Reflita sobre seu projeto atual Voc e seus colegas est o de fato trabalhando colaborativamente em equipe Est o entregando software em funcionamento com numa frequ ncia adequada Como voc s lidam com as mudan as de prioridade de neg cio do cliente Quais s o os benef cios que voc espera alcan ar com a utiliza o de m todos geis em suas equipe O que m todos geis podem trazer de positivo para seu cliente Como podem beneficiar sua equipe Verifique cada um dos bene f cios listados neste cap tulo e pense se est o em alinhamento com o que voc espera melhorar em sua organiza o Pense nos diferentes pap is e pr ticas de sua equipe Todos eles de fato est o agregando valor ao projeto 19 CAP TULO 2 Flu ncia gil Em um experimento cient fico 58 um grupo de cientistas colocou cinco macacos numa jaula No meio da jaula havia uma escada e sobre ela um cacho de bananas Quando um macaco subia na escada para pegar as bananas os cientistas jogavam um jato de gua fria nos outros macacos que estavam no ch o Depois de certo tempo quando um macaco tentava subir na escada os outros batiam nele com medo de tomar outro jato Depois de algum tempo nenhum macaco subia mais a escada apesar da tenta o das bananas Os cientistas ent o trocaram um dos macacos por outro novo
102. go por m s o capazes de fazer coisas em outras reas de conhecimento representado pela amplitude da cabe a da letra T veja um exemplo na figura 6 4 3 g S 5 s So E a 5 D gt wg S 8 e g T g q ar E Desenvolvimento Web Pesign Figura 6 4 Profissional T Equipes cross funcionais nem sempre s o feature teams em vez disso podem ser component teams A diferen a desses tipos de equipe que em vez de construir o software de ponta a ponta e entreg lo pronto para que o cliente final possa utilizar essas equipes component teams constroem partes da aplica o ou componentes que geralmente s o entregues para que outra equipe possa utilizar e enfim agregar a funcionalidade que precisa para ser entregue ao cliente Por exemplo o time A pode estar trabalhando em um componente visual de front end enquanto o time B est preparando o backend da aplica o Em bora seja recomend vel trabalhar com feature teams Mike Cohn alerta que em certas situa es e contextos pode ser interessante se utilizar de component teams Equipes geis s o capazes de entregar software funcionando a cada itera o por que s o formadas de especialistas generalistas capazes de juntos construir funciona 132 Casa do C digo Cap tulo 6 Otimizando o Sistema lidades de ponta a ponta Outra diferen a not vel o tamanho das equipes em processos tradicionais era comum encontrar equipes funcionais com mais de
103. go do tempo importante que todos os membros da equipe participem do processo de esti mar Quando um desenvolver estima uma hist ria sozinho ele o faz com base em suas experi ncias pessoais Quando a estimativa realizada em equipe o expertise envolvido muito maior e as chances de obter um resultado mais adequado tamb m Uma das medidas mais comuns de estimativa s o horas A equipe indica quan tas horas ser o consumidas para que uma funcionalidade seja implementada No desenvolvimento gil mais comum utilizar pontos para realizar estimativas Pontos podem ter significados diferentes de acordo com cada equipe ou projeto Uma das formas como recomendado no m todo XP quantificar um ponto como sendo um dia ideal de trabalho ou seja um dia totalmente dedicado a realizar uma tarefa sem interrup es Dessa forma dois pontos seriam dois dias e assim por diante Outra forma recomendada pelo m todo Scrum utilizar pontos relacionados ao esfor o em vez de tempo Dessa forma toma se uma funcionalidade simples como refer ncia por exemplo o desenvolvimento de uma tela de cadastro e assume se que essa refer ncia vale dois pontos Ao estimar outra tarefa avalia se em quantas vezes mais f cil ou mais dif cil em rela o refer ncia a hist ria atual Outra t cnica para tentar absorver a incerteza e falta de precis o das estimativas a utiliza o de intervalos como a sequ ncia de Fibonacci o 1 2 3
104. guardando para serem validadas por uma equipe de qualidade ou aguar dando para passar por um processo de integra o Tudo isso trabalho parcialmente pronto e consequentemente desperd cio Desperd cio com funcionalidades que n o agregam valor A maior fonte de desperd cio pode ser vista claramente no Chaos Report 3 somente 20 das funcionalidades desenvolvidas em software s o efetivamente utili zadas regularmente os outros 80 s o provavelmente funcionalidades superficiais respons veis pela maior parte do custo de se desenvolver o software em outras pa lavras desperd cio Al m disso ainda aumentam significativamente a complexidade da base do c digo e o custo para mant lo O custo da complexidade exponencial n o linear Quando a base de c digo muito complexa a confian a de realizar altera es de forma segura pequena Consequentemente equipes inteligentes mant m seu c digo fonte simples claro e reduzido Por m para que isso aconte a toda nova funcionalidade deve ter uma boa justificativa do ponto de vista do neg cio de forma que seja algo que realmente agregue valor Poppendieck alerta que software complexo por natureza e por isso n o gerenciar sua complexidade cuidadosamente uma receita para o fracasso Desperd cio com documenta o Produzir documentos que ningu m l desperd cio Documentar uma ativi dade que consome o tempo das pessoas e aumenta o tempo de desenvolvimento
105. ha as Op es Abertas Casa do C digo outro de trabalhar em uma funcionalidade em vez de em outra Cada uma dessas escolhas tem um retorno sobre o investimento O desafio trabalhar com a op o que tiver o melhor retorno sobre o investimento A diferen a principal entre compromissos e op es que podemos mudar de escolha de op es sem custo algum ou com um baixo custo mas mudar um com promisso geralmente gera custos ou problemas caso ele n o seja cumprido Temos o custo da op o e o retorno sobre o investimento que cada uma oferecer O mais interessante que h valor nas op es que conhecemos e naquelas que n o conhecemos tamb m Por isso sempre importante considerar todas as op es poss veis e procurar aprender sobre op es at ent o desconhecidas antes de se com prometer com uma determinada op o Decidir no ltimo momento poss vel n o confundir com negligenciar um dos princ pios de Lean Software Development e tamb m algo que faz parte de uma s rie de pr ticas utilizadas em equipes geis como Refactoring e Design Emergente o design n o definido de antem o mas vai evoluindo ao longo do desenvolvimento Planejamento Iterativo a equipe se compromete apenas com as hist rias de usu rio de um itera o e o resto do backlog torna se uma op o para o Product Owner essas hist rias podem ou n o se tornar uma obriga o se inclu das no planejamento da pr xima itera o Incremento
106. hecem o problema que o software deve resolver A vis o revela para onde o pro jeto est indo e por que ele est indo para l Todo projeto possui um ou mais vision rios algu m que conseguiu enxergar uma necessidade e teve uma ideia de solu o para suprir essa necessidade Ainda que um projeto possua muitos vision rios necess rio que algu m tome a responsa bilidade de promover e comunicar essa vis o equipe de desenvolvimento e a todos os outros interessados no projeto Esse papel geralmente de responsabilidade do gerente de projetos do pr prio cliente ou de algu m que represente o cliente No m todo Scrum por exemplo a vis o do projeto responsabilidade do Product Owner muito importante que o vision rio esteja bem pr ximo equipe de desenvol vimento para esclarecer as frequentes d vidas que surgem ao longo do projeto Por isso um dos princ pios do m todo XP ter o Cliente Presente Uma vez que todos forem contagiados com a vis o do projeto as chances de sucesso se tornam muito maiores H tr s perguntas essenciais que o vision rio precisa comunicar equipe 1 Que objetivo o projeto deve atingir 2 Por que esse projeto agregar valor 3 Como medir se o projeto foi bem sucedido Para que a equipe possa desenvolver um software alinhado com a vis o do pro jeto necess rio que a vis o esteja sempre acess vel para todos por isso a import n cia do vision rio estar presente na equipe
107. ias realizadas por meio das a es que foram definidas e efetivamente realizadas As 5 etapas das retrospectivas Diana e Derby prop em cinco passos b sicos para a realiza o eficiente de uma reuni o de retrospectiva gil 22 Esses passos ajudar o o facilitador a guiar a reu ni o e levar os membros da equipe a trazer tona poss veis itens a serem melhorados e ideias para alcan ar as melhorias 1 Prepara o 2 Apresenta o dos Dados 3 Insights 4 Decidir o que fazer 5 Fechamento 105 5 4 Melhoria Cont nua com Retrospectivas Casa do C digo Abrindo a Retrospectiva Antes de tudo importante preparar as pessoas para reuni o para que foquem no trabalho que deve ser realizado ao longo da retrospectiva Crie a atmosfera ideal para que as pessoas sintam se confort veis em discutir t picos complexos e estabelecer di logos desafiadores Defina uma meta para a retrospectiva Uma meta bem clara oferece s pessoas um senso de raz o pela qual est o investindo seu tempo Procure escolher uma meta abrangente para que a equipe fique livre para utilizar sua criatividade e alcan ar in sights Considere o contexto da equipe e descubra metas que a ajudar o certo que toda equipe tem suas particularidades diferentes pontos fortes e fracos No mo mento de elaborar a meta da retrospectiva procure algo que represente a busca das melhorias que podem trazer maior beneficio para sua equipe em particular Apresen
108. ica vez e em sequ ncia ainda que idealmente prevendo se revis es incrementais de cada etapa se necess rio Scrum Extreme Programming XP Crystal Clear e Feature Driven Develop ment s o exemplos de m todos geis Cada um deles traz uma abordagem diferente que inclui diversos valores pr ticas e reuni es O Scrum por exemplo traz uma Casa do C digo Cap tulo 1 Introdu o M todos geis abordagem mais voltada para a gest o com maior foco nas reuni es no planeja mento e na melhoria cont nua J o XP trazem maior enfoque nas pr ticas t cnicas Ao decorrer do livro estudaremos melhor esses m todos e exploraremos algumas pr ticas geis A Cascata dos M todos Tradicionais cc o o mais forte que sobrevive nem o mais inteligente mas o que melhor se adapta s mudan as Charles Darwin Em contra partida os processos tradicionais ou em cascata figura 1 1 que eram amplamente utilizados do mercado antes dos m todos geis assumem que o desen volvimento de software pode ser realizado atrav s de uma sequ ncia de atividades facilmente identificadas previs veis e repet veis mas diferente de outras engenha rias desenvolvimento de software requer criatividade e geralmente envolve um alto n vel de riscos e incertezas 38 O processo cascata costuma ser realizado atrav s de fases de an lise de requisitos projeto design implementa o testes integra o e manuten o de forma q
109. igura 6 3 ilustra a diferen a na forma o de equipes funcionais e cross funcionais 130 Casa do C digo Cap tulo 6 Otimizando o Sistema Time A Time B Time Time D uv m 2 E Lu w E co um O 5 e Time B KA A o Time C i Us Ef E Time D Desenvolvedores Testadores Designers Analistas Figura 6 3 Equipes Funcionais e Cross Funcionais Nas equipes cross funcionais todos s o respons veis pelo resultado da entrega e n o apenas por sua rea de especializa o Al m disso comum que os especia listas ensinem os outros um pouco sobre sua rea de conhecimento de modo que com o tempo todos podem ajudar no que mais for necess rio alavancando assim a produtividade do time 56 Isso n o significa que todos t m que saber fazer todo o trabalho e que t m que fazer todo o trabalho muito bem Na verdade equipes geis incentivam a forma o de especialistas generalistas s o pessoas que fazem um tipo de trabalho extrema mente bem desenvolver por exemplo por m tamb m s o capazes de fazer outros tipo de trabalho documentar ou testar por exemplo Equipes formadas com profissionais assim tendem a eliminar desperd cios e gargalos na organiza o 8 Esses profissionais sao conhecidos como Profissionais T porque sao especiali zados em alguma rea de conhecimento representada pela pela perna da letra T 131 6 4 Forma o das Equipes Casa do C di
110. imula o aprendizado colabora o divers o e prop cio para se tentar aplicar novas ideias e boas pr ticas de programa o como De senvolvimento Guiado por Testes TDD Refatora o e Programa o em par por exemplo Al m disso desenvolvedores aprendem muito ao ver as diferentes pers pectivas e abordagens de outros desenvolvedores Tudo que preciso para realizar um coding dojo um computador um teclado um projetor um desafio de programa o para ser resolvido e desenvolvedores inte ressados em participar 136 Casa do C digo Cap tulo 6 Otimizando o Sistema Existem diferentes formatos de Coding Dojos o Randori Kata e o Prepared Kata No formato Randori os programadores trabalham juntos na solu o do desafio de programa o 14 seguindo o seguinte processo 1 Escolher um desafio de programa o Dica uma simples busca no Google por source of problems for coding dojos trar algumas ideias interessantes como transformar n meros romanos em ar bicos escrever n meros por extenso etc 2 Um par de desenvolvedores vai at o computador e trabalhar em par no problema a cada X minutos geralmente 7 minutos o navegador assume o papel de con dutor dando lugar para que a algu m da audi ncia assuma o papel de navegador e o condutor anterior volta a plateia o novo par d continuidade de onde o par anterior estava O processo se repete de X em X minutos at o final do time box Os desenvolved
111. incipais o Scrum Master o Product Owner dono do produto e a equipe O Product Owner o maior interessado no software aquele que teve ou que representa quem teve a necessidade do produto e por isso tem a vis o do produto Define o que deve ser feito e prioriza as funcionalidades a serem desenvolvidas mantendo as em um artefato chamado de product backlog que nada mais do que uma lista de todas as funcionalidades que devem ser implementadas ordenadas por prioridade tamb m responsabilidade do Product Owner passar toda a informa o de ne g cio que for necess ria para que a equipe possa transformar suas ideias em software A Equipe composta por um n mero que varia de cinco a nove pessoas e cross funcional isto h pessoas dos mais variados perfis como testadores desenvolve 12 Casa do C digo Cap tulo 1 Introdu o M todos Ageis dores designers analistas de neg cio etc integrando a equipe O principal objetivo dela implementar as funcionalidades que foram selecionadas para serem desenvol vidas na itera o e entreg las em funcionamento ao final desse per odo No cap tulo 6 abordaremos mais a fundo as vantagens de se trabalhar com equipes pequenas O Scrum Master tamb m chamado de facilitador respons vel por manter o processo em funcionamento assegurando que todas as regras est o sendo aplica das e remover os impedimentos da equipe isto resolver qualquer problema que p
112. ionalidades gt gt Hist rias Figura 3 4 Hierarquia de Requisitos picos s o requisitos grandes que geralmente n o podem ser implementados em uma nica itera o e normalmente contemplam diversos eventos fluxos e ce n rios Por quest es de organiza o e prioriza o muita vezes interessante manter 49 3 6 Escrevendo Hist rias de Usu rio Casa do C digo esses itens no backlog sem detalhar exatamente o que dever ser feito e ent o so mente quando a prioridade do pico for aumentando e a hora de traz lo para o planejamento estiver se aproximando ser o momento certo para dividi lo em his t rias de usu rio Para melhor ilustrar imagine um sistema de gest o empresarial O sistema pode ter temas como Comercial Financeiro e Cont bil por exemplo O tema Financeiro pode ser derivado em picos como Cobran as e Pagamentos j o pico Pagamentos pode ser derivado em funcionalidades como Pagamento por Boletos e Pagamentos por Dep sitos A Funcionalidade Pagamento por Boleto poderia ser derivada em diversas his t rias como por exemplo Pagamento de Boletos Vencidos Pagamento de Boletos com Juros etc Dividindo Hist rias comum que algumas hist rias de usu rios sejam grandes demais para serem implementas em uma nica itera o Nesses casos interessante dividi las em v rias hist rias menores importante por m manter o aspecto INVEST Voc pode dividir h
113. is cutiremos em detalhes mais frente todo o c digo fonte que ser executado em produ o desenvolvido em pares a integra o do c digo fonte realizada fre quentemente atrav s da pr tica de integra o cont nua e o c digo fonte coletivo ou seja pertence a todos os membros da equipe e deve ser escrito de acordo com os padr es definidos pelo pr prio time Testar uma atividade de extrema import ncia para garantir a qualidade do soft ware e n o algo opcional com XP ao contr rio todo c digo deve possuir testes de unidade e todos os testes devem ser executados com sucesso antes que uma entrega seja feita Quando um defeito encontrado cria se um teste de unidade para asse gurar que esse mesmo defeito jamais volte a acontecer No XP os testes s o escritos antes do c digo de produ o atrav s de TDD Test Driven Development ou Desen volvimento Guiado por Testes 15 1 7 Fluxo Cont nuo com Kanban Casa do C digo Devido ao foco t cnico de XP e ao foco mais gerencial do Scrum muitas empre sas os combinam para obter um processo mais completo visando um processo mais eficiente Estudaremos mais a frente cada uma das pr ticas citadas 1 7 FLUXO CONT NUO COM KANBAN Figura 1 4 Kanban Kanban um m todo gil que diferentemente da maioria dos m todos geis n o possui itera es Ao inv s disso desacopla o planejamento prioriza o desenvol vimento e entrega de forma que cad
114. isso considera se que o cliente tamb m aprende ao longo do projeto e suas mudan as trar o benef cio claro que deve haver algum tipo de prote o para que as mudan as com frequ ncia exagerada n o tornem o projeto invi vel Tanto o XP como Scrum aconselham que ao menos a itera o atual n o seja modificada importante entender a diferen a e a rela o entre itera o e release Os releases representam entregas e as itera es representam ciclos que est o contidos dentro dos releases As itera es representam um determinado intervalo de tempo em que algumas hist rias ser o implementadas Nas itera es podem estar contidas diversas atividades como as reuni es de re vis o e retrospectivas discutidas poss vel por exemplo definir releases mensais com quatro itera es de uma semana cada N o existe regra quanto periodicidade dos releases afinal cada projeto tem suas particularidades e um release pode implicar em uma s rie de fatores como por exemplo implanta o e treinamento Por isso o n mero de releases e itera es estipulados devem estar alinhados s necessidades da sua organiza o Ao final do release o software entregue para o cliente pronto para produ o 3 11 ROADMAP DO PRODUTO O Roadmap uma ferramenta til para tra ar um plano de alto n vel sobre futuros releases e marcos importantes do produto que ser o alcan ados ao longo do tempo O Roadmap oferece visibilidade de que funcio
115. isso consigo mesmo de manter se em constante estado de aprendizagem e para isso voc precisar dedicar algumas horas na sua semana N o pode dedicar 4 horas como fazia na poca na faculdade N o tem problema Que voc dedique 20 minutos por dia ent o Mas fa a e ver que isso far grande diferen a na sua carreira O B sico Ingl s Nos tempos globalizados em que vivemos saber falar apenas sua l ngua nativa j n o mais suficiente Grande parte do material dispon vel para aprendizado est em ingl s e o tempo de tradu o para o portugu s muitas vezes longo demais Estude ingl s de forma a poder ler documenta o de projetos open source tutoriais artigos e assistir a palestras e apresenta es Leitura Crie o h bito de ler N o apenas livros mas tamb m blogs e portais de tecnologia como o InfoQ com por exemplo Fique ligado no que est mudando e nas novas tecnologias que est o surgindo a todo momento Esteja sempre lendo um livro Quando terminar de ler este livro n o espere 135 6 5 Pr ticas de Aprendizagem Casa do C digo Comece a ler um pr ximo e n o pare nunca Eu particularmente mantenho um Backlog de livros no GoodReads com h centenas de livros que quero ler e man tenho uma lista priorizada l sempre sei qual o pr ximo livro que come arei a ler assim que acabar o atual Cuidado por m para n o cair no h bito de comprar mais livros do que pode ler falo por experi ncia pr
116. ist rias por varia es nas regras de neg cio por varia es nos dados por diferentes cen rios de uso etc Quebrando Hist rias em Tarefas De um modo geral hist rias requerem certo esfor o para serem implementadas Por isso elas s o dividas em tarefas que representam os passos necess rios para que a funcionalidade da hist ria seja desenvolvida e entregue em funcionamento ao cli ente recomendado que as hist rias sejam quebradas em tarefas que n o precisem de mais de um dia de trabalho para serem desenvolvidas Posteriormente veremos como isso acontece e como as atividades t cnicas s o gerenciadas Apenas depois de ouvir o PO e compreender a hist ria a equipe a quebra em partes menores chamadas simplesmente de tarefas Neste momento a presen a do PO menos importante porque as tarefas t m um mbito mais t cnico e geralmente ter o descri es como criar as tabelas no banco de dados criar objetos de neg cio realizar integra o atrav s de web services etc N o preciso entrar em detalhes minuciosos sobre cada tarefa e neste mo mento pode se tomar algumas decis es de design que a equipe considerar importante como linguagens frameworks bibliotecas e padr es a serem 50 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio utilizados al m de quest es que envolvam performance e escalabilidade Decis es que a equipe considerar menos importantes podem ser tomadas mais tarde apenas no momento
117. ition Addison Wesley Professional 2010 Marc Benioff Carlye Adler Behind the Cloud the untold story of how sales force com went from idea to billion dollar company and revolutionized an in dustry Jossey Bass 2009 Chris Matts Gojko Adzic Feature injection three steps to success http www infoq com articles feature injection success 2011 Mauricio Aniche Test Driven Development Teste e Design no Mundo Real Casa do C digo Jurgen Appelo Management 3 0 Leading Agile Developers Developing Agile Leaders Addison Wesley Professional 2011 Jurgen Appelo Business guilds Management 3 0 workout http www management30 com workout business guilds 2012 Jurgen Appelo Como Mudar o Mundo Gest o de Mudan as 3 0 2012 Jurgen Appelo Exploration days Management 3 0 workout http www management30 com workout exploration days 2012 147 Refer ncias Bibliogr ficas Casa do C digo 12 Jurgen Appelo Delegation boards Management 3 0 workout http www management3o com workout delegation boards 2013 13 Kent Beck Extreme Programming Explained Embrace Change Second Edition Addison Wesley Professional 2004 14 Danilo Sato Hugo Corbucci Mariana Bravo Coding dojo an environment for learning and sharing agile practices 2008 15 Frederick P Brooks The Mythical Man Month Essays on Software Engineering Addison Wesley Professional 1995 16 Larry Burns Building the Agile Database
118. ivas com cartas backlogs etc Diana Larsey e James Shore 57 afirmaram que muitos l deres de organiza es ainda se queixam de que n o est o conseguindo alcan ar os benef cios que esperam com a ado o de m todos geis e por isso desenvolveram um modelo de flu ncia gil para ajudar as organiza es a alcan arem esses benef cios com mais efici ncia Para Larsey e Shore a flu ncia gil diz respeito maneira com que a equipe res ponde quando est sob press o Qualquer um pode seguir um conjunto de pr ticas quando h tempo para focar em uma sala de aula mas a verdadeira flu ncia requer habilidade e pr tica frequente que persiste mesmo quando sua mente est distra da com outras coisas uma quest o de h bitos Essa flu ncia gil est relacionada n o apenas com a capacita o dos membros da equipe mas tamb m com as estruturas de gest o com os relacionamentos a cultura organizacional e pr ticas da equipe Para conquistar a flu ncia gil uma equipe dever passar por 4 est gios distintos 1 Foco no Valor Atuar na Cultura na Equipe 2 Entrega de Valor Atuar nas Habilidades da Equipe 3 Otimiza o de Valor Atuar na Estrutura Organizacional 4 Otimiza o Sist mica Atuar na Cultural Organizacional Ao longo deste livro n s exploraremos o que voc pode fazer para ajudar sua equipe e sua organiza o a trilhar esse caminho que os levar a um melhor apro veitamento dos benef
119. jetivo voc deve ter ao menos um indicador indutor e um de resultado J os Indicadores de Resultado lagging indicators ajudam a confirmar que um evento pode ocorrer e reagem mais lentamente s mudan as no ambiente do que 98 Casa do C digo Cap tulo 5 Otimizando Valor os indicadores indutores S o m tricas que verificam que voc atingiu seu objetivo depois de ter completado o trabalho Por exemplo reduzir o n mero de defeitos reportados por clientes aponta que a qualidade do produto de fato melhorou ME A TIMES E N O INDIV DUOS Quando as pessoas acreditam que ser o afetadas pelos resultados de m tricas sobre seus trabalhos individuais elas rapidamente encontram formas de corromper tais m tricas 38 al m disso medir indiv duos pode destruir a colabora o do time uma vez que ajudar um outro mem bro do time pode significar melhorar a m trica de desempenho dele e prejudicar a sua pr pria J quando mede se o time em vez do indiv duo j que a colabora o tende a melhorar a performance do time como um todo a colabora o entre as pessoas ser mais incentivada Esses s o alguns dos indicadores mais comum em ambientes geis e Velocidade do Time Quantidade de pontos de hist ria que um time consegue entregar em uma determinada itera o e Acelera o Altera o da velocidade do time ao longo das itera es Lead time O tempo entre o pedido do cliente e a entrega o in cio e
120. l caves Prodo M dio horas portos Figura 4 3 Lista de Casos de Teste Uma vez tendo a lista pronta e classificada poss vel priorizar e come ar pe los testes cuja falta apresenta maior risco e que possuem maior custo de realiza o manual e menor custo de automa o Quando n o se tem testes automatizados a nica forma de garantir que uma al tera o n o quebrou uma funcionalidade preexistente realizando testes manuais N o incomum que o custo de realizar os testes manualmente seja maior do que o custo de automatizar por isso pode ser interessante estimar e apresentar aos inte ressados no projeto para que possam entender o custo benef cio do investimento na automa o deles Nem sempre temos a oportunidade de trabalhar em novos projetos em que po demos garantir alta cobertura de teste desde o princ pio mas isso n o motivo para desanimar pouco a pouco itera o a itera o poss vel mudar a realidade do pro jeto e melhorar a qualidade aumentando a cobertura de testes 4 2 SIMPLIFICANDO O C DIGO COM REFATORA O Complicar f cil Dif cil simplificar Max Gehringer natural que ao longo do tempo a base de c digo de um sistema v se tornando 74 Casa do C digo Cap tulo 4 Entregando Valor cada vez maior assim como o n mero de funcionalidades dispon veis e a complexi dade do c digo fonte Sem boas pr ticas para manter o c digo limpo e organizado medida q
121. lavra debt quer dizer d vida um valor que n o foi pago e dever ser pago futuramente j a palavra debit significa d bito um valor que foi retirado de uma conta banc ria por exemplo Depois da defini o de Cunningham no in cio dos anos 90 a comunidade con tinuou a evoluir o conceito 53 e atualmente diversos atalhos tais como design ultrapassado defeitos conhecidos que n o foram resolvidos baixa cobertura de tes tes de unidade excesso de testes manuais entre outros tamb m s o considerados parte da d vida t cnica Se ela for ignorada em algum momento o c digo pode se tornar t o confuso e ca tico que sua manuten o ser prejudicada aumentando o custo de desenvolvi mento e suporte diminuindo a produtividade do time aumentando o n mero de defeitos devido alta complexidade e dificuldade de compreens o do c digo e fi nalmente diminuindo a motiva o da equipe devido baixa produtividade e alto n mero de defeitos previs vel que em num cen rio como esse os clientes e usu rios provavelmente tamb m n o estar o muitos contentes O valor da met fora da d vida t cnica est em tornar o time consciente desses problemas e de como a produtividade pode estar sendo afetada Se o time fizer um acompanhamento da d vida t cnica poss vel evitar que ela se torne cada vez maior e em vez disso trabalhar para pag la pouco a pouco importante que a equipe mantenha um backlog de
122. lor Esse o terceiro n vel de flu ncia no qual a equipe passa a entregar ainda mais valor agregado e torna se capaz de tomar melhores decis es para os produtos em desen volvimento Nesse momento a equipe compreende muito bem o que o mercado est pedindo assim como quais s o as necessidades de neg cio e como satisfaz las Agora a equipe apresenta seus resultados atrav s de m tricas concretas de ne g cio como ROI Retorno sobre o Investimento Margem de Lucro L quido por Colaborador Satisfa o do Cliente etc 57 Larsey e Shore afirmam que para se atingir esse n vel de flu ncia a equipe pre cisar de membros especializados em neg cio trabalhando em tempo integral como parte da equipe analistas de neg cio gerentes de produto vendedores publicit rios entre outros de acordo com o dom nio de neg cio do produto em desenvolvimento 5 1 DIRECIONANDO A EQUIPE Para quem n o sabe para onde vai qualquer caminho serve 5 1 Direcionando a Equipe Casa do C digo Lewis Carroll Alice no Pais das Maravilhas Definir a vis o os prop sitos objetivos e metas da organiza o e do projeto em que o time est trabalhando uma tima forma de mostrar a todos a dire o para qual devem juntos levar a organiza o atrav s do trabalho realizado no dia a dia Tudo isso s o ferramentas para unir e direcionar as pessoas com algumas mudan as sutis em termos de abrang ncia e foco N s vamos ignorar essas s
123. lor que era esperado A Inje o de Funcionalidades em ingl s Feature Injection prop e que tudo co mece com um modelo de entrega de valor 6 como por exemplo N s esperamos que o tempo m dio de faturamento reduza de 20 minutos para 5 minutos que o n mero de colaboradores dedicados ao processo reduza de 100 para 40 e a quantidade de emiss es incorretas reduza de 900 notas fiscais para 100 notas fiscais Um modelo como esse permite que o time avalie as funcionalidades que est o desenvolvendo e se de fato poder o ou n o contribuir para que o modelo de valor seja colocado em pr tica Torn lo expl cito ajuda a criar um entendimento com partilhado de onde o valor est vindo Com um objetivo claro tamb m fica mais f cil para se definir o que entra ou n o entra no escopo e qual a prioridade de cada 63 3 12 Mantenha as Op es Abertas Casa do C digo item do backlog Basta procurar entender em que a funcionalidade contribuir com o modelo de valor 2 Injete as Funcionalidades Depois de ter o modelo bem definido hora de criar uma lista de funcionali dades que dever o ser desenvolvidas para atingir o valor de neg cio O importante que deve haver uma liga o clara e objetiva entre as funcionalidades e valor de neg cio 6 Muitos Product Owners come am perguntando o que n s precisamos em vez perguntar para que n s precisamos e isso acaba levando a uma s rie de funciona lidades que
124. m caso de encontrar alguma m pratica ent o passa a ser uma boa oportunidade de discutir sobre formas melhores de solucionar o problema em quest o Para que as revis es de c digo sejam de fato construtivas para o time impor tante manter uma atitude de trabalho em equipe quando um problema for encon trado e evitar encontrar culpados ou debochar daquele que cometeu o erro Em um ambiente gil parte se do princ pio de que todos est o fazendo o seu melhor ent o se eventualmente um problema for encontrado procure se certificar de que todos saibam como evitar que o problema volte a ocorrer e siga em frente As revis es de c digo tanto podem fazer parte da defini o de pronto e conse quentemente do processo como podem ser espor dicas sendo realizadas de tem pos em tempos Em algumas equipes um desenvolvedor revisa o c digo de outro em outras equipes a revis o coletiva envolvendo v rias pessoas Algumas organiza es fazem uma mescla entre programa o em par e revis o de c digo de forma que tudo o que n o for desenvolvido em pares revisado N o h f rmula secreta para isso interessante testar diversos m todos e encontrar aquele que funciona melhor no contexto de sua equipe 4 11 D VIDA T CNICA Imagine que voc um desenvolvedor de software que est trabalhando em um sis tema de transfer ncias banc rias Voc est fazendo uma altera o que teorica mente seria muito simples mas perce
125. m promis sores o apoio da gest o para realiza o dessas atividades poder ser mais facilmente conquistado 6 6 HACKATHONS Um Hackathon um dia de trabalho com foco no aprendizado e autodesenvolvi mento atrav s de experimentos e testes de novas ideias Uma empresa australiana chamada Atlassian possui um evento realizado a cada tr s meses chamado ShipIt Days Nesse dia todas as pessoas da empresa podem escolher uma de suas ideias para trabalhar de modo que ao final de 24 horas todas devem entregar alguma coisa pronta Outras empresas como a Facebook e Spotify adotaram abordagens semelhantes 11 e atualmente essa tem sido uma pr tica de inova o e aprendizado organizacional muito utilizada em startups e organiza es 138 Casa do C digo Cap tulo 6 Otimizando o Sistema inovadoras Os projetos podem ser feitos individualmente ou podem ser colaborativos comum que no in cio do Hackathon haja um tempo em que todos se re nem para apresentar suas ideias e ent o equipes sejam formadas de maneira auto organizada Muitos desses projetos acabam se tornando produtos reais das empresas que re alizam Hackathons comum que alguma equipe tenha ideias para os produtos que desenvolvem por m por alguma raz o n o est o no backlog ou t m baixa priori dade Essa uma oportunidade de tentar colocar a ideia em pr tica e apresentar o resultado ao Product Owner e ao time Talvez a ideia nunca fa a parte do produto de
126. m servidor de homologa o ou algo do tipo A participa o do PO na constru o dessa defini o muito importante uma vez que ele conhece melhor do que ningu m as expectativas do cliente A defini o de pronto n o deve ser est tica ao contr rio disso natural que medida que o time for evoluindo e amadurecendo a defini o de pronto seja alterada para atender crit rios de mais e mais qualidade 59 4 8 INTEGRA O CONT NUA natural que em um projeto de desenvolvimento de software os desenvolvedores do time trabalhem em paralelo no desenvolvimento de funcionalidades e corre es Muitas vezes podem acabar por alterar os mesmos arquivos gerando conflitos ou at mesmo alterar arquivos diferentes que depois de combinadas as altera es o 81 4 8 Integra o Cont nua Casa do C digo software apresente um comportamento inadequado De qualquer forma de tempos em tempos as altera es precisar o ser integradas em uma base comum de c digo O processo de integra o geralmente visto por desenvolvedores como algo custoso e demorado as pe as funcionam bem quando separadas por m para tentar uni las e faz las trabalhar em conjunto o cen rio se torna mais complicado Manter o c digo sempre integrado e pronto para ser entregue um grande de safio e essa uma das finalidades da integra o cont nua A ideia da integra o cont nua que todos os desenvolvedores realizem integra o i
127. mb m chamados de testes de ser vi o ou testes de API Eles s o mais completos e geralmente combinam diferentes componentes que trabalham em conjunto para realizar em um determinado sistema S o realizados diretamente na aplica o sem passar pela interface de usu rio Em terceiro lugar e no topo da pir mide temos os testes de ponta a ponta tam b m chamados de interface de usu rio testes de sistema ou testes de aceita o que como o nome sugere testam a aplica o desde a interface do usu rio por isso s o os mais completos e geralmente s o tamb m os mais caros de se automatizar e os mais lentos para se executar importante analisar os custos e benef cios de cada um dos tipos de testes pro postos na pir mide para se fazer bons investimentos em automa o de testes H tamb m os testes explorat rios que s o executados sempre manualmente 69 41 Testes geis Casa do C digo por um membro do time com a finalidade de ir al m de onde os testes automati zados puderam chegar Eles n o seguem um script pr planejado e se beneficiam da capacidade de investiga o da observa o da analise e da adapta o do testador Atrav s deles os testadores buscam e encontram riscos que extrapolam o universo de riscos que puderam ser previstos de antem o pela equipe Em se falando de preven o de defeitos de software TDD Test Driven Deve lopment uma tima ferramenta na maioria dos contextos Essa t c
128. mbros podem se abalar por essa situa o Uma lideran a forte extremamente importante para que a equipe passe por este est gio 3 Normatiza o neste est gio que as pessoas realmente passam a priorizar os objetivos coletivos da equipe sobre os objetivos individuais de cada membro por isso a equipe consegue entrar em consenso mais facilmente 4 Performance A equipe j possui todas as compet ncias necess rias para atin gir seus objetivos todos est o comprometidos e motivados e atuam com verdadeiro esp rito de equipe pensando em termos de n s em vez de eu ou eles Conflitos s o facilmente solucionados 24 Casa do C digo Cap tulo 2 Flu ncia gil Maturidade gil Al m de uma equipe unida e forte que saiba trabalhar colaborativamente pre ciso aprender a se trabalhar com m todos geis e amadurecer na utiliza o das pr ticas geis A arte marcial Aikido utiliza um m todo de aprendizagem desenvolvido no Ja p o a mais de 4 s culos atr s chamado Shu Ha Ri 17 figura 2 2 que consiste em tr s n veis de habilidade que podem ser utilizados como refer ncia para qualquer nova pr tica habilidade ou compet ncia a ser aprendida inclusive m todos geis Os tr s est gios s o Tp pI N Shu Ha Ri Figura 2 2 Shu Ra Hi 1 Shu Representa o primeiro est gio da aprendizagem de uma habilidade em que necess rio se construir a base a funda o do que se est aprendend
129. melhor alinhamento que resultar em uma equipe mais colaborativa com menos maus entendidos e menos atrasos desnecess rios o momento em que a equipe dever ganhar maturidade para responsabilizar se pelo resultado do trabalho n o apenas em termos t cnicos mas tamb m em termos do valor de neg cio agregado e mais do que isso devem responsabilizar se pelo resultado do time e n o apenas por suas contribui es individuais claro que para que a equipe tenha essa vis o de valor em termos de neg cio essencial a presen a de algu m com um perfil de neg cios pr ximo para ajud los a compreender o que de fato de valor e o que n o Quanto mais cedo for poss vel agregar valor ao cliente melhor ser o resultado Quando o cliente recebe o software funcionando em um curtos intervalos de tempo al m de ganhar vantagem competitiva o trabalho em progresso tamb m diminui WIP Consequentemente a quantidade de trabalho parcialmente pronto diminuir o desperd cio conforme abordado anteriormente A Dell Computadores por exemplo n o acumula estoques e entrega pedidos personalizados em menos de uma semana e exatamente por n o possuir estoques acumulados pode oferecer a seus clientes novos produtos antes de seus concorrentes sem ter que se preocupar em queimar estoques de produtos antigos Assim como a faz a Dell uma equipe de software que entrega rapidamente e man t m um baixo n vel de trabalho parcialmente pronto pode
130. metas e desen volvem pessoas Elas afirmam ainda acreditarem que muitos gerentes querem ser bons gerentes por m n o sabem como fazer um bom trabalho Se voc n o est certo de quem faz o papel de gestor da sua organiza o pergunte sobre quem se responsabiliza pelo treinamento e desenvolvimento da carreira das pessoas Quem d feedback sobre o trabalho das pessoas Quem monitora o trabalho da equipe de forma sist mica Essa pessoa provavelmente assumiu o papel de gestor O ponto que a gest o est sempre presente a quest o se o papel de gestor est dividido entre todas as pessoas envolvidas ou se est representado por algu m Jurgen Appelo no Livro Management 3 0 prop e uma nova abordagem para a gest o mais alinhada aos m todos geis e coerente com a teoria da complexidade 118 Casa do C digo Cap tulo 6 Otimizando o Sistema Para todo problema complexo h uma resposta clara simples e errada H L Mencken Jornalista e Escritor 1880 1956 O mundo mudou e muitos dos conceitos que aplicamos em nossa gest o mo derna foram herdados da era industrial e pr industrial quando lidamos com profis sionais de perfis completamente diferentes de nossos atuais profissionais da era do conhecimento Devemos reinventar a gest o para que possamos endere ar os desa fios que o mundo dos neg cios nos oferece nos tempos atuais Muitos m todos e filosofias como Six Sigma Total Quality e Teoria das Restri
131. nalidades ser o entregues pri meiro e quais ser o entregues depois e em quais releases e al m disso apresenta marcos importantes do produto que est sendo construindo ver figura 3 8 Release 1 Release2 Release3 n ai e ee Saal gt Produtos Faturamento integra o Tempo Ordem de Compra A Relat rio de Lucros VW Marco 1 Comercial Figura 3 8 Roadmap 60 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio Como desenvolvimento de software altamente complexo por natureza e dif cil de se estimar e prever num contexto gil o roadmap uma ferramenta til para mostrar inten es de release e apresentar marcos do produto mas n o tanto para definir prazos exatos de entrega de funcionalidades justamente porque natural que mudan as no escopo do produto ocorram ao longo do desenvolvimento Por isso usa se mais como um crit rio relativo do que absoluto por exemplo na figura 3 8 pode se ver que a funcionalidade de pre o ser lan ada depois da de pedido mas se est definindo uma data exata para isso Muitas vezes o roadmap pode ser til para equipes de Marketing e de Neg cio se posicionarem em rela o a mais ou menos quando determinadas funcionalidades estar o dispon veis para fins de publicidade treinamentos etc 3 12 MANTENHA AS OP ES ABERTAS Um do princ pios por detr s de muitas pr ticas dos m todos geis a liberdade de escolha 40 Chris Matts e Olav Maassen chamam no de
132. nas deve se manter fixo ao navegar entre os lan amentos s o exemplos de crit rios f ceis de testar bastando que o desenvolvedor certifique se de que eles est o sendo atendidos para saber se a hist ria ser aceita pelo cliente Essas caracter sticas formam o acr nimo INVEST I Independente e N Negoci vel e V Valiosa E Estimavel S Sucinta e T Testavel Temas Epicos Funcionalidades e Hist rias comum que muitos projetos de software naturalmente possuam uma estru tura hier rquica de requisitos de forma que algumas necessidades do usu rio de alto 48 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio n vel podem ser derivadas em diversas partes menores que por sua vez podem ser dividas novamente at uma granularidade que possa ser mais facilmente compreen dida e que possa ser desenvolvida em um determinado espa o de tempo Dean Leffingwell sugere que a hierarquia de requisitos comece com Temasque representam um conjunto de iniciativas que guiam os investimentos em sistemas produtos servi os e aplica es 37 Desses temas s o derivados os picos inicia tivas de desenvolvimento que t m potencial de agregar valor ao tema do qual foi derivado S o requisitos em alto n vel e n o s o implementados diretamente antes s o quebrados em funcionalidades que posteriormente s o quebradas em hist rias de usu rio veja na figura 3 4 Temas gt gt picos gt gt Func
133. nder as raz es pelas quais determinados eventos ocorreram A t cnica consiste em analisar um determinado acontecimento perguntando por que ele aconteceu e para a resposta a essa pergunta questiona se novamente o seu porqu e assim sucessivamente at alcan ar cinco respostas veja um exemplo na figura 5 6 108 Casa do C digo Cap tulo 5 Otimizando Valor Muitas Reclama es de Clientes nessa Semana Depois da ultima Release consultas ficaram mais pesadas N o soubemos otimizar consultas com o novo Framework Falta de conhecimento t cnico do framework s N o estudamos o framework antes de implant lo no sistema Figura 5 6 Os 5 porqu s Essa t cnica muito utilizada para resolu o de problemas foi desenvolvida por Sakichi Toyoda na Toyota e faz parte de m todos como Lean Manufacturing e Six Sigma Identificando a causa raiz do problema deve se ent o trabalhar em sua so lu o ou seja buscar insights Esse exerc cio pode ser realizado por toda a equipe em um grupo grande ou em pares que depois apresentam o resultado a todo o grupo para consolida o das ideias Definindo as A es da Retrospectiva O quarto passo tem o objetivo de ajudar a equipe a decidir o que deve ser feito Agora que a equipe tem uma lista de potenciais ideias de experi ncias e melhorias a serem realizadas preciso selecionar os itens considerados mais importantes ge ralmente um ou dois por itera o e planejar o que f
134. nhecermos todas as op es ou n o escolhermos a melhor Inje o de Funcionalidades Muitos projetos come am com uma grande lista de funcionalidades abstratas a serem desenvolvidas e ent o o time precisa correr atr s de um valor de neg cio pouco claro e desconhecido Ou seja como se soubessem que t m que correr mas n o soubessem a dire o e nem por que est o correndo Quando algu m lhe pede para alterar algo da interface de usu rio por exemplo qual o valor que est por tr s dessa mudan a Reduzir o tempo do Processo Ga nhar novos Usu rios Reduzir a chance de que um erro aconte a Quando o cliente diz Preciso que seja inclu do o Campo X no Sistema voc sabe o motivo Que valor est por tr s disso Ser que isso realmente vai agregar algum valor Para quem De que forma s vezes o PO d nfase no como em vez de enfatizar o porqu Mas se isso for invertido e o PO trouxer o porqu junto com o time podem chegar a um como muito melhor A Inje o de Funcionalidades um Processo de An lise de Neg cios criado por Chris Matts com base na Teoria das Op es Reais para resolver esse problema O processo possui tr s passos bem simples 1 Persiga o Valor de Neg cio Quando o valor de neg cio n o est claro as equipes n o podem buscar for mas diferentes e mais eficientes de se conseguir o valor A funcionalidade pode ser entregue por m de forma distorcida e n o levar o va
135. nica sugere a escrita de testes de unidade antes mesmo de se codificar a funcionalidade a ser tes tada Com isso poss vel garantir alta cobertura de testes 7 e consequentemente feedback r pido em caso de altera es que possam gerar efeitos colaterais quebrando outras funcionalidades A seguir exploraremos um pouco melhor cada um dos diferentes tipos de tes tes importante ter em mente que nenhuma abordagem melhor do que a outra na verdade cada um deles uma boa ferramenta para resolver certos tipos de pro blema e voc provavelmente precisar combinar todos para garantir a qualidade necess ria no produto que est desenvolvendo Testes de Unidade Escrever testes de unidade uma pr tica essencial para se garantir a qualidade de um software Um desenvolvedor gil evita ao m ximo escrever c digo sem escrever tamb m um teste de unidade para verificar se tudo est funcionando da forma como deveria por isso no m todo XP utiliza se uma pr tica conhecida como TDD Test Driven Development ou Desenvolvimento Guiado por Testes Com TDD os testes de unidade s o escritos antes mesmo do que as classes e m todos a serem testados melhorando assim a garantia de que todo o c digo est coberto por testes importante ressaltar que o conceito de TDD vai muito al m de apenas escrever testes de unidade e apresenta na verdade uma forma inovadora de se pensar no design de um software muito raro que um desenvolved
136. ntecimentos e principalmente os problemas que est o enfrentando isto devem refletir e falar 106 Casa do C digo Cap tulo 5 Otimizando Valor sobre o que n o est indo bem Abaixo apresentamos alguns exemplos de problemas comuns que s o levantados por equipes nessa etapa da retrospectiva e N o estamos fazendo testes de unidade e Temos d vidas sobre as hist rias de usu rio e ningu m est dispon vel para nos ajudar e H muito retrabalho e Falta de conhecimento t cnico e Muitos defeitos Gerando Insights Depois de analisar os dados hora de perguntar os porqu s pensar sobre o que se pode mudar e identificar o que fazer de forma diferente A equipe deve utilizar os dados reunidos para identificar os pontos fortes e fracos da ltima itera o e ent o expor suas ideias para fortalecer os pontos fracos e n o permitir que os pontos fortes enfraque am Insights s o grandes ideias que a equipe acredita que se aplicadas ser o eficien tes na obten o de melhores resultados Busque por condi es intera es e padr es que contribu ram para o sucesso em melhorias anteriores para encontrar novos in sights Esses insights ajudar o a equipe a descobrir formas de trabalhar com maior efici ncia que o grande objetivo da retrospectiva Ao identificar problemas evite sim plesmente aceitar a primeira solu o que for proposta Ela pode de fato ser a mais adequada por m vale considerar outras
137. ntidade de hist rias come adas e n o en tregues e Lucro Influencia das entregas no lucro obtido atrav s dos incrementos no produto em desenvolvimento Esses s o apenas alguns indicadores que podem ou n o fazer sentido no seu contexto As possibilidades s o infinitas por m procure encontrar as m tricas que mais podem agregar valor ao time e d visibilidade a elas para que o time possa acompanh las e melhorar a cada nova itera o Mas quem Respons vel pela M tricas No m todo XP h um papel importante que muitas vezes esquecido trata se do tracker O tracker acompanha a agenda do time e algumas m tricas sendo a mais importante delas a velocidade do time que a rela o de tempo ideal estimado para as tarefas e o tempo gasto na implementa o Ele deve manter seus olhos nos dados importantes a serem acompanhados como a varia o da velocidade horas extras trabalhadas a rela o de testes que passaram 100 Casa do C digo Cap tulo 5 Otimizando Valor e que falharam a quantidade de defeitos e m tricas como lead time e o tempo de ciclo al m de m tricas mais t cnicas voltadas ao c digo fonte como cobertura de testes m tricas de complexidade coes o e acoplamento Martin Fowler e Kent Beck resumem que o papel do tracker diz respeito a fazer perguntas simples que apontem poss veis problemas 28 5 3 APRESENTE O RESULTADO EM REUNI ES DE DEMONS TRA O A cada novo incremento que
138. o O aprendiz busca observar copiar e imitar o que algu m que j tem experi ncia faz geralmente um mestre Neste est gio mais eficiente seguir regras do que tentar improvisar ou modificar t cnicas Uma equipe que est come ando a trabalhar com m todos geis certamente por algum tempo estar nesse est gio um momento importante para seguir as regras do m todo numa abordagem by the book ou seja sem altera es ou improvisos Se uma equipe est utilizando Scrum neste est gio por exemplo importante que todos os pap is sejam assumidos e que todas as reuni es sejam realizadas de acordo com as regras Esse um momento em que pode ser importante procurar ajuda de algu m que tenha experi ncia com m todos geis 2 Ha Esse o segundo est gio em que o estudante j come a a pensar mais pro fundamente sobre os porqu s das coisas quebra algumas regras e rompe um pouco 25 2 2 Ordem Caos e Complexidade Casa do C digo com a tradi o Agora j poss vel refletir sobre o que foi aprendido e compreender melhor os princ pios em vez de apenas repetir ou seguir regras nesse est gio que algumas adapta es ao contexto podem come ar surgir no vas pr ticas s o inseridas e insights de experi ncias passadas servem como base para tomadas de decis o Agora mesmo que as coisas mudem um pouco em sua forma pr ticas pap is reuni es a equipe estar pronta para manter a ess ncia
139. o trabalho do dia a dia Aprenda sobre a hist ria e o ambiente da sua equipe importante analisar a hist ria e moral da equipe especialmente em rela o ao projeto atual Estude quais s o os artefatos dispon veis e quais podem ser incorporados para ajudar converse com l deres formais e informais Essa investiga o poder ajud lo 104 Casa do C digo Cap tulo 5 Otimizando Valor a fazer as perguntas certas durante a reuni o e o ajudar o a prever quais problemas devem ser enfrentados Em suma o facilitador deve guiar a reuni o assegurar que todos os membros da equipe estejam compreendendo os objetivos das atividades e que todos tenham chance de falar e expor seus pensamentos QUANTO TEMPO DEVE LEVAR UMA REUNI O DE RETROSPEC TIVA N o existe uma f rmula para definir este valor Como costumam di zer os consultores depende Voc deve levar em considera o alguns fatores como o tempo da itera o o tamanho da equipe propens o a conflitos e controv rsia e complexidade dos assuntos a serem discuti dos O m todo Scrum por exemplo sugere duas horas de reuni o de retrospectiva para um sprint de 30 dias A facilita o e at mesmo a participa o em retrospectivas um processo de aprendizado cont nuo quanto mais pr tica maior ser a efici ncia para alcan ar bons resultados Voc deve avaliar o resultado das retrospectivas atrav s dos bene f cios conquistados isto das melhor
140. o dia a dia do time construa um mural de pr ticas e torne tudo expl cito Na pr xima retrospectiva 91 4 13 E agora o que eu fa o amanh Casa do C digo discuta com o time as pr ticas atuais se todas elas ainda fazem sentido e que novas pr ticas poderiam ser acrescentadas para benef cio do projeto e da equipe Reconhe a e Pague suas D vidas T cnicas Re na sua equipe e fa a um levanta mento da d vida t cnica do seu projeto atual Classes dif ceis de se compreender ou alterar c digo sem cobertura de testes gambiarras deixadas para tr s etc Levante tudo que puder e procure fazer priorizar junto com o time de acordo com o quanto cada um dos itens prejudica a performance do time Leve a lista ao PO e negocie com ele de que forma esses itens podem ser solucionados ao longos das itera es Sua equipe tem uma pol tica para programa o em par Tudo feito em par Nada feito par Define se o que ser ou n o feito em par na Reuni o Di ria Que tal conversar com equipe sobre isso e definir alguma coisa para a pr xima itera o Que tal propor uma sess o de revis o de c digo com alguns membros do seu time Durante a sess o apresente a seu time alguns dos conceitos de Clean Code vistos nesse cap tulo Quais m todos voc s est o utilizando para guiar o processo de desenvolvimento Ser que podem incluir algumas pr ticas de outros m todos para aprimorar o pro cesso 92 CAP TULO 5 Otimizando Va
141. o fim do processo Ex 2 dias do backlog registro do pedido do cliente produ o entrega do software funcionando e Cycle time tempo de ciclo O tempo total entre o in cio e o fim da produ o ou da presta o de servi o Ex 6 horas por hist ria de usu rio do to do ao done Tempo de Vida Quantidade de tempo em que uma hist ria de usu rio est no Backlog e Quantidade de hist rias impedidas Lista de hist rias impedidas por falta de informa es ou recursos e Taxa de Defeitos por hist ria A quantidade defeitos para cada hist ria de usu rio 99 5 2 M tricas geis Casa do C digo e Sa de do Build Tempo que o Build est passando em rela o ao tempo que est quebrado e Valor de Neg cio Agregado Total de valor de neg cio das hist rias entregues na itera o e Horas Trabalhadas Soma das horas dedicadas ao projeto por todos os mem bros do time e Cobertura de Testes Percentual de cobertura de testes de unidade Pode ser facilmente obtido por ferramentas de an lise de cobertura Quantidade de Cen rios de Teste Contagem dos cen rios de testes disponi veis Throughput Produ o Quantidade de hist rias entregues em determinado per odo de tempo e Happiness Index da Equipe Indica a Motiva o do Time subjetivo mas pode ser muito til para perceber quando o clima est ruim e tomar alguma a o para melhorar Trabalho em Progresso WIP Qua
142. o mapa para definir releases em camadas ou seja releases que cont m um pouco de cada funcionalidade veja na figura 3 6 E Es ME RELEASE 2 RELEASE 3 Figura 3 6 Releases no Mapa de Historias Para ilustrar imagine por exemplo um site de com rcio eletr nico que sera composto por funcionalidades de carrinho de compra vitrine eletr nica e Consulta de Pedidos Em vez de entregar uma funcionalidade completa com todas as hist rias envolvidas poss vel entregar algumas hist rias de cada funcionalidade por release Dessa forma o produto poderia ser lan ado com o b sico de cada funcionalidade e j poderia ser utilizado medida que os outros releases forem entrando no ar as funcionalidades seriam aprimoradas com a entrega de outras hist rias 52 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio RECOMENDA ES e Desenvolva o mapa de hist rias colaborativamente convide o PO analistas de neg cio desenvolvedores etc e Mantenha o mapa sempre vis vel para que o time possa discutir frente a ele e tomar decis es mais facilmente uma vez que o mapa d uma vis o melhor do todo e sobre como as diferentes funci onalidades e hist rias de usu rio est o conectadas a objetivos de neg cio 43 3 8 CONHECENDO OS USU RIOS ATRAV S DE PERSONAS Personas s o perfis baseados nos clientes e usu rios do produto A cria o de per sonas ajuda a identificar Perfis de Clientes e Usu
143. o saiam daqui enquanto eu n o autorizar n o chorem n o gritem n o levantem e imagine e inclua mais umas 50 regras aqui Num contexto totalmente ordenado todas as vari veis devem ser isoladas e por isso poss vel prever acontecimentos por m note que ambos os extremos s o exa gerados No primeiro as crian as acabam se machucando por excesso de liberdade e neglig ncia no segundo exemplo as crian as mal podem se divertir pois preci sam seguir ordens restritas e n o t m liberdade alguma para se auto organizar ou expressar sua individualidade e criatividade O meio termo entre esses extremos seria dar s crian as algumas restri es b sicas para certificar se de que elas poder o brincar sem que nada de mal ocorra a elas Voc diria algo do tipo Crian as podem brincar do que quiserem e fiquem onde eu possa v los e n o deixem que a gua ultrapasse a cintura de voc s Agora pense em uma equipe de desenvolvimento de software que n o possui nenhuma regra comum entre os membros da equipe cada um escreve c digo da maneira que acha melhor uns escrevem testes outros n o alguns utilizam certas conven es outros utilizam outras cada um trabalha em sua linguagem de progra ma o preferida alguns trabalham no escrit rio outros de casa cada um define sua frequ ncia de integra o do c digo D pra imaginar que esse cen rio seria um bagun a n o Por outro lado uma equipe que est no extremo
144. o todos os testadores todos os designers e todos os de senvolvedores Veja na figura 6 5 um exemplo 139 6 7 Comunidades de Pr tica Casa do C digo Figura 6 5 Comunidade de Pr tica Comunidades de pr tica s o grupos de profissionais que compartilham interes ses comuns ou uma rea comum de trabalho Podem ser formadas ao redor de temas pap is na organiza o tecnologias etc Os participantes aprendem e compartilham informa es relevantes ideias e boas pr ticas e padronizam m todos de trabalho A maneira com a qual as organiza es lidam com as comunidades de pr tica pode variar bastante algumas podem possuir comunidades de pr ticas informais que n o s o reconhecidas nem apoiadas pelo organiza o outras podem ser reco nhecidas e apoiadas 20 e que podem inclusive possuir responsabilidades e mui tas vezes at ter um tempo reservado durante o hor rio de trabalho para reuni es e discuss es Isso depende do valor que a comunidade de pr tica pode agregar organiza o e da capacidade da gest o de enxergar e apoiar essas iniciativas 140 Casa do C digo Cap tulo 6 Otimizando o Sistema 6 8 E AGORA O QUE EU FA O AMANH Fa a um exerc cio com a sua equipe crie uma lista com dez problemas que voc s tenham enfrentado na ltima semana de trabalho e ent o para cada um deles ve rifique como foram resolvidos Ser que voc s realmente foram em busca da causa do problema e o resolveram de um
145. oas s o a parte mais importante de uma empresa certo Gerentes devem portanto fazer o que for poss vel para mant las ativas criativas e motivadas A Teoria X da Motiva o nos diz que as pessoas n o gostam de trabalhar traba lham por necessidade porque precisam e por isso precisam da motiva o extr nseca 120 Casa do C digo Cap tulo 6 Otimizando o Sistema para trabalhar e al m disso precisam de controle para garantir que est o de fato re alizando seu trabalho como devem Por outro lado a Teoria Y da Motiva o nos diz que as pessoas gostam de seu trabalho e que encontram prazer em trabalhar e por isso podem ser motivadas por seus desejos intr nsecos e n o somente por algo externo A motiva o extr nseca segundo Jurgen pode ser vista como um fator higi nico porque podemos compar la a escovar os dentes ou tomar banho por exemplo N o a quantidade vezes que escovamos os dentes que nos torna mais feliz mas a falta da oportunidade de escovar os dentes que nos faria tristes Pesquisas apontaram que a motiva o extr nseca em geral dinheiro b nus pr mios e recompensas n o suficiente para manter as pessoas motivadas preciso entender quais s o os desejos e necessidades de cada indiv duo atrav s da abordagem da motiva o intr nseca para que ent o de alguma forma seja poss vel alinhar esses desejos das pessoas realidade da organiza o encontrar uma intersec o entre os prop
146. oblema de forma muito mais eficiente do que poderiam fazer se estivessem trabalhando so zinhos o princ pio da sinergia aplicado programa o Em um primeiro olhar pode se pensar que a programa o em par uma t cnica que reduz a produtividade da equipe e que se ambos os desenvolvedores estivessem trabalhando em paralelo resolveriam um determinado problema mais rapidamente do que trabalhando juntos A programa o em par a pr tica de desenvolvimento gil de software com mais estudos cient ficos realizados na Academia at agora e alguns desses estudos de monstram que na pr tica a programa o em par n o apresenta grandes diferen as de produtividade 67 e que em geral o produto entregue com menos defeitos e com melhor qualidade isso significa que menos tempo ser desperdi ado em corre es de defeitos e que a futura manuten o do software ser mais f cil ou seja em uma an lise de m dio prazo podemos concluir que a programa o em par de fato eficiente Um dos fatores que apoiam essa alta produtividade press o dos pares Nestes tempos de redes sociais e mail SMS e diversas outras distra es um desenvolvedor pode facilmente perder o foco e se distrair quando trabalha sozinho Trabalhando em par o desenvolvedor assume um compromisso com seu colega reduzindo assim a distra o e a perda de foco e como h um colega acompanhando a codifica o h uma preocupa o maior em criar solu
147. obre o Investimento Quanto mais cedo os clientes puderem come ar a utilizar o produto mais r pido rece ber o retorno do valor investido no desenvolvimento do produto seja atrav s de lucros diretos gerados pelo produto ou atrav s dos benef cios gerados pela utiliza o do produto na organiza o e Maior Satisfa o do Cliente e Melhor Gest o de Mudan as de Prioridades O planejamento iterativo permite que o cliente facilmente mude suas prio ridades com impacto reduzido na produtividade da equipe porque planeja se detalhamento apenas daquilo que est mais pr ximo de ser feito evitando tamb m desperd cios e custos desnecess rios A comunica o constante e a proximidade com o cliente frequentemente resulta tamb m em um melhor alinhamento entre os objetivos de TI e com os objetivos de neg cio da orga niza o e Melhor Visibilidade dos Projetos Faz parte da cultura gil manter as in forma es do projeto vis veis e transparentes atrav s de ferramentas como burndown charts e card walls discutidas posteriormente com as quais a equipe e gest o podem acompanhar dia a dia a evolu o do projeto em rela o s metas do projeto e das itera es e Maior Produtividade Infelizmente n o h uma forma universalmente aceita de se medir produtividade de equipes de desenvolvimento de software Mui tos consideram essa tarefa at imposs vel ou algo subjetivo demais mas na pesquisa supracitada 75 dos participantes
148. olvida e explica para os desenvolvedores tudo o que for preciso para que eles possam implement la Um bom design uma excelente ferramenta para que todos possam compreender melhor os sistemas complexos suas estruturas depend ncias e regras de neg cio O principal objetivo manter o design sempre simples evitando aumentar a comple xidade com a cria o de funcionalidades que n o sejam realmente necess rias Essa a m xima do principio YAGNI You aren t gonna need it Voc n o vai precisar disto que basicamente diz que devemos fazer as coisas somente no mo mento em que realmente precisarmos delas muitas vezes antecipamos o desenvolvi mento antes mesmo que surja a necessidade real assumindo que um dia ela chegar por m essa necessidade pode nunca chegar Ao manter o design simples e fazer somente aquilo que for necess rio voc pou par tempo porque deixar de escrever c digo que n o precisa e ter mais tempo para se concentrar na qualidade do que realmente necess rio e que vai agregar va lor para a demanda real e atual do cliente Codificar uma atividade essencial para o desenvolvimento de software afinal de contas sem c digo n o existe software algum Nessa etapa extremante impor tante que o cliente continue acess vel para que possa oferecer feedback e responder s diversas d vidas que surgem durante o desenvolvimento Com XP os testes de unidade s o escritos antes do c digo de produ o d
149. or acredite que possa escrever c digo que sem pre funcionar na primeira vez Na verdade muitos ficam surpreendidos quando isso acontece Por isso independente de escrever testes antes ou depois preciso testar para garantir que o software est funcionado da maneira que deveria funcio nar Uma altera o em um determinado trecho de c digo de uma parte de um sistema pode causar um problema em outra parte e os componentes geralmente cont m de pend ncias que quando alteradas podem modificar seus comportamentos de forma 70 Casa do C digo Cap tulo 4 Entregando Valor inesperada s o os conhecidos efeitos colaterais Al m de ajudar na melhoria da qualidade os testes de unidade podem ajudar o desenvolvedor a entender melhor as regras de neg cio do sistema uma vez que provavelmente haver um teste para cada regra Dessa forma eles poder o ser con siderados tamb m uma documenta o viva porque al m servir como refer ncia para compreens o das regras de neg cio servir o tamb m para garantir que essas regras estejam implementadas corretamente e que o software esteja se comportando da maneira que se espera importante que os testes sejam f ceis de se executar porque pouco adiantar ter testes de unidade que nunca s o executados ou que s o executados com uma frequ ncia muito baixa Testando antes com Desenvolvimento Guiado por Testes Desenvolvimento Guiado por Testes TDD um processo em que o de
150. ores aplicam desenvolvimento guiado por testes e enquanto a barra estiver verde indicando que os testes est o passando todos da plateia podem dar sugest es ou discutir abordagens mas quando a barra estiver verme lha indicando que os testes est o quebrando apenas o navegador e o condutor podem falar 3 Uma r pida retrospectiva para que os participantes apontem o que correu bem e o que pode ser melhorado no pr ximo coding dojo J no formato Prepared Kata algu m que j resolveu um desafio de programa o anteriormente apresenta a solu o de um problema passo a passo desde o ponto zero utilizando desenvolvimento guiado por testes Cada passo deve fazer sentido para todos os participantes audi ncia de forma que as pessoas podem interromper a qualquer momento em caso de d vidas 2 Dojos s o uma excelente ferramenta de aprendizado para desenvolvedores e organiza es podem ceder tempo e ou espa o para que desenvolvedores possam realiz los com o intuito de praticar suas habilidades e se tornarem melhores pro fissionais Clubes de Discuss o de Livros Um Clube do Livro um grupo de pessoas leem o mesmo o livro e se re nem com determinada frequ ncia para discutir cap tulos ou trechos do livro expressando suas opini es aprendizados coisas que gostaram e n o gostaram a respeito dos conceitos 137 6 6 Hackathons Casa do C digo e ideias apresentadas do livro Geralmente as pessoas v o lendo o livro m
151. ossa atrapalhar o progresso do desenvolvimento garantindo assim que o objetivo da itera o seja atingido importante ressaltar que o Scrum Master n o atua como um gerente ou chefe da equipe porque ela auto organiz vel O Scrum Master n o determina o que cada membro da equipe deve ou n o fazer a equipe se compromete com a entrega das funcionalidades e ent o se auto organiza definindo por quem e em qual momento as tarefas ser o realizadas Toda sprint come a com uma reuni o de planejamento que dividida em duas partes A primeira delas tem um enfoque mais estrat gico na qual se decide o que ser feito isto quais funcionalidades ser o implementadas e define se uma meta para a Sprint Para isso o Product Owner apresenta os itens do product backlog e a equipe obt m informa es suficientes sobre cada um dos itens dessa forma possi vel fornecer uma estimativa que expresse um tamanho ou um n mero de horas para o trabalho e assim seja definido quantas e quais tarefas poder o ser desenvolvidas no sprint de acordo com a velocidade da equipe que calculada atrav s de dados de sprints passados Depois de definidas quais tarefas ser o desenvolvidas no sprint a equipe utiliza a segunda parte da reuni o que tem um enfoque mais t tico para decidir como ser o feitas as tarefas Ent o se analisa tarefa por tarefa com mais detalhes mais informa es de neg cio s o apresentadas e poss vel tomar diversas decis
152. overno realizar alguma mudan a no plano tribut rio voc provavelmente ter desperdi ado tempo e dinheiro 3 Hist rias devem agregar valor aos clientes Como mencionado anteriormente hist rias devem descrever funcionalidades que de alguma forma oferecer o ao cli ente retorno ao seu investimento Por essa raz o hist rias de car ter t cnico n o s o aconselh veis por exemplo atualizar o Spring Framework para vers o 2 5 n o agrega valor de neg cio ao software pelo menos n o diretamente isso n o significa que voc n o possa faz lo mas aconselh vel que exista uma hist ria escrita pelo cliente que a justifique 4 Hist rias devem ser estim veis importante que os desenvolvedores sejam capazes de estim las Para que sejam estim veis necess rio que os desenvolve dores possuam ou tenham acesso atrav s do cliente ao conhecimento de neg cio e possuam tamb m o conhecimento t cnico necess rio para transformar a hist ria em software Seria invi vel pedir a um desenvolvedor que nunca escreveu uma linha de c digo em Java que estime o esfor o para desenvolver um pedido de venda em um projeto Java EE com EJB 3 O mesmo aconteceria se pedissemos ao desenvolve dor para que estimasse o esfor o para criar um relat rio de fluxo de caixa sem antes explicar a ele o que um fluxo de caixa 5 Hist rias devem ser pequenas Hist rias muito grandes s o dificeis de esti 47 3 6 Escrevendo Hist rias de
153. para nada contribuem Por isso com Inje o de Funcionalidades voc come a de tr s para frente ou seja em vez de perguntar o que eu preciso as en tradas do sistemas voc pensa em por que precisa nas sa das do sistema importante lembrar que o valor n o est nas funcionalidades em si mas no resultado que o uso delas fornece ao usu rio Tradicionalmente as pessoas de neg cio v m com solu es meio prontas em vez de apresentar o valor de neg cio que est o buscando Com Inje o de Funcionali dades o time prop e solu es em cima do valor apresentado De certa forma a Inje o de Funcionalidades semelhante a TDD Desenvol vimento Guiado por Testes porque em vez de come ar por escrever o c digo da funcionalidade no TDD voc come a fazendo um teste que verifica se o resultado est correto e depois faz a implementa o da funcionalidade Com Inje o de Fun cionalidades voc come a com o Output do Sistema Sa das Resultado e depois descobre os Inputs Entradas de que precisa para conseguir o Output Para dar ainda mais nfase no valor de neg cio Cris Matts prop e uma invers o no formato tradicional das hist rias de usu rio de Mike Cohn Como um lt papel gt Eu quero lt funcionalidade gt para que lt valor de neg cio gt A inje o de Funcionalidades come a pelo valor de neg cio Para que lt valor de neg cio gt como um lt papel gt eu quero lt funcionalidade gt
154. penas os requisitos de maior import ncia para que seja mais simples se manter as hist rias priorizadas e organizadas Por exemplo se voc est desenvolvendo um sistema fi nanceiro e sabe que n o far o calculo de financiamento nos pr ximos 5 releases melhor manter apenas um pico Financiamento do que j quebrar em hist rias es pec ficas Calcular Financiamento com Sistema SAC Calcular Financiamento com Sistema Price etc 58 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio MANTENHA O BACKLOG PEQUENO Para se ter uma ideia de como a complexidade de priorizar hist rias aumenta medida que se adiciona hist rias no backlog se voc tiver 3 est rias no backlog A B C voc pode ter 6 ordens de prio ridade diferentes A B C B A C B C A A C B C A B e C B A Agora se voc tiver 5 itens poder ter 120 ordena es dife rentes se tiver 10 itens poder ter 3 628 800 e se tiver 20 itens poder ter 2 432 902 010 000 000 000 ordena es diferentes Isso mesmo um calculo fatorial como nas corridas de cavalos Um dos principais benef cios dos m todos geis e do desenvolvimento em ite ra es a redu o do tempo das entregas para o cliente Durante o planejamento de releases importante procurar potencializar o time to market por isso devemos descobrir qual escopo necess rio para agregar algum valor ao cliente e ent o definir um rele
155. presas passa ram a adot lo Kanban est bastante relacionado com o conceito de Pull Systems sistemas de produ o puxados do Toyota Production System TPS Tradicionalmente antes da Toyota a grande maioria das ind strias utilizava o conceito de Push Systems siste mas de produ o empurrada Um sistema de produ o empurrada caracteriza se quando a primeira opera o do processo recebe uma ordem de produ o e a executa empurrando o resultado da opera o atual para a opera o seguinte Em sistemas empurrados n o h liga o direta entre o que produzido e a demanda do cliente ou seja pode se dizer que o fato de um item ter sido produzido n o significa que um outro item tenha sido vendido J um sistema de produ o puxada exige que cada opera o do processo seja alimentada pela demanda da etapa anterior estabelecendo uma liga o direta entre o consumo real do cliente e a quantidade produzida Dessa forma o fato de um item ter sido vendido geraria a demanda para a fabrica o de outro Em uma abordagem de desenvolvimento de software poder amos dizer que a demanda para se trabalhar em uma nova funcionalidade seria gerada quando alguma outra fosse entregue Kanban uma palavra japonesa que significa cart o sinalizador utilizado no Sistema Toyota de Produ o TPS e tamb m por diversas empresas que aderiram filosofia Lean para representar em um sistema puxado de produ o um sinal para que se pux
156. prise and Scrum Microsoft Press 2007 57 Diana Larsen James Shore Your path through agile fluency http martinfowler com articles agileFluency html 150 Casa do C digo Refer ncias Bibliogr ficas 58 G R Stephenson Cultural acquisition of a specific learned response among rhe sus monkeys In Starek D R Schneider and H J Kuhn eds Progress in Pri matology Fischer 1967 59 Ken Schwaber Jeff Sutherland Software in 30 Days How Agile Managers Beat the Odds Delight Their Customers And Leave Competitors In the Dust John Wiley and Sons 2012 60 Vin cius Manh es Teles Extreme Programming Aprenda como encantar seus usu rios desenvolvendo software com agilidade e alta qualidade Novatec Editora Ltda 2004 61 Andrew Hunt David Thomas The Pragmatic Programmer From Journeyman to Master Addison Wesley Professional 1999 62 David Thomas Code kata How to become a better developer http codekata pragprog com 2007 01 code kata backg html 2007 63 Alan Shalloway Guy Beaver James R Trott Lean Agile Software Development Achieving Addison Wesley Professional 2009 64 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cun ningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C Martin Steve Mellor Ken Schwa ber Jeff Sutherland Dave Thomas Manifesto for agile software development http agilemanife
157. quenos cones expostos em uma rea do quadro da equipe veja na figura 4 5 90 Casa do C digo Cap tulo 4 Entregando Valor MOVIMENTAR RELEASES PESSOAS PEQUENOS CODE SPIKES PRIORIZAR i PALESTRAS DOCUMENTAR AN LISE EST TICA COBERTURA DE CODIGO TECNICAS ef Ga l EQUIPE PROGRAMA O MENTORING COICO LIMBO MULTI FUNCIONAL PAREADA Figura 4 5 Mural de Pr ticas Inclua todas as pr ticas do seu time aquelas das que voc s se orgulham e das que n o se orgulham torne tudo expl cito para que possam visualizar e discutir frequen temente se elas ainda fazem sentido e quando novas pr ticas poder o ser acrescen tadas Voc pode inclusive associar m tricas a cada uma dessas pr ticas para assegurar que elas realmente fazem parte do dia a dia do time e n o est o no mural apenas de enfeite Lembre se n s somos aquilo que fazemos com frequ ncia O que voc e seu time est o fazendo com frequ ncia que os tornam geis 4 13 E AGORA O QUE EU FA O AMANH Seu time j possui uma defini o de pronto para hist rias itera es e releases expli cita e vis vel para todos Ainda n o Que tal reunir o time e o PO para propor e discutir uma defini o Se voc s j possuem defini es de pronto fa a uma revis o e verifique se ela est atualizada e se est de fato representando o estado de pronto ideal para o contexto da sua equipe Re na o time e identifique as pr ticas geis que fazem parte d
158. r o finalmente instalados em produ o Assim como os outros procedimentos esta reuni o tamb m deve possuir uma cad ncia geralmente a cada duas semanas ou mensal Todos os interessados do projeto podem participar da reuni o Especialistas de integra o especialistas de redes desenvolvedores testadores designers e todos que estiverem relacionados ao processo de entrega deployment devem estar presentes O importante que a reuni o seja composta pelas pessoas capazes de tomar decis es t cnicas de neg cio e gerenciais Quando o processo de release muito complexo pode ser interessante ter uma pessoa respons vel por coorden lo comum que um gerente de projetos assuma esse papel liderando a reuni o al m de coordenar os releases Durante a reuni o de planejamento de releases deve se deliberar sobre que itens ir o compor o pr ximo release Este um momento oportuno para se levantar e con siderar os ricos pensar sobre planos de conting ncia e treinamentos analisar quanto tempo o processo de deploy dever levar quem dever estar presente no momento do deploy e quando ele ser realizado 57 310 Definindo Entregas com o Planejamento de Releases Casa do C digo Para que os releases sejam curtos necess rio tentar dividir as hist rias das itera es em grupos que representem o m nimo poss vel de funcionalidade que agregue algum valor Dessa forma o cliente n o precisar esperar muito tempo para
159. razer essas coisas para o que voc est fazendo Bem j faz algum tempo que eu venho tentando seguir esse conselho por isso que eu agrade o tamb m aqui a todos aqueles que desde o Manifesto gil v m se dedicando para que possamos encontrar melhores maneiras de se de senvolver software Agrade o tamb m minha noiva Fernanda que minha maior fonte de inspi ra o e sempre me apoia em todos os meus desafios Finalmente agrade o a voc leitor voc raz o pela qual esse livro existe sem voc esse trabalho n o seria sequer necess rio Aproveite a leitura Casa do C digo Quem sou eu Meu nome Andr Faria Gomes Atualmente sou s cio e diretor de produtos e tec nologia na Bluesoft em S o Paulo e tamb m Associated Trainer na Adaptworks Sou Bacharel em Sistemas de Informa o pela FIAP Black Belt em Lean Seis Sigma pela Funda o Vanzolini e Management 3 0 Licensed Trainer O foco principal do meu trabalho no desenvolvimento de software atuando na lideran a de equipes no coaching de m todos geis e no desenvolvimento de produtos para a Internet com diversas tecnologias e plataformas Minha carreira em TI come ou em 1999 e desde ent o trabalhei com uma grande diversidade de tecnologias Desde 2007 venho aplicando m todos geis no dia a dia e sempre buscando me lhores formas de se lidar com os desafios da gest o e do desenvolvimento de software Atuo tamb m como palestrante tradutor es
160. rdem Cass e Complexidade sushi sa E OR 26 23 Eaves 0 que ci RAD 2 ks hk dae ads ae bd dase os 29 3 Foco em Valor para o Neg cio 31 31 Disseminando a Vis o do Projeto 2 02000 33 3 2 Planejamento e Desenvolvimento Iterativo 35 3 3 Planejando uma Itera o 6k ca oe eh gas a ada a 38 SA A Reuniao Di ria ee ee anete he me eae bw AY BL ewe oe ee Gee ee BL 40 3 5 Limitando o Trabalho em Progresso 0000 44 3 6 Escrevendo Hist rias de Usu rio 000 000000 45 3 7 Mapeando hist rias de usu rios 0000 51 3 8 Conhecendo os Usu rios atrav s de Personas 53 vii Sum rio Casa do C digo 3 9 Melhorando a Previsibilidade com Estimativas 56 3 10 Definindo Entregas com o Planejamento de Releases 57 311 Roadmap do Produto 0 00000 ee eee 60 312 Mantenhaas Op es Abertas ss sas ser soca wa ae al 61 313 Eagora O que eu fa o D O esses crer pr E 65 4 Entregando Valor 67 do DEAD bw Ke Oh ES LEE ES CRERLEES EAR ESA 68 4 2 Simplificando o C digo com Refatora o 000 74 C digo Limpa ss pras iness anes da BOR eM Oa GER ES 76 4 4 Propriedade Coletiva do C digo nose ce veda pib ads 77 ee Ling agem big a ses kes bao he si kor raketa a KOS 78 4 6 Design gil Design Iterativo nonan auaa aa 79 47 Definindoo significado de Pronto ss ss sss sss eae eso 80 AS Ineera do CONUM ss Pica ad ad 4 ao d
161. re e resolver o problema Para garantir uma boa qualidade de c digo preciso refatorar medida que novos comportamentos s o inclu dos no software por consequ ncia aumentando a complexidade existe uma grande tend ncia de se escrever c digo duplicado e torn lo mais dif cil de compreender e de dar manuten o Por outro lado preciso tomar cuidado para n o cair em um perfeccionismo extremo e gastar tempo tentando aperfei oar detalhes sem import ncia Para facili tar a identifica o do momento correto para realizar a refatora o Poppendieck cita cinco caracter sticas de um sistema ntegro Se qualquer uma destas estiver faltando sinal de que hora de refatorar S o elas 1 Simplicidade Na maioria das vezes um design simples o melhor design 75 4 3 C digo Limpo Casa do C digo Design Patterns quando bem aplicados s o uma tima ferramenta para aplicar so lu es simples a problemas complexos 2 Clareza O c digo fonte deve ser facilmente compreendido por todos os mem bros da equipe Todos os elementos do c digo devem ser devidamente nomeados para que sejam facilmente compreendidos por todos 3 Efic cia Um bom design deve produzir o resultado correto isto deve atingir o objetivo pelo qual foi criado 4 Sem repeti o O mesmo c digo n o deve existir em dois lugares diferentes Quando uma mudan a precisa ser feita em muitos lugares o risco de defeitos cresce exponencialmente
162. receber retorno de seu investimento e receber esse retorno frequentemente em funcionali dades que seriam adicionadas pouco a pouco ao produto agregando assim cada vez mais valor ao software O planejamento de releases oferece um mapa para alcan ar o objetivo do projeto Imagine um projeto de seis meses para um supermercado Poder amos dividi lo em seis releases de um m s cada No primeiro release poder amos entregar o m dulo de gerenciamento de pre os no segundo release o m dulo de pedido de compra no terceiro os relat rios gerenciais e assim por diante Assim a cada m s o cliente poderia resgatar um pouco de seu investimento em forma de software importante buscar entregar o m ximo de valor agregado ao cliente a cada rele ase mas isso n o significa o mesmo que entregar o maior n mero de funcionalida des preciso entender o que agregar mais valor Muitas vezes uma nica funcionalidade pode agregar mais valor do que dezenas de outras juntas No Scrum por exemplo fala se do conceito de valor de neg cio ou business value que pode ser representado por um intervalo num rico como por exemplo de o a 100 O valor de neg cio definido pelo PO e atrav s dele que a prioridade das funcionalidades a serem desenvolvidas determinada Esse valor pode mudar ao longo do tempo por isso importante estar preparado para adaptar o planejamento Outro fator importante em se tratando de prioriza o detalhar e quebrar a
163. reduzir a produtividade neste momento Mas apesar do alto investimento uma equipe bem capacitada tecnica 41 Testes geis Casa do C digo mente poder criar produtos com menos defeitos o que resultar em mais tempo para produzir funcionalidades que realmente possam agregar valor Algumas pr ticas predominantes neste est gio s o programa o em par inte gra o cont nua propriedade coletiva de c digo e desenvolvimento orientado a tes tes TDD A seguir faremos um r pido estudo sobre cada uma dessas pr ticas geis 4 1 TESTES GEIS M todos geis defendem a ideia de que preciso criar software de qualidade desde o in cio ao inv s de assegurar a qualidade apenas no final do processo Novas funcionalidades ser o entregues com alta frequ ncia e n o se pode permi tir que as altera es realizadas no software para criar as novas funcionalidades fa am com que funcionalidades j existentes deixem de funcionar para prevenir que isso aconte a que existem os testes de regress o que podem ser realizados manualmente ou automatizados Al m disso deve se prevenir defeitos a todo o momento porque quanto antes um defeito for detectado mais r pido e barato ser para resolv lo O que mais barato descobrir que uma altera o em uma parte do software criou um defeito em outra atrav s do feedback de um testes de unidade durante o desenvolvimento e ent o resolver o problema na mesma hora enquanto ainda s
164. responder rapidamente a novas necessidades que venham a surgir sem se preocupar em deixar o trabalho que j foi come ado para tr s As organiza es que entregam rapidamente estruturam se de forma que as pes soas saibam como o trabalho deve ser feito sem que algu m precise dizer a elas o que fazer 48 Essas pessoas devem ser capazes de resolver problemas e fazer adap ta es para responder a mudan as Essas diretrizes s o profundamente aplicadas na Toyota Entregar rapidamente complementar ao princ pio de tomar decis es no l timo momento poss vel Por exemplo se o cliente recebe entregas de software toda semana n o precisa decidir sobre o que ser feito daqui a nove meses Entretanto 32 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio se o cliente recebe software somente a cada tr s meses ent o precisar decidir sobre as novas funcionalidades no m nimo tr s meses antes de poder v las em funciona mento Nesse cap tulo abordaremos como equipes podem aplicar pr ticas geis para ga rantir que o cliente receba valor de neg cio com frequ ncia atrav s da entrega itera tiva de software em funcionamento 3 1 DISSEMINANDO A VIS O DO PROJETO Projetos sempre nascem de ideias de pessoas Ideias que geralmente nascem de ten tativas de tornar um determinado processo mais eficiente Seus donos s o chamados de vision rios porque eles possuem a vis o do projeto e entendem a necessidade e con
165. ri dade alta e a outra baixa provavelmente a hist ria dependente de prioridade baixa 46 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio precisar ser desenvolvida antes das outras tarefas assim que chegar a hora da his t ria de prioridade alta ser desenvolvida Nesses casos pode ser interessante unir ambas em uma nica hist ria 2 Hist rias devem ser negoci veis n o devem ser vistas como requisitos que de ver o ser implementados a qualquer pre o Lembre se hist rias s o apenas curtas descri es de funcionalidades que dever o ser analisadas e discutidas com o cliente no momento em que sua prioridade for atingida ou seja no momento em que a his t ria fizer parte de uma itera o importante que a hist ria seja detalhada apenas quando o momento de seu desenvolvimento estiver pr ximo isto quando chegar o momento de a hist ria entrar na itera o corrente Quanto mais cedo ela for ana lisada e detalhada maiores ser o as chances de haver retrabalho e at mesmo perda de tempo e energia considerando que o cliente aprende e muda de ideia medida que as itera es v o sendo conclu das Para ilustrar melhor este exemplo imagine uma hist ria que tenha como obje tivo a cria o de um relat rio de apura o de impostos Imagine que segundo sua prioridade ela ser implementada somente daqui a seis meses mas que ainda as sim inicia se um trabalho de an lise e discuss o sobre ela Se o g
166. ria o de conhecimento e que na pr tica o design detalhado de um software ocorre so mente na codifica o Um design prematuro ou seja realizado antes da codifica o n o pode prever a complexidade encontrada durante a implementa o e tampouco pode utilizar se do feedback que s pode ser recebido ao longo do desenvolvimento O design de um software deve evoluir ao longo de seu desenvolvimento Tentar fix lo prematuramente resultar em desperd cio Em se tratando de requisitos deve se seguir a mesma linha de pensamento de forma que os requisitos devem ser detalhados apenas quando estiverem perto da hora de desenvolv los importante tamb m estar preparado para as prov veis mudan as neles uma vez que o cliente tamb m est aprendendo e evoluindo suas ideias a respeito da solu o que est sendo desenvolvida As abordagens prematuras de levantamento de requisitos e de design s o chama das respectivamente de Big Requirements Up Front BRUP e Big Design Up Front BDUF e t m sido amplamente abordadas na comunidade gil como pr ticas a se rem evitadas pois o conhecimento n o gerado por antecipa o mas sim atrav s de experimenta o codifica o e releases frequentes que permitem receber feedback dos clientes O desenvolvimento de software iterativo e incremental encaixa se per feitamente nessa linha de pensamento 79 4 7 Definindo o significado de Pronto Casa do C digo YAGNI VOCE NAO VAI
167. rioriza o o cliente pode definir quanto valor uma hist ria pode agregar ou seja quais funcionalidades podem trazer mais benef cios Temos ent o uma rela o de custo benef cio Atrav s dessa colabora o entre a equipe de desenvolvimento e o cliente pos s vel tra ar um plano para atingir sucesso no projeto O jogo do planejamento dividido em duas fases o planejamento de releases e o planejamento de itera es Um dos principais benef cios do planejamento iterativo a elimina o do des perd cio de uma longa an lise prematura que considerado um dos maiores des perd cios no desenvolvimento de software 49 comum em projetos waterfall que a an lise de todos os requisitos seja feita de antem o de forma que no momento do desenvolvimento os requisitos j mudaram e da maneira que foram analisados j n o podem mais agregar valor ao cliente Essa pr tica de levantamento prematuro de requisitos conhecida como Big Requirements Up Front BRUP 36 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio BACKLOGS DEEP Para ajudar Product Owners a n o ca rem no erro do levantamento prematuro de requisitos Mike Cohn criou o acr nimo DEEP 20 que representa 4 qualidades de um bom backlog 1 D Detalhado Apropriadamente Os itens de maior prioridade devem ser mais detalhados e os itens de menor prioridade n o precisam de muitos detalhes 2 E Estimado Se todos os itens do Backlog estiver
168. ris Matts Chris Geary Commitment Hathaway te Brake Publications 2013 31 Kevlin Henney 97 Things Every Programmer Should Know O Reilly Media Inc 2010 eae 32 Norman L Kerth Project Retrospectives A Handbook for Team Reviews Dorset House 2001 33 Laurie Williams Robert Kessler Pair Programming Illuminated Addison Wesley Professional 2002 34 Henrik Kniberg Kanban and Scrum making the most of both Lulu com 2010 35 Henrik Kniberg Lean from the Trenches Managing Large Scale Projects with Kanban Pragmatic Bookshelf 2011 36 Craig Larman Agile and Iterative Development A Manager s Guide Addison Wesley Professional 2003 37 Dean Leffingwell Agile Software Requirements Lean Requirements Practices for Teams Programs and the Enterprise Addison Wesley Professional 2010 38 Scott W Ambler Mark Lines Disciplined Agile Delivery A Practitioner s Guide to Agile Software Delivery in the Enterprise IBM Press 2012 39 Tom DeMarco Timothy Lister Peopleware Productive Projects and Teams Dorset House 1999 40 Chris Matts Olav Maassen Real options underlie agile practices http www infoq com articles real options enhance agility 2007 41 Robert C Martin Clean Code A Handbook of Agile Software Craftsmanship Prentice Hall 2008 ee 42 Robert C Martin The Clean Coder A Code of Conduct for Professional Pro grammers Prentice Hall 2011 149 Refer ncia
169. rojeto equipe cliente gerente comunidade etc Os resultados devem ser expli citos e vis veis para que os envolvidos possam entender como est o e aonde devem chegar e tomar a es para melhorar Desenvolver compet ncias O encontro da prepara o com a oportunidade gera o rebento que chamamos sorte Anthony Robbins Times n o conseguir o atingir suas metas caso alguns de seus membros n o es tiverem suficientemente capacitados A gest o deve contribuir para o desenvolvi mento das compet ncias das pessoas Mais adiante nesse cap tulo trataremos de v rias pr ticas teis que podem ser utilizadas pelo time com apoio da Gest o para fomentar o aprendizado e capacita o das pessoas Estruturar Muitos times trabalham dentro de um contexto organizacional complexo por tanto importante considerar estruturas que promovam a comunica o Como di vidir as pessoas em equipes Unir as pessoas de acordo com suas fun es ou formar equipes que entreguem o produto do in cio ao fim Como essas equipes poder o se 124 Casa do C digo Cap tulo 6 Otimizando o Sistema comunicar diretamente ou por interm dio de algu m Qual a quantidade ideal de membros em um time gil Todas essas s o quest es relevantes em se tratando de estruturar a organiza o Mais adiante falaremos de forma es de equipes e abordaremos esse assunto com mais profundidade Melhorar tudo O importante n o parar de questionar
170. rtunidade que o time tem de entender porque est nessa situa o de press o e o que pode fazer para sair dela O Facilitador de Retrospectivas Toda reuni o de retrospectiva deve ter um facilitador tamb m chamado de l der de retrospectiva O facilitador deve garantir que todos os participantes mantenham o foco nos objetivos da retrospectiva e ajudar a equipe a se organizar para realizar as atividades que os direcionem a descobrir o que precisa ser melhorado e o que pode ser feito para melhorar Os facilitadores focam na estrutura e no processo da retrospectiva e devem es tar constantemente atentos s atividades e ao tempo importante que o tempo de dura o da reuni o seja bem definido apresentado a todos assim como respeitado Ultrapassar o tempo definido pode fazer com que os participantes fiquem dispersos e sintam se desrespeitados uma vez que podem ter outros compromissos atividades e obriga es que requerem sua aten o ap s a reuni o Reuni es que n o terminam no tempo definido tendem a se tornar cansativas e pouco produtivas Os outros participantes da retrospectiva em contrapartida devem estar total mente focados no conte do na discuss o e na tomada de decis es completamente despreocupados com o processo da retrospectiva deixando o a cargo do facilitador O papel de facilitador pode ser rotativo dentre os membros da equipe de forma que a cada itera o possa existir uma pessoa diferente assumindo
171. s Bibliogr ficas Casa do C digo 43 Lindsay Ratcliffe Marc McNeill Agile Experience Design A Digital Designers Guide to Agile Lean and Continuous New Riders 44 Tim Ottinger Continuous Improvement In A Flash A Guide For Scrum Masters Leanpub 45 Carol Sansone Carolyn C Morf A T Panter The Sage Handbook of Methods in Social Psychology SAGE Publications 2004 46 Roman Pichler Agile Product Management with Scrum Creating Products that Customers Love Addison Wesley Professional 2010 47 Daniel H Pink Drive The Surprising Truth About What Motivates Us Ri verhead Books 2011 48 Mary Poppendieck Tom Poppendieck Lean Software Development An Agile Toolkit Addison Wesley Professional 2003 49 Jonathan Rasmusson The Agile Samurai How Agile Masters Deliver Great Soft ware Pragmatic Bookshelf 2010 50 Donald G Reinertsen Managing the Design Factory Free Press 1997 51 Ken Howard Barry Rogers Individuals and Interactions An Agile Guide Addison Wesley Professional 2011 52 Winston Royce Managing the development of large software systems 1970 53 Kenneth S Rubin Essential Scrum A Practical Guide to the Most Popular Agile Process Addison Wesley Professional 2012 54 Harvard Business School Hbs elevator pitch builder http www alumni hbs edu careers pitch 55 Ken Schwaber Agile Project Management with Scrum Microsoft Press 2004 56 Ken Schwaber The Enter
172. s Potencialmente Entreg veis O PO pode exercer ou n o a op o de fazer um release do resultado de uma itera o etc J com m todos tradicionais o cliente precisa decidir sobre todo o escopo de an tem o e se precisar de altera es ter custos extras por isso levado a tomar uma s rie de m s decis es antecipadas e esse mesmo erro permanece no Big Require ments Up Front e no Big Design Up Front Muitas pessoas preferem estar erradas do que estar em d vida Por isso acabam tomando decis es ruins por serem precipitadas 30 Op es Reais nos apresentam uma melhor forma de lidar com nossas decis es Tr s regras das Op es Reais 1 Op es s o valiosas Op es s o valiosas porque podem ser executadas No exemplo do ingresso do cinema para o comprador uma op o que est justamente na possibilidade de entrar na sess o para ver o filme O valor est em ter op es em poder escolher 2 Op es expiram Op es t m um tempo de vida no caso do ticket de cinema ele s vale durante o tempo do filme ap s a sess o do filme a op o perde seu valor independente de ser sido exercida ou n o 3 Nunca se comprometa cedo a menos que saiba o porqu Quando voc se 62 Casa do C digo Cap tulo 3 Foco em Valor para o Neg cio compromete com uma op o est abrindo m o de todas as outras e do valor que elas podem oferecer Quando nos comprometemos cedo demais h um grande risco de n o co
173. s t cnicas 22 Nenhum processo perfeito Al m disso sua equipe nica e provavelmente est sempre enfrentando desafios diferentes de todas as outras por isso o processo deve ser adaptado e melhorado continuamente para atender de forma eficiente as necessidades da equipe exatamente nisso que as retrospectivas podem ajudar um equipe de desenvolvimento de software Nas retrospectivas poss vel que a equipe reflita e identifique mudan as e me lhorias que poder o aumentar a qualidade do software e aprimorar seu dia a dia de trabalho Retrospectivas s o naturais em m todos geis que focam em adapta o e res postas r pidas a mudan as por m podem tamb m ser realizadas em equipes que utilizam m todos tradicionais James Shore e Shane Warden sugerem que apenas os membros da equipe parti cipem de retrospectivas 66 para que esses possam sentir se vontade e que efetiva mente possam falar abertamente de seus problemas do cotidiano Deve se entender por equipe todas as pessoas envolvidas no projeto que s o diretamente ligadas ao desenvolvimento do software isso exclui por exemplo clientes investidores e curi osos 102 Casa do C digo Cap tulo 5 Otimizando Valor N O SUBESTIME O PODER DA RETROSPECTIVA Retrospectivas infelizmente costumam ser a primeira pr tica a ser cortada do processo em momentos que a equipe est sob press o mas ocorre que geralmente a retrospectiva a melhor opo
174. s tomadas fiquem dispon veis de alguma forma para consulta de todos e utiliza o em retrospectivas futuras Algumas equipes mant m todas as melhorias definidas na reuni o de retrospectiva em um backlog de melho rias que mantido e priorizado pelo pr prio time 110 Casa do C digo Cap tulo 5 Otimizando Valor COMECE COM O FORMATO MAIS SIMPLES Tanta informa o etapas tempo prepara o t cnicas etc podem parecer um pouco demais para quem est come ando N o se intimide com isso comece reunindo o time em frente a um quadro branco ou um flip chart e discuta com o time sobre as seguintes perguntas e O que est indo bem e O que pode ser melhorado No final das contas o que realmente importa que a reuni o tenha como resultado a es a serem tomadas pela equipe para que a melho ria cont nua seja aplicada e que na pr xima retrospectiva a equipe seja melhor do que era na ltima A medida que o time for evoluindo na utiliza o de m todos geis procure variar um pouco as t cnicas utilizadas para que a reuni o n o se torne previs vel e massante Dinamizar e alterar o formato da retrospec tiva sem d vida estimular a criatividade do time para buscar solu es para melhorar continuamente Voc pode pesquisar por novas t cnicas e din micas de grupo para utilizar nas retrospectivas nos sites http retrospectivewiki org e http tastycupcakes org 5 5 ELIMINANDO DESPERDICIOS COM LE
175. senvolve dor come a a implementa o de uma nova funcionalidade pelo teste e deve o tempo todo fazer de tudo para que seu c digo fique simples e com qualidade 7 TDD realizado atrav s de um ciclo com os seguintes passos Figura 4 2 Ciclo de TDD Imagem de Maur cio Aniche 1 Adicione um teste rapidamente 2 Execute todos os testes e observe o novo teste falhar 71 41 Testes geis Casa do C digo 3 Fa a uma pequena mudan a para fazer o teste passar 4 Execute todos os teste e observe que foram bem sucedidos 5 Refatore O uso de TDD assegura que todo c digo adicionado ao reposit rio seja testado e al m disso d nfase em se escrever apenas o c digo necess rio para que os tes tes passem evitando que o desenvolvedor escreva mais do que necess rio contri buindo para um c digo mais simples enxuto e tamb m mais f cil de se dar manu ten o Testando de Ponta a ponta com testes de Aceita o Testes de Unidade n o s o os nicos tipos de teste que devem ser realizados Existem outros tipos que unidos aos unit rios poder o trazer uma qualidade ainda melhor ao software o caso dos testes de aceita o tamb m conhecidos como testes funcionais ou testes de usu rio final Testes de aceita o diferente dos testes de unidade que verificam apenas o com portamento de uma classe ou m todo testam o comportamento do sistema de uma forma mais ampla Geralmente representam o cont
176. sma raz o n o recomend vel que um desenvolvedor perten a a v rias equipes A programa o em par um bom exemplo de t cnica que ajuda a evitar inter rup es uma vez que duas pessoas trabalhando juntas e trocando conhecimentos muito provavelmente n o precisar o interromper outros membros do time para re solver problemas Desperd cio por atrasos Uma das maiores fontes de desperd cio no desenvolvimento de software s o os atrasos Atrasos por aprova o ou revis o de requisitos atrasos por contrata o de pessoal atrasos nos testes atrasos na entrega etc 113 5 6 E agora o que eu fa o amanh Casa do C digo Quanto maior o atraso mais tempo ser necess rio para que o cliente obtenha retorno sobre o investimento realizado no desenvolvimento do software As t cnicas estudadas anteriormente para limitar o trabalho em progresso e en tregas frequentes for am o processo a ser mais enxuto e flu do reduzindo assim esse tipo de desperd cio Desperd cio por recursos ou pessoas indispon veis Quando o Product Owner n o est presente e n o h ningu m que o represente e existe alguma d vida ponto a ser esclarecido ou decis o a ser tomada preciso esperar que ele esteja presente para dar continuidade ao desenvolvimento ou no pior dos casos por falta de informa es o desenvolvedor pode seguir por um caminho inadequado que provavelmente resultar em um defeito Por essa raz o muito importan
177. solu o ruim que pode nem sequer agregar valor mas que em vez disso o valor de neg cio seja o foco do processo e que puxe tudo o mais que for preciso para que ele possa ser conquistado 3 13 E AGORA O QUE EU FA O AMANH Voc se responsabiliza ativamente pelo resultado do seu time ou apenas por suas contribui es individuais Reflita sobre isso A vis o do produto que voc est ajudando a construir est disseminada entre todos os membros da sua equipe Que tal criar um discurso de elevador para seu produto 65 3 13 E agora o que eu fa o amanh Casa do C digo Quais s o os marcos mais importantes do seu produto Fa a um roadmap de seu produto e identifique os Quais os diferentes perfis de usu rios que utilizam ou utilizar o o produto que voc est ajudando a criar Discuta com sua equipe e crie algumas personas procure associ las com as funcionalidades que voc s est o desenvolvendo atualmente Qual a frequ ncia com que voc s entregam software para o cliente Essa frequ ncia poderia ser diminu da de alguma forma No pr ximo planejamento da sua equipe proponha fazer um mapeamento das hist rias de usu rio depois de escrever as hist rias e organiz las verifique se est o atendendo os crit rios INVEST e discuta sobre isso com a equipe Sua equipe j est utilizando limites de trabalho em progresso WIP Se n o que tal conversar com time e definir alguns limites iniciais para identificar g
178. sso sincronizem o c digo fonte produzido com o sistema de controle de vers o a maior quantidade de vezes poss vel ao longo do dia recomendado que a cada integra o todos os testes de unidade sejam execu tados para assegurar que o build n o seja quebrado e que tudo est funcionando corretamente Chamamos de build constru o o processo de gerar um pacote execut vel de software Isso inclui a compila o de c digo fonte e al m disso pode se acoplar uma s rie de outros processos para garantir que o pacote est em boas condi es como an lise est tica de c digo verifica o de padr es de codifica o execu o de testes automatizados etc Alguns exemplos de ferramentas de build s o make Gradle ant maven e BuildR Se o software possuir um bom n vel de cobertura de testes e os testes forem bem escritos essa pr tica pode reduzir consideravelmente o n mero de defeitos em produ o e garantir que o c digo fonte produzido para implementar novas funcio nalidades n o fez com que algo deixasse de funcionar como deveria Existem diversas ferramentas na verdade servidores de integra o cont nua inclusive alguns s o de uso livre e open source que podem ajudar na integra o cont nua poss vel configurar essas ferramentas para que cada vez que algum desenvol vedor enviar algum novo c digo fonte para o sistema de controle de vers o todos os testes sejam executados e o desenvolvedor receba uma
179. st de f rias Esta pessoa um ilha de conhecimento e essa situa o nociva para o projeto porque se cria uma depend ncia muito grande em uma nica pessoa o que possivelmente tamb m resultar em gargalos e sobrecarga C digo Coletivo uma boa vacina contra ilhas de conhecimento e reduz o risco se algu m por alguma raz o deixar o projeto 77 4 5 Linguagem ub qua Casa do C digo Nessa abordagem de propriedade de c digo se um desenvolvedor encontrar um c digo pouco claro sem testes ou fora dos padr es e qualidade n o importa quem o escreveu esse c digo poder e dever ser melhorado 4 5 LINGUAGEM UB QUA Desenvolvedor N s estamos com um problema no NFBusinessDelegate quando enviamos o objeto para o Service parece que a transa o n o iniciada e o DAO e ent o n o funciona bem Cliente Desenvolvedores devem falar a linguagem de neg cio 66 Um dos grandes desafios do desenvolvimento de software muitas vezes a co munica o entre desenvolvedores que n o s o experts no dom nio reas de neg cio do software com os experts do neg cio 66 Em seu livro Domain driven design DDD Eric Evans cunhou o termo Lingua gem Ub qua que diz respeito cria o de uma linguagem comum entre experts no neg cio e o time de desenvolvimento de software Dessa forma essa mesma lingua gem de neg cio utilizada no pr prio c digo fonte do software na hora dar nomes a par me
180. sto org 2001 65 VersionOne State of agile development survey results 66 James Shore Shane Warden The Art of Agile Development O Reilly 2007 67 Laurie Williams Strengthening the case for pair programming 68 James Q Wilson and George Kelling The police and neighborhood sa fety http www theatlantic com magazine archive 1982 03 broken windows 304465 1982 151
181. tando Dados Depois da prepara o vem a apresenta o dos dados Ainda que os benef cios de reunir informa es de uma itera o que tenha durado uma ou poucas semanas possa n o ser evidente essa uma pr tica muito importante para a retrospectiva Em uma itera o semanal por exemplo perder um dia significa perder 20 dos acontecimentos Mesmo que as pessoas estejam presentes elas n o veem tudo o que acontece Al m disso pessoas diferentes veem os mesmos acontecimentos com perspectivas diferentes Portanto reunir informa es faz com que a equipe crie uma vis o compartilhada de tudo o que aconteceu expandindo a perspectiva de toda ela importante apresentar m tricas hist rias de usu rio conclu das decis es to madas resultados de outras reuni es realizadas ao longo da itera o desafios en frentados novas tecnologias adotadas e tudo que tiver significado para a equipe Voc pode utilizar como m tricas o burndown chart a velocidade da equipe o n mero de hist rias prontas o n mero de defeitos resolvidos a cobertura de testes etc Outra t cnica interessante para apresentar os acontecimentos da itera o criar uma linha do tempo e permitir que as pessoas enumerem acontecimentos Isso faz com que as pessoas lembrem se dos eventos relevantes ao projeto como releases milestones e problemas diversos que podem ser posteriormente analisados Independente da t cnica utilizada a equipe deve descrever os aco
182. te que o Product Owner esteja presente pr ximo da equipe Desperd cio por defeitos Defeitos s o sem d vida uma das maiores fontes de desperd cio no desenvolvi mento de software e quanto mais tempo um defeito leva para ser identificado maior ser o desperd cio gerado Por essa raz o defeitos devem ser identificados e resolvidos o mais r pido pos s vel Essas s o apenas algumas das muitas fontes de desperd cios que todas as equipes de desenvolvimento de software possuem em maior ou menor grau O exerc cio constante de analisar e questionar o processo essencial para que eles possam se tornar cada vez menores e menos relevantes 5 6 E AGORA O QUE EU FA O AMANH Quais m tricas voc s utilizam para acompanhar a produtividade e qualidade do tra balho da sua equipe Revise as m tricas apresentadas na se o 5 2 e verifique se alguma delas poderia ajudar Que tal utilizar um dos gr ficos apresentados CFD Burndown ou Burnup e deix lo vis vel para que toda a equipe possa acompanhar o progresso da itera o Quais dos desperd cios apresentados na se o 5 5 voc reconhece no seu projeto O que voc poderia fazer para ajudar a reduzir ou elimin lo 114 Casa do C digo Cap tulo 5 Otimizando Valor Procure uma t cnica de retrospectiva diferente uma que nunca foi utilizada em sua equipe antes e ofere a se para ser o facilitador da pr xima retrospectiva 115 CAP TULO 6 Otimizando o Sistema
183. tidade de pessoas que trabalha naquela etapa do processo Numa equipe com dois testadores por exemplo poder se ia iniciar com um limite de 3 e fazer experimentos ao longo do tempo para se chegar no limite ideal No quadro da figura 3 3 o limite do desenvolvimento est estourado e os desen volvedores n o podem puxar mais hist rias nem os testadores que est o no limite Nessa situa o a equipe toda precisa focar em entregar as hist rias que est o mais pr ximas do final do processo antes de poder come ar a trabalhar em novas hist rias Sem limite de trabalho em progresso mais trabalho seria come ado e poderia correr o risco de na data de release a equipe n o ter terminado ainda uma s rie de hist rias e defeitos que mesmo estando em andamento n o estariam prontos para serem entregues ao cliente Quando uma hist ria ficar pronta no est gio em que se encontra e esperando para ser puxada para o pr ximo est gio est em uma fila As filas devem ser t o pequenas quanto poss vel Recomenda se considerar a cria o de pequenas filas para que absorvam a varia o do processo e permitam que fluxo n o seja interrompido Muitos processos se n o possu rem filas poder o fazer com que as pessoas fi quem desocupadas gerando tempo ocioso devido a varia es no tempo que cada item leva para ficar pronto Novamente importante observar seu processo e em piricamente optar pela solu o que permitir melhor fluidez 3 6 E
184. tos 40 pontos 20 pontos 0 pontos Dia Dia 2 Dia 3 Dia 4 Dia 5 Dia 6 Dia 7 Figura 5 2 Burnup Chart Equipes que aplicam o m todo Kanban geralmente utilizam um gr fico seme lhante ao burnup chart por m detalhado por etapa do processo permitindo visua lizar a varia o do trabalho em progresso ao longo do tempo trata se do diagrama de fluxo cumulativo em ingl s Cumulative Flow Diagram ou CFD veja na figura 5 3 96 Casa do C digo Cap tulo 5 Otimizando Valor EB Pronto Testando Desenvolvendo E Backlog 500 pontos 375 pontos 250 pontos 125 pontos 0 pontos Semana Semana 2 Semana 3 Semana 4 Semana 5 Semana 6 Figura 5 3 Cumulative Flow Diagram Com o CED poss vel observar exatamente onde o trabalho em progresso est e quais os gargalos Observe na figura 5 3 que depois da semana 3 a etapa testando n o parou de aumentar de tamanho diminuindo as entregas etapa pronto Isso pode ser um sinal que os testes se tornaram um gargalo e que algo precisa ser feito para tornar o processo mais eficiente aumentando o throughput entregas Na grande maioria das vezes esse acumulo de trabalho em determinada etapa do processo um sinal de que necess rio trabalhar os limites de trabalho em progresso conforme estudamos na se o 3 5 Depois de algumas itera es poss vel medir tamb m a velocidade do time por itera o total de pontos entregues por itera o e a velocidade m
185. transformando a em algo conhecido como jogo de culpas o que geral mente faz com que as pessoas levem para o lado pessoal percam o foco da re trospectiva e criem um clima desagrad vel e competitivo impedindo que o grupo trabalhe colaborativamente Ao inv s de culpar algu m por ter quebrado o build por exemplo deve se pro curar expor problemas por falta de aten o ao enviar o c digo ao reposit rio sem antes executar os testes de unidade e ressaltar a import ncia de manter se alerta a essa pr tica Foco est sempre no problema e n o na pessoa ou poss veis culpados Norm Kerth em seu livro Project Retrospectives apontou uma frase a qual chamou de primeira diretriz das retrospectivas Independentemente do que descobrirmos hoje n s compreendemos e acredi tamos que todos fizeram o melhor trabalho que podiam dado o que conheciam suas compet ncias e habilidades os recursos dispon veis bem como a situa o em m os 32 Kerth recomenda que no inicio das retrospectivas o facilitador leia a primeira diretriz para a equipe Ela uma ferramenta para trazer consci ncia para o trabalho colaborativo e para a confian a que os membros da equipe devem depositar entre si Dessa forma poss vel evitar problemas como ataque a indiv duos e distribui o de culpa essencial que as pessoas deixem de lado a competi o e colaborem para alcan ar um bom resultado na retrospectiva podendo estender isso tamb m a
186. tros m todos vari veis classes testes etc importante que o time compreenda cada um dos termos utilizados por clien tes comum que os experts do neg cio tenham seus pr prios jarg es assim como desenvolvedores e testadores tamb m t m seus pr prios Em um projeto sem uma linguagem comum o tempo todo desenvolvedores precisam traduzir seus termos para o expert de neg cio assim como esse tamb m t m que traduzir seus termos para os desenvolvedores e isso prejudica a comunica o 23 Com uma linguagem comum tanto a linguagem das discuss es quanto a do pla nejamento ser a mesma utilizada no c digo Se em um sistema de log stica por exemplo o cliente se refere a cargas os desenvolvedores no c digo fonte utiliza r o precisamente o mesmo o termo cargas e n o mercadorias ou produtos ou lote por exemplo O primeiro passo para melhorar a comunica o reconhecer a sua fragilidade e a linguagem ub qua uma excelente ferramenta para ajudar voc e sua equipe a se comunicarem melhor com as pessoas de neg cio envolvidas em seu projeto 78 Casa do C digo Cap tulo 4 Entregando Valor 4 6 DESIGN GIL DESIGN ITERATIVO Um dos maiores erros do desenvolvimento em cascata achar que o conhecimento existe apenas na forma de requisitos levantados antes do in cio da implementa o e separados do desenvolvimento Em uma perspectiva gil o desenvolvimento de software um processo de c
187. ue foi planejado O eixo vertical representa o total de traba lho pendente nesse caso pontos de hist ria de usu rio poderia ser qualquer outra medida de trabalho de pendente enquanto o eixo horizontal representa o tempo nesse caso dias da semana poderia ser qualquer outra medida de tempo como ite ra es ou semanas por exemplo O Ideal O Realizado 60 pontos 45 pontos 30 pontos 15 pontos 0 pontos Dia Dia 2 Dia 3 Dia 4 Dia 5 Dia 6 Dia 7 Figura 5 1 Burndown Chart Note que no dia 4 h uma diferen a grande entre o ideal e o realizado e uma boa oportunidade para que o time possa discutir sobre o que est acontecendo e tomar alguma a o para eventualmente melhorar e investir no sucesso da itera o enquanto ainda h tempo 95 5 2 M tricas geis Casa do C digo No burndown chart sempre que algum trabalho for conclu do o gr fico cai quando o trabalho reestimado o gr fico sobe quando algum trabalho acrescen tado o gr fico sobe e quando algum trabalho removido o gr fico desce 19 Uma alternativa ao burndown chart burnup chart que em vez de descer medida que o trabalho vai sendo conclu do vai subindo Alguns times preferem usar o burnup porque mais f cil de expressar altera es do escopo como por exemplo uma melhoria ou defeito urgente que surgiu ao longo de uma itera o como pode ser visto na Figura 5 2 O Ideal O Realizado Escopo 80 pontos 60 pon
188. ue mais c digo vai sendo acrescentado mais desorganizado e dif cil de se compreender o reposit rio vai se tornando Isso impacta negativamente na produtividade dos de senvolvedores que encontrar o mais dificuldade em dar manuten o nas funciona lidades existentes e em adicionar novas funcionalidades Qualquer idiota pode escrever c digo que um computador pode entender Bons programadores escrevem c digo que seres humanos podem entender Martin Fowler Refatorar alterar a estrutura do c digo sem alterar o seu comportamento uma pr tica que permite que o desenvolvedor melhore o design do c digo tornando o mais limpo e f cil de se compreender uma t cnica essencial para prevenir que o c digo se deteriore 20 Mas para que o desenvolvedor possa alterar o c digo com seguran a de que o comportamento n o ser alterado essencial que o c digo possua uma boa base de testes que atuem como uma rede de seguran a prevenindo que o comportamento do software perca a consist ncia Por isso escrever testes e refatorar s o t cnicas que geralmente s o utilizadas em conjunto e exatamente por isso que ambas s o utilizadas no desenvolvimento guiado por testes conforme estudaremos a seguir Um bom design evolui ao longo da vida de um sistema mas Poppendieck afirma que um bom design n o acontece por acidente Por isso ao encontrar algo errado na base do c digo preciso parar de incluir novos comportamentos ao softwa
189. ue todos possam utilizar esse feedback para melhorar J a forma pode variar bastante H diversas abordagens que podem ser usadas por exemplo pode ser an nimo pode ser face a face pode ser mais subjetivo e aberto ou mais objetivo e relacionado a metas espec ficas o resultado pode ser particular ou pode ser publicado para todos Alguns dos formatos mais comuns s o 1 Face a face Uma reuni o informal em um ambiente casual em que cada parti cipante oferece e recebe feedback de cada um dos outros 8 De acordo com Jurgen 128 Casa do C digo Cap tulo 6 Otimizando o Sistema Appelo reuni es informais funcionam melhor do que avalia es mais tradicionais porque as pessoas podem discutir abertamente e esclarecer d vidas para entender melhor pedindo exemplos reais 2 Envelopes Essa uma forma que geralmente um pouco aberta em que todos os membros do time recebem um envelope com seus nomes escritos contento folhas em branco A equipe ent o senta em formato de c rculo e os envelopes s o passados em sentido hor rio de forma que cada um dos membros do time ao pegar o envelope do colega escreve algo positivo sobre ele e algo que ele pode melhorar Ao final os envelopes voltam a m o de seus donos com as folhas preenchidas com o feeback Cada um fica com seus resultados para analisar o que pode melhorar 3 Formul rios A forma mais tradicional atrav s de formul rios que podem ser digitais ou em papel em qu
190. ue uma fase iniciada somente quando a anterior termina O termo foi originado em um artigo publicado em 1970 por W W Royce 52 O pr prio autor descreveu o m todo como arriscado e propenso a falhas 12 M todos geis Casa do C digo Requistos El am ise q El dem j E codifica o El testes j E implanta o E manuten o Figura 1 1 Processo em Cascata Waterfall claro que desenvolvimento gil n o a nica forma de se encarar o desenvol vimento de software nem a nica maneira eficiente como disse Frederick Brooks em 1986 nenhuma tecnologia ou t cnica de gest o resolve todos os problemas de todos os contextos Ele resumiu essa ideia dizendo que n o h prata de bala 15 M todos geis assumem imprevisibilidade natural do desenvolvimento de soft ware por isso considera se que o cliente tamb m est aprendendo sobre o que precisa e que a cada feedback pode mudar de ideia e alterar o escopo do projeto Assume se tamb m que estimativas de esfor o e tempo de desenvolvimento s o de fato estimativas e n o devem ser tratadas como algo certo e sem margem de erro Por assumir a imprevisibilidade envolvida no desenvolvimento de software m todos geis se baseiam nos ciclos de feedback constante permitindo que o cliente e a equipe de desenvolvimento possam adaptar se s mudan as aumentando assim as chances de sucesso do projeto Um fato interessante que muitas vezes d
191. uipe Quantas pessoas deixaram a equipe nos ltimos seis meses e quantas novas pessoas foram recebidas Reflita so bre o impacto dessas mudan as na produtividade da sua equipe Voc s rotacionam os membros das equipes de tempos em tempos Isso foi bom ou ruim Por qu Qual tem sido o impacto dessas mudan as na performance da equipe Pense em qual dos est gios Tuckman sua equipe se encontra no seu ponto de vista em rela o agilidade O que pode ser feito para vencer os desafios atuais e seguir para o pr ximo est gio Converse com sua equipe sobre os seus objetivos Voc s sabem qual o papel de voc s na organiza o Caso estes objetivos n o estejam claros procure compreend los conversar com a gest o e torn los expl citos para que toda a equipe saiba para onde est o indo e aonde devem chegar A equipe tem liberdade para decidir qual a melhor forma de atingir seus obje tivos ou as decis es s o impostas pela gest o Discuta com sua equipe sobre como voc s podem ganhar mais confian a da gest o para criar um ambiente mais favor vel auto organiza o Pense sobre as quais s o as regras da sua equipe S o realmente necess rias Ser que alguma delas foi til no passado mas agora j perdeu o sentido 29 CAP TULO 3 Foco em Valor para o Neg cio N o incomum ouvirmos hist rias de times que passaram anos construindo um produto que ningu m jamais usou ou ent o de equipes que passaram meses otimi
192. utilezas e nos referir apenas a metas Uma diferen a crucial entres metas tradicionais e metas geis que as caracteris ticas e crit rios para defini o das geis n o s o fixas mas vari veis de acordo com o contexto 8 Dependendo do objetivo final algumas metas podem ser mais inspiradoras ou memor veis ou espec ficas ou ambiciosas enfim as caracter sticas da meta n o pre cisam atender a um conjunto de crit rios como SMART Espec ficas Mensur veis Ating veis Realistas Tang veis por exemplo para que sejam teis para guiar o time A Wikimedia funda o por tr s da famosa enciclop dia digital Wikipedia apre senta sua miss o como A miss o da Funda o Wikimedia empoderar e engajar pessoas pelo mundo para coletar e desenvolver conte do educacional sob uma li cen a livre ou no dom nio p blico e para dissemin lo efetivamente e globalmente 26 j sua vis o Imagine um mundo onde cada ser humano possa compartilhar livremente na soma de todo o conhecimento Esse o nosso compromisso 27 Note que ambas de uma forma ou de outra mostram exatamente o que a Wi kimedia est fazendo e no que seus colabores devem concentrar seus esfor os para conquistar Esse o ponto Jamais use metas para intimidar as pessoas ou amea las em vez disso para ajud las a entender o que a organiza o precisa que fa am naquele dado momento e para que todos possam remar o barco na mesma dire
193. vantagens de se utilizar um software como apoio s o as fun cionalidades que permitem armazenar detalhes extras das hist rias de usu rio visu aliza o de m tricas como tempo de ciclo e lead time gera o de gr ficos de burn down e burnup entre outros facilitadores Alguns softwares que podem ajudar sua equipe s o Acelerato em portugu s Lean Kit Kanban Agile Zen Target Process Silver Catalyst RadTrack Kanbanery VersionOne Greenhopper com Jira Flow io entre outros Se houver um quadro f sico e um virtual importante garantir que ambos per mane am atualizados e consistentes Por isso existe o papel do Sticky Buddy su gerido por Darren Davis que nada mais do que algu m que assume a respon Casa do C digo sabilidade de manter o quadro f sico sempre atualizado em caso de algu m estar trabalhando remotamente e n o poder mover os itens do quadro f sico Se voc e sua equipe nunca utilizaram um software como esses antes vale a pena propor um teste para analisar se agrega ou n o valor voc s 146 Casa do C digo Refer ncias Bibliogr ficas Refer ncias Bibliogr ficas Pair programming http www extremeprogramming org rules pair html What is a coding dojo http codingdojo org cgi bin wiki pl WhatIsCodingDojo Chaos report http www standishgroup com 2008 Lyssa Adkins Coaching Agile Teams A Companion for ScrumMasters Agile Co aches and Project Managers in Trans
194. vemos dar prefer ncia para m tricas globais em vez de m tricas locais 8 Para melhor ilustrar esse conceito imagine que determinada empresa terceiriza os testes dos softwares que desenvolve e que a empresa terceirizada recebe por de feito encontrado no sistema Espera se ent o que todos os defeitos sejam identifica dos pela empresa terceirizada antes que o software entre em produ o Entretanto quando um defeito for encontrado provavelmente a empresa terceira n o ir cola borar devidamente com a equipe que desenvolveu o software para que defeitos de mesma natureza n o voltem a ocorrer porque n o de seu interesse que a quanti dade de defeitos diminua Se os defeitos forem encontrados e resolvidos antes do software ir para produ o ent o a m trica deve apresentar um bom resultado e pode se vir a pensar que as coisas est o indo bem mas na verdade n o est se considerando a real causa do defeito e o problema n o est sendo resolvido em sua raiz O objetivo otimizar o processo da cadeia de valor como um todo e n o em cada etapa do processo isoladamente 6 1 A GEST O PODE SER GIL Aqueles que n o fazem acontecer n o s o nem gerentes nem l deres Johanna Rothman e Esther Derby Muitas pessoas acreditam que a gest o n o importa e que bons t cnicos v o produzir bons resultados independente da qualidade da gest o Johanna Rothman e Esther Derby discordam disso Para elas os bons gestores atingem
195. versas atividades e relacionamentos existentes no processo de desenvolvimento Quanto mais r pido e frequente for o feedback mais r pido pode se responder corrigir e melhorar Existem algumas pr ticas e ferramentas que podem ajudar as pessoas a dar e receber feedback A seguir estudaremos algumas delas Reuni es One on ones conhecendo o time Para liderar pessoas preciso conhec las bem Cada pessoa nica e possuir diferentes desejos pontos fortes e fracos Um bom gestor precisar saber quem s o as pessoas seus pontos fortes fracos e interesses e em que est o trabalhando qual a miss o da equipe e de que forma ela agrega valor e como as equipes se encaixam na organiza o como um todo As reuni es one on ones basicamente s o oportunidades em que o gestor se re ne com cada membro da equipe um a um para conversar e perguntar coisas como 126 Casa do C digo Cap tulo 6 Otimizando o Sistema e Como as coisas est o e Como seu projeto est indo e O que voc mais gosta no seu trabalho e Quais s o os aspectos mais frustrantes e Voc poderia me falar mais a respeito de Reuni es One on ones realizadas da forma correta constroem bons relaciona mentos Gestores que fazem essas reuni es com frequ ncia muitas vezes as consi deram um dos melhores usos de seu tempo e uma ferramenta primordial As one on ones podem ajudar sua equipe a saber o que voc espera deles al m de criar um canal par
196. zer o cliente para perto da equipe o cliente faz parte do projeto e tem um papel muito importante para que o projeto seja bem sucedido A nica coisa constante a mudan a Her clito de feso Finalmente responder a mudan as mais importante do que seguir um plano diz respeito essencialmente capacidade de adapta o que uma equipe gil precisa possuir Planejar preciso mas planos n o precisam ser escritos em pedras eles podem ser apagados corrigidos refeitos A capacidade de adaptar se em um mundo em constante mudan a uma quali dade essencial entregar projetos relevantes e bem sucedidos 1 4 BENEF CIOS DOS M TODOS GEIS Uma das maiores motiva es para a transi o para m todos s o os benef cios que s o trazidos para a organiza o devido ao valor que agregado ao cliente com qua 1 4 Benef cios dos M todos geis Casa do C digo lidade e velocidade 63 M todos geis ajudam organiza es a responder mais rapi damente s necessidades do mercado muitas vezes resultando em grande vantagem competitiva Uma pesquisa realizada pela VersionOne com em 2011 65 envolveu mais de 6 000 pessoas e organiza es dos mais variados perfis na industria de desenvolvi mento de software Ela nos mostra alguns dos principais benef cios obtidos por essas organiza es ap s a transi o par m todos geis Os principais benef cios s o e Melhor Time to market e Maior Retorno s

agile - desenvolvimento de software com entregas frequentes e foco

Contents

Download Pdf Manuals

Related Search

Related Contents