segunda-feira, dezembro 03, 2007

[Workshop] Planejamento e Estimativas em Projetos Ágeis

PLANEJAMENTO E ESTIMATIVAS EM PROJETOS ÁGEIS

Data: 15 de dezembro
Local: São Paulo/SP
Público alvo: Scrum Masters, Gerentes e líderes de projetos ágeis, membros de times ágeis que precisam estimar suas tarefas, Gerentes de Produto (Product Owners) e qualquer profissional envolvido em projetos ágeis.
Carga Horária: 8 hs.
Investimento: R$ 435,00 (10% de desconto para membros da comunidade Scrum-Brasil)

Obs: Informações de local e procedimento de matrícula serão enviados após sua solicitação de reserva.

Conteúdo:

1. Necessidades para o processo de estimativa;
2. Falando sobre unidades: Size, Story Points, Ideal Day e Hours;
3. Quando estimar em horas? Quando estimar em tamanho?
4. Técnicas de estimativa;
5. Planejamento de Releases;
6. Planejamento de Sprints;
7. Técnicas para uma Planning Meeting bem sucedida;
8. Planejando projetos de escopo aberto;
9. Planejando projetos de escopo fechado;

Reservas: E-mail para axmagno (at) gmail (dot) com

Instrutor: Alexandre Magno, CSP

quinta-feira, novembro 22, 2007

London Scrum Gathering - Um breve relato

Na última semana estive em Londres para palestrar na edição de outono do Scrum Gathering, o principal evento de Scrum do mundo. A viagem foi extremamente interessante tanto por aspectos profissionais quanto pessoais, visto que ao visitar Londres consegui realizar um antigo (mas sempre vivo em minha mente) sonho adolescente.

Sobre o evento
O evento foi aberto através de um Keynote do Bruce Radloff da TeleAtlas, mas infelizmente não pude acompanhar visto que a minha palestra era logo na seqüência, e então – além do nervosismo – eu estava ocupado deixando tudo pronto na minha sala de apresentação.
Após um tradicional “tea break” britânico – chegou a hora da verdade! A minha apresentação “Why Scrum intimidates?” tinha como propósito mostrar os porquês da grande resistência sofrida pelas abordagens ágeis (com foco em Scrum) nas empresas ao redor do mundo. Com um forte toque de humor (tradicional em minhas palestras) avaliei “ponto-a-ponto” a forma com que Scrum ameaça a zona de conforto existente hoje nessas empresas, e – a partir destes vícios mapeados - mostrei alguns mecanismos que venho utilizando para quebrar essa resistência. Fiquei satisfeito com o resultado final: consegui passar minha mensagem, fui compreendido bem e mostrei ao mundo que o Brasil já está fazendo muita coisa com Scrum.
Após o almoço, assisti a palestra "Why Scrum Projects Fail?" apresentada por Joseph Pelrine da MetaProg e Jiri Lundak da Löwenfels Partner (Suiça). Foi uma palestra muito legal, que tocou muito no lado humano que Scrum envolve e forneceu grandes e importantes conselhos para as Scrum Retrospectives. Na seqüência, para última palestra do dia escolhi assistir ao Mike Cohn da Mountain Goat (USA) falando sobre o processo de transição para agile, uma palestra também recheada de dicas valiosíssimas.

No dia seguinte perdi novamente o Keynote inicial, agora com o pessoal da F-Secure (como vocês podem perceber eu sofri um pouquinho com o fuso). Neste dia assisti às duas melhores palestras do evento, uma proferida pela Sabine Canditt (CSP da Siemens) - a Sabine havia assistido a minha palestra no dia anterior e ao decorrer do evento trocamos algumas informações bem legais. A palestra dela foi muito interessante, fiquei impressionado em ver como a Siemens vem usando Scrum pra “quase” tudo. Depois disso, sala lotada para assistir “ninguém mais – ninguém menos” que ele: Mr. Ken Schwaber com sua palestra “The Enterprise and Scrum”. A palestra foi ótima, mas um ponto importante pra mim foi ter visto Mr. Schwaber tocar em uma série de pontos e alertas que eu havia falado em minha palestra no dia interior. Pensei “opa...então eu estou realmente certo!” ;)
O Keynote seguinte (da British Telecom) – que foi excelente e divertidíssimo por sinal – era pra ter sido a última apresentação do dia. Mas Ken Schwaber presenteou-nos com uma sessão "extra" de 4 horas(acho que treinamento seria mais apropriado) intitulada “Scrum Update”...MAGNÍFICO! Ser treinado pelo cara que co-criou Scrum foi realmente algo muito importante e que com certeza melhorará a “minha forma” de usar Scrum nas empresas daqui pra frente. Saímos da Dexter House após às 22hs, eu estava realmente muito cansado, mas ainda tinha que parar em algum pub para tomar pelo menos um pint para celebrar o dia. :)

Último dia do evento: Open Space com Rachel Davies da Agile Experience. A sessão iria durar o dia inteiro e eu estava muito cansado mesmo, então acompanhei algumas partes (bem legais por sinal) e após o almoço me despedi dos conhecidos e voltei para o hotel.

Bom, a experiência foi única e importantíssima para a minha carreira. Foi uma honra me ver palestrando no principal evento de Scrum do mundo ao lado “dos caras” e, principalmente, ver que estou fazendo certo, que muito que penso e aplico está “de acordo” com o que os caras das origens do Scrum pensam e aplicam.
Muitos links que coloquei neste post levam aos slides das apresentações, mas infelizmente tenho que frisar que eles não representam nem 15% do que foi visto em cada sessão.

E vamos seguindo a estrada, mas vamos pela de barro e com buracos, porque é por ela que mais iremos aprender e nos divertir! ;)

Obs: Na próxima edição da revista Visão Ágil farei um relato detalhado sobre o evento.

quarta-feira, outubro 17, 2007

[Oportunidade] Scrum Master

A UpLexis, empresa de desenvolvimento de soluções tecnológicas, está em busca de um profissional para atuar como Scrum Master em seus projetos de software. Segue algumas caracetrísticas e necessidades da vaga:

- Ampla experiência em gerência de projetos de software;
- Sólidos conhecimentos sobre práticas ágeis, principalmente Scrum/XP;
- Perfil de liderança: habilidades comunicativas e motivacionais;
- Experiência em análise de sistemas e mapeamento de processos;
- Forte background técnico em desenvolvimento de softwares;
- Plataformas Linux e ambientes Java, PHP, Perl e C;

O profissional atuará como Scrum Master (gerente de projetos) de um time inicialmente composto por 12 membros com alto nível tecnológico e, nos primeiros meses, será auxiliado através de coaching com o Alexandre Magno, CSP.

A UpLexis é uma empresa de desenvolvimento de soluções tecnológicas que habilitam a eficiente recuperação, organização e descoberta de informações de alto impacto nos processos de negócios corporativos.
Suas ferramentas são estruturadas através de métodos computacionais relacionados à aquisição, organização e acesso à informação. Seu domínio de atuação abrange o processamento computacional de textos em linguagem natural, através de conhecimento fundamentado em áreas interdisciplinares como linguística, estatística e inteligência artificial.

Interessados favor enviar e-mail para jmarcelo (at) uplexis (dot) com (dot) br com cópia para axmagno (at) gmail (dot) com

quinta-feira, outubro 04, 2007

As armadilhas do Scrum

No dia 22 de setembro, os membros da comunidade Scrum-Brasil se reuniram na FIT (Faculdade Impacta de Tecnologia) para a primeira reunião do grupo. Na ocasião eu tive a oportunidade de proferir a palestra "As armadilhas do Scrum", que teve como objetivo apresentar alguns alertas para os cuidados que devemos tomar no processo de promoção, "implantação" e acompanhamento do Scrum dentro das equipes e empresas.

Você pode fazer o download da palestra clicando AQUI!

quinta-feira, setembro 20, 2007

Fall Scrum Gathering - Londres

No dia 14 de novemdro, estarei palestrando em Londres no evento Fall Scrum Gathering. A palestra selecionada para o evento tem o título "Why Scrum Intimidates?" onde procurarei apresentar aos participantes do evento os principais pontos que podem gerar uma certa rejeição do Scrum nas empresas, e como neutralizá-los.
Para mim é um orgulho ter tido uma palestra selecionada para um evento de tal porte, e palestrar ao lado de grandes nomes do "Mundo Scrum" como Ken Schwaber e Mike Cohn.

Mais informações sobre o evento: http://www.scrumgathering.org

sexta-feira, setembro 14, 2007

Scrum e XP...é tudo a mesma coisa?

Primeiramente, por saber que se trata de um post polêmico, gostaria de deixar claro que o seu conteúdo expressa simplesmente a minha opinião sobre o assunto.

Em muitos clientes, palestras e treinamentos, eu sou frequentemente questionado sobre a semelhança de algumas práticas do Scrum com práticas da Extreme Programming. A semelhança existe realmente...mas seriam apenas semelhanças?

Certa vez eu li em algum lugar que, se você utiliza XP, consequentemente já está usando Scrum, o que discordo em gênero, número e grau. Há diferenças, principalmente no comportamento que deve ser exercido em determinadas atividades e práticas.
Para ser claro, para mim, Extreme Programming é engenharia e ponto final! Opa...já estou ouvindo os gritos: Mas e o jogo do planejamento? E a reunião em pé? Isso não é é gerenciamento? Então...XP é gerenciamento e engenharia, certo?
Deixem eu me explicar. Para início de conversa, a maioria das práticas de gerenciamento do XP vieram de onde? Pois é...do Scrum! Então, podemos dizer que muito (quase tudo) que XP faz relativo ao gerenciamento do projeto na verdade é Scrum...só que, por estas técnicas estarem sendo entregues juntamente com uma série de técnicas de engenharia, elas acabam perdendo o brilho.

Eu gosto bastante de algumas práticas de engenharia do XP, principalmente TDD, mas acho que as práticas de gerenciamento que XP "trouxe" do Scrum são melhor abordadas na sua "versão original". Gosto mais do formato de reuniões diárias do Scrum, bem como do planejamento, estimativas, reviews e retrospectivas. Tá, sei que são muito parecidas, é verdade! Mas acho que justamente o foco que Scrum dá nessas atividades faz com que os resultados obtidos por elas sejam mais interessantes. Talvez o motivo disto seja originado na diferença de foco entre os papéis: Coach (XP) e ScrumMaster (Scrum). Nas equipes que conheci (XP ou Scrum) eu sempre vi um papel muito mais atuante do ScrumMaster que do Coach em XP (quanto às tarefas de gerenciamento). Talvez pela importância que Scrum dá a esse papel, sempre os encontrei com mais foco em servir ao time.

Recentemente, ministrando um treinamento de Scrum no Paraná, tive contato com uma equipe que trabalhava há mais de 1 ano com XP, eles inclusive haviam recebido treinamento e coaching em Extreme Programming durante o projeto. Ao me abordarem, percebi que tudo que eles me falavam que "ainda precisava melhorar bastante" nos seus projetos estava diretamente relacionado ao gerenciamento. Confesso que vi poucas equipes no Brasil praticar um TDD e uma pair-programming tão bem quanto eles, o que elimina a possibilidade de faltar-lhes habilidade em XP...mas o planejamento, as retrospectivas, estavam deixando muito a desejar.
Após o treinamento, eles me revelaram que perceberam a necessidade de ter alguém com as características de um ScrumMaster em seu time, e de "deixar" que Scrum cuidasse das práticas ligadas ao gerenciamento. Bem, pode ser apenas um caso, uma empresa (eu tenho certeza que não é)...mas dias atrás recebi um e-mail de um dos diretores de lá me informando que a parte de gerenciamento se tornou mais eficaz após as mudanças adotadas.

Eu particularmente gosto de separar as coisas, vejo que engenharia e gerenciamento de projetos tem muitos interesses em comum, mas por outro lado possuem necessidades bem diferentes (por mais que uma sempre complemente a outra). Não foram poucas as equipes em que, primeiro tive que organizar a parte gerencial e depois a engenharia (ou inverso), ou mesmo lugares que gostariam de manter sua metodologia caseira de engenharia, mas queriam adotar algo para melhorar o gerenciamento de projetos.

Portando pergunto, qual o problema em se dizer: uso XP para engenharia e Scrum para o gerenciamento? Afinal as práticas de gerenciamento de XP já sabemos de onde vieram. Ok...alguém deve dizer, porque em XP precisamos customizar "sensivelmente" algumas práticas para que nos atendessem melhor. Hmmmm...se for assim lançarei aqui a ADPM(aX-Driven Programming & Management), vocês vão se surprender com o que proponho:

# Twins-programming: É uma prática de engenharia semelhante (mas não é) pair-programming;
# Integration Now!: É uma prática de engenharia semelhante (mas não é) integração contínua;
# Wake-up meetings: Não se enganem, é apenas parecido com daily meetings, mas tem detalhes importantes da minha metodologia;
# Planning Party: Também é apenas parecido com a reunião de planejamento, mas há diferenças...eu juro!
# Planning Truco: É uma técnica de estimativas muito interessante.

Mas acreditem...isto não é XP, nem Scrum...é ADPM!

Brincadeiras à parte, na minha opinião isso atrapalha o entendimento dos clientes e talvez principalmente dos que estão iniciando os estudos em agile. Afinal, não parece ser fácil responder à pergunta: qual a diferença entre Scrum Daily Meeting, Standup Meeting, Morning Call e Wake-up meetings?

Finalizando então este post, minha mensagem é: pense em algo para o gerenciamento de seus projetos (Scrum ou não), e em algo para a engenharia deles (XP ou não)...depois pense em como estas duas escolhas podem trabalhar em conjunto, e vá em frente!

Veja um pouco sobre XP @ Scrum clicando AQUI! ou AQUI!

sexta-feira, agosto 10, 2007

Scrum na Caelum : Primeira turma

Na semana de 30 de julho a 03 de agosto ministrei o treinamento "Gerenciamento de Projetos de Software com Scrum" para a primeira turma na Caelum. O resultado final superou as minhas expectativas, e um grande fator para isto foi o espírito de time que foi criado nos 05 dias que passamos juntos aprendendo Scrum. Também fiquei bastante satisfeito por ter conseguindo atingir um dos meus principais objetivos, que era o de conduzir um treinamento de Scrum focado principalmente na prática, colaborando para que todos os membros do time aprendessem com nossos próprios erros. Acho que ficou claro para todos a evolução que cada um teve no decorrer da semana através de uma comparação de resultados alcançados em cada atividade, e o quão cultural são a maioria destes problemas.
Por fim, agradeço a cada um dos alunos pela confiança, colaboração e comprometimento com o treinamento...fico feliz que todos estejam agora prontos para iniciar a "desafiadora tarefa" de implantar Scrum em suas empresas.

Próxima turma: 24 a 28 de setembro
Informações sobre o treinamento: Caelum


Mais fotos do treinamento AQUI!

segunda-feira, agosto 06, 2007

The Daily Meeting Trap

Fico feliz em anunciar que o artigo "Scrum e as armadilhas das reuniões diárias" foi publicado sob o título "The Daily Meeting Trap" pela Scrum Alliance:


Leia o artigo clicando AQUI!

quinta-feira, julho 26, 2007

Revista Visão Ágil

Por Manoel Pimentel

É com uma enorme satisfação que comunico a todos que a primeira edição da revista Visão Ágil, já está disponível, acessem o site http://www.visaoagil.com, faça seu cadastro em nosso grupo livre de leitores, e baixa o arquivo PDF, contendo essa edição número 01 desse novo canal de conhecimento sobre processos ágeis.

Revista Visão Ágil : agilidade do início ao fim
Por Alexandre Magno

Uma das primeiras perguntas que nos fizemos ao termos a idéia da Visão Ágil foi: como elaborarmos uma revista de forma ágil? De uma coisa sabíamos, ela não poderia ser elaborada da mesma maneira que as outras revistas, precisávamos de algo mais...ágil! Bom, fico feliz em comunicar a todos que a Revista Visão Ágil é agilidade pura, e utiliza o framework Scrum em todo o seu processo de criação e desenvolvimento. Optamos por fazermos esta edição 01 da revista com artigos já conhecidos de nomes consagrados da comunidade ágil brasileira, seu maior propósito é a divulgação da marca e do processo de elaboração que a mesma adotará a partir da segunda edição...portanto, apertem os cintos e sejam bem vindos à agilidade do início ao fim!

Como funcionará a Visão Ágil?
A Revista Visão Ágil possui um Product Owner, e ele será o elo entre todos vocês stakeholders aos nossos articulistas (desenvolvedores) e ao nosso Scrum Master (Editor). No nosso site haverá uma área para sugestões de artigos e temas, essa área será gerenciada pelo nosso Product Owner que, através das solicitações de vocês, montará o Product Backlog da Visão Ágil, definindo o business value de cada sugestão de artigo de acordo com a quantidade de solicitações para o mesmo tema. Em cada data agendada para o início do Sprint de desenvolvimento da próxima edição da revista, o time realizará o Planning Meeting e, de acordo com o Product Backlog, escolherá o que "entrará" na próxima edição, ou seja, o que tem realmente valor para vocês, nossos leitores. É em cima do Product Backlog selecionado que nosso time trabalhará, buscando os melhores articulistas para cada assunto selecionado e iniciando a Sprint.
Paralelamente a isso nosso Product Owner continuará recebendo as solicitações de vocês e atualizando o Product Backlog para as edições seguintes.

quarta-feira, julho 18, 2007

Improvecast 11: Entrevista com Alexandre Magno na Série Experiências Ágeis

Por Vinícius Teles

Acaba de ser publicado o Improvecast 11 no qual entrevistei Alexandre Magno, Certified ScrumMaster Practitioner. Conversamos bastante sobre experiências na área de desenvolvimento de software, Feature Driven-Development (FDD) e Scrum.

Esses foram alguns dos assuntos tratados no podcast:

- Experiências de um projeto mal-sucedido usando RUP.
- Experiências com Feature-Driven Development (FDD).
- O que é FDD?
- Origens do FDD.
- Práticas do FDD.
- Semelhanças e diferenças entre XP e FDD.
- Experiências com Scrum.
- Resultados observados na aplicação de abordagens ágeis de desenvolvimento.
- A dinâmica chamada "Teatro Ágil".
- Comentários sobre o artigo "Scrum e as armadilhas das reuniões diárias".
- O conceito de "pigs and chickens".
- O que é um Certified ScrumMaster Practitioner?
- Quais as práticas do FDD?
- Curso de Scrum na Caelum.
- Diferenças entre o curso de Scrum da Caelum e o treinamento de Certified Scrum Master?
- Grupo de discussão Scrum Brasil.

Alexandre irá ministrar um Treinamento de Gerenciamento de Projetos com Scrum entre os dias 30 de julho e 3 de agosto de 2007. O treinamento, que será conduzido em parceria com a Caelum, será uma excelente oportunidade de aprender mais sobre planejamento e gerencialmento de projetos ágeis, usando Scrum e outras abordagens ágeis.

Ouça ou Baixe a entrevista.

quarta-feira, junho 20, 2007

Scrum na Caelum

NOVA DATA: 30/07 a 03/08

Em parceria com a Caelum, estarei ministrando o treinamento Gerenciamento de Projetosde Sofware com Scrum no período de 30/07 a 03/08 em São Paulo. O prinipal propósito deste treinamento, é o de preparar profissionais para darem início às experiências com Scrum em seus projetos de software. Utilizando uma didática focada no mundo real - e adequada à cultura das empresas nacionais - e práticas consagradas para o ensino de abordagens ágeis, o treinamento aborda desde recursos introdutórios do Scrum até a sua integração com outras práticas do mundo do gerenciamento de projetos.
A Parte I do treinamento engloba os conceitos necessários para um bom entendimento do porque da utilização de abordagens ágeis e faz um apanhado geral de todas as práticas do Scrum. Esta parte do treinamento é finalizada com o consagrado Scrum 59 Game, onde os participantes do treinamento terão a oportunidade de aplicar as práticas do Scrum em um inusitado projeto.
A Parte II apresenta um estudo de caso do início ao fim de um projeto de software, dando oportunidade aos participantes do treinamento de interagirem com o projeto, tentando assim aplicar seus conhecimentos de Scrum. O instrutor atua aqui como um facilitador, para que em cada nova parte do projeto o debate entre os envolvidos seja transformado em conhecimento para todo o grupo.
Na Parte III, o treinamento é finalizado apresentando a forma com que o Scrum se relaciona com outras metodologias, práticas e certificações do mercado, tais como: UP, XP, FDD, CMMI, PMBok e Corrente Crítica.

Maiores informações e inscrições: http://www.caelum.com.br/

terça-feira, junho 05, 2007

Grupo Scrum-Brasil










Criado grupo para os SCRUMgers de plantão. Pigs e chickens são bem vindos! Associe-se e venha saber mais sobre as maravilhas do Scrum:
scrum-brasil@yahoogrupos.com.br

Teatro ágil

[postagem de 05/10/06 no grupo agile-brasil]

Bom amigos, vou citar a seguir uma experiência que realizei recentemente e que - para o meu objetivo - foi extremamente satisfatória. Pode parecer "loucura" para alguns, mas não podemos esquecer que "tornar o trabalho divertido" é uma das principais práticas para termos equipes ágeis.
Eu procuro sempre, antes de iniciar um projeto e propor metodologias, processos, etc., realizar o que eu chamo de "acompanhamento" junto ao cliente...o que é isso? Eu passo, digamos, duas semanas a um mês acompanhando o dia-a-dia do cliente, as práticas atuais, os vícios, a cultura da empresa, etc. Após isso normalmente eu realizo uma espécie de kick-off sugerindo o que "a meu ver" se encaixa para a melhoria dos processos de desenvolvimento de software da empresa. Pois bem, isso normalmente funciona, mas sempre achei que faltava um "algo mais"...então recentemente resolvi experimentar algo...que foi bem mais ágil e divertido.
Após o tal acompanhamento resolvi "mudar de profissão" e escrevi um "roteiro" de uma estória que inícia com os problemas comuns do desenvolvimento de software e tem um final feliz com a implantação de processos ágeis. Com isso em mãos convidei alguns colaboradores do cliente (os mais e menos envolvidos) e montamos uma espécie de "teatro" contando a estória de uma empresa fictícia que passa por todos os problemas até chegar à implantação de atitudes e de uma abordagem ágil. Como disse - pode parecer loucura - mas o resultado foi impressionante, pois o cliente durante a apresentação "se viu" no "palco", viu seus erros, identificou soluções para esses erros (como a mulher que assite novela e se identifica com um personagem, e depois tira aquilo como lição para querer mudar). Quando digo o cliente, digo "todos os envolvidos", a "platéia" presente.
Penso que a agilidade tem que ser aplicada desde o início...desde a forma com que você aborda o cliente, e, novas técnicas de facilicação, como a do teatro, podem gerar resultados interessantíssimos.

Alexandre Magno Figueiredo

sexta-feira, abril 27, 2007

Scrum e as armadilhas das reuniões diárias

Uma das principais práticas do Scrum é a reunião diária (Daily Meeting). Essas reuniões se resumem em uma atividade de quinze minutos(pode ser um pouco mais ou menos, mas só um pouco) que deve ser realizada todos os dias. Durante estas reuniões os membros do time do projeto devem responder às seguintes perguntas:
- O que fiz desde a última reunião diária?
- O que farei até a próxima?
- Estou tendo algum impedimento?
Quando realizo apresentações de Scrum, é comum perceber o quão simples esta atividade parece ser para a maioria das pessoas, porém, por traz de uma simples "reuniãozinha", a reunião diária esconde o termômetro do seu projeto...e não é preciso dizer o que pode acontecer quando um termômetro é mal utilizado, certo?

Reunião diária não é "hora do café"
Algumas equipes, no decorrer do projeto, passam a achar que a reunião diária é algo bastante trivial, sem portanto exigir a necessidade de uma formalização com horário e local fixo. A consequência disso é que, com o passar do tempo, reuniões diárias passam a ser realizadas na sala de cafézinho, no "fumódromo" ou até na padaria. Na verdade a equipe passa a substituir o propósito do “Daily Meeting” para "conversas informais de quinze minutos sobre o projeto". As reuniões diárias devem sim ser realizadas no mesmo local e horário (pelo menos enquanto durar o sprint corrente). Isso é importante!
Uma sugestão de locais ideais para a realização das reuniões seriam: salas de reunião ou de treinamento, ou em algum local com espaço suficiente para acomodar toda a equipe. A sala do chefe é uma péssima opção.
Quanto ao horário, li em muitos artigos e/ou livros que o horário da manhã é o ideal para as reuniões diárias do Scrum, o que faz até sentindo mas, ná prática, eu realmente não vi exatamente com estes olhos. Trabalhei com reuniões no início do dia e ao final dele, e em ambos tive prós e contras. Pela manhã todos os participantes estão descansados e prontos para um novo dia de trabalho, isso é bom! Mas pela manhã sempre(e sempre mesmo) tem alguém atrasado(trânsito, chuva, filhos, etc.), ou seja, em pouquíssimas vezes você consegue realizar a reunião com toda a equipe, e isso é muito ruim! No fim do dia estão todos um pouco(ou muito) cansados, o que diminui a empolgação durante as reuniões, isso é ruim! Em compensação, é bem mais comum você ter toda a equipe presente, e isso é bom! Então, na minha opinião, analise o cenário cultural envolvido(empresa, projeto e equipe) e escolha uma das duas opções.

Reunião diária não é "conversa sobre futebol"
Se você pretende abrir as reuniões diárias para participação de pessoas apenas envolvidas com o projeto(chickens), deixe bem claro ao fazer o convite que o mesmo dá apenas direito a participação como "ouvinte". Apenas as pessoas que estejam realmente comprometidas com o projeto(pigs) devem falar durante a reunião diária. Deixar "chickens" falarem durante a reunião é permitir que pessoas que não estão tendo um acompanhamento dia-a-dia do projeto opinem sobre o seu andamento. Isto provavelmente causará um mal-estar entre "pigs" e “chickens” e, pior ainda, fará com que os quinze minutos acabem antes que você perceba.

Reunião diária não é "conversa sobre a relação"
Muitas equipes tem confundido os quinze minutos da reunião diária com momentos de desabafo e resolução de problemas. Muitas vezes já tive que interromper algum programador quando este falava sobre os impedimentos que estava encontrado: “Estou com um problema com a framework XYZ, pois lá tem a classe Zummble que preciso instanciar...mas não consigo fazer isso devido a esta classe herdar da JJJ que possui a implementação da interface U. Se eu fizer a instância direta cairei em um problema de redeclaração de método, blá, blá, blá”. Bem, este simples parágrafo geraria debates técnicos que, com certeza, ultrapassariam os quinze minutos da reunião. Qual seria a forma ideal de reportar este impedimento na reunião diária? Algo tipo: “Estou tendo dificuldades com a framework XYZ e creio que eu esteja precisando de um suporte/ajuda com isso para poder ter um ritmo mais adequado". Ponto final! Com isso, após a reunião, é papel do Scrum Master providenciar uma solução para o problema do programador, seja convocando uma reunião técnica, solicitando suporte junto ao fabricante, organizando uma programação em par com alguém mais experiente na framework...enfim.
Obviamente, você não pode sair cortando e proibindo todos os assuntos que emerjam na reunião e não estejam ligados às três perguntas, até porque é natural que esses outros assuntos apareçam. Eu particularmente costumo usar a estratégia do Rat Hole da FDD durante as reuniões diárias. O Rat Hole nada mais é que um papel de flip-chart ou mesmo um espaço em um quadro branco, que receberá entradas toda vez que algum assunto pertinente, mas que não deveria ser aprofundado durante esta reunião, emergir . Após a finalização do meeting, o Scrum Master define quando e de que forma tais assuntos serão discutidos.

Reunião diária não é um “julgamento”
Este talvez seja o erro mais freqüente nas reuniões diárias. Os times, principalmente aqueles compostos por membros que não estão habituados a fazer parte de equipes auto-gerenciadas, insistem em usar os quinze minutos da reunião para reportar-se AO Scrum Master, e na maioria das vezes se justificando por algum atraso ou problema do gênero. A reunião diária foi criada principalmente para o time, e não para o Scrum Master. E é AO time que cada membro deve se reportar. A reunião diária é o que nos ajuda a termos sempre uma visão atualizada do seguinte: de onde viemos? onde estamos? para onde estamos indo? E essa talvez seja a sua grande valia! Se você usar esses preciosos quinze minutos diários para penalizar membros da equipe por atraso, ouvir justificativas, dar lição de moral ou coisas do gênero, você não conseguirá utilizar o termômetro.
Infelizmente os times são os que mais demoram para entender isso. Se você, como Scrum Master, não conseguir avaliar se seu time está capitando bem a finalidade das reuniões diárias, experimente durante um dia não estar presente na empresa no horário da reunião – não avisando nada antecipadamente. Se ao retornar eles lhe informarem que não realizaram a reunião, afinal você não estava presente...você tem problemas! Eles realmente ainda não entenderam que a reunião diária é feita para eles.

Portanto entenda - e faça o time entender - que as reuniões diárias:
- Nos ajudam a analisar nossa velocidade/ritmo;
- Fazem com que todo o time esteja a par do que está acontecendo em todo o projeto;
- Identificam impedimentos;
- Integram diariamente o time;
- E, principalmente, nos fornecem um termômetro sempre atualizado de "Como está o nosso projeto?"

domingo, abril 08, 2007

FDD numa casca de banana

O documento "FDD numa casca de banana" tem como propósito ser um guia de rápido aprendizado para a FDD(Feature-Driven Development). Utilizando uma linguagem simples, ideal para os que pretendem iniciar-se na utilização desta metodologia ágil em seus projetos, o documento é composto de tópicos que abordam desde os conceitos básicos da metodologia, passando pelo seu ciclo de vida e pela execução de um projeto de exemplo utilizando todas as suas práticas.
Espero que o documento seja de utilidade para a comunidade brasileira e que contribua para o crescimento desta fantástica abordagem ágil em nosso país.

Faça o downlod do documento clicando AQUI!

sexta-feira, março 09, 2007

O arco-íris de Feynman

Um dos melhores livros que li nos últimos anos! No tempo do livro, Leonard Mlodinow é um pesquisador de física do Caltech, indeciso quanto ao seu futuro, ao que pesquisar e se dedicar, enfim, ao rumo a ser seguido. Richard Feynman, o grande físico, ganhador do Nobel de 1965, está com os dias contados devido a um incurável câncer. A troca de conhecimento e, principalmente, de sentimento entre este jovem e indeciso estudante e a mente brilhante de Feynman, gerou uma das histórias mais bonitas que li recentemente...sem contar que é uma excelente introdução para a teoria das cordas, uma visão mais recente da teoria do campo unificado de Einstein.

Um dos bons trechos do livro:
"Minha sensação era de que ter um trabalho - qualquer um - no campo da física acadêmica era um privilégio. As pessoas menosprezam a universidade por causa dos salários relativamente baixos. Mas eu estava cansado de ver muitos "adultos" trabalharem horas a fio numa atividade da qual não gostavam só para acumularem coisas das quais eles apenas imaginavam precisar; então, décadas depois, lamentavam todos aqueles anos "desperdiçados". E tinha visto meu pai trabalhando arduamente para pagar as contas no fim do mês. Havia prometido a mim mesmo ter uma vida melhor. Para mim, o maior patrimônio que eu podiaconquistar era a possibilidade de passar meu tempo fazendo algo que gostava."

quinta-feira, fevereiro 22, 2007

Pigs & chickens

O site "Implementing Scrum" traz uma área muito boa de cartoons referentes ao conceito de pigs e chickens utilizado pela principal metodologia ágil de gerenciamento de projetos, o Scrum.
Para introduzí-lo ao assunto, pigs são aqueles indíviduos que estão diretamente comprometidos com o projeto, enquanto chickens possuem apenas um envolvimento. Os cartoons são excelentes (e rápidos) recursos para se ambientar com o assunto.
Em breve, muita coisa de Scrum por aqui.

quarta-feira, janeiro 24, 2007

Imperdível! Workshop de FDD em março, São Paulo!

A Heptagon, do colega Adail Retamal, convida a comunidade ágil para o Workshop de Introdução à FDD, em São Paulo-SP, inicialmente previsto para os dias 16 e 17 de março de 2007 (sexta e sábado).

Não perca esta grande oportunidade de conhecer a que, na minha opinião, é a mais responsável metodologia ágil para o desenvolvimento de projetos de software.

Mais informações: http://www.heptagon.com.br/