Depois de apresentar o Scrum ao gerente, e obter a aprovação, chegou a hora de apresentar Scrum a uma parte da equipe (basicamente os dois, além de mim, que irão iniciar o projeto em C#)
A apresentação foi a mesma realizada para o gerente (irei fazer outras apresentações separadas sobre estimativas, TDD e outra sobre extreme programming, se houver necessidade, faria mais em algumas em outros tópicos), a aceitação deles foi boa.
Na verdade eles gostaram da idéia, segundo eles, o maior problema é que atualmente os clientes ligam diretamente para eles e dizem “Vou apresentar tal coisa daqui 2 dias, preciso disso pronto”. E como o número de clientes é grande… já imagina a bagunça, certo? Tirando essa questão da dificuldade atual de estabelecer um sprint backlog e seguir esse backlog, eles não tiveram problemas para aceitar a idéia. Imagino que as maiores dificuldades serão em relação às estimativas e TDD (por isso irei apresentar estes tópicos de forma separada e mais detalhada).
Tenho planejado iterações de uma semana então outra questão que surgiu foi “Então se o cliente ligar na terça-feira pedindo algo, eu vou dizer que só posso entregar na sexta-feira da outra semana?”, a minha resposta foi que “Se o product owner achar na próxima semana que isso é importante, é só na outra sexta. Mas poderemos entregar algo na próxima quarta-feira, desde que esteja pronto-pronto”. Como na nossa situação, ao menos inicialmente, estaremos trabalhando em mais de um projeto, não vejo problema em desenvolver as estórias de um projeto e na quarta-feira já entregar para o cliente e então começar o restante das estórias.
Além disso, eles não entederam muito bem a questão de requisitos+layout+testes+código sendo produzido (quase) em paralelo, mas neste caso eu dei uma explicação mais superficial, ao explicar TDD, vou voltar nesse assunto e deixar bem claro.
Outra questão que surgiu, é que os itens no sprint backlog deveriam ser priorizados, para que caso em alguma semana não a equipe não consiga desenvolver tudo, ao menos ela desenvolva o que é mais importante. Expliquei que como há um acompanhamento diário da evolução, se for atrasar, nós saberemos cedo que irá atrasar e então conversaremos com o product owner para alterar o sprint backlog. A minha sugestão é que inicialmente não iremos priorizar os itens, se notarmos que há essa necessidades, iremos priorizar os itens do sprint backlog.
Na próxima semana pretendo terminar as apresentações (TDD, XP, estimativas) e aí acho que as dúvidas maiores aparecerão, por enquanto está tudo indo bem 🙂
Ahhh, e para bem terminar a semana, hoje (sexta-feira) às 17:00 peguei um pequeno projeto para desenvolvedor (um sistema para os chefes poderem fazer (i.e. anotar) o planejamento estratégico! O bom é que apesar de terem sugerido usar PHP, já comecei a desenvolver em RubyOnRails!