revista visão Ágil - edição 02
Post on 30-May-2018
216 Views
Preview:
TRANSCRIPT
-
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/ -
8/14/2019 Revista Viso gil - Edio 02
2/282Revista Viso gil - www.visaoagil.com - Edio 02
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/ -
8/14/2019 Revista Viso gil - Edio 02
3/283Revista Viso gil - www.visaoagil.com - Edio 02
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
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
4/284Revista Viso gil - www.visaoagil.com - Edio 02
Equipe Viso gilDiretor Editorial: Manoel Pimentel Medeiros
Diretor de Marketing: Alexandre Magno FigueiredoAcessoria Administrativa: Manuella Bulco Medeiros
Atendimento ao leitore-mail: manoelp@gmail.com
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 manoelp@gmail.com, e teremos o maior prazer emtrabalharmos juntos.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
5/285Revista Viso gil - www.visaoagil.com - Edio 02
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
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
6/286Revista Viso gil - www.visaoagil.com - Edio 02
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.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
7/287Revista Viso gil - www.visaoagil.com - Edio 02
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.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
8/288Revista Viso gil - www.visaoagil.com - Edio 02
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
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
9/289Revista Viso gil - www.visaoagil.com - Edio 02
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.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
10/2810Revista Viso gil - www.visaoagil.com - Edio 02
As 5 Doenas do gerenciamento de ProjetosAs 5 Doenas do gerenciamento de Projetos
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.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
11/2811Revista Viso gil - www.visaoagil.com - Edio 02
As 5 Doenas do gerenciamento de ProjetosAs 5 Doenas do gerenciamento de Projetos
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.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
12/2812Revista Viso gil - www.visaoagil.com - Edio 02
As 5 Doenas do gerenciamento de ProjetosAs 5 Doenas do gerenciamento de Projetos
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 adail@heptagon.com.br.
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 aelder@nolimitsleadership.com.
Adail Muniz
Retamal(*Tradutor)
http://www.visaoagil.com/mailto:aelder@nolimitsleadership.commailto:aelder@nolimitsleadership.comhttp://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
13/2813Revista Viso gil - www.visaoagil.com - Edio 02
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
14/2814Revista Viso gil - www.visaoagil.com - Edio 02
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.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
15/2815Revista Viso gil - www.visaoagil.com - Edio 02
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.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
16/2816Revista Viso gil - www.visaoagil.com - Edio 02
Desenvolvimento Orientado a TestesDesenvolvimento Orientado a Testes
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
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
17/2817Revista Viso gil - www.visaoagil.com - Edio 02
Desenvolvimento Orientado a TestesDesenvolvimento Orientado a Testes
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)
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
18/2818Revista Viso gil - www.visaoagil.com - Edio 02
Humor deHumor de
ProjetosProjetosQuem disse que no existecomdia em projetos?
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
19/2819Revista Viso gil - www.visaoagil.com - Edio 02
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.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
20/2820Revista Viso gil - www.visaoagil.com - Edio 02
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
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
21/2821Revista Viso gil - www.visaoagil.com - Edio 02
Um cardpio de metodologias geisUm cardpio de metodologias geis
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.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
22/2822Revista Viso gil - www.visaoagil.com - Edio 02
Um cardpio de metodologias geisUm cardpio de metodologias geis
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 : (fabio.camara@fcamara.com.br) 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:fabio.camara@fcamara.com.brmailto:fabio.camara@fcamara.com.brhttp://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
23/2823Revista Viso gil - www.visaoagil.com - Edio 02
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
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
24/2824Revista Viso gil - www.visaoagil.com - Edio 02
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
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
25/2825Revista Viso gil - www.visaoagil.com - Edio 02
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)
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
26/2826Revista Viso gil - www.visaoagil.com - Edio 02
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.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
27/2827Revista Viso gil - www.visaoagil.com - Edio 02
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.
http://www.visaoagil.com/http://www.visaoagil.com/ -
8/14/2019 Revista Viso gil - Edio 02
28/28
Apoios
t 4di it l
www.heptagon.com.brwww.heptagon.com.br
top related