Escolar Documentos
Profissional Documentos
Cultura Documentos
De sve ndando o
Fundamentos,
teoria e
prtica
Dicas super
interessantes
para quem j
utiliza .
Por Flvia Freire
time. compara.
de desenvolvimento de software.
Guilherme Chapiewski
alistair.cockburn.us/crystal/crystal.html
Cingapura, em 1997.
www.poppendieck.com
Ou Lean Thinking (Mentalidade Enxuta), denomina uma filosofia
de negcios baseada no Sistema Toyota de Produo que identifica o
que o desperdcio e o que o valor a partir da tica dos clientes e
usurios. As prticas envolvem criao de fluxos contnuos e sistemas
puxados, baseados na demanda real dos clientes, alm da anlise e
melhoria do fluxo de valor das plantas e da cadeia completa, desde as
matrias-primas at os produtos finais. Surgiu no Japo, logo aps a
Segunda Guerra Mundial.
www.dsdm.org
Ou Mtodo de desenvolvimento dinmico de sistemas. Originase de tcnicas de desenvolvimento rpido de aplicativos (RAD)
que enfatizam o envolvimento do usurio. Funciona melhor em
cenrios onde o aplicativo precisa funcionar em um ambiente
de computador complexo que o desenvolvedor no entende
muito bem. O DSDM Consortium desenvolveu esta metodologia
em 1990, no Reino Unido, para consolidar experincias com
melhores prticas de programao.
eXtremeProgramming (XP)www.extremeprogramming.org
Este mtodo enfatiza muito a adaptabilidade em vez da
previsibilidade. Funciona melhor em cenrios onde a
organizao no sabe, com exatido, de quais produtos
necessita. Foi idealizado por Kent Beck em 1996.
ele comea a entender melhor o que realmente precisa para resolver o problema dele, e novas idias vo surgindo. Se voc
no conhece o seu cliente, no sabe o problema que ele tem, nem o que ele quer exatamente, como voc pode desenvolver um
software para resolver o problema dele? aconselha o gerente de desenvolvimento de aplicaes Web na Globo.com, Danilo Bardusco.
Entenda o Ciclo do Scrum por Danilo Bardusco, responsvel pela evangelizao e implantao desta metodologia gil na Globo.com:
2
4
7
9
1) O ciclo comea com o Product Owner definindo uma viso de produto compartilhada com o time.
2) Essa viso ento transformada, junto com o time, no que chamamos de Product Backlog. O Product Backlog contm uma lista de requisitos de todos os entregveis para que
aquele produto faa sentido. Essa lista deve estar sempre priorizada por valor de negcio. Requisitos podem ser adicionados ou removidos a qualquer tempo, assim como a prioridade
tambm pode mudar. Ou seja, o Backlog precisa ser continuamente mantido pelo Product Owner, visando maximizar o retorno sobre o investimento.
3) Com o Backlog em mos, o time e o Product Owner fazem o Sprint Planning 1, onde ser definido o qu ser feito durante o Sprint. Essa a fase de documentao do
projeto. Histrias so refinadas, cenrios de aceitao so escritos, e scketches feitos por designers podem ajudar a melhorar o entendimento do que precisa ser feito. As histrias
selecionadas, com os demais artefatos produzidos na reunio de trabalho, formam o Selected Product Backlog.
4) O Selected Product Backlog o resultado do Sprint Planning 1, e define a quantidade de trabalho com a qual o time se comprometeu a entregar naquele Sprint. Ele se
mantm inalterado durante todo o Sprint.
5) O Sprint Planning 2 a hora de definir como a soluo ser implementada. a fase de modelagem do projeto. Nela, o time deve identificar as melhores solues para
resolver cada um dos problemas, identificando as tarefas necessrias para atingir o objetivo.
6) O resultado do Sprint Planning 2 o Sprint Backlog, uma lista de atividades necessrias para entregar a verso final das funcionalidades que sero aceitas pelo cliente.
7) Comea o Sprint. a fase de construo, onde diariamente o time se rene para sincronizar o trabalho que est sendo feito. O ciclo menor representa o primeira iterao,
em geral de duas a quatro semanas, onde todas as fases do projeto so exercitadas para que seja possvel concluir um incremento de funcionalidade pronto para ser utilizado. Dentro
deste, o ciclo maior representa as iteraes dirias onde o time se replaneja constantemente para achar solues aos problemas que surgem durante o desenvolvimento.
8) Ao final do Sprint, uma reunio de Review acontece, onde so apresentadas ao cliente as funcionalidades que esto disponveis para o uso. O cliente pode aceitar ou rejeitar as
funcionalidades nesse momento, alm de sugerir melhorias ou novas ideias.
9) Finalmente, para encerrar o ciclo de melhoria contnua, acontece a Retrospectiva do Sprint, onde ser identificado o que deu certo e o que deu errado no Sprint. So
identificados pontos de melhoria no processo e levantados impedimentos que atrapalham o melhor desempenho do time. Esse um momento de reflexo do time, que precisa se sentir
seguro para falar tudo o que tem que ser dito. Por isso, participam desta reunio apenas os prprios membros do time e o ScrumMaster, fazendo a moderao. Qualquer exceo s
deve acontecer pela solicitao do prprio time.
O resultado
No faltam bons exemplos de resultados positivos em empresas
brasileiras que adaptaram o Scrum aos seus projetos. A Provider Sistemas
comeou a aplicar Scrum em abril de 2008, aps um treinamento no
oficial sobre Scrum feito por Igor Macabas, ScrumMaster e Agile Coach
da empresa. Durante quatro meses, convertemos todos os projetos
da empresa para Scrum. Hoje, temos quatro projetos rodando
simultaneamente, com cerca de trinta desenvolvedores trabalhando.
Isso s foi possvel porque tivemos muito apoio da alta direo da
empresa, que percebeu de imediato os grandes benefcios e ganhos
que o mtodo possibilitou ao nosso processo de desenvolvimento:
ganhamos transparncia, visibilidade, previsibilidade, agilidade nas
entregas, e melhoria contnua no nosso processo. Como a cultura da
empresa j estava permeada com o conceito de melhoria contnua,
pois j tnhamos certificaes ISO 9001 e MPS.BR nvel G antes
do Scrum, aplicar o Scrum na organizao nos ajudou a ser ainda
melhores. Aps nossa implementao do Scrum, j passamos por
uma re-certificao da ISO, e estamos atualmente trabalhando para
aumentar o nosso nvel de maturidade do MPS.BR (www.softex.
br/mpsbr) do nvel G para o nvel F que equivalente ao CMMi
nvel 2. Tudo isso usando Scrum, aliado aos valores e princpios do
manifesto gil, e s prticas de engenharia consistentes como
programao em par, integrao contnua, reunies stand-up
(reunies em p de quinze minutos), refatorao, TDD etc. conta
conta Igor.