Vai um Scrum aí?

Enviei o texto abaixo para as listas de discussões: agildf@googlegroups.com, agile-brasil@yahoogrupos.com.br e scrum-brasil@yahoogrupos.com.br.

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!!

Teste Nokia

Achei por acaso este blog e tem bastante coisa legal…vai aí um exemplo:

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

Indicação de Blog – Fragmental

Pessoal,

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

ScrumBut – Apresentação Gary Morgan

The Paradigm Shift

The Agile Process in the PMBOK world

Gary Morgan – Apresentação Completa

ScrumBut (compilação)

Scrumbuts are the best part of Scrum (Jurgen)
…
The pattern of a ScrumBut is like this:
Here is a shorter description:
ScrumBut = (practice not being followed)(logical excuse)(workaround)
There’s even a definition for it:
scrumbut [skruhmbut] noun.
1. A person engaged in only partial Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenants of the SCRUM methodology.
4. In general, one who uses the word “but” when answering the question “Do you do SCRUM?”
continua em Scrumbuts are the best part of Scrum

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…

SINFORM, Ágiles e RailsSummit 2 – relatos

Para quem não foi, alguns relatos:

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.

Applying the “80-20 Rule”

Prioritize and focus on what matters the most, you’ll see more benefits emerge with less effort. Ask yourself the question “What are the priorities and are we working on the ones that we value the most”. You’ll see it applies to many other aspects of life, not only the software business!

Artigo completo:

Applying the “80-20 Rule” with The Standish Group’s Statistics on Software Usage

Scrum no Ambiente Bancário – Entrevista

Entrevista com Eduardo Cheng (ScrumMaster) realizada nesse mês de Maio (2009) em Brasília-DF, que narra algumas experiências (erros e acertos) na adoção de Scrum no ambiente Bancário/Financeiro do Sicoob Brasil postado por Manoel Pimentel no Visão Ágil .

Entrevista