Scrum no Google Insights
Nós últimos 90 dias, o termo Scrum foi pesquisado no estado de SP.
Nos demais estados não há volume de pesquisas suficiente para exibir os gráficos. DF: o que estamos pesquisando no google?!

O Google Insights é uma ferramenta MUITO INTERESSANTE!!

No vídeo “Fala de Abertura para o VIII Seminário Internacional de Gerenciamento de Projetos do PMI de São Paulo (2008)” , eu retirei as seguintes frases:
- Onde há crise, há oportunidade.
- Gerenciamento de projetos traz propriedade.
- Visão com otimismo.
- Condução dos projetos com ética e responsabilidade.

Fluxo do PMBOK 4a Edição

Por que Gerenciamento das Comunicações?:

- As pessoas DÃO O MELHOR DE SI quando compreendem as decisões que as afetam e suas razões.

- As pessoas precisam perceber:
* O que têm de fazer e por quê.
* Seu desempenho em relação ao esperado.
* Sua situação profissional.

- Objetivos da comunicação:
* Gerar compreensão do exato significado e intenção de outros.
* Ser compreendido por outros.
* Obter aceitação de si mesmo e suas idéias.
* Produzir ação ou mudança.

- Principais benefícios:
* Aumentam o controle gerencial.
* Agilizam as decisões.
* Orietam a revisão da estrutura.
* Melhoram a capacidade de adaptação.
* Permite desenvolver diferenciais competitivos e novas técnicas.
* Antecipam as situações desfavoráveis.

- Principais falhas das comunicações:
* Dados insuficientes ou não confiáveis.
* Pouca sistematização.
* Pouca importância dada à distribuição da informação.
* Interesse voluntário em ocultar informações.
* Falta de um padrão de comunicação.

- Obstáculos para a Comunicação: crenças, distância, diferença de personalidade, distrações, cultura, religião, educação, motivações, tecnicismos e emoções.

- Número de canais de comunicação: n * (n-1) / 2

Eu achei interessente os seguintes trechos:

- Pouco preparo dos interessados na implantação dos PMO`s têm gerado profundas frustações nas empresas.
- Utilização errada da estrutura do PMO com o interesse de “fiscalizar” e “controlar” áreas da empresa.
- Acreditar que implementar um escritório de projetos é instalar um software.
- Não buscar apoio dos alto-executivos, acreditado ser esse um trabalho meramente técnico.
- Implantar visando criar um ambiente de fiscalização e não um ambiente de COLABORAÇÃO.
- Seguir a “moda” do todo mundo está fazendo
- Querer implementar a solução em TODAS as áreas de uma vez.
- Um PMO precisa de:
* Investir na mudança de cultura.
* Criar um ambiente de colaboração e de ganhos para todos, e não apenas para os executivos.
* Criar, de modo democrático, o padrão de trabalho a ser utilizado.
* Alinhar estrategicamente os projetos com os objetivos empresariais.
* Romper o paradigma do imediatismo. Aceitar que os resultados não são tão diretos e instantâneos.
- Tendências dos PMO’s:
* Utilização de Balanced Scorecard para a avaliação de portfólio de projetos no PMO.
* Enfoque mais estratégico para o PMO, AMPLIAR o leque do tradicional controle de cronogramas e custos.
* Desmitificar os escritórios de projeto – NÃO SÃO a salvação da lavoura.

Para saber mais sobre PMO

Cenário:
Ambiente com equipes “não ágeis”, equipes separadas por função (administrador de dados, testes, analistas de requisitos, arquitetura etc.) e necessidade de um “projeto ágil piloto” na TI.
Restrições:
1) Não existe a possibilidade de agrupar totalmente as equipes para o projeto. No máximo, analistas de requisitos, desenvolvedores e líder do projeto. As demais equipes trabalham por demanda. Exemplo: a equipe do projeto piloto solicita a criação do banco de dados. A equipe de banco de dados não participou da reunião, não sabe do que se trata o projeto. Tem uma visão vaga do assunto.
2) Primeiro projeto em Java. A equipe não tem conhecimento das melhores práticas, não sabe de teste automatizado, etc.
Desafio:
Desenvolver um sistema utilizando princípios ágeis.
Perguntas:
1) A criação do banco de dados é uma demanda externa. Como considero isso dentro da Sprint do projeto piloto? Em determinado momento, existirão várias atividades em paralelo e de equipes diferentes.
2) A equipe de teste é externa e solicitou casos de usos. Como a equipe ágil pode contornar esta solicitação? Como o analista de testes que não conhece do negócio terá acesso ao negócio para realizar os testes?
3) Em uma determinada Sprint existem somente atividades de desenvolvimento. As próximas necessidades podem ser levantadas? Como se fosse um adiantamento de atividades?
4) Quais os documentos mínimos necessários que vocês recomendam para um cenário destes? Lembrando que não existe uma comunicação ideal, equipes distintas, etc.
É um cenário que não favorece. É qualquer coisa menos um ambiente favorável para Ágil. É difícil conseguir um ambiente ideal quando se têm várias empresas prestando serviço para a construção de um produto único mas não é por isso, que uma tentativa de um “projeto ágil de ponta-cabeça” não possa ser implementada. Nem que seja só para disseminar a idéia, gerar interesse, etc.
Preciso de sugestões, de algumas ações/atitudes que deram sucesso em ambientes parecidos, etc.

Como sempre, a galera contribui e com ótimas respostas. VALEU!

Alexandre Campos
É Luciana, jogo duro! Não recomendo o scrum para o seu cenário. Voce pode usar algumas práticas. Acho que a sua missão é trazer os valores ágeis para dentro do seu ambiente, uma mudança cultural mesmo. comece pelo manifesto ágil! acho que é um excelente ponto de partida….vc vai trazer valores como: Colaboração com o cliente, entregar software funcioanando, pequenas interações e por ai vai….assim vc consegue construir a base para no futuro adotar a agilidade de verdade…eu só tomaria muito cuidado com os rótulo, procure não dizer: estamos utilizando scrum, estamos utilizando tdd, xp, ou seja qual outra metodologia…isso pode “queimar” a metodologia, trazendo visoes negativas que não corresponde a realidade da metodologia, mas sim do ambiente….acho q uma ordem para vc conseguir implatar metodos ageis seria algo do tipo:
1- introduzir valores ágeis
2- introduzir práticas ágeis
3- metodologia “but” – Deixando claro para todos q a está usando a metodologia but
4- metodologia de verdade (adaptada as necessidades sim, mas

Rafael Prikladnicki
Eu particularmente concordo com o Alexandre. Não adianta empurrar práticas.
Ontem li em outra lista algo que acabei colocando inclusive no meu twitter…
Agile is not a set of practices, but a core set of beliefs and principles
Se tentar colocar práticas, pode sentar e esperar pelo fracasso. Comece apresentando a cultura ágil. Boa sorte!

Silvio Neto
Já participei de um projeto parecido e deu certo. Baseado nisso vou te dizer como eu acho que deveria ser.
E não como foi, pois acho que mesmo tendo dado certo alguns pontos eu alteraria. Para ser mais ágil e principalmente diminiuir o tempo da entrega. Não digo que seja uma verdade absoluta. Só a minha opinião pessoal.
1) Não existe a possibilidade de agrupar totalmente as equipes para o projeto. No máximo, analistas de requisitos, desenvolvedores e líder do projeto. As demais equipes trabalham por demanda. Exemplo: a equipe do projeto piloto solicita a criação do banco de dados. A equipe de banco de dados não participou da reunião, não sabe do que se trata o projeto. Tem uma visão vaga do assunto.
- Pronto analistas, desenvolvedores e lider juntos. OK
- Solicitação de criação de banco de dados. ERRADO.
CORRETO: Um arquivo versionado de script do banco.
O Time de desenvolvimento cria as tabelas, nem que seja usando Derby. Uma vez que a maioria dos projetos hoje em dia em java utilizam JPA. Ou seja o banco pode ser alterado com facilidade. Na entrega de cada sprint você entrega um cd com todo o fonte inclusive o script do banco, para a criação das tabelas pelos DBAs da empresa.
2) A equipe de teste é externa e solicitou casos de usos. Como a equipe ágil pode contornar esta solicitação? Como o analista de testes que não conhece do negócio terá acesso ao negócio para realizar os testes? Você disse que terá analistas, logo terá casos de uso que são os documentos gerados por essa galera. Como a equipe de testes é externa você só vai precisar deles quando tiver casos de uso descritos e implementados. Ou seja você já terá os insumos que eles necessitam para trabalhar.
3) Em uma determinada Sprint existem somente atividades de desenvolvimento. As próximas necessidades podem ser levantadas? Como se fosse um adiantamento de atividades? Para os desenvolvedores começarem a implementação, é necessário um mínimo de conhecimento do negócio. Para isso você deveria rodar a primeira sprint da seguinte forma:
Os analistas começam com o levantamento de requisitos e especificação de de casos de uso.
Que devem ser validados com os usuários diariamente.
Os desenvolveres tendo acesso diário a esses documentos.
Já podem retirar os requisitos não funcionais e montar a arquitectura.
Fazer protótipos (evolutivos) do caso de uso, para testar a arquitetura escolhida e para servir de protótipo aos analistas. Assim que os documentos dos casos de uso forem realmente aprovados pelos usuários (assinado de preferência) e as telas validadas em protótipo. Os desenvolveres aproveitando os casos de uso já podem implementar as regras de negócio enquanto a equipe de testes cria os casos de testes (unitários e funcionais) e a equipe de análise já parte para o levantamento dos próximos casos de uso da próxima sprint.
Quando os casos de uso passarem por todos os testes unitários e funcionais, pronto os casos de uso estão entregues.
4) Quais os documentos mínimos necessários que vocês recomendam para um cenário destes? Lembrando que não existe uma comunicação ideal, equipes distintas, etc.
Primeiro de todos o quadro do scrum com as atividades.
Depois os Requisitos funcionais, Requisitos Não Funcionais, Documento de arquitetura, Casos de Uso, casos de testes. Bem nessa parte acho que exagerei para o ágil né. Vejo esses não como mínimo mas os principais.
Eles ajudaram muito após a entrega do sistema para quem for dar manutenção. Mesmo que sejam os próprios desenvolveres. Espero ter ajudado. Gostaria de ouvir críticas.

Tiago Peczenyj
sugestão de leitura Fragmental – Introduzindo Agilidade num ambiente

Gustavo Resende
Falando em Agile 2008 : Scrum na Globo – Derrubando mitos

Aproveitei o final de semana para refletir e ler muito.

Respondendo a pergunta Vai um Scrum aí? Não! Não cabe.

ps: gerei um post sobre ScrumBut

É como se tivesse um boneco e por adaptação, tira as pernas e coloca rodinhas. Tira o coração e coloca uma bateria. Depois falha, é SCRUM que não funciona!

Na minha opinião, antes de implantar agilidade ou inventar um modelo ágil adaptado ao seu ambiente, é necessário estudar sobre o assunto, fazer uma pesquisa de campo (ver como outras pessoas implantaram, as dificuldades, etc.), procurar consultorias confiáveis e trocar muita idéia por aí.

Eu vejo a “onda” Ágil como uma luz no fim do túnel. Chega de gastar dinheiro com trabalho ineficiente!
São muitos depoimentos de sucesso e o mais legal é a motivação. O Mundo Ágil é algo que “contagia”. É a alegria de se trabalhar com informática, muita novidade e uma comunidade extremamente ativa.

Voltando ao problema exposto, gostei da idéia de inserir alguns princípios ágeis. Eu acho que funcionará melhor do que falar: “Estamos usando SCRUM mas….”

Por favor, nada de criar monstrinhos Scrum!

Obrigada a todos pela contribuição!

Vamo q vamo!!

A Técnica Pomodoro é um método de gerenciamento do tempo que pode ser usado para qualquer tipo de tarefa. Para muitas pessoas o tempo é um inimigo. A ansiedade causada pelo “tic-tac” do relógio, especialmente quando existe um prazo limite envolvido, acaba gerando ineficiência no trabalho e péssimos hábitos de estudo que, por sua vez, acabam levando à procrastinação.
O objetivo da Técnica Pomodoro é usar o tempo como um aliado importante para realizar, à nossa maneira, tudo aquilo que queremos fazer e também nos permitir melhorar continuamente o modo como trabalhamos e estudamos.
Continua em: A Técnica Pomodor

Pomodoro Technique Website
www.pomodorotechnique.com
Pomodoro Cheat Sheet
The Pomodoro Technique Book v1.3
Template – Pomodoro_todo
Template – Pomodoro Inventory

Aprenda a lidar com as interrupções internas (ocasionadas por nós mesmos) e externas.
* Você trabalha numa única tarefa durante 25 minutos, sem parar, e ao final, descansa de 3 a 5 minutos;
* faça isso durante 4 vezes seguidas (são 4 pomodoros);
* ao final de 4 pomodoros, descanse de 25 a 30 minutos.
BENEFÍCIOS: uma (grande) mudança de percepção do seu tempo. Passe a trabalhar por POMODOROS, e não mais por HORAS. POMODOROS são pontos ganhos; uma estimativa que liga tarefas ao tempo de execução de cada uma delas. Trabalhar com POMODOROS ajuda- o no controle da ansiedade e no fluxo de trabalho constante.
Texto Completo em Organize-se e tenha foco

No 4. Tech Day (15/08/2009): palestras com duração máxima de 25minutos.
Palestra feita por Adolfo Sousa – apresentando a técnica de pomodoro, uma maneira simples e eficiente de organizar o dia-a-dia para conseguir focar nas tarefas mais importantes e evitar interrupções indesejadas que impedem o trabalho de ser finalizado.
Hoje é dia de pomodoro

Quer um programa para ajudar na contagem de tempo?
http://www.focusboosterapp.com

Gostei muito desta idéia de palestras de 25minutos. Assisti algumas palestras dos eventos Agiles de uma hora que poderiam ser resumidas em 25min, fora a perda de foco durante a apresentação.

Teste Nokia: de onde surgiu? (por Carlos Santos)

Lembrei essa semana do Teste Nokia (Nokia Test) e fui procurar alguma atualização sobre o mesmo.
Encontrei no blog do Jeff Sutherland e resolvi traduzir pra contribuir com as pessoas que queiram saber mais acerca desse importante checklist. Em 2005, Bas Vodde (CST) estava fazendo coaching em equipes na Nokia Networks na Finlândia e então desenvolveu o primeiro Teste Nokia focado nas práticas Ágeis. Ele tinha centenas de times e queria uma forma simples de determinar se cada time estava fazendo o básico.
O teste Nokia é parecido com uma verificação rotineira de manutenção do seu carro. Como verificar se seu pneu possui ar, seu tanque tem gasolina, válvulas estão boas, etc. Deve executar antes de “rodar” Scrum com seu time. Não é o segredo da alta performance, porém é a primeira linha da receita para a alta performance

Quer conhecer o teste? Teste Nokia

Já recebi links para o blog Fragmental mas nunca dei uma navegada. O blog é muito bom!!! Recomendo demais.
Alguns posts de lá:

Agile Software Deployment
Par de Jarros
Testadores Ágeis
Abaixo o gerenciamento por post-it
Gerenciando Débitos
Introduzindo Agilidade num ambiente

Apresentação

The Agile Process in the PMBOK world

Gary Morgan – Apresentação Completa

Scrummi (Ana Sofia Cysneiros Marçal)
Scrummi é um processo para gerenciamento ágil de projetos que foi desenvolvido como resultado de projeto de pesquisa de mestrado da aluna Ana Sofia Cysneiros Marçal, visando combinar práticas do método ágil Scrum com práticas das áreas de processo de gestão do CMMI.
É um processo de gestão simples e completo, que pode ser estendido e adaptado para atender a uma grande variedade de projetos.
Continua em Scrummi

Don’t be a SCRUMBUT! (post 1 – Bits ‘n Widgets)
…
1. Use a 2-week or 4-week sprint. 2-week preferred
2. Appoint a scrummaster who will hold the team accountable, AND also keep the wolves at bay.
3. Make sure the entire team is jointly accountable for the success of the project.
4. Have a prioritized product backlog ready before the sprint. This can include both bugs and features
5. Have a REAL planning meeting where the team commits to stories and they are thoughtfully tasked out and estimated.
6. Team members commit to stories, and then break them down into tiny pieces (tasks). If any estimates are over 4 hours, break them down further.
7. Do a daily stand-up. What did you do, what are you going to do, and what’s blocking.
8. Don’t do anything that’s not estimated and in the sprint backlog.
9. Establish, post, and meet DONE criteria. It’s only real if it’s posted and visible to everyone.
10. Post a sprint backlog task burn-down chart and update it daily.
11. Keep the product owner in the loop at all times.
12. Hold a stakeholder review a the end of the sprint – this is the fun part!
(13) Then, have a retrospective meeting to discus what went well, what could use improvement, and action items.
Continua em Don’t be a SCRUMBUT!

Don’t be a SCRUMBUT! (post 2 – Bits ‘n Widgets)
But is it really OK to be a Scrumbut? Can the scrum process work if every one of the pieces of the methodology is not followed exactly?
Perhaps…
Scrum works best when all of its pieces are used in the process. It is unlikely that the full benefit of the agile methodology will benefit from an incomplete process. However, in the real world it is sometimes very difficult to get an organization to adopt each and every piece. I think however, that even the teams using incomplete scrum might still be able to get some value out of the pieces that are adopted. Sometimes being a Scrumbut is still better than floating in the barrel as it goes over the waterfall…
Continua em Don’t be a ScrumBut! (segund post)

Were doing Scrum But (Dennis Stevens)
Last week, I went to the source and completed Jeff Sutherland’s Certified Scrum Master course. During the training with Jeff Sutherland last week, he presented a ScrumBut test. We are doing Scrum but… means you aren’t doing Scrum. Not doing Scrum means you likely won’t get the benefits other teams that are doing Scrum have claimed. Scrum, when done well, is a responsible way to develop software and if positioned maturly is a benefit to management. With permission from Jeff, here is the ScrumBut test. Take the test, add up your scores and divide the result by 9.
**Quiz** em Were doing Scrum But

Tradução – Scrum Flácido (Akita)
Dias atrás, Martin Fowler escreveu um artigo que pode ser um pouco polêmico para Scrummers, mas não vejam isso como uma crítica ao Scrum e sim como uma crítica a quem aplica Scrum da maneira errada e a quem não se preocupar em tornar isso aparente. A seguir eu traduzi o artigo dele na íntegra, e no final coloquei alguns comentários meu mesmo.
Existe uma bagunça que eu ouço em muitos projetos recentemente. Funciona assim:
* Eles querem usar um processo ágil, e escolhem Scrum
* Eles adotam as práticas Scrum, e talvez até os princípios
* Depois de um tempo o progresso é lento porque a base de código é uma bagunça
Continua em Tradução (Akita)

Scrumbut (Eric Gunnerson’s Compendium)
As somebody who is interested in Scrum but hasn’t yet had a chance to try it, I’ve been paying attention to the various experiences people are having with it.
I’ve been noticing something for a while, but I didn’t really realize that there was something bigger going on.
I call that phenomena “Scrumbut”. It shows up in the following way:
“We’re doing Scrum but…”
* our sprints are 12 weeks long…
* we do two normal sprints and one bugfix sprint…
* we do all our planning up front…
* we skip the daily meeting…
* our managers decide what’s in each sprint…
* we haven’t read the books yet…
* our team has 30 people…
I’m not a strict methodologist – a specific methodology may need to be adapted to a specific situation. But most of these are anti-scrum rather than modified-scrum.
Continua em ScrumBut por Eric Gunnerson’s Compendium

ScrumBut (Cory Fory)
Scrumbut – 04 partes

Apresentação sobre ScrumBut em ControlChaos.com

SCRUM works great, if you can just follow the (whole) program. It’s not surprising how many organizations say they have failed using SCRUM, when they have only picked and choosen a few of the aspects to implement.
For those of you who need a 12-step program… and you know who you are…

http://blog.seatecnologia.com.br/2009/10/16/sinform-agiles-e-railssummit

http://akitaonrails.com/2009/10/17/rails-summit-2009-retrospectiva

Gostei muito do Manifesto 2.0. Show!

Perdi muito coisa legal.