Use A Cabeça Ágil

você está aqui X 35

valores e princípios ágeis

P: O que quer dizer

"cascata" mesmo?

R: "Cascata" indica a forma específica

de criação de softwares utilizada

tradicionalmente por algumas empresas.

Nesse modelo, os projetos são divididos

em fases e geralmente podem ser

representados por um diagrama parecido

com esse:

Requisitos

Design

Implementação

Verificação

Manutenção

O nome "cascata" foi criado por um

pesquisador e engenheiro de software na

década de 1970, o primeiro a descrever

esse modelo como uma forma pouco

eficiente de criar softwares. Em regra, a

equipe deve conceber um documento de

requisitos e um design quase perfeitos

antes de começar a criar o código, pois

voltar atrás e consertar eventuais

problemas nos requisitos e no design

demanda muito tempo e esforço.

Mas muitas vezes não há como

saber se os requisitos e o design

estão corretos até a equipe começar a

criar o código. Comumente, uma equipe

que atua com projetos em cascata acha

que fez tudo certo na documentação, mas

acaba descobrindo graves falhas quando

os desenvolvedores começam

a implementar o design.

P: Então, por que as pessoas ainda

usam processos em cascata?

R: Porque funciona ou, pelo menos,

pode funcionar. Muitas equipes já criaram

ótimos softwares utilizando processos

em cascata. Certamente, é possível criar

primeiro os requisitos e o design a fim de

reduzir a necessidade de

futuras alterações.

E o mais importante: há muitas empresas

cuja cultura realmente combina com um

processo em cascata. Por exemplo, imagine

que seu chefe vai puni-lo severamente se

achar que você cometeu um erro. Logo, se

ele aprovar pessoalmente os requisitos e os

documentos de design completos antes do

código ser escrito, seu emprego pode ser

salvo. Mas, seja qual for o procedimento,

o esforço necessário para identificar o

responsável por cada decisão no projeto

é descontado da energia que poderia ser

empregada na criação do produto.

P: No final das contas, o processo

em cascata é bom ou ruim? Ele é

menos "leve" que a metodologia,

abordagem ou framework ágil?

R: Nem "bom" nem "ruim", o processo

em cascata é apenas um modo de fazer as

coisas. Como qualquer ferramenta, tem

seus pontos fortes e fracos.

No entanto, muitas equipes vêm obtendo

mais sucesso com metodologias ágeis

como o Scrum do que com o processo em

cascata. Essas organizações acham que o

processo em cascata é muito "pesado" e

impõe muitas restrições à sua estrutura

operacional: as empresas são obrigadas

a passar por fases de elaboração de

requisitos e design completos antes do

código ser escrito. No próximo capítulo,

vamos ver como as equipes Scrum usam

as etapas e as práticas de planejamento

para criar o software rapidamente e

entregar o produto em funcionamento aos

usuários. Isso dissemina uma sensação

de "leveza" entre a equipe porque todas

as suas ações têm efeito imediato sobre o

código criado.

P: Então, como eu devo executar

meus projetos? Minha equipe deve

criar uma documentação ou não?

Devemos trabalhar com base em uma

especificação completa ou descartar

completamente a documentação?

R: A documentação é importante

para as

equipes de desenvolvimento

ágil

, principalmente por ser uma

forma eficiente de criar um software

operacional. Mas a documentação só será

útil se for lida, o que, na prática, quase

nunca acontece.

Quando entrego um documento de

requisitos de especificação que escrevi

para a equipe criar o software, esse

documento não é importante. Na verdade,

o essencial é que o que está na minha

cabeça coincida com o que está na

sua e na cabeça dos membros da equipe.

Em alguns casos de cálculos complexos

ou fluxos de trabalho, um documento

pode ser uma forma eficiente de viabilizar

um entendimento compartilhado que

permita a criação de excelentes softwares.

P: Ainda não entendi direito a ideia

da importância dos valores. Minha

equipe precisa deles para programas?

R: Os valores no Manifesto Ágil

servem para orientar você e sua equipe a

adotarem uma mentalidade que estimule

a criação de softwares melhores. Como

já vimos, a mentalidade e a atitude em

relação às práticas utilizadas fazem uma

grande diferença.

Considere o exemplo do último capítulo,

em que Kate e Mike tiveram problemas

com a reunião diária. Kate só obteve

resultados medíocres quando aproveitou

a ocasião para explicar seu plano e exigir

atualizações de status da equipe. Os

resultados só melhoraram com o advento

de uma atitude mais colaborativa. É assim

que a mentalidade exerce um grande

efeito sobre os resultados no mundo real.