jump to navigation

Os desafios em escalar resultados com várias equipes Julho 31, 2008

Posted by Manoel Pimentel in Scrum.
Tags: , , ,
add a comment

Esse post é um complemento ao debate iniciado em nossa comunidade: http://br.groups.yahoo.com/group/visaoagil/message/799 .

 

Olá pessoal, tudo bem?

 

Antes de continuar com a leitura desse texto, lembre que quando falamos  em projetos para várias equipes, temos que analisar  também as seguintes questões:

 

  • De onde surgiu a demanda de ter várias equipes?
  • Foi o projeto atual que exigiu essa situação?
  • Será que essa estrutura já está na empresa há muito tempo devido ao pensamento tradicional e só estamos tentando achar justificativas para mantê-la?
  • Essa estrutura de várias equipes, está contribuíndo para gerar  bons resultados ao negócio de minha empresa?

 

Na verdade essa é uma questão muito delicada, apesar de termos algumas ferramentas como o Scrum of Scrums, que nos ajudará muito na sincronização escalar da comunicação entre os Product Owners, ScrumMasters e entre as Equipes, nosso maior desafio é escalar RESULTADOS através dessa estrutura.

 

 

Acredito também que esse processo é um pouco mais simples quando estamos tratando de equipes que são divididas por produtos diferentes, aí teremos cada equipe, com seu  Product Backlog, com seu Product Owner,  com seu ScrumMaster e com a sua estrutura de Sprints, aí é só uma questão de sincronizar os resultados das  ”meetings” para gerar visibilidade para uma estrutura  organizacional  orientada a PROGRAMA e PORTFÓLIO.

 

Mas o maior desafio que eu vejo, reside quando temos várias equipes trabalhando para o mesmo produto, aí sim temos algumas questões importantes que precisam  de atenção, como por exemplo:

  • Precisamos ter um Product Owner e um ScrumMaster para cada equipe?
  • Como iremos fazer definição de itens técnicos de arquitetura que serão comuns a todas as equipes?
  • Como será feito a priorização desses itens técnicos?
  • Como e onde será feito o compartilhamento de decisões técnicas.
  • Quais são os cuidados para não gerar certa inércia no projeto devido à dependência entre as equipe?

 

Esse cenário é um pouco pior quando estamos em equipes separadas geograficamente, pois temos  alguns  problemas de sincronização das Sprints devido a várias questões com relação fusos-horário diferentes, calendário de feriados regionais e por aí vai. Mas claro que mesmo em equipes com separação geográfica, podemos usar as práticas ágeis, só temos que lembrar que nesse cenário, só não iremos usar algumas práticas  que favorem a comunicação face-a-face, porém a estrutura base de Product  Backlog, Sprint Planning, Sprint Backlog, Daily Meeting, Sprint Review e Sprint Retrospective,  continua sendo factível, se usarmos ferramentas de comunicação via internet como serviços de chats, de documentos compartilhados e de reuniões on-line.

 

Solução Geral: Não exisite uma solução mágica e única para essa questão, como eu falei anteriormente, a técnica Scrum of Scrums, oferece uma estrutura base para guiar as idéias de como podemos vencer esses desafios,  mas a única constante nisso tudo é que: ter equipes em escala é algo que exige uma dose extra de  CORAGEM e HUMILDADE para experimentar técnicas de COMUNICAÇÃO com  SIMPLICIDADE de acordo com cada caso, para garantir um rápido FEEDBACK em todos os níveis do projeto.

 

Referências

É possível encontrar mais detalhes sobre Scrum of Scrums no artigo “Advice on Conducting the Scrum of Scrums Meeting” escrito por Mike Cohn e que  está disponível em:
http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting .

Sobre o autor:

Manoel Pimentel, CSP

Manoel Pimentel, CSP

É Engenheiro de Software, com mais de 15 anos na área de TI, atualmente trabalha com projetos Java pela Rhealeza(SP) e como Coach em metodologias pela Fratech Tecnologia(SP). É Diretor Editorial da Revista Visão Ágil, Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.
Contatos: manoel@visaoagil.com

Entrevista com Manoel Pimentel na TDC 2008 Julho 31, 2008

Posted by Vinícius Manhães Teles in Vídeos.
Tags: , , , , , ,
add a comment

Continuando com as entrevistas que foram gravadas nas TDC 2008, agora é a vez do Manoel Pimentel, da Revista Visão Ágil:

 

 

Link direto para o vídeo.

Resumo do evento TDC 2008 Julho 30, 2008

Posted by Manoel Pimentel in Notícias.
Tags: , ,
2 comments

Olá Amigos,

Nó final de semana passado, mas precisamente nos dias 25 e 26 de Julho, ocorreu na cidade de São Paulo (SP)  o evento TDC 2008 (The Developers Conference), com o objetivo de trazer duas grandes trilhas: uma sobre Java e  outra sobre Agile.

Esse evento foi organizado pela GlobalCode,  que de maneira geral, deu um show em organização e em conteúdo trazido, por isso, deixo aqui meus parabéns e meu obrigado pelo convite como palestrante aos meus amigos Vinícius Senger, Yara Senger e Jorge Diz.

Tivemos também uma oportunidade histórica de fazer um grande encontro com outros grandes nomes da comunidade agile aqui no Brasil, por isso, esse evento teve um gostoso clima de “estar em casa“, pois fizemos muitas coisas legais, muitos bate-papos, muitas entrevistas, algumas muvucas, fizemos também a Macarronada Ágil que virou a FeijoÁgil, enfim foi um momento muito bacana, que nos deus um gás interessante para promover mais encontros como esse aqui no Brasil (em breve  falarei mais sobre  esse assunto  aqui no Blog).

Outro ponto importante foi que o interesse do público sobre agile foi muito grande, pois  além de lotarem todas as palestras sobre o tema, os mesmos foram muito participativos em todas elas, o que ajudou a engrandecer mais ainda o nível das palestras.

No final do último dia, tivemos um grande painel sobre processos, que contou com a presença dos seguintes nomes:  Jorge Diz (Globalcode), Vinicius Teles (ImproveIT), Manoel Pimentel (Visão Agil), André Piza (UOL), Marcos Dorça (Borland), Enio Stein (Paggo) e José Papo  (BRQ),  e nesse painel de debates, como seria o esperado, teve alguns pontos polêmicos entre a famosa questão Agile X CMMi.

Para terminar, outro fato um tanto pitoresco desse evento, foi ver nascer a “veia jornalística” de meu grande amigo Felipe Rodrigues (Fratech), onde o mesmo fez umas entrevistas iradas com os gringos: Reza Rahman(EJB), Burr Sutter (JBoss) e Ed Burns (Sun), que serão publicados em Setembro desse ano, na ocasião do lançamento da InfoQ Brasil (Em breve postarei mais detalhes sobre esse nosso trabalho).

Para quem quiser ver algumas fotos sobre o evento, acessem o link do picasa: http://picasaweb.google.com/comunidade.globalcode/TDC2008Resumo

 Muito Obrigado e até a próxima.

 

 

 

 

 

 

Atendendo de forma ágil às janelas de mercado Julho 29, 2008

Posted by Manoel Pimentel in Lean, Pensamentos, Scrum.
Tags: , , , ,
2 comments

Historinha

Imagine que para atender uma nova janela de mercado, você realizou um projeto de 12 meses de trabalho (entre análise, desenvolvimento, testes e documentação) para criar uma solução pioneira em aplicação web para esse novo nicho, só que ao lançá-lo ao mercado, você descobre que há cerca 11 meses atrás, outra empresa do mesmo porte que a sua, já havia lançado um produto web para esse mesmo nicho e que já têm um enorme marketing-share face ao potencial de consumo desse mercado consumidor, portanto seu produto será apenas mais um no mercado e perderá todo o impacto do pioneirismo e inovação.

Mas não satisfeito com o fato de que seu investimento foi inútil, você resolve se aprofundar em saber como essa outra empresa conseguiu fazer um lançamento tão rápido. Mas para sua maior tristeza, você descobre que ao contrário do que pensou, essa empresa não começou o projeto antes que a sua, pois esse mercado se revelou ao mesmo tempo para todos, ou seja, ela também começou a desenvolver o seu produto acerca 12 meses atrás.

Só que nessa sua incursão “lerda” de inteligência competitiva, você descobre que na verdade o segredo dessa empresa, foi ter lançado pequenas partes usáveis desse software ao mercado, dessa forma, ela conseguiu captar mais cedo o feedback que o clientes lhe forneciam e adaptar o produto de forma que as próximas liberações mensais, estivessem mais acuradas ao desejo de seu mercado consumidor.

Mas como você é um empreendedor valente e que não desiste nunca, você até tentou recuperar alguns clientes que já estavam usando o software dessa outra empresa, porém, você não conseguiu fazer isso, pois os clientes haviam criado uma relação de grande confiança com esse outro fornecedor, não somente pelo pioneirismo em si, mas por sua capacidade em responder rápido às mudanças, ser realista acerca dos custos, prazos e viabilidades técnicas de sua solução.

Então depois de inúmeras tentativas de marketing, várias ações promocionais e muito, mas muito dinheiro jogado fora, você decide descontinuar o seu produto, assumir o prejuízo, fechar seu negócio, culpar a conjuntura econômica e social do país e abrir um restaurante em seu bairro para aproveitar aquela partilha de herança que sua querida sogra fizera antes de morrer.

Moral da História

Tirando o aspecto trágico de usar a herança da sogra e apesar dessa história ser direta por questões didáticas, você acha que esse cenário é algo comum e factível em nosso mercado de software?

Se você respondeu SIM, é que você de alguma forma, já está com um pensamento alinhado aos pilares ágeis de visibilidade, inspeção e adaptação para garantir um feedback mais rápido e eficaz, de forma que “time-to-marketing” da entrega de software de seu processo seja menor, possibilitando com que o ROI (Return Of Investment) de um projeto de software seja maximizado o mais cedo possível, viabilizando uma real vantagem competitiva em seu mercado.

Agora caso você ache que essa historinha NÃO reflete a realidade do mercado, muito cuidado, você pode acabar igual ao empresário que teve que fechar a empresa e montar um restaurante (com dinheiro da sogra).

Sobre o autor:

Manoel Pimentel, CSP

Manoel Pimentel, CSP

É Engenheiro de Software, com mais de 15 anos na área de TI, atualmente trabalha com projetos Java pela Rhealeza(SP) e como Coach em metodologias pela Fratech Tecnologia(SP). É Diretor Editorial da Revista Visão Ágil, Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.
Contatos: manoel@visaoagil.com

Desconforto Julho 27, 2008

Posted by Francisco Trindade in Pensamentos.
1 comment so far

Esse post é mais ou menos uma continuação do último, juntando com algumas idéias que me vieram a cabeça ao participar de uma discussão sobre rastreabilidade em software em processos ágeis.

Recapitulando, o post passado sobre estimativas surgiu da dúvida que algumas pessoas colocaram sobre como estimar projetos de escopo fechado, e se técnicas como Pontos de Função ou Casos de Uso poderiam ser utilizadas para isso. Enquanto isso, a discussão sobre rastreabilidade ocorreu a partir da pergunta de como gerar matrizes de rastreabilidade partir de User Stories em métodos ágeis.

Antes que vcs se perguntem o que estimativas tem a ver com rastreabilidade, eu ja posso responder: nada, pelo menos nesse post.

Mas o ponto comum que eu achei interessante em ambas as discussões é a necessidade de que muitas pessoas (e equipes) têm de possuir ferramentas/técnicas que gerem resultados extremamente precisos, como estimativas de 1924.5 horas para um projeto, ou quais linhas de código serão afetadas se eu por acaso mudar essa linha aqui, no caso da rastreabilidade.

E eu acho que essa é a maior dificuldade que equipes adotando métodos ágeis encontram. Elas ainda querem ter as mesmas ferramentas fornecidas pelas metodologias tradicionais, que produzem resultados precisamente errados, levando a uma falsa sensação de conforto.

E isso remete ao fato de que muitas equipes tentam adotar processos ágeis através de técnicas, sem realmente entender os princípios que estão por trás disso.

Não se aceita que equipes ágeis não saibam exatamente quando o software será entregue, mas sim que em qualquer dia durante o projeto, tenham software funcionando e pronto para ser entregue, ou que só tenham uma idéia do impacto gerado por mudanças, mas ao mesmo tempo tenham testes que mostrem exatamente quais funcionalidades foram comprometidas após a mesmo.

E principalmente, não se aceita que existam dúvidas em qualquer aspecto de um projeto, quando na verdade desenvolvimento de software é quase tanto formado de dúvidas como é de certezas.

Então, quando vejo dúvidas desse tipo, acho que o melhor pensamento a se ter é relaxar um pouco e deixar as coisas fluírem, e depois se perguntar pq se quer saber todas essas informações, e se realmente elas agregam algum valor ao que sua equipe está tentando fazer.

[]’s

Francisco

Sobre o autor:

Frank Trindade

Francisco Trindade

Francisco Trindade é desenvolvedor e consultor da ThoughtWorks UK. Engenheiro de Computação e mestre em Engenharia de Software pela UFRGS, Francisco possui 5 anos de experiencia em desenvolvimento de software, alem de ser um entusiasta e praticante de metodologias ágeis.
http://blog.franktrindade.com

Entrevista com Cicero Torteli, fundador da Paggo Julho 27, 2008

Posted by Vinícius Manhães Teles in Experiências, Vídeos.
Tags: , , , , , ,
add a comment

Acabo de chegar de São Paulo, onde participei da TDC 2008. O evento foi muito legal. Tive a oportunidade de rever vários amigos, entre eles o Cicero Torteli, fundador da Paggo, que falou sobre a adoção do Extreme Programming por lá:

Ainda sobre a Paggo, escute também o podcast que gravamos há algum tempo com Maurício Hermógenes, Diretor de Tecnologia da Paggo.

Há várias outras entrevistas que foram gravadas na TDC 2008, com vários colegas aqui do blog Visão Ágil, tais como o Manoel, o Papo, Ricardo, Felipe, Rodrigo e meu amigão, Juan Bernabó. Em breve, estarão disponíveis aqui também.

Visão Ágil no evento TDC 2008 – The Developers Conference Julho 23, 2008

Posted by Visão Ágil in Notícias.
add a comment

Será realizado na cidade de São Paulo neste próximo final de semana (dias 25 e 26 de Julho), o evento TDC 2008 – The Developers Conference, que é organizado pela empresa GlobalCode.

Nesse evento além da excelente trilha sobre Java, teremos também uma trilha de palestras bem interessantes sobre metodologias ágeis e engenharia de software, feitas por vários amigos já conhecidos da comunidade agile aqui no Brasil conforme mostra a listagem abaixo:

  • Análise de Requisitos, Estimativas e Métricas
    Marcos Dorça / Borland
  • Estratégias para testes: a metáfora da pirâmide alimentar
    Jorge Diz e Kleber Xavier / Globalcode
  • Scrum
    Juan Bernabó
  • Modelagem Ágil
    Manoel Pimentel / Visão Ágil

  • eXtreme Programming
    Vinícius Manhães Teles / ImproveIT

  • Caso Prático: Java como ferramenta de suporte a um ambiente realmente colaborativo no método Scrum de trabalho
    André Piza / UOL

  • Conheça a iniciativa Jazz da IBM – Pessoas constroem grandes aplicações, não empresas!
    Rodolpho Rugolini / IBM

  • Painel Gestão, metodologias e processos de software: com a teoria, a prática é outra
    Jorge Diz / Globalcode, Vinicius Teles / ImproveIT, Manoel Pimentel / Visão Ágil, André Piza / UOL, Adriano Romero / Borland, Enio Stein / Paggo, José Papo / BRQ

Para maiores informações sobre esse evento, acesse: http://www.thedevelopersconference.com.br/programacao.html

Vejo vocês lá!

Refactoring em Banco dados no 5° FDD Julho 22, 2008

Posted by Manoel Pimentel in Biblioteca, Notícias.
Tags: , ,
1 comment so far

Nesse sábado passado dia 19/07/2008, ocorreu minha palestra sobre Database Refactoring na quinta edição do evento FDD (Firebird Developers Day), que fora realizado na cidade de Piracicaba-SP.

Vejam que Database Refactoring é uma técnica ágil consiste num método interativo e incremental para aplicar melhorias em banco de dados legados, ou criação de novos bancos dados em um típico projeto de desenvolvimento de software.

Para quem desejar maiores informações sobre o evento, veja o report do mesmo em: http://www.firebirddevelopersday.com.br/fdd/reports/5FDD/index.html

Quem desejar acessar os slides que usei na palestra, basta baixar o arquivo pela URL: http://visaoagil.files.wordpress.com/2008/07/database_refactoring.pdf

Quero aproveitar e parabenizar o meu amigo Calos Cantu e sua equipe pela organização de mais esse excelente evento para comunidade e também, reforçar os votos de que o sucesso continue nas próximas edições.

Sobre o autor:

Manoel Pimentel, CSP

Manoel Pimentel, CSP

É Engenheiro de Software, com mais de 15 anos na área de TI, atualmente trabalha com projetos Java pela Rhealeza(SP) e como Coach em metodologias pela Fratech Tecnologia(SP). É Diretor Editorial da Revista Visão Ágil, Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.
Contatos: manoel@visaoagil.com

Estimar é Desperdício! Julho 19, 2008

Posted by Francisco Trindade in Lean, Pensamentos.
Tags: , ,
14 comments

Para começar minha participação nesse blog, resolvi escrever sobre algumas ideias que venho tendo a algum tempo, e que recentemente vieram à tona por causa de uma discussão na lista Scrum Brasil.

Contextualizando, a discussão começou com uma duvida sobre como estimar projetos de escopo fechado com Scrum, e passou por técnicas como Pontos por Caso de Uso (UCP), Pontos de Função (PF), Story Points, entre outras.

A idéia desse post não é discutir técnicas de estimativas (o que fica para outra hora, se alguem estiver interessado), mas sim apontar para um fato que nem todo mundo se lembra na hora de estimar:

Estimativa é Desperdício!

Quando digo isso não quero dizer que não se deve estimar, ou que estimativas não servem para nada. O que quero deixar claro é que quando estamos usando (perdendo) tempo para estimar, não estamos adicionando nenhum valor para o produto que está sendo entregue (o software), mas sim realizando um processo de apoio, que deve ser considerado desperdício.

É claro que na maioria dos casos, estimar é um desperdício necessário, mas devemos ter em mente para que estamos criando estimativas, de forma a otimizar ao máximo o processo.

O Chris Leishman escreveu um post interessante sobre isso, onde ele especifica as três razões (3 Ps) para estimar. Resumidamente:

  • Prediction: para estabelecer o escopo e tamanho do projeto
  • Prioritisation: para que o cliente possa priorizar as estorias que devem ser executadas
  • Performance: para medir o desempenho da equipe

Entao, quando penso sobre estimativas, gosto de pensar para que essas estimativas vão servir, e tentar descobrir como atingir esse objetivo com o menor esforço possível, para poder dedicar mais tempo ao que realmente importa, que é desenvolver software.

Ps: Vale a pena comentar que não vejo nenhum caso onde o tempo gasto com análises como UCP ou PF é justificável :-)

Sobre o autor:

Frank Trindade

Francisco Trindade

Francisco Trindade é desenvolvedor e consultor da ThoughtWorks UK. Engenheiro de Computação e mestre em Engenharia de Software pela UFRGS, Francisco possui 5 anos de experiencia em desenvolvimento de software, alem de ser um entusiasta e praticante de metodologias ágeis.
http://blog.franktrindade.com

Marketing Ágil – Serviços vs Produtos Julho 18, 2008

Posted by Felipe Rodrigues in Pensamentos.
3 comments

Nesta semana estive lendo sobre marketing de serviços e acredito ter aprendido algumas lições importantes que podem ser trazidas para a questão dos processos ágeis. Afinal de contas, o que é o desenvolvimento de software senão um serviço?

Atualmente estamos vivendo a economia de serviços, que nada mais é do que o fim da diferença entre produtos e serviços. Cada vez mais empresas fortemente baseadas em produtos estão acrescentando serviços para agregar valor aos seus produtos. Ter um bom produto hoje em dia não é suficiente. É preciso mais do que isso pra agradar ao cliente. É preciso ter a habilidade de deixar o cliente confortável no processo.

(mais…)

Os doze passos para desenvolver software altamente eficaz Julho 18, 2008

Posted by Jose Papo in Pensamentos.
6 comments

Lendo o livro Dreaming in Code, encontrei uma referência muito interessante para o chamado Joel Test.

Joel Spolsky, um grande desenvolvedor de software. Ex-Microsoft e que possui agora uma companhia que produz uma inovadora ferramenta de gestão de incidências chamada FogBugz.

Ele fez uma lista com 12 passos para medir se um time é bom ou não. O time ganha um ponto para cada passo que possui. 12 é um score perfeito, 11 é tolerável. 10 ou menos e você tem problemas. Segundo ele, que também é um prolífico autor e pesquisador na área de desenvolvimento de software, a verdade é que a maioria das organizações de software possui um score de 2 ou 3!

Aí vão os pontos essenciais:

1. Você usa controle de versões?

2. Você pode criar um build e sua documentação em somente um passo?

3. Você faz builds diários?

4. Você tem uma ferramenta de gestão de defeitos e incidências?

5. Você corrige defeitos antes de escrever código novo?

6. Você tem um cronograma e o mantém continuamente atualizado?

7. Você tem uma especificação?

8. Os programadores tem condições de trabalho tranqüilas?

9. Você usa as melhores ferramentas que o dinheiro pode comprar?

10. Você tem testadores?

11. Novos candidatos escrevem código durante a entrevista?

12. Você faz testes de usabilidade?

Sobre o autor:

José Papo
José Papo

Sou engenheiro de software e mestre em engenharia da computação pelo IPT. Professor de pós-graduação na Universidade São Judas Tadeu, na FIAP, no SENAC e na FAGOC. Sou IBM Certified Solution Designer Rational Unified Process V7.0, IBM Certified Specialist for Requirements Management w/Use Cases, IBM Certified Solution Designer – Object Oriented Analysis and Design vUML 2, IBM Rational Solution Sales Professional, Certified Scrum Master, ITIL Foundation Certified Professional e OMG UML 2.0 Certified Professional. Sou um historiador e filósofo diletante… entre outras coisas

Resistência à Mudanças Julho 11, 2008

Posted by Ricardo Almeida in Pensamentos, Scrum.
add a comment

As metodologias ágeis enfrentam muitas resistências no mercado. Muitas vezes a resistência está em nós mesmos!

Com certeza essa metodologia é um quebra de paradigma. E para entender bem um novo paradigma as vezes é preciso que esvaziemos alguns conceitos de nossa cabeça para poder absorver outros. Muitas empresas ainda apresentarão resistências à esses frameworks de processos ágeis por causa de alguns pontos. Vou citar alguns:

(mais…)

Scrum Overview Julho 8, 2008

Posted by Fábio Aguiar in Scrum.
2 comments
Recentemente escrevi meu artigo de conclusão de curso de sistemas de informação sobre gerenciar de forma ágil uma implantação de sistemas ERP com Scrum. Com isto resolvi postar um resumo sobre Scrum para aqueles que ainda não o conhecem.

 

Figura 01

Figura 01

1. Scrum
Scrum é um framework com conjunto de práticas objetivas, papéis bem definidos e totalmente adaptáveis, seu ciclo de vida se resume em interações e funcionalidades incrementais, é um método ágil voltado para gerenciamento de projetos. Com isso, permite um melhor acompanhamento do que está acontecendo durante o projeto, facilitando o ajuste durante o projeto e fazendo com que possamos alcançar os objetivos do projeto de forma ágil. Ou seja, Scrum não diz exatamente o que fazer, não irá resolver todos os problemas, mas com certeza os problemas serão mais facilmente identificados.

2. Ciclo do processo Scrum
O Scrum é baseado em interações bem definidas, com duração de uma a quatro semanas, também chamados de Sprint. Antes de cada Sprint é realizado todo planejamento inicial do objetivo que o cliente almeja. A partir desse momento é criado o Product Backlog, baseado na visão de negócio do cliente, com todos os requisitos a serem implementados. Depois de preparado todo Product Backlog, é realizada a primeira reunião de planejamento do Sprint, onde são selecionados os itens pelo Product Owner e o Scrum Master a serem desenvolvidos que agregarão mais valor ao negócio do cliente naquele momento e depois colocado na ordem de maior prioridade, em seguida realizamos a segunda reunião de planejamento do Sprint, onde a própria equipe estima o esforço das tarefas, faz a divisão das tarefas entre os diferentes membros e compromete-se a concluir as tarefas no final da interação e define de quanto tempo vai ser a Sprint. A partir desse momento é criado o Sprint Backlog que são as tarefas selecionadas pela equipe para ser executada na Sprint.
A próxima etapa é a execução do Sprint com base nos itens do Sprint Backlog, durante a execução as tarefas são acompanhadas por reuniões diárias que não podem passar 15 minutos e a equipe deve responder três perguntas diante dos envolvidos: O que você desenvolveu até o momento? O que você irá desenvolver? Quais impedimentos você está tendo? Com base nessas perguntas o Scrum Master consegue ter uma visão de como está o andamento do projeto, conhecendo os impedimentos que estão acontecendo.
No final da Sprint é realizada uma reunião de Revisão da Sprint, com o objetivo, de mostrar ao Product Owner e todas as partes interessadas as funcionalidades que foram concluídas. A equipe apresenta os resultados obtidos durante o Sprint e possíveis modificações nos itens do Product Backlog. Logo após é realizado outra reunião de Retrospectiva do Sprint, onde é feito uma “lavagem de roupa suja”, onde os membros da equipe devem responder duas perguntas: O que aconteceu de positivo durante esse Sprint? O que pode ser melhorado para o próximo Sprint?

Figura 02

Figura 02

3. Papéis
No Scrum temos três papéis principais: Product Owner, Scrum Master e a Equipe, abaixo a figura 2 que representa a responsabilidade que esses três papéis têm em relação ao Scrum:

3.1. Product Owner
É o dono do produto, geralmente é representado pelo o cliente. Ele é responsável por definir as características do produto a ser desenvolvido, identifica os requisitos do produto, tira dúvida da equipe quanto ao entendimento dos requisitos. É o único que define a ordem em que esses elementos serão desenvolvidos, de acordo com o valor apresentado pelos clientes e usuários de cada negócio, alimenta o Product Backlog para o planejamento da Sprints. E define as metas e toma decisões relativas Release planejamento. Uma pessoa que desempenha esse papel deve ter as seguintes competências:
- Bom conhecimento de negócio. - Ser capaz de demonstrar uma liderança, respeitado pelos interessados externos (clientes e usuários). – Ser capaz de tomar decisões no momento certo (não muito cedo, nem muito tarde). – Flexível a mudanças. – Boa comunicação com a equipe. – É importante que ele esteja disponível para responder às perguntas da equipe.

3.2. Scrum Master
É responsável pelo andamento do projeto, pela aplicação das práticas do Scrum. Levando para o lado tradicional é o Gerente de Projeto. Durante o desenvolvimento, ele acompanha a equipe no dia a dia, retirando os impedimentos e ajudando a equipe a se auto-gerenciar, buscando melhor resultado da equipe. Para conseguir isso ele executa as seguintes tarefas:
- Tem como objetivo através das reuniões do scrum animar e motivar a equipe.
- Eliminar impedimentos, tendo em consideração os acontecimentos ocorridos em qualquer momento do projeto, a fim de resolvê-los o mais rápido possível, ao mesmo tempo proteger a equipe e priorizar o comprometimento da equipe com o projeto.
- Certifique-se de que a equipe permanece centralizada no projeto com objetivo proposto inicialmente, que é desenvolver os Itens do Backlog e estreitar colaboração com o Product Owner, e permanece produtivo.

3.3. Equipe
É composta por seus membros (desenvolvedores), que é capaz de realizar todas as diversas tarefas para as quais ele tem responsabilidade coletivamente durante cada Sprint. É capaz de determinar o que precisa ser feito para alcançar o sucesso do Sprint, a equipe deve ser capaz de executar as diferentes tarefas para as quais assume responsabilidade coletivamente durante o Planejamento do Sprint. Isto significa que devem ser de amplo conhecimento, tais como análise, projeto, codificação, testes e outras tarefas. A equipe é geralmente feita de 3 a 10 membros.

3.4. Stakeholder
São aqueles que não participam diretamente do projeto, mas podem influenciar no produto a ser desenvolvido, ou seja, não participa do desenvolvimento, mais está interessado no desenvolvimento do produto e pode ter valores que podem influenciar no crescimento do produto.

4. As práticas do Scrum (Conceitos, Artefatos e fases)

4.1. Product Backlog
A partir de uma reunião inicial com todos os envolvidos e interessados do projeto, são levantadas todas as implementações a serem desenvolvidas a partir da necessidade do negócio do cliente, contém uma lista de requisitos a serem desenvolvidos durante o projeto. É visível a todos, e regularmente atualizado. É apresentado na primeira reunião de Planejamento do Sprint, uma vez aprovado, temos os itens necessários para compor o Sprint Backlog.

4.2. Reunião de Planejamento do Sprint
A reunião de planejamento se divide em duas partes:

4.2.1. Primeira Reunião de Planejamento do Sprint
Com duração de no máximo quatro horas, o Product Owner junto com a Equipe discutem os itens do Product Backlog, são selecionadas neste momento as tarefas que tem mais prioridade para o cliente.

4.2.2. Segunda Reunião de Planejamento do Sprint
Com duração de quatro horas, a Equipe define as tarefas necessárias, estima o esforço das tarefas, a própria equipe faz a distribuição das tarefas entre os membros da equipe, o Product Owner deve está presente para esclarecimento de dúvidas e por fim a Equipe compromete-se em concluir as tarefas.

4.3. Sprint Backlog
São as tarefas que foram selecionadas na reunião de planejamento do Sprint pela Equipe junto com o Product Owner e Scrum Master, é o ponto inicial de cada Sprint.

4.4. Sprint
São pequenas séries de interações que podem ter uma duração de uma a quatro semanas, no final da interação a equipe tem que ter alcançado o objetivo inicial do Sprint, onde a equipe está focada em não como fazer, mas sim em vamos fazer. A equipe executa as tarefas compõem o Sprint Backlog. O objetivo final de cada Sprint é ter um produto incremental e funcional para o cliente. É a fase principal do Scrum, pois é nesta hora que ocorre a execução das tarefas, depois de todo o planejamento inicial. É importante que os restantes das Sprint tenham o mesmo tamanho da inicial para que não causem perda de ritmo da Equipe. É imprescindível que no primeiro Sprint alcance o sucesso, pois é um período delicado, pois as partes envolvidas e interessadas estão com expectativa muito grande em cima do resultado (produto incremental).

4.5. Reunião Diária do Sprint
Reuniões diárias que ocorre todos os dias durante a execução do Sprint, com duração em média de 15 minutos. O grande objetivo dessa reunião é que todos os envolvidos tenham conhecimento de como está o andamento do projeto e também fazer com que cada um relate os impedimentos que estão enfrentando ao executarem as suas respectivas tarefas.
O Scrum Master é o responsável pela condução da reunião, é muito importante que todos envolvidos no projeto estão participando principalmente a equipe, basicamente a equipe responde com clareza a três perguntas durante a reunião:
a. O que foi concluído desde a última reunião? (Neste momento o Scrum Master registra as tarefas que foram concluídas e as que ainda estão pendentes).
b. Quais impedimentos estão tendo durante a tarefa? (O Scrum Master registra os impedimentos relados por cada membro da equipe, e após o termino da reunião irá propor solução para os problemas citados).
c. Qual será a próxima tarefa a ser executada? (Neste momento todos ficam sabendo quais tarefas cada membro da equipe está executando).
O Scrum Master tem como objetivo nessa reunião não deixar com que a reunião perca seu foco, basicamente responder as três perguntas, ter uma visão que a equipe não perdeu o objetivo final do Sprint, e gerenciar os impedimentos que vão acontecendo durante a execução da Sprint. O ponto forma desta reunião é responder apenas as perguntas feitas pelo Scrum Master e ponto.

4.6. Produto Incremental
No final de cada Sprint há uma entrega parcial do produto. O principal resultado de um Sprint é a entrega incremental e funcional de um produto, os impedimentos para entrega dessa etapa e os novos requisitos adicionado durante o desenvolvimento deste Sprint.

4.7. Reunião de Revisão da Sprint
Esta reunião é realizada no último dia do Sprint com duração de no máximo 4 horas e de responsabilidade do Scrum Master, a Equipe não de gastar mais de uma hora na preparação da reunião. Neste momento é apresentado o resultado da Sprint que é o produto incremental com suas funcionalidades pela Equipe e o Scrum Master para Product Owner e os envolvidos do projeto (cliente). Analisaram junto se foi alcançado o objetivo inicial do Sprint, e já discutem novas funcionalidades para atualizar os itens do Product Backlog que vão sendo identificada ao final de cada Sprint.

4.8. Reunião de Revisão da Sprint
É realizada logo após a reunião de revisão do Sprint com duração de no máximo 3 horas com a participação da Equipe, Scrum Master, Product Owner e os envolvidos e interessados. Os membros da Equipe devem responder a duas perguntas?
a. O que aconteceu de bom durante o último Sprint?
b. O que pode ser melhorado para o próximo Sprint?
O Scrum Master registra as respostas e prioriza na ordem que deseja discutir as melhorias e tem como papel também facilitar ao time melhores formas de aplicar as práticas do Scrum.
Por ser uma reunião de lavagem de roupa suja, deve se ter cuidado para não levar pontos pessoais, pois podem ser fundamentais para prejudicar a aplicação das práticas do Scrum. Essa reunião é fundamental para o progresso e sucesso do projeto, é fundamental a clareza e objetividade para que os participantes alcancem o sucesso da reunião.

Sobre o Autor

Fábio Aguiar

Fábio Aguiar

Bacharel em Sistemas de Informação (IESAM), com 10 anos de experiência nos processos de desenvolvimento de sistemas e com grande vivência na área de Gestão Empresarial. Atualmente atua como Analista de Desenvolvimento, Customização e Implantação voltado para soluções de ERP, CRM e BI. Possui certificação Borland e também participa da comunidade TaSaFo – divulgando desenvolvimento ágil no Pará.

Sim! Nós agilistas temos escopo… Julho 7, 2008

Posted by Rodrigo Yoshima in Pensamentos.
2 comments

Vocês sabem que as maiores reclamações do mundo em desenvolvimento de software é a famosa correria, os atrasos e a explosão de custos no final dos projetos. Geralmente para nós agilistas o final do projeto é a coisa mais tranquila do mundo. Nós corremos nas primeiras iterações e focamos em entregar valor. Nas últimas iterações é comum sobrar as funcionalidades mais inúteis do mundo a serem desenvolvidas. Quando o cliente percebe isso é comum o projeto acabar algumas iterações antes do que foi planejado.

As maiores razões para esse correria no final do projeto é:

1. A equipe não sabe desenvolver software
2. Gestão Covarde: começar a fazer o software pelas funcionalidades inúteis.
3. Escopo mal definido (assim como as métricas)

O problema com “escopo” em software é achar que desenvolvimento em cascata (waterfall) resolve a questão. Infelizmente quando falamos de escopo dentro de qualquer metodologia de desenvolvimento (FDD, Scrum, RUP como exemplo) sempre focamos que o objetivo do projeto é RESOLVER PROBLEMAS de negócio e não implementar requisitos (isso também é uma coisa que já falei umas 10 vezes aqui).

Parando de ser repetitivo, como nós documentamos esse escopo? Como nós declaramos que problemas o projeto está focado em resolver? Qual é o nível de profundidade desse escopo?

Estabelecer a Visão de um sistema é uma arte. Para este tipo de trabalho é necessário ter um grande conjunto de conhecimentos que na maioria das vezes não é natural para uma pessoa enfiada em linhas de código. Vou colocar uma pequena lista para vocês terem uma idéia. Para estabelecer uma visão é necessário:

- Desenvoltura no ambiente empresarial
- Focar-se no problema e não na solução
- Estabelecer fronteiras claras
- Saber gerenciamento de projetos (definir envolvidos, estabelecer responsabilidades, financiamento)
- Identificar usuários
- Documentar premissas e restrições
- Compreender sobre retorno e risco
- Saber escrever bem
- Ser político (conseguir concordância de todos os envolvidos)

Essas entre outras coisas formam o conjunto de habilidades necessárias para estabelecer uma boa visão. Uma visão que deixe o escopo deslizar dentro do processo iterativo mas que ao mesmo tempo dê um objetivo claro para o propósito do projeto.

Dentre essas habilidades, estabelecer fronteiras é uma das mais importantes. Quando você está desenvolvendo um grande sistema com muitos stakeholders em um ambiente corporativo é comum que a aplicação tenha suporte de outros sistemas ou processos manuais também fora do escopo da automação. Deixar claro que essas responsabilidades externas não são escopo também é um aspecto importantíssimo da visão. Responsabilidades do processo externo e integrações com outros sistemas sempre são importantes para o refinamento do escopo, assim como premissas e restrições na avaliação dessas interfaces.

Sem essa visão clara é comum que ocorram frustrações dentro de um projeto. Uma empresa tem muitos problemas e geralmente o que estamos desenvolvendo não solucionará TODOS os problemas. O escopo delimita exatamente quais problemas serão solucionados.

conjunto problemas - conjunto problemas

O RUP é um dos processos que mais valoriza o estabelecimento dessa visão. O OpenUP também nos fornece um bom material para estudo dessa importante tarefa.

No site da Aspercom nós também temos alguns exemplos:

Visão da HotMotors (Oficina de Tunning)
Visão da KrowCorp (Rede de Hotéis)
Visão da Clínica Anna Suiter (parte integrante do curso on-line grátis, é necessário se cadastrar no site)

Esses documentos tem algumas coisas que geralmente não existem em documentos reais. No caso da KrowCorp (Curso UML & UP) e da Clínica Anna Suiter (Curso Grátis “Entendendo Casos de Uso”) as necessidades dos usuários estão detalhadas demais (estão assim para os objetivos do curso). Já a visão da HotMotors está abrangente demais. O Documento de Visão documenta mais o problema do que a solução. Ele é um resumo executivo do projeto. É o documento que você leva para aquela reunião onde o Sponsor quer cancelar o projeto. A Visão prova a necessidade do software.

É importante ressaltar que dependendo do projeto a Visão pode ser menos ou mais abrangente. Isso depende do que você considera escopo. De qualquer forma nenhuma metodologia iterativa considera que os requisitos do software detalhados são o escopo. O escopo em software sempre é mais abrangente que “requisitos de software detalhados”. Existe diferença entre o problema, as necessidades dos usuários e os requisitos de software.

triangulo - triangulo

Dean Leffingwell e Don Widrig explicam mais sobre essa diferença no livro “Managing Software Requirements“.

Um dos problemas do “Escopo de Alto Nível” é que na maioria das vezes o medo do gerente covarde ou a gestão de projetos tradicional não aceita este tipo de escopo como válido. Para eles “tudo tem que estar explicadinho e assinado” por conta de escopo, prazo e custo serem fixos no processo Waterfall. Isso nos leva ao anti-pattern “Big Requirements Up Front” e a uma dispendiosa e irracional Gerência de Mudancas.

O escopo focado no problema é suficiente para o controle dos objetivos do projeto. Determinados replanejamentos de custo, prazo ou funcionalidades podem ocorrer durante a execução. Isto é previsto no processo iterativo. Porém, se o seu cliente desejar que novos problemas façam parte do escopo aí sim teremos impactos maiores de escopo e um replanejamento geral do projeto pode ser necessário (talvez uma nova concepção/iniciação do projeto ocorra gerando impacto em custo e prazo). Isso sim seria uma mudança de escopo e não a inclusão de um campo a mais numa tela.

Muitos desses assuntos são explorados no nosso curso de Levantamento e Especificação de Requisitos.

Sobre o autor:

Rodrigo Yoshima

Rodrigo Yoshima

Técnico em Processamento de Dados (UNESP) e Bacharel em Administração de Empresas (Mackenzie-SP), trabalha com desenvolvimento de software desde 1994. É colunista da Revista Mundo Java. Possui 7 anos de experiência em gestão de projetos, design e programação de software orientado a objetos. É um dos primeiros SCRUM Master Certificados no Brasil e também obteve a certificação em UML 2.0 pela OMG em 2005. Especialista em automação e produtividade, desenhou diversas soluções de geração automática de código para os mais diversos setores. <!–[endif]–>Atualmente ministra treinamentos e seminários sobre análise e design de software pela ASPERCOM.

Agora é Oficial – InfoQ Brasil em Setembro de 2008 Julho 4, 2008

Posted by Felipe Rodrigues in Notícias.
1 comment so far

Na última quarta-feira foi oficializada a parceria entre a Fratech e a C4Media, empresa responsável pela administração do portal InfoQ.com. A parceria é fruto da sinergia entre a C4Media e a Fratech e foi consolidada durante alguns meses de negociação. A idéia do InfoQ Brasil faz parte do programa de regionalização da comunidade infoq. Esse programa teve início com a InfoQ China e posteriormente InfoQ Japão, chegando no Brasil através da Fratech.

Para quem não sabe, o intuito do portal InfoQ é oferecer notícias e informações sobre várias ramificações do desenvolvimento de sistemas corporativos. Para isso conta com as Comunidades Java, .NET, Ruby, SOA, Agile, Architecture. Dessa forma a InfoQ Brasil seguira as mesmas diretrizes, com a responsabilidade de gerar conteúdo para o público brasileiro e internacional através de tradução, além de traduzir o conteúdo disponível no portal principal para o português.

O trabalho começou. Atualmente estamos traduzindo um dos free books para português e nas próximas semanas montaremos um time de edição e tradução (aguardem a chamada de trabalho) dos artigos e notícias originais. O trabalho de tradução deve preparar o InfoQ Brasil para ser lançado ao público aberto em meados de Setembro de 2008. A Fratech também é responsável por centralizar as negociações com patrocinadores, fato que ajuda a manter a infraestrutura do portal.

Acreditamos sériamente no potencial da comunidade brasileira para produzir conteúdo de qualidade e com responsabilidade. Acreditamos que essa iniciativa irá fortalecer ainda mais o desenvolvimento de software com qualidade no Brasil. Acreditamos ainda que iremos colaborar para um desenvolvimento de mais qualidade, resultando em satisfação para o público brasileiro.

Aguardem mais novidades…

Sobre o autor:

Felipe Rodrigues

Felipe Rodrigues

Arquiteto de Sistemas com experiência de 5 anos em desenvolvimento de sistemas distribuídos. Atualmente trabalha em projetos pela Fratech, atuando na arquitetura de aplicações críticas. Participa atvamente do desenvolvimento do framework Struts2 e mantém o projeto open-source BoxSQL. Palestrante no QCon em Londres.

Scrum Master e sua importância – “Antes de construir software, construir pessoas!” Julho 4, 2008

Posted by Jose Papo in Scrum.
add a comment

Pretendo aqui ajudar a esclarecer a importância do Scrum Master, qual seu papel em uma organização de desenvolvimento de software que aprende e como devem ser suas características de liderança.

Resolvi escrever esse artigo baseado em duas inspirações: A primeira é a série de livros fenomenais que descrevem em detalhes o Sistema Toyota de Produção (ou Produção Lean), sua filosofia e cultura(os livros são: The Toyota Way, The Toyota Way Fieldbook, Toyota Talent e Toyota Culture). A segunda inspiração teve como base os debates ocorridos nas listas sobre desenvolvimento ágil, tratando sobre se o scrum master é necessário e se o scrum master é uma função única.

(mais…)

A Inspeção boa e a ruim Julho 4, 2008

Posted by Alisson Vale in Testes.
add a comment

Embora Quality has nothing to do with testing seja um ótimo post que vale a pena dar uma olhada, acho que o título ficaria melhor formulado como Quality has nothing to do with finding defects. Testes são instrumentos de feedback que obtemos do software quando comparamos seus resultados com nossas expectativas. Assim, quando o resultado de um teste é associado com a completude de uma expectativa, ele é sim um importante instrumento de qualidade.

O mérito do post está em desmistificar as atividades de teste como sendo as únicas necessárias para garantir a qualidade do software. Na verdade, o que ocorre é que as atividades de teste perdem dramaticamente o poder de agregar valor em termos de qualidade quando são utilizadas como instrumento de inspeção-para-a-localização-de-defeitos. Se uma feature sai do ambiente de desenvolvimento sem funcionamento adequado, será certamente mais apropriado parar e descobrir porquê isso ocorreu do que registrar os problemas em um bug tracking e depois continuar o trabalho de inspeção incansável até que nenhum problema seja mais encontrado.

Uma melhor opção é utilizar as atividades de testes como instrumentos para prevenção-de-defeitos. Ao criar, por exemplo, um teste automatizado, não há inspeção. Há a formalização de critérios de aceitação que passarão a conviver eternamente de forma agregada ao produto à partir daquele momento. Assim, somos capazes de introduzir qualidade no produto no mesmo passo em quê o desenvolvemos.

A qualidade dos incrementos de software liberados em um projeto Ágil depende muito do efeito conjunto resultante da aplicação de diferentes tipos de técnicas e práticas, cujo intuito central é evitar que defeitos sejam introduzidos no produto. A ação conjunta desses elementos tem o poder de eliminar (muitas vezes por completo) a necessidade de inspeções-para-a-localização-de-defeitos.

Testes orientados para inspecionar aquilo que, já no seu início, é produzido sem levar em conta os vários aspectos de qualidade relevantes para desenvolvimento de software, são nocivos na medida em que criam uma cultura em que quem desenvolve não precisa garantir a qualidade daquilo que faz, pois há uma implícita delegação para que isso seja verificado por uma outra pessoa.

No entanto, inspeções não serão sempre ruins. Há as inspeções boas também. Elas ocorrem quando o foco é gerar feedback. Ao inspecionar uma nova funcionalidade, por exemplo, o foco de quem inspeciona não precisa ser verificação e conferência. O objetivo da boa inspeção é dar feedback, é oferecer um novo ponto de vista de modo a encontrar pontos que poderiam estar melhor resolvidos. O mesmo ocorre quando inspecionamos código, seja passando o código para um colega inspecionar, ou seja fazendo inspeção contínua com pair programming. Em ambos os casos, a procura-por-problemas é elemento secundário, enquanto que feedback é o elemento central.

Em resumo, a inspeção ruim procura por defeitos, enquanto que a boa gera feedback.

Sobre o autor:

Alisson Vale

Tem mais de 15 anos de experiência com desenvolvimento de software e a mais de 6 anos lidera projetos de software dos mais variados tipos e tamanhos. Hoje é Líder de Projeto e Diretor da Phidelis Tecnologia, onde lidera a equipe de desenvolvimento da solução acadêmica oferecida pela empresa. E-mail:

alisson.vale@phidelis.com.br Weblog: http://www.phidelis.com.br/blogs/alissonvale

IBM Adotando Agilidade? Julho 4, 2008

Posted by Ricardo Almeida in Notícias.
Tags: , ,
add a comment

Está cada vez mais claro os benefícios que as metodologias ágeis estão trazendo para nós. Grandes empresas agora se mostram muito preocupadas com o assunto, e a IBM, é claro, não quer ficar para trás.

A IBM está focada em unir Desenvolvimento Ágil com a Governança, como um “Investimento disciplinado”.

“Tailoring governance is a progress.”

Estive no IBM Developer Conference 2008 e comentei sobre o evento nesse post:

http://manifestonaweb.wordpress.com/2008/06/20/metodologia-agil-na-ibm/

Sobre o Autor:

Ricardo Almeida

Ricardo Almeida

Ricardo Luiz de Almeida é consultor, arquiteto e desenvolvedor de software. Já atuou em sistemas bancários, cosméticos, automóveis, finaneiros, logística e energia. Atua na área desde 2002. Graduação na PUC-SP e Pós-Graduado na FIAP.
Experiência Internacional de desenvolvimento de software no Chile.
Admirador de metodologias ( de preferência ágeis ) e boas práticas de desenvolvimento de Software.

Lean Software Development Julho 3, 2008

Posted by Victor Hugo Germano in Lean.
1 comment so far

Introdução

“Lean Thinking” (ou “Mentalidade Enxuta”) é um termo cunhado por James Womack e Daniel Jones para denominar uma filosofia de negócios baseada no Sistema Toyota de Produção que olha com detalhe para as atividades básicas envolvidas no negócio e identifica o que é o desperdício e o que é o valor a partir da ótica dos clientes e usuários. (mais…)

Os Moinhos de Vento dos processos ágeis Julho 3, 2008

Posted by Manoel Pimentel in Pensamentos.
2 comments

No mundo inteiro, estamos vivendo um momento interessante no cenário Agile, pois cada vez mais temos novas empresas adotando algum processo ágil, um número maior de profissionais estão se dedicando a consultoria especializada sobre assunto, muitos blogs têm surgido para trazer temas relacionados aos processos ágeis, as comunidades estão ficando cada vez maiores e mais participativas.

Porém nossas comunidades na mesma velocidade em que crescem, também sofrem de uma característica típica das relações entre as pessoas: “A divergência de idéias”, não que isso seja algo negativo, pois como disse Nelson Rodrigues: “Toda unanimidade é burra”, então grande parte das divergências sobre Agile têm estimulado significativos avanços na compreensão e adoção das metodologias ágeis em projetos de software no mundo afora.

O maior problema é que fazendo uma simples analogia a história de Dom Quixote, escrito por Miguel de Cervantes, em nossas comunidades é comum ver alguns bons cavaleiros lutando contra “Moinhos de Vento”, ou seja, monstros imaginários que habitam nossos sonhos e devaneios ocupando o lugar de nossos inimigos, ou seja focando em debates que não agregam valor para ninguém.

Claro que semelhante ao universo imaginário que Don Quixote misturava ao seu mundo real, esses pseudo-inimigos são frutos de nossos sonhos e frustrações aliados aos nossos paradigmas que norteiam o que acreditamos ser é certo ou errado no mundo de projetos de software, ou seja, a criação desses Moinhos de Vento não é gratuita, existem algumas causas que estimularam nossas mentes a criar esses inimigos e essas causas, apesar de muitas vezes serem questionáveis, devem ser respeitas por todas as comunidades.

Para ser mais pragmático, o grande fator que me estimulou a escrever esse desabafo, no lugar de uma artigo tradicional, é a existência de “fogo amigo” dentro de nossas comunidades, pois tenho visto constantes ataques entre as diferentes vertentes sobre metodologias ágeis no Brasil e no mundo, alguns exemplos:

- Excessivos debates sobre qual metodologia é melhor do outra,

- Longos debates sobre a morfologia de termos usados em nossa área,

- Críticas aos backgrounds de cursos e certificações relacionados aos processos ágeis

É importante observar que o problema não é a existência das divergências em si, pois como eu falei anteriormente, algumas divergências são saudáveis para a nossa evolução, porém o lado negativo, é o fato que essas divergências estão estimulando algumas segregações, onde na verdade estamos precisando urgentemente de agregações.

Pude confirmar isso, ao conversar com um CIO de uma grande empresa quando ele me falou o seguinte:

“Tenho observado as comunidades sobre métodos ágeis e cheguei a conclusão de que vocês agilistas não sabem onde querem chegar… e te falo mais, fica muito difícil saber por onde começar em agile com tantas diferentes idéias sobre o que é certo ou não…”

Também achei a opnião dele meio forte, argumentei um pouco, tentei minimizar as coisas, gastei bastante saliva e no final acho que ele se convenceu de que essas divergências são normais, mas esse foi apenas um caso, creio que devam existir muitas pessoas que compartilham o mesmo pensamento, ou seja possuem uma visão equivocada de nossa comunidade em função de nossas próprias ações.

Por isso, termino esse breve texto, clamando pelo respeito a todas as idéias, iniciativas e principalmente para que todos nós, tentarmos trabalhar na parte mais difícil desse processo de construção, que é usar nossas diferentes idéias, de maneira convergente para a ajudar a disseminar e estimular a adoção das metodologias ágeis nos universos onde estamos inseridos.

Sobre o autor:

Manoel Pimentel, CSP

Manoel Pimentel, CSP

É Engenheiro de Software, com mais de 15 anos na área de TI, atualmente trabalha com projetos Java pela Rhealeza(SP) e como Coach em metodologias pela Fratech Tecnologia(SP). É Diretor Editorial da Revista Visão Ágil, Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.
Contato: manoel@visaoagil.com