Agilidade Gramatical: Como ser mais eficiente na comunicação dos requisitos

Umas das frases mais famosas (pelo menos na minha visão) do mundo ágil, principalmente quando o assunto é Requisitos, foi dita por Mike Cohn:

"Software Requirements is a communication problem."  

(User Stories for Agile Requirements)

Um software não nasce no primeiro rabisco.  Muito menos na primeira linha de código ou no primeiro diagrama de classes. Ele nasce bem antes disso. Ele nasce na mente das pessoas que sentem uma determinada necessidade.  Por curiosidade, é provável que alguns dos softwares que conhecemos hoje, tenham sido criados antes do surgimento dos transistores, em 1947.  Na verdade, até mesmo antes da criação do primeiro computador, que acredita-se ter sido o Mecanismo de Anticítera, criado no século I a.C., na Grécia.  Mas isso é outra história.  Ou melhor, isso é História.

Mecanismo de Anticítera

Não é difícil encontrar, nos livros de negociação e empreendedorismo, frases como: "Resolver problemas e atender à necessidades é a arte do sucesso",  "Crie um produto que atenda às suas necessidades e, provavelmente, esse produto atenderá a outras pessoas" ou "Faça um estudo de mercado antes de lançar um produto". Repetir estas frases é quase como dizer que precisamos nos alfabetizar para sermos escritores.  Entretanto, nem sempre o que é óbvio, é seguido.  O desenvolvimento de software segue princípios semelhantes, mas muitos profissionais os ignoram.  O software é um produto.  E como tal, suas necessidades precisam ser identificadas antes da sua concepção.

"A criação de um software é a arte de resolver problemas e atender necessidades  humanas com o uso de programas de computador"  

O escritor Dam Roam, em seu livro The back of the Napkin, afirma o seguinte: 

"A arte dos negócios é a arte da resolução de problemas... Que tal se existisse uma maneira de encontrar os problemas mais rapidamente, entendê-los mais intuitivamente, endereça-los de maneira mais confiável e transmitir mais rapidamente aos outros o que temos descoberto?"

"Descobrir necessidades do usuário é preciso, desenvolver software não é preciso"

A frase acima faz uma alusão ao famoso discurso do general romando Pompeu: "Navegare necesse; vivere non est necesse". Desculpem meus amigos desenvolvedores. Tenho nada contra eles.  Até porque também sou desenvolvedor.  Mas percebi que identificar as necessidades de usuário é mais valioso que desenvolver o software. 

Quer um exemplo? Imagine um automóvel.  Qualquer um. É comum ouvir pessoas dizendo: "Eu preciso de um carro".  No entanto, carro não é uma necessidade, mas um objeto ou produto que nos ajuda a atender a uma necessidade (ou várias). Uma das necessidades que pode ser atendida por um automóvel, e provavelmente a principal delas, seria: "Eu preciso locomover de maneira mais rápida entre locais diferentes".  
Utilizando esta analogia como referência, pode-se concluir que uma das principais habilidades para a construção de um software passa a ser a capacidade de identificar a diferença entre necessidades e objetos.  A dica que dou pra isso é: Use a gramática! 

"Necessidades são os verbos, objetos são os substantivos. 

Se seguirmos a conclusão de Mike Cohn dita no início deste artigo, onde ele afirma que requisitos é um problema de comunicação, podemos fazer um melhor uso da gramática para comunicar requisitos e necessidades dos usuários de uma forma mais eficiente e clara.

Segundo o dicionário, gramática é... 

"... o conjunto de princípios que regem o funcionamento de uma língua; a gramática orienta como as palavras podem ser combinadas ou modificadas para que as pessoas possam comunicar-se com facilidade e precisão. 

A abordagem de como comunicamos os requisitos tem um impacto significativo no escopo de um projeto.  A "forma tradicional" de análise de requisitos impede que o desenvolvedor de software pense. E o pior, impede que o usuário pense.

Preste atenção nos 2 requisitos abaixo:

    1. Eu preciso de um chuveiro.
    2. Eu preciso tomar banho.

Qual a diferença entre eles?
A diferença é que o requisito 1 usa um substantivo (chuveiro) como elemento principal, enquanto que o requisito 2 usa um verbo (tomar) e nos obriga a pensar.  Sei que muitos dos leitores devem estar pensando que ambos os requisitos dizem a mesma coisa, uma vez que para tomar banho, muitos pensariam em ter um chuveiro. Se você é um destes leitores, tente chegar a essa mesma conclusão com os requisitos 3 e 4 abaixo:

    3. Eu preciso de uma Ferrari.
    4. Eu preciso locomover mais rapidamente.

Agora perceba que, apesar de ambos os requisitos parecerem dizer a mesma coisa, o requisito 3, caso seja implementado, pode ser bem mais caro e demorado que o requisito 4, uma vez que, para atender ao verbo locomover, diversas soluções mais baratas que a Ferrari poderiam ser encontradas.

Em resumo, a forma como nos comunicamos interfere drasticamente no quanto gastamos em um projeto de software. E a agilidade gramatical pode nos ajudar, consideravelmente, a amenizar este risco com uso correto de técnicas vindas da agilidade, como as estórias de usuário e o mapeamento destas, e a nossa gramática.

Software de Qualidade mais que Software Funcionando

Em 2011, quando Fortaleza sediou o Agile Brazil, os participantes do evento tiveram a oportunidade de assistir a um Keynote entitulado: "Liderança adaptável: acelerando a agilidade organizacional".  Durante os dias do evento, pude conhecer um pouco mais sobre Jim Highsmith, o preletor desta palestra e um dos autores do Manifesto Ágil. Em uma das conversas com ele, uma frase ficou gravada na minha mente: "Qualidade é Pessoal."

Na verdade, eu já havia escutado esta frase várias vezes, mas nunca da boca de Jim Highsmith.  Ele falara de forma tão precisa e profunda, que acreditei haver algum material de sua autoria na internet falando do assunto.  Encontrei um artigo dele chamado When Quality is Personal.  Também encontrei um outro artigo entitulado Quality is Personal, escrito por Israel Gat. Indico a leitura dos dois.

Comecei a ver o conceito Qualidade de forma diferente. Anteriormente, software funcionando mais que documentação abrangente, já me dizia tudo. O tempo e a experiência me fizeram perceber que não há como definir qualidade de software, tendo em mãos, "apenas" um Software Funcionando.   Segundo o dicionário,  "Qualidade é um atributo, condição natural, propriedade pela qual algo ou alguém se individualiza, distinguindo-se dos demais; maneira de ser, essência, natureza..." 

Entretanto, no desenvolvimento de software, conseguimos encontrar um outro conceito para a palavra qualidade: 

"Experiência agradável (ou desagradável) pela qual passa um usuário ao utilizar um programa de computador"

Atualmente, há uma tendência em valorizar empresas que investem grandes volumes de recursos financeiros em qualidade de processos, desenvolvimento de pessoas e melhoria no ambiente de trabalho. Mas "apenas isso" não é suficiente para criar um produto de qualidade.  

Por exemplo:

O Brasil é, hoje, um dos maiores produtores e consumidores de café do planeta. Em uma recente pesquisa feita pela ABIC (Associação Brasileira da Indústria de Café), foi constatado que um brasileiro chega a consumir 83 litros de café por ano. É muito café! Acredito que eu tenha uma parcela de contribuição nesta estatística.

O resultado dessa pesquisa não é surpresa. Durante anos, os produtores de café fizeram grandes investimentos na lavoura, na industrialização do café e na logística de entrega. Grandes quantias em dinheiro são gastas, anualmente, para alcançar elevados níveis de qualidade nos processos de fabricação.

Mas o que isso nos interessa?  Simples.  Eu gosto de café, mas detesto café forte. Não adianta o melhor processo de produção, guiado pelos mais conceituados profissionais do planeja... se eles me entregarem uma xícara de café forte... vou fazer careta! 

"A boa qualidade de um produto não depende do processo de fabricação ou da competência técnica dos profissionais envolvidos, mas da experiência agradável vivenciada pelo consumidor. "

Equipes de desenvolvimento de software que realmente buscam a qualidade, estão preocupadas com a Experiência do Usuário com o produto. O processo de "industrialização" do software é secundário.

Essa é a razão pela qual muitos dos nossos colegas falam em User eXperience (UX). Um trecho de uma entrevista feita a Steve Jobs, em um artigo de 2003 entitulado "The Guts of a New Machine" ("As entranhas de uma nova máquina") publicado no The New York Times por Rob Walker, já resumia o que hoje chamamos de UX :

...

 ''Most people make the mistake of thinking design is what it looks like,'' says Steve Jobs, Apple's C.E.O. ''People think it's this veneer -- that the designers are handed this box and told, 'Make it look good!' That's not what we think design is. It's not just what it looks like and feels like. Design is how it works.''

...

O foco deste post não é falar sobre UX.  Irei escrever um outro artigo sobre isso futuramente.  No entanto, para quem interessar, sugiro o material WHAT IS UX DESIGN? por Ross Popoff-Walker.

Finalizo este post com a simples conclusão de que não adianta falar de qualidade sem proporcionar aos usuários/clientes a experiência de usar nosso software. 

Como dizer ao cliente que ele é importante?

Nos últimos anos, tive a oportunidade de lidar com diferentes clientes e empresas.  Algumas das pessoas com as quais conversei, absorveram a importância delas (clientes) em participar dos projetos. Não somente validando resultados, mas direcionando o desenvolvimento.  Entretanto, grande parte dos clientes não se interessa pela execução do projeto. Uma das razões pra isso é que nós, pessoas que constroem o software, não sabemos como dizer a eles, pessoas que usam o software, a importância da sua participação. Este post não tem a pretensão de ensinar como fazer isso, mas tentar mostrar como uma analogia pode mudar todo o entendimento. Então, como deixar claro que a participação dos nossos clientes/usuários é decisiva? 

Leia a analogia abaixo:

---

Imagine uma Ferrari Enzo.  Agora, se conseguir, imagine um fusca. Ambos são carros e têm um objetivo em comum: transportar pessoas (sem piadas com o fusquinha, por favor).  No entanto, existe uma "pequena" diferença na potência desses carros. Uma Enzo pode chegar a 800 cavalos enquanto um fusca chega a 200.  E daí?  Calma! 

Pergunta: Qual dos dois carros o leitor gostaria de ganhar de presente?  A maioria esmagadora das respostas seria óbvia, a Ferrari.  Mesmo os apaixonados por Fusca ainda escolheriam a Ferrari.  A venda dela daria para comprar vários Fuscas. 

Mas a questão não é essa. 

Vamos dar vida a essa história. 
Suponha que você ganha na loteria.  Algumas dezenas de milhões de reais.  Mas o prêmio será entregue em outra cidade à 2000km de distância.  Você tem duas opções de transporte: a Ferrari Enzo ou o Fusca (vamos levar em consideração que você não está no Brasil, uma vez que não temos rodovias decentes pra suportar uma Ferrari). Cada um dos carros com um motorista.  Qual dos dois veículos você escolheria?  Parece fácil, mas tem um detalhe... um dos motoristas não sabe o caminho, além de ser um bêbado estressado (isto é só um exemplo. Se beber, não dirija!), enquanto o outro é um GPS humano e nunca colocou uma gota de álcool na boca.  Qual dos carros seria escolhido?

A resposta é: Depende em qual dos carros está o motorista bêbado e estressado. Nesse caso, a decisão não depende do carro, mas da pessoa que irá guia-lo. É bem mais seguro gastar uma semana para percorrer 2000km em um Fusca, com um motorista sóbrio, do que entrar em uma Ferrari com a certeza absoluta de que o bêbado estressado vai levar você, e talvez ele (o "motorista" quase sempre escapa), para o túmulo.

---

No mundo corporativo, é fácil encontrar equipes tão potentes quanto uma Ferrari sendo guiadas por pessoas estressadas que não sabem aonde ir. Já vi times de desenvolvimento de software de alto nível fazerem entregas pífias, bem como Sprint Reviews de times inexperientes que resultaram em pedaços de software verdadeiramente úteis.

É importante, pra não dizer essencial, que o cliente entenda que ele não é "somente" um Product Owner (dono do produto) no sentido literal da palavra.  Ele é a parte mais importante deste conjunto multi-disciplinar de elementos que envolve um projeto de software. Ele é "O Guia" do projeto. 

Agilidade vai falhar na minha empresa porque...

Em agosto deste ano, tive a oportunidade de participar do Agile 2013, um grande evento de agilidade organizado pela Agile Alliance nos EUA.

Como não poderia ser diferente em um evento como esse, conheci pessoas.  Dentre elas: Jeff Patton, Linda Rising, Jeff Sutherland, Ron Jeffries, Mike Cohn e muitos outros.  Quem estuda um pouco de agilidade, já deve ter lido algum livro ou ouvido falar algum desses nomes.  Participei de apresentações que mais pareciam verdadeiros TED Talks.  Muitos Workshops mão-na-massa e espaços para troca de ideias. Um evento diferenciado. E o hotel era um show à parte.

No entanto, o que mais chamou minha atenção no evento não foram as pessoas, apresentações ou o hotel (que repito... era espetacular), mas um painel onde os participantes escreveram frases que diziam porque agilidade iria falhar em suas empresas.

AGILE WILL #FAIL AT MY COMPANY BECAUSE... 

"Because the CEO manages with fear and Intimidation"

"Only focused on changes on development teams; Not looking at whole value Stream... "

"Because of our culture"

"No buy-in from the business"

"Because the company wears 'Agile' as a label and does nothing to remove the bureaucracy and obstacles teams face daily while trying to implement agile."

"We are different"

"Our egos are bigger and more important then the company goals"

"Insufficient support from leadership"

"Different parts of the biz use different types of agile"

"My leadership no longer believes in it..."

"It's counterintuitive and hard to practice"

"We have not explained the 'why'"

Cada uma destas frases já daria um post, mas aqui está meu ponto: Agilidade é um sentimento universal e nós não estamos sozinhos.  

O fato é que... falar, escrever e ensinar agilidade não é difícil.  Vou além, é muito fácil falar de agilidade.  Até porque (eu, por exemplo), quando discurso sobre o assunto, vejo olhos brilhando e ouvidos atentos. Agilidade é o discurso que todos gostam de ouvir, mesmo os "chefes".  O problema é que transformar todo esse BLÁ BLÁ BLÁ em prática AINDA É UM GRANDE DESAFIO, mesmo para os nossos colegas norte-americanos, onde a cultura é... digamos... mais avançada.

Quando vejo um ianque escrevendo que agilidade vai falhar na empresa dele por conta da burocracia, meu primeiro pensamento é mudar de área e ir pra medicina (se bem que a concorrência com os cubanos e a falta de estrutura pra trabalhar me fariam pesar essa decisão).

Por fim, cada vez que toco no assunto Agilidade/Cultura, tenho a seguinte certeza: 

"Ou a cultura acabará com a agilidade... ou a agilidade mudará a cultura do mundo."

Como ter uma ideia

O programa Globo Ciência do dia 12 de outubro de 2013 teve, como uma de suas matérias, o tratamento de esgoto.  Neste dia, várias ideias para tratamento foram apresentadas. Todas elas tinham um processo bem desenhado e passos bem definidos para transformar esgoto em água potável.  

Entretanto, um destes processos chamou minha atenção. A ideia do criador foi construir um dispositivo com 4 orifícios. O primeiro orifício tinha a função de receber a água do esgoto, que saía filtrada e limpa pelo segundo orifício.  Até aí, nenhuma surpresa. O que chamou minha atenção foi a função do terceiro e quarto orifícios (figura abaixo).

  

De acordo com o pesquisador, nem toda água que entrava no orifício 1 conseguia ser filtrada.  A função do orifício 3 era fazer com que a água não filtrada fizesse outro ciclo de tratamento. Em outras palavras, ela saía pelo orifício 3 e entrava no orifício 4. 

Fazendo uma análise bem crítica, nada há de extraordinário nesta ideia. Mas, pra mim, sim!  Enquanto assistia a reportagem, comecei a pensar no processo Kanban de desenvolvimento e imaginei um "dispositivo" que pudesse ser utilizado em um processo ágil para reciclagem de requisitos. A ideia seria assumir que nem todo requisito que é empurrado para nosso processo esteja "pronto para consumo". Em outras palavras, que tal ter um processo de tratamento de requisitos?  Coisa de maluco...  

Mas meu raciocínio não parou por aí. O Insight que me levou a escrever este blog teve seu ápice quando comecei a pensar sobre como eu cheguei à conclusão da criação de um dispositivo para transformar requisitos "podres" em "potáveis".  Como uma ideia leva à outra? Na verdade, a mágica (se é que existe) está na quantidade e qualidade de conhecimentos gerais adquiridos por nós, seres humanos. De fato, ter uma ideia não é algo tão difícil. Todo ser humano as têm.  O mais difícil, entretanto, é realiza-las. A realização fica mais fácil quando lemos ou conhecemos diversos assuntos.

Neste mesmo programa, um pesquisador (que era músico e matemático) apresentou um programa de computador que amplia a expressão de quem está tocando um instrumento musical.  A ideia básica do seu software era apresentar imagens ou videos no computador que representassem o som tocado pelo instrumento usado. Coisas desse tipo nos trazem à mente o seguinte pensamento: "Por que não pensei nisto antes?  É tão simples!"

Não pensei porque as ideias mais simples do mundo são resultado da combinação de vários conhecimentos. Ter uma ideia depende do quanto você ler e conhece de assuntos gerais. Qualquer pessoa pode ter ideias, mas uma pessoa que conhece música e matemática tem maior probabilidade.  Uma pessoa que conhece Kanban e aprende um pouco sobre tratamento de esgoto em uma reportagem de televisão, também. 

Em suma, se você nunca teve uma ideia simples que pudesse ser executada, ENTÃO LEIA. Estude assuntos que você nunca pensou em estudar e faça atividades que você nunca imaginou fazer! 

Depois da prática, a teoria

A última vez que publiquei um post neste blog foi em Abril de 2010.  Na época, estava falando sobre estimativas ágeis.  Passaram-se 3 anos e a experiência adquirida neste período foi consideravelmente esclarecedora.  Percebi que gastar tempo em criar estimativas perfeitas é tão útil quanto mascar chiclete; Por mais que você mastigue, jamais vai ter coragem de engolir.

Entretanto, minhas experiências foram além de apenas buscar boas estimativas.  Durante muitos meses, tive a oportunidade conhecer diversos clientes, das mais diferentes empresas.  E, apesar de querer valorizar muito os desenvolvedores e os famigerados Scrum Masters,  tive que reconhecer que os clientes são as peças mais importantes dessa engrenagem chamada projeto de software.

Como se não bastasse, também comecei a abrir os olhos para o que chamamos de requisitos de software.  E, mais uma vez, aprendi que tudo é perfeito nos livros, nas palestras, nos eventos... Mas no campo de batalha, no espaço de desenvolvimento, na sala do cliente... os fatos são bem mais complexos e nebulosos do que nossos colegas agilistas pregam.

Enfim, descobri que a agilidade teórica é tão distante da agilidade prática quanto o caos é da verdadeira auto-organização e auto-gerenciamento.  Por isso, dedico esse blog, a partir de hoje, a falar de como realmente a agilidade acontece na prática e o que aprendi com ela nos últimos anos.  E como ela realmente tem a ver com a felicidade e satisfação no trabalho e a melhoria contínua; Não de processos, mas da qualidade de vida.  E por falar em qualidade de vida, dedico este blog a alguém que, de forma extremamente ágil, melhorou consideravelmente minha qualidade de vida. Um grande beijo, minha Princesa Linda.

Que venham as postagens.  Muita coisa boa vem por aí.

Estimativa e Planejamento Ágil de Projetos (parte 1)

Este mês, vou iniciar uma série de artigos falando sobre planejamento ágil de projetos. A base para a escrita destes posts são 3:

1. O livro "Agile and Estimating Planning" (por Mike Cohn)
2. O livro "Sotware Estimation" (por Steve McConnell)
3. Minhas experiências*

* Sem dúvida alguma que a maioria esmagadora da base para a escrita destes posts virá dos livros citados acima.

Neste primeiro post, iremos falar sobre os propósitos do planejamento, porque fazê-lo e entender o que faz um planejamento ser ágil..

Começando do começo

Muitos de nós acha que fazer planejamento e estimativa é algo difícil.  Bom, estes muitos estão certos.  Planejar um projeto no início e se comprometer com um plano é algo extremamente perigoso.  Podemos visualizar essa afirmação em uma figura chamada "Cone da Incerteza" (Steve McConnell).

O eixo X mostra a linha de tempo do projeto e o eixo Y mostra a margem de erro do plano  inicial do projeto.  A medida que a linha do tempo avança, menor é a margem de erro.

Mas afinal... por que planejar?

Fazer planejamento e estimativas não é apenas ou somente uma questão de determinar uma data apropriada para entregar um produto.  Planejamento (principalmente quando lidamos com uma abordagem ágil) é trabalhar para encontrar a solução para o principal enigma a ser quebrado: O que deveremos construir?  

De fato, fazer planejamento nos ajuda a:

• Reduzir riscos no projeto
• Reduzir a incerteza no projeto (lembra do cone?)
• Fornecer suporte para melhor tomada de decisões
• Estabelecer confiança
• Transmitir informações

Ironicamente, um plano ruim é aquele que dá uma data exata para entregar o produto contratado.  

Então o que faz um plano ser bom ou ruim?
Um bom plano é aquele em que os patrocinadores do projeto podem setir confiança suficiente para usá-lo na tomada de decisões.  Por exemplo, antes de começar o projeto poderíamos fazer um planejamento que resultasse num plano que nos dissesse que o projeto não poderia ficar pronto no primeiro semestre do ano caso o número de funcionalidades não fosse menor.  Isso é uma decisão estratégica que não precisa de data exata.  

Segundo Mike Cohn, planejamento ágil tira o foco da palavra Plano e enfatiza a palavra Planejamento.  Planos são documentos estáticos ou figuras.  Eles são projeções do que nós achamos que o projeto terá no futuro.  Planejamento é uma atividade.  Ele nos ajuda a aprender no decorrer do projeto e isso nos permite diminuir a incerteza e ganhar confiança ao estimar.  Em outras palavras, o projeto ágil não tem um Plano, ele tem um planejamento contínuo.  Um plano ágil é preparado para mudar porque as mudanças são boas, uma vez que elas nos ajudam a aprender sobre os usuários e sobre o projeto.

Mesmo assim, alguém pode indagar: "Eu faço planejamento contínuo, mas mesmo assim ele falha, por quê?" 

Responderemos isso no próximo post: "Por que meus planejamentos falham?"

Grupo Scrum Fortaleza - 3o. Encontro

Aconteceu no último dia 29/03/2010 o terceiro encontro do grupo Scrum Fortaleza. Tivemos a oportunidade de conhecer o Michel Goldenberg e o Heitor Roriz, assim como rever nosso amigo Fabiano Milani.

Na ocasião, tivemos uma palestra do Michel falando sobre "Estimativa e Planejamento Ágil" ou como ele prefere dizer: "Planificação e Estimação Ágil". Alguns destaques da sua palesta:

"Se sua equipe não acredita em Reunião Diária, pare de fazer e veja o que acontece. Mas lembre... marque o dia em que deixaram de fazer."

"Existem duas maneiras de calcular prazo e custo de projeto: i) Mentindo para o cliente e ii) colocando uma baita gordura no projeto"

Depois tivemos a oportunidade de ouvir e ver Fabiano Milani falando sobre as armadilhas de usarmos Scrum.

Ao final, tivemos o Michel, o Fabiano e a presença ilustre de Heitor Roriz numa mesa-redonda-em-pé-ao-lado-de-uma-mesa-retangualar (veja as fotos). Na oportunidade o grupo discutiu sobre: importância do PO nos projetos, nova cerfifcação CSD da Scrum Alliace ...

Enfim, esse encontro reuniu ainda mais a comunidade Ágil de Fortaleza e foi nosso maior encontro, pois no primeiro encontro tivemos 28 pessoas. No segundo, 40 pessoas. E agora, no terceiro, mais de 70 pessoas presentes.

Abraço a todos e aguardem pelos próximos...

A primeira vez de Martin Fowler... no Brasil

Em entrevista feita a Danilo Sato, o cientista-chefe da ThoughtWorks, Martin Fowler, estará no Brasil para ministrar um Keynote no Agile Brazil 2010.
Seguem abaixo alguns pontos da entrevista que me chamaram a atenção:

- Quando perguntado sobre suas espectativas sobre o evento, Martin Fowler foi emblemático quando disse que depois de tantos anos participando de conferências e encontros, seria difícil se sentir empolgado pelo Agile Brazil 2010. Ele está mais empolgado em visitar o Brasil do que com qualquer outra coisa, uma vez que é sua primeira vez na América do Sul.

- Outro ponto interessante foi sua afirmação em dizer que não sabia ainda o que iria falar em seu Keynote e que isso seria uma decisão para ser tomada na noite anterior. Nosso amigo Danilo foi feliz em dizer que o Mr. Fowler é um dos poucos palestrantes que consegue preparar um keynote de um evento internacional na noite anterior.

Aqui você pode conferir a entrevista inteira.

No mais, quem puder participar do evento não perca esta oportunidade!!! Abraços.

Agiles 2009, um GRANDE evento

Nos últimos dias 08 e 09 de Outubro tivemos a oportunidade de participar do Agiles 2009 em Florianópolis (que cidade linda). Realmente um evento ímpar para a nossa comunidade e sem dúvida está entre os melhores que já tivemos no país... ou o melhor.

O evento começou com o KeyNote sensacional de Brian Marick, um dos autores do Manifesto Ágil. Seu bom humor foi o tom de sua apresentação e seu principal foco foi sempre voltado para equipes multidisciplinares, auto-gerenciadas e, sobretudo, XP.

Várias apresentações chamaram a atenção:

A primeira delas foi a simpática Diana Larsen entitulada "TRUST – THE KEY TO AGILE TEAM COLLABORATION". Os pontos fortes foram:

• É fundamental que conheçamos as pessoas antes de trabalharmos com elas
• A credibilidade é fundamental para a confiaça entre as pessoas e isso é conseguido através do compartilhamento de informações e sentimentos
• A confiança não deve estar presente apenas no time, mas na relação que eles têm com pessoas externas

Uma segunda palestra que me chamou a atenção foi de Dave Nicolette, "Agiles Project Metrics" e uma frase resume o que foi o tom do seu discursso: "Measure just the necessary, nothing more". Outra frase de Dave que me chamou a atenção foi: "Working software is the primary measure of progress".

Joshua Kerievsky também nos deu uma aula de agilidade e arte quando comparou de maneira muito feliz os diversos estágios da arte com os diversos estágios da Agilidade. Foi ele que afirmou veementemente que muitos de nós estamos fazendo software de uma forma medieval.

Uma das palestras que mais me chamou a atenção foi a de David Hussman, um cara que tem sido mentor e coach de equipes ágeis nos EUA, Canadá, Europa, Índia, Egito, Rússia e Ucrânia. Foi recentemente agraciado com o prêmio Gordon Pask Award no último Agiles em Chicago. Fez questão de dizer que é apaixonado por música e não exitou em fazer a comparação de uma banda com uma equipe ágil.

Por fim, tivemos um belo painel com os "astros" do evento: Brian Marick, Diana Larsen, Roy Singham (ThoughWorks) e Joshua Kerievsky. Não podemos deixar de dizer que essa parte do evento teve como pano de fundo o bom humor de Brian Marick, sempre ressaltando a importância das pequenas empresas na economia mundial, o que era sempre elegantemente rebatido pelo sócio-fundador da ThoughWorks, Roy Singham. Segue foto abaixo.

Da esquerda para a direita: Brian Marick, David Hussman, Joshua Kerievsky, Roy Singham (ThoughWorks), Diana Larsen.

O ponto negativo foi saber que nós, cearenses, estamos a alguns anos atrás no tocante ao desenvolvimento ágil de sistema e, principalmente, no que se refere aos paradigmas que precisam ser quebrados por nossos profissionais.

Bom, esse foi um resumo muito rápido do que foi o evento em Floripa. Abraço.

Apresentação de SCRUM na Faculdade de Juazeiro do Norte

No último dia 19/06, eu e nosso amigo Cristiano Milfont participamos de um evento em Juazeiro do Norte onde foram feitas duas apresentações, uma de XP (Milfont) e outra de Scrum (Eu), ambas disponibilizadas no Slideshare.

Fiquei realmente surpreso com o interesse da turma e com o nível de conhecimento dos participantes, que demonstraram isso com perguntas e questionamentos bastante relevantes para os temas abordados.

Infelizmente o tempo era curto para falar tudo que gostaríamos, tanto que a segunda palestra (a qual falei sobre Scrum) terminou depois das 22:00h.

Seguem abaixo os links para acessar as duas palestras
http://www.slideshare.net/cmilfont/apresentando-extreme-programming
http://www.slideshare.net/paulofurtado/palestra-de-scrum-em-juazeiro

Esperamos novos convites para voltar a essa terra tão receptiva que é Juazeiro do Norte.

2o. Curso de Certificação Scrum Master em Fortaleza

Devido ao rápido preenchimento da turma de CSM agendada para fortaleza nos dias 25 e 26 de Junho, tivemos que abrir uma nova turma de CSM (Certified Scrum Master) nos dia 30 e 31 de Julho de 2009. O evento vai ter, novamente, total apoio do CGDT (Centro de Gestão e Desenvolvimento Tecnológico) e terá como instrutor Alexandre Magno, único Certfied Scrum Trainer do Brasil (pelo menos por enquanto, :) ).

As incrições poderão ser feitas através da Adaptworks ou através do telefone (0x11) 5585-7738.

Esperamos mais uma turma cheia em Fortaleza. Abraço.

Especificação: Documentação ou Comunicação?

Esse é um tema que já causou muita polêmica e AINDA causa, como vemos em posts como "Documentação Ágil" e "E a documentação?". Poderia citar vários outros.

Entretanto, vai aqui alguns mitos sobre documentação que ainda incomodam pessoas da nossa área:

1) A documentação serve para Especificar detalhadamente o funcionamento do sistema, pois dessa forma os Analistas de Negócio repassam algumas necessidades dos usuários para os desenvolvedores enquanto trabalham na especificação de novas funcionalidades.

Mera ilusão!!! A documentação, neste caso, está servindo como um mecanismo de comunicação entre os analistas e os desenvolvedores. Eu poderia aqui citar várias referências de profissionais que aboliram esse mecanismo de comunicação a muito tempo. Mas, em vez disso, faço as seguintes indagações:

a) Como desenvolvedor, você prefere conversar com o analista e entender as funcionalidades em 2 horas de "papo" ou prefere passar o dia lendo uma especificação de caso de uso extensa e tentar interpretar o que foi dito, ou melhor, escrito pelo Analista?

b) Como Analista (seja sincero!!), você acha que conseguiu entender perfeitamente o problema do usuário para chegar ao ponto de escrever um bolo de documentos e garantir que isso não vai mudar assim que o usuário ver o que foi implementado? Além disso, temos que ser sinceros, as pessoas que escrevem documentos de especificação não são nenhum Luís Fernando Veríssimo ou um Ariano Suassuna.

c) Como Stakeholder, você se sente a vontade para esperar que toda ou grande parte da análise seja escrita para entrar em desenvolvimento e só depois ter alguma funcionalidade do sistema pronta (ou não)?

Bom, proponho aqui (isso muitos já fizeram também) algumas ferramentas que podem substituir um documento extenso de análise: Boca, mão, pincel e quadro branco. Nesse caso, até uma foto do quadro ou um rascunho no papel podem servir para comunicação das idéias por trás de uma funcionalidade e, ao final do projeto, pode-se até criar uma documentação mais formal se for o caso

2) Deve-se ter uma documentação completa para garantir que, quando os atuais integrantes da equipe sejam substituídos, seus sucessores possam ter uma referência do que foi feito.

Ótimo!!! Mas não existe melhor documentação do que um código bem feito, e isso pode ser alcançado com algumas práticas como Programação em Par e Refatoração Contínua. No entanto, se mesmo assim houver a necessidade de uma documentação, deixe para fazer ao final do projeto, pois a probabilidade de mudanças nessa documentação será mínima.


Enfim, espero que os profissionais da área de TI possam focar muito no produto final em vez de se preocupar com atividades "burrocráticas" e desnecessárias. Não somos escritores de software, somo DESENVOLVEDORES de software.

Como usar Scrum sem ser Ágil?

Depois de uma conversa com um amigo, decidi escrever este post para esclarecer alguns pontos em relação a Scrum e Agile, segundo meu ponto de vista. Antes de apresentar os pontos de interesse, vou mostrar parte deste diálogo:

Ele: "Paulo, então ficamos combinado de entregar, ao final deste Sprint, o documento inicial de requisitos e regras de negócio?"

Eu: "Seria bom nós já entregarmos algumas funcionalidades implementadas, pois é isso que prega o Scrum"

Ele: "Nada disso, o Scrum funciona para o gerenciamento de qualquer projeto e pode ter como resultado/meta um documento com os requisitos"

Alguns podem me crucificar, mas isso me fez achar que ele, de alguma maneira, tinha razão. Realmente nós podemos ter como resultado final de um Sprint qualquer produto que dê o máximo de valor para o cliente, mesmo que seja um documento.

No entanto, apesar do o Scrum ter surgido antes do Manifesto Ágil, não consigo ver seu uso (pelo menos na área de TI) sem que esteja atrelado às premissas básicas descritas no manifesto. E uma delas é: Software funcionando é mais importante que Documentação Extensa. Se o seu cliente acha que documentação é mais importante, aconselho a leitura do post "Product Owner: Um De$graçado Ganancio$o", do nosso amigo Rodrigo Yoshima.

Dessa forma, esse simples post vem deixar clara minha opnião de que Scrum não é ágil por si só. Ele precisa das pessoas certas para ser ágil. E se estas trouxerem algumas práticas da XP como TDD, pair programming, integração contínua e o que eu chamo de AQA (Agile Quality Assurance), melhor ainda.

Confirmado primeiro curso de Certificação Scrum Master no Ceará

É com grande satisfação que comunico a todos que o primeiro curso de CSM (Certified Scrum Master) no Ceará ocorrerá nos 25 e 26 de Junho de 2009. O evento vai ter total apoio do CGDT (Centro de Gestão e Desenvolvimento Tecnológico) e terá como instrutor Alexandre Magno, único Certfied Scrum Trainer do Brasil (pelo menos por enquanto, :) ).

As incrições poderão ser feitas através da Adaptworks ou através do telefone (0x11) 5585-7738.

Esperamos turma cheia em Fortaleza. Abraço.

Hoje eu começo

Em breve estaremos postando diversos assuntos interessantes neste blog.

AGUARDEM!!!