Os times ágeis trabalham com um conceito que é a “definição de pronto” (DOD – definition of done). A definição de pronto caracteriza quando uma funcionalidade pode ser considerada pronta ou finalizada.

A apresentação do Gustavo Coutinho e Luciano Félix, para o Brazil Scrum Gathering 2009, trata de forma prática o assunto:

Definition of Done

View more OpenOffice presentations from lucianofelix.

Fonte: Código Ágil

Publicada a versão 2009 do Gartner Magic Quadrant for IT Project and Portfolio Management.

O Magic Quadrant é a representação gráfica de um mercado durante um período de tempo específico.

Ele descreve a análise da Gartner de como determinados fabricantes são avaliados com base em critérios definidos pela própria empresa para esse mercado. A Gartner não endossa nenhum fornecedor, produto ou serviço descrito no Magic Quadrant nem recomenda que os usuários de tecnologia selecionem apenas os fornecedores dispostos no Quadrante dos “Líderes”.

O Magic Quadrant é meramente uma ferramenta de pesquisa e não tem como objetivo ser um guia específico de decisões estratégicas.

Os fabricantes são classificados em quatro quadrantes como: “Líderes”, “Desafiadores”, “Visionários” ou “Fornecedores de nicho”.

• Líderes. São aquelas empresas que têm uma atuação consistente no mercado, assim como uma visão clara de direcionamento de marketing. Essas empresas devem, ainda, manter um desenvolvimento de competências para sustentar sua posição de liderança no mercado.
• Desafiadores. Os desafiadores executam bem, mas ainda não demonstram uma visão particular neste mercado.
• Visionários. Estes fornecedores já demonstraram inovação neste mercado, mas ainda terão que apresentar o mix da viabilidade global, dimensão funcional, execução de vendas, e acompanhamento dos registos para passarem para o quadrante dos líderes.
• Fornecedores de nicho. Os fornecedores que se encontram neste quadrante tendem a ter pontos fortes em muitos aspectos do mercado, sem disponibilizarem um suporte mais abrangente. Alternativamente, tendem a ter uma experiência mais limitada em termos geográficos, através da falta de enfoque neste mercado, ou porque são novos no mercado.

Veja na integra em: http://mediaproducts.gartner.com/reprints/microsoft/vol6/article11/article11.html

Fonte: Twitter do Ricardo Vargas

Postado por Mark Levison, traduzido por Gisela Nogueira em 09 Jun 2009 12:20 PM

Recentemente, Kay Johansen fez a pergunta “Porque você ama teste ágil?“. As respostas variaram das mais sérias às mais descontraídas.

1. Não há mais teste manual de scripts! –Ao invés dos scripts serem executados automaticamente, disponibilizando mais tempo para o testador executar testes exploratórios.
2. Desenvolvedores realmente gostam de mim! –Localizar problemas antes do final da interação e enquanto o código está fresco na mente dos desenvolvedores, facilita que eles encontrem o problema.
3. Agora eu posso verificar os recursos antes deles serem escritos! (ambos Kay e Philip) – O testador pode evitar problemas ao iniciar o teste antes que os recursos sejam definidos.
4. Os resultados do teste automatizado podem ser visto muitas vezes ao dia –fornecendo um feedback rápido após qualquer alteração.
5. A atmosfera é fortemente orientada a equipe (John Overbaugh) – Cada membro da equipe se preocupa em terminar os testes e não somente o código (Lisa Crispin).
6. O testador pode ocasionalmente ajustar o defeito  (Lista Crispin) – Cada membro da equipe sente-se mais confortável já que o teste é automatizado.
7. Fornece a oportunidade para revisar constantemente as práticas de teste (Adam Knight) – Ao invés de simplesmente repetir o que foi feito anteriormente, as práticas constantemente revistas. No caso de Adam os testes que costumavam levar 5 dias para serem executados manualmente foram reduzidos agora para 30 minutos.
8. Eu gasto muito, muito menos tempo debugando  (Adrian Howard) – Eu tenho o feedback quase ao mesmo tempo em que cometi um erro, por isso, geralmente é trivial localizar e corrigir.
9. A chance de realmente impactar na qualidade ao invés de somente documentá-la! (Jonh Overbaugh) – quando os defeitos são corrigidos imediatamente ao invés de colocar numa pilha de defeitos.
10. Sempre existe tempo para testar, porque o teste é feito primeiro – Josue Barbosa dos Santos contou a história de trabalhar num escritório do governo no Brasil onde a prática era testar no final do projeto. O desenvolvimento sempre atrasado no cronograma do projeto atingindo o prazo limite e sendo liberado para os usuários sem teste. Com a introdução do TDD e ATDD pelo menos algum teste era executado enquanto o software era desenvolvido.

A razão número um para Kay amar teste ágil: Eu posso ouvir as pessoas falando “esse é o melhor projeto que eu já trabalhei na minha vida!”

Fonte: InfoQ

1. Michele Sliger

Link: http://twitter.com/michelesliger
Bio: Agile coach, trainer, and consultant. Certified Scrum Trainer, PMP.

2. Esther Derby

Link: http://twitter.com/estherderby
Bio: working to help teams deliver software

3. Jeff Sutherland

Link: http://twitter.com/jeffsutherland
Bio: Co-Creator of Scrum

4. Ron Jeffries

Link: http://twitter.com/RonJeffries
Bio: I’m sure you can figure out who I am if you really want to.

5. Kent Beck

Link: http://twitter.com/KentBeck
Bio: Programmer, author, father, husband, goat farmer.

6. Ward Cunningham

Link: http://twitter.com/WardCunningham
Bio: Objects, Patterns, Agile, Wiki

7. Mike Cottmeyer

Link: http://twitter.com/mcottmeyer
Bio: Work… Agile thinker, writer, project manager, consultant >> Life… Christian, husband, dad, guitarist, backpacker, scout leader, and coffee drinker

8. Scrum Alliance

Link: http://twitter.com/ScrumAlliance
Bio: The Scrum Alliance is the leading global professional association for Scrum users. Our mission is to transform the world of work with Scrum.

9. Martin Fowler

Link: http://twitter.com/martinfowler
Bio: Loud Mouth, ThoughtWorks

10. David Alfaro

Link: http://twitter.com/agilenature
Bio: Project Manager for Web Tools, Software Engineer, ScrumMaster, Usability Consultant. All that in Artinsoft. Cross-Browser Compatibilty Junkie

Fonte: Scrumology

Para Ione Coco, ao contrário do que acontece na maior parte dos casos, as áreas de negócio – e não o CIO – precisam decidir quais projetos de tecnologia da informação devem ser implementados primeiro na organização

Tatiana Americano, da CIO Brasil
Publicada em 08 de junho de 2009 às 17h09

A priorização dos projetos de TI sempre foi uma questão polêmica para as organizações e, de forma geral, representa um ponto de conflito entre os responsáveis pela tecnologia da informação e as áreas de negócio. No entanto, Ione Coco, vice-presidente do Gartner para América Latina, considera que a origem do problema está na falta de entendimento sobre as responsabilidades por esse tipo de decisão.

“Existe uma distorção nas empresas, uma vez que a área de TI assume um papel de definir quais os projetos são prioritários para a companhia”, afirma Ione, que explica: “Mas essa responsabilidade não pode ser do CIO e, sim, do negócio, que deve analisar quais as iniciativas são estratégicas e devem ser implementadas primeiro.”

Ainda de acordo com Ione, o papel da área de TI deve ser o de prover as informações necessárias para a construção do escopo do projeto. “Só que quem precisa defender o investimento como prioritário para a companhia é o dono da iniciativa”, complementa a vice-presidente.

Uma das formas apontadas pela especialista para solucionar esse problema é a criação de uma área voltada exclusivamente a gerenciar os projetos da organização – não só da área de TI – e que esteja ligada ao presidente ou ao CEO da companhia.

Fonte: CIO

Postado por Marco Mendes para o Blog do Marco Mendes
em 7 de Junho de 2009

Estive em uma interessante e instigante apresentação de um arquiteto chamado Jan Bosch no último evento do SBQS. Comento aqui alguns dados interessantes sobre a organização de times da Amazon e do Google.

• 3 homens mês x 3 meses. Todo e qualquer projeto tem no máximo 3 pessoas em um tempo não maior que 3 meses.
• A regra das 2 pizzas. O tamanho máximo de um time deve ser limitado pela quantidade de comida presente em 2 pizzas grandes. Fiz rápidas contas e acredito que um o tamanho máximo não deve exceder 6 ou 7 pessoas para que ninguém fique com fome.

Aparentemente, a premissa é colocar como regra corporativa que o ciclo de vida de um produto deva ser guiado por projetos curtos com poucas pessoas e portanto com pouco overhead gerencial. Em times deste porte, podemos ter gerentes técnicos ou mesmo arquitetos que possam conduzir as atividades necessárias a geração de um produto.

Este conceito também traz implicações interessantes. Produtos devem ser gerados incrementalmente respeitando as enormes pressões de tempo de mercado e ao mesmo incentivando a criatividade dos técnicos envolvidos. A técnica clara para que isto opere é uma forte priorização de requisitos e um adiamento dos requisitos menos importantes para futuros ciclos e novas versões dos produtos.

Podemos ver também uma forte influência de culturas ágeis, com a geração de valor (produto operável na mesa dos usuários) como a regra número 01.

Em resumo, o que vemos nestas empresas talvez seja também uma forma humilde de reconhecer que a TI não deve operar como um fim em si mesma mas como uma forma de gerar maior valor de negócios. Projetos pequenos e rápidas liberações parece ser uma estratégia interessante, o que pode explicar uma parte do sucesso da Amazon e da Google.

Fonte: Blog do Marco Mendes

Nesse podcast Ricardo apresenta o gerenciamento ágil de projetos e os conceitos de Scrum. Ele teve um contato inicial com Agile e Scrum e tenta nesse podcast falar um pouco sobre como funciona o Agile e Scrum. Importante ressaltar que Ricardo não é um especialista no assunto. O objetivo nesse podcast é apresentar para os não especialistas em Agile e Scrum alguns dos principais conceitos envolvidos na técnica. Ele tb comete um pequeno deslize no podcast onde fala que scrum é do jogo de futebol americano. Na verdade Scrum é a formação do Rugby.

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

25/05/2009 Gerenciamento Ágil de Projetos e Scrum 1 de 2

Nesse podcast, Ricardo mostra suas percepções sobre o uso de gerenciamento ágil e como isso pode ser utilizado em conjunção com o PMBOK Guide e outros padrões e/ou metodologias para uma prática bem sucedida de gerenciamento de projetos. Segundo podcast sobre o tema.

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

01/06/2009 Gerenciamento Ágil de Projetos e Scrum 2 de 2

Ricardo Viana Vargas é especialista em planejamento, gerenciamento e controle de projetos. Atualmente atua como presidente da Macrosolutions, uma empresa de consultoria de gerenciamento de projetos no Brasil com mais de 20 perfis complexos de projetos do Brasil e América Latina, abrangendo um portifólio de investimentos de mais de $5 bilhões. Ricardo Vargas é membro do PMI desde 1997, e atualmente ocupa a posição de diretoria do Board do PMI. Participou da revisão do PMBOK®, Project Management Body of Knowledge (PMBOK® Guide), e foi membro da equipe do projeto de atualização do PMBOK® Guide em 2004. Também foi presidente do Comitê de Verificação de Tradução para língua portuguesa do PMBOK® Guide 2004.

Fonte: Ricardo Vargas – Five Minutes PM Podcast

Achei esses vídeos de uma oficina Scrum apresentada pelo Guilherme Chapiewski da Globo.com em 29/11/2008:

Parte 1:

Parte 2:

Postado por Luiz Cláudio Parzianello para Lista agile-brasil
em 6 de junho de 2009

Pessoal,

Alguém já viu a paródia que fizeram sobre um trecho de um filme (acredito que tenha sido Operação Valquíria, pois ainda não o vi), onde Hitler fica furioso com os resultados de sua equipe? Pois é, nessa paródia, ele fica muito furioso pois descobre que, no planejamento da sexta iteração, a equipe havia abandonado os testes na terceira pois estavam apresentando muita falha!

É ÓBVIO que a figura central é péssima (um ser abominável) e que o comportamento demonstrado é comando-controle com a disseminação do medo (totalmente contra a cultura ágil), mas que o texto foi criativo e a sincronização do mesmo com as cenas ficou hilária, só vendo para crer!

Quem tiver curiosidade, acesse http://www.youtube.com/watch?v=l1wKO3rID9g

Luiz

O vídeo:

Postado por André Pantalião em 05 Jun 2009 03:48 PM

No Scrum Gathering Brasil, Rodrigo de Toledo, do Cenpes, fez uma apresentação muito competente sobre a cerimônia de Review do Scrum.

Em sua palestra ele mostrou a importância da Review e porque ela propicia uma maior compreensão do que deve ser desenvolvido. A Review, é uma das 2 cerimônias fundamentais para o bom andamento do Scrum e que acontecem ao final de cada sprint. A outra cerimônia é a retrospectiva,mas esta é assunto para outro post.

Mais sobre a Review

A Review mostra ao Product Owner o resultado da sprint. Mas o que é feito na Review:

• A última sprint plannig é relembrada. Mostra-se qual foi a meta e o backlog selecionado.
• Demonstra item por item o que foi feito. O Product Owner que utiliza o sistema e esta apresentação deve ser feita sem uma gota de suor, o time tem que estar tranquilo.

A Review é importante para "homologar" o produto e obter feedback, colhendo possíveis ajustes sugeridos pelo Product Owner. Esta interação com o Product Owner é importante porque quando a pessoa usa, já se altera a concepção sobre o sistema que ele tem na cabeça dele. Se a Retrospectiva é o ponto de inspeção e adaptação do time, a Review é o ponto de inspeção e adaptação do produto.

Segundo Ken Schwabber, na Review:

• Sem aplausos, por favor: Para que o time não vire "mico de aplausos". Se o aplauso acontece quando o time faz o que era esperado ou mais, ele irá sempre tentar isto na Sprint Review.
• Não é necessário nos enfeitarmos. É para ser uma apresentação honesta e sincera.
• E lembre-se, ninguém está sendo julgado!

Expectativas do Product Owner

Existem 3 níveis diferentes de expectativas:

• Para o projeto ou produto: Maximizar o ROI.
• A cada sprint: Maiores prioridades e atender o que foi acordado.
• Expectativas Indiretas: Comprometimento do time, previsibilidade, checar se são porcos ou frangos.

É importante não haver dúvidas sobre o que está sendo pedido e o que está sendo executado. E como o Scrum facilita isto? O Scrum traz a discussão para o momento certo. Ele fez uma ótima conceituação sobre separação da discussão tática da discussão estratégica, que será detalhada em um post futuro.

Preparando uma Boa Review

• Seja transparente, passe credibilidade.
• Utilize um PPT (apresentação) para conduzir a reunião. Mas este PPT é só para conduzir a reunião, não é para ser um show. Quanto mais o time participar, melhor!
• Além do software funcionando leve o gráfico de burn-down e documentos que tenham sido gerados.

Na sequência, ele mostra uma sequência de passos importantes para uma sprint, não precisam ser executados exatamente nesta ordem:

1. Refresque a memória:

• Mostre a meta.
• Relembre a quantidade de pontos, stories e total de stories previstas.
• Time (relembre as presenças e ausências).
• Quantidade de dias que foram gastos na sprint.

2. Realizações, Mostre o que foi feito:

• Total de stories, pontos realizados e tabela de velocidade.
• Stories realizadas.
• Stories extras, estejam ligados ou não a meta.
• Mostre o gráfico de burn-down da sprint, ele é o "heartbeat" do projeto.
• Pode ser uma boa por a lista de impedimentos resolvidos. Ele nunca fez isto na Petrobrás, mas é uma boa.
• Mostre números relativos à qualidade de software.

3. Feedback do time para o Product Owner:

• Mostre os impedimentos que estão relacionados ao Product Owner.
• Resumo filtrado da retrospecitva

4. Próxima Sprint

• Datas
• Pontos previstos
• Previsão de pessoas presentes e ausentes

5. Demo

• Software rodando, entregável. O Product Owner põe a mão na massa, o time deve ficar sem medo, sem frio na barriga. A versão que está sendo entregue deve estar o mais próximo possível do bug free.
• Documentos. Inclua resultado de pesquisas, mesmo que sejam técnicos. Para toda sprint podemos criar uma história de pesquisa, um documento registrando as fontes.
• Um bom pensamento para esta demo, é que você está mostrando para o Product Owner aonde foi o dinheiro.

Após esta apresentação do Rodrigo, fica muito mais fácil realizar uma sessão de Review. Esta sessão por si só não resolverá os problemas, mas fará com que o Product Owner já tenha uma impressão do sistema, critique o que não concordar, o time ganhe mais confiança… Enfim, traz maior visibilidade a todo o processo.

Você já fez sessões de Review? Qual as maiores dificuldades que você enfrentou? Você acha esta uma sessão proveitosa?

Fonte: InfoQ