Escolar Documentos
Profissional Documentos
Cultura Documentos
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
A
Software pela UFES. Tem mais de 12 anos utilizao de metodologias competitivo. As prticas geis iniciaram
de experincia profissional na rea de en- geis em projetos de desenvol- sua aplicao em organizaes de pe-
genharia de software, atuando principal- vimento de software j uma queno porte, apesar de terem mostrado,
mente como arquiteto de software J2EE.
realidade, sendo motivada principal- ao longo dos ltimos anos, que tambm
Utiliza o framework Scrum h trs anos e
atualmente engenheiro de software no mente por sua caracterstica dinmica, podem ser utilizadas em corporaes de
servio pblico federal. exigncia de um mercado cada vez mais mdio e grande porte, onde comum a
implementao de prticas formais de melhoria de processo Metfora: traduo das palavras do cliente para facilitar a
de software, dada a necessidade de se repetir e melhorar os comunicao com o desenvolvedor;
resultados obtidos em todos os projetos do portflio organi- Projeto Simples: preciso ter foco na funcionalidade mais
zacional. Os modelos de melhoria de processos de software importante para cada iterao;
mais utilizados no Brasil so o CMMI e MPS.BR, considerados Testes de Aceitao: testes construdos pelo cliente em
referncia para empresas que desejam elaborar processos conjunto com analistas e testadores para aceitao de deter-
otimizados e maduros. minados requisitos;
Muitos adeptos dessas metodologias defendem que mo- Programao em Pares: Desenvolvedor experiente e iniciante
delos de melhoria de software, como o CMMI e MPS.BR, e programando juntos buscando amadurecimento do iniciante e
metodologias geis divergem entre si em conceito e propsito, proporcionando a reviso do cdigo em busca de diminuio
impossibilitando que possam ser integrados. Talvez esse tipo de defeitos;
de reao se deva ao aparente antagonismo de princpios en- Refatorao: proporciona melhoria contnua da progra-
tre elas ou, at mesmo, por simples orgulho proveniente do mao, mantendo a compatibilidade com cdigo original,
comportamento humano. diminuio de erros e duplicaes de cdigo;
Na observao criteriosa dos processos e prticas do CMMI Propriedade Coletiva: onde o cdigo no tem dono, pro-
e MPS.BR e alguns mtodos propostos pelo manifesto gil, porcionando que todos alterem qualquer parte do programa
possvel perceber que ambos se complementam, ou seja, e conheam todas as suas partes;
perfeitamente vivel definir um processo de software Integrao Contnua: a cada nova funcionalidade produzida,
aderente a modelos de maturidade e utilizar mtodos geis feita a integrao ao cdigo existente para que se saiba a real
para sua implementao prtica. A tendncia que os be- situao da programao;
nefcios desses dois diferentes paradigmas sejam somados, Semana de 40 horas: horas extras s devem ser permitidas
possibilitando o desenvolvimento de software mais eficiente caso haja motivao suficiente para boa produtividade;
e maduro. Reunies em p: reunies rpidas e produtivas evitando a
perda de foco;
Metodologias geis Padronizao de Cdigo: o cdigo de todos os desenvolve-
Em 2001 foi criado o Manifesto gil, movimento cuja essncia dores deve ser padronizado, permitindo que todos possam
o desenvolvimento de software respeitando os seguintes manter qualquer parte do sistema.
conceitos:
Pessoas e interaes, ao contrrio de processos e Estas prticas so claras, objetivas e especficas e utilizadas
ferramentas; no dia a dia dos membros de uma equipe de XP.
Software executvel, ao contrrio de documentao
abrangente; TDD (Test-Driven Development)
Colaborao do cliente sobre negociao do contrato; O Test-Driven Development uma tcnica de desenvolvimento
Respostas s mudanas, ao invs de seguir planos. onde, primeiramente, so definidos testes para todos os cen-
rios dos requisitos levantados e, em seguida, escrito o cdigo,
Vrias metodologias e ferramentas geis foram originadas que deve respeitar as restries impostas por eles. Dessa forma,
desse movimento, tendo como base os conceitos previamente o engenheiro tem a tendncia de entender melhor o problema,
listados. Dentre as metodologias geis existentes, algumas antes de implementar a soluo.
delas mais utilizadas no mercado so XP (Extreme Program- Apesar de no ser considerada uma tcnica exclusivamente
ming), TDD (Test-Driven Development), FDD (Feature-Driven relacionada ao XP, o TDD tem suas origens nele, sendo comu-
Development), SCRUM e Kanban. mente utilizado em projetos geis.
A maturidade de um processo tambm est diretamente com outras empresas. Todos os processos de um nvel devem
associada qualidade do produto resultante do mesmo. Po- atingir um determinado patamar de maturidade para evoluir
rm, a formalizao advinda de modelos de maturidade pode a um prximo nvel.
significar maior volume de documentos e grande nmero de
atividades. Isso pode burocratizar demasiadamente o processo As reas de processos do CMMI, distribudas entre os nveis
e prejudicar a produtividade da equipe, caso seja utilizada de de maturidade da representao por estgios, so exibidas na
forma incorreta. Tabela 1.
A utilizao de modelos de maturidade tem sido realizada Como se pode observar, h uma concentrao maior de reas
principalmente por organizaes de grande porte, devido aos de processos nos dois primeiros nveis de maturidade. Como
custos envolvidos em sua implantao e tambm pelo objetivo consequncia, ao implantar estes dois primeiros nveis, o
de atingir um nvel de maturidade certificado, permitindo uma impacto causado na organizao tende a ser muito alto.
colocao reconhecida no mercado.
Dois dos modelos de maturidade e melhoria de processos
de software mais utilizados no Brasil so o CMMI e MPS.BR,
que podem ser utilizados tanto em organizaes sem processo
de software definido, quanto naquelas que j possuem um
processo, mas desejam melhor-lo.
CMMI
O CMMI (Capability Maturity Model Integration) um modelo
desenvolvido pelo SEI (Software Engineering Institute) que indica
prticas especficas e genricas com o objetivo de obter um
nvel de maturidade (ou capacidade) em disciplinas especficas.
Est dividido em trs modelos:
CMMI para Desenvolvimento (CMMI-DEV), para o desen-
volvimento de servios e produtos;
CMMI para Aquisio (CMMI-ACQ), para aquisio e ter-
ceirizao de bens e servios;
CMMI para Servios (CMMI-SVC), para empresas presta-
doras de servios.
Verificao - VER
Validao - VAL
D Largamente Definido Projeto e Construo de Produto - PCP AP 1.1 AP 2.1 AP 2.2 AP 3.1 e AP 3.2
Integrao de Produto - ITP
Desenvolvimento de Requisitos - DRE
Medio - MED
Garantia de Qualidade - GQA
F Gerenciado AP 1.1 AP 2.1 e AP 2.2
Gerncia de Configurao - GCO
Aquisio - AQU
que sejam efetivamente aplicadas em equipes maiores, muito os demais mdulos do sistema numa verso executvel, per-
comuns em organizaes que adotam modelos de maturida- mitindo a resposta a erros inseridos de forma mais rpida.
de. Para isso, treinamentos adequados so necessrios e, em-
bora a abordagem gil valorize mais as pessoas e interaes Garantia da Qualidade (CMMI nvel 2, MPS.BR nvel F)
mais do que processos e ferramentas, possvel contar com A qualidade do desenvolvimento gil est relacionada
processos corretamente dimensionados e ferramentas certas principalmente qualidade do cdigo fonte do produto de
para atingir sucesso. software, que pode ser feita atravs de revises e inspees.
Outro ajuste indicado para a utilizao de tcnicas geis para Entretanto, atravs de algumas prticas do mtodo gil XP,
a definio de processos maduros a adoo de planos mais como refatorao, padronizao de cdigo e programao em
detalhados, exigidos pelos modelos de maturidade, apesar pares, a qualidade do cdigo melhorada de forma dinmica,
do princpio gil defender que as respostas s mudanas tem reduzindo a necessidade desses controles.
prioridade mais alta sobre a adeso a um plano. A refatorao possibilita a reestruturao do cdigo, tor-
nando-o mais limpo e coeso, reduzindo a insero de erros e
Mapeamento Agile X CMMI X MPS.BR facilitando a remoo dos mesmos. Ter escrita de cdigo pa-
Dentro deste contexto de adaptaes para a integrao de dronizado tambm contribui para a garantia da qualidade por
prticas geis e modelos de maturidade, possvel mapear facilitar a manuteno do software. Por sua vez, a programao
mtodos geis s reas de processos do CMMI e aos processos em pares permite que o cdigo seja validado no momento de
do MPS.BR, agrupando as vantagens dos dois paradigmas e sua escrita, diminuindo a quantidade de erros.
definindo processos melhores.
A seguir sero apresentados os processos do CMMI e MPS. Medio (CMMI nvel 2, MPS.BR nvel F)
BR onde se torna vivel e compatvel a utilizao de prticas A medio em projetos geis pode ser feita em dois nveis,
geis para sua implementao. utilizando o Scrum. O Daily Scrum permite que a evoluo
das tarefas seja medida dia a dia, proporcionando respostas
Gerncia de Requisitos (CMMI nvel 2, MPS.BR nvel G) mais rpidas. As ferramentas geis Kanban e Burndown Chart
O mtodo gil XP pode proporcionar diversos benefcios podem auxiliar neste processo.
na implementao deste processo, por ter o cliente como ator O Sprint Review Meeting realizado ao final de um Sprint
fundamental do projeto. Algumas das prticas utilizadas so: acumula os resultados do ciclo, permitindo aprendizado para
comunicao contnua, feedback e integrao contnua. o ciclo seguinte e projetos posteriores.
O mtodo gil Scrum fornece elementos essenciais na gern-
cia de requisitos, so eles: backlog, contendo as user stories e o Verificao (CMMI nvel 3, MPS.BR nvel D)
Product Owner, responsvel por controlar as stories. Alm disso, Este processo pode ser implementado pelos mtodos XP e
possvel obter melhoria contnua com o auxlio das reunies Scrum atravs das frequentes interaes entre equipe e clien-
dirias (daily meeting). te. A presena diria do Product Owner ganha destaque nesta
O mtodo FDD pode contribuir com este processo atravs de disciplina, impedindo que o desenvolvimento fuja do escopo
lista de Features e relatrios de progresso do projeto atrelado requerido e permitindo que mudanas de requisitos sejam
aos requisitos. realizadas com o menor custo possvel.
O TDD tambm podem ser teis para a verificao, por criar
Gerncia de Projetos (CMMI nvel 2, MPS.BR nvel G) testes aderentes aos requisitos antes mesmo da construo,
O processo de gerenciamento de projetos est intimamente dificultando os desvios de escopo.
ligado ao Scrum como um todo, dado que esse tem esse pro-
cesso como principal objetivo. Validao (CMMI nvel 3, MPS.BR nvel D)
Apesar de no possurem funes idnticas, o Scrum Mas- Existem duas formas geis muito utilizadas para validar se
ter executa atividades similares a de um gerente de projetos, o produto est sendo desenvolvido corretamente:
como remoo de impedimentos e organizao de reunies Atravs da prtica XP de programao em pares, onde o
de integrao entre membros da equipe. cdigo validado durante sua construo;
Alm disso, as ferramentas geis Kanban e Burndown Chart Por meio do TDD, onde os testes antecipados diminuem os
podem ser utilizadas em conjunto para auxiliar o controle de riscos de desvios e erros.
atividades da equipe durante um Sprint.
Mais uma vez, a natureza interativa e cclica da prtica gil
gerncia de Configurao (CMMi nvel 2, MPS. permite que o produto seja frequentemente validado pelos
BR nvel F) membros da equipe e pelo cliente.
A caracterstica dinmica e interativa dos projetos geis di-
reciona este processo para a integrao contnua. Isso significa Integrao do Produto (CMMI nvel 3, MPS.BR nvel D)
que, a cada commit de cdigo no repositrio de desenvolvi- Atravs da prtica XP de integrao contnua o produto pode
mento do projeto, feita integrao entre o que foi inserido e ser integrado a cada alterao de cdigo. Isso permite que
s
D
os processos do CMMI e MPS.BR. A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Assim, no preciso definir um processo de desenvolvi- Para isso, precisamos saber o que voc, leitor, acha da revista!
s
ta
edio
mento de software rgido que integre metodologias geis e D seu voto sobre este artigo, atravs do link:
modelos de maturidade. possvel flexibilizar a utilizao www.devmedia.com.br/esmag/feedback
de mtodos geis e modelos de maturidade de acordo com as
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Como formar Times de alta performance: equipes, organizaes ou grupos virtuais, que so
Diversas metodologias foram criadas para siste- altamente focados nas suas metas e alcanam re-
matizar o desenvolvimento de software. Tais me- sultados de negcio surpreendentes.
todologias podem ser divididas em tradicionais, No existe um modo de aplicar um questionrio
que enfatizam a documentao de cada processo e dizer com certeza que um time de alta per-
do desenvolvimento de software, ou geis, que formance. O cliente deve perceber a evoluo
consideram um novo paradigma de desenvolvi- dos times e reconhec-los como tal. Para isso,
mento de software. Os mtodos geis focam em importante extrair informaes e mtricas que
Danilo Cereda simplicidade, software funcional no incio das indiquem que o seu time est na direo certa, de
danilo.cereda@gmail.com iteraes, flexibilidade e intensa comunicao, modo que a avaliao do time no fique somente
Graduado na rea de TI, com 7 anos de tanto internamente quanto com clientes. Alm na percepo superficial do cliente e sim em uma
experincia em desenvolvimento de disso, aplicam o desenvolvimento iterativo e in- percepo formada por fatos concretos.
Software e 11 anos de experincia profissio- Este artigo retrata tcnicas e experincias em pro-
cremental, planejamento adaptativo, flexibilidade
nal atuando na rea de desenvolvimento de
sistemas WEB, sendo os ltimos 3 dedicados e rpida resposta a mudanas. jetos Scrum relacionadas formao de times de
liderana de equipes e coordenao de O Scrum uma metodologia gil para gerncia alta performance e demonstrao de ganho para o
projetos utilizando metodologia gil e o de projetos, baseado em inspeo e adaptao, cliente atravs de mtricas de projeto.
framework Scrum. Atualmente atua como iterativo e incremental, e pode ser aplicado a
Lder / Scrum Master em Campinas na Ci&T
qualquer produto ou no gerenciamento de qual- Em que situao o tema til:
(multinacional brasileira especializada em
consultoria e outsourcing de aplicaes vol- quer atividade complexa. Assim, o Scrum um Este artigo fornece uma viso geral de formao
tadas para agilidade nos negcios). processo leve para gerenciar e controlar projetos de times geis e como desenvolve-los de modo a
de desenvolvimento de software e para criao de ganhar performance, at que possa ser chamado
produtos. Cada iterao dura aproximadamente de um Time de Alta Performance. So apresenta-
Fabio Pallini trinta dias, sendo conhecida como Sprint. Ao final das tcnicas que podem ser aplicadas a projetos
fmpallini@gmail.com de cada Sprint deve ser entregue ao cliente parte geis para dar viso objetiva ao time de desenvol-
Graduado na rea de TI possui 3 anos de do produto concludo e funcional. vimento e ao cliente, sobre a qualidade e produti-
experincia em desenvolvimento gil. Times de Alta Performance um conceito dentro vidade das equipes.
Certificado como Professional Scrum Mas-
do desenvolvimento das organizaes referente a
ter pela Scrum.org, atualmente trabalha na
Ci&T Campinas.
O Scrum prega que quanto mais multidisciplinar for um Mas e a qualidade? Por que a qualidade no negocivel?
time, melhor ser para o projeto. Se possvel, o time todo deve O pilar qualidade fica entre os trs vrtices, o que impossibili-
ser capaz de planejar, executar e testar estrias, assim como ta que seja negociado. Qualquer problema com qualidade gera
executar tarefas de Front-end e Back-end, com praticamente impacto direto em custo, prazo e/ou escopo. No existe motivo
o mesmo esforo. Porm, sempre haver pessoas com mais para diminuir a qualidade, mesmo que a falta de cuidado com a
facilidade para um tipo de atividade e menos para outro tipo, qualidade parea atraente por diminuir o custo, como nos casos
mas deve haver o incentivo a multidisciplinaridade e o trabalho que h diminuio no time de testes ou no escopo de testes, por
conjunto sempre que possvel, o que auxilia ter um time menos exemplo. O problema que se no h garantia de qualidade,
sujeito a situaes imprevisveis. dificilmente haver como dizer que entregaremos no prazo ou
Qualquer empresa gostaria de ter em seus times somente que respeitaremos o custo. Ento o ganho aparente ser posto
pessoas com muitos anos de experincia comprovada, um em prova quando defeitos em desenvolvimento, homologao
time inteiro snior. Na maioria das vezes, isso no possvel, ou produo comearem a impactar negativamente no prazo
seja por motivo de falta de colaboradores com esse perfil no e no custo, um risco que no vale a pena correr.
mercado, seja pelo alto custo. O que deve estar claro que a Diante disso, existe um cuidado com times de desenvolvi-
no ser que o cenrio exija e possibilite um time de sniores, mento que no deve ser negligenciado, o de produzir com
o aconselhvel a fazer montar um time balanceado. Onde qualidade, acima de velocidade ou previsibilidade.
desenvolvedores menos experientes tenham apoio tcnico de
um desenvolvedor mais experiente, assim como um testador Desenvolvimento contnuo
jnior possa ser responsvel por executar os testes, enquanto Para atingir as metas de velocidade sem perder qualidade, o
um testador mais experiente possa ser responsabilizado pela ideal seria iniciar o projeto com um time de tcnicos especialis-
criao dos cenrios e validao dos requisitos, de modo a focar tas nas tecnologias do projeto, com profundo conhecimento no
em planejamento e no na execuo de testes. negcio, no cliente e comprometido com a entrega do produto.
Na maioria das vezes, o sucesso de um projeto tem uma rela- Esta realidade possvel para equipes que desenvolvem pro-
o direta entre o equilbrio de qualidade, custo e prazo. dutos diretamente para a empresa onde atuam, trabalhando
em conjunto com a rea de negcio e com conhecimento prvio
Pilares: Escopo x Custo x Prazo do sistema que ser criado ou evoludo.
As trs primeiras reas a serem estudadas pelo PMI (Project Esta no a realidade das consultorias e fbricas de softwa-
Management Institute), Escopo, Custo e Prazo, ajudaram re, pelo fato de que tanto na contratao dos profissionais,
a formar um diagrama, chamado de Trinmio Sagrado do quanto na formao da equipe, no existe garantia de que
Gerenciamento de Projetos. Este diagrama mostra resultados os colaboradores tenham conhecimento tcnico necessrio.
das variaes sobre o escopo, custo e prazo do projeto e seu Dificilmente os colaboradores conhecero o negcio do cliente
impacto na qualidade. antes de iniciar o projeto e muito menos haver garantia de que
Para o sucesso de um projeto necessrio equilibrar esses todos estejam comprometidos com a entrega. Por este motivo
trs pilares, que so relacionados como vrtices de um trin- importante entender que times diferentes, compostos por
gulo (veja a Figura 1). Se a opo for um custo menor, deve-se pessoas com nvel tcnico e de maturidade diversificados, tero
aumentar o prazo ou reduzir o escopo. Se a busca for pela incio de projeto com resultados diferentes. Por isso, quando
entrega em menor prazo, provavelmente haver um custo no existe garantia de iniciar um projeto com alto rendimen-
maior ou ser necessria reduo do escopo. to, os colaboradores devem ser conduzidos pelo processo de
melhoria contnua, de forma a serem capazes de alcanar o
desenvolvimento tcnico e pessoal necessrio para atender a
necessidades identificadas.
O Scrum um framework iterativo, baseado em ciclos de PDCA;
sigla em ingls que significa Planejar, Executar, Validar e Atuar
(Plan, Do, Check, Act). Deste modo, as fases que compem uma
iterao (ou ciclo) devem ser analisadas para dar aos times
insumos para o desenvolvimento, aumentando a percepo
do prprio time sobre seus pontos fortes e de melhoria.
Com o foco na melhoria contnua e considerando o aprovei-
tamento mximo e feedback das iteraes, alguns pontos de
ateno devem ser levados em considerao, os quais sero
analisados na sequncia.
reconhecer os momentos onde o time precisa de ajuda para se e o cliente, todos devem ter ferramentas para acompanhar os
desenvolver, podendo ser atravs de um treinamento, que pode resultados dos Sprints de modo claro e intuitivo.
ser realizado no dia a dia do Sprint, direcionado para a soluo Com todas estas diretivas se cria um ambiente com condies
do problema ou de um treinamento mais formal. O que importa para o time se desenvolver, afinal, o prprio time deve ser
que o time entenda que tem um problema a resolver e seja capaz de visualizar sua condio atual e o caminho para se
encorajado a se desenvolver, tendo apoio para isso. No caso tornar melhor. Aes de melhoria e corretivas podem ser pla-
de ter um colaborador do time com dificuldades, sugerido nejadas e executadas, mas se o time no estiver comprometido
treinamento especfico de forma a equalizar o conhecimento a evoluir, no se tornar um HPT.
em que ele esteja defasado dos demais.
O cliente enxerga a alta performance do seu time?
Exibir claramente os resultados sobre as metas aceitas No momento da entrega, pouco vale o fornecedor estar
O PO uma das chaves para o sucesso do projeto. Ele deve orgulhoso do seu time HPT e do produto construdo, se o
acreditar no Scrum e defender seu uso perante os stackeholders cliente no enxerga o mesmo. Mas, como medir e demonstrar
e sponsors do projeto. O sucesso ou a falha da entrega do time performance para seu cliente?
o sucesso ou a falha da entrega do PO, que sabe o valor de cada O cliente muitas vezes quer saber quantas horas/minutos/
entrega, o compromisso firmado com o time e tem condies segundos o time levou para desenvolver cada estria, se con-
de justificar o desempenho do time se for questionado. sidera este dado o mais importante para seu planejamento.
De nada adianta o time estar orgulhoso em cumprir o acordo Dentro de um cenrio complexo de gesto de projeto muitas
do Sprint se ao apresentar o produto ao PO ele estiver com uma variveis interferem nas estimativas de entrega. Ento, porque
expectativa maior. Por isso importante que o acordo firmado no planejamento do Sprint se usa Story Points, em vez de estimar
na planning esteja alinhado com a expectativa do cliente, tam- o prazo de desenvolvimento em horas? Porque cada estria
bm importante ao PO conhecer e acreditar na metodologia, diferente da outra. Mesmo tendo levado trs dias para entregar
ou seja, entender as regras do jogo, de modo que participe ati- uma estria de treze Story Points, no existe garantia de que
vamente dos resultados, j que ele est construindo o produto uma estria, aparentemente parecida com os mesmo treze Story
junto ao time. Para que exista o comprometimento entre o time Points, ser entregue em trs dias tambm.
Previsibilidade
A mtrica de previsibilidade mede o desvio das datas de en-
trega, no momento do planejamento do roadmap sobre as datas Figura 2. Acompanhamento das entregas previstas e realizadas para
de entrega efetivas. Para o cliente, a capacidade de prever o Sprints de um release ou projeto
que ser entregue e quando. Para garantir uma medida correta
de previsibilidade importante manter o controle de Baseline Produtividade
do projeto, atualizando qualquer desvio ocorrido. Para medir A produtividade a capacidade de entrega de um time, sen-
o desvio aps a entrega de um Sprint necessrio realizar o do a quantidade de funcionalidades que um time consegue
grooming do backlog, ou seja, a anlise do backlog restante, com entregar em um perodo de tempo. Essa pode ser medida
foco em rever qual o esforo necessrio para entregar as demais utilizando a velocidade do time (velocity) em Story Points, essa
estrias e avaliar se essas foram alteradas para mais complexas velocidade calculada pela quantidade de pontos que o time
ou menos complexas, com base na pontuao das estrias j consegue entregar por Sprint, considerando a quantidade de
entregues. Atravs de um backlog inicial pode ser gerado um desenvolvedores fixa ou a taxa resultante da quantidade total
release e um grfico de burndown que mostra na linha do tem- de Story Points dividida pela quantidade de desenvolvedores,
po a concluso dos Sprints de um release, para medir o quo caso o time sofra alteraes.
prximo do planejado se esta aps o trmino de cada sprint Deve ser considerado ganho positivo quando o time entrega
e deste modo demonstrar desvios por aumento de escopo de uma quantidade maior de Story Points do que no ltimo Sprint,
produto, consequente aumento do backlog. projetando velocidade crescente. Mas para este ganho ser real,
Com a percepo de desvios nas entregas dos Sprints, pode- o time deve mostrar que entrega realmente mais, pois, apenas
se replanejar datas do projeto ou cortar escopo, de modo a subir a pontuao das estrias gera uma viso errada de ganho
concretizar a entrega na data inicial proposta. Lembrando que de produtividade. importante fazer uma anlise comparativa
quando entra uma estria (funcionalidade) nova ou aumenta do tamanho das estrias Sprint a Sprint.
a complexidade de alguma existente no backlog, automatica- No final do Sprint podem ser comparadas as estrias e
mente necessita se despriorizar outra estria, de preferncia verificar se elas so do tamanho proposto inicialmente.
que entregue menor valor ao negcio. O escopo do projeto, que O importante manter as comparaes atualizadas, para que
forma o backlog, deve ser visto como um espao limitado, onde na prxima planning meetings as estimativas sejam baseadas
no cabem mais estrias e para que entre uma, outra de mesmo em valores atualizados.
tamanho deva sair. O importante que as trocas sejam feitas Acompanhando os valores da velocidade do time nos Sprints,
pelo PO, junto ao Scrum Master e/ou o time e devidamente o esperado que o time, ao adquirir maturidade, aumente sua
alinhadas com as reas de negcios. produtividade nos primeiros Sprints, mas em algum momento
No exemplo da Figura 2 pode ser acompanhado o total pre- ele deve estabilizar, pois atinge sua produtividade mxima.
visto de pontos que deveriam ser entregues em nove Sprints. O maior desafio, deste ponto em diante, manter estes valores
O grfico mostra atravs da linha verde (entrega executada) constantes, pois uma diferena negativa pode aparecer de um
que houve um atraso nos quatro primeiros Sprints, atravs Sprint para outro, por motivos que no podem ser controlados.
dos Story Points (SP) restantes acumulados. Acompanhando a O esperado que uma vez que o time atingiu um patamar m-
linha vermelha (entrega planejada), que mostra os Story Points ximo de produtividade, a mdia de Story Points dos ltimos se
restantes planejados para o final de cada Sprint, como pode ser mantenha estvel, com pouca variao em torno deste valor.
Links
[1] The Wisdom of Teams, escrito por Katzenbach, editora HarperBusiness, 2003
Figura 3. Acompanhamento da qualidade de implementao na fase de [2] JALOTE, Pankaj. CMM in practice: processes for executing software projects at
desenvolvimento atravs de um Burnup de defeitos Infosys. USA: Addison Wesley Longman, 1999.
s
D
diminuio progressiva nos prximos Sprints. A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que voc, leitor, acha da revista!
s
ta
Concluso
edio
D seu voto sobre este artigo, atravs do link:
Quem no gostaria de trabalhar sempre em times de alta per- www.devmedia.com.br/esmag/feedback
formance? Times que entregam muito, rpido e com qualidade.