O design está morto?

Começo com esse post a tradução de um dos melhores artigos que conheço a respeito de design ágil de software: "Is design dead?" do Martin Fowler.

Vou traduzir o texto em vários posts, para preservar um pouco do meu tempo, e pra adaptar o discurso longo a um formato mais curto, mais apropriado ao blog.

Para os que já conhecem, é uma ótima oportunidade para recordar. Pra quem nunca leu, meu conselho é que corra logo e leia a versão em inglês no blog do autor (que com certeza é bem melhor que a minha tradução).

Mas se ainda não mexi com sua curiosidade o bastante para vencer a preguiça, acompanhe a série de posts que farei aqui, ou espere até o final da tradução e confira o texto completo, que será publicado junto às outras traduções.

Se por acaso alguém achar que a tradução não ficou boa, e quiser deixar alguma sugestão, será muito bem vinda nos comentários.

Vamos à seção que introduz o artigo, apresentando sua questão central.

(apenas a titulo de registro, estou traduzindo a versão de maio de 2004)

Para muitos que têm seu primeiro contato com Extreme Programming, parece que XP prevê a morte do design de software. Não somente a maioria das atividades de design é ridicularizada como "Big Design Up Front", mas ainda técnicas como UML, frameworks flexíveis, e até mesmo design patterns são pouco enfatizadas ou totalmente ignoradas. Na verdade XP envolve muito design, mas o faz de um modo diferente dos processos de software estabelecidos. XP rejuveneceu a noção de design evolutivo com práticas que tornam a evolução uma estratégia de design viável. Ela também apresenta novos desafios e habilidades já que os designers precisam aprender como fazer um design simples, como usar refactoring para manter um design limpo, e com usar patterns em um estilo evolucionário.

(Esse artigo foi escrito para minha apresentação na conferência XP 2000 e sua forma original foi publicada como parte dos anais.)

* Design planejado e evolucionário
* As práticas habilitadoras de XP
* O valor da simplicidade
* O que diabos é simplicidade, afinal
* Refatoração viola YAGNI?
* Patterns e XP
* Cultivando uma arquitetura
* UML e XP
* Sobre metáforas
* Você quer ser um arquiteto quando crescer?
* Reversibilidade
* A vontade de projetar
* Coisas que são difíceis de refatorar
* O design está ocorrendo?
* Então o design morreu?
* Créditos
* Histórico de revisões

Extreme Programming (XP) desafia muitas das suposições sobre desenvolvimento de software. Uma das mais controvérsas é sua rejeição a esforços significativos em design prévio, em favor de uma abordagem mais evolucionária. Para seus criticos isso é um retorno ao desenvolvimento "code and fix" - normalmente conhecido como hackear. Para seus fãs é frequentemente visto como uma rejeição das técnicas de design (como a UML), princípios e padrões. Não se preocupe com design, se você escutar o seu código um bom design surgirá.

Eu me encontro no centro desse argumento. Grande parte da minha carreira envolveu linguagens gráficas de design - a linguagem de modelagem unificada (UML) e seus precursores - e padrões de projeto. Eu escrevi livros sobre ambos: UML e patterns. O meu envolvimento com XP significa minha renúncia ao que escrevi sobre esses assuntos, livrando minha mente de todos esses conceitos contra-revolucionários?

Bem, não vou conseguir mantê-los nesse suspense. A resposta curta é não. A resposta longa é o resto desse artigo.

A resposta longa será publicada aqui, seção por seção.

Continue lendo a segunda parte: Design planejado e evolucionário

Agile and The Matrix

Foi lendo o Fragmental que me deparei com essa comparação, em um dos comentários:

Por fim, quem já viu o “making the matrix” que vem no DVD do Matrix? O produtor (GP) explica como eles conseguiram fazer o filme a um custo tão baixo. Porque os diretores conseguiram ver todo o filme no storyboard. Não precisaram ir filmando para irem apurando a idéia. Foi um Waterfall. Matrix!

Adoro analogias, mas também acho que essa deixou um pouco a desejar. A resposta do Philip, sintetizando bem grosseiramente, foi:

- Documentos são caros;
- É difícil prever o futuro;
- Filmar é muito caro, pode valer a pena o preço para tentar adivinhar o futuro;
- Software é flexível;

Não descordo de nenhum dos pontos dele (embora tenha achado o terceiro meio confuso), mas gostaria de fazer as minhas considerações também. Como adoro analogias, achei que o assunto merecia um post só pra mim. ;-) [ licença Philip, licença Augusto. ]


O meu ponto de vista:

Em primeiro lugar, não acho que o story-board por si só configure um waterfall. Story-boards são uma ferramenta maravilhosa, pois conseguem expressar o projeto de forma âmpla. Mas apenas de forma âmpla, não detalhada.

Os detalhes serão, sim, pensados just-in-time. Quanta luz será usada? Incidindo em que posição/direção? Como os atores devem se posicionar? Devem falar essa frase mais ou menos rápido? Com que expressão? Com que tom de voz? E o penteado? Muitos e muitos detalhes são deixados pra última hora, não tem jeito. Ninguém consegue imaginar todos os detalhes com antecedência. E nem seria muito inteligente fazer, pense um pouco...

Esse não é um caso BDUF (Big Design Up-Front), mas de EDUF (Enough Design Up-Front). A diferença é sutil. (Engraçado, olha o primeiro resultado que o Google traz para enough: good enough)

O Philip escreveu que, "[no caso do filme,] pode ser mais barato pagar o preço de tentar adivinhar o futuro e modelá-lo completamente em uma ferramenta gráfica." Mas acho que, no caso do software, o problema é ainda mais crítico. Pois um pequeno detalhe, descoberto em cima da hora, pode acarretar uma mudança gigantesca no custo do projeto (guardadas as proporções).

É como se, na hora de analisar a iluminação da última cena, descobríssemos que o filme todo precisará ser filmado novamente porque senão ninguém vai assistir o filme, e o dinheiro terá sido praticamente jogado no lixo.

No caso do filme, é até difícil imaginar um cenário desses. Mas em software, esse tipo de coisa acontece praticamente todo dia. Não há como evitar as mudanças, pelo menos se estamos querendo desenvolver algo que realmente tenha qualidade, no sentido de maximizar o retorno do investimento.

O problema é mais simples que isso: não dá pra adivinhar o futuro e pronto. Não importa quanto dinheiro se esteja disposto a gastar.

Se não podemos prever as mudanças, e evitá-las é contra-producente (pra não dizer estúpido), a única solução possível é se preparar para a adaptação às mudanças (Embrace Changes): um dos pilares do desenvolvimento de software moderno.

Scrum funciona sem XP?

Fui ouvir falar de Scrum bem depois de já ter batido muita cabeça tentando convencer as pessoas a usarem XP. Parece que de uma hora pra outra todos os mesmos conceitos que causavam pânico a qualquer gestor derrepente se tornaram moda. É como se o diabo tivesse sido promovido a arcanjo da noite pro dia, só porque mudou de nome (e de roupa). Não tenho dúvidas, Scrum é muito mais "vendável" que XP. Agora, cá pra nós, dá pra aplicar gerenciamento ágil com segurança sem usar práticas de desenvolvimento que o suportem?

Mesmo que se afirme que o Scrum tenha sido criado antes do XP, não foi assim que vi as coisas acontecerem aqui no Brasil. De um jeito ou de outro, não é esse o ponto central nesse post. Também não quero entrar no mérito sobre o Scrum tratar-se de uma disciplina mais âmpla, aplicável a outras áreas, além do desenvolvimento de software. Pretendo menos ainda atiçar uma disputa entre os dois ou dizer que "XP é melhor do que Scrum" ou outros maniqueísmos babacas (com o perdão da(s) palavra(s)).

Então a relação mais simples a se delinear entre esses dois, sob o ponto de vista de seus conteúdos, me parece ser:


E sob esse ponto de vista XP seria mais âmplo que Scrum. Mesmo porque as práticas de planejamento do XP são, em sua essência, Scurm - puro e escarrado. A menos de certos detalhes (ao meu ver) irrelevantes, não há o que tirar nem pôr.

Agora, falando especificamente sobre desenvolvimento de software, me parece arriscadíssimo aplicar o gerenciamento ágil sem técnicas como desenvolvimento orientado a testes, integração contínua, refactoring, etc.

Como posso me dar ao luxo de deixar o cliente escolher a ordem em que as funcionalidades serão desenvolvidas, ou permitir que a equipe levante os detalhes do sistema just-in-time, na hora de codificar?

Não há como implementar um software dessa forma sem se deparar volta e meia com algum detalhe que não havia sido pensado, suposições erradas a respeito do negócio, modelagens incoerente e outros mal entendidos. Aprendizado é uma palavra-chave aqui, certo?

Trabalhar dessa forma, portanto, pressupõe que o design do código volta e meia terá que passar por algumas "reformulações" (como se traduz refactoring mesmo?). Mas como pode uma equipe (de seres humanos) mexer na estrutura de um sistema poucos dias antes de uma entrega de um produto que deve estar "em qualidade de produção", relativamente sem bugs?

Alguém se arriscaria a mudar o modelo relacional do banco de dados de uma aplicação crítica, que já está em produção, e deve permanecer lá, sem erros, depois do upgrade daqui a duas semanas? Ou melhor: alguém se arriscaria a uma coisa dessas sem ter uma bela suite de testes automáticos pra dar segurança?

Costumo dizer que programar sem testes automáticos é o mesmo que um eletricista mexer em um painel de disjuntores sem ter as emendas dos cabos isoladas com fita. Vc botaria a mão ali?


Sinceramente, não me parece seguro aplicar Scrum a um projeto de software sem testes automáticos, integração contínua, design incremental, refactoring, e programação em par.

Na verdade, não me parece seguro aplicar coisa alguma sem isso! Não é privilégio do Scrum, claro.

Meu objetivo não é "falar mal" do Scrum. Como li n'alguma coisa do ViniciusTelles (não lembro onde), "não tenho nada contra Scrum. Adoro Scrum! Tanto que o uso como metodologia de planejamento em meus projetos XP" (ou alguma coisa parecida com isso).

O que me deixa "encafifado", simplesmente, é que é muito comum as pessoas se apaixonarem por Scrum e morrerem de preconceitos de XP. Como pode?

(Veja também minha opnião sobre Agile x PMBok & cia)

PMBok x Agile: análises e manuais

Aqui estou com o "CMMI - Guidelines for process Integration and Product Improvement" na minha frente, tendo acabado de ler o excelente post do Willi sobre PMBok e Agile. (Me lembro agora como fiquei impressionado com a estruturação desse livro. Cada referência é feita com uma precisão cirúrgica. Cada coisa tem um código, cuidadosamente atribuído e utilizado para remeter aos tópicos citados. )

A discussão sobre se "é possível aplicar PMBok/RUP/CMMI/MPS.Br com Agile" não faz mesmo muito sentido, no fim das contas. Todas essas siglas do time das metodologias tradicionais, não passam de diferentes visões a respeito do processo de desenvolvimento. Tratam-se de modos diferentes de se entender um "mundo" específico: o de projetos de desenvolvimento de software (Eu sei, não se aplicam apenas ao desenvolvimento de software, mas isso não é importante agora).

Modo de entender também específico, diga-se de passagem. São visões essencialmente analíticas, que procuram clarear as coisas "destrinchando" ou "separando" seus elementos, numa estratégia "dividir e conquistar". O oposto seria o entendimento sintético, onde se parte de vários elementos e compõe-se um todo, como fazemos ao concluir um texto: juntamos tudo o que foi dito para se reconstruir a idéia geral novamente.

Sob esse ponto de vista, conjuntos de conhecimento como PMBok e CMMI seriam muito bem apresentados em um MapaMental.

(conteúdo tirado da wikipedia)

Cá pra nós, trata-se de uma bela análise de todos os elementos necessários à grande maioria dos projetos de software. Alguns vão descordar com o meu "necessário". Muitas dessas coisas podem não ser realmente necessárias... Será? Peguemos alguns elementos como exemplo.

• Controle de mudanças do escopo

"Ora, em meu projeto ágil eu não preciso fazer controle das mudanças do escopo."

Como não? E o que é que estamos fazendo quando não permitimos, de jeito nenhum, mudanças no backlog ao longo de um sprint? Só permitimos que novas tarefas entrem no planejamento a partir de uma reunião com toda equipe. Pra que? Pra que se possa controlar as mudanças no escopo, oras. Se a equipe não tiver controle sobre as mudanças no planejamento, não poderá lidar com elas.

• Gerênca de riscos

"Não tenho um plano de riscos em meu projeto ágil."

Pode ser. Mas dizer que não há gerência de riscos já é demais. Os riscos são gerenciados o tempo todo. Pelo product owner ao escolher histórias durante o planejamento; pela equipe ao estimar; pelo coach ao cultivar a disciplina em se escrever testes automáticos. Todos avaliam os riscos de cada passo ao longo do projeto.


Dê uma olhada na estrutura de tópicos desses livros. São análises extremamente detalhadas, completas e estruturadas. Trata-se de um trabalho de mestre. Identificar, estruturar e descrever cada um desses elementos foi sem dúvida um trabalho notável e de grande valor para nossa indústria. Obrigado.

O problema não está exatamente na análise que essas abordagens fazem. As análises são espetaculares. O problema é que, no dia a dia de um projeto, essas análises são inúteis.

É como comprar um manual de direção de automóveis que faz uma análise detalhada de todas as técnicas para se apertar a embreagem, o momento ideal para se passar as marchas, etc. Por mais detalhado e acertado que esteja o manual, não ajuda nada levá-lo no colo na hora de dirigir. Nem adianta estudar cada detalhe e tentar lidar com tudo de uma vez.


No momento de dirigir, o que importa não são os detalhes, mas o todo. Tentar visualizar, compreender e controlar cada um dos elementos envolvidos é ao mesmo tempo inútil e desgastante. É coisa demais.

Isso nos leva diretamente ao argumento do Willi. Ninguém disse que se precisa aplicar tudo o que está nos livros. Pelo contrário, os capítulos iniciais de todos eles afirmam categoricamente que tudo deve ser adaptado, escolhido, filtrado. O problema é que nenhum deles explica como as coisas devem ser escolhidas, nem tampouco adaptadas. As práticas precisam ser modificadas para o seu projeto especificamente. Mas como? Problema seu.

Dessa forma, a leitura subliminar que se faz é que os projetos devem ser gerenciados sob todos os aspectos. Quanto mais detalhes se consegue visualizar e documentar, mais maduro seu processo é. Sobre isso cria-se uma escala de mérito totalmente deturpada, baseada em inspeções, avaliações, provas, exames e outras atrocidades. Elementos artificiais, que contribuem apenas para enviesar ainda mais o processo de melhoria, cuja preocupação maior passa a ser o certificado que se ganha no final. (Não me parece muito um sinal de maturidade... :-/ )

XP e Scrum, ao contrário, não fazem leituras analíticas. Lidam com questões práticas que se sustentam através de uma cadeia de valores explícita e coerente, reflexo das necessidades reais de projetos reais. Você adora cálculos geométricos complicados e instrumentos de precisão. Ótimo, mas para levantar a parede reta seu pedreiro precisa é do fio de prumo.


Pra ser honesto, no livro mais importante sobre XP (na minha opnião), KentBeck faz também uma leitura analítica: XP divide-se em valores, princípios e práticas. Mas veja que nesse caso não se trata de uma análise do processo de desenvolvimento em si. A análise feita refere-se ao modelo de pensamento utilizado para sustentar as práticas.

Essa sim é uma análise relevante. Ela privilegia não uma visão específica de como se deve fazer software, mas uma estrutura de decisão que nos auxilia a definir como as coisas devem ser adaptadas em cada caso. Diferentemente dos livros citados acima, aqui a forma como as coisas devem ser adaptadas é clara e coerente.

O próprio Kent Beck ressalta que os princípios apresentados em seu livro não são os únicos possíveis. Organizações particulares podem cultivar outros valores, outros princípios. E elas devem fazê-lo! O que se coloca é que se deve utilizar uma cadeia de raciocínio análoga para se definir como deve ser o dia a dia dos projetos. Entenda seus valores, expresse seus princípios e deles derive as práticas a serem seguidas.

"Para dirigir, use as duas mãos ao volante." Isso expressa o princípio da direção defensiva, que se sustenta sob o valor Segurança. Agora, se prefere cultivar o valor do Conforto, então deixe o braço esquerdo escorado na janela, é muito melhor. Qual dos dois valores é mais importante agora? Eis um framework para tomada de decisões realmente útil.

Então, sintetizando :-) , o problema de PMBok/RUP/CMMI/MPS.Br não está exatamente na análise que é feita, mas na leitura (propositalmente?) induzida de que se tratam de manuais de direção. Não são. São instrumentos teóricos maravilhosos. Mas se vc está interessado em dirigir bem, deixe-os em casa e veja as coisas da forma ágil.

Profissão: analista de sistemas

Quando me perguntam por aí qual a minha profissão, ou quando preciso responder isso em algum formulário “genérico”, costumo responder: Analista de Sistemas. É uma resposta também “genérica”, rápida, que não exige maiores explicações e satisfaz a maioria das perguntas - normalmente feitas apenas por obrigação.


Embora seja um termo meio “genérico” demais - e até obsoleto sob certos pontos de vista - ainda o utilizamos em muitos contextos, como no debate sobre a regulamentação da profissão. Não pretendo aqui entrar no mérito dessa discussão, mas refletir sobre o significado do termo em si, questão um pouco mais fundamental, cuja reflexão pode alimentar e influenciar opniões sobre o assunto.

Afinal, o que faz um analista de sistemas? Ora, se interpretarmos ao pé da letra, deve ser alguém que estuda sistemas e o divide (corta, quebra) em outros menores, mais simples, para que se possa compreendê-los mais facilmente. Não é difícil encaixar nessa definição alguns papeis e funções que costumamos ver em projetos de software tradicionais.

O “analista de requisitos” esclarece os detalhes de um dado domínio, através de modelos, diagramas e descrições. Seu “sistema” são os processos do cliente. O arquiteto analisa o problema em módulos, componentes, camadas, e outros recortes. Seu “sistema” é um programa, (ou vários) visto como um todo. O programador divide cada funcionalidade e operação em funções, procedimentos, estruturas de dados e instruções.

A visão tradicional de um analista de sistemas passa, de um modo ou de outro, por um desses aspectos. Ou por todos ao mesmo tempo, considerando-os especializações, ou rumos a se seguir dentro da profissão. Enxerga “o sistema”, portanto, como toda essa “coisa” que automatiza (informatiza) os processos do cliente.

Em metodologias ágeis costumamos identificar um número menor de papéis, ou especializações, criado uma visão mais holística de equipe, que ressalta valores como interdisciplinaridade, auto-organização, habilidades sociais, lideranças, etc.

Mas, se por um lado tem-se menos tipos de “analistas”, por outro enxergamos mais “sistemas” a serem analisados, compreendidos e geridos. Ou pelo menos um sistema mais completo, que vai além dos saberes técnicos que são ensinados nas faculdades de tecnologia - cursos focados em teorias e técnicas matemáticas, exatas, objetivas.

Essas metodologias reconhecem outros sistemas extremamente relevantes aos processos de desenvolvimento. Aspectos humanos e organizacionais, jogos de intenções e interesses, forças políticas, estruturas sociais e questões motivacionais. Um emaranhado de fatores que compõem o ambiente e a cultura da empresa, e que fazem parte do inconsciente coletivo da equipe. Questões importantíssimas e determinantes para o sucesso de qualquer projeto.

Um arquiteto pode estar mais preocupado com seu ego do que com o bom andamento do projeto, ao propor uma solução complexa demais; um gestor pode estar mais interessado em seguir uma tendência de pensamento com que sua gestão já se comprometeu; um programador pode não tirar uma dúvida importante de projeto com o cliente pela estrutura de comunicação que se criou; ou pode não sinalizar sobre um problema que identificou no design por causa de sua baixa auto-estima junto à equipe.

O desenvolvimento de software é acima de tudo uma atividade criativa, de aprendizado coletivo e de auto-conhecimento para todos: clientes, usuários, programadores. Ao mesmo tempo que a equipe está aprendendo os detalhes tecnológicos envolvidos na solução, usuários estão aprendendo a ver de forma mais clara seus processos de trabalho. A equipe como um todo (incluindo cliente e usuário) está aprendendo a se comunicar e a colaborar para desenvolver uma visão única e coesa do “sistema”, aprimorando seu processo de trabalho a cada dia (melhoria contínua).

Sob esse novo ponto de vista, a expressão “analista de sistemas” ganha uma conotação integral, levando em conta um sistema mais âmplo, que precisa ser não apenas analisado, mas percebido, compreendido, refletido e gerido.

Programação em par

Essa talvez seja a prática mais demorada de se aprender em XP. Não que seja extensa ou complicada. Nada disso.


A questão é que, para se compreender a prática de verdade, é preciso primeiro acreditar nela.

O pensamento mais imediato, claro, é sempre imaginar que se gasta o dobro para realizar a mesma tarefa. Esse pensamento não está certo. Porque a programação é uma tarefa criativa e não respeita à lei "quanto mais gente, mais trabalho se realiza". Nesse caso, a qualidade do código produzido interfere muito na produtividade dos próximos passos. Então vale muito mais a pena "gastar" o dobro da atenção sobre cada parte dele.

Não é fácil argumentar sobre isso, nem é esse o meu propósito aqui. Quem já experimentou programação em par "na veia" vê isso com uma clareza impressionante. Mas pra quem está iniciando, acreditar nisso não é tão natural.

Quanto mais se acredita, melhor se pratica. Quanto melhor se pratica, mais se acredita. Mais um ciclo virtuoso que costuma estar presente em XP.

Aqui está um screencast muito interessante pela própria "inovação tecnológica" da idéia. Mais interessante ainda pela forma como consegue expor uma seção de programação em par tão de perto. Quase que se participa dela. Impressionante!

(Sugestão: assista em full-screen)


Cola: Real-Time Shared Editing from Mustafa K. Isik on Vimeo.

A programação em par, quando acontece fluida, assemelha-se muito a uma conversa, ou uma seção de design, onde se discute a modelagem do sistema com papel e lápis. Se a programação for guiada por testes ainda por cima, aí é que a coisa fica bonita!

Alguém se habilita pra gravar algumas seções com foco mais metodológico que tecnológico, usando TDD, BDD, etc.?

AgilDF, reunião 2

Na última sexta-feira, dia 20/06/2008, fizemos nossa segunda reunião presencial do grupo AgilDF. A reunião foi ótima! Alguns bons indicativos que posso citar de antemão são a participação, que dobrou desde a última reunião (éramos mais ou menos 15 dessa vez) e o horário de término da reunião, que prolongamos por uma hora sem nem perceber (acabamos às 22:00 ao invés das 21:00 e ainda ficamos conversando lá embaixo mais uns 15 ou 20 minutos).

A reunião aconteceu mais uma vez na SEARCH, na sala de treinamentos deles que é ótima! Conversamos em volta da mesona oval... Muito bom! Valeu Ricardo, valeu SEARCH !!!

Vou descrever em linhas gerais o que conversamos, mas é bem provável que eu esqueça alguma coisa, já que estou me baseando nos rabiscos que fiz durante a conversa. Por favor, complementem nos comentários!

A reunião foi marcada pras 19:00, mas como o pessoal foi chegando aos poucos, a conversa foi começando informalmente e encorpando enquanto o pessoal chegava. Nesse começo, a conversa ficou um pouco em torno de perguntas em torno das experiências que estamos tendo na SEA, acho que porque somos os únicos que estamos divulgando por enquanto. :-)

Entre 19:30 e 20:00 o Giovani achou por bem intervir e organizar um começo mais formal para a reunião. Fizemos uma rodada de apresentações, onde cada um falou seu nome, onde trabalha, qual sua posição na equipe, as experiências que já teve e que interesses tem no encontro e no grupo, em geral.

O levantamento que ficou anotado na minha folha de papel foi:

Banco Central:

• Giovani;
• Marcio;
• Cristiano;
• Djalma;
  

Search:

• Ricardo;

Min. Previdência

• Cristopher;

MPU

• Ronald Tetsuo;
• Ranieri;

Min. Transportes


• Derlon;

Lumi

• Waelson

Stephanini @ STF

• Jusmar

SEA

• Bruno (eu);
• Renato Willi;
• Ana Carolina;
• Euler;
  

(Errei algum? Esqueci alguém? Alguém quer um link? deixem comentário...)



Pela minha percepção, tirando nós lá da SEA (que já andamos falando bastante do nossos casos), o pessoal da SEARCH está bem encaminhado, com uma equipe de umas 15 pessoas evoluindo bastante com reuniões de planejamento e testes automáticos; e a equipe do Cristopher que tb estão usando bastante coisa de Scrum.

Além disso, o pessoal do Bacen já teve alguma experiência com XP, estão bastante desanimados com a situação atual (RUP/Praxis/Cascatão) e avistam algumas boas oportunidades para começar um projeto piloto por lá. (Boa sorte, contem comigo (concosco) e vamos acompanhar!);

Lembro tb do caso do MPU, onde já fizeram algumas tentativas (com Scrum né?), mas parece que a bola deu uma baixada. Vamos levantar ela de novo!

Mais algum caso que esqueci?

Depois disso, íamos organizar algum assunto específico pra discutir, mas a conversa se deixou levar pelos ímpetos do pessoal. Deixamos rolar.

Conversamos sobre as restrições que os contratos tradicionais criam, atrelando o pagamento de parcelas a entregas de documentação, assunto puxado pelo Jusmar. A conversa evoluiu para contratos em geral, acordos baseados em PCU, etc. e depois foi pra processos e resistências das estruturas sociais que já existem nas "corporações" por aí (o pessoal do PMI, CMMI, RUP e ouras letrinhas...)

Reservamos os últimos 15 minutos pra conversar sobre o formato das próximas reuniões. Em suma, decidimos que vamos variar o local e o horário. O Ricardo sugeriu de fazermos um encontro aos sábados, em volta de uma churrasqueira (eu gostei da idéia). Vamos sempre fazer uma equete e decidir na lista.

Concordamos com uma periodicidade inicial de aproximadamente um mês, enquanto tivermos assunto e quórum.

Levantamos alguns temas para serem discutidos. Como bons agilistas que somos, vamos priorizá-los na lista e escolher os dois mais interessantes para a próxima reunião. Os temas que anotei foram:

• Testes automáticos;
• Contratos;
• Design evolutivo;
• (eu que propus esses três primeiros, pra “abrir a porteira”)
• Testes de aceitação com Selenium (Caso SEA@Aeronáutica. Fiquei de escrever um blog antes)
• Retrospectivas;
• Estimativas;
• Caso Bacen - dificuldades, oportunidades, etc.

Essa é apenas a lista que levantamos lá na hora. Vamos aprimorar ela na lista. Acho que a próxima reunião promete! :-)

Comentários?