Va 04

O seu canal sobre processos geis
Integrao Contnua lbum da Viso gil no FISL 9.0 lbum do Encontro da comunidade de Metodologias geis do RS As 5 Doenas do Gerenciamento de Projetos
Causa n 4: Dependncia Entre Tarefas
Avalie o comportamento ideal de um ScrumMaster e suas habilidades vitais
ScrumMaster por ele mesmo

Nove Pecados Mortais no Planejamento de Projetos Aperfeioamento de Projetos geis - Parte II
Gerenciamento de resultados Cobertura da QConference com o Product Storage Chart 2008 em Londres News e Referncias geis
Ano Viso gil Edio 04 Edio 04 Revista II
-Voltar www.visaoagil.com 1 para o Sprint Backlog
Sprint Backlog
Conhea os temas selecionados para essa edio(iterao).
As 5 Doenas do Gerenciamento de Projetos
Pgina 05
Ir direto...
Integrao Contnua
Pgina 10 Ir direto...
Aperfeioamento de Projetos geis Parte II

Nove Pecados Mortais no Planejamento de Projetos

News

Referncias geis
lbum do Encontro da comunidade de Metodologias geis do RS

Cobertura da QConference 2008 em Londres

lbum da Viso gil no FISL 9.0

Gerenciamento de resultados com o Product Storage Chart

2
Revista Viso gil Edio 04
Voltar para o Sprint Backlog
Editorial
Agile como vantagem competitiva Equipe Viso gil Diretor Editorial:
Manoel Pimentel Medeiros,CSP
No mundo inteiro, estamos vivendo um momento interessante no cenrio Agile, pois cada vez mais temos novas empresas adotando algum processo gil, um nmero maior de profissionais est se dedicando a consultoria especializada sobre o assunto, muitos blogs tm surgido para trazer temas relacionados aos processos geis, as comunidades esto ficando cada vez maiores e mais participativas. Mas ao contrrio do que se pensa com esse cenrio, Agile ainda no "bola da vez", pois ainda falta muita coisa acontecer para que isso seja uma verdade absoluta e isso depender de um grande esforo conjunto de toda a comunidade. Porm, nos ltimos anos fui consolidando uma viso particular sobre o mercado de desenvolvimento de software, pois vejo queamecnica desse mercado se assemelhaao conceito "Yin & Yang",ou seja, s h Agilidade se houver Cascata". Traduzindo: NO acredito quea maioria dasempresas ir adotar Agile em seus processos, e na verdade acho isso MUITO BOM, pois dessa forma, as empresas que realmente esto adotando,continuaro a ter uma vantagem competitiva sobre as que no adotam. Na verdadeficaria muito chato se todas as empresas tivessem a mesma produtividade e trabalhassem seguindo as mesmas idias, pois a beleza deusar agile exatamente essa: "mostrar que possvel ser mais produtivo que seus concorrentes". Porm, caso voc tambm queira que sua organizao mudea forma de trabalhar e passe ter benefcios reais com a implantao de agile, nessa quarta edio da Revista Viso gil, estamos com uma coleo de artigos bem especiais para turbinar a caixa de ferramentas de quem est implantando alguma metodologia gil em uma organizao, portanto, seja bem-vindo e boa leitura. Manoel Pimentel, CSP Diretor Editorial
Diretor de Marketing:
Alexandre Magno Figueiredo, CSP
Assessoria Administrativa:
Manuella Bulco Medeiros
Atendimento ao leitor
e-mail: manoel@visaoagil.com site: www.visaoagil.com
Edies Anteriores
Qualquer edio anterior pode ser baixada gratuitamente no site www.visaoagil.com
Artigos
Se voc est interessado em ver seus artigos sobre prticas agis pblicados em nossa revista, por favor envie-os para manoel@visaoagil.com para que possamos apreci-los. Sua colaborao sempre bem vinda.
Publicidade
Se voc est interessado em fazer alguma ao de marketing em parceria da Revista Viso gil, entre contato conosco atravs do email amagno@visaoagil.com, e teremos o maior prazer em trabalharmos juntos.
News
Veja aqui as novidades do mundo gil
InfoQ no Brasil A Fratech Tecnologia est em negociao para firmar uma parceiria estratgica com a InfoQ aqui no Brasil. Maiores informaes: www.fratech.net
Agile 2008 Em agosto acontecer em Toronto mais uma edio do principal evento gil do mundo, o Agile 2008. www.agile2008.org
Viso gil 2008 A Revista Viso gil junto aos grupos de usurios, realizar nos dias 19 e 20 de Setembro a conferncia sobre processos geis com profissionais do cenrio nacional e internacional. Participe: www.visaoagil.com Workshop Scrum com Rodrigo Yoshima 31 de maio em Belo Horizonte/MG www.aspercom.com.br
Palestra Was Socrates a ScrumMaster? com Alexandre Magno NYC Scrum Group - New York, USA 20 de julho amagno.blogspot.com
Ciclo de treinamentos de Gesto gil daTeamware Novas turmas disponveis em vrias cidades do Brasil www.teamware.com.br
Artigo
As 5 Doenas do Gerenciamento de Projetos

Tradutor: Adail Muniz Retamal
diretor da Heptagon Tecnologia da Informao Ltda, empresa de consultoria e treinamento focada na aplicao da Teoria das Restries em geral, e da Corrente Crtica em particular, Engenharia de Software, metodologias geis de gerenciamento e desenvolvimento de software, Adail Engenheiro Eletricista/Eletrnico, atuou como consultor, instrutor e arquiteto de solues para a Borland Latin America por 4,5 anos. Lecionou em universidades pblicas e privadas. palestrante, articulista e est escrevendo um livro. Adail pode ser contatado em adail@heptagon.com.br.
Autor: Allan Elder

presidente da No Limits Leadership, Inc., uma empresa de consultoria dedicada a ajudar as organizaes a entregar mais projetos, mais rpido, atrves da liderana eficaz.
Em projetos, todas as tarefas dependem de outras. Em seu livro "The Mythical Man Month" ("O Mito do Homem-Ms"), Fred Brooks respondeu pergunta sobre como os projetos atrasam: "Um dia por vez". Voc j notou que se a data final do seu projeto desliza, quase impossvel recuper-la? Voc tambm j notou o quo fcil atrasar, mas o quanto difcil adiantar? Se j, ento voc entende os problemas criados pela dependncia entre tarefas. Um efeito negativo causado pela dependncia entre tarefas explicado no seguinte exemplo. Voc tem uma tarefa que foi estimada em 5 dias, incluindo a segurana, a inicia imediatamente e a completa "mais cedo". A pessoa que recebe sua sada est pronta para us-la imediatamente? Geralmente no. Portanto, se voc entregar os resultados em 3 dias, a prxima pessoa no vai toc-los por 2 dias adicionais, porque ela no est agendada para comear a tarefa dela at aquele dia. Assim, a segurana embutida perdida, mesmo com a tarefa sendo terminada antes. Para superar esse problema voc precisa ter um sistema de projetos que garanta que todas as tarefas comecem, no quando elas esto agendadas para comear, mas quando as entradas necessrias estiverem disponveis. Isso especialmente vital com as tarefas no caminho crtico (ou na corrente crtica). Revista Viso gil Edio 04 Voltar para o Sprint Backlog 5
As 5 Doenas do gerenciamento de Projetos
Outro teoria da
efeito
negativo
causado chamado
pela de
dependncia entre tarefas bem conhecido na probabilidade, "probabilidade de eventos dependentes" (tambm conhecido por outros nomes). Essa teoria afirma que o tempo total requerido para eventos dependentes, em termos de probabilidade, o produto da probabilidade de todos os eventos dependentes. Veja como isso impacta voc (Figura 7). Se voc tem trs tarefas que so dependentes uma da outra, e cada uma tem uma chance de 90% de ser terminada no prazo, qual a probabilidade de todas as trs serem completadas no prazo? Cerca de 73%! Devemos calcular a probabilidade de terminar a Tarefa-1 (90%) e depois calcular a probabilidade de terminar a Tarefa-2, dada sua dependncia com a Tarefa-1 (90% x 90% = 81%). Como pode ver, a probabilidade de terminar a Tarefa-1 e a Tarefa-2 no prazo de apenas 81%. Podemos ento calcular a probabilidade de completar a Tarefa-3, dada sua dependncia com a Tarefa-1 e a Tarefa-2 serem completadas no prazo (90% x 90% x 90% ? 73%). Com apenas trs tarefas, cada uma com 90% de chance de terminar como prometido, h apenas uma chance de 73% de terminarmos, de fato, todas as trs como prometido. No precisamos de muitas tarefas para alcanar uma probabilidade zero de terminar o projeto no prazo. Voc pode estar pensando: "Eu no tenho esse problema, porque eu realizo as tarefas em paralelo, em vez de em srie." Vamos examinar esta soluo (Figura 8). Se cada tarefa possui uma chance de 90% de ser feita como planejado, qual a chance do projeto todo terminar no prazo? Sua primeira reao pode ser 90%. Porm, j que o trmino do projeto depende do trmino de todas as tarefas, devemos usar o produto de cada evento dependente para determinar o tempo provvel de trmino. Neste caso, vamos multiplicar 90% de cada tarefa em paralelo, obtendo a mesma chance de 73% de trmino no prazo. Agora voc pode ver porque tentar fazer com que cada tarefa termine no prazo no significa que o projeto terminar no prazo. Ser exigido que toda tarefa dependente termine como planejado, para que o projeto termine no prazo. Esse efeito fez com que os gerentes de projetos conclussem que a nica forma de terminar um projeto no prazo garantir que todas as tarefas, realmente, terminem no prazo. Tal soluo exigiria que todas as tarefas sejam estimadas com 100% de preciso. Mesmo se isso fosse possvel, faria com que os tempos das tarefas tivessem uma durao inimaginvel. Para entender melhor como os atrasos so passados adiante, mas os adiantamentos no, examine a Figura 9. Este projeto foi planejado para durar 17 dias.
O quanto adiantado ele poderia terminar se a primeira tarefa estivesse cinco dias adiantada? Os mesmos 17 dias. A razo que ns somos dependentes do trmino de todas as cinco tarefas. Portanto, mesmo se uma tarefa estiver adiantada, o projeto no terminar adiantado em nada. E se as primeiras quatro tarefas terminassem 5 dias antes? A durao do projeto ainda seria de 17 dias. Agora pense na durao do projeto se apenas uma tarefa atrasar 5 dias. O projeto levaria 22 dias. Como podemos ver, adiantamentos no so passados adiante, atrasos sempre so. Uma dependncia adicional no discutida, e geralmente proibida na metodologia do caminho crtico, a dependncia de recursos. Na imagem seguinte (Figura 10), temos um projeto que inclui dependncias de tarefas e de recursos. Note que as tarefas A e D ambas requerem o uso do recurso "programador". Para completar as tarefas C e D temos que completar A e B. Para iniciar a tarefa D tambm precisamos completar a tarefa A, devido dependncia de recurso. Dado que cada tarefa possui uma probabilidade de terminar no prazo de 90%, qual a probabilidade deste projeto terminar no prazo? Apenas 73%! Embora no haja uma seta ligando a tarefa A tarefa D, a dependncia permanece. Com essa dependncia encontramos todos os problemas mencionados previamente. Entretanto, dependncias de recursos no so calculadas em redes de projetos tradicionais. Vamos examinar o ciclo vicioso de lgica que ocorre devido ao fato de fazer as estimativas se tornarem compromissos. Lembre-se que as pessoas querem ser vistas como confiveis e, portanto, tentam completar as tarefas o mais prximo da data compromissada quanto possvel. Isto impede que a proteo seja removida nas estimativas futuras e as ajuda a serem vistas como confiveis. Quando um projeto est atrasado, qual a resposta tpica? Conduza uma atividade de lies aprendidas e identifique as tarefas que atrasaram o projeto. Qual o comportamento criado por essa descoberta? Da prxima vez que criarmos um plano de projeto, adicionaremos mais segurana e detalhes a esses tipos de tarefas. Porm, se adicionarmos mais segurana e no mudarmos como medimos as pessoas, para permitir que os trminos antecipados e atrasados se compensem entre si, ento o projeto no terminar "no prazo" da prxima vez. Igualmente, se nas tarefas culpadas por atrasar o projeto adicionarem mais segurana, esse projeto ser planejado para durar ainda mais. Se os ganhos e os trminos antecipados no se compensarem e o projeto ainda no terminar no prazo, nas lies aprendidas descobriremos quais tarefas atrasaram o projeto.
Como voc pode ver, isso torna-se um lao negativo. Estamos atrasados, culpamos tarefas, adicionamos mais segurana, ficamos atrasados de novo, culpamos tarefas, adicionamos segurana, e assim por diante. Eventualmente, seus clientes procuraro seu concorrente, porque seus projetos demoram demais. Seus clientes determinam o quanto voc pode aumentar o cronograma por conta do gerenciamento deficiente. Uma ltima questo relacionada com tarefas que se integram umas com as outras. Qualquer lugar em que h integrao de tarefas h riscos adicionais. As coisas nem sempre se encaixam como esperamos. O que acontece quando tarefas que se integram tm problemas? O projeto atrasado. Sim, voc poderia colocar mais segurana nesses pontos, mas ela seria desperdiada como j descrito. Esse problema pode ser superado apenas por um mtodo de agendamento que considere a variao e a incerteza nas duraes das tarefas. Ele no pode ser superado simplesmente declarando que as pessoas "devem" terminar no prazo. O mtodo de agendamento que gerencia essas questes chamado Corrente Crtica. Encorajo os leitores a lerem "Corrente Crtica", de Eliyahu Goldratt, para mais informao sobre o assunto.
Workshop sobre Modelagem gil e DDD

Um passeio pela MDA (Model Driven Architeture) Conhecendo a DDD (Domain Driven Design) O que DDD Para que usar DDD Arquitetura em Camadas (Layered Architecture) Domain Objects Linguagem Onipresente (Ubiquitous Language) Design Flexvel(Supple Design) Design Estratgico (Strategic Design) O Manifesto gil Engenharia de requisitos com Scrum, XP e FDD Testes geis Documentao gil Explorando a viso arquitetural M3 - Modelagem Baseada em Mapas Mentais UML em Cores Uso de prototipao AgileDraw
Organizao:
Um projeto do "zero" - Dinmicas Prticas
Informaes pelo site: www.fratech.net

Carga Horria: 16h Data: 13 a 14 de Junho/2008 Local: Universidade Anhembi Morumbi So Paulo(SP)
Referncias geis
Veja aqui, alguns sites e blogs indispensveis para o mundo gil
Blog de Alisson Vale, Um dos pioneiros na utilizao e divulgao de mtodos geis aqui no Brasil. Devido sua grande experincia como lder e diretor de projetos da empresa Phidelis, tornou-se um dos mais respeitados autores nacionais sobre agile e afins. URL: http://www.phidelis.com.br/blogs/alissonvale
Blog do renomado Mike Cohn, um dos personagens internacionais mais bem conceituado quando o assunto a aplicao da metodologia Scrum em um projeto de software. URL: blog.mountaingoatsoftware.com
Artigo
Integrao Contnua
Seu sistema ao alcance de um clique
Autor: Victor Hugo Germano Bacharel em Cincia da Computao e Especializado em Gesto Estratgica de TI. Atualmente atua como integrante do Escritrio de Projetos na empresa Audaces Automao, auxiliando no processo de implantao de metodologias geis em Desenvolvimento de Software. Autor do blog A Maldita Comdia, tambm participa do grupo de desenvolvedores do Coding Dojo Floripa. Pode ser contatado atravs do correio eletrnico: victorhg@gmail.com
Normalmente subestimado pelas equipes, o perodo de integrao do cdigo e dos subsistemas dentro de um projeto pode facilmente ser o principal vilo na liberao de um release. Esta falta de preocupao em criar, o quanto antes, um produto finalizado levar a atrasos em entregas e desculpas comuns como "mas funcionava na minha mquina". Em uma equipe com vrios desenvolvedores, qual a melhor forma de unificar as diversas alteraes feitas na base de cdigo? Processos geis utilizam a prtica conhecida como Integrao Contnua para solucionar essa questo. Integrao Contnua consiste em integrar o trabalho diversas vezes ao dia, assegurando que a base de cdigo permanea consistente ao final de cada integrao. Nesse artigo, voc conhecer os passos necessrios para usar essa prtica em seu dia-a-dia, e quais os benefcios para a sua sade e a sade de seu projeto.
10
Integrao Contnua
O que Integrao Contnua?

O processo de integrar um software no , nem de longe, um problema novo, ainda que no seja um problema real em um projeto solo, com poucas dependncias de sistemas externos. Entretanto, medida que a complexidade do projeto aumenta (adicionando mais uma pessoa, por exemplo), preciso garantir que os componentes de software funcionem juntos - precoce e frequentemente. Esperar at o final de um projeto para integrar seu cdigo pode levar a toda sorte de problemas de qualidade, que so extremamente caros e normalmente levam os projetos ao atraso. A Integrao Contnua (IC) trata estes riscos em pequenos incrementos. Em seu famoso artigo "Continuous
Isto significa que, segundo Paul Duval:
Todos os desenvolvedores executam a construo do
sistema antes de enviar qualquer cdigo ao repositrio de arquivos para assegurarem-se que suas mudanas no quebraram o build de integrao.
Desenvolvedores sincronizaro seus cdigo com o
repositrio de arquivo ao menos uma vez ao dia.
Builds de Integrao ocorrem vrias vezes ao dia num
servidor em separado .
100% dos testes devem passar. Um produto ser gerado (ex: WAR, executvel, JAR,
etc.) que poder ser funcionalmente testado.
Qualquer problema no processo
de construo
automtica possui prioridade mxima.
Alguns dos desenvolvedores revisam os relatrios
Integration", Martin Fowler descreve a IC como:
gerados no processo de construo, como mtricas para padres de cdigo e relatrios de anlise de dependncia, buscando reas para melhoria.
"... uma prtica de desenvolvimento de software onde os membros de uma equipe integram seu trabalho frequentemente, normalmente ao menos uma vez ao dia para cada pessoa - levando a mltiplas integraes dirias. Cada uma destas integraes verificada por um processo de build automatizado (incluindo testes) para detectar erros de integrao o mais rpido possvel. Muitas equipes j identificaram que esta abordagem leva reduo significativa de problemas de integrao e permite equipe desenvolver um software coeso mais rapidamente..."
O processo
11
Integrao Contnua
Paul Duval, em seu livro Continuous Integration, descreve o cenrio acima da seguinte maneira: O desenvolvedor envia o cdigo para o controle de verso (SVN, CVS, etc). Enquanto isso a mquina de integrao (servidor de Integrao Contnua) est "ouvindo" o repositrio buscando por modificaes.
Teste
Muitos consideram Integrao Contnua sem testes automatizados uma farsa. E no poderia deixar de concordar. Sem a validao automatizada de requisitos de negcio, funcionalidades e correes de bugs, no h como garantir a confiabilidade do software. A maior parte dos desenvolvedores em um ambiente de IC utiliza ferramentas como JUnit, NUnit ou qualquer outra xUnit para executar testes. Entretanto, possvel que esta fase da construo do software se encarregue de validar vrios outros aspectos, no apenas testes unitrios. Podemos citar: testes de carga/performance, segurana, sistema e requisitos de negcio.
Logo aps um commit ser efetuado, o servidor identificar a mudana no cdigo. Inicia-se o processo de build baixando os arquivos do Servidor de Controle de Verso. Assim, o script de build executado, testes so realizados, relatrios gerados, e todo o projeto integrado.
O Servidor de Integrao envia por e-mail ou outros dispositivos o feedback sobre o build para usurios especficos do projeto.
O servidor volta ao estado de Pull buscando por mudanas no repositrio.
Inspeo
Automatizar a inspeo de cdigo, por exemplo anlise dinmica ou esttica pode ser utilizado para auxiliar na melhoria da qualidade do software atravs do estabelecimento de regras. Por exemplo, um projeto pode determinar que nenhuma classe dever possuir mais de 300 linhas de cdigo no comentado, ou que os testes devem cobrir ao menos 90% das linhas de cdigo. A inteno remover a interveno humana neste processo, reduzindo custos - atualmente atribudos equipe de Quality Assurance -, e principalmente evitando o desgaste natural que pode acontecer. A nica interveno humana neste caso feita para a configurao de regras.
Um comportamento importantssimo: Esta arquitetura fora a equipe a manter sempre em funcionamento todo o cdigo fonte que existir no repositrio, adicionando mais controle a possveis problemas de implementao ou integrao.
Identificamos cinco fases principais:
Compilao
Praticamente o sinnimo de Integrao Contnua, j que o elemento mais bsico de todo o processo de construo e integrao. A gerao de cdigo binrio requisito para o sucesso das outras fases. Obviamente, normal que em linguagens dinmicas como Python, PHP ou Ruby esta fase se torne nebulosa, e o processo de criao de um binrio possa ser substitudo por uma ateno mais minuciosa fase de teste e inspeo.
Implantao
a forma de garantir, a qualquer momento, a disponibilidade de uma verso compilada, testada e pronta para o uso. Este o ponto principal de todo o processo de Integrao Contnua. Este o foco: criar, vrias vezes ao dia, uma verso estvel, inspecionada por mtricas de qualidade e testada, pronta para se avaliada pelo cliente. Que tal, til?
12
Integrao Contnua
Feedback Contnuo e Documentao

A dificuldade em criar documentaes por parte dos desenvolvedores pode ser diminuda - seja o problema em escrever ao invs de codificar, ou o custo em manter diagramas e documentaes de cdigo em tempo real. JavaDoc, NDoc, Maven e doxygen so exemplos muito teis para agilizar a produo de documentaes. A gerao de relatrios e mtricas
Erros podem ser encontrados no momento que eles so introduzidos ao sistema, ao invs de esperar algumas semanas por um ciclo de uma rea de testes. Incorporando testes e inspees contnuas em seu sistema, a sade de muitos atributos de software, como complexidade, pode ser rastreada no decorrer do tempo. Assim, diminua incertezas sobre ambientes e casos especficos: implemente-os em seu servidor de build e obtenha o resultado imediato!
automatizadas ser o ponto principal na melhoria da qualidade de software. Esquea pontos de funo finalizados ou linhas de cdigo produzido. V alm! De forma automatizada possvel visualizar o acoplamento de seu sistema, dependncia das classes, nmero de linha de cdigo por mtodo, conformidade com padres de formatao e design, quantidade de cdigos com problemas no repositrio ou todas as mtricas propostas por Bob Martin no livro Agile Software Development. Estes podem ser os principais insumos para uma anlise mais profunda e realmente relacionada produo de softwares com qualidade.
Reduo de Processos Repetitivos

Processos repetitivos executados por seres humanos, em nosso ambiente, devem ser considerados desperdcio! O Custo, esforo e tempo empregados poderiam ser utilizados para o processo criativo de produo de software. Parece obvio, certo? Mas pense bem sobre suas atividades dirias. Quais delas poderiam ser automatizadas? Quanto tempo voc dispende preparando um ambiente para produo? Quanto tempo demora para apresentar o seu sistema para um novo cliente?
Gerar software funcionando

Integrao Contnua permitir que voc entregue software em funcionamento a qualquer momento. Do ponto de vista do usurio ou cliente, este o maior benefcio da IC. Assim, adicionar pequenos incrementos
O Valor da Integrao Contnua Reduo de Riscos

Integrando seu cdigo vrias vezes ao dia, voc pode reduzir alguns dos riscos de seu projeto, facilitando deteco de defeitos, a mensurao da sade de seu cdigo e reduzindo o nmeros de incertezas.
de software a um sistema pode ser facilmente incorporado numa poltica de apresentao de funcionalidades. E mais ainda, implantados em produo imediatamente! Projetos que no utilizam essa prtica podem sofrer de muitos atrasos, pois ser sempre necessrio preparar um ambiente para validar a produo do software, sempre ao final de um ciclo de desenvolvimento.
13
Integrao Contnua
Ampliar a Visibilidade do Projeto

A IC ampliar suas possibilidades de inovaes e experimentao. Projetos podem sofrer por no possurem dados concretos para a tomada de deciso, j que normalmente decises sobre cdigo e arquitetura so tomadas baseadas no sentimento dos desenvolvedores, no em mtricas. Tentar conseguir informaes manualmente pode facilmente levar inutilizao de qualquer documentao no tempo, devido dificuldade de aferir as mtricas propostas neste artigo. Assim, uma equipe poder partir para uma implementao arriscada, ou ainda tentar a utilizao de novas tecnologias sem que isso comprometa tudo o que havia sido produzido.
Mantenha seu cdigo organizado e em um nico lugar e gerencie suas verses atravs de um Servidor de Controle de Verses. Assim, os desenvolvedores podero trabalhar em paralelo, e uma parte do trabalho de integrao de cdigo poder ser realizado pela ferramenta. Existem muitas aplicaes no mercado, mas vou citar duas: CVS e sua evoluo SVN, ambos de cdigo aberto. Cuidado: se voc ainda no possui uma ferramenta dessas em seu ambiente de trabalho, deveria estar preocupado.
Servidor de Build
Entre as funes de um servidor de build, o mnimo que voc deve se preocupar:
Recuperar as ltimas alteraes no repositrio de arquivos em algum intervalo de tempo. Executar aes baseadas num cronograma, como diariamente ou a cada hora. Suporte para diferentes ferramentas de scripting, incluindo as executadas em linha de comando: Rake, make, Ant ou NAnt. Enviar emails ao interessados do projeto com informaes sobre o build. Armazenar um histrico dos builds Possuir uma interface web acessvel a qualquer um. Informaes sobre qual ferramenta utilizar, e as
Ampliar a Confiana no Produto

Poucos foram os projetos em que vi desenvolvedores com certeza sobre: a robustez de suas solues, sua capacidade de estimativa de esforo ou a confiabilidade em entregar um sistema que funcione quanto em um ambiente com IC. Experimente!
Por onde comear? Controle de Verso

Pode parecer mentira, mas existem muitas empresas que ainda no possuem um servidor de controle de verso para o cdigo em desenvolvimento. Irresponsabilidade? Ignorncia? Espero que no.
funcionalidades de cada uma podem ser encontrados na Tabela de Funcionalidade de IC (CI Feature Matrix), disponvel na sesso de links. CruiseControl, Anthill, Gump e CI Factory so alguns exemplos de ferramentas. Crie um desafio em seu projeto: Poderamos automatizar a compilao de um de nossos sistemas? Invista tempo em aprender sobre ferramentas de script e como utiliz-las em seu ambiente. Assim, a escolha de um servidor de build ser bastante simples.
14
Integrao Contnua
Testes
Sou adepto da idia de Bob Martin sobre profissionalismo em desenvolvimento de software: "Nos dias de hoje, irresponsabilidade um desenvolvedor entregar qualquer linha de cdigo sem que exista um teste unitrio para comprovar o seu funcionamento" Mesmo sendo extremista, acredito que este deve ser o direcionamento. Mas como reunir seus testes em um ambiente de Integrao Contnua? A famlia de ferramentas xUnit pode ser bastante til na criao da IC. Entretanto, testes unitrios podem no ser suficientes, j que tambm possvel verificar aderncia de regras de negcio e carga, por exemplo. O Selenium e o JWebUnit podem suprir a necessidade de testar interfaces web, servindo muito bem para validao de regras de negcio. Todas essas ferramentas devem ser integradas juntamente com o processo de construo via script.
Crie a cultura de avaliao contnua sobre a arquitetura de seu cdigo, assim os insumos gerados por uma ferramenta como o Checkstyle ou NDepend podem contribuir e muito para a sade de seu sistema. Feedback No desperdice seu tempo criando relatrios manualmente. Encontre a documentao exata de seu cdigo, extraia a arquitetura em que o sistema est realmente construdo. Tome decises de desenvolvimento baseadas por fatos e nmeros, no suposies. "Como regra geral, o homem mais bem sucedido em vida aqueles que possu as melhores informaes" Benjamin Disraeli
Receba informaes sobre problemas no momento em que eles surgirem. Deixe visvel para toda a equipe o momento em que o seu software deixou de ser confivel. Tome medidas rpidas para corrigir o problema. Este um exemplo bastante ntido do princpio Stop the line! do Lean. Utilize com cautela Emails, Instant Messagers, Sirenes e SMS para retirar o melhor proveito da infraestrutura de feedback criada pela IC.
Inspeo de Cdigo
Decida o que voc quer medir antes de mais nada. Cobertura de cdigo, complexidade e duplicaes podem ser teis para sua equipe. Checkstyle uma ferramenta que permite verificar a aderncia de seu cdigo a padres de
Concluses
Mesmo no sendo a panacia para todos os problemas de software, o ambiente proposto neste artigo espera ajudar a melhoria da qualidade dos projetos atravs de mtricas e nmeros reais sobre o estado de seu sistema. Encontrar a resposta sobre "Onde estamos" o primeiro passo para ampliar a sua capacidade de produzir sistemas com melhor qualidade.
desenvolvimento,
podendo
tambm
encontrar
redundncias e fazer inspees em nvel de design e complexidade de cdigo. Voc pode remover a complexidade de seu cdigo ficando atento a: O nmero de classes, mtodos, linhas de cdigo no comentadas e variao do estilo de documentao entre os pacotes (um padro JavaDoc pode ajudar).
Complexidade ciclomtica. Dependncias. Voltar para o Sprint Backlog 15
Acoplamento. Revista Viso gil Edio 04
Integrao Contnua
Focar-se na produo de software uma mudana muito grande na cultura de nossas empresas. Transformar os desenvolvedores em avaliadores de qualidade trar benefcios muito alm da construo Um de produtos de mais confiveis. Contnua ambiente Integrao
Artigos
Cases
modificar a forma com que seu cdigo produzido e a forma com que os envolvidos no projeto lidaro com problemas Ao aventurar-se de neste desenvolvimento. campo, esteja
preparado para questionar todas as suas atividades e todo o processo de conduo de um projeto de software. Boa sorte!
Comunidade
Biblioteca Pblica
Referncias e Links
O artigo mais clssico sobre o tema: http://martinfowler.com/articles/continuousIntegratio n.html
Eventos
Tudo sobre Agile
Livro: Continuous Integration - Improving Software Quality and Reducing Risk - Paul Duvall, Steve Matyas e Andrew Glover
Continuous Integration Feature Matrix http://confluence.public.thoughtworks.org/display/C C/CI+Feature+Matrix

www.visaoagil.com
Blog do Autor: http://malditacomedia.blogspot.com Foto por Manu Contreras
http://www.phidelis.com.br
16
Encontro da comunidade de Metodologias geis do RS
lbum
Em Porto Alegre(RS), Na noite de 17 de Abril de 2008, nas dependncias da Faculdade Dom Bosco, foi organizado pelo pessoal do XP-RS(Grupo de Usurios Extreme Programming do Rio Grande do Sul), um encontro para trazer palestras e debates acerca de Metodologias geis. Ns da Viso gil, aproveitando nossa estadia em Porto Alegre em funo do FISL, participamos do evento e cobrimos os melhores momentos para voc amigo leitor.
Daniel Wildt na palestra inicial sobre eXtreme Programming: principios, valores e prticas.
O pblico compareceu em peso ao evento, com bastante interesse, muitas perguntas e bastante participativo.
Manoel Pimentel fazendo uma breve apresentao institucional sobre a Revista Viso gil.
Vincius Manhes Teles, No incio de sua apresentao no estilo Tropa de elite sobre eXperincias geis
17
Artigo
Aperfeioamento de Projetos geis

Parte II: As Trs Perspectivas
Autor:Alisson Vale
Tem mais de 15 anos de experincia com desenvolvimento de software e a mais de 6 anos lidera projetos de software dos mais variados tipos e tamanhos. Hoje Lder de Projeto e Diretor da Phidelis Tecnologia, onde lidera a equipe de desenvolvimento da soluo acadmica oferecida pela empresa. E-mail: alisson.vale@phidelis.com.br Weblog: http://www.phidelis.com.br/blogs/alissonvale
No existe processo perfeito. Isso fato. No entanto, buscar a perfeio, mesmo sabendo que nunca iremos alcan-la faz parte da essncia do ser humano. Todos ns lutamos para melhorar nossas condies de trabalho, nossa eficincia e nossos resultados. O que muda de uma pessoa para outra (ou de um projeto para outro) a freqncia com que paramos para analisar o que fazemos, buscando formas de sermos melhores hoje do que ramos ontem. Alguns o fazem todos os dias, outros todas as semanas ou todos os anos. A grande questo : como podemos fazer isso de modo estruturado? Nesse artigo, eu descrevo formas de abordar e aplicar modelos de aperfeioamento contnuo em projetos de software baseados em prticas complementares, capazes de atuar sob o prisma de trs perspectivas diferentes. Inspeo e Adaptao so duas faces de uma mesma moeda em projetos geis. A Inspeo direciona nossa ateno para questes relacionadas com o nosso modo de trabalhar que de alguma forma interferem nos resultados que obtemos . Quando fazemos inspeo olhamos de dentro para fora, ou seja, algo dentro do dia-a-dia do projeto precisa ser melhorado para que quem esteja do lado de fora perceba melhores resultados. Quando falamos em adaptao, no entanto, nossa ateno direcionada para fora do controle do nosso projeto. Ela precisa aparecer quando eventos ou situaes originadas fora do mbito do projeto acabam interferindo em seus resultados.
18
Nesse caso precisamos nos adaptar a um cenrio diferente daquele que estamos habituados. comum no percebemos essa diferena pois, alm de ser sutil, ela acaba se tornando irrelevante j que o instrumento que possibilita a inspeo e a adaptao o mesmo: o aperfeioamento contnuo. So as tcnicas de aperfeioamento contnuo que daro a capacidade necessria para que um time de projeto tenha condies de auto-inspecionar seu prprio processo de trabalho. E sero as mesmas tcnicas que daro a capacidade para que esse mesmo grupo consiga se adaptar s questes externas que inevitavelmente surgiro no decorrer do projeto. Neste artigo, eu apresento algumas tcnicas e as organizo no que eu costumo chamar de Perspectivas. Prticas de aperfeioamento contnuo tero melhor eficcia quando utilizadas para enderear problemas de acordo com o seu nvel de abrangncia. Por exemplo, problemas de natureza sistmica sero resolvidos de forma mais eficaz quando forem tratados adotando-se uma Perspectiva Estratgica. Um problema sistmico certamente envolver conhecer muito profundamente suas vrias causas dificilmente esse tipo de problema ter uma nica causa -, e, mais do que isso, envolver uma anlise profunda para se chegar causa-raiz primria que efetivamente gera o problema. Quando se tenta resolver um problema utilizando a Perspectiva Estratgica, espera-se causar um grande impacto na forma em que o projeto est estruturado ou at nos conceitos sobre os quais ele se baseia. A anlise de causa-raiz utilizada pela Toyota um timo instrumento para enderear problemas sob o ponto de vista estratgico.
A Perspectiva Estratgica no a nica que podemos utilizar para criarmos as condies para o aperfeioamento contnuo. O dia-a-dia em um ambiente de trabalho tomado por inmeros pequenos problemas que quando se acumulam podem gerar um efeito devastador sobre sua eficcia. para resolver esse tipo de problema que precisamos adotar instrumentos que atuem equilibrando o processo na medida em que as prticas adotadas no geram o resultado apropriado. Quando intervimos no modelo operacional de trabalho estamos atuando segundo uma Perspectiva Ttica. So esses instrumentos que nos ajudaro a responder pergunta: Como podemos fazer isso melhor?. Mesmo depois de sermos capazes de autoaperfeioar nossos prprios processos e prticas de trabalho, ainda temos mais um desafio a resolver: Como nos auto-aperfeioarmos como pessoas ou como profissionais na direo de fazer essa mquina de autoaperfeioamento girar? Essa a Perspectiva Individual e nela que est a base de tudo, pois, no final das contas, o esforo individual das pessoas que ser somado na direo de aperfeioar toda a organizao.
A Perspectiva Estratgica: O Kaizen

Perguntamos por que cinco vezes. o que diz Yuichi Okamoto, ex-presidente do Toyota Techinical Center, quando perguntado sobre o segredo do sucesso da Toyota e do seu sistema de produo, mais conhecido como Toyota Production System (Liker, 2005). Um dos elementos mais importantes do sistema de produo utilizado pela Toyota o seu modelo para melhoria contnua e soluo de problemas, tambm conhecido como kaizen. O princpio bsico desse modelo reside na conscincia de que todo o problema, antes de ser um mero inconveniente, acima de tudo uma oportunidade de melhoria; e que a soluo para tais problemas s sero permanentes e efetivas se identificarmos a sua causaraiz. Voltar para o Sprint Backlog
19
O primeiro desafio desse modelo deixar de procurar pela fonte de um problema e comear a tentar identificar sua causa-raiz. Um dos principais instrumentos que a Toyota utiliza para isso, o que ela chama de Anlise dos 5 porqus. Ao identificar um problema, pergunte porqu ele ocorre. Aps encontrar a primeira resposta, pergunte porqu novamente. Repita esse processo repetidamente por cinco vezes e voc chegar a uma razo onde o nvel de distanciamento da causa para o efeito ser o mais adequado para encontrar a soluo definitiva para o problema. Por exemplo, imagine que uma equipe utilizando uma de metodologia um produto gil no no esteja desenvolvimento
A equipe identifica isso como um problema, pois as atividades que envolvem ajustes e correes executadas sobre as features da verso n afetam o rendimento da iterao n+1 e seguem afetando as demais iteraes de forma progressiva. Veja na Figura 1 um possvel uso da tcnica dos cinco porqus para entender melhor o problema e, assim, encontrar solues definitivas. Normalmente, quando tentamos resolver um problema, ns nos concentramos em resolver seu primeiro nvel (o primeiro porqu). Como nossa mente est muito acostumada a estabelecer relaes diretas de causa e efeito, esse foco na causa superficial bastante natural. Mas, infelizmente, essa abordagem no costuma gerar bons resultados. Quando voc se concentra em resolver a causa imediata, entra-se em um processo que eu costumo chamar de se livrar do problema ao invs de resolver o problema. Normalmente, a soluo para o primeiro porqu resolve o problema de forma imediata, mas no evita que ele aparea novamente e, o que pior, colabora para o efeito progressivo causado pelo problema na medida em que ele se mantm ao longo do tempo. No exemplo da Figura 1, quando voc decide simplesmente entregar apenas o que tem qualidade de produo no final de uma iterao e deixar o que ficou de fora para a prxima, voc se livrou do problema. Afinal, o que no ficou pronto ser absorvido na iterao seguinte e tudo aparentemente estar de acordo com os princpios metodolgicos. Mas, nesse caso, voc realmente resolveu o problema? Sob que ponto de vista? O seu ou do seu cliente? Conforme j exposto na Parte I desse artigo, a Toyota avalia a resoluo de problemas sob a tica dos elementos de avaliao primria. Isso envolve qualidade, custo, produtividade, segurana e atendimento ao cliente (Liker & Meier, 2007).
conseguindo entregar uma verso funcional com qualidade de uso ao final de uma iterao. Seguindo tcnicas do Scrum, a equipe consegue fazer demonstraes do seu produto para o cliente ao final da iterao. Mas a verso desenvolvida na iterao n s consegue ser disponibilizada para uso em meados do meio da iterao n+1.
Figura 1: Exemplo de uso da tcnica dos 5 porqus da Toyota.
20

Quando apenas a causa superficial de um problema resolvida, normalmente os efeitos sobre esses elementos para em no que uma so eqalitativamente seja de afetado lei de distribudos. Um elemento acaba sendo afetado negativamente positivamente, outro espcie No entanto, importante ter em mente que solues sistmicas eventualmente so to traumticas que os estudiosos do modelo Toyota costumam dizer que, nesses casos, no h como melhorar sem piorar primeiro. preciso muita coragem e muito envolvimento do grupo de trabalho para adot-las. No exemplo utilizado anteriormente, a mudana que precisa ser feita certamente causar muitos transtornos no incio, mas depois de passado o perfil de turbulncia aquela piora antes da melhora -, o projeto se beneficiar de uma interveno definitiva e de um efeito de melhoria sistmica muito maior. O modelo Kaizen da Toyota um modelo essencialmente organizacional. Ele se infiltra em cada setor da organizao at chegar ao nvel do indivduo, que ter seus prprios instrumentos de melhoria contnua. Quando falamos especificamente da realidade de nossos projetos de software, nem sempre temos a capacidade de influenciar toda uma organizao de forma que ela possa adotar um modelo to engenhoso como o caso do Kaizen. Mas podemos utilizar as mesmas tcnicas para tentar influenciar nossos projetos de forma mais significante. A grande diferena entre essa Perspectiva Estratgica e a Perspectiva Ttica que veremos a seguir, que a primeira lenta, requer muito tempo de observao, anlise e reflexo. Portanto, ineficiente se feita no escopo de uma reunio de retrospectiva, por exemplo. Solues que emergem dessa perspectiva tambm tendem a ser difceis e custosas para se implementar. Por isso, importante saber quando e como us-la.
compensao. Quando voc atinge a causa-raiz de um problema, comum que todos os elementos sejam afetados positivamente, variando apenas em que momento cada elemento ser influenciado (curto, mdio ou longo prazo). Retomando o exemplo da Figura 1, a resposta ao segundo porqu comea a nos levar s origens do problema. Assim, quando a equipe se depara com a questo de incorporar os tempos de testes e ajustes s estimativas, ela perceber que isso no ser uma tarefa fcil, pois uma equipe diferente faz os testes e difcil prever a complexidade dos ajustes que precisaro ser feitos logo depois que uma funcionalidade desenvolvida e que um feedback dado. Aprofundando a anlise, chegaremos ao problema conceitual que efetivamente contribui para as dificuldades que a equipe vem enfrentando. Diferentemente do que incentivado pelas metodologias geis, a equipe continua executando pequenos ciclos de fases encadeadas dentro das iteraes, deixando uma fase de testes ser executada aps a fase de implementao. O que a leva a perceber que ainda necessria uma reavaliao conceitual do seu mtodo de trabalho. A interveno sistmica ocorrer, assim, por meio de uma mudana no paradigma utilizado, o que causar um impacto profundo no modelo utilizado. Chegar ao quinto porqu nos leva a um melhor entendimento do problema e, na maioria das vezes, a uma soluo de efeito sistmico permanente, ao invs de uma soluo temporria e pouco eficaz. Revista Viso gil Edio 04
Perspectiva Ttica: As Retrospectivas

Tambm podemos influenciar nossos prprios projetos adotando prticas de melhoria contnua que atuem no mbito ttico e operacional. Os mtodos geis de forma geral nos oferecem alguns instrumentos para lidar com o aperfeioamento contnuo no mbito do dia-a-dia do projeto. O instrumento mais utilizado para isso so as Reunies de Retrospectiva. Voltar para o Sprint Backlog 21
Projeto campeonatos
geis esportivos.
so Um
semelhantes campeonato
As pessoas no precisam fazer anotaes em uma retrospectiva (a no ser que realmente queiram). Toda a coleta e registro de informaes ser feito por meio de quadros brancos, flipcharts e post-its. Alm de facilitar o trabalho colaborativo de coleta e anlise dos dados, esse tipo de material far parte da decorao do ambiente de trabalho, criando um lembrete visual do que foi discutido e acordado. Utilizar datashows e softwares durante a reunio pode no ser uma boa idia, uma vez que muitas vezes contribuem para quebrar o clima de colaborao devido ao trabalho operacional enfadonho. Outros pontos importantes a se considerar para uma Reunio de Retrospectiva: Controle de tempo (timeboxed). Definir os tempos de cada etapa da reunio. Isso a tornar mais objetiva e ajudar na manuteno do foco da reunio.
disputado jogo a jogo. Cada jogo ter uma histria diferente e apresentar um resultado diferente. A equipe vencer se conseguir focar em resultados, se adaptar com a realidade de cada jogo e ao mesmo tempo aperfeioar sua forma de jogar ao longo do campeonato. Projetos tradicionais esperam o campeonato terminar para refletir e melhorar. O modelo gil, por outro lado, trata cada uma de suas iteraes como as equipes esportivas tratam seus jogos. A primeira atitude de um tcnico esportivo depois de um jogo reunir a equipe para falar sobre os pontos positivos e negativos do ltimo jogo. No contexto do modelo gil, tais reunies so chamadas de Reunies de Retrospectiva. Usualmente, essas reunies ocorrem no incio ou ao final de uma iterao e tem como objetivo avaliar os pontos positivos e negativos do processo e das prticas adotadas na iterao anterior, bem como propor aes de melhoria para a iterao seguinte. A retrospectiva o instrumento que enderea de forma mais direta o princpio da inspeo e adaptao presente no modelo gil. Em uma reunio de retrospectiva, uma equipe gil reflete e discute sobre como executar seu trabalho de maneira mais eficiente. A seguir descrevo rapidamente como essas reunies so estruturadas e quais so seus principais elementos conceituais.
Participao de todos os membros da equipe. Alm da contribuio de todos nas discusses, importante dar aos membros da equipe a sensao de que eles fazem parte do processo de melhoria do seu prprio trabalho.
Ambiente confivel e seguro. Deve-se estabelecer que a reunio um ambiente de livre troca de idias sem medo ou insegurana. Sem presses hierrquicas e sem crticas pessoais.
A Diretiva Primria (The Prime Directive)

Uma retrospectiva NO uma reunio de cobrana ou de avaliao individual de performance. uma reunio de avaliao das prticas e do processo, no das pessoas. O instrumento utilizado para tentar evitar que uma coisa se transforme em outra , antes de comear a reunio, convocar os participantes a aceitarem a Diretiva Primria (Kerth, 2001), que declara: Independentemente do que descobrirmos, devemos entender e acreditar que todos fizeram o melhor que podiam, dado o que era conhecido at ento, as habilidades de cada um e as condies do momento.
A Estrutura da Reunio
Reunies de retrospectiva tm mais semelhana com workshops do que com reunies segundo o formato tradicional que conhecemos (aquele em que todos sentam em uma mesa retangular munidos de uma caneta e um bloco de anotaes). Revista Viso gil Edio 04
22
Quando a equipe aceita essa prerrogativa, a reunio ser focada nas causas dos problemas e no nas pessoas que os causaram. De fato, uma reunio onde se discutem problemas pode facilmente ter seu foco desviado para crticas pessoais e para a busca de culpados. Se a reunio atingir este ponto ser totalmente ineficaz. Portanto, preciso ter muito cuidado na conduo de tais reunies, principalmente com equipes com problemas de relacionamento ou que trabalhem em ambientes muito competitivos. No caso de haver um problema individual de performance este deve ser discutido em outro mbito, no no mbito da retrospectiva.
Voc pode aproveitar a retrospectiva para coletar e divulgar nmeros que evidenciem a qualidade do trabalho desempenhado pela equipe. A idia registrar esses nmeros em quadros de acompanhamento e monitor-los entre uma iterao e outra. Na Tabela 1, so apresentados alguns exemplos de mtricas que podem ser monitoradas. Veja mais em (Leffingwell, 2006).
Introduzindo a situao atual

Na etapa inicial de uma retrospectiva, importante estabelecer a situao atual do projeto e o qu foi alcanado at ento. Busca-se com isso, criar o foco necessrio para o resto da reunio. Se voc quer manter a reunio mais formal, pode utilizar essa etapa para apresentar uma agenda, introduzir convidados ou resumir os esforos alcanados at o momento pelas aes de melhoria da equipe. Essa etapa no deve levar mais do que alguns minutos e abrir espao para a prxima etapa: a coleta de informaes. Coleta de Dados: Anlise quantitativa Nmeros tm fundamental importncia pois evidenciam tendncias de melhora ou de piora para determinados aspectos do projeto. A questo-chave identificar quais os nmeros realmente so relevantes e que merecem ser analisados no seu projeto. Eventualmente eles servem apenas para demonstrar ou apoiar uma anlise terica. Em outros casos, eles podem revelar se os nveis de qualidade do projeto esto melhorando ou piorando. Revista Viso gil Edio 04 Um outro tipo de anlise quantitativa pode nos ajudar a saber se estamos conseguindo melhorar um outro aspecto importante do projeto: a questo motivacional. Medir o nvel de satisfao da equipe pode ser uma boa maneira de acompanhar os nveis de aceitao psicolgica que a equipe tem com relao s suas atividades e ao seu ambiente de trabalho. No livro Agile Retrospectives, Making Good Teams Great (Derby & Larsen, 2006), descrito um instrumento interessante para avaliar satisfao: um histograma de satisfao (Figura 2). Por exemplo, a lista apresentada a seguir apresenta os nveis de satisfao considerados na anlise: 5. Extremamente Satisfeito 4. Muito Satisfeito 3. Satisfeito 2. Eventualmente Satisfeito 1. Insatisfeito Durante a retrospectiva, cada membro da equipe escreve o nmero que represente seu nvel de satisfao em um carto, post-it ou pedao de papel e o coloca em uma sacola, na mesa ou o empilha. Depois um voluntrio faz a contagem dos nmeros e preenche um histograma como o da Figura 2. Voltar para o Sprint Backlog 23
Com o timeline montado ser mais fcil levantar o que foi bom e o que foi ruim dentro da iterao. A tcnica fazer com que cada membro da equipe descreva em postits itens que respondam a algumas perguntas simples que os levem a fazer uma anlise qualitativa da iterao de forma rpida e sem formalismos, por exemplo:
Figura 2: Exemplo de um Histograma de Satisfao
O que foi bom e devemos continuar fazendo na
Ao se fazer isso em todas as retrospectivas, obtm-se uma noo do nvel de motivao da equipe, podendo-se utilizar essa informao para planejar aes que aumentem a auto-estima do grupo melhorando, dessa maneira, sua coeso e disposio para atingir as metas estabelecidas.
prxima iterao?
O que poderia ter sido melhor?
O que devemos tentar evitar para no acontecer novamente na prxima iterao?
Que aes podemos tomar para melhorar o que no foi bom?
Coleta de Dados: Anlise qualitativa

O prximo passo da reunio a coleta de dados no numricos: eventos significativos da iterao, aes que funcionaram bem ou aquilo que precisa ser melhorado. H algumas tcnicas que podem ser utilizadas para isso. A primeira o Timeline. Desenha-se uma linha horizontal em uma folha de flip-chart marcando-se a data de incio da iterao no incio da linha e a data de fim no final da linha. Distribui-se post-its para a equipe, que ento os utiliza para descrever os eventos significativos que aconteceram durante a iterao. Os post-its so colados nas datas em que os eventos ocorreram na linha do tempo de forma que a histria da iterao possa ser visualizada graficamente. A funo do timeline principalmente reavivar a memria da equipe para no deixar que um possvel evento significativo escape da anlise que vir a seguir. Esse trabalho com o timeline tambm ajudar no processo de nivelamento do conhecimento da equipe sobre o que houve na iterao. A idia que a memria coletiva seja utilizada para emergir os eventos que aconteceram durante a iterao, tornando-os visveis para toda a equipe. Revista Viso gil Edio 04 de
Ao escrever em um post-it e colar na rea de anlise da reunio (que pode ser um flip-chart ou um quadro branco), o membro da equipe deve descrever aquilo que escreveu em poucas palavras. Nesse momento, importante no deixar que se comece longas discusses sobre possveis causas ou soluo para os itens apresentados. O momento mais de elicitao do que propriamente de discusso. importante tambm separar o momento em que se fala dos problemas do momento em que se fala das solues. Misturar as duas coisas pode causar desordem e confuso. O Scrum tem uma boa tcnica para resolver esse processo, conforme descrito a seguir.
Anlise qualitativa no Scrum

Equipes que utilizam o Scrum como metodologia trabalho costumam trabalhar com questes semelhantes, mas utilizando perguntas mais diretas e padronizadas (em ingls): What Went Well? e What can be improved? (respectivamente O que foi bom? e O que pode ser melhorado?).
24
No Scrum, cada item da lista do que pode ser melhorado um impedimento. Impedimentos atrapalham ou bloqueiam o trabalho da equipe, por isso precisam ser direcionados para uma soluo. Tal soluo pode estar no mbito da prpria equipe ou no mbito da organizao. Por isso, h ainda uma terceira pergunta a ser feita para cada impedimento: Who is in control of this impediment? (Quem tem o controle sobre o impedimento?). H apenas duas respostas possveis: a equipe ou a organizao. O que for considerado como algo que pode ser resolvido no mbito da equipe adicionado ao Backlog de Produto. As questes de mbito organizacional so adicionadas ao Backlog de Impedimentos. O Scrum Master acompanhar o Backlog de Impedimentos tentando mediar as solues junto organizao. A equipe, por sua vez, ter ainda a responsabilidade de explicar a importncia dos itens adicionados ao Backlog de Produto e de negociar algum tempo com o Product Owner para que os impedimentos listados ali possam tambm entrar no escopo de trabalho das prximas iteraes.
Tendo conscincia disso, ser muito mais fcil para as pessoas adotarem a Perspectiva Individual da melhoria contnua. Nesse mbito ocorre o caminho inverso: o indivduo ajuda o grupo. Nesse modelo, todas as pessoas da equipe podem utilizar sua capacidade criativa e de resoluo de problemas para criar e pensar sobre instrumentos que gerem resultado em termos de melhoria para todas os outros membros da equipe. Nada impede, por exemplo, que um membro da equipe pense e proponha um modelo de teste mais eficiente, ou que ele use uma parte do seu tempo para aprender e divulgar o uso de uma ferramenta mais produtiva. Mesmo que isso no seja de sua responsabilidade, todos devem se preocupar em melhorar o que fazem, em serem teis no s executando suas tarefas dirias, mas tambm em criar solues que gerem benefcio direto para o grupo em que trabalham. Cada membro da equipe pode sim ver-se beneficiado pela sinergia do processo de melhoria contnua e, assim, ser estimulado a dar a sua parcela de retribuio. Ou pensando em oportunidades de surpreender seus colegas com criatividade e bom senso, ou simplesmente esforando-se para propor idias inovadoras para a melhoria do projeto em que trabalham.
A Perspectiva Individual
Um dos aspectos-chave das retrospectivas o fato de elas canalizarem o esforo de todo um grupo de trabalho para melhorar o trabalho dos indivduos que a ele pertencem. Retrospectivas freqentes no trazem apenas resultado para o projeto em si, ou para a organizao. Elas trazem benefcio direto para cada indivduo que pertence quele grupo. Eventualmente, tais benefcios retornam para o indivduo na forma de melhora na qualidade do trabalho, em melhora da sua capacidade tcnica ou at mesmo na melhora da qualidade de vida de cada pessoa. Revista Viso gil Edio 04
Concluso
No h dvida que ambientes de trabalho que consigam unir as Perspectivas Estratgica, Ttica e Individual tero um efeito devastador sobre seus resultados. claro que isso no uma tarefa fcil. Mas o simples de fato de sabermos que h tantos instrumentos que podemos utilizar para criar processos de melhoria contnua em nossos projetos, j um grande ponto a nosso favor. Afinal, no h nada mais reconfortante do que descobrirmos que somos melhores hoje do que fomos ontem.
25
Referncias
Derby, E., & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. The Pragmatic Programmers, LLC. Kerth, N. L. (2001). Project Retrospectives: A Handbook for Team Review. New York: DORSET HOUSE PUBLISHING CO., INC. Leffingwell, D. (2006). Iteration and Release Retrospectives: The Natural Rhythm for Agile Measurement. Agile Journal . Liker, J. K. (2005). O Modelo Toyota: 14 Princpios de Gesto do Maior Fabricante do Mundo. Porto Alegre: Bookman. Liker, J. K., Meier, D. (2007). O Modelo Toyota: Manual de Aplicao. Porto Alegre: Bookman. Sprint-It & InfoQ. (2006). InfoQ: Scrum Checklists. Retrieved Mar 18, 2008, from InfoQ: http://www.infoq.com/minibooks/scrum-checklists Vale, A. (2008). Aperfeioamento de Projetos geis - Parte 1: Viso Sistmica. Revista Viso gil (Ed. 3 Ano II).
Artigos
Cases
Comunidade
Biblioteca Pblica
Eventos
Tudo sobre Agile
www.visaoagil.com
26
Artigo

Tradutor: Victor Hugo Germano Bacharel em Cincia da Computao e Especializado em Gesto Estratgica de TI. Atualmente atua como integrante do Escritrio de Projetos na empresa Audaces Automao, auxiliando no processo de implantao de metodologias geis em Desenvolvimento de Software. Autor do blog A Maldita Comdia, tambm participa do grupo de desenvolvedores do Coding Dojo Floripa. Pode ser contatado atravs do correio eletrnico: victorhg@gmail.com
Autor: Steve McConnell CEO e Engenheiro Chefe na Construx Software. Autor dos livros Code Complete (1993, 2004) e Rapid Development (1996), ambos premiados pela revista: Software Development . Em 1998, publicou Software Project Survival Guide, Professional Software Development (2004) e em 2006: Software Estimation: Demystifying the Black Art.
Introduo
Em um momento em que algumas empresas de sofware alcanaram resultados prximos perfeio em entregas, 1 outras continuam a sofrer com resultados medocres. Pesquisas normalmente indicam que um planejamento de projetos pobre uma das principais fontes de problemas. Como voc pode reconhecer um projeto de software mal planejado? Aqui voc encontrar alguns dos pecados mais mortais que pude encontrar em planejamento de projetos.
27
1. Sem Planejamento algum

De longe o problema mais comum em planejamento no ter planejamento algum, sendo este pecado facilmente evitvel. Uma pessoa no precisa ser um especialista na rea para criar um planejamento eficiente.Tenho visto inmeros projetos planejados por amadores que tem se sado bem simplesmente pelo fato das pessoas no comando terem considerado cuidadosamente as necessidades especficas do projeto. Forado a escolher entre um especialista em planejamento de projetos que no pensa cuidadosamente atravs de seu plano ou um amador na rea que tenha exaustivamente avaliado suas necessidades, eu apostaria no amador todas as vezes.
Alguns
projetos
que
terminam
dentro
do
planejamento reduzindo o ciclo de testes originalmente planejado; a razo para tal que provavelmente no existiro muitos defeitos para serem detectados ou corrigidos. (Determinar o porque - se for realmente o caso - no se costuma planejar um ciclo menos de testes no primeiro momento deixado como um exerccio ao leitor.)
3.
Falha
Em
ao
Design
Planejar
Paradigms 2,
por
riscos
Petroski
Henry
argumenta que, no arquitetura de pontes, as falhas mais espetaculares foram normalmente precedidas de perodos de sucesso que levaram ao prazer na criao de novos designs. Arquitetos de pontes mal sucedidas estavam to iludidos em copiar os atributos de pontes bem sucedidas que no prestavam ateno suficiente em cada uma das
2.
Falha
ao
contabilizar
todas
as
potencialidades de falha para as novas pontes. Para projetos de software, esquivar-se
atividades do Projeto
Se o Pecado Mortal #1 no ter planejamento algum, o Pecado Mortal #2 no planejar o suficiente. Alguns planos de projetos so criados assumindo que ningum no time de desenvolvimento ficar doente, ter treinamentos, frias ou sair da empresa. As atividades principais so geralmente subestimadas emgrande nvel. Planejamentos criados assumindo condies irreais como estas levaro projetos ao desastre. Existem inmeras variaes deste tema. Alguns gestores negligenciam ao contabilizar atividades secundrias como o esforo necessrio para configurar sistemas, converter dados de verses anteriores, realizar cortes para novos sistemas, realizar testes de compatibilidade e outros tipos de trabalhos chatos que necessitam de mais tempo em projetos do que gostaramos de admitir. Revista Viso gil Edio 04
constantemente de falhas to importante quanto simular o sucesso. Em muitos contextos, a palavra "risco" no mencionada a menos que o projeto j esteja em grandes problemas. Em software, o gestor do projeto que no utiliza a palavra "risco" todos os dias e no incorpora o gerenciamento de riscos em seu plano provavelmente no est realizando seu trabalho. Como Tom Gilb diz: "Se voc constantemente no atacar os riscos de seu projeto, eles iro constantemente atacar voc"3 4. Utilizar o mesmo plano para todos os projetos Algumas empresas crescem envoltas em uma forma particular de conduzir os projetos de software, que conhecida como "o jeito que fazemos as coisas por aqui". Quando esta abordagem utilizada, a empresa tende a ir bem enquanto o projeto se parecer com os antigos projetos. Voltar para o Sprint Backlog 28
5.
Aplicar
Indiscriminadamente
Planejamentos Pr-fabricados
6. Permitir que um Planejamento fuja Realidade do Projeto

Uma abordagem comum para o planejamento criar um plano no incio do projeto e ento coloc-lo no
Um primo prximo do Pecado Mortal #3 reutilizar um plano genrico criado por outra pessoa sem aplicar seu prprio julgamento ou sem considerar suas necessidades nicas de projeto. "O plano de algum" normalmente chega na forma de um livro ou uma metodologia que um gestor aplica em teoria. Exemplos mais atuais incluem Rational Unified Process,4 Extreme Programming, em algum ponto (apesar de minhas melhores intenes de fazer o contrrio) meu prprio Software Project Survival Guidee o CxOnede minha empresa. Estes planos prfabricados podem ajudar a evitar os Pecados Mortais #1e #2, mas no so um substituto para a tentativa de otimizar o planejamento de um projeto para sua principais necessidades.
armrio e deix-lo acumular poeira apenas para lembrana. medida que as condies do projeto mudam, o plano torna-se invariavelmente irrelevante, e, ao chegar metade, o projeto correr livre de formas, sem nenhuma relao real entre o planejamento inicial e realidade do projeto. Este Pecado Mortal exacerbado pelo Pecado Mortal #5- gestores que levantam a bandeira de metodologias pr-fabricadas so muitas vezes relutantes mudana de seu modelo mental quando isso no funciona. Eles pensam que o problema est na aplicao do planejamento quando, de fato, o problema o prprio planejamento. Bons planejamentos de projeto devem
Nenhum
especialista
de
fora
pode
evoluir atravs do projeto.
compreender as necessidades especficas de um projeto to bem quanto as pessoas diretamente envolvidas nele. Gestores deveriam sempre deixar o planejamento "dos especialistas" para suas circunstncias especficas. Felizmente, tenho visto que gestores que tem a real conscincia dos problemas envolvidos em planejamento para lerem livros de engenharia de software tambm possuem suficiente bom senso para serem seletivos sobre que partes de um plano pr-fabricado poderiam funcionar.
7.Planejar em Muitos Detalhes Muito Cedo

Alguns gestores bem intencionados tentam mapear todo o valor das atividades de um projeto muito cedo. Mas um projeto de software consiste em um grupo de decises constantemente desconhecido, e cada fase de um projeto cria dependncias para as futuras decises. Uma vez que ningum possui bola de cristal, tentar planejar atividades distantes em muitos detalhes um exerccio de burocracia to ruim quanto no ter nenhum planejamento.
29
Quanto mais trabalho houver em criar prematuramente planos detalhados, mais facilmente o planejamento se tornar arquivvel (Pecado Mortal #6). Ningum gosta de desperdiar trabalhos anteriores, e gerentes algumas vezes tentam forar a realidade do projeto encaixar em seu primeiro planejamento, ao invs de laboriosamente revisar seu plano prematuro. Eu imagino um bom planejamento de projetos como dirigir noite com as lanternas ligadas. Podem existir mapas que diro como ir da Cidade A a Cidade B, mas a distncia que posso ver em detalhes atravs de meus faris limitada. Em projetos de mdio ou grande porte, planejamento deve ser mapeado fim-a-fim cedo no projeto. Detalhamento e micro planejamento deve geralmente ser conduzido apenas algumas semanas por vez, e deve ser guiado na forma "just in time".
medida que a equipe progride para as fases mais adiantadas do projeto, a velocidade no aumenta; ela ir diminuir medida que encontrar as consequncias do erros cometidos mais cedo e investir tempo tentando corrigir tais erros.
9. No aprender com Planejamentos Antigos
os
Pecados
de
O Mais Mortal de todos os pecados no aprender com os pecados anteriores. Projetos de Software podem durar muito tempo, e a memria das pessoas pode ser preenchida com egos e a prpria passagem do tempo. No final de um longo projeto, pode ser difcil recordar todas as decises anteriores que afetaram sua concluso. Uma forma fcil de conter esta tendncia e prevenir futuros pecados mortais conduzir uma retrospectiva post mortem.Tal processo estruturado pode no apagar os pecados passados de um projeto, mas pode certamente ajudar a prevenir os pecados dos futuros. Referncias
1. Sanjiv Ahuja, "Laying the Groundwork for Success" (Interview), IEEE Software, Nov/Dec 1999, pp. 72-75. 2. Henry Petroski, Design Paradigms, University Press, 1994. 3. Tom Gilb, Principles of Software Engineering Management. Wokingham, England: Addison-Wesley, 1988. 4. Phillippe Kruchten, The Rational Unified Process: An Introduction, 2d Ed., , Mass.: Addison Wesley, 2000. 5. Kent Beck, Extreme Programming: Embrace Change, , Mass.: Addison Wesley, 2000. 6. Steve McConnell, Software Project Survival Guide, Redmond, WA.: Microsoft Press, 1997. 7. Michiel van Genuchten. "Why is Software Late? An Empirical Study of Reasons for Delay in Software Development." IEEE Transactions on Software Engineering, vol. 17, no. 6 (June 1991), pp. 582-590. 8. Bonnie Collier, Tom Demarco, and Peter Fearey, "A Defined Process For Project Postmortem Review," IEEE Software, July 1996, pp. 65-72.
8. Planejando para alcanar no futuro

Para projetos que trabalham em atraso, um erro comum planejar para recuperar o tempo perdido no futuro. A racionalizao tpica que "A equipe estava escalando a curva de aprendizado no incio do projeto. Ns aprendemos muitas lies na maneira mais difcil. Mas agora ns entendemos o que estamos fazendo, e seremos capazes de finalizar o projeto rapidamente.". Resposta Errada!Uma pesquisa realizada em 1991 em mais de 300 projetos encontrou que projetos dificilmente recuperam o tempo perdido - eles tendem a ficar ainda mais atrasados. A fluxo desta racionalizao que equipes de software fazem suas principais decises no incio do projeto - o momento em que novas tecnologias, novas reas de negcio e novas metodologias so menos compreendidas. Revista Viso gil Edio 04
Links
1. Texto original: http://stevemcconnell.com/ieeesoftware/eic19.htm 2. Autor: http://blogs.construx.com/blogs/stevemcc/default.aspx 3. Blog do Tradutor: http://malditacomedia.blogspot.com
30
Cobertura
Viso gil pelo Mundo
Acompanhe a visitao ao nosso site(www.visaoagil.com) durante a ltima edio
31

Avalie o comportamento ideal de um ScrumMaster e suas habilidades vitais
Capa
Autor: Alexandre Magno

Alexandre Magno lder de projetos de software onde utiliza principalmente metodologias e processos geis. Atua na rea de software h mais de 15 anos, j tendo participado de projetos de variadas dimenses de lead time, escopo e investimento. Foi o primeiro Certified Scrum Practitioner da Amrica Latina, sendo hoje membro do comit da Scrum Alliance para avaliao de novos CSPs. Magno o fundador do grupo Scrum-Brasil e atualmente responsvel pelos servios de agile da Caelum (www.caelum.com.br). Contato: axmagno@gmail.com / http://amagno.blogspot.com
Introduo
Atravs deste estou iniciando uma srie de artigos que ir avaliar detalhadamente cada um dos trs principais papis do Scrum. O que motivou esta srie foi a grande quantidade de questionamentos que recebo em meus treinamentos e consultarias em volta deste assunto: quem deve ser o Product Owner? ScrumMaster o gerente de projeto? Ele deve ser tcnico? Um membro do time pode exercer mais de um papel? Por quem so gerenciados os problemas burocrticos do projeto (custo, penalidades, etc.)? Estas so apenas algumas das mais freqentes perguntas que tenho recebido e que acredito que habite a cabea de muitos que esto iniciando (ou no) o trabalho com Scrum.
32
Na srie de artigos ...por ele mesmo no vou citar perguntas e respostas, mas sim situaes reais que aconteceram em variados projetos em meus clientes. Por exemplo, no artigo ScrumMaster por ele mesmo estarei narrando um conjunto de histrias vivenciadas junto a ScrumMasters de alguns clientes. Obviamente no conseguirei abordar em detalhes tudo que envolve o dia-a-dia de um ScrumMaster, nem mesmo este o objetivo do artigo, mas pretendo citar situaes reais de lies aprendidas por clientes em relao a este importante papel em projetos Scrum. Por motivos bvios estarei utilizando nomes fictcios tanto para as empresas e verticais quanto para os ScrumMasters. Espero que o conjunto de artigos agrade a comunidade, e esclarea, dentro do alcance de um artigo, as principais dvidas em volta dos papis no Scrum.
Em Scrum espera-se que os times sejam auto-gerenciveis, o que significa que cada membro do time ser responsvel por decidir o que vai fazer, como e em quanto tempo. Sendo assim a necessidade de termos nos times algum cobrando status de atividades passa a ser nula, visto que cada membro estar comprometido com aquilo que planeja entregar. O grande problema aqui que, devido a anos e mais anos de comando-controle, os prprios membros do time que reclamam tanto deste modelo se sentem inseguros ao se verem com uma carga de comprometimento que no esto acostumados. Ao sentir esta insegurana o mais comum que estes membros tentem empurrar de volta o comando-controle para o lder do projeto (em nosso caso, o ScrumMaster) e aqui que est a grande dificuldade pois, neste momento, o ScrumMaster no deve aceitar o comando-controle que o esta sendo oferecido, mas sim orientar cada membro do time a manter-se de forma auto-gerenciada. Um bom ScrumMaster no aceita o controle, por mais tentador que isto possa parecer principalmente para gerentes acostumados com a forma tradicional de gerenciamento de projetos.
Quem o ScrumMaster?
O papel do ScrumMaster, diferentemente dos gerentes de projeto na maioria das prticas e metodologias, est distante do tradicional comando e controle. Em Scrum, um ScrumMaster trabalha com e, principalmente, para o time. esperado que um ScrumMaster possua as seguintes responsabilidades: Permitir que o time seja auto-gerencivel: esta talvez seja uma das mais desafiadoras responsabilidades de um ScrumMaster, pois no mundo de projetos que temos hoje a prpria equipe espera que haja dentro do time algum com o perfil comando-controle para dizer o que cada um tem que fazer e, na seqncia, controlar o desenvolvimento do que foi atribudo a cada membro do time. Revista Viso gil Edio 04 Garantir que os caminhos para a comunicao do time estejam abertos permanentemente: sem uma comunicao eficiente um time Scrum certamente ir falhar pois ela uma pea chave em todo o processo de gerenciamento de projetos com Scrum. Por este motivo temos que ter em um time algum que seja responsvel por garantir que a comunicao do time esteja funcionando de forma satisfatria, esse algum novamente o
ScrumMaster. Neste cenrio o ScrumMaster deve garantir que no haja nenhuma barreira de comunicao (seja fsica, poltica, hierrquica, etc.) entre os membros do time, entre time e Product Owner (ou especialistas de domnio) e entre Pigs e Chickens. Voltar para o Sprint Backlog 33
Garantir e auxiliar o time a seguir corretamente as prticas do Scrum: o ScrumMaster o responsvel pela boa aplicabilidade das prticas do Scrum no projeto. O time deve enxerg-lo como algum que conhece bastante de Scrum e que est pronto para corrigir qualquer deslize na utilizao de suas prticas e para tirar as dvidas relativas a Scrum de qualquer pessoa envolvida no projeto. Remover qualquer impedimento que o time encontre: durante a execuo das Sprints os membros do time estaro envolvidos em mecanismos que faro com que seus problemas apaream quase que de imediato. Por exemplo, em um reunio diria a membros se do time sero algum encorajados informar tiveram
do time devido solicitaes externas ao projeto.

(1) multi-tarefa quando algum est paralelamente comprometido a executar um conjunto de tarefas de projetos, clientes e interesses diferentes.
Facilitar as reunies do projeto (Planning Meeting, Daily Meeting, Review e Retrospectives): Entenda por facilitao a habilidade de transformar divergncia em convergncia, a habilidade de fazer com que um tema seja explorado de diversas formas diferentes com o propsito de fazer com que todos os envolvidos na discusso consigam entender o que est sendo explorado da melhor forma possvel. As reunies em Scrum, por serem freqentes, precisam ser rpidas e eficientes, e nestas reunies que o papel de facilitador do ScrumMaster deve ser elevado, pois neste ponto que ele precisar utilizar todas as suas tcnicas e conhecimentos de Scrum e de facilitao para fazer com as reunies sejam bem sucedidas.
impedimento no dia anterior e, caso positivo, o ScrumMaster quem dever se empenhar para remover trabalho. aquele O impedimento, do de forma que est mantenha o membro do time focado em seu dia-a-dia ScrumMaster diretamente ligado remoo de impedimentos e, por este motivo, ele deve conhecer habilidades que o faam enxergar os impedimentos o quanto antes e remov-los com rapidez. Proteger o time de interferncias externas para garantir que sua produtividade no seja afetada: o ScrumMaster um tpico lder-servidor e, como tal, uma de suas principais atribuies manter o time focado na meta da Sprint e na viso do produto. Para isso ele deve garantir que fatores externos no estejam interferindo na produtividade do time, isso inclui o surgimento de impedimentos, que por ele devero ser removidos, a interferncia no trabalho de algum membro do time atravs de decises hierrquicas da empresa, que por ele devero ser negociadas, e o surgimento da multi-tarefa(1) dentro Revista Viso gil Edio 04 Voltar para o Sprint Backlog 34
Histrias de ScrumMaster
O ScrumMaster conhecedor A Cosmos Brothers uma empresa com mais de 15 anos no mercado brasileiro, eles possuem uma rede de postos de gasolina com unidades instaladas na regies Sul e Sudeste do Brasil. Paulo Cosmos scio e diretor de tecnologia da empresa e, quando assumiu este papel, determinou que a empresa iria trabalhar com softwares caseiros para a gesto do negcio, ou seja, softwares desenvolvidos por sua prpria equipe. Gabrielle Moraes a atual gerente de projetos da Cosmos, ela gerencia os principais projetos da empresa, que so desenvolvidos por uma equipe composta de 8 (oito) membros, dentre eles: programadores, analistas de requisitos, testers e arquitetos. Gabrielle participou de um treinamento de Scrum h alguns meses e, recentemente, comeou a utiliz-lo no gerenciamento de projetos. Durante a reunio de planejamento do ltimo Sprint, Gabrielle se sentiu insegura para exercer este papel, pois ao ser questionada por Frank sobre qual seria a framework Java ideal para a integrao do produto deles com o de terceiros, ela no soube responder. Entrave similar ocorreu durante a Sprint, veja abaixo um trecho de uma reunio diria: Bom, ontem eu efetivei a criao dos mtodos buscarClientesPorUF Iniciei a e publicao buscarClientesPorRegiao.
...eu j havia mencionado isto na Sprint passada... disse Frank, tambm desenvolvedor do time, tive um problema similar, conforme mencionei em nossa ltima Retrospectiva. Ento, eu at pensei em fazer um upgrade da JRE, mas tive receio desta ao afetar o trabalho dos outros. O que voc acha Gabrielle? - complementou Cristiano. Bom gente......como vocs sabem eu no sou especialista em Java, mas andei dando uma pesquisada sobre este assunto desde a nossa ltima Retrospectiva. Me desculpem, mas eu estou fazendo o melhor que posso para tentar encontrar a melhor soluo para o caso. - disse Gabrielle, a ScrumMaster do time. Frank exps seu ponto de vista - ...ok, mas acho que o quanto antes tivermos isto melhor pois este um impedimento que realmente nos est atrapalhando. Gabrielle, outra pergunta, devemos discutir estes assuntos tcnicos aqui na reunio diria ou deixamos para citar estes problemas na retrospectiva? Bom, acho que no tem problema em falar aqui no...inclusive se algum tiver alguma sugesto para me dar quanto resoluo do impedimento da JRE, eu ficaria grata. - disse Gabrielle. ...devemos discutir estes assuntos tcnicos aqui na reunio diria ou deixamos para citar estes problemas na retrospectiva?
destes mtodos em nosso WebService principal, mas passei a ter problemas porque a verso da JRE instalada no servidor no contempla o recurso de parsing que precisei utilizar nos mtodos... - disse Cristiano, desenvolvedor. Revista Viso gil Edio 04
35
Paulo Cosmos, Scio-Diretor da empresa, estava participando da reunio e deu sua contribuio, Gabrielle - disse ele, eu acho que voc deveria se reunir com alguns desenvolvedores mais experientes para que lhe ajudem neste caso. Se necessrio contratar algum servio de suporte tcnico ou consultoria. timo, uma excelente idia!...bom, Ceclia, agora sua vez de responder s 3 perguntas...mas pessoal, nossos 15 minutos j passaram, ento solicito a todos que respondam s perguntas o mais rpido possvel disse Gabrielle. Ao ser procurado por Gabrielle, ela me narrou o fato ocorrido naquela reunio diria e falou sobre sua apreenso por no conhecer Java. Falou tambm que como o papel do ScrumMaster ficava bem mais prximo do time do que um tradicional Gerente de Projetos, ela via agora claramente que s conseguiria exercer bem este papel se conhecesse profundamente assuntos tcnicos.
verdade Gabrielle, eu disse isso. Mas veja, quando eu digo que um ScrumMaster deve ser conhecedor isto no significa necessariamente ser um grande conhecedor da plataforma ou linguagem de
desenvolvimento que seu time utiliza. eu disse. Gabrielle espantou-se com minha colocao e perguntou No?? Ento conhecedor em que? Eu respondi com outra pergunta Gabrielle, me responda: quais so as principais atribuies de um ScrumMaster?. Remover impedimentos, facilitar as reunies, garantir o uso de Scrum...dentre outras, certo? disse ela. Correto...ento vamos l, como voc pode ser uma grande conhecedora na remoo de impedimentos? enviei mais uma pergunta como resposta.
Bom, depende...mas no caso que estamos falando, conhecer Java me ajudaria a remover o impedimento mais rapidamente rebateu Gabrielle.
Muito
bom
Gabrielle
eu
disse,
Hmmm...vamos
uma
metfora
Gabrielle,
conhecimento nunca demais, e conhecer mais sobre a plataforma de desenvolvimento que seu time est utilizando ser muito bom para voc e para eles.. Pois Alexandre, quando ocorreu este fato eu lembrei de certa vez quando voc me disse que um ScrumMaster deve ser um conhecedor! complementou Gabrielle.
imagine que voc est viajando de carro com sua famlia, seu marido est ao volante, noite e chove bastante... no caminho vocs encontram uma rvore cada no meio da estrada que impede a passagem de vocs. O que seria melhor neste momento: o seu marido ter lido um livro for Dummies de como remover rvores de uma estrada com
Artigos
Eventos
Cases
Tudo sobre Agile
Comunidade
Biblioteca Pblica
Voltar para o Sprint Backlog 36
as prprias mos ou voc ter garantido levar consigo todos os nmeros de emergncia, tal como o da empresa responsvel pelo socorro na estrada? Qual seria o mecanismo mais seguro para fazer com que sua famlia seguisse em frente? - disse eu. Gabrielle respondeu pensativa ...neste caso no necessariamente saber remover uma rvore do caminho com as prprias mos seria a melhor soluo para remover o impedimento". Exatamente Gabrielle... - eu disse, ser conhecedor na remoo de impedimentos no significa saber fazer tudo, mas sim saber direcionar o melhor caminho para a resoluo do problema. Seus filhos estavam no carro, com frio e fome, enquanto isto seu marido lutava com a rvore teimando em tir-la do caminho com as prprias mos, voc pegou o celular e ligou para o socorro que em 20 minutos estava l resolvendo o problema. Em quem voc acha que seus filhos mais confiaro na prxima vez que estiverem em apuros? Em voc ou no seu marido?. Gabrielle entendeu a mensagem, e percebeu que ao tentar resolver o problema da JRE do servidor com as prprias mos ela no s estava atrasando a resoluo de um impedimento e conseqentemente atrapalhando o time como tambm se mostrando como uma pssima removedora de impedimentos, o que, talvez, num futuro faria com que algum membro do time omitisse a existncia de algum impedimento s para no ter que v-la novamente lutando com a rvore. ...no necessariamente saber remover uma rvore do caminho com as prprias mos seria a melhor soluo para remover o impedimento" Revista Viso gil Edio 04
Eu disse Gabrielle, voc deve ter o conhecimento para escolher o melhor caminho na hora de remover um impedimento, isto sim ser um ScrumMaster conhecedor! No entanto no s isso. Voltemos ao assunto da reunio diria que voc citou, nela voc no se mostrou muito boa na facilitao da reunio. Como assim?, espantou-se Gabrielle. Ficou claro para mim que voc no se colocou na postura de um bom facilitador - eu disse Por exemplo, um assunto tcnico citado pelo Cristiano tomou conta da reunio, alm disso, ao se ver apressada voc sugeriu que todos respondessem suas perguntas o mais rpido possvel o que diminui a qualidade nas resposta e nem sequer permitiu que o Cristiano finalizasse seu raciocnio!. ...voc deve ter o conhecimento para escolher o melhor caminho na hora de remover um impedimento, isto sim ser um ScrumMaster conhecedor! , agora percebo que o meu desespero em providenciar uma soluo tcnica para algo que j atrapalhava o time desde a Sprint anterior me fez perder o rumo da reunio disse Gabrielle. No s isso Gabrielle. Por no ter facilitado bem a reunio voc acabou comprometendo o bom uso do Scrum e, como voc mesmo citou, garantir o uso do Scrum uma das principais atribuies do ScrumMaster. Alm de permitir que um assunto tcnico invadisse a reunio, voc permitiu que um chicken interferisse no andamento da mesma - eu disse. Voltar para o Sprint Backlog 37
Puxa, estou me sentido pssima...acho que realmente no sou uma boa ScrumMaster lamentou Gabrielle. No isso, voc apenas estava investindo sua ateno para o conhecimento errado (pelo menos para o momento). Para ser uma boa ScrumMaster conhecedora voc em deve tcnicas primeiramente de facilitao ser e conhecedora da arte de remover impedimentos, ser comunicao, ser conhecedora da cultura da empresa e, to importante quanto, ser conhecedora de Scrum para saber exatamente o que fazer em cada prtica e para enxergar as armadilhas o quanto antes. Ser conhecedora na plataforma de desenvolvimento de seu time ser um timo plus, mas sem dvida nenhuma os pontos citados inicialmente so os mais importantes para um ScrumMaster - conclui.
lder tinha sido um excelente aluno e agora estava claro para mim que ele realmente havia se tornado um grande ScrumMaster. Minha primeira surpresa foi ao constatar que a equipe era muito focada durante as reunies, a tal bolinha para pedir a vez de falar j havia sido apresentada por lder pelo jeito h muito tempo, pois todos respeitavam a vez de cada um falar e faziam isso de uma forma extremamente natural. Num momento seguinte, ainda na reunio, lder interrompeu a apresentao do Product Owner, que estava sendo feita em volta de uma das Features mais complexas do Product Backlog. Ele informou ao time que aquela interrupo estava sendo feita porque ele acreditava que o foco da conversa estava tendo desvios e que o assunto Impresso de Boleto, mesmo sendo deveras importante, no estava diretamente ligado quela Feature. lder ento sugeriu que este tpico fosse colocado em uma rea denominada Rat Hole que ele havia criado no quadro-
O ScrumMaster facilitador
lder era ScrumMaster da Essential Systems, uma empresa que fabricava um ERP voltado para a vertical de mveis modulados. Ele havia sido meu aluno em uma turma de Scrum e depois havia me chamado para realizar um coaching de 60 dias na Essential, e agora, 12 meses depois, entrou em contato para me convidar a participar de uma reunio de planejamento do mais importante projeto que ele estava envolvido atualmente. Aceitei o convite de pronto e, como um chicken, fiquei quieto em um canto apenas acompanhando o desenrolar da reunio.
branco, esta rea iria conter assuntos importantes a serem discutidos, mas que no estavam diretamente ligados quela reunio de planejamento. Ao fazer isto ele trouxe a conversa novamente para o foco, mas sem causar o mal que seria gerado caso ele sugerisse abandonar aquele assunto por ser menos importante. Uma boa tcnica de facilitao. Na segunda parte da reunio de planejamento o time solicitou a presena de algum especialista de domnio que pudesse explicar-lhes em mais detalhes como deveria ser a pgina na qual os usurios conseguiriam visualizar toda a movimentao financeira de um ano para um cliente especificado, pois muito j havia sido discutido com muitas idas-e-vindas na conversa.
38
Carla, a especialista de negcio, falou durante 20 minutos sobre aquela funcionalidade e pareceu colocar mais interrogaes na cabea do time, que descordou em grande parte do que Carla havia explanado. lder pediu a palavra e solicitou que Carla e um ou dois membros do time se aproximassem de um grande quadro branco que ficava ao fundo da sala. Reunindo todos l ele pediu para que tentassem em conjunto desenhar a tal pgina no quadro branco, de forma com que todos os outros envolvidos na reunio pudessem participar. Cada um desenhava um pouco, apagava um pouco e em poucos minutos conseguiram chegar a um consenso, tendo agora em mos (ou melhor no quadro) uma tela que havia sido desenhada por todos. Um conjunto de fotos, tiradas atravs de uma mquina digital, documentou o trabalho. Transformar divergncia em convergncia, esse o objetivo da facilitao. No fim da reunio lder me chamou para tomarmos um capuccino na rea de convivncia da empresa e l chegando ele foi direto ao ponto Alexandre, que tal, o que achou?. lder, foi muito bom! - eu disse, Voc utilizou simples mas poderosas - tcnicas de facilitao e, o mais importante, demonstrou entender perfeitamente qual o papel do ScrumMaster dentro desta reunio. Alm disso o time se mostrou educado e focado, o que com certeza deve ser mrito de sua postura nas reunies ao longo desses ltimos meses. Eles lhe enxergam como um facilitador, como algum que vai ajud-los e, por isso, permitem e enxergam sempre com bons olhos a sua entrada no meio de alguma discusso.
verdade Alexandre - disse ele, eu percebi que com o tempo e com os resultados que eu ajudava a gerar durante as reunies, eles passaram a enxergar minha entrada nas conversas como uma sada para a discusso. Certas vezes percebo inclusive que eles param e ficam olhando para mim, como dizendo: por favor, nos salve desse debate. lder continuou, Mas e agora, como aprender mais sobre facilitao? J li todos os livros sobre este tema e, mesmo sabendo que a boa facilitao parte de aes simples, percebo que preciso aprender mais..
Transformar divergncia em convergncia, esse o objetivo da facilitao.
Veja, facilitao, na minha opinio, uma expanso da habilidade de comunicar. Voc s consegue ser um bom facilitador se for um bom comunicador. A facilitao a arte de tornar mais eficiente a comunicao entre grupos maiores, e quem foi um dos maiores comunicadores de toda a nossa histria se no Scrates? Grande parte das tcnicas de facilitao que utilizo hoje em reunies e retrospectivas foram aprendidas atravs das lies por ele nos ensinada. Facilitao uma daquelas habilidades do ScrumMaster que mais est ligada ao lado humano do que ao lado tcnico da pessoa ., conclui.
39
O ScrumMaster lder
Joo Pedro era Gerente de Projetos de uma das principais empresas de aviao do pas quando nos conhecemos a 2 anos atrs. Naquela poca eu havia sido contratado como consultor para ajudar a agilizar os processos da empresa, e um dos passos a serem dados envolvia a adoo de Scrum no gerenciamento de projetos. Durante o treinamento que ministrei para todos os gerentes de projetos de l, Joo havia se mostrado bastante resistente idia do ScrumMaster no possuir poder sobre o time. Lembro dele ter me questionado bastante sobre como ser responsvel por algo que no se pode comandar e controlar. Foi bom encontr-lo novamente em uma conferncia sobre gesto de projetos e poder convid-lo para um almoo. Ento Joo, pelo que conversei com o Borges (diretor da empresa) recentemente, parece que Scrum realmente se institucionalizou na empresa. O que voc pode me falar sobre isso? eu disse. Como voc sabe muito bem tivemos um trabalho muito duro no incio. Mas a boa execuo daquele desafiador projeto piloto que voc esteve envolvido conseguiu motivar o restante da empresa, tivemos quer criar um Backlog de Projetos uma espcie de portflio para conseguir definir a prioridade de cada e conseguir atender a todos., disse Joo. Resolvi expandir a conversa, Muito bom, me fale um pouco sobre as lies aprendidas, sobre o que aprendeu com o projeto piloto e que conseguiu melhorar nos projeto seguintes?
Alexandre, o ponto principal que posso citar foi a questo da postura, percebi a grande diferena entre ser lder e ser gerente. Antigamente, como um gerente de projetos, eu me portava de uma forma que fazia com que os membros do time me enxergassem do lado de fora do crculo. Percebi que eles s passaram a me enxergar como algum que estava junto com eles dentro do crculo a partir do momento em que mudei minha postura nas pequenas coisas do dia-a-dia. - disse Joo. Voc pode me citar um exemplo de algum fato que tenha deixado isso claro pra voc? - eu disse. Olha, certa vez quando estvamos realizando uma reunio de planejamento, eu estava bastante preocupado para que a reunio fosse executada de forma otimizada, ento a conduzi de forma a fazer com que o time estimasse e planejasse tudo o mais rpido possvel. A conseqncia disso foi que durante a Sprint o
planejamento se mostrou desastroso, e eu tive que sugerir o cancelamento da Sprint. Marquei uma reunio com todos incluindo Product Owner e expus a situao, falei que o planejamento havia sido fraco e que eu me sentia responsvel por isso, por justamente ter forado o time a acelerar o processo. Eu mesmo me surpreendi com essa minha atitude, pois em outros tempo eu,
sinceramente, buscaria um culpado. Para o Product Owner eu diria que o time era inexperiente e se precipitou, para o time diria que o Product Owner no entendia bem do negcio.
40
Faria isso principalmente para que o time no enxergasse minha falha, afinal nada pode ser pior do que ver um gerente seu falhando, certo? Engano meu! Veja que impressionante. Com essa atitude o efeito foi inverso ao que eu imaginava. O time se colocou ao meu lado, dividiu a responsabilidade do erro, e a partir da poucas foram as vezes em que vimos algum no time criando desculpas para algum problema ou tentando colocar a culpa em algum. Vi que aquela minha atitude serviu de exemplo para eles, e a partir daquele momento passei a me sentir um lder de verdade., - finalizou Joo. Muito interessante esta experincia Joo. esse exatamente o papel do lder, deixar visvel que voc igual a todos, tem fraquezas, comete falhas, e por a vai, mas que est ali para ajud-los a fazer um trabalho melhor. No adianta falar de time, tem que sempre apresentar a prova. Se fala que no h indivduos e sim um time, tem que mostrar como que se faz isso, porque todos j esto cansados de discursos. Um bom lder tem que produzir energia diariamente, tem que fazer com que todos se sintam realizando o trabalho mais importante do mundo, tem que inspirar a audcia. - conclui.
Mas Alexandre, disse Mrio, Scrum algo completamente novo para ns, no vejo ningum do nosso time que possa exercer este papel. Sem contar que acho completamente arriscado colocar um projeto nas mos de algum que ainda no liderou nenhum projeto com Scrum. Mrio, justamente por este motivo que estou sugerindo que eu atue como coach, para ajudar o ScrumMaster a seguir pelo caminho correto, ajud-lo a fazer os desvios necessrios e a no cair em nenhuma das armadilhas que surgiro. No entanto, pense no
ScrumMaster como algum que ter que remover os impedimentos do time, esses impedimentos esto
espalhados por toda a empresa e seus departamentos, e muitas vezes at fora dela. Agora imagine que um desenvolvedor do time que estarei fazendo parte me fale sobre um impedimento que precisa ser resolvido, um impedimento burocrtico que envolve pessoas de outros departamentos. Quem devo procurar? Como devo fazer a solicitao? Mas tudo bem, com algum pouco de comunicao eu consigo pular estas questes e fazer a solicitao pessoa certa. Esta pessoa no me conhece, o Duff enorme eu sou novo aqui...ser que eu terei a influncia necessria para remover este impedimento da melhor forma possvel?, eu disse. ... para ser influente no basta ter um alto cargo impresso em seu carto de visitas, mas sim ter um conhecimento verdadeiro da cultura da empresa ... Voltar para o Sprint Backlog 41
O ScrumMaster influente
Mrio Wernner gerente de sistemas do Duff Bank. Ele me procurou a alguns meses para atuar como consultor em um projeto de alto-risco que estava a ser iniciado utilizando Scrum. ScrumMaster deste time. Eu o informei que no achava que esta formao fosse a ideal, citei o fato de eu no conhecer a cultura do banco e de no possuir influncia em volta de todos os ambientes que iriam estar envolvidos com o projeto. Sugeri a minha participao como coach. Revista Viso gil Edio 04
Entendo sua colocao, mas ningum nasce sabendo no verdade? Acho que voc conseguiria aprender como as coisas funcionam aqui num espao de tempo razovel. Eu poderia colocar ao seu lado algumas pessoas influentes que poderiam lhe auxiliar... - disse Mrio. Certo, realmente poderia funcionar. eu disse, Mas veja, o que voc est me propondo exatamente o mesmo que eu. A diferena que eu estou lhe propondo guiar um ScrumMaster seu, e voc est propondo colocar algumas pessoas que conhecem a cultura da empresa e tenham influncia aqui para me guiar. O que ser que mais complexo: Scrum ou a cultura da sua empresa? perguntei. Hmmm...olhando por essa tica vejo que voc tem razo, mais fcil eu colocar algum para ajudar um ScrumMaster do meu time com Scrum do que tentar tornar algum influente aqui dentro. Exato, alm do que eu como consultor sairei da sua empresa ao final do projeto, e voc voltar a ter o mesmo problema de antes. E lembrese, para ser influente no basta ter um alto cargo impresso em seu carto de visitas, mas sim ter um conhecimento verdadeiro da cultura da empresa e ser bem visto dentro dela, conclui.
responsabilidade,
colaborao,
humildade,
comprometimento, influncia e conhecimento. Note que grande parte destas qualidades est ligada diretamente ao lado humano, e no tcnico, de um profissional. Isto vai de encontro com o que foi bastante discutido quando da reunio que originou o manifesto gil, ou seja, precisamos mais de uma mudana de atitude e comportamento em nossos projetos do que de novos processos e ferramentas, e para esta mudana comportamental a qual est diretamente ligada com as responsabilidades do
ScrumMaster precisamos mais de algum com habilidades humanas do que tcnicas. bvio que muito interessante quando o ScrumMaster possui um
conhecimento tcnico suficiente para conversar na mesma linguagem com o time, isto timo pois facilita a comunicao e faz com que o ScrumMaster consiga mais rapidamente ajudar o time, mas de longe suas habilidades humanas, necessrias para conduzir o time mudana comportamental desejada, so mais importantes.
Referncias
Schwaber, K. 2004. Agile Project Management with SCRUM. Microsoft Press Cohn, M. 2007. "Leader of the Band: Six Attributes of a Good ScrumMaster". Scrum Alliance website. Magno, A. 2007. The Daily Meeting Trap. Scrum Alliance website. Goddard, P. 2008. The Hills are Alive with the Sound of Scrum. Scrum Alliance website.
Palavras finais
Mike Cohn, autor de importantes livros sobre abordagens e prticas geis, citou em seu artigo Leader of the band: Six Attributes of a Good ScrumMaster" que as principais qualidades esperadas em um ScrumMaster so:
42
Chamada de Participao
O Viso gil 2008 ser o evento realizado pela Revista Viso gil em parceria com grupos de usurios, que reunir toda a comunidade brasileira do segmento corporativo, tcnico e acadmico, para debater, aprender e construir fortes bases de conhecimento sobre a adoo de metodologias geis nos diversos nveis de uma empresa, atravs de palestras e workshops feitas por grandes profissionais do cenrio nacional e internacional, nas mais diversas vertentes agile como XP(Extreme Programming), FDD(Feature Driven Development), Scrum, OpenUp, DSDM, MSF, Lean, etc. Datas: 19 e 20 de Setembro de 2008, Local: So Paulo, SP Brasil Sugestes de Macro-Temas: #Agile for Business - Planejamento - Estimativas - Mtricas - Custos - Contratos - Gesto de resultados - Gesto de riscos - Modelos de Maturidade - Liderana gil - Estudo de Casos # Core Agile -Requisitos -Modelagem -TDD -Testes -Integrao contnua -Gerncia de Configurao -Documentao -Qualidade -Refactor -Ferramentas
Participe da organizao do evento -Como Palestrante: A Revista Viso gil est abrindo chamada para palestrantes de acordo com os macro-temas do evento, portanto, se voc deseja palestrar, envie um e-mail contendo a seguinte estrutura: - Mini-CV - Ttulo e Macro-Tema - Descrio - Tpicos - Por que sua palestra ser interessante para os participantes do evento? (Mnimo 3 respostas) -Como Grupo de Usurios Sabedora da importncia e da fora da comunidade agile nacional, estamos convidando TODOS os grupos de usurios interessados para participarem da comisso organizadora do evento, dessa forma, os grupos tero possibilidade de contribuir para o acontecimento do mesmo, atravs de: #Responsabilidades: - Pessoas para staff, - Apoio aos palestrantes - Coordenadores de grade, - Coordenadores de mesa, - Divulgao #Benefcios - Nome do grupo vinculado como apoiador do evento, - Espao para apresentar o grupo de usurios ao pblico. - Direito a 4 (quatro) inscries gratutas Importante: Todas as submisses devero ser enviadas para o e-mail eventos@visaoagil.com at o dia 31 de Junho de 2008. Revista Viso gil Edio 04 Voltar para o Sprint Backlog 43
Cobertura
QConference 2008 em Londres
Autor: Felipe Rodrigues

Felipe Rodrigues de Almeida (felipero@gmail.com) Arquiteto Java com experincia de 5 anos em desenvolvimento de sistemas distribudos. Atualmente trabalha na arquitetura de sistemas de GeoProcessamento e, conduz projetos e eventos na Fratech TI. Participa ativamente do desenvolvimento do framework Struts2 e mantm o projeto open-source BoxSQL ( http://boxsql.dev.java.net/). Passa o tempo livre curtindo e cuidando de seus 4 ces.
No perodo entre os dias 10 e 14 de Maro, tive o prazer de participar da QConference. Conferncia de arquitetos de software, realizada em Londres/UK pela InfoQ e que engloba tambm a conferncia JAOO. A primeira coisa interessante que notei foi o local. A conferncia foi realizada no Queen Elizabeth Center em Westminster, ao lado da Westminster Abbey (http://www.westminster-abbey.org/), prximo s casas do Parlamento onde fica o Big Ben e a quatro quarteires do castelo de Buckingham e com vista para a London Eye. Local privilegiado em Londres. Tudo isso foi patrocinado pelos participantes que pagaram valores que variavam de USD$ 680,00 USD$ 2896,00. O mais incrvel que a conferncia estava cheia. Com bem mais de 1.500 pessoas. O que demonstra o interesse do pblico europeu para com esse tipo de encontro. No segundo dia, tivemos vrios workshops sobre Ruby e Ruby on Rails, alm de um workshop sobre Testes e um Workshop sobre Agile, ministrado por David Anderson, um dos criados do FDD.
44
No terceiro dia comeou a conferncia propriamente dita, com participao de incrveis 105 palestrantes. Nomes como Erich Gamma, Rod Johnson, Martin Fowler, Kevlin Henney, Neal Ford, entre outros, abrilhantaram ainda mais o evento, trazendo as tendncias e vises sobre os problemas atuais vividos por ns, mortais arquitetos. Os assuntos foram separados em 16 Tracks ( http://qcon.infoq.com/london-2008/tracks/), forma que cada track tinha seis apresentaes. Pude assistir a algumas palestras sobre Groovy, Um ponto interessante foi a aplicao de conceitos geis na organizao da conferncia. Por exemplo, na forma do participante expressar se gostou ou no de uma apresentao. Na sada da sala, foram disponibilizados cartes coloridos de papel e, um balde. O participante poderia escolher um carto verde, vermelho ou amarelo para colocar no balde. Ao final os cartes verdes eram respostas positivas, os amarelos significam que poderia ser melhor e os vermelhos significavam que no foi boa a apresentao. Isso permitia agilidade e garantia melhor aderncia ao sistema de avaliao. Grails, Ruby, Rails, Henkel, DSL e vrias outras. Infelizmente no era possvel estar em todos os lugares ao mesmo tempo. Mas conversando com outros participantes, pude perceber que todas as tendncias esto linhadas de acordo com o pensamento daqueles palestrantes. Eu realizei minha palestra sobre Domain Driven Design, apresentando conceitos e tendncias nessa rea. Minha palestra fez parte da track Effective Design, que foi organizada por Kevlin Henney(InfoQ) e me deu a oportunidade de conhecer figuras como Pete Goodlife, Udi Dahan, Kent Beck e o prprio Kevlin Henney. Sentado ao lado de Neal Ford, pude observar a palestra de Venkat Subramaniam, que falava sobre como criar DSLs com Groovy, mostrando a fora desta poderosa linguagem. Nesta mesma palestra descobri que meu destino utilizar TextMate para casos em que uma IDE no necessria. Como uso Windows vista em meu
Figura 01 Palestra de Martin Fowler
de
Figura 02 Debate com grandes nomes sobre arquiteura
notebook, procurei uma alternativa e encontrei o E-TextEditor e estou gostando muito.
45
Depois foi a vez de conversar com Pete Goodlife, sobre como eu palestrar em ingls pode ser uma analogia ao desenvolvimento de software quando possuem times que falam idiomas diferentes. O ponto chave foi, ser que conseguimos pensar em um idioma no nativo como a mesma agilidade que pensamos em nosso idioma? No chegamos a nenhuma resposta, mas o assunto foi bem
Figura 03 Noite em um pub para reunir os palestrantes
Outra palestra que me chamou muito a ateno foi : Panel: When is Rails an appropriate choice?h com David Chelimsky, James Cox, Aslak Hellesy, Nic Williamse Ola Bini. Onde eles debateram a qualidade da linguagem Ruby e do framework Rails para uso em aplicaes corporativas. Na quarta-feira a noite, os participantes se reuniram para Drinks and Snacks em um pub prximo ao local do evento. Extremamente divertido e com a cara de Londres, pudemos dar boas risadas. Na sexta-feira a noite, foi a vez dos palestrantes e expositores irem um pub. Pude observar que os arquitetos tambm tem vida social. Bom, pelo menos alguns tm. Outra noite de gargalhadas e muitas conversa com pessoas de todo lugar no mundo. Dentre os americanos a piada foi o pub servir X-Burgers durante boa parte da noite, coisas que eles esto cansados de comer. No pub conversei muito com Floyd Marinescu sobre a InfoQ Brasil e ele garantiu que deseja lana o site no Brasil ainda este ano. O objetivo traduzir o contedo para portugus e tambm gerar contedo, aproveitando nossos profissionais. Eu gostei tanto da idia que a Fratech est negociando a gerncia do site na verso em portugus. Revista Viso gil Edio 04
explorado e nos rendeu algumas horas para tomar cerveja.
Aps o painel de encerramento, voltei para o hotel e no dia seguinte pela manh fui para Paris. Mas essa uma outra histria..
Figura 04 Encontro de alguns participantes frente a ponto turstico de Londres.
46

Autor: Manoel Pimentel Medeiros
Engenheiro de Software, com mais de 15 anos na rea de TI, atualmente trabalha com projetos Java pela Rhealeza(SP). Diretor Editorial da Revista Viso gil, Membro da Agile Alliance e foi um dos pioneiros na utilizao e divulgao de mtodos geis no Brasil. J escreveu artigos para importantes revistas e portais especializados no Brasil e no exterior. Possui as certificaes CSM e CSP da Scrum Alliance. J participou do time de Desenvolvimento do NetBeans, foi criador do framework BoxSQL, fundador do grupo XPNorte e do NUG-BR e frequentemente palestra em eventos sobre processos e tecnologias. Maiores informaes em: http://manoelpimentel.blogspot.com
Artigo
Introduo: O Desafio do ROI (Return on Investment)

No mundo dos projetos, h muito tempo, existe uma necessidade latente em se criar formas de gerenciar o retorno proporcionado por um determinado investimento. Com essa premissa, no mundo do desenvolvimento de software, temos grandes dificuldades em usar mecanismos que forneam formas de mensurar a relao entre o valor investido e o volume de software entregue.
Mas para minimizar essa dificuldade, nos ltimos anos, uma idia que vm ganhando muita fora em funo da grande disseminao da metodologia Scrum, o uso de Business Value como medida para expressar o valor que aquele projeto ir retornar para a empresa e tambm uma forma de definir a prioridade relacionada a cada requisito desejado pelo cliente em forma decrescente, pois a equipe ir sempre trabalhar primeiro nos itens de maior valor de acordo com sua capacidade de entrega. Revista Viso gil Edio 04 . Voltar para o Sprint Backlog 47
Outra atribuio muito importante dessa medida, tambm fornecer meios para acompanhar a velocidade e o volume de entrega que a equipe de desenvolvimento est alcanando, dessa forma, comeamos a estabelecer um ponto de equilbrio da famosa relao entre o investimento financeiro em um projeto e o valor entregue pela equipe em forma de software ou seja, ter mecanismos para tentar maximizar o ROI(Return on Investment) de um projeto de software em uma menor faixa de tempo. Para explicar bem claramente essa idia, imagine que o Business Value ser uma moeda de troca durante o projeto e o cliente empresta um determinado valor dessa moeda para a equipe e esta por sua vez, ter que devolver o valor correspondente em forma de software, ou seja, uma dvida que a equipe assume com o cliente e que dever ser amortizada a cada ciclo(Sprint), at que a mesma seja totalmente liquidada (zerada).
ou seja, no fluxo que o Scrum utiliza, existe um artefato chamado Product Backlog, que rene os requisitos funcionais e no funcionais em uma lista priorizada do maior valor (Business Value) para o item de menor valor definido pelo Product Owner e que no incio de cada Sprint (Iterao), esses itens sero selecionados pela equipe com base nas medidas de tamanho ou complexidade e de acordo com a meta estabelecida para criar um incremento de verso de produto potencialmente usvel.
O Desafio e o Incio da soluo

Outra grande questo como definir formas eficientes e eficazes para acompanhar a evoluo diria das entregas de Business Value, por isso, como mostra Figura 01, o Scrum, oferece o BurnDown Chart como uma forma muito prtica para fazer esse
acompanhamento, pois fornece normalmente um grfico em linha para mostrar diariamente o tamanho das entregas a partir do total selecionado para aquele sprint ou projeto, de maneira que esse valor v gradativamente sendo decrementado at chegar em zero.
O Fluxo do Scrum
importante lembrar que segundo o prprio Ken Schwaber: O Product Backlog priorizado pelo os itens que tm maior probabilidade de gerar valor,
Figura 01 Exemplo de um tpico Burn-Down Chart.
48
Mas o meu objetivo com esse artigo, compartilhar interessante com que voc, surgiu uma devido soluo a bem situaes
Como funciona? Como voc viu no tpico anterior, primeiramente para fornecer as informaes para que o grfico seja gerado, importante que o total de Business Value seja agrupado por Milestones de cada sprint de seu projeto. Portanto, como voc pode ver na Figura 02 temos um resumo de cada Sprint, onde h um quadro que mostra os totais devidamente separados por milestones e tambm adicionamos duas outras informaes nesse quadro, que so:
especficas que vivenciei em alguns projetos. Essas situaes me estimularam a criar e usar uma ferramenta adicional que batizei de responder algumas perguntas Product ao Storage Chart, que simplesmente um grfico para comuns gerenciamento de resultado em projetos baseado em Business Value, influenciado por algumas idias de controle de nveis de estoque numa linha de produo, exemplo: Em matria-prima, produo, perdas e beneficiado (Da o nome Product Storage). Na verdade, foram vrias as perguntas que surgiram durante alguns projetos sobre o acompanhamento das entregas com base em Business Value, porm o contedo dessas perguntas geralmente era: Em que situao est o valor(Business Value) que eu emprestei para esse projeto? ou seja, precisavam saber estava quanto do Business Value destinado para aquele projeto ainda pendente no Backlog, se j estava se estava em selecionado para algum Sprint, entregue.
O total Em Backlog - Para agrupar o total de
Business Value ainda no selecionado para algum Sprint.
O total Acumulado
- Para somar quantos
Business Value j foram entregues durante todo o projeto, com base na soma das finalizaes de todos os Sprints anteriores.
processo, ou simplesmente se j havia sido Veja que uma vez de posse desses dados, basta usar alguma ferramenta de planilha eletrnica ou o meio que achar mais conveniente, para gerar de maneira automtica um grfico de barras verticais tambm mostra a Figura 02. Note que apesar que minha preferncia por grfico de barras verticais, na prtica, esse grfico pode ser feito com barras horizontais ou grfico de pizzas, pois na idia de um Product Storage Chart, o contedo mais importante do que a forma. conforme
O Agrupamento de dados
Com base nessas questes, achar a soluo no foi difcil, pois bastou apurar o total de Business Value agrupado por Milestone de status (PENDENTE, A FAZER e FEITO). Note que esses milestones podem variar de acordo com seu projeto, por exemplo, alm dos trs milestones citados acima, voc pode trabalhar tambm com os milestones EM IMPEDIMENTO, EM INSPEO e REJEITADO. milestones mais simples. Revista Viso gil Edio 04 Porm por uma
questo didtica, resolvi mostrar apenas os trs
49
Veja que esse mesmo raciocnio ser repetido em todos os sprints at zerar a barra Em BackLog e ter todos os Business Value na barra Acumulado no final do ltimo sprint conforme mostra a figura 04
Figura 02 Resumo com os totais e o Product Storage Chart para Sprint 01.
Observe tambm na Figura 02, que no primeiro Sprint, teremos uma barra de Acumulado pequena e principalmente bem menor do que a barra Em Backlog. Na Figura 03, voc poder observar a
Figura 04 Product Storage Chart para Sprint 04(Final)
mecnica desse grfico no segundo Sprint. Veja que a barra de acumulado j est bem maior, pois est levando em considerao todos os valores entregues no final do Sprint 1 e somando com valores j entregues nesse segundo Sprint.
Leituras e Interpretaes
Agora que voc j viu como funciona essa ferramenta, importante saber quais as possveis leituras e interpretaes das variaes desse grfico. A primeira interpretao possvel, obviamente o prprio objetivo do grfico de fornecer uma viso sintetizada do andamento de um Sprint e de um projeto. A segunda interpretao visualizada ao final de um Sprint, pois ser facilmente verificado se todos os valores selecionados para aquele Sprint, foram realmente entregues, ou ficaram pelo caminho (Em progresso, Impedimento, Inspeo, etc).
Figura 03 Product Storage Chart para Sprint 02
50
A terceira interpretao que durante um Sprint, podemos ver se tm um volume muito alto de Business Value em progresso, isso pode significar uma srie de efeitos indesejveis como por exemplo, erro de seleo do tamanho dos itens ou excesso de itens em impedimento.
Observe porm, que o Product Storage Chart, em hiptese alguma deseja concorrer com ferramentas j conhecidas pelo grande pblico como o BurnDown Chart, KanBan, Parking Lot, etc; E sim, o Product Storage Chart pode e deve ser combinado com algumas dessas ferramentas para um melhor e completo gerenciamento de
A quarta interpretao possvel, a identificao de possveis restries do lead time de um sprint, por exemplo, se em uma data prxima ao final do sprint atual, muito significativa INSPEO, ainda houver uma quantia de Business Value em
um projeto gil.
Para finalizar, acredito que esse artigo tenha alcanado seu objetivo principal de divulgar essa tcnica de Product Storage Chart e estimular voc para que sintase encorajado em us-lo, como uma ferramenta adicional para o gerenciamento de Business Value em seus projetos, usando a metologia Scrum, porm, lembre-se que essa
pode ser um sintoma de algum
problema nas prticas de inspeo e testes que a equipe est enfrentando ou simplesmente os impedimentos no esto sendo removidos em tempo hbil. importante observar que vital que essas leituras, estimulem aes gerenciais por parte da equipe, visando aplicar medidas corretivas ou preventivas para evitar que o projeto sofra grandes impactos na sua qualidade.
ferramenta relativa nova e funcionou muito bem em meus projetos, o que no significa que voc no precise fazer uma ou outra adaptao para us-la em seus prprios projetos. evolua! Portanto, no melhor sentido agile, adapte e
Concluses
Como voc viu nesse artigo, extremamente importante ter mecanismos para gerenciar de maneira simples e eficaz, os avanos e o retorno de valor agregado de um investimento em algum projeto de desenvolvimento de software. Com essa premissa, voc observou que a ferramenta Product Storage Chart que apresentei nesse artigo, pode adicionar uma viso mais ampla para o acompanhamento do dia-a-dia da evoluo das entregas de Business Value em projeto usando Scrum. Revista Viso gil Edio 04 Voltar para o Sprint Backlog 51 um tipico Blog do Autor do artigo e da ferramenta manoelpimentel.blogspot.com Schwaber, Ken - Documento eletrnico "What Is Scrum?" Disponvel no site da ScrumAlliance www.scrumalliance.com
Referncias
Nos dias 17, 18 e 19 de Abril de 2008, a Viso gil, participou com um stand na rea de grupo de usurios do FISL 9.0 (9 Frum Internacional de Software Livre) em Porto Alegre(RS), portanto, acompanhe aqui os melhores momentos desse grande acontecimento no mundo de TI.
Viso gil no FISL 9.0
lbum
Victor Hugo, dando um show nas explicaes sobre testes e integrao contnua para o visitantes de nosso stand.
Manoel Pimentel em sua palestra sobre Integrao entre o Struts2 e o JasperReports para relatrios em aplicaes web em Java.
Manoel Pimentel interagindo com Greg Sporar (Evangelista Chefe da Sun para o NetBeans)
Victor Hugo conversando sobre agile com um visitante.
52
Viso gil no FISL 9.0
Manoel Pimentel em contato com as tradies do RS, tomando o famoso chimarro.
Victor Hugo e Manoel Pimentel em entrevista ao pessoal do grupo SAFOS de Belm do Par (br.groups.yahoo.com/group/safos)
Victor Hugo ladeado por visitantes ilustres, Na esquerda: Silvestre Mergulho(XP-Rio) e na direita: Vinicius Manhes Teles(XP-Rio).
Guilherme Chapiewski em sua palestra sobre Desenvolvimento gil de software com XP e Scrum, onde apresentou alguns conceitos e um pouco de sua experincia com agile na Globo.com
Manoel Pimentel em roda de discusses sobre diversos temas agile (Nessa parte, explicando sobre o funciomanento da tcnica de KanBan).
Victor Hugo em roda de discusses sobre diversos temas agile (Nessa parte, explicando sobre o fluxo do Scrum).
53
Apoio
www.tc4digital.com
54

Va 04

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Va 04

Enviado por

Direitos autorais:

Formatos disponíveis

O seu canal sobre processos geis

Avalie o comportamento ideal de um ScrumMaster e suas habilidades vitais

ScrumMaster por ele mesmo

Ano Viso gil Edio 04 Edio 04 Revista II

-Voltar www.visaoagil.com 1 para o Sprint Backlog

Aperfeioamento de Projetos geis Parte II

Nove Pecados Mortais no Planejamento de Projetos

ScrumMaster por ele mesmo

lbum do Encontro da comunidade de Metodologias geis do RS

Cobertura da QConference 2008 em Londres

lbum da Viso gil no FISL 9.0

Gerenciamento de resultados com o Product Storage Chart

Revista Viso gil Edio 04

Voltar para o Sprint Backlog

Alexandre Magno Figueiredo, CSP

e-mail: manoel@visaoagil.com site: www.visaoagil.com

Qualquer edio anterior pode ser baixada gratuitamente no site www.visaoagil.com

Revista Viso gil Edio 04

Voltar para o Sprint Backlog

Revista Viso gil Edio 04

Voltar para o Sprint Backlog

As 5 Doenas do Gerenciamento de Projetos

Autor: Allan Elder

As 5 Doenas do gerenciamento de Projetos

Revista Viso gil Edio 04

Voltar para o Sprint Backlog

As 5 Doenas do gerenciamento de Projetos

Revista Viso gil Edio 04

Voltar para o Sprint Backlog

As 5 Doenas do gerenciamento de Projetos

Workshop sobre Modelagem gil e DDD

Um projeto do "zero" - Dinmicas Prticas

Informaes pelo site: www.fratech.net

Revista Viso gil Edio 04

Voltar para o Sprint Backlog

Revista Viso gil Edio 04

Voltar para o Sprint Backlog

Revista Viso gil Edio 04

Voltar para o Sprint Backlog

O que Integrao Contnua?

Isto significa que, segundo Paul Duval:

Todos os desenvolvedores executam a construo do

Desenvolvedores sincronizaro seus cdigo com o

repositrio de arquivo ao menos uma vez ao dia.

Builds de Integrao ocorrem vrias vezes ao dia num

etc.) que poder ser funcionalmente testado.

Qualquer problema no processo

automtica possui prioridade mxima.

Alguns dos desenvolvedores revisam os relatrios

Integration", Martin Fowler descreve a IC como:

Revista Viso gil Edio 04

Voltar para o Sprint Backlog

O servidor volta ao estado de Pull buscando por mudanas no repositrio.

Identificamos cinco fases principais:

Revista Viso gil Edio 04

Voltar para o Sprint Backlog

Feedback Contnuo e Documentao

Reduo de Processos Repetitivos

Gerar software funcionando

O Valor da Integrao Contnua Reduo de Riscos

Revista Viso gil Edio 04

Voltar para o Sprint Backlog

Ampliar a Visibilidade do Projeto