revista visão Ágil - edição 02

8/14/2019 Revista Viso gil - Edio 02

1/281Revista Viso gil - www.visaoagil.com - Edio 02

Estratgias para

Projetos

de Software

As 5 Doenas doGerenciamento de ProjetosCausa n 2:Lei de Parkinson

Um cardpio deMetodologias geis

Uma viso geral dos principaisprocessos geis.

DesenvolvimentoOrientado a Testes

Veja os principais pontos sobre TDD

O seu canal sobre processos geis

Ano I - Edio 02 - www.visaoagil.com

Tabuleiro de ProjetosUma breve crnica sobre estratgias

em projeto de software, atravs depeas de xadrez

E mais:Humor de Projetos, Viso gil pelo Mundo,

Referncias geis e Veio da Enquete

Desenvolver ou no Desenvolver,eis a questo.

Uma analogia, sobre a mecnica de projetos.
http://www.visaoagil.com/http://www.visaoagil.com/http://www.visaoagil.com/



Sprint BacklogSprint BacklogConhea os temas selecionados

para essa edio(iterao).

As 5 Doenas doGerenciamento de ProjetosCausa n 2:Lei de ParkinsonPgina 08

DesenvolvimentoOrientado a TestesVeja os principais pontos sobre TDDPgina 14

Um cardpio deMetodologias geisUma viso geral dos principaisprocessos geis.

Pgina 19

Desenvolver ou no Desenvolver,eis a questo.Uma anologia, sobre a mecnica de projetos.Pgina 24

Tabuleiro de ProjetosUma breve crnica sobre estratgiasem projeto de software, atravs depeas de xadrezPgina 26

NewsPgina 05

Veio da EnquetePgina 06

Viso gil pelo MundoPgina 07

Humor de ProjetosPgina 18

Referncias geisPgina 23
http://www.visaoagil.com/http://www.visaoagil.com/



EditorialEditorial com muito prazer que iniciamos essa segunda edio da Revista

Viso gil, agora, estamos cada vz mais nos consolidando como o canal

de informaes sobre processos geis no Brasil.

Aps a primeira edio, tivemos vrios feedbacks positivos e vriaspessoas interessadas em colaborar com artigos em nossa revista, por issoagora, estamos trazendo alguns nomes fortes do cenrio gil atravs deartigos inditos sobre asssuntos quentes, como por exemplo a segundaparte das 5 Doenas do desenvolvimento, Desenvolvimento Orientadoa Testes, Cardpio de Metodologias geis, Desenvolver ou no

desenvolver, eis a questo, e o Tabuleiro de Projetos.

Alm de trazermos algumas sees inditas como Viso gil noMundo, Humor de Projetos, Referncias geis e Veio da Enquete.

Portanto, caro amigo agilista, espero que goste dessa segundaedio, pois foi feita com muito carinho, focando em qualidade,objetividade e clareza nas informaes. Boa Leitura.

Manoel Pimentel MedeirosDiretor Editorial



Equipe Viso gilDiretor Editorial: Manoel Pimentel Medeiros

Diretor de Marketing: Alexandre Magno FigueiredoAcessoria Administrativa: Manuella Bulco Medeiros

Atendimento ao leitore-mail: [email protected]

site: www.visaoagil.com

Edies AnterioresQualquer edio anterior pode ser baixada gratuitamente no sitewww.visaoagil.com

PublicidadeSe voc est interessado em fazer alguma ao de marketing emparceria da Revista Viso gil, entre contato conosco atravs do

e-mail [email protected], e teremos o maior prazer emtrabalharmos juntos.



NewsNewsVeja aqui as novidades

do mundo gil

Evento JavaBrasil 2007,Confira maiores informaes em:

www.javabrasil.org

Encontro sobre Scrum em LondresNovembro em Londres

informaoes: www.axmagno.com

Evento BorCon 2007http://info.borland.com.br/borcon

WorkshopStruts 2 in Agile em Novembro

www.fratech.net

WorkshopJava for web in Agile em Novembro

www.fratech.net

Coding dojo floripa dia 01/11http://dojofloripa.wordpress.com



Veio daVeio da

EnqueteEnqueteAcompanhe o resultadoda enquete do ms

Neste ms, ocorreu a enquete com seguinte pergunta: Quais processos geis voc j usou

em seus projetos? (Escolha todas que se aplicam). Confira quais eram as opes e como ficou o

resultado dessa enquete.



Viso gilViso gil

pelo Mundopelo MundoNossa revista se fortalecendoe ampliando seu pblico

Desde o lanamento da primeira edio da revista Viso gil, tivemos vrias virias que se

mostraram em nmeros. Primeiro foi o nosso grupo de usuros, que est quase atigindo o total de

500 membros. Em seguida, segundo dados fornecidos pelo Google Analytics, tivemos uma grande

procura em nosso site, inclusive com acessos vindos de outros paises como: United States, Israel,

Portugal, Germany, Canada, Mozambique, United Kingdom, Belgium, Japan, Switzerland, Turkey,

Argentina, New Zealand. Confira esses pases no mapa abaixo.



As 5 DoenasAs 5 Doenas

do Gerenciamentodo Gerenciamentode Projetosde Projetos

Causa n 2:Lei de Parkinson

A multi-tarefa nociva faz os membros da equipe embutirem maior segurana nas estimativas de tarefas.

Vamos examinar mais detalhadamente o tpico da estimao das tarefas e avaliar a validade e o prejuzo causado ao

nflacionar a quantidade de segurana nas estimativas de durao. Quando atribui-se uma tarefa para uma pessoa, aprimeira pergunta : Quanto tempo voc vai demorar? Voc concorda que as pessoas tm uma tendncia a incluir

proteo na estimativa da durao, para acomodar fatores externos como Murphy e multi-tarefa? Pense numa

tarefa recente que voc estimou. Que nvel de certeza voc ofereceu? Foi 100%? Provavelmente no, pois algo

poderia acontecer e impedir voc at de completar a tarefa, tal como uma morte e, portanto, 100% de certeza no

alcanvel. Que tal 50%? Mesmo neste nvel de certeza voc estaria atrasado em 5 de cada 10 vezes. Talvez sua

oferta tenha sido prxima a 90%. Isto significa que 9 em cada 10 vezes voc est no prazo. Isto parece razovel? Que

nvel de certeza voc exige de sua equipe? Voc exige que suas estimativas sejam precisas toda vez? Ou voc est

bem com atrasos em 5 de cada 10 vezes? A maioria dos gerentes quer que as pessoas forneam estimativas

precisas, o que no faz sentido porque uma estimativa, por definio, apenas uma aproximao.

Traduo de Adail Muniz Retamal

Artigo



As 5 Doenas do gerenciamento de ProjetosAs 5 Doenas do gerenciamento de Projetos

Intelectualmente ns entendemos que

estimativas no so exatas. Mesmo assim, ns as

exigimos. Por qu? H uma crena subjacente de

que se podemos determinar precisamente o tempo

para cada tarefa, e nos assegurarmos que cada tarefa

seja terminada no prazo, ento o projeto terminar

no prazo. Porm, ns tambm sabemos que o

objetivo no terminar cada tarefa no prazo, mas

completar o projeto no prazo.Segurana 'normal' A

realidade do trabalho do projeto que a incertezaexiste e, portanto, o tempo das tarefas no pode ser

determinado, apenas estimado

O resultado da exigncia de estimativas

precisas que as estimativas de durao so

convertidas em compromissos. Assim, para fornecer

uma estimativa realista devemos levar em conta

todas as coisas que podem impactar na durao datarefa, embutindo segurana.

Quando uma pequena segurana adicionada s

estimativas elas no so consideradas como irrazoveis

porque, mentalmente, ns adicionamos a segurana

considerando uma distribuio normal do tempo.

Numa distribuio normal, 50% do tempo est de

um lado da mdia e 50% do tempo est do outro lado da

mdia. Assim, avanar de 50% de probabilidade para 80%

no parece ser significativo (veja Figura 2).

Porm, tempos de tarefas no so normais. De

fato, no existe tal coisa como normal. A distribuio

normal ocorre apenas na matemtica, no na vida real.

Devido ao Teorema do Limite Central, se incluirmos

amostras suficientes, eventualmente teremos a distribuio

normal. Um exemplo bobo se eu colocar um p num

balde de gua fervente e outro p num balde de gua

gelada, na mdia, eu devo me sentir confortvel.




Tempos de tarefas no seguem uma curva

normal.Segurana 'real' Em vez disso, eles comeam

em algum lugar alm do zero (toda tarefa deve tomar

alguma quantidade de tempo) e ento a

probabilidade de complet-la como prometidoaumenta rapidamente, e logo comea a diminuir

numa longa cauda (veja a Figura 3). Quando

comparar os dois grficos ver que a pequena

segurana embutida , na realidade, bastante grande.

Quando maior a incerteza da tarefa, mais a cauda

cresce. O resultado uma tarefa com

aproximadamente metade de sua durao estimadasendo segurana.

O nico a adicionar segurana o membro

individual da equipe? Nunca. Posteriormente, o gerente

toma as tarefas estimadas com segurana e adiciona a sua

prpria segurana. Em cada nvel de gerncia mais

segurana adicionada (ver Figura 4). Essa seguranaadicional desnecessariamente prolonga a data de trmino

do projeto e, de fato, no protege contra a incerteza.

Algumas vezes outra doena ocorre, isto , todo mundo

inflaciona suas estimativas porque sabem que o nvel

acima ir cort-las. J que o recurso no sabe o quanto

ser arbitrariamente cortado, ele chuta o quanto

inflacionar a durao. Continuando, j que o prximo

nvel no tem idia de quanta segurana foi adicionada,

ele corta chutando o quanto de segurana ele acha que

foi adicionada. O processo todo ridculo.




Se h tanta segurana embutida em cada

tarefa, por que as tarefas continuam a atrasar? No

deveriam elas terminar no prazo ou antes? Se voc

concorda que a segurana embutida para levar em

conta o desconhecido (Murphy), e que Murphy no

ataca toda tarefa como previsto, ento a maioria das

tarefas no deveria terminar no prazo. Deveria

terminar antes. Apenas uma tarefa ocasional, que

teve tudo imaginado durante a estimao, e a teve

uma sorte muito pior, deveria atrasar. Se as tarefas

no esto terminando antes na maior parte do tempo,

ento a segurana est sendo perdida.

Mesmo uma tarefa que termina no prazo

inaceitvel, pois aproximadamente metade do tempo

estimado estava reservado para eventos que nunca

ocorreram (Murphy).

O mais notvel ainda que as pessoas se esforam

para cumprir o pedido absurdo de fornecer estimativas

precisas. Por qu? Voc concordaria que a maioria das

pessoas quer ser considerada confivel? Se assim, isto

significa que ns tentamos cumprir nossos compromissos,

certo? E se isso verdade, o resultado que ns

adicionamos segurana e lutamos para impedir que ela seja

removida por outros.




Se temos segurana extra embutida, que no

foi necessria, ento usamos esse tempo extra para

fazer um trabalho melhor, em vez de reportar umtrmino antecipado.

Afinal, se exigimos 6 semanas e entregamos

em 4 semanas, qual ser a recompensa por

entregar antes, na prxima vez que pedirmos 6

semanas para uma tarefa? Nossa segurana ser

cortada. Isto pode fazer com que falhemos em nossocompromisso, nos atrasando e nos tornando no

confiveis. Este fenmeno to predominante que

possui seu prprio nome:

Lei de Parkinson. Esta lei expressa que: O

trabalho se expande para preencher o tempo

disponvel. Agora voc deve concordar que aspessoas realmente adicionam segurana, mas ela no

est sendo usada apropriadamente. Sua prova que a

maioria das tarefas no terminam antes, como seria

esperado.

diretor da Heptagon Tecnologia da InformaoLtda, empresa de consultoria e treinamentofocada na aplicao da Teoria das Restries emgeral, e da Corrente Crtica em particular,

Engenharia de Software, metodologias geis degerenciamento e desenvolvimento de software,atuando como catalisador da mudanaorganizacional, alm de ajudar as organizaes aconstrurem sua estratgia e ttica para alinharseus esforos com suas metas. Adail Engenheiro Eletricista/Eletrnico, atuou comoconsultor, instrutor e arquiteto de solues para aBorland Latin America por 4,5 anos. Lecionou emuniversidades pblicas e privadas. palestrante,articulista e est escrevendo um livro. Adail pode

ser contatado em [email protected].

Allan Elder (*Autor) presidente da No Limits Leadership, Inc., umaempresa de consultoria dedicada a ajudar asorganizaes a entregar mais projetos, maisrpido, atrves da liderana eficaz. Allan trabalhoucomo diretor de GSI (Gerenciamento de Sistemasde Informao) para a segunda maior empresa deseguros corporativos e a maior empresa desegurana na Califrnia. Allan foi certificado comoPMP, um Jonah na Teoria das Restries,possui bacharelado em Telecomunicaes,mestrado em Gerenciamento de Projetos e Ph.D.em Organizao e Gerenciamento. Alm de seutrabalho em consultoria, Allan o principalinstrutor de gerenciamento de projetos para aUniversidade da Califrnia, Irvine, prestouconsultoria e lecionou para a UCI GraduateSchool of Business, e foi um Examinador Sniorpara o California Award for PerformanceExcellence (CAPE) por trs anos. Allan pode sercontatado em [email protected].

Adail Muniz

Retamal(*Tradutor)
http://www.visaoagil.com/mailto:[email protected]:[email protected]://www.visaoagil.com/



DesenvolvimentoDesenvolvimento

Orientado aOrientado aTestesTestesPor Victor Hugo Germano

Artigo

Os tempos so de mudana. No se pode mais pensar em um modelo de negcios que no sofra influncia das

reas econmica, poltica ou estratgica. Nosso modelo de desenvolvimento deve estar pronto para responder

rapidamente s alteraes que por ventura afetem um projeto.

Nesse ambiente complexo, em que requisitos nem sempre so definidos e a nica certeza que temos a da

mudana, devemos assumir uma postura pr-ativa que d ao desenvolvimento a chance de responder rapidamente

alterao do processo de negcio.

Assim surgem os modelos evolucionrios de desenvolvimento, sendo o TDD (Test Driven Development),

uma maneira de garantir o progresso sustentvel do software frente s incertezas que cercam seus requisitos e

objetivos futuros. Trazendo um modelo de simplicidade e clareza regendo todo o ciclo de vida do produto, oDesenvolvimento Orientado a Testes pode ser uma tima opo de garantia da qualidade e robustez no

desenvolvimento de software.



Desenvolvimento Orientado a TestesDesenvolvimento Orientado a Testes

Antes de tudo, deixem-me esclarecer uma

coisa: este no um artigo sobre testes. Este artigo

sobre um mtodo de desenvolvimento que nos guia

para um cdigo mais robusto e passvel de

manuteno. Softwares complexos no precisampossuir um cdigo incompreensvel, e quanto maior

a complexidade, maior ainda ser o impacto positivo

gerado pelo TDD.

Desenvolvimento Orientado a Testes uma

tcnica de desenvolvimento de software que envolve

a definio de um caso de teste, ou mesmo a

mplementao de um cdigo de teste, antes deniciar a implementao de uma funcionalidade ou

mtodo. A implementao deve ser apenas para

fazer o teste passar. Desta maneira, pode-se ter um

feedback rpido sobre o progresso da

mplementao. Formalizado primeiramente atravs

dos trabalhos de Kent Beck em sua introduo ao

eXtreme Programming, foi atribuda ao TDD grande

responsabilidade, sendo definido como o cerne de

todo o Desenvolvimento gil. Fora do ambiente

gil, entretanto, TDD torna-se um sub-processo que

acaba fazendo parte de todo o processo de

Desenvolvimento de Software.

As trs Regras do TDD

No blog Uncle bob, existe uma explicaosimples por meio de trs regras:

Nenhum cdigo de produo ser escrito ano ser que seja para fazer um teste unitrio

passar.

Apenas o essencial ser codificado para queum teste unitrio falhe; e erros de compilaoso erros

O nico cdigo de produo escrito ser osuficiente para fazer o teste unitrio passar.

Ken Beck(2003) atribui a estas regras uma

mudana drstica no comportamento dos indivduos da

equipe: Desenvolvimento orgnico, com cdigo

funcionando provendo feedback rpido entre as

decises

Escrever os prprios testes e no ter queesperar 20 vezes ao dia para que outra pessoa osescreva para voc

O ambiente de desenvolvimento deve proverrespostas mais rpidas para pequenas mudanas(i.e. a necessidade de compiladores e suites deteste mais robustas)

A arquitetura do sistema torna-se altamentecoesa e componentizada, sendo ainda menosacoplada (devido caracterstica altamentenormalizada da tcnica), tornando os testes maisfceis de serem executados.




Desta maneira, viramos o desenvolvimentotradicional do avesso. Criando software atravs depassos menores, podemos manter o controle do

cdigo escrito, garantindo que qualquerfuncionalidade adicionada deva ser previamenteprojetada e testada. Na verdade, um programador

utilizando TDD risca, recusa-se a escrever umanova funcionalidade sem que ao menos um testetenha sido criado para validar tal incremento devalor.

E os benefcios vo muito alm. A cada horanmeros testes so criados, e nenhuma nova

funcionalidade adicionada sem que todos os testesanteriores estejam sendo executados perfeitamentesem falhas. Isso cria a garantia de que caso um

problema ocorra, ele poder perfeitamente serreproduzido criando mais alguns testes, e ainda

assim, se uma funcionalidade nova for inserida,pode-se garantir que ela no afetar outros pontos dosistema, caso todos os testes estejam validados.

Neste caso, os testes servem no apenas paragarantir que o cdigo esteja perfeitamentefuncionando, mas obriga que desenvolvedoresdealizem o funcionamento prvio das

funcionalidades, isto , cria a necessidade da anlisedo problema durante o desenvolvimento, fazendocom que a compreenso e o modelo emerja dacontnua tentativa de fazer um teste passar. Aonde

chegaremos com isso? O design da aplicao criado, especificado e materializado atravs de umaferramenta que possibilita a automatizao deverificaes: o teste.

Este modelo fora os desenvolvedores apensarem de forma desacoplada, favorecendo a

componentizao. Tendo a inteno de testar ummdulo isoladamente, necessrio cri-lo demaneira componentizada, forando-os a pensar emotimizao de cdigo, reutilizao e em simplicidade

Ampliando a Qualidade de SoftwareTradicionalmente temos a fase de testes de

software ocorrendo no momento posterior mplementao, seguindo o modelo j ultrapassado,

mas ainda utilizado, o cascata. Com esta postura,existe a idia de que a equipe de testes deve varrer osistema procura de erros e bugs. E se o realentendimento da rea de testes fosse outro? Que talnterpretar uma rea de testes como um local onde

apenas ser verificado se os erros realmente no

existem, assumindo que o desenvolvimento j estempenhado em evitar que tais erros aconteam,deixando para a rea de testes a funo de garantir oalinhamento entre Requisitos e Software emfuncionamento.

O principal ganho do modelo TDD no

descobrir erros, mas evitar que eles sejam criados.A expresso mais utilizada atualmente "build

quality in", isto , garante-se o feedback imediato sobre aimplementao, e em funo disso amplia-se a confianano cdigo e a garantia de que o sistema realmente alcanceos requisitos propostos.

Num modelo cascata, o custo da alterao derequisitos cresce exponencialmente medida que osistema evolui entre as fases de Anlise, Implementao,Teste e Implantao. Temos assim, o quadro abaixo,retirado do artigo "Custo da Mudana" de Barry Boehm(em ingls):

Surge uma observao importante: sendo o custoto alto, movendo-se a fase de testes para a esquerda,talvez houvesse uma chance de reduzir o custo de umamudana, j que antes de passar entre as fases estaramosvalidando o que foi feito na fase anterior.

Neste ponto, o desenvolvimento evolucionrioTDD acaba se favorecendo, pois permite que sejamosmais flexveis diante de mudanas nos requisitos. Ao

invs de levar muito tempo em todas as fases dodesenvolvimento, entregando - ou no - ao final doprocesso um produto, nos encontramos em uma situaoonde se pode demonstrar partes completamentefuncionais do sistema ou funcionalidades muito antes. E,ao fazer isso, o custo de mudana torna-se imensamentemenor.

Independentemente daopo de seutilizar XP ouqualquer outro mtodo gil, o TDD torna-se uma opo

para qualquer modelo de desenvolvimento. Automatizartestes, tentar especificar funcionalidades de maneira

incremental, garantir a consistncia do cdigodesenvolvido e ainda a possibilidade de calcular oimpacto gerado por bugs de maneira fcil so os pontosfortes da adoo




Documentao

Encaremos um fato: desenvolvedoresdificilmente so adeptos de manter e lerdocumentaes, preferindo, normalmente, oscdigos. Como programador, me agrada, antes de

tudo, quando inicio o trabalho com uma novabiblioteca, verificar qual o cdigo utilizado para

acessar essa nova biblioteca. E no h nada de erradonisso. Testes unitrios bem escritos possuem essepropsito, provendo uma especificao funcional docdigo, e em decorrncia disso so uma timareferncia tcnica.

Da mesma forma, a definio de o que osstakeholders esperam do sistema pode serautomatizada atravs de testes. Este processo deespecificao de requisitos em forma de testes

chamado Teste de Aceitao. Assim,transformamos o teste de sistema em uma ferramentade especificao e no apenas de validao.

No se deve esquecer a necessidade dedocumentao do processo de negcio, essencialpara o entendimento do ambiente em que o softwareest inserido. De maneira alguma um documentoescrito torna-se obsoleto com o modelo apresentadoacima, mas pode-se concluir que possvel diminuirem muito a documentao gerada que necessite umamanuteno complexa para manter o alinhamentocom o cdigo.

TDD x Matriz de rastreabilidade

Segundo Clayton Vieira Fraga Filho:"A matriz de rastreabilidade oferece como grande

acilitador a visualizao global dos Casos de Uso erequisitos do sistema em uma tabela de forma

rfica, dando suporte ao analista para tomardecises e descobrir problemas e sua soluo de

orma mais rpida, muitas vezes antes do fase deimplementao."

Bastante utilizado nos modelos CMMI eMoProSoft, a Matriz de Rastreabilidade pode servirde ferramenta na estimativa do impacto de umamudana nos requisitos de sistema. Entretanto, coma progresso do desenvolvimento, torna-se muitocara a manuteno dessa tabela tendo em vista suacaracterstica no acoplada ao cdigo. O nvel de

detalhamento possui papel importante no custo damanuteno.

A vantagem da utilizao do DesenvolvimentoOrientado a Testes est, em grande parte, aderncia aocdigo fonte e automatizao que os testes trazem.Mesmo no apresentando a visibilidade completa doimpacto, j que testes podem falhar aps uma alteraono prevista, existem maneiras de simular o uso de uma

matriz de rastreabilidade, com o auxlio de ferramentasde desenvolvimento. IDEs mais completas possuemformas de verificar utilizao de mtodos no cdigofonte. Com a garantia da componentizao e baixoacoplamente que o TDD traz, informaes consistentes

podem ser geradas, simulando assim uma matriz derastreabilidade.

Concluses

Durante a apresentao do contedo acima, tentei

apresentar o conceito do Desenvolvimento Orientado aTestes de maneira a mostrar as vantagens de suautilizao. Apresentaremos nas prximas reportagens olado prtico de sua aplicabilidade. Fiquem atentos!

Referncias:

Tudo Sobre TDD - Coding Dojo Floripahttp://dojofloripa.wordpress.com/2007/09/10/tudo-sobre-tdd/

A Maldita Comdiahttp://malditacomedia.blogspot.com

Bacharel em cincia da computao pela Universidadefederal de santa catarina, especializado em Gestoestratgica de TI. Atualmente trabalhando na empresaAudaces auxiliando no processo de adoo demetodologias geis.

Victor HugoGermano(*Autor)



Humor deHumor de

ProjetosProjetosQuem disse que no existecomdia em projetos?



Um cardpio deUm cardpio de

metodologiasmetodologiasgeisgeisPor Fbio Cmara

Artigo

Um projeto de software est com srios problemas e quando acordei percebi que no era um pesadelo. Pegueium livro e li: O mau gerenciamento pode incrementar os custos de um projeto de software mais rapidamente quequalquer outro fator, escreveu Barry Boehm em 1981. Temi pelo meu emprego e pensei: _ antes de desistir voucontratar muitos desenvolvedores. Peguei outro livro e li: Adicionar pessoas faz um atrasado projeto atrasar aindamais, escreveu Frederick Brooks em 1995.

Neste cenrio assustador questionei-me: o que vou fazer diferente se preciso de resultados diferentes? Comocompreender os verdadeiros obstculos do gerenciamento de um projeto de software?

Procurei por muitos caminhos mas a resposta que mais gostei me foi ensinada pelos mtodos geis. Entremuitos aprendizados que tive, li que o pensamento gil reconhece 5 obstculos no gerenciamento de projetos desoftware. So eles: pessoas, tempo, funcionalidades, oramento e recursos (excluindo pessoas). Com isto em mente,coloquei em prtica um pouco de 4 propostas geis que estudei.

Vamos conhecer um pouco destas propostas geis. So elas XP, MSF, SCRUM e FDD.

eXtreme Programming

Mtodos geis so propostas incomuns de tcnicas para projetos de software. XP, como o nome sugere, algoum pouco mais radical. Propostas estranhas de tcnicas esquisitas fazem os gerentes de projetos temerem utiliz-lasem grandes projetos. Para atrapalhar ainda mais as poucas iniciativas de se quebrar paradigmas, o radicalismo dealguns pensadores de XP afastam a compreenso sobre as reais vantagens e os benefcios para o negcio que podemosalcanar com estes mtodos.



Um cardpio de metodologias geisUm cardpio de metodologias geis

A programao em pares, um dos maisdiferentes e originais mtodos do XP, traz para ogerente do projeto a necessidade de uma posiosem hipocrisia. Ou voc ama, ou voc odeia. Athoje no encontrei um gestor em cima do murosobre esta tcnica.

Como exemplo, vamos citar Karl Wiegers,famoso autor de livros tcnicos, que afirma em seusensinamentos que a programao em pares comoforma de inspecionar cdigo no efetiva nareduo dos defeitos. Segundo o mesmo, entre 25 %e 35 % o ganho atingido no aspecto defectreduction. Esta afirmativa questionada por DavidAnderson, outro grandioso autor, que defende umnmero percentual em torno de 50%.

J em minha prpria vivncia, as reunies em

p (stand-up meeting) so fabulosas em quase todosos aspectos. Particularmente acredito no pensamentode Jonh Kennedy, ex-presidente dos EUA, que dizia:quando se quer no fazer nada fingindo que esttrabalhando, entre em uma reunio.

Listamos a seguir os principais mtodospolmicos do XP.

Pair Programming; Continuous Integration; Stand-Up Meeting;

Collective Ownership (cdigo fontecoletivo);

Refactoring; On-Site Customer; Generalists.

Na minha leitura, o XP uma proposta muitocompleta de ciclo de vida de desenvolvimento desoftware, agradando ou no um gestor de projetos.Um dos principais fundadores do XP chama-se KentBeck.

FDD Feature Driven DevelopmentCriado entre 1997 e 1999 em Cingapura por

um time liderado pelo Jeff De Luca, uma simplescompilao de prticas estabelecidas nos ltimos 30anos. Um de seus maiores desenvolvedores, PeterCoad, definiu a idia de Feature Definition e FeatureList. Diversos renomados autores participaram daconcepo das idias do FDD. Dentre estesdestacamos: Tom De Marco, Tim Lister, Jerry

Weinberg e Frederic Brooks.Em sua essncia, FDD mais um mtodo degerenciamento de software do que um ciclo de vidade desenvolvimento de software.

Resumidamente, FDD dividido em 5 fases queexplicam sua funo. So elas

Shape Modeling uma forma de questionar se

todos compreendem o que para fazer, analisar

requisitos no-funcionais e modelo de arquitetura; Feature List a representao do escopo

listando a compreenso do que para ser feito e osrequerimentos a serem desenvolvidos;

Plan by subject area a modularizao da listaem conjuntos de funcionalidades relacionadas,

permitindo o desenvolvimento de parte do sistemaautonomamente;

Design by feature set uma orientao quedetermina o desenvolvimento com base nodomnio do problema. Sugere-se nesta fase uma

modelagem profunda e detalhada em UML; Build by Chief Programmer Work Package

o empacotamento de pequenas funcionalidades,uma reduo evolutiva que nasce na fase 2 at afase 4. Prioriza-se este pacote, codificando suafuncionalidades e criando unit tests.

FDD define tambm 4 camadas de arquitetura desoftware:

UI User Interface; PD Problem Domain (lgica do negcio); DM Data Management; SI Systems Interfaces.

Notamos que o core de todas as fases e dascamadas de arquitetura a funcionalidade (feature). Cadafuncionalidade definida com uma frmula simples, que

permite ser repetvel e confivel. A frmula dafuncionalidade tem a seguinte estrutura:

Exemplo: O valor total de vendas Faturamento bruto mensal

Produtos vendidos no perodo




MSF Microsoft Solutions Framework

Disseram-me que MSF s funciona emprojetos com tecnologias da Microsoft.

mpressionante a associao restritiva quenaturalmente os desinformados impem as coisas.

Tambm j ouvi que metodologias geis sso recomendadas para projetos pequenos. Pior quesso! Ouvi de uma diretora de TI de um banco: _

Hoje ns somos geis (referindo-se a ausncia degesto e de anlise de requisitos de seudepartamento), queremos ser mais organizados.

Estudando o assunto h 9 anos, eu sempreconsiderei o MSF uma proposta equilibrada, aondeseus 2 modelos e suas 3 disciplinas nunca seapresentaram como uma espcie de bblia sagrada,determinstica ao sucesso ou fracasso de seu projeto.

Inclusive na verso 3.1 do MSF, antes daformalizao das propostas geis no ano de 2001,tinha como conceito chave: _ Stay agile, expectchanges.

O MSF 4.2, possui duas novas instncias:MSF for Agile Software Development e MSF forCMMI Process Improvement. Podemos afirmar queo MSF Agile um mix de posies equilibradas,pois defende um SDLC (Software Development LifeCycle) mais curto com iteraes de no mximo 4semanas, contudo preserva a importncia dos papisdefinidos previamente e abomina a linha todomundo pode fazer tudo no projeto. Outro quesito dedestaque nesta fuso so os testes unitrios e apreocupao com a cobertura de 100% do cdigofonte.

Um tema muito forte dentro do MSF Agile ntegrao. Metodologias geis nescessitam que os

stakeholders estejam presentes o tempo tododurante o projeto. Para isso so constitudos cenriosde tarefas de trabalho que englobam atividades

planejadas para um desenvolvedor. Estes cenriosfazem parte de uma determinada iterao do planode iteraes. Esta iterao agrupa os cenrios dedesenvolvedores e os cenrios de testes (que soefetuados em seguida ao desenvolvimento). Destaforma controla-se a integrao de um time com

papis diversos dentro do projeto (usurio,desenvolvedor e analista de testes).

Para o MSF, um projeto precisa dos seguintesppeis (entende-se papis como responsabilidades

que devem ser assumidas por algum membro da

equipe):

Program Manager Product Manager User Experience Tester Developer

Architect Release Manager

rduo afirmar que foi o fundamentador do MSF, porm o grande patrocinador sempre foi a prpriaMicrosoft. Para no ficar em branco com nomes, MichaelCusomano, Steve McConnell destacam-se entre muitosoutros como personagens da histria do MSF.

SCRUM

SCRUM um mtodo de gerenciamento desoftware que pode ser usado com XP ou MSF. baseadona teoria do controle emprico de processos e seusfundamentos so originados na indstria de manufaturaaponesa.

Ciclo de vida emprico um ciclo baseado naobservao dos fatos. Muitos gerentes de projetos nogostam do mtodo reativo sugerido pelo SCRUM e

preferem trabalhar com um planejamento que na minhaleitura um trabalho especulativo, pois tenta prever uma

seqncia de atividades lineares. Por mais que ocronograma tenha um valor que o planejamento prvio,ou seja, pensar antes de sair fazendo, perde muito emtentar prever atividades distantes cheias de dependncias

predecessoras e no facilita o controle das mudanas derequisitos.

Segundo o SCRUM, o desenvolvimento deve sertrabalhado em 3 nveis: Sprint, Release e Product.

O ponto central que os requisitos soconvertidos em uma lista que contm valores do clientechamada Product Backlog. Um sub-conjunto desta lista

criado e chamado de Release Backlog. Este sub-conjunto particionado mais uma vez transformando-se em Sprint,uma espcie de acordo de desenvolvimento defuncionalidades que aps aceito pela equipe no deve sermais alterado.

Praticando SCRUM, o que mais chama a ateno a simplicidade. Controlar projetos desta forma

participar de um jogo competitivo e saudvel em quetodos se auto-avaliam todos os dias (daily stand-upmeeting) tornando possvel resultados e tcnicas demelhoria contnua.




A orientao gil :

Considere na imagem que a seta vermelha umaconstante, a seta verde mais ou menos varivel e a setalils a mais varivel.

Compreendendo a diferena entre as duas ealinhando com as caractersticas das expectativas de seusstakeholders, voc conseguir alcanar resultadosdiferentes. Experimente!

O gerente de projetos como conhecemoshoje, na proposta SCRUM, chamado de SCRUMMaster. Suas principais responsabilidades resumem-se em duas: Proporcionar a passagem tcnica eretirar todos os impedimentos. A equipe do projeto dividida em apenas 3 ppeis: o SCRUM Master

(coach), o Product Owner e a equipe.Em diversos aspectos, as tcnicas doSCRUM diferenciam-se das propostasconvencionais. Destaque para:

Product Backlog; The 30-Day Sprint; The SCRUM Meeting; Team Size; The Sprint Review.

Para saber mais sobre SCRUM, mprescindvel ler algum dos ttulos lanados por

Ken Schwaber.

O que experimentar

Independente de sua curiosidade para novossabores, os mtodos geis so uma honesta respostaa pergunta: o que vou fazer diferente se preciso de

resultados diferentes?Baseados em processos iterativos

ncrementais e empricos, os mtodos geis sondiscutivelmente diferentes das propostas

tradicionais que so fundamentadas em processoscascata. Esta diferena pode ser a resposta a suadvida tambm.

Meus resultados mudaram significativamentequando entendi a diferena essencial da proposta gilem comparao ao modelo que eu havia aprendidonos ensinamentos do PMI Project ManagementInstitute.

A orientao PMI : ([email protected]) MCT, MCP,MCSA, MCAD Charter, MCITP, MCTS,MCSD.NET, MSF Practitioner, Certified ITILFoundations e Certified SCRUM Master Acreditaem bons resultados em projetos com tcnicasgeis, principalmente para as caractersticas domercado brasileiro.

Fabio Cmara(*Autor)
http://www.visaoagil.com/mailto:[email protected]:[email protected]://www.visaoagil.com/



RefernciasReferncias

geisgeisVeja aqui, alguns sites e blogsindispensveis para o mundo gilBlog do Jos Papo, um timo lugar

para voc ter acesso a um material em

portugus bem variado, profundo,feito com resposabilidade, e abordando temascomo agile, OpenUP, UML, Modelagem earquitetura.URL:josepaulopapo.blogspot.com

Site do papa Martin Fowler, quem ele?Imagine um cara que foi citado em todos

os principais livros sobre programao,

modelagem, arquiteturas,padres de projetose refatorao de cdigo.

O resto, descubra por s s.URL: martinfowler.com



DesenvolverDesenvolver

ou noou noDesenvolver,Desenvolver,

eis a questo.eis a questo.Uma breve crnicasobre a mecnica de um projeto de

desenvolvimento de software

Por Manoel Pimentel Medeiros

Artigo

Sei que voc pode estar pensando, Desenvolver ou no desenvolver? U, eu j ouvi uma frase

parecida..., exatamente, usei essa adaptao da clebre frase do livro Hamlet, escrita porWilliam Shakespeare,

para tentar mostrar uma breve metfora para explicar o cotidiano de um projeto de desenvolvimento de software.

Ento, a idia lev-lo a uma reflexo sobre esse assunto, pois, que tal comparar a atividade de desenvolvimento de

software, com uma pea de um grupo teatral, pois acompanhe comigo:

O Autor da pea normalmente a escreve em conjunto de outros autores ou com ajuda de revisores.

O Diretor e o produtor da pea precisam constantemente ler e reler os atos e cenas a fim de revisar a obra e

buscar as melhores formas de mont-la.

Os figurinistas, iluminadores e cengrafos tero que conhecer muito bem o texto, os personagens e o

ambiente de cada cena.

Os atores, precisam ler e r-ler o texto de forma minuciosa, afim de aprend-lo, e principalmente precisam

entender as sub-linhas do mesmo, para que possam compor melhores personagens



Desenvolver ou no Desenvolver, eis a questo.Desenvolver ou no Desenvolver, eis a questo.

Cada ator, apesar de suas falas especficas,

precisam conhecer o texto como um todo,

para que haja sincronismo nas cenas e nas

falas, para isso, ento, cada ator, ensaia o

texto sozinho, lendo suas falas e dos outrospersonagens tambm, dessa forma, cada ator,

consegue ter uma compreenso impar acerca

da pea, e cada um poder sugerir melhorias

em suas cenas.

Quando os atores esto ensaiando em grupo,

sua atuao posta ao conhecimento de

outros atores e tambm do diretor, gerandoento uma grande margem para as

sugestes, crticas, elogios e trocas de

conhecimento acerca das tcnicas individuas

de atuao.

Dessa forma, como os atores adquirem um

conhecimento pleno acerca da pea,

possvel que quando necessrio, um ator,substitua outro ator, na interpretao de um

personagem em algum momento da pea, o

nvel de dependncia individual pequeno.

E quando o grupo pequeno, comum, que

haja uma polivalncia entre seus

membros, dessa forma, muitas vezes, uma

mesma pessoa, ator, maquiador, ajuda na

direo e na produo da pea.

importante lembrar, que uma pea

ensaiada durante vrios meses, e a cada

ensaio, detectado nas necessidades de

ajustes em cada detalhe da pea, ou seja, cria

como houvesses pequenos ciclos tambm

conhecidos de iteraes, para que a pea

possa ser construda e melhorada a cada

ensaio.

E quando finalmente pea mostrada ao pblico,

cada apresentao ajuda a gerar uma retrospectiva

sobre o que pode ser melhorado para as prximas

apresentaes. Dessa forma, a pea passa por um

processo de melhoria contnua para alcanar omximo da satisfao do pblico.

Para terminar, veja que esses fatos e outros que no

mencionei aqui, podem muito bem servir de metfora ao

processo de criao de um software, principalmente pela

idia central de que: mesmo que haja um esforo

individual e solitrio em alguns momentos, pela prpria

dinmica da pea, o resultado desse esforo compartilhado e validado de maneira gradual com

todos os participantes, gerando um resultado final

chamado obra coletiva, que ser avaliado por um grande

pblico, ou seja um alto nvel de exigncia de qualidade e

encantamento, portanto meu caro amigo, pense nisso, e me

diga se a nossa rea de desenvolvimento de software no

semelhante construo de uma pea teatral. Muito

Obrigado e at a prxima.

Engenheiro de Software e CSM, trabalha comprojetos Java pela Rhealeza Informtica, Tambm Dir. Editorial da Revista Viso gil, Conlunistada Java Magazine, Membro do Desenvolvimentodo NetBeans, Lder do projeto BoxSQL, efundador do XPNorte, NUG-BR, e PrPatterns e

Frequentemente palestra em eventos sobreprocessos e tecnologias. Maiores informaesem: http://manoelpimentel.blogspot.com .

Manoel PimentelMedeiros(*Autor)



Tabuleiro deTabuleiro de

projetosprojetos

Uma breve crnica sobre estratgiasem projeto de software, atravs de peas de xadrez.

Por Manoel Pimentel Medeiros

Artigo

Estratgia, esse foi um dos pensamentos mais importantes para nossa evoluo, porm, sempre imaginamosque o pensamento estratgico est distante da nossa realidade, apesar de que principalmente na rea dedesenvolvimento de software, o pensamento e aes estratgicas so fundamentais para o sucesso de um projeto.Durante muito tempo, devido a algumas vises equivocadas de alguns modelos de produo, fomos condicionados apensar que devamos apenas nos importar em apertar parafusos, no sabendo exatamente qual o parafuso certo epara que serviria aquele parafuso.

Porm, com o passar dos tempos, o poder do pensamento mais analtico foi tomando importncia, e o poderdo pensamento estratgico foi se tornando um fator determinante para o sucesso de muitas companhias.

Na verdade o pensamento estratgico, no algo propriamente novo, ele est presente na histria dahumanidade h muito tempo, desde as antigas guerras que contriburam sistematicamente para as mudanas de nossacivilizao.

Voc deve est se perguntando, o que isso tem a ver com projetos de software? Eu lhe respondo: elementarmeu caro leitor, hoje em dia o sucesso de muitos projetos de software est intimamente ligado ao uso de estratgias,porm, poucas as pessoas que participam de projetos, compartilham com essa viso.

Dado a importncia que o pensamento e aes estratgicas tm para um projeto de software, resolvi brincarum pouco com essa idia, usando como metfora um jogo de xadrez, onde atravs da figura de cada pea, vocentender de uma forma bem divertida e dinmica, como tratar cada elemento de um projeto de software.

Mais ateno, leia atentamente a tabela abaixo, e principalmente reflita bem, sobre as correlaes entre aspeas do jogo xadrez e os elementos comuns em um projeto de software que estou tentando mostrar.



Tabuleiro de projetosTabuleiro de projetos

Como voc deve ter percebido, muito importante, que os elementos chaves de projetos sejam gerenciadoscom muita estratgia, a fim de maximizar as chances de sucesso, evitando dessa forma os famosos atrasos, estourosde oramentos, software fora do escopo, enfim vrios outros problemas que voc deve conhecer.

Claro que no existe uma combinao mgica, que funcione como uma bala de prata para garantir o sucesso

de um projeto, portanto, sempre que possvel, lembre sempre desse esquema, afim visualizar o efeito de cadamovimento seu em um projeto, ou seja, o que ser ganho e poder ser perdido em cada movimento no projeto,dessa forma, voc poder tomar as decises de maneira mais conscientes e acertadas.

Espero que voc tenha gostado desse texto, e principalmente tenha absorvido a idia principal relacionada aoselementos de um projeto e sua relao com o jogo de xadrez, portanto, muito obrigado e at a prxima.

PeaSignificado no

projetoPontoForte

PontoFraco

Pees

Simplicidade

Devido a sua simplicidadede movimentos, muitasvezes, ignorado peloadversrio, porm, umpeo capaz de deixar emxeque um rei adversrio ou

at mesmo se tornar umarainha podendo determinaro sucesso de um jogo.

Muitas vezes, para defenderalguma pea ou quandofazemos um movimentoerrado, os pees so osprimeiros a serem eliminados,ou seja, muito fcil perder

totalmente o poder dasimplicidade durante o jogo.

Torres

Prazo

Quando tudo est bem no jogo, raramente iremosmexer com a torre, masquando necessrio equando bem manipulado capaz de criar um bomxeque-mate.

Lembrando que a torre spode ser movimentada nahorizontal e vertical, quantascasas forem necessrias,note que h um limite demovimento, pois s vezes,gostaramos que ela semovimenta-se na diagonal,mas isso no possvel, ouseja, temos limitaes ao

tentar mover de formaeficiente essa pea.

Bispos

Recursos

Representando a sabedoriano jogo, pode facilmentetransitar em qualquer parte,devido aos seusmovimentos na diagonal eusado com sabedoria, podefazer ou facilitar vriasopes de xeque-mate.

Usado frequentemente paraproteger peas como a rainhaou o rei, e por transitarfacilmente pelo terrenoadversrio durante umataque, comum perder-los,por excesso de zelo ou pordemasiada ousadia.

Cavalos

Criatividade

Pelo poder de alcance e alimitao de s se moverem forma de L, fora o

jogador usa-lo com muitacriatividade, dessa forma,somos capazes de iniciarum jogo ou fazer o xeque-mate usando o cavalo.

Frequentemente, o cavalo usado para proteger a torre, obispo, a rainha ou at mesmo

o rei, dessa forma, comumterminarmos o jogo, semnenhum cavalo.

Rei

O Software

o objetivo do jogo, tantopara o ataque quanto paradefesa, a vitria quandoatingimos o rei adversrio,ou seja, o famoso xeque-mate.

Infelizmente, simplesmentequando nosso rei sofre umxeque-mate, perdemos o jogo(acho que deu para ser claro,certo?).

Rainha

Qualidade

Esta pea mais poderosado jogo, pois ela pode semover em qualquer direo, quantas casasforem necessrias,podendo ser fulminantequando usado para oataque, garantindo umavitria certa no jogo.

Porm, frequentemente,sacrificamos a rainha, paradefender o rei, e quando issoacontece, nosso poder devitria diminui drasticamente.


28/28

Apoios

t 4di it l

www.heptagon.com.brwww.heptagon.com.br

revista visão Ágil - edição 02

Documents