Scrum Gathering Brazil: Impressões

Scrum Gathering Brazil: Impressões

Saudações!!
Antes de continuar com este post, um esclarescimento: Como sou um dos editores da InfoQ Brasil, não publicarei informações sobre as palestras neste blog, já que MUITA informação será disponibilizada no http://www.infoq.com/br no decorrer dos próximos dias. Fique no aguardo!

Agora voltando às impressões pessoais do evento:

Cara, Scrum Gathering talvez esta tenha sido a principal oportunidade de encontrar a maioria dos caras que formam a comunidade Ágil brasileira! E todos num único lugar!
Durante os dois dias de evento, nos revezamos discutindo, criticando e trocando informações importantíssimas sobre Agilidade e o impacto disso no mundo dos negócios. O perfil do evento possibilitou imensamente o contato, tendo sido realizado no Hyatt Hotel, em são paulo.

Gostei muito do que vi, apesar de alguns absurdos (como apresentado já pelo Rodrigo Yoshima), mas saí com a impressão que precisamos nos focar em discussões mais profundas sobre práticas e incluir, que sabe, mais práticas ágeis no evento.

Fotos do evento por Manoel Pimentel: Scrum Gathering Brazil


E pra aproveitar esse povo todo em são paulo, fomos tomar cerveja!!



Foto por @rodrigoy

Tem tanta gente nessa foto que não tenho nem coragem de começar a escrever os nomes, com medo de esquecer de alguém. Mas vou citar uma pessoa importante: O Martim Fowler brasileiro: Felipe Rodrigues! Veja-o ao lado de Manoel Pimentel: O Martim Fowler Brasileiro

Valeu galera!!! Hooters foi o bicho!

Parabéns Alexandre Magno e Edmilson Miyasaki pela organização!
Até a próxima!!


PS: Tire férias em outubro! Ágiles 2009 vem ai!

Falando em Agile: Antonio Carlos Silveira

Antonio Carlos Silveira, um dos mais novos gerentes do Yahoo! Brasil, apresentou uma palestra com o tema O Product Owner e o Product Backlog. Pra variar, ele também é um dos caras que já trabalhou na Globo.com, e que ajudou a empresa a utilizar Scrum, tornando-se o maior case de utilização no Brasil. Minha impressão: a melhor palestra do evento

Tudo começa com uma brincadeira muito boa. No dia anterior, o Guilherme Chapiewski apresentou um pouco da atuação dos líderes Ágeis na Globo.com e é claro, mantendo a imagem de uma empresa massa pra caramba!(Foi muito massa a palestra, logo escrevo um pouco sobre ela).

Mas, mantendo seu compromisso principal com a verdade, o Antonio Carlos mostrou como é realmente o trabalho na Globo.com: A competitividade é acirrada!!

A intenção da apresentação era realmente esclarecer o conceito de Product Owner, e o artefato Product Backlog do Scrum. O nome em si não importa, mas os princípios por trás dos papéis e dos artefatos.

Alegoria interessante:

Uma equipe Scrum é formada por:

• Darth Vader - Scrum Master - O protetor do processo
• Stormtrooper Crew - Equipe - Responsável pela qualidade
• Indiana Jones - Product Owner - Vem de uma cultura de chicotada (normalmente um Product Manager)

Tradicionalismo x Agilidade - De onde viemos e Para onde vamos

Tradicionalmente, principal missão de um Product Manager era se antever e prever futuro. Mas Por quê? A fórmula é simples:

• Se antecipar aos acontecimentos de um projeto pode reduzir incertezas
• Reduzindo incertezas provavelmente diminuirá a quantidade de Change Requests
• Como Change Requests são caras, reduzir sua ocorrência certamente diminuirá o custo do projeto

Surge a figura de um Product Manager carrasco, que não se importa com a saúde das equipes que trabalham para ele, e está mais preocupado a cumprir um cronograma custa o que custar.

Não existe, neste ambiente, uma preocupação em adaptar-se à mudança, mas em restringir a mudança. Antecipar-se é o principal foco deste modelo, mesmo que o nosso mundo esteja seguindo na direção contrária. AC atribuí a isso uma espiral negativa dentro das empresas: setores de tecnologia querendo restringir mudanças devido aos custos elevados, e os setores de marketing buscando adaptar os produtos aos mercados.

Este é o principal motivador para o crescimento de métodos Ágeis. Assim, o que queremos é a agir rapidamente a qualquer Request de mudança. Ao invés de criar procedimentos para restringir mudanças, precisamos abraçar as mudanças adaptando-se o mais rápido possível.

O Product Owner

O papel do PO primeiro de tudo é: Ele precisa entender o Cliente Ele precisa responder às seguintes perguntas:

• Qual o seu Target ?
• Quem é o seu público alvo?
• Quais são as personas? (dica do Danilo Bardusco)
• Quem se quer atingir?
• Por que um cliente gastaria dinheiro com o seu produto?

Além disso também, o cliente é uma Ponte entre os Clientes e o Time, inclusive na hora de buscar mais informações quando seu conhecimento do domínio do problema não é completamente compreendida. Assim, ele facilita o contato entre o Business e o Desenvolvimento.

Existe sempre uma tenção entre este PO e a equipe. Em métodos Ágeis, TUDO é baseado em confiança. E qual o paradoxo desta realidade: estamos num mundo em que confiamos muito poucos uns nos outros, e desenvolvimento Ágil para funcionar precisa muito de confiança.

Espiral negativa da vez:

• PO não confia no time, porque normalmente não recebe o que solicita. Assim, o que ele faz? Atola a equipe de solicitações, na esperança de ganhar alguma coisa "do balaio"
• A equipe sabe que o PO vai pedir mais do que eles conseguem produzir. Como sair dessa? Estimar cada vez mais tempo para completar as tarefas...

É isso que precisa ser mudado para que um ambiente ágil seja produtivo. Transparência é a palavra de um projeto Ágil. Inclusive, para que se entenda melhor essa alegoria. Imagine um projeto scrum como um barco: Se ele afundar, vai todo mundo pro buraco.

• O PO pode ser técnico? Não necessariamente. Primeiramente, o PO precisa entender a equipe: sua capacidade de produção. Precisa entender que não é apenas empurrando trabalho para a equipe que mais software vai ser entregue. O Danilo Bardusco já escreveu sobre isso.

É necessário criar um ciclo virtuoso em que:

• O PO entender as necessidades de esclarescimento da equipe.
• Estimula a equipe no limite, para que ela consiga se comprometer e produzir o melhor produto. Tendo orgulho do que faz.
• Sabe que um número, que a preocupação apenas com produtividade não trará o resultado esperado.
• Trás um ponto de vista para a equipe que agregue valor para a equipe

PO: Cria a Visão

O PO precisa pintar uma imagem bonita, para onde todos da equipe queiram seguir. Dois exemplos foram citados: Disney e Mirosoft. A primeira empresa cria uma Visão única, que guia todos da empresa, e é um dos motivadores de seu sucesso:
We create happiness by providing the finest in entrertainment for people of all ages, everywhere

Na criação desta Visão, o Product Owner deve estar preocupado em conquistar a equipe como um todo. E para isso a visão deve ser:

• Compartilhada e compreendida por todos
• Deve criar o desejo na equipe em fazer parte desta conquista
• Deve ser clara e concreta
• Deve ser difícil de ser alcançada, mas não impossível

Você é o product owner de um projeto? Qual a visão do seu software? e a equipe, entende essa visão?

PO: Entende o domínio do Problema e da Solução

Deve ser a referência sobre o Domínio do problema. Ele deve ser o ponto focal para a equipe, quando ela estiver em dúvida. E pra isso ele deve ter poder de decisão.

Receita para o fracasso:

Um product Owner que nunca decidiu nada. Criando a "Síndrome para o PO Mensageiro": Se para tomar qualquer decisão o PO precisa se comunicar com alguém para pedir a opinião, o problema está formado. Quais as consequências disso?

• Equipe vai desconsiderar o papel do PO, indo diretamente à pessoa que decide.
• O Time passa a tomar decisões. Se sentindo no direito de tomar as próprias decisões sobre o produto.

É necessário que o PO imponha respeito à equipe. Tudo que está sendo dito aqui é sobre pessoas, e a interação entre elas. Esqueça ferramentas! O que importa é a relação entre esse as pessoas, a maneira como você interage com elas. Comunicação Oral é o principal! Lembre-se disso: ferramentas não vão substituir o sucesso da interação pessoal entre as pessoas. (Repetitivo? náá)

Além disso, é obrigação do PO aceitar o que for produzido pela equipe. Para isso:

• Deve estar presente para esclarecer dúvidas (deve estar próximo)
• Deve avaliar o que for produzido

Aqui, o AC indica um estudo bastante interessante: A universidade de Michigan descobriu (há quase 10 anos), que equipes multiciplinares juntas produzem mais que o dobro do que equipes separadas por salas, predios, etc. Leia a notícia

Nota importante: é o PO que organiza o Release Plan para o produto. Ele que encontrará o melhor momento para lançar uma versão nova do produto.

PO: Responsável pelo ROI

Sim!!! Retorno sobre investimento!

É o foco do PO! Normalmente relacionado a dinheiro. Mas não necessariamente o dinheiro em si. Acima de tudo, ROI deve estar ligado a um objetivo mensurável:

• Dinheiro
• Audiência
• Satisfação do Cliente
• Fidelidade

PO: Responsável pelo Product Backlog

Resumindo o que apresentamos acima: O Product Owner tem como função?

• Entender o Cliente
• É o elo de comunicação entre os Clientes e a Equipe
• Entender do domínio do problema e principalmente possui o poder de decisão sobre o projeto
• Aprova/Rejeita o resultado do Sprint
• Responsável pelo Release Plan
• Responsável pelo ROI
• Responsável pelo Product Backlog

Lembrando que: Product Backlog é uma lista priorizada (em qualquer mídia) e ordenada com coisas que trarão algum benefício para o usuário.

Como descrever itens do backlog? User Stories!

AC ainda explicou sobre a profundidade na elaboração do Product Backlog, já explicado na apresentação: 10 ways to screw up with Scrum and XP. (Numa imagem muito bonita: 3D, tons pastéis, Estrelinha e um "r" no logo!)

O que define um bom Product Backlog?

• Está Planejado adequadamente para os próximos 3 Sprints, ajudando o time a ter uma visão maior sobre para onde estão indo.
• Sempre priorizado. Para que a equipe consiga escolher sempre o item mais prioritário
• Sempre visível: Isso trás transparência
• Deve ser mantido pelo Produtc Owner (não é função da equipe priorizar o Backlog)

Priorização

Foram citados os modelos de priorização:

• Kano Model
• Benefício Relativo
• Modelos Financeiros
  • VPL
  • TIR
  • Payback

Principal Bibliografia Ágil sobre o assunto: Agile Estimating and Planning por Mike Cohn

No Modelo de Kano, deve-se categorizar o product backlog através do valor percebido pelo cliente. Em três categorias:

• Must-have: Obrigatórios (Um hotel deve ter cama)
• Linear: Quanto mais melhor (Cerveja grátis no quarto do hotel - ótimo )
• Exciters: Necessidades não conhecidas (TV de LCD 42'' no Quarto - ótimo, mas não faz tanta diferença)

Para cada item do Backlog, faça duas perguntas:

• Funcional: O que vc acha de ter uma Latinha de cerveja de graça no quarto de hotel, quando vc chegar?
• Disfuncional: Se você chegar num hotel e não tiver uma latinha de cerveja de graça no quarto, o que vc acha?

No método de Benefício Relativo é necessário, primeiramente, que as estórias estejam estimadas. Após isso, preencha a seguinte tabela:

	Benefício em ter	Penalidades em não ter	SUM(BV)	Estimativa	BV/Est
Funcionalidade 1	1	9	10	2	5
Funcionalidade 2
Funcionalidade 3
Funcionalidade 4

A Ordenação se dá pela coluna BV/EST

Mesmo sendo um método bastante interessante, em sua experiência, Antonio acredita que no final é o chutão que conta. A Utilização de personas pode ajudar bastante.

É isso... Esses relatórios estão ficando bastante extensos... mas espero ter passado a idéia da apresentação... aos que não assistiram...

Antonio: Parabéns pela apresentação!

(Acompanhe as impressões dele sobre o evento, além inúmeras referências)

Tomei a liberdade de adicionar neste blog os slides da apresentação (sem autorização, desculpe!). Aproveite:

Falando Em Agile 2008: Product Owner and the Product Backlog

Scrum Checklist em português

Lá vou eu de novo! Mais uma pequena tradução...

Desta vez, peguei a versão Mapa Mental que o Henrik Kniberg colocou à disposição num post em seu blog.

Usando o FreeMind, ai está a primeira versão:Scrum Checklist_ptBR.mm


clique para ampliar...

Divirtam-se e ajudem a melhorar o documento...

Lean: Como maximizar o feedback?

Adaptado do livro: Lean Software Development: An Agile toolkit.

Passo a passo para ampliar o feedback

1) Escolha o seu problema mais difícil e encontre uma maneira de ampliar o feedback

a. Amplie o feedback das equipes de desenvolvimento à gerencia perguntando a cada equipe ao término de uma interação as seguintes perguntas:

• A equipe possuiu todos os conhecimentos necessários para esta iteração?


• Algum recurso necessário faltou?


• Como podemos modificar nosso trabalho de forma a tornar o desenvolvimento mais rápido e melhor?


• O que está atrapalhando o caminho?

b. Aumente o feedback dos clientes e usuários para a equipe de desenvolvimento mantendo um grupo com foco no usuário final. Encontre as respostas para as perguntas:

• O quão bem esta sessão do software resolverá o problema para o qual ela foi criada?


• Como pode ser melhorado?


• Como esta última iteração afetou a sua percepção sobre as suas necessidades?


• O que você precisa para colocar este último incremento de software em produção?

c. Ampliar o feedback do produto para a equipe de desenvolvimento pode ser feito através de:

• Ter os desenvolvedores escrevendo e executando testes de código à medida que o código de produção é escrito


• Ter analistas, clientes ou testadores executando e criando testes de aceitação à medida que os desenvolvedores trabalham no código. Permita que os desenvolvedores auxiliem nestes testes com o intúito de automatizar tudo.


• Permita que desenvolvedores tenham acesso aos testes de usabilidade de cada uma das funcionalidades próximas de serem finalizadas, para que eles possam verificar como os usuários reagem à implementação

d. Amplie o feedback dentro da própria equipe através de:

• Torne os testadores em parte integrante da equipe


• Incorpore todos os envolvidos no projeto desde as primeiras fases


• Estabeleça a política de que a equipe de desenvolvimento deverá manter o produto

2) Inicie iterações com sessões de negociação entre clientes e desenvolvedores. Clientes devem indicar quais funcionalidades possuem a prioridade máxima, e os desenvolvedores devem selecionar e comprometerem-se somente com aquelas que eles acreditam realmente serem capazes de completar no período fechado da iteração

3) Insira os gráficos de progresso para seu projeto em uma área comum para que a equipe(s) possa visualizar sem problemas o que precisa ser feito e que todos possam ver para onde o projeto está convergindo

4) Se você dividir um projeto através de múltiplas equipes, faça um esforço a mais para dividir a arquitetura de maneira a permitir que elas possam trabalhar o mais independentemente possível. Encontre maneira dos times sincronizarem o próprio trabalho o maior número de vezes possível (build contínuo do sistema todo)

5) Equipes independentes devem considerar também a interface do usuário de forma independente

6) Encontre o seu problema mais complexo e faça sua equipe conseguir três soluções viáveis para resolvê-lo. Ao invés de escolher apenas uma das soluções, permita à equipe experimentar todas as três opções ao mesmo tempo.

[]s

Por que Scrum funciona?

• A natureza iterativa de desenvolvimento do Scrum(incluindo a reestruturação de prioridades entre as iterações)


• Celulas de desenvolvimento completas do Scrum (juntos todas as pessoas necessárias para realizar um trabalho)


• Pelo fato de muitas equipes utilizando Scrum tiveram a change trabalharem no mesmo ambiente físico


• Muitas equipes Scrum trabalham em um projeto por vez


• A maior parte dos relatorios chatos e pesados, além de formulários burocráticos estão sendo deixados de lado porque as equipes estão produzindo algo novo


• O Foco em definir testes de aceitação juntamente com os requisitos


• A disponibilidade de campeões(Donos do produto e entusiastas de Scrum)

Entenda a história Completa

[]s

Velocity? que tal Capacity?

Desabafo muito interessante de Tim Ottinger da Object Mentor, falando sobre um dos termos mais utilizados em scrum: Velocity

Complementando o post do Tim, vou aproveitar e tecer alguns comentários...

Trocando em miúdos: velocidade é a CAPACIDADE da equipe em produzir uma parte do sistema... simples?? Nem tanto.
Notou a ênfase no termo capacidade?

Isto quer dizer que, tendo em mente o conceito de funcionalidade finalizada:

Uma equipe deve medir a velocidade desde que este valor não seja tomado como um indicador de pressão. Vou explicar melhor: imagine-se numa equipe Scrum. Até ai, tudo lindo e maravilhoso... a quantidade de trabalho que a equipe consegue suportar com saúde é 35 pontos(ou horas ideais). Qualquer mudança neste número pode significar duas coisas: um desastre para seu gerente ou uma aparente evolução da equipe.

Quando for um desastre

Somos seres humanos, e qualquer gestor não identificará com bons olhos a menor variação para menos no valor da Velocidade da equipe. Por quê??? Oras, é muito mais fácil criticar e dzer que a equipe deixou de cumprir as "metas" e está fazendo corpo mole.
Entenda, nesta situação a Velocidade está sendo encarada como uma medida de produtividade, sem que explicitamente isto seja dito. Assim, a primeira atitude seria forçar o retorno ao estado anterior, mesmo que para isso seja necessário cortar qualidade. Isto fere completamente as Regras de Ouro do Desenvolvento Ágil e removerá muitos dos benefícios da abordagem.

Aparente evolução da equipe

É bom finalizar uma Sprint com o Burndown zerado... certo? Orgulha a equipe, dá direito a pizzas, talvez uma ida mais cedo pra casa... e assim, no próximo Sprint o melhor a fazer é conseguir "aquele pouquinho a mais", pra incentivar a equipe a se esforçar mais... para no proximo sprint, se tudo correr bem, forçar um pouquinho a mais as "metas"...


Moral das duas histórias: Onde está a preocupação com o quê foi produzido?? É muito fácil se perder em números e na tentativa de controlar a produtividade da equipe através de gráficos burndown que finalizam "na mosca" e pré determinando a velocidade dos sprint.
Velocidade é uma medida de estado/capacidade e não predição. Ela apenas determina o quanto, na situação da sprint, a equipe é capaz de fazer.

Meça produtividade de outras formas: label: Métricas

Uma sugestão interessante: você consegue analizar a relação:

Funcionalidades Finalizada X Valor de Negócio X Sprint

Não??? Antes de pensar em quantos pontos uma equipe faz ou deixa de fazer, meça o quanto a produção deles está lhe trazendo de retorno... vai se surpreender...
Metas, no desenvolvimento Ágil, são as funcionalidades que a equipe conseguiu alcançar, e não a estimativa que tais atividades possuem... Meça o que realmente importa, deixa a equipe cuidar do resto




Pra finalizar:

Treinamento Scrum SC - Teamware

12 e 13 de Maio - Florianópolis

Objetivos:

Cada individuo será treinado para ser capaz de assumir as seguintes responsabilidades:

• Utilizar Scrum para gerir o trabalho como membro de uma equipe de desenvolvimento de produtos.
• Remover as barreiras entre o desenvolvimento e o cliente, para que o cliente dirija o desenvolvimento.
• Ensinar o cliente como maximizar o ROI e alcançar os seus objetivos através de Scrum.
• Melhorar continuamente a vida da equipe de desenvolvimento através da liberação da criatividade e o fortalecimento.
• Melhorar continuamente a produtividade da equipe de desenvolvimento de todas as formas possíveis.
• Melhorar continuamente as práticas de engenharia e suas ferramentas, para que todo incremento de funcionalidades seja potencialmente entregável.

Mais informações: Gestão Ágil de Projetos com Scrum SC


[]s

Release Planning

Prática originária do Extreme Programming, ela pode ser bastante útil para a implantação de Scrum em sua empresa, principalmente para as empresas que possuem um cultura mais tradicionalista em gerenciamento de projetos.

Release Planning pode ser definido como: (Fonte)

Criação de um Plano de Projeto baseado nas expectativas do cliente juntamente com o histórico de desenvolvimento do produto. Planejamentos iniciais são necessariamente imprecisos: prioridades nem estimativas são sólidas, e até a equipe iniciar o trabalho não há como saber o quão rápido seguirão. Mesmo o planejamento para o primeiro release não será claro, e continuamente este plano será revisado pela equipe/cliente.

Integrando ao Scrum

Criando Roadmap do Projeto

Scrum é basicamente sobre fatos reais, não contos de fada. Assim, o Product Owner, interpretando o valor de negócio das funcionalidades, forças técnicas e restrições de mercado pode transcrever suas expectativas em um roadmap (Mapa de produto), para que possa preparar-se melhor na evolução do projeto.

Este roadmap será simples. Fornecerá deadlines e a priorização (em nível macro) necessária para criar o Plano de Release.

Meça o presente olhando para o futuro

Steve McConnell (9 Pecados Mortais do Gerenciamento de Projetos) fez uma interessante comparação:

Eu imagino um bom planejamento de projetos como dirigir à noite com as lanternas ligadas. Podem existir mapas que dirão como ir da Cidade A para a Cidade B, mas a distância que posso ver em detalhes através de meus faróis é limitada. Em projetos de médio 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".

Interpete a citação acima da seguinte forma: Mantenha um pequeno plano sobre três Sprints à frente da atual. Revise este plano a cada Sprint Review para manter nítidas as suas intenções de curto e médio prazos. O product backlog, macro e priorizado por valores de negócio e criticidade, continuará existindo, estou apenas propondo um item a mais na sua incursão no Desenvolvimento Ágil.
Utilize os resultados do Sprint, Retrospectivas e o Sprint Planning para manter-se focado no estado real do projeto para determinar qual caminho seguir.


[]s

Marcio Marchini at edugraf

Saudações a todos!
Bem, na semana passada, em Florianópolis, houve uma apresentação do Marcio Marchini, consultor da Bedarra, empresa Canadense do Dave Thomas. Bem, o Marcio está no Brasil para auxiliar a Audaces na adoção do desenvolvimento Ágil. Estamos crescendo muito com a participação dele!

Desculpe a divagação.

Na terça passada o Marcio fez uma apresentação (aula aberta) com o título "Desenvolvimento de Software no Silicon Valley North", mostrando sua experiência com Desenvolvimento de software e principalmente com Desenvolvimento Ágil.
A palestra foi bastante produtiva, e alguns pontos são importantes ressaltar:

- Na Rational eles usam Diagramas de classe para o desenvolvimento? Resposta: HAHAHAHAHAHAHAHA
- Na Rational eles fazem testes automatizados? Resposta: HAHAHAHAHAHA
- E na IBM? Resposta: HAHAHAHAHAHA
- A Microsoft utiliza o Project para desenvolvimento de Software? Resposta: HAHAHAHAHAH

"Em casa de ferreiro o espeto é de pau"...

Também foi uma oportunidade para o Marcio divulgar os serviços da Bedarra no Brasil... com o CTIP (Continuous Test and Integration Plattaform), que é uma compilação de vários sistemas para promover a Integração Contínua.

O Edugraf disponibilizou os slides da apresentação, e logo estará disponível o video com a palestra... vale muito a pena conferir!

Veja os slides: Marcio-Bedarra-Agile.pdf

[]s

Um pouco de Alan Shalloway

Allan Shalloway, da NetObjectives apresenta seu ponto de vista sobre os benefícios do Scrum:

Fonte: Praise for Scrum

A natureza iterativa do Scrum permite o aprendizado rápido. Sendo Scrum baseado num modelo iterativo, é normalmente necessário construir uma parte do sistema e inclusive entregá-la ao cliente para receber feedback e somente assim continuar. Esta natureza permite aprender rapidamente as necessidades do cliente tão bem quanto aprender de que forma otimizar o próprio processo de entregar valor agregado ao cliente.

A inclusão do cliente, assim mais valor pode ser entregue rapidamente. Focando-se na relação entre o cliente e a equipe, Scrum traz à tona um dos maiores desafios para a equipe: conseguir informações concretas sobre o que construir. Scrum provê uma serie de idéias para lidar com clientes sobre a ótica de produtos. Construindo software em partes com o contato direto com o cliente, as funcionalidades mais importantes podem ser entregues rapidamente.

Diminuição do risco de construir a coisa errada. Apresentando o mais rápido possível as funcionalidades implementadas ao cliente, a equipe pode diminuir significativamente as chances de construir ou interpretar errado requisitos. Isto é extremamente importante, sendo o maior risco para o desenvolvimento de software. Construir funcionalidades que não serão utilizadas é obviamente desperdício de recursos. Entretanto é muito pior do que se imagina. A complexidade extra, e não utilizadas, deste software pode causar ainda maiores custos de manutenção, que serão normalmente maiores que o custo de construir a funcionalidade.

A ênfase em na remoção de impedimentos. Sendo Scrum um ótimo processo para iniciar, seu foco em remover impedimentos leva a equipe à procura de continuamente melhorar seu desempenho. Isto não apenas possibilita à equipe gerar mais valor, é um beneficio para a propria criação do time. E uma ótima equipe produzirá muito mais valor com um processo capenga do que uma equipe mediana. Boas equipes com processos ótimos podem ser realmente maravilhosos.

Dá a oportunidade às pessoas perceberem que estão no controle de seu destino. Remover impedimentos da vida de alguém possue um efeito espiritual. Traz à tona a consciencia de que esta pessoa não é a vitma, mas o capitão de suas proprias decisões.

Facilmente implementado pela equipes. O fato de Scrum ser tão simples é impressionante. Com apenas um dia de treinamento já é possível iniciar a sua utilização. Vitórias rápidas são as melhores!

The Enterprise Scrum

Saudações! Eis a minha mais nova aquisição, o novo livro do Ken - The Enterprise Scrum. Seguindo a indicação do próprio Ken Schwaber, na lista scrumDevelopment (sim, ele respondeu um email meu!!! hahahahah que merda).
Os questionamentos que me fizeram comprar o livros estão relacionados à formas de extrapolar a utilização do movimento Ágil, deixando o ambiente de software e TI para uma visão mais ampla e estratégica da empresa. Talvez tenha encontrado uma pequena introdução neste livro...

Estou no início do livro, mas algumas coisas são interessantes:
- Afirmação clara: Scrum não resolverá seus problemas. Pelo contrário, ele os tornará mais explícitos e será difícil não encará-los. Portanto, se você não está pronto para resolver seus problemas, utilizando o scrum, você apenas vai deixá-los mais expostos.
E tenho visto esta a afirmação realmente ocorrer em nossa utilização do Scrum na Audaces. Conflitos sempre ocorrerão. E realmente, este é o maior sinal de que a mudança que propomos com o Desenvolvimento Ágil está acontecendo...
- O livro é mais uma tentativa de vender inúmeros livros e cursos para formação ScrumMasters... como não poderia deixar de ser...


Está sendo interessante a leitura...

[]s

Implantando Scrum em 10 passos

Saudações!!

Bem, aqueles que acessam o site já devem ter percebido que eu disponibilizo uma seleção de posts direto dos feeds que assino (GoogleReader Shared Links)...
E tenho acompanhado muito de perto os escritos de Kelly Waters, do All About Agile. Ultimamente Kelly tem escrito um série de posts sobre como implantar Scrum de forma simples (será mesmo??? )... valeu MUITO a pena a leitura...
Infelizmente não estou com muito tempo para traduzir, e provavelmente o farei em breve... então lá vai o texto em inglês:

How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...

Scrum at Yahoo and Google AdWords.

O vídeo abaixo foi retirado do site AgileSoftwareDevelopment, e conta a história de como Yahoo! e o projeto Google Adwords passaram a utilizar Desenvolvimento Ágil apresentada por Jeff Sutherland (pai da criança)...

Uma aula excepcional... ASSISTAM!

Resumão PIV (pra inglês ver):

Yahoo
1. Yahoo já foi uma empresa "organica". Existiam vários pequenos grupos com a capacidade de realizar qualquer coisa com o mínimo de disciplina.
2. Houve a necessidade melhorar a estrutura da empresa. Assim, os consultores entregaram 300 páginas de um processo Pesado e complexo. Todos odiaram a iniciativa, e não trouxe reais benefícios para aempresa
3. Viram scrum como a possibilidade de retornar às origens, enquanto ainda teriam alguma estrutura. Atualmente o desenvolvimento de produtos é realizado utilizando Scrum (Mais informações: aqui )


Google AdWords
1. Em 2001 existiam inúmeros gerentes no Google. Eles costumavam a dizer a pessoas inteligentes o que elas deveriam ou não fazer. Então a empresa livrou-se deles.
2. Então tornou-se comum inúmeras equipes orgânicas de três pessoas com liderança rotativa. Em torno de 160 equipes se reportavam para uma única pessoa - sem problemas uma vez que os times não necessitavam instruções. Ainda assim aplicações b2b precisavam de muitos retornos do cliente.
3. Scrum tornou-se uma opção bastante promissora. Sua hierarquia é bastante próxima do que eles já possuiam, mas ainda assim possui alguma estrutura e permite facilmente a apresentação de prioridades de forma mais clara.

Com vocês, o vídeo:

Fonte

Em busca de uma Empresa Ágil

Success, particularly today, is a function of a team's ability to react to change, not its ability to plan and follow that plan. How teams are measured affects their adaptiveness. Adaptation—rather than adherence—brings success.

Fonte:The Measure Of A Management System

Tenho pensado muito sobre métricas e formas de mensurar progresso em equipes ágeis, e a forma que estas informações se alinham às informações necessárias para a tomada de decisão dos diretores de uma empresa Ágil.
Num post anterior, trabalhei a questão mundana deste tema, isto é, apresentando ferramentas de medição condizentes com o Processo Ágil. Danilo Sato, em sua teste de mestrado, apresenta de forma detalhada outras ferramentas. Vale a pena a leitura!

Mas gostaria de ir além...

A revista Better Software Magazine, apresenta um artigo mostrando de que maneira métricas de progresso devem ser aplicadas para garantir a real avaliação de desempenho para equipe de Desenvolvimento Ágil. Leia o artigo completo.


Fonte: Wikipedia

Dentro Balanced Score Card(BSC), existem 4 perspectivas bem definidas: Financeira, Cliente, Processos Internos e Aprendizado/Crescimento. A figura apresentada inlustra bem a forma como tais perspectivas se comunicam, numa relação de causa-efeito. Empresas privadas que visam o lucro que somos, é natural imaginar que a perspectiva financeira venha à frente de decisões estratégicas. Gostaria de tratar sobre a perspectiva do cliente.

Cliente
Medidas claras focadas a segmentos específicos devem ser apresentadas a toda a organização. Compartilhar a informação em todos os níveis da empresa, e garantir que indicadores de progresso estejam disponíveis é uma forma bastante clara de alinhamento entre decisões estratégicas e iniciativas.
O Feedback contínuo dos representantes destes segmentos é uma maneira de garantir alinhamento e progresso. Como nos Princípios do Desenvolvimento Ágil, software em funcionamento é a primeira medida de progresso. E sendo assim, transformar a satisfação do cliente em um indicador é um grande passo.
Na lista xpRio, Clavius Tales, da Fortes Informática, apresentou os resultados obtidos utilizando XP. Uma ótima medida de progresso utilizada pela equipe do Clavius foi "satisfação do cliente". Os resultados:

Alguns números que podem não dizer muito, mas que me impressionaram: amanhã finalizamos, com vinte dias de adiantamento, um projeto daqui da empresa, que tinha originalmente um prazo previsto de quatro meses e meio. A equipe era formada por onze colaboradores. Monitoramos a satisfação do cliente através de uma nota semanal entre 0 e 10. Na última semana, a nota ficou em 9,88 - chegou a estar em 7,8. Também monitoramos com uma nota entre 0 e 10, só que diariamente, o moral da equipe. A nota atual está em 9,8 - chegou a estar em 7,9. Estamos trabalhando com um nível de 75% de todas as práticas de XP (versão 2).

Um abraço.

Clavius Tales

Para tomar proveito da ligação entre cliente e desenvolvimento, gerando informações válidas para a empresa, é necessário uma intervenção branda através de medidas de desempenho que alimentarão indicadores do BSC.
Uma forma de se fazer isto é através da Análise de Valor Agregado (do inglês EVA), que pode ser adaptado para auxiliar analistas de negócio e diretores a garantir o ROI mais adequado na utilização do Desenvolvimento Ágil.
Nota Importante:Não estou tratando o ponto de vista do patrocinador de um projeto (o cliente), mas da empresa que utiliza o desenvolvimento Ágil como forma de garantir Qualidade, flexibilidade e menor custo.
Definição: "Earned Value Management (EVM) is a method for integrating scope, schedule and resources, and measuring project performance.” Fonte: APM with Scrum
Um artigo muito interessante (e complexo) que trata desta informação foi publicado pelas empresas SolutionIQ e InfoTech: acesse o artigo.
No documento, os autores concluem que a adaptação da técnica de EVM para o Scrum pode trazer resultados semelhantes à análise do Burndown, e deve ser utilizado em conjunto com as ferramentas do scrum, gerando informações importantes sobre releases e adequação orçamental.

Trabalhar com valor de negócio e agregação de valor ao cliente é uma postura bastante diferente do que estamos acostumados em nossos projetos. Para a maior parte das empresas, um projeto no prazo e debtri di orçamento é mais importante do que garantir que os clientes estejam realmente satisfeitos com as soluções promovidas. Isto é preciso ser alterado para que se possa atingir maiores benefícios relacionados ao Desenvolvimento Ágil.

Measurement systems are crucial to creating an agile enterprise, particularly for those projects that implement new products, services, or processes that will create your future company. If you are creating the future, an extra month or a few extra dollars will be insignificant. If you don't deliver value or you don't deliver innovation, that will be significant. We cannot continue to ask teams to be innovative, flexible, and adapt to changing competitive conditions and then measure their performance by forcing them into narrow expectation alleys. We have to be as innovative with our measurement systems as we are with our methodologies.

Entre a Expectativa e a Satisfação

Isso somente ocorre por aqui, em Florianópolis: Mulheres normalmente reclamam que os homens não prestam, e estes por sua vez, sempre dizem que elas querem demais... Interessante os pontos de vista discordantes desse conflito, onde mulheres esperam muito dos homens, que por sua vez, por não terem o real conhecimento do quê elas esperam, acabam passando a imagem de desleixados, relapsos, insensíveis ou inadequados. Seria isto uma realidade? Somos assim tão a quem das expectativas?

É realmente complexo assumir a postura: "Eu sei tudo o que você precisa, não se preocupe, vou satisfazê-la!" e não quebrar a cara dentro de uma relação. Isto porque é humanamente impossível saber de antemão o que pode ou não satisfazer uma mulher sem que ela mesma seja consultada a respeito. E todos nós somos diferentes neste sentido... é necessário que a conquista seja iterativa, isto é, a cada momento descobre-se o que é necessário fazer para suprir uma necessidade, obtém-se o feedack e parte-se para outra necessidade... hehehehe simples né?

Seria nossa atitude como profissionais semelhante? Não estaríamos tentando satisfazer clientes imaginando de antemão tudo que ele possa querer?
Motivação para mim é um assunto bastante delicado, e está solidamente aplicado em conceito do Desenvolvimento Ágil, talvez as características psicológicas e sociais relacionadas ao Scrum e XP é que tornem sua utilização mais agradável para as equipes.

Ciclo de expectativa e a atuação do Cliente

Como consumidores que somos, no dia-a-dia, sempre temos uma opinião formada sobre o que nos agrada e o que não nos agrada. O fato desta noção ser tão pessoal, faz com que muitas vezes tenhamos uma postura pessimista com relação a alguns produtos, já que não existe uma preocupação em produzir algo personalizado, que atenda nossas próprias necessidades.
O modelo de entrega contínua de valor agregado e feedback contínuo em práticas de Sprint Review, Sprint Planning, Jogo do Planejamento, Cliente Presente e iterações menores garante maior satisfação do cliente.
Infelizmente, expectativas são inversamente proporcionais à satisfação. Isto é, lembrando do exemplo amoroso acima, quanto mais uma mulher espera de um homem, menor será a satisfação que ela terá ao perceber que não é possível para seus parceiros suprirem tais expectativas.

O mesmo ocorre com seus clientes, que esperam 6 meses ou até mesmo um ano para poderem visualizar o software em funcionamento. Assim, o resultado esperado por eles não consegue ser atingido, já que eles passaram tempo demais fantasiando como seria o sistema.
No Desenvolvimento Ágil trazemos para nível contornáveis esta balança entre expectativa e satisfação. Isto é: se quanto mais se espera de um sistema maior é a frustração em não obter o resultado, vamos diminuir a quantidade expectativas e, no menor tempo possível, receber o feedback necessário para mudar e adequar-se às novas expectativas que surgem.
Simples? Nem tanto. As várias práticas relacionadas acima se unem para garantir que o cliente esteja sempre satisfeito, ou ainda, que no menor tempo possível ele receberá algo concreto com o qual poderá gerar valor para sua empresa.
Scott Ambler traz de forma exepcional uma comparação entre modelos tradicionais de feedback e os modelos Ágeis, que trascrevi uma parte neste post (sim, em inglês). Leia o documento completo

Technique	Description	Feedback Period
Active Stakeholder Participation	Stakeholders (users, managers, support people, ...) are actively involved with the modeling effort, using inclusive techniques to model storm on a just in time (JIT) basis.	Hours. A stakeholder will describe their requirement(s), then the developer spend several hours, or perhaps day or two, implementing them to produce working software which they can then show to the stakeholder(s).
Agile Model Driven Development (AMDD)	AMDD is the agile version of Model Driven Development (MDD). With an AMDD approach, at the start of a project you do some high-level, initial requirements modeling and initial architecture modeling. During development you model storm on a just in time basis.	Hours. With model storming, you explore a requirement with your stakeholder(s) or a technical issue with other developers and then spend several hours or days implementing working software.
Big Design Up Front (BDUF)	With a BDUF approach, a comprehensive design document is developed early in the project lifecycle which is used to guide the implementation efforts.	Months. It is typically months, and sometimes years, before stakeholders are shown working software which implements the design.
Big Requirements Up Front (BRUF)	With a BRUF approach, a comprehensive requirements document is developed early in the project lifecycle which is used to guide the design and implementation efforts.	Months. It is typically months, if not years, before stakeholders are shown working software which implements their requirements.
Code Inspections	A developer's code is inspected by her peers to look for style issues, correctness, ...	Days to Weeks. Many teams will schedule reviews every Friday afternoon where one person's code is inspected, rotating throughout the team. It may be weeks, or even months, until someone looks at the code that you've written today.
Continuous Integration	The system is built/compiled/integrated on a regular basis, at least several times a day, and ideally whenever updated source code is checked into version control. Immediately after the system is built, which is often done in a separate "project integration sandbox" it is automatically tested.	Minutes. You make a change to your code, recompile, and see if it works.
Model With Others	The modeling version of pair programming, you work with at least one other person when you're modeling something.	Seconds. You're discussing the model as you're creating it, and people can instantly see a change to the model made by someone else.
Model/Documentation Reviews	A model, document, or other work product is reviewed by your peers.	Days to Weeks. A work product will be created, the review must be organized, materials distributed, ... The implication is that it can be weeks, or even months, before the item is reviewed.
Pair Programming	Two developers work together at a single workstation to implement code.	Seconds. You're working together to develop the code, the second coder is watching exactly what the person with the keyboard is doing and can act on it immediately.
Test Driven Design (TDD)	With TDD, you iteratively write a single test then you write sufficient production code to fullfill that test.	Minutes. By implementing in small steps like this, you quickly see whether your production code fulfills the new test.
Traditional Acceptance and System Testing	Acceptance testing attempts to address the issue "does the system do what the stakeholders have specified". System testing, including functional, load/stress, and integration testing, attempts to address the issue "does the system work". With traditional testing the majority of testing occurs during the testing phase late in the lifecycle. Testers will write test cases, based on the requirements, in parallel with implementation.	Months. By waiting until the system is "ready for testing", the testers won't see the system until months after the requirements are finalized.

Entre amores e projetos, seguimos tentando a todo custo gerar um único valor: satisfação.

[]s

Impressões - Semana Acadêmica do Senac

Saudações a todos!

Recorde para mim: 3 capitais brasileiras em menos de uma semana...
Informação off-topic: Dona Rita, minha mãe, defendeu o mestrado esta semana e está toda feliz pela nota 10 com louvor na PUC/SP. Isso ai! PARABÉNS MÃE!! Estou em São Paulo para comemorar junto com ela essa conquista!! (...)

Voltando.
Quinta feira apresentei duas palestras na semana acadêmica do Senac, como descrito no post anterior. Muito bom!! Para as duas primeiras palestras falando de Desenvolvimento Ágil que fiz... até que foi ótimo!

Bem, foi bastante diferente do que imaginei, mas gostei muito da experiência...
A primeira das apresentação foi para um grupo pequeno de alunos do curso de Análise de Sistemas, e confesso ter ficado um pouco receoso se o foco estaria realmente adequado para os participantes, mas no final correu tudo bem, espero que as pessoas tenham gostado.

A segunda apresentação, com 50 inscritos foi mais tranquila, me senti mais à vontade com as perguntas dos participantes, e o ritmo da apresentação foi mais orgânico. Tanto que consegui falar por mais de 2 horas... absurdo! E só duas pessoas dormiram!! Com certeza um recorde!

Questões importantes: precisamos exercitar mais nosso poder didático e explicar melhor conceitos, evitando que coisas saiam mal entendidas. Mais de uma pessoa me perguntou: "vem cá, como esse tal de XP consegue elimar toda a documentação? Isso funciona mesmo?"... vamos produtores de conhecimento, aos princípios!! Eles nos salvarão da mediocridade do mundo... Agilistas Uni-vos!

Fiquei muito feliz em saber que um grupo de desenvolvimento de um Hospital de Porto Alegre conseguiu utilizar eXtreme Programming em uma equipe php, influenciando os demais desenvolvedores a utilizar algumas práticas. Um comentário interessante que ouvi: "Uma coisa interessante que identificamos é a mudança de postura com os cliente: ao invés do papel de chato, sempre cobrando 'e ai, ta pronto já esse sistema?' que os cliente faziam, passaram a ser os próprios desenvolvedores a cobrar por atitudes mais colaborativas dos clientes: 'e ai, já testou a funcionalidade que lhe enviamos?'". Bom!! Muito bom!!

Abaixo segue uma parte da apresentação... apenas o início... agradeço ao Pelotas (vulgo professor Guilherme) por ter gravado essas partes no celular... tb não consegui editar o video para que ele ficasse na posição correta... hahahah eu sei, eu sei... está horrível, mas alguém sabe me dizer como deixá-lo correto???
PS: desculpem as tosses!! que coisa feia!

Palestra - Semana Acadêmica Senac RS

Saudações a todos!
A convite de um grande Amigo (Guilherme Pelotas), hoje estou de viagem marcada a Porto Alegre apresentar a palestra: Desenvolvimento Ágil - O desafio da mudança no dia 25 (quinta-feira)

A apresentação será feita na Semana Acadêmica das Faculdades Senac.

Bem, minha intenção é apresentar alguns princípios por trás do desenvolvimento Ágil (seguindo o exemplo de Kelly Waters) e de que maneira eles se unem gerando softwares de qualidade e divulgando empresas como o Google (se é que existe alguma empresa como o google). De forma descontraída, quero passar o que acredito ser o mais importante no desenvolvimento de software.

Programação do evento:
http://www.senacrs.com.br/2007/personal/2007109/10361.pdf
Uma correção: Meu nome é Victor Hugo Germano =)

Segue o pdf da apresentação:
http://www.4shared.com/file/27325657/fa6c772e/Desenvolvimento_gil.html

Novamente, minha intenção é divulgar o desenvolvimento Ágil, por isso disponibilizei a apresentação em seu formato real... sinta-se livre para modificá-la, critiá-la e distribuí-la.... desde que mantenha as referências... (chame-me de lunático... mas eu sou completamente partidário da mentalidade Wikinomics) =)
Ainda estou verificando a questão de copyrigth das imagens... mas logo se resolverá.

[]s

Tornando-se um líder Ágil - Parte 2

Como acabar com um projeto em nove passos

Se você já passou por projetos que:

• Simplesmente não deu certo


• Foi cancelado e você nem foi avisado


• Foi um desastre de proporções nababescas


• Atrasou por meses, com orçamento estourado e seus cabelos brancos


• Acabou com seu cabelo de tanto stress

Este texto não serve para você... muito provavelmente por o que escreverei você já deve saber...

Bem, com a experiência de quem já passou por projetos assim, Steve McConnell escreveu sobre Nove pecados que não se deve cometer, caso queira que seu projeto seja um sucesso. (não foi o caso de um projeto que participei...). Engraçado, mas o artigo que li é de 2001, mas completamente atual! Que coisa, será que até quando vamos acreditar nos velhos paradigmas??? Quantos projetos mais devem ir por água abaixo?

Vamos lá: (Fonte: The nine Deadly Sins of Project Planning, 2001) (versão online)

1- Planejamento Nenhum!
Obviamente, sem planejamento, não há projeto que se sustente... ou melhor, talvez possa existir por algum tempo, mas efetivamente ele ruirá por não conseguir suportar os encargos que um projeto desse tipo possui. Nota mental: encontre profissionais que saibam planejar e não seguir planos.

2- Falha ao levar em conta todas as atividades do projeto
Não planejar o suficiente. Não menospreze problemas que podem ocorrer durante o percurso do projeto. NUNCA crie planos irreais em que se assume que o projeto estará lindo e maravilhoso não importante o que ocorra com sua equipe, seu sistema, a tecnologia envolvida...
Extremamente importante levar em consideração: versões antigas do projeto, o tempo de setup para deploy da aplicação, a falta de testes suficientes, a motivação e comprometimento da equipe...
Problemas devem ser corrigido no momento em que eles surgirem em sua frente!

3- Falhar ao planejar levando em consideração o risco
Tudo bem se você não gosta de Desenvolvimento Ágil, mas acreditar que a melhor coisa a fazer é deixar para se preocupar com riscos de projeto só quando for tarde demais é burrice! Neste ponto o fato que nós tentarmos priorizar as tarefas, realizando as mais importantes primeiro, é que saimos na frente no controle de riscos. Assim, os pontos mais críticos do sistema são resolvidos primeiro e possuem acompanhamento diário, aliviando a vida de todos.

4- Utilizar o mesmo planejamento para todo projeto
JOGUE FORA A EXPRESSAO: "Esta é a forma que fazemos as coisas aqui na empresa"!!!!!!!!!!!!
Cada projeto deveria ser único, ou você terá grandes problemas em adequar tudo ao seu Modelo Unificado de Projetos...
Este tipo de atitude funcionará muito bem enquanto os projetos forem semelhantes. No momento em que um projeto novo, com escopo e necessidades novas surgir, você estará encrencado.
Não digo para criar um modelo de gerenciamento completamente novo para cada projeto da empresa, mas deixar esse mesmo modelo flexível às especificidades que cada projeto possui. Isso inclui, por exemplo, não tratar um projeto Web da mesma forma que se trata um projeto Desktop.

5- Utilizar modeos empacotados indiscriminadamente
Seguir princípios não quer dizer que não se possam fazer ajustes à realidade do projeto. Acreditar que comprar o livro sobre eXtreme Programming e utilizá-lo a risca vai ser o máximo é assinar o atestato de fracasso.
Identifique necessidades, estude soluções e aplique as melhores práticas de forma coordenada, para que tudo possa ser validade em seu ambiente... e o mesmo serve para o RUP, CMMI, PRINCE2, etc

6- Permitir que o planejamento se torne divergente da realidade
Um procedimento comum em projetos é criar um plano inicial e tentar seguí-lo na medida do possível. E independentemente do que ocorra, tentar manter este mesmo plano no decorrer do projeto...

7- Planejar com muitos detalhes de início
Fato: REQUISITOS MUDAM
Poderíamos discutir por horas aqui, mas não vou fazer isso, deixarei que a experiência de vocês fale por si só.
Além do óbvio disperdício de tempo e recursos que existe ao se planejar com muitos detalhes de início, eu acredito que o maior problema dessa abordagem é o descontrole emocional que isso pode causar numa equipe. Imagine-se trabalhando numa especificação por 6 meses, e então durante o primeiro mês de desenvolvimento descobre-se que a tecnologia ou os requisitos não vão atender à demanda. Todo seu trabalho será jogado fora e refeito... quem não gostaria de um bom saco de pancadas para evitar os pensamentos homicidas neste momento?

8- Planejar pela compensação
Não acredito em curva de aprendizado durante o planejamento. Seja consistente e realista ao traçar um planejamento para adesão de novas metodologias, novas pessoas e novos projetos. Se você planejar supondo que a equipe compensará o tempo perdido, certamente acabará com um projeto atrasado. Já passei por um projeto desses, é frustrante...

9- Não aprender com as experiências passadas
Um projeto que participei, como programador, em que TODOS envolvidos com o desenvolvimento me disseram a mesma coisa: "Que droga, está acontecendo exatamente como nos outros projetos, vai dar tudo errado"...
Aceite o desafio da mudança! Credite na experiência dos projetos, faça sessões de retrospectivas... somente assim pode evitar a repetição de erros conhecidos... é o que dizem: "erra é humano, mas persistir no erro..."

Até mais!

Compartilhando equipes Ágeis

Product Owner único, Scrum Master responsável por manter a ordem e o foco no projeto, e uma equipe isolada do mundo exterior, criada somente para trabalhar num único projeto.
Seria o ideal, mas o mundo não funciona deste jeito. Na verdade o que acaba acontecendo é que empresas não possuem pessoas suficientes para tocar todos os projetos, fazendo com que um único desenvolvedor seja responsável por mais de um projeto.
A resposta natural ao problema de possuir uma única equipe e vários projetos é dividir o time. Simples e funcional... mas muitas vezes o tamanho da equipe não permite tal divisão. Então como tratar?

Kelly Water, do AllAboutAgile, dá uma solução interessante em poucos passos:

Trate a equipe como um único elemento
Não divida a equipe, tente reuní-la em torno de um único foco por vez. como fazer isso?
Tenha um Product Owner para cada projeto que a equipe será responsável. (muito importante!)
Determine, baseado em seu orçamento, o percentual de utilização da equipe para cada projeto. ex: 3 projetos: 70% 10% 20% da capacidade da equipe será alocada (leia-se velocidade).
Faça reuniões com todos os Product Owners e esclareça que eles só terão o percentual definido de tarefas para uma Sprint.

Talvez seja necessário aumentar a granularidade dos requisitos de cada Product Backlog, mas não se esqueça: estime apenas no Sprint Planning.

Deixe a cargo da Equipe a divisão do trabalho para os projetos. Lembre-se que agora você trabalha com uma equipe auto-gerenciável.

É isso...

Scrum FAQ em português

Saudações a todos!

Bem, não sei ao certo o porque fiz isso, talvez pela influência do livro Wikinomics...
Com a intenção de ampliar a divulgação de Scrum e Desenvolvimento Ágil nas empresas brasileiras, o documento escrito por Howard van Rooijen filiado à empresa Conchango, que transcreve entrevistas feitas com Ken Schwaber respondendo perguntas sobre Scrum, foi traduzido para o português por mim.

Vejam o documento: arquivo

editNote: Link já corrigido

[]s