CENTRO UNIVERSITRIO UNA DIRETORIA DE EDUCAO CONTINUADA, PESQUISA E EXTENSO CURSO DE PS-GRADUAO EM ENGENHARIA DE SOFTWARE CENTRADA EM MTODOS GEIS

ROTEIRO DE APOIO IMPLEMENTAO DA AGILIDADE

ALUNA: Juliana Villas Bas Fonseca PROFESSOR ORIENTADOR: Edgard Davidson

BELO HORIZONTE 2011/2 SEMESTRE

Sumrio 1. Resumo .............................................................................................................................. 1 2. Introduo .......................................................................................................................... 1 3. Referencial terico .............................................................................................................. 2 3.1 Por onde comear? ........................................................................................................ 2 3.1.1 O que Agilidade?.................................................................................................. 2 3.1.2 Diferena entre Mtodo e Prtica gil ...................................................................... 3 3.1.3 Caractersticas para um mtodo ser considerado gil ................................................ 4 3.2 Prticas geis: viso geral .............................................................................................. 4 4. Procedimentos metodolgicos ............................................................................................. 5 5. Anlise dos dados ............................................................................................................... 5 5.1 Tipos de problema ......................................................................................................... 5 5.1.1 Gesto .................................................................................................................... 6 5.1.2 Engenharia.............................................................................................................. 6 5.2 Quando optar pela agilidade? ......................................................................................... 7 5.3 Questionrio de check-lists ............................................................................................ 7 5.3.1 Check list para problemas relacionados gesto .................................................... 8 5.3.2 Check list para problemas relacionados engenharia............................................ 11 6. Consideraes finais ......................................................................................................... 14 7. Bibliografia ...................................................................................................................... 15

1. Resumo Diante de tantos mtodos e prticas geis atualmente disponveis, quais implementar? Como escolher? Por onde comear? O que no fazer? Ser que a agilidade til para o negcio? Estas so algumas questes que este artigo busca responder. Primeiro, traz o conceito de agilidade, explicitando a diferena entre mtodo e prtica gil, bem como as caractersticas para um mtodo ser considerado gil. Em seguida, apresenta uma viso geral sobre as prticas hoje existentes. A anlise dos dados consiste na compreenso dos dois tipos de problema que podem ser encontrados em um cenrio: gesto e engenharia. Para isso, o conceito de dbito tcnico apresentado. Passa-se, ento, a uma breve reflexo sobre a adoo da agilidade. No final do artigo, dois questionrios em forma de check-lists so oferecidos para preenchimento. Eles iro auxiliar o leitor na percepo de falhas cotidianas presentes no cenrio onde atua, bem como suas possveis solues. Busca-se, com esta interatividade, um direcionamento consistente na implementao da agilidade s inmeras realidades empresariais possveis. Isto significa a j conquistada liberdade na adoo das prticas geis, porm aliada segurana, confiana e, consequentemente, uma maior efetividade na conduo de projetos geis. Palavras-chave: roteiro, personalizado, implementao, agilidade.

2. Introduo Mtodos e prticas geis no so novidade. Surgido em fevereiro de 2001, o Manifesto gil trouxe consigo os pilares desta abordagem. Segundo o State of Agile Survey (2010), atualmente 86% das empresas adotam a agilidade em seus projetos. Contudo, a dificuldade das organizaes em implantar a agilidade recorrente. Fruto da disseminao dos mtodos tradicionais no decorrer dos ltimos 40 anos, problemas como falta de apoio dos nveis superiores, de parceria com os clientes e de puro desconhecimento das tcnicas so obstculos comumente observados. Para se ter resultado, preciso ir alm do rompimento com a famosa barreira cultural. O insucesso ocorre ora porque o problema no foi entendido corretamente, ora porque a equipe no

est devidamente capacitada, ou ainda por se optar pela implantao de algo que esteja na moda no momento. Diante deste cenrio, importante investigar as necessidades das organizaes, bem como suas dificuldades. Saber se a agilidade a melhor escolha e, caso positivo, tentar guiar as empresas para as melhores opes e combinaes na implantao de mtodos e prticas geis.

3. Referencial terico

3.1 Por onde comear?

Uma caixa de ferramentas.

assim que costumam ser vistos os processos geis.

Diferentemente de seus antecessores preditivos e iterativos, a agilidade no prega uma sequncia de utilizao de suas tcnicas. So empricos e adaptativos. Uma viso de liberdade, mas que tambm pode trazer a sensao de perda de foco. Muitos so os mtodos e, principalmente, as prticas. Modismos parte, cada qual tem seus pontos positivos, como tambm suas deficincias. Ento, como agir? Por onde comear? o que este artigo se prope a responder. Comecemos por entender o conceito de Agilidade.

3.1.1 O que Agilidade?

No final dos anos 90, algumas metodologias comearam a chamar a ateno das pessoas. Cada qual com uma combinao diferente de ideias. Mas todas elas destacavam certos pontos, como a colaborao entre desenvolvedores e clientes, a comunicao direta e times encarando o processo de forma que mudanas nos requisitos no significassem um problema. Em fevereiro de 2001, o Manifesto gil veio firmar este consenso, formalizando-os atravs de seus doze princpios. Surgia, assim, o conceito de Agilidade.

3.1.2 Diferena entre Mtodo e Prtica gil

Mtodo gil um processo ou capacidade no qual os agentes humanos, atravs de mudanas sensveis e contextos dinamicamente interligados, determinam uma abordagem de desenvolvimento de um sistema para um projeto especfico (AYDIN, M. N. Harmsen et al., 2004). Eles se diferenciam dos mtodos convencionais basicamente por serem adaptativos (ao invs de preditivos) e orientados a pessoas (ao invs de orientados a processos) (FOWLER, Martin, 2003). J as prticas geis so atividades concretas, as quais fazem parte de um dado mtodo. Um mtodo pode possuir N prticas geis. Uma prtica, por sua vez, pode pertencer a N mtodos.

Mtodos geis

Prticas geis

3.2 Mtodos geis: viso geral Os mtodos ditos geis visam reduzir o ciclo de vida do software (e por conseguinte acelerar seu desenvolvimento) atravs da criao de uma verso mnima, integrando seguidamente as funcionalidades atravs de um processo iterativo, baseado na escuta do cliente e testes ao longo de todo o ciclo de desenvolvimento. Tem como origem a instabilidade do ambiente tecnolgico e do fato de o cliente estar frequentemente incapacitado de definir suas necessidades de maneira exaustiva no incio do projeto. O termo gil no significa simplesmente o desenvolvimento rpido de aplicaes, mas principalmente a capacidade de adaptao com rapidez e flexibilidade s mudanas nos processos, produtos e no ambiente. Ao adotar um mtodo gil, o cliente inteiramente o coordenador de seu projeto. Isto faz com que as primeiras entregas correspondam quilo que representa mais valor para a organizao.

3.1.3 Caractersticas para um mtodo ser considerado gil

Segundo ABRANTES (2007), para ser considerado gil, um mtodo deve possuir certas caractersticas. Abaixo, as cinco principais, por ordem de importncia: Caracterstica Adaptabilidade Interpretao Adaptar-se rapidamente ao processo, reagindo a mudanas de ltima hora ou a situaes de risco no previstas. No tentar construir o sistema todo de uma s vez. Ao invs disso, Incrementabilidade dividi-lo em incrementos, que podem ser desenvolvidas em paralelo em ciclos rpidos. Quando o incremento completado e testado, ele integrado ao sistema. Iteratividade Colaboratividade Envolver vrios ciclos curtos, dirigidos por caractersticas do produto, nos quais as atividades so completadas em poucas semanas. Encorajar a comunicao para disseminao da informao e apoiar a integrao rpida de incrementos. Realizar a interao aberta e prxima entre os stakeholders, tornando o Cooperao cliente parte ativa do processo e prover feedback de forma regular e frequente.

3.2 Prticas geis: viso geral

As prticas geis so atividades e produtos concretos que fazem parte de um mtodo. No entanto, elas possuem a capacidade de se estender atravs dos mtodos, sendo adaptveis realidade de cada projeto. (AYDIN, 2004). A adoo parcial das prticas, como sugerido por BECK (2001), tem sido relatada em vrias ocasies. Tal adoo requer adaptao, sendo que o pressuposto fundamental por trs deste conceito que o escopo de um projeto nunca permanece o mesmo do incio ao final. Dada esta definio, mapas de rotas podem ser utilizados para saber quais prticas adotar para um projeto particular. Obviamente, em um cenrio cujo contexto emergente, mapas de rotas do tipo prescritivo no so indicados, pois muitas vezes preciso modificar ou at mesmo inovar nas prticas durante a execuo de um projeto (AYDIN ET AL., 2005).

4. Procedimentos metodolgicos

O estudo teve como motivao uma necessidade real, identificada diante do primeiro projeto com chances de ser gil. A pesquisa foi iniciada a partir do estudo do State of Agile Survey (2010), tendo como base a situao atual dos projetos considerados geis. Posteriormente, foi feito um levantamento sobre mtodos e prticas geis, incluindo as caractersticas para que um mtodo seja considerado gil, sua permeabilidade com as prticas e quando a agilidade (ou no) a melhor opo. O resultado desta pesquisa norteou a diviso entre os dois tipos de problemas encontrados (gesto e engenharia). A partir desta viso, vislumbrou-se os questionrios com check-lists. A verso 2.1 do Scrum Checklist (2009) contribuiu no formato destes questionrios, os quais compreendem a essncia do artigo.

5. Anlise dos dados 5.1 Tipos de problema

Abordaremos dois principais tipos de problema. Mas, antes, importante conhecer o significado do termo dbito tcnico: Voc tem parte de uma funcionalidade a ser adicionada ao sistema. Voc v duas maneiras de faz-lo: um rpido, mas confuso e de difcil manuteno futura. O outro tem design mais limpo, mas vai demorar mais tempo. Fazer as coisas de maneira rpida e suja cria um dbito tcnico (...). H um esforo extra no futuro por causa desta escolha. Podemos optar por continuar pagando os juros, ou refatorar o projeto para melhorar o design. (FOWLER, Martin, 2009) Dependendo da sua origem, um dbito tcnico pode estar relacionado gesto ou engenharia.

5.1.1 Gesto

Se desenvolver um sistema no algo simples, geri-lo algo ainda menos simples. Pesquisas mostram que 45% das causas de atrasos na entrega de projetos esto relacionadas a falhas na gesto. De acordo com um estudo recente feito pelo Project Management Institute PMI, mais de 50% dos problemas encontrados em projetos esto relacionados a mudanas constantes no escopo ou a no definio correta do mesmo. Outro problema frequentemente identificado (45%) com relao limitao dos recursos e envolvimento dos mesmos em mais de um projeto simultaneamente. Alm disso, o desconhecimento de um gerenciamento eficaz dos riscos contribui para a falta de estabilidade do projeto. De uma maneira geral, os desafios inerentes aos problemas de gesto esto associados a: Viso incorreta e/ou muito otimista do cenrio; Falha nas estimativas de valor/tempo de desenvolvimento; Constantes mudanas nos requisitos; Presses externas.

5.1.2 Engenharia

No que tange engenharia, podemos ver um projeto de software como a aplicao de uma abordagem sistemtica, disciplinada e quantificvel, tanto para desenvolvimento quanto para operao e manuteno de sistemas, alm do estudo destas abordagens. (ABRAN, Alain, 2004). Estudos demonstram que a incapacidade de atingir metas um dos fatores de insucesso dentre os projetos. Segundo BELL (2007), um dos maiores desafios em engenharia de software reside no acompanhamento das mudanas dos requisitos, os quais so alterados na velocidade das mentes dos clientes. Outros problemas conhecidos: Prazos subestimados (viso romntica do projeto); Desconhecimento dos riscos; Falta de nivelamento de conhecimento tcnico;

Resistncia a novas formas de se trabalhar (Ex.: TDD1); Falta de comunicao entre os membros da equipe. Consequentemente, problemas deste tipo fazem com que seja alta a rotatividade entre os

desenvolvedores, o que piora ainda mais o cenrio.

5.2 Quando optar pela agilidade? Nem sempre a agilidade parece ser a melhor opo na hora de se adotar um mtodo de desenvolvimento de sistemas. Nesta escolha, alguns pontos devem ser considerados. Se o cenrio apresenta requisitos incertos (ou volteis), voc conta com uma equipe responsvel e motivada e com cliente se dispondo a ser o dono do produto (product owner)2, estes so indcios que a agilidade pode ser uma boa opo. Por outro lado, se o projeto de preo e/ou escopo fixo, a equipe de desenvolvimento tem mais de cem pessoas ou a cultura organizacional da empresa do tipo de comando-controle, estes so indcios de que talvez seja melhor optar por um mtodo tradicional.

5.3 Questionrio de check-lists A seguir, dois questionrios auxiliam na identificao falhas no desenvolvimento de sistemas. O primeiro se refere a prticas para soluo de problemas de gesto. J o segundo, de engenharia. Os questionrios so compostos por check-lists, que devero ser marcados de acordo com a aplicao das prticas. Cada bloco de check-list contempla, alm da marcao principal, trs secundrias, que representam suas caractersticas fundamentais. Marcar uma ou duas opes secundrias significa que a prtica parcialmente adotada e deve ser revista, a fim de prevenir futuras lacunas que comprometam a sua qualidade. Os termos em negrito nas marcaes principais indicam a prtica correspondente. Os anexos deste artigo contm uma breve descrio de cada prtica, na ordem de apresentao dos check-lists. Utilize-os como referncia.
1 2

Vide anexo item 8.1 Vide anexo item 8.2

5.3.1 Check list para problemas relacionados gesto O ambiente de trabalho compartilhado A maior parte do espao livre Promove a comunicao rpida e sem rudos entre os membros do time H um espao para conversas particulares As causas dos problemas so identificadas, analisadas e combatidas So feitos brainstormings peridicos para levantamento No h a cultura de apagar incndios Problemas futuros so prevenidos O backlog da iterao (sprint backlog) obtido do backlog do produto Contm os itens de maior ordem/prioridade O time de desenvolvimento estima o tempo de cada item Devido aos imprevistos, no ocupa 100% do tempo da sprint O backlog do produto (product backlog) possui as funcionalidades do sistema Serve de guia para o trabalho da equipe de desenvolvimento Seus itens so ordenados, de acordo com o valor para o negcio constantemente atualizado pelo dono do produto (product owner) As metas so claras para a equipe O foco no resultado final (no nas estratgias) O status da meta acompanhado at a concluso A equipe prov feedback das metas alcanadas Os itens do backlog do produto tem definio de pronto Ambas as definies (tanto de Ready quanto de Done) existem. So feitas em conjunto com o dono do produto (product owner). Aparecem em local visvel para a equipe H o papel do dono do produto (product owner) Mantm atualizado o product backlog Participa ativamente das cerimnias disponvel para tirar dvidas, quando solicitado pela equipe A equipe de desenvolvimento auto organizada Os membros so altamente comprometidos com os resultados No h um gerente de projeto Todas as cerimnias da metodologia adotada so cumpridas A escalabilidade aplicada em projetos de maior porte H coordenao efetiva do time como um todo As habilidades so bem distribudas entre os pequenos times Os times se comunicam entre si

As estrias de usurio (user stories) so usadas para guiar o desenvolvimento Seguem o formato eu, como <papel>, desejo <caracterstica>, para <motivo> Possuem requisitos de aceitao para valid-las As de requisitos funcionais geralmente so escritas pelo cliente O grfico de burndown (burndown chart) reflete o trabalho da equipe atualizado constantemente atualizado pelo time Possui visualizao restrita ao time de desenvolvimento Impedimentos visveis so comunicados e resolvidos Em tempo hbil pelo Scrum Master Quando do mesmo tipo, se repetem com menor frequncia H colaborao do time na resoluo Os itens de backlog do produto (product backlog items) esto presentes no projeto Do origem s estrias de usurio So analisados quanto ao nvel de granulao So discutidos com o dono do produto (product owner) O projeto desenvolvido em iteraes (sprints) A primeira iterao possui itens de base e de menor dependncia dos demais Cada iterao possui fases que vo do levantamento de requisitos implantao A equipe aplica na iterao atual o que foi aprendido nas anteriores O planejamento de iteraes corretamente realizado O dono do produto (product owner) tira dvidas na reunio O dono do produto no discute a forma como o trabalho ser feito Nenhuma iterao iniciada sem um planejamento prvio Os requisitos so priorizados pelo dono do produto (product owner) Antes da reunio de planejamento da iterao O dono do produto reorganiza continuamente os requisitos Requisitos que dependem de outros so discutidos com o time O quadro de tarefas (Kanban) auxilia a equipe de desenvolvimento A equipe o mantm atualizado/organizado H um espao para registro de itens no planejados H um espao para registro de impedimentos Aps a reunio de reviso, feita a reunio de retrospectiva Todo o time participa Crticas e sugestes de melhoria so documentadas definida a soluo de pelo menos o principal problema atualmente enfrentado

10

Terminada a iterao, feita a reunio de reviso O time apresenta o trabalho e coleta feedbacks (no o Scrum Master) O time entrega o valor definido para a iterao Junto com o dono do produto, detalhado e discutido o que no foi completado A reunio diria habitual No ultrapassa 15 minutos Geralmente ocorre no mesmo lugar e horrio Cada membro responde fala sobre o que foi feito, o que no foi e impedimentos O time possui um ritmo sustentvel de trabalho Raramente faz horas extras H motivao no ambiente de trabalho A mdia semanal de 40 horas trabalhadas O Scrum Master faz parte do time Remove impedimentos encontrados pelo time Blinda o time contra interferncias externas Certifica que as regras e cerimnias adotadas pela metodologia sejam seguidas O time multidisciplinar Possuem diferentes expertises Possuem diferentes nveis de habilidade So altamente comprometidos com a meta O time tem sua velocidade obtida Aps as primeiras trs iteraes Varia de acordo com o projeto utilizada para estimar as futuras iteraes A viso do produto (product vision) clara para o time Descreve o projeto em alto nvel (sem detalhamento) Possui caractersticas de qualidade desejada feita vrias vezes durante o projeto, evitando o desvio da meta

11

5.3.2 Check list para problemas relacionados engenharia O build automatizado O processo feito regularmente Gera notificao de sucesso ou falha Os logs so usados na investigao de problemas Classes so identificadas com cartes CRC Todo o time participa da criao dos cartes Focam o essencial, sem aprofundar nos detalhes Auxilia cada classe a ter um nico contrato utilizado cdigo coletivo H um compromisso conjunto para construir bons cdigos Os problemas so sempre corrigidos, no importando onde esto Um desenvolvedor melhora o cdigo feito por outro O cdigo escrito limpo fcil de compreender No repetitivo Cada classe possui uma nica responsabilidade feito o controle de verso O histrico pode ser rigorosamente controlado H marcao da ltima verso estvel Vrias linhas de desenvolvimento podem ser trabalhadas em paralelo O desenho do sistema guiado pelo domnio do negcio O desenvolvedor busca entender plenamente o negcio A modelagem feita leva a questionamentos e sugestes para o negcio O cdigo se mostra menos acoplado e mais coeso O desenvolvimento do sistema guiado pelo comportamento do usurio O desenvolvimento se inicia pela interface priorizada a linguagem no-tcnica na comunicao com o cliente Desenhos de tela (mock-ups, wireframes) so amplamente utilizados A codificao do sistema guiada por testes Testes so escritos antes do cdigo propriamente dito Primeiramente, o cdigo escrito para passar no teste Depois de passar no teste, o cdigo ento refinado

12

H a entrega frequente de valor para o cliente entregue software testado e funcionando O intervalo varia de uma a quatro semanas H um registro do que entregue A integrao contnua adotada Erros so detectados rapidamente atravs do build automatizado Erros so imediatamente corrigidos, assim que detectados Cada membro do time integra pelo menos uma vez ao dia O sistema possui uma boa metfora Todos os objetos tem nomes consistentes Novos desenvolvedores compreendem o sistema rapidamente e sem esforo O cdigo plenamente reutilizvel Um padro de codificao seguido Se for lido aps um ms, compreendido sem a necessidade de ler cada linha comentado e endentado de forma clara No so utilizadas frases rpidas de escrever, complexas e sem legibilidade Personas so usadas para levantar as necessidades dos usurios Capturam a essncia do tipo de usurio do sistema Possuem objetivos que o sistema dever atender Os resultados so realistas (sem esteretipos) As estrias de usurio so estimadas com poker do planejamento (planning poker) Todo o time participa Feito logo que o backlog do produto (product backlog) criado ou atualizado O menor e maior valor estimados so justificados para chegar a um consenso Os programadores desenvolvem utilizando programao em par Enquanto um programador digita o cdigo, o outro faz o papel de observador Os papis so alternados com frequncia Ambos os programadores so altamente concentrados no cdigo O cdigo melhorado atravs da refatorao Os testes participam do processo, garantindo o comportamento externo intacto No existe cdigo duplicado Mtodos e classes tem contexto sucinto

13

Aps a fase inicial de desenvolvimento, o cdigo passa por reviso Erros so descobertos e corrigidos A reviso feita pelos prprios desenvolvedores Se necessrio, revisores externos so solicitados para auxiliar So feitos testes de aceitao Pelo usurio final do software Simulando operaes de rotina O feedback do cliente documentado So feitos testes de fumaa Como testes preliminares (antes dos demais testes) Somente as principais funcionalidades so testadas No h preocupao com condies de erro A combinao dos mdulos testada atravs de testes de integrao Feitos aps os testes de unidade Falhas na transmisso dos dados entre os componentes so apontadas Dependendo do escopo, feito por etapas Os testes de sistema so efetuados Em ambiente similar ao ambiente final Focando as regras de negcio Falhas nos testes so documentadas Os testes unitrios so feitos Pelos prprios desenvolvedores De forma iterativa, na medida em que se desenvolve o cdigo Com o auxlio de ferramentas especficas

14

6. Consideraes finais No existe um roteiro trivial para implementao da agilidade. Tal existncia

engessaria o processo, tornando-o similar aos modelos preditivos. Ao mesmo tempo, a ideia de uma caixa de ferramentas trazida pela agilidade assusta primeira vista: j que inmeros mtodos (e principalmente prticas) esto disponveis, ento como decidir? O roteiro de apoio implementao da agilidade proposto por este trabalho buscou o meio-termo. Pensado no formato de check-lists focados nas prticas geis, possibilitou um resultado personalizado. Isto se deve forma com que foi imaginado, ou seja, partindo-se do ponto de vista das falhas de cada cenrio e de suas realidades em si, ao invs de enfocar, simples e cegamente, nas vantagens oferecidas por cada prtica. Alm disso, a marcao parcial de um check-list foi capaz de apontar brechas em procedimentos que at ento tinham sido vistos como plenamente implantados. Acredito que o artigo traga ganhos para o mercado de trabalho, uma vez que notada a necessidade de um guia deste tipo por parte dos profissionais que hoje buscam implantar ou adequar seus processos s premissas geis.

15

7. Bibliografia ABRANTES, Jos Fortuna. TRAVASSOS, Guilherme Horta. Caracterizao de Mtodos geis de Desenvolvimento de Software. Rio de Janeiro, RJ: Universidade Federal do Rio de Janeiro, 2006. AYDIN, M. N. Harmsen, F. Slooten, K. v. & Stagwee, R. A. An Agile Information System Development Method in use. Wikipedia, 2004. Disponvel em: <http://en.wikipedia.org/wiki/Agile_software_development>. Acesso em: 07 set. 2011. BECK. Kent, THOMAS. Dave, SUTHERLAND, Jeff et al. Manifesto for Agile Software Development, 2001. Disponvel em: <http://www.agilemanifesto.org/>. Acesso em: 12 out. 2011. BELL, Peter. The Two Biggest Problems in Software Engineering. Application Generation. Disponvel em: <http://www.pbell.com/index.cfm/2007/1/5/The-Two-BiggestProblems-in-Software-Engineering>. Acesso em: 07 out. 2011. COLLNS, Dan. Characteristics of a good team and a team member. The Team Building Directory. Disponvel em: <http://www.innovativeteambuilding.co.uk/pages/articles/ characteristics.htm>. Acesso em: 12 out. 2011. FARIA, Andr. Lista com todas as prticas geis. Blog do Andr Faria, 2010. Disponvel em: <http://blog.andrefaria.com/lista-com-todas-as-praticas-ageis>. Acesso em: 03 ago. 2011. FOWLER, Martin. TechnicalDebt. Martin Fowlers Website, 2009. Disponvel em: <http://martinfowler.com/bliki/TechnicalDebt.html>. Acesso em: 12 out. 2011. FOWLER, Martin. The New Methodology. Martin Fowlers Website, 2009. Disponvel em: <http://martinfowler.com/articles/NewMethodology.html>. Acesso em: 12 out. 2011. FOWLER, Martin. The New Methodology. Martin Fowlers Website, 2009. Disponvel em: <http://martinfowler.com/articles/NewMethodology.html>. Acesso em: 12 out. 2011. NIELSEN, Jacob. Agile Usability: Best Practices for User Experience on Agile Development Projects. Strategies to enhance the user experience. Disponvel em: <http://www.nngroup.com/reports/agile/>. Acesso em 12 ago. 2011. SCHWABER, Ken. SUTHERLAND, Jeff. O Guia do Scrum. Disponvel em <http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf>. Acesso em 15 set. 2011. VERSION ONE. State of Agile Survey. 5. Ed. Atlanta-GA, EUA, 2010. 10p.

8. Anexos

8.1 Anexo I - Prticas geis relacionadas gesto

Ambiente de trabalho compartilhado (Collocated team / Sitting together / Common Workspace): um ambiente projetado para promover a comunicao rpida e sem rudos entre os membros da equipe. Estaes de trabalho so dispostas em um ambiente aberto (sem divisrias). Um quadro branco indispensvel. Deve haver um espao para objetos pessoais, bem como para conversas particulares.

Anlise de causa raiz (Root cause analysis / 5 Whys): objetiva a identificao da(s) causa(s) de um problema e consequentemente a reduo do retrabalho nos problemas existentes (apagar incndios). Dentre as tcnicas existentes, destaca-se o diagrama de causa e efeito, os cinco porqus (5 Whys) e as reunies de brainstorming.

Backlog da iterao (Sprint backlog): lista dos requisitos que devero ser implementados na sprint, mediante estimativa prvia de tempo feita pelo time. Possui os itens de maior ordem do backlog do produto (product backlog) e cujo tempo de desenvolvimento cabe na sprint. Deve haver uma sobra de tempo para imprevistos.

Backlog do produto (Product backlog): lista de itens que o sistema dever ter para que a viso do PO seja transformada em produto propriamente dito. consequentes alteraes nas necessidades. nico em todo o projeto, regularmente atualizado pelo PO, de forma a refletir as mudanas inerentes ao negcio e suas

Definio de metas (Goal setting): prov senso de direo e propsito equipe. Garante que os membros do time com um objetivo comum estejam cientes do que se espera deles. Engloba a tcnica SMART, na qual as metas devem ser especficas (Specific), mensurveis (Mensurable), atingveis (Attainable), realizveis (Realistic) e rastreveis (Trackable).

Definies de pronto (Ready / Done): so diferentes. A definio de Ready se refere a caractersticas que um item dever ter para entrar numa iterao (sprint). Pode-se dizer, por exemplo, que este dever ser tecnicamente vivel e testvel. J a definio de Done diz respeito a caractersticas para um item ser encarado como pronto. Ele dever estar documentado, testado e sem problemas, por exemplo.

Dono do produto / Cliente interno (Product Owner / On-site customer): a voz do cliente. Define e ordena as funcionalidades do projeto, de acordo com o valor para o negcio. Inspeciona o que entregue e faz as adaptaes necessrias. Comunica o andamento do projeto para os demais interessados. o responsvel pelo sucesso (ou insucesso) do projeto.

Equipes auto organizadas (Self-organizing teams / Scrum teams): neste tipo de equipe o compromisso com o cliente firmado pelo time, e no pelo gerente do projeto. So formadas por pessoas altamente comprometidas. Cientes do prazo de entrega, sabem estimar o tempo e decidem a melhor forma de fazer o trabalho. O feedback ocorre internamente, bem como diretamente com o dono do produto (product owner).

Escalabilidade (Scrum of scrums): uma forma de assegurar a coordenao de diferentes times que, juntos, formam um grande time Scrum, em torno de um mesmo objetivo e trabalhando simultaneamente. Nesta abordagem, cada time atua normalmente, mas tambm contribui com uma pessoa para assistir s reunies do time maior. Estrias de usurio (User stories): so frases que guiam o desenvolvimento de software. De linguagem no-tcnica, captam o que o usurio deseja alcanar com o sistema, bem como requisitos no-funcionais. Um procedimento de aceitao deve ser escrito pelo usurio para garantir que o que foi pedido foi cumprido, aps a implementao.

Grfico de Burndown (Burndown charts): mede o trabalho restante da sprint ao longo do tempo. Representa a combinao do tempo restante para a sprint e o nmero de tarefas que faltam ser feitas. Inerente ao trabalho da equipe de desenvolvimento, no deve ser mostrado para o dono do produto (product owner).

Impedimentos visveis: so bloqueios no andamento das atividades. Problemas tcnicos ou de desconhecimento de uma linguagem de programao so alguns exemplos. Devem ser ditos na reunio diria (daily meeting) e anotados pelo Scrum Master, para que este possa providenciar a remoo. importante saber o qu precisa ser feito, quem o far e quando ir comunicar o resultado. Item do backlog do produto (Product backlog item): um item do product backlog quebrado em estrias, e estas em tarefas. A reduo na granulao de um item ajuda a estim-lo, facilitando a escolha do que entrar (ou no) na sprint. Iteraes (Sprints / Fixed sprints / Timeboxing / Fixed iteration length): so perodos cclicos e fixos de tempo pr-determinado, nos quais as atividades para desenvolvimento do projeto so alocadas, divididas nas fases de levantamento de requisitos, modelagem de dados, anlise, design, desenvolvimento, testes e implantao. oramento e prazo de entrega. Cada iterao tem seu prprio contedo,

Planejamento de iteraes (Sprint planning / Iteration planning / Planning game): reunio de duas etapas. Na primeira determina-se o que fazer na prxima iterao. O resultado o backlog da iterao (sprint backlog). Na segunda etapa discutida a forma como o trabalho ser feito. O dono do produto (product owner) deve estar presente para esclarecer dvidas e tomar decises quanto ao design da aplicao. Priorizao de requisitos (Requirement Prioritization): a primeira priorizao (ou ordenao) do backlog do produto (product backlog) deve ser feita antes da reunio de planejamento da iterao, pelo dono do produto (product owner). No decorrer do projeto, os requisitos so reorganizados, de acordo com surgimento de novos ou implementao dos existentes (Backlog Gromming). Quadro de tarefas (Task board / Kanban board):tambm conhecido como Kanban, um quadro onde as tarefas so expostas, divididas nas colunas a fazer, em andamento e feitas. Pode conter o grfico de burndown (burndown chart). uma excelente ferramenta de visibilidade, d transparncia e, por ser fsica, exerce uma presso positiva sobre o trabalho do time. Reunio de retrospectiva (Sprint retrospective / Reflection workshop): feita aps a reunio de reviso, discute e documenta o processo de melhoria contnua. Nela, o time inspeciona como foi a ltima iterao (sprint), relacionando o que deu certo e o que pode melhorar. Todo o time participa, incluindo o dono do produto (product owner) e o Scrum Master. Reunio de reviso ou de demonstrao (Sprint Review / Iteration Demo): cerimnia feita no final de uma iterao (sprint), onde o trabalho feito apresentado pelo time e inspecionado pelo dono do produto (product owner). onde ocorre a adaptao do processo emprico, pois cada membro colabora com seu ponto de vista para melhoria deste processo. Reunio diria (Daily stand-up meeting / Daily Scrum):com durao de 15 minutos, o momento no qual cada membro do time responde a trs perguntas: 1) O que fiz ontem? 2) O que farei hoje? 3) Quais so os impedimentos? Promove o alinhamento entre as ideias e aes do time. O Scrum Master pode ou no participar.

Ritmo sustentvel (Sustainable pace): trabalhar alm do tempo previsto diminui a motivao do time e, consequentemente, a qualidade do projeto. Planos realistas devem envolver um ritmo sustentvel de produo. Isto ir auxiliar na identificao da velocidade da equipe. Alm disso, importante manter o ambiente de trabalho energizado, ou seja, pessoas constantemente motivadas. Scrum Master: remove barreiras entre o time de desenvolvimento e o dono do produto (product owner). Para que o dono do produto guie diretamente o projeto, sugere a ele como fazer as escolhas certas para maximizar o ROI. Alm disso, busca melhorar o ambiente de desenvolvimento do time, bem como as prticas e ferramentas de engenharia adotadas pelo mesmo. responsvel pelo seguimento das regras do SCRUM, alm de blindar o time contra interferncias externas. Times multidisciplinares (Cross-functional teams): composto por 5 a 9 integrantes com diferentes expertises e nveis de habilidade, em torno de um mesmo objetivo. Para compor um time multidisciplinar, busca-se tambm pessoas comunicativas e organizadas. Velocidade (Velocity): nmero mdio de itens que o time consegue entregar numa iterao. Cada time tem sua velocidade. Uma forma de estim-la atravs da visualizao de iteraes anteriores, desde que a composio do time e a durao da iterao sejam constantes.

Viso do produto (Product Vision / Vision Statement): mostra os objetivos do produto para o qual o projeto est sendo feito. Deve ser feita pelo gerente de produto. Sua informao primria uma relao de requisitos de negcio e possui as caractersticas de qualidade desejada.

8.2 Anexo II - Prticas geis relacionadas engenharia

Build automatizado (Automated builds / Daily builds / Ten-minute builds): processo no qual as tarefas referentes integrao dos pacotes desenvolvidos feita de forma automtica, ou seja, sem a interferncia do desenvolvedor. Normalmente usado no processo de Integrao Contnua e quando existem vrios desenvolvedores trabalhando na mesma aplicao (vide Controle de verso). Cartes CRC (Class Responsability Collaborator Cards): tcnica de brainstorming para definir o desenho de uma aplicao, na qual cartes so produzidos, cada um contendo uma classe, suas propriedades (mtodos e atributos) e associaes.

Cdigo coletivo (Collective Code Ownership):conceito no qual qualquer cdigo do projeto pertence ao time como um todo, e no a um desenvolvedor especfico. Assim, todos podem fazer alteraes, bem como resolver problemas. Desta forma, todos tem responsabilidade para com a qualidade do cdigo. Cdigo limpo (Clean code):o cdigo desenvolvido usando-se nomenclaturas coerentes para variveis, mtodos, etc. fcil de ser compreendido por outro desenvolvedor, no precisando ser comentado ou reescrito. Alm disso, no repetitivo e cada classe possui uma nica responsabilidade. Controle de verso (Version control / Source control): feita por um software especfico, permite gerenciar diferentes verses de arquivos guardados em um repositrio. Cada desenvolvedor possui uma cpia local somente a ltima verso de cada arquivo. A cada alterao relevante, preciso atualizar as informaes do servidor, que guarda ento a nova alterao, juntamente

com todo o histrico mais antigo. Para atualizar sua cpia local, o desenvolvedor deve baixar as novidades do servidor. Desenho guiado pelo domnio (DDD Domain Driven Design): abordagem de desenho de software que rene um conjunto de conceitos, tcnicas e princpios com foco no domnio e na lgica do domnio para criar um modelo de domnio (domain model) Desenvolvimento guiado pelo comportamento (BDD Behaviour Driven Development): processo de desenvolvimento de software de fora para dentro, no qual o cliente responde o que espera da aplicao numa linguagem no-tcnica. Desenhos de tela como os mock-ups so frequentemente utilizados para amparar a comunicao. Desenvolvimento guiado por testes (TDD Test Driven Development): tcnica na qual blocos de testes so escritos antes do cdigo propriamente dito. Eles determinam o cdigo que necessrio escrever. Nenhum cdigo escrito sem que haja um teste a ele associado.

Entregas frequentes (Frequent releases / Frequent delivery): o time deve entregar verses iterativas do sistema com frequencia. Este intervalo pode variar de uma a quatro semanas. Ao final de cada iterao o software estar testado, funcionando e pronto para ser mostrado ao cliente. A deciso de coloc-lo em funcionamento do dono do produto (product owner). Integrao contnua (Continuous integration): prtica onde os membros da equipe integram o cdigo produzido pelo menos uma vez por dia. Cada integrao verificada pelo build automatizado, o que permite saber rapidamente se h erros. Assim, atravs da juno de pequenas partes testadas, tem-se todo o sistema integrado e com qualidade ao final do desenvolvimento. Metfora do Sistema (System Metaphor): a capacidade de explicao de um design de software a novos desenvolvedores na equipe, de forma rpida e sem a necessidade de vasta documentao. Isto se faz atravs da nomeao consistente de mtodos e classes, o que torna o cdigo reutilizvel. Se estas novas pessoas adivinham o nome de algo j existente e acertam na maioria das vezes, ento o sistema tem uma boa metfora.

Padres de codificao (Coding standard/Coding guidelines / Coding style) so padres style): definidos para manter a consistncia do cdigo e facilitar a compreenso por parte de toda a equipe. Engloba a endentao correta, nomenclatura coerente, comentrios adequados, dentre outros itens que focam a legibilidade. Personas: uma explicao breve sobre o que se sabe dos usurios do sistema. Auxiliam a xplicao equipe na determinao do produto (requisitos), na comunicao com a equipe (documentao) e a medir a efetividade do design (validar ideias).

Poker do planejamento (Planning Poker): espcie de jogo utilizado para estimar estrias. Nele, Poker est as estrias so apresentadas e, depois de discutidas, cada participante escolhe uma carta cujo nmero representa o esforo para constru-la. constru la. Nenhuma estimativa dita at que cada participante apresente sua carta. Quando reveladas, o(s) dono(s) do maior e do menor valor dono(s) apresentado discutem o porqu. A estimativa final dada quando se chega a um consenso. Programao em par (Pair programming / Pairing): uma tcnica na qual cada dois Pairing) programadores trabalham numa mesma estao de trabalho. Enquanto o programador principal digita o cdigo, o programador observador revisa cada linha, sugerindo ideias e prevenindo possveis problemas. Estes papis so constantemente alternados. Refatorao (Refactoring): um processo no qual o cdigo de um sistema alterado, porm sem modificar seu comportamento externo. garantir que o comportamento no foi alterado. Objetiva aprimorar o desenho do software, melhorando o entendimento do cdigo. importante aliar a refatorao aos testes. Isto ir

Reviso de cdigo (Code reviews / Peer reviews): o exame minucioso do cdigo construdo. Tem como finalidade encontrar e corrigir erros que passaram despercebidos na fase inicial de desenvolvimento, aprimorando a qualidade do mesmo, bem como as habilidades dos desenvolvedores. Testes de aceitao (Acceptance testing / Acceptance criteria / Storytesting): geralmente realizados pelos usurios finais do sistema, simulam operaes de rotina, de forma a verificar se o comportamento do software est de acordo com o que foi requerido. Isto faz com que o usurio aceite (ou no) o sistema. Testes de fumaa (Smoke testing / Build verification test): tambm conhecido como teste rpido, avalia se algo vai (ou no) falhar de forma desastrosa. Preliminar aos demais tipos de teste, no teste de fumaa somente as principais funcionalidades so testadas, sem se preocupar com as condies de erro. A metfora vem da ideia de que se ligar e no sair fumaa, porque est funcionando. Testes de integrao (Integration testing): comumente feito aps o teste de unidade, testa a combinao dos mdulos em grupo. Auxilia na identificao de falhas com origem na integrao interna dos componentes ou camadas do sistema (transmisso de dados). Testes de sistema (System testing): validam os requisitos funcionais e no-funcionais de toda a aplicao, executando o sistema sob o ponto de vista do usurio final e em condies similares de ambiente, interfaces e base de dados. So baseados nas exigncias das regras de negcio e normalmente ocorrem aps os testes de integrao. Testes unitrios (Unit testing): tambm conhecidos como testes de componente/mdulo, procura defeitos em partes especficas do software, em caractersticas funcionais e nofuncionais. No necessita documentao. feito com acesso ao cdigo em desenvolvimento e com o auxlio de ferramentas especficas.