No dia 22/08 último eu participei da abertura da I Semana de Computação da CJr/UnB fazendo uma palestra motivacional com o título "Somos quem queremos ser. Sonhos que podemos ter."  No geral, o objetivo da chautauqua era o de abrir o olho da molecada para um outro lado da moeda, não tão valorizado principalmente pela mídia brasiliense, concurseira de plantão. Foram quase 3 horas de conversa que passaram voando. Se um daqueles estudantes tiver coragem de fazer sua própria história, já terá valido a pena. 

Na história da SEA, já quisemos nos comparar a várias outras empresas de mercado. Entretanto, o tempo passa, a gente amadurece e a cabeça muda. Hoje, acho que se fosse para enumerarmos alguma empresa brasileira com a qual a SEA se simpatiza,  filosoficamente falando, seria a ImproveIt. Coincidência ou não, uma semana após minha apresentação na UnB, o Vinícius Teles, figura carimbada da blogosphere, publicou um post que tem tudo a ver com um discurso super recorrente nosso. Permita-me, Vinícius e ImproveIt, a transcrever alguns trechos aqui. Economiza-me palavras.

"Este post tem muito a ver com o que irei falar no Rails Summit Latin America dentro de algumas semanas. Tem a ver com empreendedorismo e paixão. Tem a ver com parar de reclamar do chefe chato, da empresa babaca, do trabalho entediante e criar uma história de vida melhor para si mesmo.
(…)
Acredito que há poucas chances de ser realmente bem sucedido quando você não ama o que faz. Por uma razão muito simples: não há menor chance de você se dedicar e se aprimorar incansavelmente em um assunto que não lhe interessa. Ter sucesso envolve várias coisas, mas, na minha opinião, há uma que é a base de tudo: paixão. Para ter sucesso, ou você é apaixonado pelo que faz, ou você é absurdamente apaixonado pelo que faz. Não há outra opção e ponto final. Aliás, na SEED3, essa era a mensagem cristalina que cada um dos apresentadores nos deu. Se quiser fazer sucesso e se dar muito bem, você tem que seguir sua paixão.
(…)
Fico muito triste quando vejo as pessoas fazendo concursos ou se candidatando para trabalhos que elas detestam, mas pagam razoavelmente. Elas preferem passar a vida lamentando pelo trabalho que têm, só porque terão alguma "segurança financeira". O que elas não compreendem é que, se fizessem o que realmente amam, teriam muito, muito mais chances de não apenas ter segurança financeira de verdade, como também poderiam ganhar muito melhor e ter uma vida mais satisfatória. Tem muita gente que se vende barato demais!

Sim, empreender é arriscado. Mas, acredito que passar a vida fazendo o que não gosta é muito mais arriscado. Acredite, fazer o que gosta é a opção menos arriscada e a que tem as maiores chances de gerar retornos significativos em todos os sentidos: dinheiro, felicidade, realização e tantos outros."

Fonte: http://blog.improveit.com.br/articles/2008/08/27/receita-do-sucesso-fazer-o-que-voce-ama

Assino embaixo.

[]s

Na última reunião da AgilDF, fiquei de escrever um pouco sobre nossa experiência com testes de aceitação escritos com Selenium. O Rafa escreveu sobre os detalhes técnicos de se colocar os testes pra funcionar, mas fiquei achando que faltou descrever um outro lado, mais relacionado com as dúvidas que o pessoal trouxe na reunião:

De que forma os testes podem funcionar como documentação?

Como escrever os testes selenium antes de codificar as telas e o fluxo?

Que testes são necessários?

Como/quando/quem deve escrevê-los?

Vou tentar responder a todas as questões de uma vez, descrevendo a forma como estamos fazendo no Sigadaer. Não estou dizendo que essa é a forma correta, ou melhor forma, nem nada disso. (Tenho um outro post sobre isso, aguardem.) O que será descrito aqui trata-se apenas da forma como a coisa se desenvolveu no nosso projeto, no nosso cliente, com as nossas restrições, e da forma como a nossa criatividade mandou.

Inicialmente, vale lembrar que a terceira pergunta (quais testes) foi um dos grandes motivadores para evoluirmos nosso esquema de testes. Levantou-se em uma reunião de retrospectiva como essa que alguns bugs não haviam sido detectados pelos testes. Discutimos um pouco e chegamos à conclusão de que haviam faltado alguns cenários de teste.

Até então, havíamos combinado escrever apenas um teste selenium por cenário, exercitando o “caminho feliz” daquele caso. Isso porque a maior parte da equipe ainda estava engatinhando com a técnica de testes, com o selenium, com o sistema, e - porque não dizer - com o cliente. Achamos que é mais fácil aprender uma coisa de cada vez.

Depois de algumas iterações, a questão surgiu sozinha, de dentro da própria equipe. Precisávamos que a Valeska ou o Souto (nossos product-owners) descrevessem o cenário. Mas como pedir, por exemplo, para o Souto colocar as mãos no código e testar a aplicação? Não rola… Então decidimos que, antes de se começar cada novo cartão, a equipe deveria chamar um dos dois e levantar os cenários de teste um a um, anotando num papel de rascunho ou então escrevendo direto em comentários no código, desse jeito:

Esse código é real e foi extraído do código fonte no dia em que levantamos os cenários. Na verdade, como dá pra perceber, não tem praticamente nenhum código aí. Apenas comentários que refletem exatamente o que o usuário nos disse. Depois, com toda calma, o pessoal, enquanto programa a funcionalidade, vai preenchendo esses métodos com código de verdade, até que no final da iteração o mesmo arquivo acaba ficando assim:

E esse teste, no final da iteração executa e prova que a funcionalidade foi corretamente implementada. Melhor ainda: esse teste vai executar umas 10 vezes por dia, garantindo que isso não para de funcionar à medida em que programamos coisas novas ou reestruturamos o código todo porque não estávamos satisfeitos com o design do código.

No final, ainda conseguimos gerar o javadoc das classes e ter uma documentação detalhada de tudo o que os testes estão cobrindo. Ainda não chegamos ao ponto de um rpec ou de um fitnesse em termos de geração de documentação a partir dos testes, mas já está muito bom. O principal recado é esse: não se preocupe em acertar de primeira, faça o seu melhor hoje e faça amanhã melhor do que fez ontem (MelhoriaContinua).

Espero que tenha dado uma boa visão de como os testes têm nos ajudado nesse e em todos os outros projetos. Hoje consideramos que a disciplina de testes é o carro chefe do sucesso dos nossos projetos. Citando o GuilhermeChapiewski, “nosso lema é qualidade - nós não viramos noite e mesmo assim entregamos software no prazo, testado e funcionando muito bem, obrigado.” Por isso, aliás, é que consideramos fundamentais iniciativas como o DojoSEA!

Aproveito pra deixar o link desse artigo do DaniloSato sobre testes de aceitação com que esbarrei agora sem querer no blog do Guilherme, procurando a referência acima.

Muito se ouve sobre Arquitetura de Informação (AI) e Design no meio tecnológico, mas pouco se entende sobre eles.

Esse termo AI, tem duas vertentes: uma filosófica que busca as estruturas da informação no meio social e psicológico, e outra que se ocupa com as estruturas aplicadas aos meios de comunicação e divulgação da informação.

A segunda vertente aparece principalmente quando se trata de desenvolvimento de softwares, mas não é claro como essa disciplina é aplicada na obtenção do melhor resultado para o usuário final.

No momento não vou expor todos os conceitos sobre esse assunto, mas prometo voltar em breve com mais explicações.

Agora vou mostrar a utilização de uma das dinâmicas usada para se obter uma boa AI em uma Intranet, o Card-Sorting.

O Card-Sorting é uma técnica usado para descobrir a classificação da informação a partir do ponto de vista dos usuários. Com ele o Arquiteto de Informação consegue obter uma visão de como o usuário organiza e distribui a informação em sua mente.

O funcionamento básico desse método consiste em levantar as informações essenciais que podem ser usadas pelo usuário em um determinado contexto, distribuir essas informações em cartões e propor para os usuários que organizem esses dados conforme seu entendimento.

Para auxiliar a dinâmica, devem ser apresentados alguns cartões com propostas de categorias para as informações, assim o usuário pode ter uma idéia de como agrupar o conteúdo apresentado, é bom deixar disponíveis alguns cartões em branco para que eles escrevam novos agrupamentos ou insiram novas informações ao seu conteúdo.

Este método pode variar um pouco, exemplo: se não soubermos ao certo qual o conteúdo que deve ser apresentado, podemos ter um momento de sugestões, sendo que cada sugestão vai sendo anotado nos cartões que deverão ser agrupados e organizados.

Os agrupamentos geralmente obedecem as seguintes definições: agrupamento por similaridade ou por contexto de uso.

A organização do agrupamento pode adotar o grau de importância ou ordenação alfabética.

Em um dos projetos da SEA no governo do Distrito Federal, realizamos um Card-Sorting para organizar as informações contidas na atual Intranet da instituição. Levantamos 77 itens de conteúdo que estavam organizados em 10 categorias, na estrutura do cliente.

Existia uma grande dificuldade por parte deles em organizar essa quantidade de conteúdo.

As maiores dificuldades eram que alguns dos 77 itens eram desconhecidos pelos participantes e parte das informações não era atualizada a mais de 3 anos.

Para a realização do Card-Sorting, foi disponibilizado alguns cartões em branco para a criação de novas categorias e a inserção de novo conteúdo.

A princípio, não alterei nada do que eles já tinham, coloquei na dinâmica as informações desconhecidas e desatualizadas, pois gostaria de observar como lidariam com essas dados.

Com tudo pronto, comecei explicando as regras e colocando na mesa todas as informações levantadas. A parti desse ponto eu procurei não interferir, só quando era chamado.

Em um processo empírico, eles perceberam que ali tinha muita informação duplicada, sem valor e desconhecida. Eles procuraram identificar todas as informações, pesquisaram as mesmas dentro da organização ligando para pessoas que poderiam ajuda-los a entender as informações desconhecidas.

Enfim, eliminaram do processo cerca de 24 itens, e no decorrer da brincadeira, eliminaram algumas categorias e alteraram os nomes de outras.

Aplicaram palavras e entendimentos já correntes na cultura interna da instituição, alteraram a ordem de apresentação do conteúdo e identificaram os valores aplicados a cada tipo de agrupamento, os ordenando por grau de importância.

O resultado final da nova estrutura apresentou 43 itens de conteúdo distribuído em 6 categorias, sendo que 10 itens foram organizados para serem apresentados na primeira página. Para ajuda-los eu estruturei um Wireframe, onde eles distribuíram esses 10 itens de forma consciente na tela.

O resultado foi sensacional.

Contando um pouco mais sobre minha experiência, essa foi a primeira vez que obtive uma participação tão dedicada dos interessados, acredito que foi devido a maturidade do cliente em relação ao seu problema, e o conhecimento fornecido por mim sobre a importância de se aplicar métodos de estruturação e organização do conteúdo.

Hoje eu posso garantir que eles entendem muito mais sua estrutura de informação, como ela funciona e quais são suas principais características. Podem alterar e evoluir a arquitetura sem muita dificuldade.

Até os próximos tópicos:
- Arquitetura da Informação no âmbito filosófico;
- O que é, e como podemos montar um Wireframe;
- Design aplicado a sistemas informatizados (Softwares);

Nossos projetos têm colhido ótimos frutos da aplicação de práticas ágeis, especialmente em relação à utilização de testes automáticos. Mas entendemos que ainda temos muito o que aprender em relação a essa disciplina.

Desse modo, visando um maior envolvimento do pessoal com nossas iniciativas ágeis e apostando firme no amadurecimento técnico de nossa tropa de elite, resolvemos iniciar na Sea o nosso próprio CodingDojo. Então, inspirados pelo post "5 razões para ter um Dojo na sua empresa" do IvanSanches, demos início, na última quinta feira (31/07/2008), às atividades do DojoSea.
 

Pra quem não sabe do que se trata (e está com preguiça de pesquisar), é uma reunião semanal cujo objetivo é desenvolver técnicas de programação e design. Em especial, técnicas ágeis baseadas e relacionadas com TestDrivenDevelopment e ProgramaçãoEmPar . O nome Dojo remete aos tradicionais centros de treinamento em artes marciais.

Nossa primeira reunião foi ótima! Começamos a implementar um identificador de mãos de poker, em um treinamento do tipo randori. O enunciado do problema seria algo como:

"Dada uma mão de poker (formada por 5 cartas), identificar qual o jogo formado (carta-alta, um-par, dois-pares, trinca, seqüênca, flush, etc)".

Como o VictorHugo bem nos alertou, trata-se de um problema complexo e por isso não conseguimos resolvê-lo todo em nossa primeira reunião. Mas como o pessoal foi unânime com a escolha desse desafio (a outra opção seria decodificar números romanos) e como teremos encontros semanais, ficamos com esse mesmo.

Conseguimos chegar até a identificação dos 4 primeiros jogos (carta-alta, um-par, dois-pares e trinca). Surgiram algumas dúvidas e discussões, e nos 20 minutos finais (nosso encontro durou 2h) fizemos uma bela reflexão sobre como o código estava ficando, como foi o trabalho orientado a testes e quais os próximos passos do Dojo.

A partir dessa semana, passaremos a nos encontrar nas sextas-feiras, às 17:00. Na próxima, continuaremos com o nosso primeiro desafio, que estava começando a ficar interessante!

O código fonte, por enquanto, está ficando apenas no SVN da SEA, e a ata das reuniões em nosso Coral. Temos planos de divulgar mais (e melhor) nossas atividades, criar um intercâmbio com outros Dojos (DojoFloripa, DojoSãoPaulo, algum outro?) e em breve abrir as reuniões para pessoas de fora da SEA, como o pessoal da AgilDF, alunos da UnB e da Católica (e da comunidade em geral).

Por enquanto, estamos ainda em fase de experimentação e reflexão. Acompanhe nosso blog, onde tentaremos manter sempre um breve relato de como as coisas vão andando por aqui.

Senhorios e Senhorinas!

Respeitável público!

Venho anunciar meu mais recente post no "além mar"!

Valeu!

Willi

Olá pessoal!!!

Enfim chegamos ao fim de mais uma release, e lhe confesso uma coisa: esta release realmente foi um rali! Tivemos vários obstáculos pelo caminho, mas no fim das contas conseguimos como prêmio diversas melhorias e concluímos uma função muito importante para o projeto, o microblog, apelidado por nós todos de Planc.

Acompanhe nosso diário de bordo

Nosso planejamento inicial para esta release era aprimorar a comunicação cliente x servidor. Para isso, o WiFindMe teria que receber os SMSs com informações e convites trocados pelos membros da rede social. Para que a mensagem fosse endereçada à caixa de mensagens do WiFindMe configuramos o User Data Header (UDH), eu posso explicar isso melhor em outro blog :P

Depois de vários testes, tudo funcionando perfeitamente, nos deparamos com O obstáculo.



O gateway, responsável por converter as solicitações http para SMS, e vice-versa, estava desconfigurando toda mensagem que passasse por ele . Depois de muitos contatos com o suporte do provedor de serviços do gateway, conseguimos resolver o grande desafio da release.

Apesar de perder algum tempo com o problema do gateway, tivemos grandes avanços: além de corrigir alguns bugs e fazer melhorias na arquitetura de informação, incrementamos as formas de convite e interação entre os membros da rede social, esta talvez seja a melhoria mais significativa.

Em nossos testes percebemos que o bluetooth não era muito eficaz para a troca de dados entre WiFindMe`s… Para contornar isto, passamos a utilizar SMSs para enviar convites de amizade e de comunidade. O usuário pode criar uma lista de convidados e mandar o convite, assim, enviando um SMS ele consegue convidar vários amigos de uma vez.


E como funciona esse tal de Planc!?

O Planc é um Mobile Micro-Blogging, ele é uma espécie de twitter para celulares, com ele os usuários podem publicar mensagens breves (140 caracteres) em suas comunidade. Tá bom, até aí nenhuma novidade, nós podemos enviar mensagens via celular para o twitter também, mas, você só consegue enviar mensagens, para visualizar as mensagens é preciso estar conectado a internet. Com o Planc envia e recebe as mensagens no seu celular!

Isso é muito legal pois muitas vezes não estamos na frente do computador. Imagine só, no último fim de semana eu fiquei sabendo de última hora que ia rolar uma apresentação de um grupo canadence de dança no teatro nacional, evento gratuito (e excelente) que abriu o Dance Brasília 2008 (nem sabia que existia isso aqui). Com o WiFindMe eu poderia passar a informação à todos os meus amigos (usando apenas um SMS) e eles não precisariam estar na frente do computador para receber meu recado. Isso é mobilidade!

Ah! Por falar em mobilidade, escute o podcast da Mobile & Embedded Community que participamos. Ele foi gravado em entrevista que demos ao Roger Brinkley durante o FISL.

WiFindMe na SEA

Não vejo a hora que todos da SEA começarem a usar o WiFindMe, isso seria muito legal!!! Mas antes precisamos que a aplicação receba SMSs mesmo estando desligada. Para que isso aconteça precisamos de um certificado digital, ele já esta sendo providenciado :-D

[]s

Até o próximo post!

Esse mundo louco da tecnologia é um oceano cheio de ondas que periodicamente vêm e vão. Volta e meia me perguntam quais as melhores ondas para surfar e qual o momento certo de pegá-las. Exatamente, eu não sei, mas tenho uma desconfiança.

A melhor onda

Escolha a onda que aparente lhe der maior satisfação. Estratégias muito ortodoxas, motivadas exclusivamente por retorno financeiro não se sustentam a longo prazo. Já vi esse filme N vezes. Por isso, acho que o melhor mesmo é ficarmos atentos àqueles ventos que sopram sentido aos rumos que queremos seguir. Fazendo o que se gosta, faz-se bem feito. Fazendo bem feito, cedo ou tarde vem o reconhecimento. Se, além da satisfação romântica (pessoal) a escolha lhe trouxer satisfação clássica (financeira), naturalmente você terá atingido posição de destaque naquele mercado.

Se, por razão qualquer, o mercado não estiver ao seu favor, aí ainda lhe resta a possibilidade de fomentá-lo, se estiver disposto a assumir o esforço (tema pra outro blog). Se acaso a onda escolhida começar bem mas quebrar antes do que se esperava, replaneje-se. Não se apegue a planos de longo prazo. Tenha metas, sim mas, antes de tudo, tenha habilidade para readaptação rápida, caso necessário.


Quando entrar (aqui que o bicho pega)

Como no surf, a hora certa de começar a dar braçadas para acompanhamento da marola que está se formando só é descoberta com a experiência. Há o timing exato. Se se entra muito antes, podemos não ter força para acompanhá-la até o seu auge. Esperando muito, o bonde passa e ficamos a ver navios.

Dia desses alguém na SEA comentou que devemos aproveitar as oportunidades que raramente batem às nossas portas. Discordei de imediato, pois acredito que oportunidades nos vêm e vão todo santo o dia. O que nos falta, no entando, é saber percebê-las e aproveitá-las.

Steve Jobs tem um discurso interessantíssimo no Youtube no qual diz que só conseguimos analisar nosso caminho de vida olhando para trás. Por mais que façamos planos futuros, o que somos hoje é consequência do que fizemos no passado e raramente coincide com os planos que tínhamos na época. Nos mundos científico e artístico, isso acontece com frequência também. Grandes méritos só foram atribuídos post mortem. Em seus tempos, quantos grandes pesquisadores não foram perseguidos, queimados ou degolados por serem considerados hereges, mas cujas descobertas serviram de base para todo o conhecimento posterior? Quantos artistas não foram rechaçados em vida, mas tornaram-se ícones após nos deixar?

Coincidentemente, hoje, a Globo irá apresentar um especial sobre o Chacrinha. Hipócritas. O cara foi sacaneado por uma vida inteira e só agora é tido como o divisor de águas da televisão brasileira. Então, nunca saberemos se o que estamos fazendo hoje terá reconhecimento ou não no futuro. E, diante dessa dúvida eterna, resta-nos caprichar ao máximo no hoje, e por isso que eu digo que a decisão romancista do barco profissional a ser tomado é a de maior probabilidade de sucesso pois, naturalmente, quanto se combina trabalho e prazer, esmera-se mais e as chances de referência post mortem tornam-se maiores.

Garanto pra vocês que nenhum dos caras que hoje são líderes de suas comunidades assim o são por consequência de uma estratégia friamente calculada no início de suas carreiras. Dos que eu conheço, todos começaram por paixão ao que faziam. E assim faziam sem qualquer perspectiva de futuro. Por fatalidade do destino e méritos individuais, entretanto, vários deles viram suas bolhas inflarem a velocidades incríveis e, por estarem bem posicionados à época, consagraram-se deuses do assunto, cada um no seu quadrado, obviamente. Exemplos? Software Livre - Sérgio Amadeu, Marcelo Branco. Java - Bruno Souza. Ruby/Rails - Fábio Akita. Python - Jean Ferri. Linux - Marcelo Tosatti. E por aí vai.

O engraçado é que enquanto um ou outro se firma como o ícone do segmento, todo o grupo de convívio se promove. Nos anos 80, várias bandas de rock nacional se despontaram. Coincidência ou não, eram todos próximos entre si. Quando se fala em samba tradicional, a maior parte das grandes referências foram contemporâneas e fazia parte de um mesmo grupo de convivência social. Os grandes mestres da capoeira viveram juntos. Pode até ser coincidência, mas eu prefiro acreditar no poder colaborativo da coletividade, ou cooperativismo.

Pensa assim, existe um bando de gente apaixonada pelo que faz e que faz aquilo por puro prazer (Cartola, no samba. Mestre Pastinha, na capoeira. Renato Russo, no rock.). Daí, de uma hora pra outra, por influência deles próprios ou do dito "mercado", o valor daquilo que faziam sobre às nuvens. A oportunidade aparece pra um, que leva outro, que convida um terceiro, e assim vai sendo promovida todo a rede de relacionamento do assunto. Como resultado final, todos ganham.

Há 10 anos atrás, eu me envolvi com um grupo social desse. Entitulavam-se grupos de usuários Java (JUGs). Na época, tinham por objetivo único a discussão e promoção da tecnologia que acreditavam. Com o passar dos anos, tornaram-se importantíssimas ferramentas políticas de grandes empresas para a difusão de produtos e instrumentos essenciais para a promoção pessoal num mercado que se tornou tão competitivo. Assim como no samba, na capoeira e no rock, os primeiros contemplatos pelas grandes oportunidades, puxaram os demais que viveram o mesmo momento.

Hoje, há várias dessas sementes incudadas por aí que podem germinar a qualquer momento. Qual dará os primeiros frutos? Não sabemos. A única certeza do mercado são suas incertezas. Os muitos céticos sofrem mais, pois não participam da fundação das comunidades e depois forçam a barra para serem considerados seus fundadores.

Logo, encontre o regaço que melhor te acolha e motive, e siga em frente. Se é Java, Ruby, Python, PHP, XP, Scrum, UP, não importa. Há mercado para todos e o destaque de uma ou outra tecnologia depende de vários fatores, inclusive você (já falei que isso é tema pra outro blog, né?). Pois bem, seja lá o que for fazer, faça apaixonadamente que os resultados certamente virão, em maiores ou menores proporções. Só não se esqueça que em todo investimento, ganha-se na compra, e não na venda. Decidir por comprar uma papel depois que todos já o adiquiriram pode ser tarde demais. Oportunidades nem sempre se apresentam como tal. Talvez a chave para sua posição de destaque no mercado futuro pode estar no apoio descompromissado que hoje você dá a alguma comunidade desconhecida. Eis o mistério da fé.
 

Inspirados pela participação na tradução do “Why’s (Poignant) Guide to Ruby”…

Estamos recrutando voluntários pra tradução do “Scrum and Xp From the Trenches”, do Henrik Kniberg!

O livro já foi traduzido pra Espanhol, Chinês e Japonês. O blog do autor diz que estão em curso as traduções para Coreano, Alemão, Francês, Eslovaco e Português… Essa última, nossa própria promessa!

O processo é muito simples. Basta entrar na nossa lista de discussão, em sft_pt arroba googlegroups ponto com, e enviar um email com o subject “Quero traduzir SfT”, que em breve você receberá um pequeno pedaço do livro em formato word pra traduzir. Depois, basta traduzir o pedaço e devolvê-lo pra gente, no mesmo arquivo, seguindo a numeração. Pra cada pedaço devolvido, respondemos enviando mais um.

Ah, e é claro que todos os colaboradores serão citados na versão final da tradução.

Abraços,

Willi

No último domingo, 06 de julho, aconteceu o Grande Prêmio de Silverstone, na Inglaterra. Achei dois aspectos interessantes na corrida relacionados a projetos de software que gostaria de comentar aqui.

Pra quem não teve oportunidade de acompanhar, vou contar resumidamente os fatos interessantes. O clima estava bastante instável no final de semana. Chovia e parava seguidamente, e ninguém sabia qual o melhor jogo de pneus usar a cada pit-stop durante a corrida: o de chuva pra pista bastante molhada, o intermediário pra pista molhada (ou secando) ou o liso pra pista seca. Na primeira parada das Ferraris, não estava chovendo, a pista já estava secando e existia uma previsão de chuva que poderia se confirmar ou não. Os carros estavam desde o começo com pneus intermediários, que desgastados ficam próximos dos lisos, servindo bem em pistas secas. Numa corrida anterior, em Mônaco, a Ferrari se viu na mesma situação e confiou na previsão de chuva. Trocou os pneus para de chuva, não choveu, e acabaram perdendo a corrida. Provavelmente influenciados por essa decisão errada, tentaram se redimir e arriscaram apostar contra a previsão do tempo agora – mantiveram os pneus intermediários gastos acreditando que a pista ia secar. Só que choveu… E muito!

Os carros deram algumas voltas com um rendimento bem ruim, perderam bastante tempo, o Felipe Massa rodou 5 vezes na corrida e depois de algum tempo a Ferrari chamou os pilotos de volta pra mais um pit-stop não planejado pra trocar os pneus pra de chuva. Os locutores ficaram se perguntando: “Por que não chamou antes, já que iam fazer uma parada a mais de qualquer jeito? Perderam mais tempo ainda!”. Resultado: Quem não arriscou e apostou na previsão se deu bem e o Massa apesar de ter feito o maior número de voltas (inclusive em torno do próprio eixo), terminou em último. Quem quiser ler mais, pode ver aqui, aqui e aqui também.

A primeira lição tirada desse episódio é sobre tomada de decisão. Quem joga poker sabe que cada mão é um jogo novo. Você tem que manter a mente limpa e se concentrar em uma jogada de cada vez, “se esquecendo” do que se passou nas outras mãos. A Ferrari pecou justo nesse ponto. Olhou pra trás ao invés de olhar pra cima. Ficou comprometida com a recuperação do erro do passado ao invés de analisar a situação atual. Ela não deveria ter arriscado dessa vez. Tirou a lição errada de Mônaco e aplicou em Silverstone. As outras equipes olharam pro céu e viram nuvens realmente bastante negras, estavam na Inglaterra, que tem um dia sem chuva por ano e se lembraram dos dias passados, em que chovia o tempo todo. Claro que havia risco de não chover, mas bem menor.

Depois de cometido ao erro, ficaram comprometidos demais com o planejamento inicial de 3 paradas e demoraram pra tomar uma nova decisão e corrigi-lo: chamar os pilotos pra parar mais uma vez e trocar os pneus pra chuva. A nova parada custaria caro! Mais tempo perdido… Mas será que teria compensado o tempo perdido com as 5 rodadas do Massa? Será que se tivessem trocado pra chuva a corrida seria diferente? Será que se tivessem chamado os pilotos de volta logo depois o resultado não teria sido o mesmo?

A resposta é: nunca saberemos.

Decidir é um negócio difícil! Os americanos dizem “Se tomar uma decisão, pode errar. Se não tomar, já errou.” Hoje, com a velocidade com que as decisões complexas têm de ser tomadas, é muito caro e difícil ter as informações necessárias a tempo. O grau de incerteza é grande e talvez seja mais difícil ainda saber se uma decisão foi a bem tomada, pois também é difícil mensurar e comparar resultados. Assim como na corrida, você passa pela situação aquela vez e não tem como voltar e saber no que outra decisão teria resultado.

Tem um agravante quando o ambiente é instável, como na corrida ou em desenvolvimento de software: com a mudança do ambiente, o que seria aparentemente uma boa decisão pode tornar-se rapidamente ruim. Seria o caso se qualquer variável da corrida tivesse mudado, por exemplo, se a chuva tivesse sido muito breve. Nesse caso, todo mundo que colocou pneu de chuva seria prejudicado depois. E se tivesse dado uma bandeira amarela? bagunça tudo de novo… Gerenciar projetos de software é como se durante a corrida, mudasse o tempo todo o clima, o piloto, a equipe, a pista, o carro, várias bandeiras amarelas, acidentes e etc.

Normalmente nós passamos muito mais tempo convivendo com o efeito das decisões tomadas do que tomando as decisões. Decisões ruins podem se tornar fatais. Além disso, algumas informações só ficam visíveis depois de tomada a decisão. Então, por tudo isso que está escrito, é muito mais importante estar atento a esses efeitos e mudar rápido do que investir em uma decisão excelente.

O ambiente pode mudar e a decisão que foi caríssima e lenta fica mais cara ainda, pois terá que mudar tudo de novo. E como normalmente houve muito comprometimento com essa decisão, há mais demora ainda para que seja corrigida. Enquanto que, se tomar a melhor decisão possível para o momento e ela se mostrar ruim, você aprende e se adapta rapidamente à nova realidade, com baixo custo, e não sofre por completo (nem por muito tempo), seus males.

E o que tem Scrum, XP e agilidade a ver com isso tudo? Tudo!
Um dos valores do Manifesto Ágil é que se adaptar às mudanças é mais importante que seguir um plano… Por essa razão que temos reuniões diárias, semanais, mensais, trimestrais e etc. Cada uma pra inspecionar e nos adaptarmos ao caos do nosso dia-a-dia. Temos vários pit-stops pra inspecionar o tempo e trocar nossos pneus de acordo com o altíssimo ritmo das mudanças de nosso ambiente. Na Fórmula 1 o pit-stop sai caro pois é demorado… Em projetos também pode acabar ficando caro, e é por isso que controlamos o tempo das reuniões.

Também é por essas razões que não planejamos com detalhes todo o projeto antes de iniciá-lo. Ao planejar, tomam-se várias decisões que, à época da execução, podem todas terem “perdido a validade” devido às diversas mudanças de ambiente. Cria-se uma expectativa perigosa com a idéia de que o plano seja uma “previsão do futuro”, e qualquer mudança nele pode gerar frustração. Além disso, cria-se um “comprometimento”, ou “apego” à todo trabalho despendido nesse planejamento que pode retardar uma mudança necessária, como no caso das 3 paradas planejadas antecipadamente para a corrida.

Notaram alguma semelhança com seu dia-a-dia? Acho que é uma analogia bem legal e espero que ajude a clarear as idéias sobre essa forma de planejar, além de motivar algumas mudanças. Que tal um planejamento iterativo agora?

Até a próxima!

Willi

Eu tenho falado da filosofia ágil por todo lugar que passei ultimamente e, após uma ou outra olhada torta, a conclusão coletiva sempre tem sido simpática aos valores defendidos.

Em alguns lugares mais tradicionalistas, disseram que já ouviram esse discurso N vezes na história da computação e que, no fundo, todo mundo está atrás da qualidade e produtividade no desenvolvimento de software. Até acredito nisso, mas tenho uma tendência a acreditar mais no momento atual do que nas tentativas de outrora. Nós da SEA não vivemos todas as "grandes idéias" do passado, mas estamos participando do momento atual e temos observado grandes resultados na pele.

Como César Brod, colunista da tradicionalíssima lista Dicas-L, do colega Rubens Queiroz, bem disse, metodologias ágeis de desenvolvimento não se aplicam apenas para software. E ele exemplifica isso com o caso da Alaska Airlines que, utilizando-se de técnicas muito utilizadas em projetos Scrum, otimizaram seus procedimentos de atendimento. E, para engrossar o coro, compartillho experiência semelhante que temos tido na própria gestão da área técnica da SEA.

Bem que tentamos implantar vários procedimentos administrativos, burocráticos, taylorianos no passado. Por alguma razão, ainda desconhecida, falhamos todas as vezes. Pode ser porque não estudamos Administração de Empresas, ou não. De fato, isso sempre era visto como a causa óbvia de todos nossos problemas, até que arriscamos experimentar algo diferente.

Nos últimos tempos, sob a luz dos valores ágeis, não apenas solucionamos 80% dos conflitos tolos existentes na área, como também apresentamos índices de evolução e satisfação do grupo nunca antes observados. Ainda há muito o que melhorar, sem dúvida mas, mantidas suas devidas proporções, só tenho a acreditar que aquele pensamento "old-school" está  muito comprometido.

Hoje somos muito mais democráticos, decisões são tomadas muito mais rápidas e a máquina, definitivamente, anda. Reveja alguns posts que já fizemos aqui e entenda melhor o caso.

Mudanças na TEC

"Estamos adotando um novo modelo de gestão para a Diretoria de Tecnologia da SEA. Após várias tentativas com modelos tradicionalistas e, agora, motivados por algumas tendências de mercado, caminhamos rumo a uma estratégia que apelidamos de "Gestão Ágil". Afinal, acreditamos que a condução de toda a área aproxima-se mais ao ato de dirigir um veículo, recheado de eventos assíncronos, do que ao seu processo de construção, previsível e determinístico.(…)"

 Empreender faz sentido

"Se hoje eu entrar na sala de aula de qualquer universidade e perguntar quem quer ser empreededor, acredito que poucos demonstrarão interesse. Entretanto, em verdade em verdade eu vos digo: aquele que não souber empreender, queimará no purgatório da subserviência até que a asas da previdência os leve ao "conforto" da inatividade.(…)"

Depoimento pró-agilidade

"Gostaria de dar meu depoimento em relação à boa experiência que tivemos numa reunião num cliente, utilizando práticas ágeis no desenvolvimento dum projeto.(…)"

Por que mudar?

"Por muito tempo estivemos melhorando nosso processo de desenvolvimento de software, treinando mais as equipes, aperfeiçoando nossas atividades, nossa documentação e mesmo assim nossa taxa de sucesso nos projetos era a mesma de qualquer empresa, segundo o Standish Group.(…)"

SEA: um celeiro de idéias

"(…)A SEA, já há algum tempo, vem incentivando seus colaboradores e parceiros a desenvolverem habilidades empreendedorísticas essenciais às atividades de consultoria especializada por ela executada. Vários posts já foram publicados no blog público da SEA e constantes incentivos são dados para a elaboração de projetos de pesquisa e para a condução autônoma dos projetos em execução. Agora, a fim de galgar mais um degrau nessa escala de capacitação profissional, a empresa traz uma nova modalidade de incentivo à atividade empreendedora.(…)"

Pessoas auto-gerenciáveis

"(…)É um tipo habilidade que a gente valoriza bastante aqui na SEA. Em geral valorizamos habilidades sociais, tanto quanto as técnicas. Como mencionei outro dia num email cá entre nós:
Vc sabe programar muito bem? Bom pra vc.
Vc conhece as API’s de cór e salteado? Bom pra vc.
Vc tem iniciativa, criatividade, coragem e astúcia? Bom para o projeto.(…)"

Adoraríamos também ouvir seus comentários a respeito. Estamos de portas abertas para apresentação do modelo SEA de operacionalização e gestão.  Colaboração é a palavra-chave. Queremos um mundo melhor e acreditamos que só chegaremos lá se formos juntos.

Um abraço.