Bas de Baar do blog e video podcasts “Project Shrink“, que discute liderança em gerencimento de projetos, entrevista Jesse Fewell em seu podcast episódio 28. Jesse é o líder de um grupo de integrantes do PMI, interessados nas práticas ágeis.

Na entrevista são discutidos diversos pontos, dentre eles, o que a comunidade ágil pode contribuir com o gerenciamento de projetos tradicional e vice-versa.

Mais Informações:
    PMI lança Comunidade de Práticas Ágeis na Agile2009
    Oficializada a comunidade “PMI Agile”!
    

Um post no blog Débito Técnico do Rodrigo Yoshima, onde ele faz uma relação ao que matou o RUP pode matar o Agile.

…
O que vocês devem estar se perguntando é: O que matou o RUP e pode matar o Agile? Como eu falei, eu temo pelo movimento Agile. Assim como foi em 2003, em 2009 eu ví o primeiro pseudo-especialista Agile falando absurdos – violando valores. A partir do momento que eu vejo a comunidade Agile discutindo e dando importância demais a post-its, quadro de tarefas e cartinhas de planning poker, eu temo pelo movimento Agile. Quando eu vejo a comunidade Agile buscando certificações, preocupados em como casar Agile com CMMI ou como adaptar Agile à contratos de escopo fechado, eu temo pelo movimento Agile. Sempre que eu vejo isso no mundo Agile, me transporto a 10 anos atrás e me lembro das discussões sobre templates de casos de uso, definições de padrões de modelagem UML, pensamento linear, check-lists de artefatos, uso incorreto de ferramentas, falta de compreensão sobre fases e o pior de todos: o departamento que cuida dos processos de desenvolvimento. Resumindo, quando vejo esse mind-set de besteirols e libertinagens Agile, eu me lembro do mind-set burro e burocrático que contaminou o RUP.

O que matou o RUP foi a falta de entendimento, e isso é o que vai matar o Agile. Lean é o próximo da fila. Escreva aí: em 5 anos, dependendo dos ventos da economia e do clima empresarial, muitos vão estar criticando Agile do mesmo modo que hoje criticam o RUP, sem autoridade de causa. Tudo vai depender do mind-set vigente no momento. Tudo depende do mind-set: se você der o Scrum e XP para um “tradicionalista” ele não vai mudar seu mind-set, mas sim adaptar o Scrum e o XP às suas “crenças”. Se você der o RUP para um pragmático, ele também não muda o seu mind-set, mas sim, adapta o RUP à sua realidade. Você pode decidir o seu mind-set: ou você realmente acredita nos 4 valores e 12 princípios ágeis e adota este estilo, ou você se enche de penduricalhos ágeis só para ficar na modinha.
…

O post completo pode ser encontrado em: http://blog.aspercom.com.br/2009/09/29/o-que-matou-o-rup-pode-matar-o-agile/

Fonte: Débito Técnico

Fonte: Scrum Log – Jeff Sutherland

Message from the Board of Directors

On September 15, Ken Schwaber resigned as President and Chair of the Board of Directors of the Scrum Alliance. Tom Mellor was elected President and Chair of the Board by the Board members. Kenexpressed to the Board his intentions to remain active in the Scrum community. The Board expresses its appreciation to Ken for his service and leadership. Additionally, Jim Cundiff is no longer Managing Director of the Scrum Alliance and a search is underway for a new managing director. The Board anticipates filling the position in the very near future. Questions can be directed to Jodi Gibson at jgibson@scrumalliance.org

posted by Anand Shah (22 Sep 09)

Fonte: Scrum Alliance

Mike Cohn elaborou uma interessante idéia da qual concordo, mas que pode parecer uma heresia para muitos agilistas: Agile tem tudo a ver com micro-gerenciamento!!!

Sim, isso mesmo, provavelmente alguns devem ter iniciado uma fogueira para queimar os excelentes livros do Mike Cohn sobre gestão e estimativas ágeis em projetos e sobre user stories. Mas antes de riscar o fósforo deixe a idéia ficar mais clara .

Diversas práticas básicas dentro de métodos ágeis estão lá para suportar o micro-gerenciamento das pessoas. Exemplos:

- O Daily Stand-up Meeting (Reunião diária de 15 minutos em pé) é um micro-gerenciamento diário do planejamento da iteração. Ele garante que todos estão fazendo ou farão aquilo que deveriam.

- A Integração Contínua é colocada para que, no instante em que um desenvolvedor cometa um erro e quebre um build, todos fiquem sabendo rapidamente.

- A programação em pares garante que os desenvolvedores não percam o foco, não façam goldplating e que limpem e refatorem continuamente o código.

Mas quem faz esse micro-gerenciamento todo? Aí vem o ponto importante: a equipe faz um auto-microgerenciamento! Isso é bem diferente de um gerente micro-gerenciar. Quando a equipe faz seu próprio micro-gerenciamento ela só tem benefícios e realiza o nirvana da auto-organização.

Fonte: José Papo Weblog

Postado por Chris Sims, traduzido por Luiz Fernando Signorelli em 10 Set 2009 12:26 PM

O Project Management Institute (PMI) lançou oficialmente a sua Comunidade de Práticas Ágeis na conferência Agile2009. A missão do grupo é: "Equipar os membros do PMI e com habilidades e conhecimentos de metodologias Ágeis" Mike Griffiths foi o responsável por fazer as coisas andarem, quando ele lançou um desafio ao PMI na Agile 2007, para que este formasse um grupo de trabalho específico para metodologias ágeis.

O grupo de voluntários que criou a Comunidade de Práticas Ágeis (CoP), aplicou práticas ágeis durante o trabalho de criação da própria organização. Eles trabalharam com iterações de 2 semanas e fizeram retrospectivas visando melhorar seus processos. Jesse Fewell, desempenhou um papel análogo ao Product Owner de uma equipe Scrum. Em uma entrevista gravada para o Project Shrink Podcast, Jesse deu um exemplo de como a equipe repriorizou seu"backlog" com o intuito de entregar mais valor rapidamente. O resultado foi a criação de um wiki onde as pessoas puderam encontrar informações sobre o grupo, e sobre metodologias ágeis, mesmo antes de todo o trabalho administrativo de formação do grupo estivesse completo.

O lançamento foi comemorado em uma festa promovida pela ThoughtWorks, na sua sede em Chicago. O evento atraiu mais de 200 pessoas, incluindo Martin Fowler, Jim Highsmith, Ward Cunningham, Alistair Cockburn .

O lançamento não foi o único evento relacionado ao PMI durante a conferência Agile2009.Na "Fresher’s Fair " da primeira noite Jesse, Ainsley Nies, Brian Bozzuto, Sanjiv Agostinho, e outros, notificaram um maior envolvimento e interesse do PMI na comunidade ágil.

O que é um Gerente de Projetos Ágil? foi uma sessão interativa, apresentada por Pat Reed e Jesse Fewell, que explorou o papel do gerente de projetos em um contexto ágil.

Mike Cottmeyer apresentou O PMP Ágil: Ensinando novos truques a um cachorro velho, que examinou os processos e as áreas de conhecimento do PMI e como adaptá-los aos projetos ágeis.

No último dia de sessões oficiais, Jesse apresentou a história de como a Comunidade de Práticas Ágeis do PMI foi criada, no Growing PMI Using Agile (Melhorando o PMI usando metodologias ágeis) .

A equipe distribuída responsável por fazer da Comunidade de Práticas Ágeis do PMI uma realidade inclui:

• Sanjiv Agostinho
• Rodney Stijns
• Brian Bozzuto
• Mike Cottmeyer
• Mike Griffiths
• Jean Laporte
• Dan Mezick
• Ainsley Nies
• Dave Antes
• Pat Reed
• George Schlitz
• Michele invasao
• Bob Tarne

Fonte: InfoQ

Postado por Mike Bria, traduzido por Paulo Henrique em 09 Set 2009 08:55 AM

Há debates incessantes sobre se a adoção ágil é melhor realizada de uma forma mais gradual ou com uma abordagem "tudo-ou-nada". Johanna Rothman diz que é necessário realizar as duas abordagens: os projetos devem mergulhar nela, enquanto as organizações devem levá-la gradualmente.

Nos 2 últimos posts, Plunge In (For Projects) e Small Steps Are Good, Be Careful What You Call Them, Johanna postula que as pessoas precisam mergulhar de cabeça na adoção de abordagens ágeis no nível do projeto. Em essência, ela toma uma linha mais rígida do que fazer as coisas como trabalhar em iterações “timeboxed” ou fazer integração contínua, mesmo que esteja melhorando a sua situação, não significa que você está fazendo "ágil". E ainda assim você está se preparando para o fracasso se você chamar isso de ágil:

…se você chamar algo ágil, por favor, torne-o ágil. Se você mergulhar nele, você ainda não fez o compromisso. Se você variar seu “timebox” dependendo se você terminar o trabalho no “timebox”, isso não é ágil; é desenvolvimento incremental. Você pode dizer: "Nós estamos experimentando com o desenvolvimento incremental. Nós escolhemos variar o tamanho do “timebox” para que possamos começar a prática do conceito de “done”. Talvez depois de praticá-lo por um tempo, nós vamos corrigir os nossos timeboxes e ver como é que funciona".

Isso é perfeitamente razoável. Convido você a fazer isso, se você ainda não experimentou desenvolvimento incremental ainda. Mas não o chame ágil. Pois, não é.

Logo depois, Rothman apresentou um terceiro postulado que, em última análise sugere o oposto quando se trata de níveis organizacionais de adoção ágil. Ela sugere que os gerentes adotem uma abordagem mais gradual em relação à evolução das estruturas administrativas em toda a organização:

Migrar uma organização para um conceito ágil é um problema não-trivial. A etapa 0 é o projeto. O primeiro passo é a portfólio de projetos. Em seguida, vem o trabalho realmente duro: os sistemas de recursos humanos são o próximo passo. Uma vez que você migrou os sistemas de recursos humanos de volta para ajudar os funcionários, agora você pode atacar os sistemas orçamentários. (Um dos meus clientes está tentando fazer os sistemas orçamentários em primeiro lugar, e que não está funcionando. Pode haver alguns prós e contras com os sistemas de recursos humanos e orçamentários).

Gerentes, mergulhe agilmente para os sistemas de gestão, desde que você pegue uma parte coerente e comprometa-se de forma ágil ou lean para essa parte. Não é bom mergulhar em um determinado projeto, comprometer-se agilmente para um projeto, se isso é certo para você. E, comprometa-se a aprender sobre gerenciamento ágil e lean.

Em essência, Rothman diz sobre esta pequena série de postulados que fazer bem de forma ágil requer um nível de disciplina que nem todos os projetos estão preparados. Escolha quais projetos estão prontos, e migre-os totalmente, mas, não se preocupe com a transição de todos os projetos ou toda a organização de uma só vez, pense ‘gradual’ quando se trata disso. O que você acha?

Fonte: InfoQ

Postado por André Pantalião em 25 Ago 2009 10:03 AM
Para o InfoQ

Estava acompanhando a lista de e-mails leandevelopment e surgiu uma discussão sobre como definir o que seria Lean em 30 segundos. Algumas definições interessantes surgiram e tentarei listar algumas neste post.

Alan Shalloway disse:

"Lean é uma abordagem para entregar valor mais rapidamente para seus clientes focando em melhorar o workflow dos produtos sendo entregues. Em particular, times devem sempre reduzir atrasos, que estão ligados a desperdício e baixa qualidade."

Mary Poppendieck complementou citando a opinião de John Shook sobre o assunto:

“Como sabemos, muito e se não a maior parte, se não quase tudo do "Lean" é essencialmente procurarmos meios de executar o P-D-C-A em tudo que fazemos.”

Definição retirada de [http://www.lean.org/shook/2009/07/managing-to-pitch-with-pdca-pitch.html. É preciso se registrar para visualizar.]

Além disso Mary complementou que Lean é tudo sobre aprendizado constante. Fácil de dizer, difícil de fazer, especialmente em uma grande organização.

Robin Dymond contribui com uma explicação de 5 segundos que ele usa:

"Lean é um termo do Sistema de Produção Toyota (Toyota Production System – TPS). TPS é a razão da Toyota ser o fabricante dominador no setor automotivo atualmente."

Ele argumenta que isto atrai a atenção das pessoas e exibe os benefícios que eles podem ser obtidos. Mas no fim das contas, ele acredita que a melhor forma não é explicar o que Lean é, mas sim, mostrar os benefícios que podem ser obtidos.

Na sequência, Luiz Parzianello citou o workshop que desenvolveu para mostrar os benefícios que podem ser obtidos com Lean. Este workshop foi desenvolvido para desafiar mentes pragmáticas e analíticas que estão acostumadas a trabalhar sob o paradigma de produção em massa. Ele chamou este workshop de "Jogos Estatísticos para Adoção de Agile" e serão apresentados na Agile 2009 (Chicago). Quem quiser pode verificar a sua apresentação em: http://www.agile2009.org/node/1587.

Kent Beck resumiu muito bem sua opinião assim:

"Ao aplicar o desenvolvimento lean eliminamos tempo e esforço desperdiçado. O que sobra é produtividade. Exceto que uma vez que você fez isto, você está pronto para ver o próximo nível de esforço e tempo desperdiçado. Desta forma, o ciclo de melhoria nunca termina."

Mary Poppendieck comenta novamente e faz algumas observações na mesma linha de Kent Beck. Ela estava pensando sobre o que John Shook queria dizer e conclui:

"Lean é sobre sempre melhorar o que você é agora através de testes e métricas dos resultados. Então é sobre nunca estar confortável com o status quo, e sempre aprender como melhorar utilizando o método científico."

Ela ainda complementa: 

"Lean pode ser sobre fornecer mais valor ao cliente – mas como você sabe o que é valor para o cliente e como você sabe o que fazer para entregar mais valor para ele? Lean pode ser sobre aumentar o lucro – mas como você sabe que estes lucros estão contribuindo para o sucesso a longo prazo?

Em dez segundos, teremos só parte da mensagem. E isto pode ser perigoso, porque estas definições não o fazem pensar. Ela pensando sobre a frase de John Shook sobre Lean como : lean é fundamentalmente sobre entender o que é importante e usar uma abordagem disciplinada para constantemente melhorar nas coisas que foram definidas como importante. Uma definição bem genérica. Talvez é só parte da mensagem. Talvez seja algo para o pessoal pensar."

Siga o conselho de Mary, pense sobre o assunto, saiba mais e tire suas próprias conclusões.

Fonte: InfoQ

Postado por Amr Elssamadisy, traduzido por Rodrigo Piovezan em 18 Ago 2009 01:01 PM

Em uma discussão recente no Yahoo! Grupo de test driven development Carlos Ble compartilhou seu entendimento de categorias de testes decorrente de sua pesquisa:

Acabei tendo a seguinte imagem:
Testes do desenvolvedor:
Testes unitários : Isolados, atômicos, inócuos: exercitados com xUnit
Testes de integração:
Testes isolados que podem mudar o estado do sistema, por exemplo: salvar em banco, escrever em arquivo… Um teste de integração não representa por si um requisito funcional. Podem ser escritos para xUnit. Eles verificam a integração do nosso código com uma ferramenta de terceiros ou com diferentes camadas de nosso próprio código, por exemplo: a camada de lógica de negócio requer a camada de acesso a dados

Testes funcionais: (também conhecidos como Testes de Sistema)
Um teste que exercita uma parte completa do sistema, algum requisito funcional. Ele pode mudar o status do sistema.
Testes do Product Owner:
Testes de aceitação: Testes funcionais cuja entrada e saída podem ser validadas por uma pessoa não-técnica, o product owner.

John Donaldson forneceu um modelo multidimensional para testes que foca em papéis de teste e tipos de teste:

Eu gosto da visão de testes que você propõe. Mas acho que é uma instância de um modelo maior, onde você tem (pelo menos) papéis de atuação e tipos de teste.

Papéis de atuação: desenvolvedor, testador, QA, usuário, sponsor, etc.

Tipos de teste: unitários, de integração, funcionais, sistêmicos, de aceitação, de carga prolongados (soak), preliminares (smoke), etc.

Em qualquer situação dada você provavelmente sabe qual papel se encarrega de qual teste – mas no próximo projeto isso pode ser diferente.

Dale Emery sugeriu que não saber qual tipo de teste você está escrevendo é um sintoma de código ruim e indica falta de clareza. Um teste pode cair em diversas categorias ao mesmo tempo e o que importa é o seu ponto de vista atual:

O desafio, penso eu, é que qualquer teste pode ser classificado razoavelmente de várias formas diferentes, dependendo de quais dimensões você está focando. E existem diversas dimensões que as pessoas usam para classificar testes. Eu identifiquei algumas aqui: http://cwd.dhemery.com/2004/04/dimensions/

Por isso estou menos interessado em saber "qual tipo" de teste é, e mais interessado em saber onde um teste se encaixa nas dimensões que são mais importantes para mim, dependendo do meu objetivo em determinado momento. Aquelas em que penso com mais frequência são:

• Qual "unidade" esse teste define e valida? (Qual sistema, subsistema, objeto, colaboração…) – Qual funcionalidade o teste define e valida?
• Quem está primariamente envolvido com esse teste? Quem se preocupa mais com os resultados da execução desse teste?
• Quais decisões serão tomadas a partir dos resultados da execução desse teste?

Charlie Poole fornece uma análise detalhada da categorização de Carlos e sugere:

Na minha opinião, a distinção mais importante é entre os testes de objetivos do desenvolvedor e os testes de objetivos do cliente.

Essa discussão evidencia o fato de que classificar testes pode ser bastante confuso – especialmente para o iniciante.  O consenso é que a forma mais indicada para classificar testes é uma abordagem dimensional e que o tipo de classificação que é relevante depende dos objetivos do usuário naquele momento e do contexto.

Fonte: InfoQ

Por Guilherme Chapiewski para o Blog Guilherme Chapiewski
em 17/08/2009

Esses dias numa conferência alguém veio me contar a sua história, que era de uma empresa que nos últimos anos vinha desenvolvendo seus projetos de forma tradicional, em cascata, e que tinha gostado do que tinha visto sobre metodologias ágeis e estava pensando em tentar. Ele gostou principalmente da idéia de trabalhar com desenvolvimento iterativo e decidiu que iria tentar usar Scrum na sua empresa.

Passadas algumas semanas encontrei denovo com essa pessoa em um outro evento. Para a minha surpresa, ela me disse que sua vida estava um inferno! Os clientes não estavam dispostos a fechar contratos de escopo negociável, eles queriam saber exatamente o que e quando os projetos seriam entregues. Eles definitivamente não quiseram trabalhar com desenvolvimento iterativo, até porque os projetos já eram bem curtos (menos de 1 mês). Pra terminar, por ser uma agência pequena a equipe é de menos de 10 pessoas fazendo com que uma pessoa precise trabalhar em 3 ou 4 projetos ao mesmo tempo. E por aí vai…

Então eu perguntei: Quantos projetos davam errado antes de você começar com Agile?

E ele respondeu: Todos os nossos projetos sempre foram bem sucedidos.
E eu perguntei denovo: Então qual é o problema que você está tentando resolver usando Scrum e desenvolvimento iterativo?
(silêncio…)
Eu novamente: Ok, já entendí. Faça o seguinte, volte para o seu processo de trabalho antigo. Não sei como é mas me parece ótimo.

Muita gente se surpreende quando eu falo isso. Só porque eu falo sobre desenvolvimento ágil não significa que eu acho que isso é a solução para todos os problemas. Se todos os seus clientes estão satisfeitos do jeito que você está trabalhando, seus projetos não falham, você faz ótimas entregas e tudo está ótimo, você não tem um problema. E se você não tem um problema, você não precisa resolver nada. E nesse caso eu recomendo: não use uma metodologia de desenvolvimento ágil só porque está na moda.

Metodologias ágeis partem do princípio de que os requisitos de um projeto de software vão mudar. Geralmente em projetos de software grandes é muito difícil de planejar todos os requisitos de uma vez no início do projeto. Não seria impossível fazer isso mas o custo é tão alto que vale mais a pena planejar menos e ir adaptando o software e os requisitos ao longo do tempo até que ele esteja pronto. No cenário dessa pessoa, como os projetos são muito pequenos é perfeitamente possível planejar tudo antes em pouco tempo e desenvolver em seguida.

Em alguns outros casos onde os requisitos não mudam waterfall também pode fazer sentido. Por exemplo, quando você desenvolve software para o governo, toda a especificação do projeto normalmente é produzida e informada antes em um edital. Algumas vezes até o prazo de entrega já está definido. Eu pessoalmente já trabalhei em vários projetos desse tipo que deram certo, que foram entregues dentro do prazo, atendendo a especificação e sem maiores problemas. Como tudo estava funcionando, não havia motivo para pensar em outra forma de desenvolvimento que eventualmente poderia trazer mais problemas do que soluções, como no caso dessa pessoa que conversou comigo.

O que eu quero dizer com isso tudo é que não existe uma metodologia que funciona para todos os casos e todos os projetos do mundo. Assim como você deve usar a melhor ferramenta para cada problema, você deve usar a melhor metodologia para cada projeto.

No projeto que eu estou atualmente estamos quebrando vários paradigmas de desenvolvimento ágil. Estamos com times gigantes, usando quadros de Lean totalmente customizados misturados com Scrum e por aí vai. Estamos sempre analisando os resultados das iterações e replanejando nosso processo. Apesar de todos os livros dizerem que os times têm que ser pequenos, estamos trabalhando com um time de 20 pessoas que dá certo e está super produtivo. Esse é o espírito: faça o que for melhor para o projeto e o que te fizer ter os melhores resultados, não o que alguém diz que é certo ou é errado ou o que está na moda.

É perfeitamente possível desenvolver projetos bons em qualquer metodologia. Entenda qual é o seu cenário, quais são os seus problemas, limitações e aí sim decida qual é a melhor forma de trabalhar nos seus projetos.

Fonte: Blog do Guilherme Chapiewski