Categories
Carreira

Mais 10 livros recomendados para desenvolvedores

Lá atrás em 2008 escrevi um post sobre 10 livros recomendados para desenvolvedores. Na época o post foi bastante popular e eu sempre pensei em escrever uma continuação, que acabei nunca fazendo.

Enfim, a hora chegou e aqui vai mais uma lista de outros 10 livros recomendados para desenvolvedores! Mas antes disso, alguns detalhes sobre como cheguei nessa lista:

Por que apenas 10 livros e não 20 ou 30? Não sei dizer – o primeiro post foi assim então vou continuar. 🙂 O bom é que isso me deixa uma quantidade de livros mais do que suficiente para no futuro escrever vários posts!

Por que essa lista tem livros sobre “processos” como Kanban ou Lean? Não era para ser livros para desenvolvedores? Não tenho pretensão de escrever aqui uma lista definitiva e restrita a apenas um tópico, mas sim listar alguns livros que pessoalmente acho importantes para desenvolvedores de software e que me marcaram de alguma forma. Nosso trabalho não é só programar direito mas também saber se organizar (ou organizar um time) para que se entregue mais software, com mais qualidade e em tempo recorde, portanto acho esses tópicos super importantes.

Por que um livro sobre JavaScript e nenhum sobre Ruby, Python, Java ou qualquer outra? Tem alguma preferência de linguagens rolando aí? Não tem preferência não. O “Good Parts” é sensacional porquê me fez entender e respeitar JavaScript de um jeito completamente diferente. Não acredita? Leia o livro então! Acha que é perda de tempo? Eu acho que não, JavaScript hoje em dia é uma das linguagens mais populares e é indispensável conhecê-la bem para fazer desde um simples website como este blog até gigantes como Yahoo e Facebook.

Por que todos os livros são em inglês? 99% de toda a literatura relevante de tecnologia é em inglês e em muitos casos não há tradução disponível, portanto se você ainda não está craque, pule esta lista e vá urgentemente aprender inglês antes de mais nada! De todas as linguagens (de programação ou não) que você pode pensar em aprender, essa é provavelmente a mais importante.

Clean Code: A Handbook of Agile Software Craftsmanship Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin
Test Driven Development: By Example Test Driven Development: By Example
Kent Beck
Growing Object-Oriented Software, Guided by Tests Growing Object-Oriented Software, Guided by Tests
Steve Freeman e Nat Pryce
Code Complete: A Practical Handbook of Software Construction Code Complete: A Practical Handbook of Software Construction
Steve McConnell
Working Effectively with Legacy Code Working Effectively with Legacy Code
Michael Feathers
JavaScript: The Good Parts JavaScript: The Good Parts
Douglas Crockford
Kanban: Successful Evolutionary Change for Your Technology Business Kanban: Successful Evolutionary Change for Your Technology Business
David J. Anderson
Lean Software Development: An Agile Toolkit Lean Software Development: An Agile Toolkit
Mary Poppendieck e Tom Poppendieck
The Lean Startup: How Today The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
Eric Ries
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
Jez Humble e David Farley
Categories
Carreira Notícias

Estamos contratando no Yahoo! Brasil

Estamos contratando desenvolvedores para o Yahoo! Brasil!

Nosso time é responsável pelo desenvolvimento e manutenção do Yahoo! Meme. Para trabalhar conosco é imprescindível ser faixa preta em Python, PHP ou JavaScript e conhecer pelo menos uma segunda outra dessas três. Mesmo sendo essas as principais linguagens que usamos por aqui, precisamos de desenvolvedores multidisciplinares que saibam usar diferentes tipos de ferramentas – porque nunca sabemos quais produtos virão no futuro e que tipos de vantagens poderemos ter usando ferramentas diferentes.

Tão ou mais importante do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil (especialmente XP), conhecer ferramentas de testes unitários, ser capaz de trabalhar com TDD, entender sobre CI e a sua importância, automatização de rotinas/build/etc., melhores práticas de desenvolvimento de software, Orientação à Objetos, Domain-Driven Design e tudo mais que puder ser relevante para ajudar a construir software confiável e manutenível de forma rápida e com ritmo/qualidade sustentável. Experiência com automatização de testes com Selenium ou Webdriver também é essencial. Como trabalhamos com web, também é necessário ter conhecimento em HTML, CSS e desenvolvimento de aplicações cross-browser.

Como desenvolvemos produtos de escala mundial, é necessário ter experiência com aplicações de alta performance e disponibilidade, identificação e otimização de gargalos de performance, escalabilidade, caching e sharding. É importante também ter bons conhecimentos de pelo menos um tipo de Unix e seus derivados.

Conhecimentos em C, C++, arquitetura de serviços, desenvolvimento de mashups, experiência com uso e desenvolvimento de APIs (REST, YQL, etc.) e experiência em desenvolvimento para iPhone/iPad são bons diferenciais, porém não são requeridos.

Para estas posições é necessário saber inglês bem, o que quer dizer que você deve ser capaz de conversar e ler/escrever em inglês sem problemas (e eventualmente ser entrevistado em inglês caso necessário).

Estamos procurando por pessoas criativas, que gostem de inovação, de pesquisar e identificar novas tendências e de encarar desafios complexos com agilidade e velocidade. Nosso time é pequeno, jovem e nosso ambiente está em constante mudança e evolução. Queremos pessoas irreverentes, que gostem de desafios, com idéias novas e com vontade de criar produtos incríveis!

A empresa oferece contratação apenas por CLT e benefícios como plano de saúde e vale refeição. Estamos localizados na Vila Olímpia em São Paulo. Geralmente contratamos pessoas de outros estados, mas desta vez infelizmente só estamos contratando pessoas de São Paulo/Capital. Update: Voltamos a contratar pessoas pessoas de outros estados e oferecemos auxílio para mudança (passagem, hospedagem, etc.).

Se você se encaixa neste perfil, envie seu curriculo em inglês para mim (gc AT yahoo-inc.com) com uma lista dos últimos 3 livros técnicos que leu. Não esqueça de colocar links para o seu Twitter, LinkedIn, GitHub e o que mais você achar relevante e que pode nos ajudar a te conhecer melhor. 🙂

Update: mais detalhes sobre a vaga (em inglês) na página de desenvolvedores do Meme.

Categories
Agile

Alguns pensamentos sobre “documentação ágil”

Existe um mito de que não se documenta em projetos que usam metodologias de desenvolvimento ágil. Não é bem assim, aliás, não chega nem perto de ser verdade.

A grande diferença entre projetos “tradicionais” e de desenvolvimento ágil é que os processos tradicionais geralmente são bastante prescritivos e você tem que documentar tudo que estiver definido no processo (que geralmente é muita coisa). Você não pensa no que está fazendo, simplesmente segue o que foi definido e escreve documentos. Em métodos ágeis não há prescrição de documentação (e o manifesto ágil fala também sobre “software funcionando mais do que documentação”), mas isso não significa que você não pode documentar nada. Muita gente confunde isso e diz que nunca se deve documentar em projetos “ágeis”, o que é um grande engano. Em projetos ágeis você pode documentar sem problemas desde que seja necessário de fato. A idéia é que você não deve perder tempo com nada que não seja requerido de verdade para o projeto.

Já participei de projetos onde documentar foi extremamente necessário. Por exemplo, uma vez trabalhei num projeto com vários times onde nem sempre os desenvolvedores estavam no mesmo espaço físico, portanto era preciso documentar alguns pontos chave da arquitetura e ambiente para que todos pudessem trabalhar sem problemas. Também já participei de situações onde meu time desenvolvia componentes que precisavam ser usados por outros times, e esses componentes precisavam estar bem documentados para que os outros times pudessem trabalhar adequadamente. Note que isso é totalmente diferente de documentar o projeto inteiro ou escrever dezenas de casos de uso. Documentamos apenas o que fazia sentido ser documentado.

Enfim, há diversas situações onde você pode precisar documentar por diversos motivos. Para te ajudar a decidir quando documentar e como documentar, veja a seguir alguns princípios do que chamei de “documentação ágil”. Essas são apenas algumas práticas úteis e princípios importantes que observei ao longo do tempo em diversos projetos de que participei. Certamente existe muito mais do que isso, mas vamos lá:

Documentação não substitui comunicação

Em projetos tradicionais, muitos documentos são usados para comunicar idéias entre o Analista e o Programador, com QA e por ai vai. Em desenvolvimento ágil o objetivo da documentação é registrar as informações por outros motivos (como os motivos acima). Se você estiver se comunicando por documentos, você já deixou de ser ágil há muito tempo. Documentação não deve ser usada para substituir a comunicação intensa e constante entre os membros do time.

Documentação não pode ser perecível

Documentação tem que ser leve e não pode ser perecível, ela deve ser durável. Se você documenta algo que precisa ser modificado todo dia, existem grandes chances de você esquecer de atualizar a documentação e ela passa a ficar desatualizada. É melhor não ter documentação do que ter documentação errada. Além disso, se você precisa mudar a documentação toda hora significa que você está se aprofundando demais nos detalhes, e então a documentação vai “quebrar” a cada linha de código que você escrever. Quando estiver documentando, pergunte-se: “daqui a algum tempo essa documentação ainda será válida?”. Faça documentação durável. Não entre num nível de detalhe que te faça mudar a documentação o tempo todo (a não ser que você realmente precise disso – e mesmo assim pense se não dá pra fazer de outro jeito, por exemplo, automaticamente).

Documente o necessário, e não mais do que isso

Assim como você deve implementar apenas o necessário para entregar uma funcionalidade e não mais do que isso, você deve documentar apenas o que for necessário e nada mais do que isso. Não perca tempo escrevendo documentação que nunca será usada por ninguém. Se ninguém precisa usar a documentação, então ninguém deve documentar. Documento tem que ter um motivo, documentar sem uma necessidade real não faz sentido

Documentar tem que ser fácil

Documentar tem que ser rápido, não pode dar trabalho. Use ferramentas como wikis, geradores de documentação (como o Sphinx) e por aí vai. Se for fácil documentar, as chances de você fazê-lo serão maiores. No caso de não usar wiki (ou alguma coisa online/web), use ferramentas para publicar a documentação automaticamente. Se a documentação for fácil de ser acessada (e tiver busca) ela fica mais útil. Além disso, prefira usar uma tecnologia fácil e conhecida para que todos os membros do time possam documentar. Por exemplo, se você escolher usar LaTeX, você está reduzindo as chances de designers documentarem, pessoas de negócio e outros membros não-programadores de um time.

Documentação faz parte do “Definition of Done”

Se o seu projeto precisa de documentação por qualquer motivo, a documentação deve fazer parte da “Definition of Done”. É melhor documentar no momento que as histórias estao sendo desenvolvidas – quando o conhecimento está fresco na cabeça – do que acumular um monte de débito e ter que pagar de uma vez só – quando você vai precisar conferir um monte de coisas que já estão prontas para documentar com precisão, o que vai te dar mais trabalho e consumir mais tempo.

Documentação no código pode ser um “code smell”

“Code smell” é um sintoma no seu código que pode indicar um problema maior. Muitas vezes códigos precisam ser documentados porque eles são desnecessariamente complexos. Sempre que possível prefira refatorar o código para ele ficar mais fácil de entender ao invés de escrever comentários (até porque muitas vezes o código muda e o comentário fica lá desatualizado, e isso acaba mais atrapalhando do que ajudando). Tenha uma boa suite de testes (uma suite bem escrita e organizada é uma especificação executável), use Domain-Driven Design para expressar melhor o domínio do software, metáforas, tenha um design simples, use design patterns, enfim, é melhor fazer com que o software seja mais bem escrito e não mais bem documentado.

Categories
Carreira Notícias

Yahoo! procura Ninjas

Estamos procurando Desenvolvedores e Scrum Masters Ninjas para integrarem nossa equipe no Yahoo!

Nosso time é o que chamamos de “Innovation Cell”, que é algo como uma incubadora de projetos, responsável por pesquisar e criar novos produtos. Atualmente nosso carro-chefe é o Yahoo! Meme, que foi inteiramente desenvolvido no Brasil no último ano e já está em vários outros países como Indonésia, Filipinas, México, Argentina e Taiwan.

Desenvolvedor Ninja

Os Desenvolvedores Ninja serão responsáveis pelo desenvolvimento e manutenção de aplicações web, em especial o Yahoo! Meme e outros aplicativos de integração com redes sociais. É imprescindível ser faixa preta em Python, PHP ou JavaScript e conhecer bem pelo menos uma segunda outra dessas três. Mesmo sendo essas as principais linguagens que usamos por aqui, precisamos de desenvolvedores multidisciplinares que saibam usar diferentes tipos de ferramentas – porque nunca sabemos quais produtos virão no futuro e que tipos de vantagens poderemos ter usando ferramentas diferentes.

Tão ou mais importante do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil e ser capaz de trabalhar com TDD, entender sobre CI e a sua importância, automatização de rotinas/build/etc., melhores práticas de desenvolvimento de software, Orientação à Objetos, Domain-Driven Design e tudo mais que puder ser relevante para ajudar a construir software confiável e manutenível de forma rápida e com ritmo/qualidade sustentável. Experiência com automatização de testes com Selenium ou Webdriver também é essencial.

Como desenvolvemos produtos de escala mundial, é necessário ter experiência com aplicações de alta performance e disponibilidade, identificação e otimização de gargalos de performance, escalabilidade, caching e sharding. É importante também ter bons conhecimentos de pelo menos um tipo de Unix e seus derivados.

Conhecimentos de OpenSocial, desenvolvimento de mashups, arquitetura de serviços e experiência com uso e desenvolvimento de APIs (REST, YQL, etc.) são diferenciais.

Scrum Master Ninja

O Scrum Master Ninja deverá ajudar o time de desenvolvimento a produzir no máximo da sua capacidade. Sua missão será organizar e facilitar os Sprint Plannings e Reviews, bem como Retrospectivas e o que mais for necessário para suportar os times de desenvolvimento e produto. Ele deverá identificar e remover impedimentos, ajudar o time a manter o foco mas dando todo o espaço e autonomia que ele precisa para se auto-organizar e gerenciar. É necessário já ter tido alguma experiência anterior relevante nesta posição.

Como o Yahoo! é uma empresa que em sua maioria ainda trabalha com métodos tradicionais de desenvolvimento, esta pessoa também será responsável por fazer com que o time esteja dentro das normas da empresa, gerando relatórios para as células de gerenciamento de projetos e fazendo algum trabalho burocrático de registro e comunicação de métricas.

Queremos um Scrum Master influente, que seja capaz de entender questões técnicas mesmo que em alto nível, que seja apaixonado por procurar maneiras de melhorar o processo de desenvolvimento, construtivo na hora de resolver problemas e solucionar conflitos e com muita vontade de descobrir novas maneiras de trabalhar com métodos ágeis. O Yahoo! é uma empresa que ainda está engatinhando em métodos ágeis e por isso precisamos de alguém com muita disposição e vontade de mudar a empresa!

Por último, experiência com XP, Lean Software Development, Kanban e diversos métodos ágeis são diferenciais.

Continuando…

Para ambas as posições é necessário inglês avançado, o que quer dizer que você deve ser capaz de conversar e ler/escrever em inglês sem problemas (e eventualmente ser entrevistado em inglês caso necessário).

Estamos procurando por pessoas criativas, que gostem de inovação, de pesquisar e identificar novas tendências e de encarar desafios complexos com agilidade e velocidade. Nosso time é pequeno, jovem e nosso ambiente está em constante mudança e evolução. Queremos pessoas irreverentes, que gostem de desafios, com idéias novas e com vontade de criar produtos incríveis!

A empresa oferece contratação apenas por CLT e benefícios como plano de saúde e ticket refeição. Estamos localizados na Vila Olímpia em São Paulo. Vamos dar preferência para pessoas de São Paulo mas também vamos olhar com carinho currículos de pessoas de fora e daremos auxílio para mudança caso necessário.

Se você se encaixa em algum destes perfis, mande seu curriculo em inglês para mim (gc AT yahoo-inc.com) com uma lista dos últimos 3 livros técnicos que leu. Não esqueça de colocar links para o seu Twitter, LinkedIn, GitHub e o que mais você achar relevante e que pode nos ajudar a te conhecer melhor. 🙂

Categories
Agile

2 anos de Scrum e Agile na Globo.com e algumas coisas que eu aprendi

Já se passaram pouco mais de 2 anos desde que começamos a trabalhar oficialmente com Scrum e Agile na Globo.com e um pouco mais de 2 anos e meio desde que a coisa toda começou de fato.

Depois de trabalhar diariamente com processos ágeis e uma porção de times diferentes na Globo.com, minha sensação é a daquele dito popular que diz que quanto mais você sabe de alguma coisa, mais você descobre que tem que aprender. De tempos em tempos surgem idéias novas excelentes e as vezes são coisas tão simples que eu me pergunto porque nunca tinha pensado nelas. Ou então algumas idéias que não deram certo no passado voltam à tona, são colocadas em prática e passam a funcionar muito bem. Sempre que eu acho que já aprendi como alguma coisa funciona alguém aparece com uma idéia melhor e me prova que eu estava errado em achar isso.

Me lembro quando perguntei lá no início para o Boris Gloger sobre o tempo que levaria para as coisas acontecerem. Na época ele falou que para uma empresa do tamanho da Globo.com certamente levaria de 2 a 4 anos para as coisas mudarem de fato. Eu achei um exagero e que ele estava louco, mas era eu que não tinha noção do tamanho da coisa toda. Ele estava certo.

Infelizmente eu não tenho uma história romântica para contar e estaria mentindo se dissesse que as coisas são maravilhosas depois que você adota Agile, Scrum ou o que quer que seja. Muito pelo contrário, os problemas começam a aparecer e tudo fica caótico. As vezes a quantidade de problemas chega a ser enlouquecedora e minha insônia aumentou consideravelmente depois disso. Mas eu não tenho nenhuma dúvida de que os processos ágeis são os que mais se adaptam às características de projetos de desenvolvimento de software, mais do que qualquer outra coisa que eu já tenha usado. Tivemos muito mais sucesso do que em qualquer outra iniciativa na história da empresa e as coisas acontecem muito mais e muito melhor do que aconteciam antes, mas mesmo assim ainda temos um caminho muito longo pela frente.

Hoje eu consigo entender com mais clareza o real sentido do empirismo que tanto se fala. Mesmo com pilhas de livros sobre desenvolvimento ágil na minha prateleira, eu olho para trás e vejo que o processo de “tentativa e erro” foi muito mais importante para o meu aprendizado do que qualquer teoria. Várias coisas escritas nos livros deram certo para alguns times e não deram para outros, e no fim das contas o que ficou foi uma mistura de todas essa experiências. Fomos fazendo as coisas, vendo o que dava certo ou errado, mudando, adaptando e seguindo em frente. Hoje não dá pra dizer que a Globo.com usa Scrum, XP, Lean ou Kanban. Você pode encontrar todos os seus sabores preferidos de Agile por aqui, às vezes misturados e até mesmo bem customizados e diferentes do tradicional.

Nesse tempo todo vivenciei muitos problemas, muitos sucessos, muitas derrotas, muitas falhas e muita mudança. Eu queria poder dizer que encontrei o Santo Graal do desenvolvimento ágil, mas dificilmente isso existe. E se existir, provavelmente o da minha empresa será diferente da sua e por ai vai. Porém, eu posso falar de algumas coisas que eu aprendi e que talvez possam ser úteis para outras pessoas e empresas:

Você sempre estará em transição.

Basicamente eu não acredito mais em transição ágil como eu já li por ai, que parece uma coisa que tem inicio, meio e fim. Hoje eu percebo que sempre se está em transição. Sempre surgirão projetos novos com características diferentes e sempre será necessário ajustar e se adaptar. Isso tudo fora que as pessoas e os times também mudam, e ai começa tudo denovo. É um trabalho que nunca acaba.

É muito fácil começar a fazer Scrum, o difícil é vencer a resistência das pessoas.

Grande parte do meu tempo nesses anos foi investido em quebrar barreiras e a resistência das pessoas. E não estou falando de diretores ou gerentes, às vezes os piores problemas estão dentro dos times. Os mais diversos tipos de problemas acontecem: tem gente que tem medo de trabalhar em par e expôr suas fraquezas para os outros, tem gente insatisfeita na empresa que envenena iniciativas, enfim, acontece de tudo. É muito importante trabalhar com pessoas bem intencionadas, comprometidas e que acreditam no que estão fazendo e que acreditam que as coisas sempre podem (e devem) ser melhoradas.

As pessoas precisam estar felizes.

É importantíssimo que a empresa reconheça seus talentos, que eles ganhem o que merecem e que eles trabalhem num ambiente agradável. Ninguém trabalha direito e dá 100% do seu potencial se não estiver feliz e satisfeito com a empresa. Pessoas infelizes e insatisfeitas podem acabar com um time inteiro, por isso a empresa tem que dar o primeiro passo e dar todas as condições para que isso não aconteça e, quando acontecer, resolver o problema o mais rápido possível.

Se o foco das pessoas for em “fazer telas”, “testar” ou “escrever software”, você está perdido. O foco das pessoas deve ser o produto, e não a sua função.

Muito desenvolvedor não gosta de fazer teste exploratório “porque isso é função do cara de QA”. Muito designer não gosta de fazer CSS e HTML porque isso é coisa de “desenvolvedor de front-end”. Bullshit! Imagine se um zagueiro está com a bola na linha do gol e diz que não vai fazer o gol porque não é atacante? Não tem essa, o foco é ganhar o jogo, entregar o produto, deixar o cliente feliz, não importa fazendo o que. Com o tempo você descobre a receita do time (quantidade de pessoas de cada especialidade) para que as pessoas passem a maior parte do tempo fazendo sua especialidade, mas isso não significa que elas não devem fazer ou entender de outras coisas.

Escalar não é facil. Aliás, se for possível, não escale nunca.

Times ágeis funcionam melhor quando são pequenos, porque o universo de pessoas é menor e a comunicação é melhor, as pessoas confiam mais no resto do time e por aí vai. Quando o número de pessoas e de times aumenta, a comunicação fica problemática e isso gera uma porção de problemas, desde coisas triviais como conflitos de merge até coisas mais complexas de resolver como falta de confiança, dificuldade em mudar de direção, dificuldade de passar a visão do produto, pessoas querendo aparecer mais do que outras e por aí vai. Faça um teste: reuna 30 amigos seus e tentem combinar um lugar para almoçar em no máximo 2 minutos. Repita o teste com 3 amigos e compare os resultados. Foi possível combinar um único lugar de forma unânime? Quanto tempo levou? Quais foram os conflitos de interesse? Qual foi o nível de barulho, stress e insatisfação das pessoas? Ter mais pessoas ajudou a fazer com que a decisão fosse mais rápida ou mais demorada? Talvez esse não seja o melhor exemplo do mundo mas vai ser bem fácil de perceber como times grandes se organizam com muito mais dificuldade.

Boas práticas de engenharia e desenvolvimento ágil como automatização, testes, refatoração, programação em par, integração contínua e TDD são fundamentais, imprescindíveis, inevitáveis, totalmente obrigatórias.

Todos os grandes saltos de qualidade e produtividade que demos na história da evolução da Globo.com foram porque essas práticas foram intensificadas e usadas com mais disciplina, e todas as vezes que elas não recebem a devida importância a velocidade diminui, a produtividade baixa e o time entrega menos (e com mais defeitos).

Um dos “problemas” com o Scrum é que ele não fala nada sobre usar essas práticas. Isso é proposital porque o intuito era que ele fosse bastante genérico e simples, mas como muitas pessoas gostam de seguir o livro cegamente sem pensar, elas acabam achando que não é necessário fazer o que não está escrito, e daí a probabilidade de fracasso é gigantesca. Você pode usar Scrum para produzir um marca-passo, por exemplo, mas você seria louco de não testá-lo exaustivamente só porque não está escrito? Você tem que fazer, porque é uma necessidade imposta pelo tipo de projeto. Com software não é muito diferente: se você não faz TDD, seu código fica pouco testável, e consequentemente você refatora menos ou tem dificuldade para fazê-lo. Consequentemente o tempo para implementar novas funcionalidades aumenta cada vez mais e como o cliente está sempre cobrando mais e mais coisas, você passa a testar menos para dar tempo de fazer mais funcionalidades. E por aí vai (para o buraco).

As regras são excelentes quando você não sabe o que está fazendo. Depois que aprender, quebre-as.

Geralmente quando as pessoas começam com Agile o que se recomenda é que você siga as regras à risca por algumas iterações até que você aprenda e que o processo esteja “no sangue”, e só depois que possíveis customizações devem ser feitas. Muita gente confunde isso com “sempre siga as regras à risca”. Por exemplo, hoje alguém me convenceu numa conversa que o Sprint Planning 2 do jeito que um determinado time estava fazendo estava bem inútil, uma grande perda de tempo. A sugestão foi fazer uma coisa mais “just-in-time”, ou seja, na hora que a história começar a ser desenvolvida. Muita gente pode falar que “ah, mas não é assim que o Scrum funciona” ou o clássico “aqui na empresa nós não fazemos desse jeito”. Se você tem um bom motivo para mudar as regras do jogo, discuta o assunto com o time e implemente as melhorias. Não existe essa coisa de “as regras do Scrum”, existem times produtivos com alta capacidade de adaptação e em constante evolução ou times que passam 50% do tempo discutindo o processo e não deixam o cliente feliz.

Trabalhar num ambiente ágil é muito muito muito mais divertido.

Acabei de passar quase 40 dias de férias e em conferências. Muita gente estaria odiando voltar para o trabalho depois disso, mas eu gostei. Quando eu cheguei hoje na empresa depois de mais de 1 mês a minha mesa já não era mais minha e eu não achava meu computador. O escritório mudou totalmente e o time que eu estava está todo misturado. Quando eu entrei na sala as pessoas estavam em pé discutindo, rabiscando no quadro e o barulho estava alto pra caramba. Depois de contar as novidades, de almoçar e de alguns updates, passei o resto da tarde programando em par numa tarefa que nem eu e nem o meu par faziamos idéia de como resolver, mas juntos descobrimos como fazer e resolvemos o problema. Foi um dia caótico porém muito produtivo e muito divertido, como a maioria dos que eu tenho. Tudo muda muito e está em constante evolução, e cada dia é um novo desafio. Se você gosta de ficar escondido atrás da “baia” e tem dificuldades em dividir o seu teclado com um amigo, recomendo fortemente que você não use Agile.

Agile não é o Santo Graal.

Nenhum processo de desenvolvimento (ágil ou não) é perfeito. Muita gente gosta, muita gente não gosta, alguns não se adaptam, outros se motivam a cada dia com os novos desafios e é assim que as coisas funcionam. <ironia> “Agile é tão perfeito” </ironia> que quando as coisas dão errado é muito mais fácil culpar o seu processo e reclamar que ele não funciona. Bullshit! Como o Jeff Patton fala, as pessoas fazem isso porque o processo não vai se defender de você e porque é muito mais dificil assumir e enxergar os problemas de verdade. Uma das chaves de ser bem sucedido nesses processos é entender que eles são apenas ferramentas muito simples e que se não estão funcionando é porque você precisa encontrar e resolver algum problema da sua empresa, do seu time, das pessoas ou do que quer que seja. Não bote a culpa no processo.

As pessoas são mais importantes que o processo. Foco nas pessoas.

São elas que fazem tudo acontecer. Quanto mais agentes de mudança sua empresa puder ter, melhor. A empresa tem que reconhecer essas pessoas e motivá-las para que elas motivem ainda mais seus pares e assim por diante. É preciso dar liberdade para elas criarem, tentarem coisas novas e errarem sem medo de serem repreendidas. Faça de tudo para que todos estejam felizes e motivados. Resolva os conflitos. Coloque tudo em pratos limpos. Trate todos com respeito e como amigos. Faça as pessoas crescerem e deixe (e ajude) que elas tenham visibilidade dentro da empresa. De todas as coisas que eu vi até hoje, nada é mais eficaz do que ter as pessoas certas do seu lado.

Nada disso é definitivo e eu posso mudar de opinião a qualquer momento sobre qualquer uma dessas coisas. Aliás, hoje numa conversa aprendi que é ótimo mudar de opinião, porque significa que você aprendeu alguma coisa nova/diferente que te fez pensar de uma forma nova/diferente e, portanto, você evoluiu. Fica então a última:

Crie sua opinião, aprenda mais e mude sua opinião. Esteja em constante evolução.

Categories
Eventos Python

[PythOnCampus-RJ] Eu fui!

Adorei participar do PythOnCampus nesse último sábado e conhecer várias pessoas muito legais da comunidade Python carioca (que não vou citar para não correr o risco de esquecer alguém)! Vejam as fotos no blog da comunidade PythOnRio.

Minha palestra sobre Testes e Qualidade de software em Python foi bem divertida! Quando percebí que a galera estava bem interessada eu deliberadamente estourei totalmente o tempo e ficamos quase duas horas falando sobre conceitos de testes, TDD e outras práticas de XP, doctest, unittest, pMock, Pyccuracy e por aí vai… Mais do que teoria, vimos bastante código Python!

Para quem não conseguiu anotar, a bibliografia que recomendei no final foi a seguinte:

Nas próximas semanas o PythOnCampus será repetido em outras faculdades pelo Rio de Janeiro. Acompanhem o site da comunidade PythOnRio para ficarem por dentro das datas e dos detalhes.

Categories
Agile Eventos

[Encontro Locaweb] Eu fui!

Ontem estive em Salvador a convite do meu amigo Fabio Akita para participar do 11o. Encontro Locaweb de Profissionais de Internet. O evento estava bastante legal e eu gostei bastante das únicas duas palestras que assisti, uma do Galileu Vieira (que gostou da minha camisa sobre wingdings) da Microsoft sobre inovações relacionadas a fotografia e Silverlight e outra da Cíntia Assali do Google que foi um “medley” sobre todos os produtos (incluindo coisas que eu não conhecia como o Google Ad Planner). Quanto mais eu aprendo mais eu vejo que sempre tem coisas pra aprender. 🙂

Enquanto o Akita se diverte na Rails Conf eu fiz uma apresentação sobre Agilidade e Qualidade em projetos de software. Não vou publicar o PDF da apresentação aqui porque os slides não tem a menor graça e o menor valor se eu não estiver apresentando (já que a maioria deles são fotos e desenhos). No entanto, seguem alguns links para quem quiser se aprofundar no que falamos:

Espero que tenham se divertido como eu me diverti! 🙂

Categories
Agile

Louco por automatização!

Ultimamente tenho feito uma brincadeira que todos ficam achando que eu sou maluco. Costumo dizer que o meu objetivo a cada dia é tentar fazer com que todo o trabalho que eu faria em 2 dias seja feito em apenas 1 hora, e assim eu posso aproveitar as outras 15 horas escrevendo posts no meu blog, estudando coisas novas, jogando Guitar Hero ou até mesmo dormindo (se eu não tivesse insônia).

Parece loucura mas não é. Quando eu ainda era um jovem Padawan um dos vários mentores que tive ao longo da minha vida me ensinou uma lição muito valiosa.

Há bastante tempo atrás, observando um amigo trabalhar percebi que ele passava horas e horas automatizando cada pequena tarefa que faziamos na empresa. Se precisavamos criar uma entrada no DNS, tinha um shell script para fazer isso. Se precisavamos fazer backup, existia um script para fazer isso e ele até já funcionava sozinho. E no caso dele, ele tinha scripts prontos até para facilitar fazer as compras do mês no Zona Sul online (isso é sério mesmo). Basicamente ele era obcecado por automatizar tarefas.

Como ele passava a grande maioria do tempo automatizando coisas, um dia eu resolvi perguntar porque ele perdia tanto tempo fazendo aquilo. Não era apenas uma obsessão sem sentido, tinha um fundamento muito simples. Ele disse: “Quanto mais você trabalhar para tornar a sua vida mais fácil automatizando as tarefas repetitivas, mais você terá tempo livre para fazer mais coisas que você quiser! Fazendo assim você vai ter tempo de sobra para investir nas tarefas realmente desafiadoras, que vão exigir toda sua intelectualidade e que vão te dar prazer. É por isso que eu sempre trabalho com a meta mental de reduzir todo o trabalho que eu faria em 2 dias para 1 hora, e fazendo assim todo o dia e a todo momento as coisas simplesmente vão acontecer; e eu vou produzir muito mais que qualquer um sem absolutamente nenhum esforço”.

Eu sempre achei isso genial! Obviamente ele não passava 15 horas de bobeira fazendo outras coisas. O objetivo era apenas estabelecer uma meta agressiva de automatização de tarefas para conseguir alcançar um nível onde muitas coisas podem ser feitas com pouquissimo esforço, e a brincadeira de “passar 15 horas de bobeira” serve apenas para ilustrar e tornar o exemplo mais divertido. 🙂

Desde essa época eu venho usando essa abordagem para o máximo de coisas que eu consigo. Meu problema sempre foi que eu nunca tentei de verdade ser tão extremo quanto ele (ao ponto de automatizar até as compras do mês), mas de uns meses pra cá eu tenho sido cada vez mais e mais radical e tenho me tornado cada vez mais produtivo (apesar de ainda ir fisicamente no mercado fazer compras).

“Radical” e “extremo” são palavras que têm uma conotação muito negativa, mas ser radical ou extremo pode ser muito útil quando se tem um propósito como esse (ou então para se fazer uma abordagem como a que eu postei sobre porque eu não gosto de escrever comentários no código).

Em projetos de desenvolvimento de software, os ganhos com uma abordagem desse tipo são impressionantes. No último projeto que comecei (e que estou atualmente) propús para os meu amigos do time que tentassemos fazer uma abordagem desse tipo – radical e extrema – em relação a automatização. A regra que criamos juntos e concordamos ficou bem simples: se alguma coisa precisou ser feita mais de uma vez então ela necessariamente deve ser automatizada.

Depois de aproximadamente 3 semanas de trabalho as coisas funcionam mais ou menos assim:

  • Todos os testes unitários e de aceitação são automatizados e podem ser rodados com apenas um comando (desde criar/atualizar banco de dados até subir Selenium Server, colocar o sistema em um estado conhecido, executar os testes e depois desfazer isso tudo).
  • Toda vez que é feito um push para o Git, o build server roda primeiro todos os testes unitários automaticamente.
  • Se qualquer um dos testes falha, uma sirene toca automaticamente alertando que alguém fez besteira.
  • Se os testes passam, o Capistrano faz um deploy em cada uma das máquinas do ambiente de testes de aceitação e dispara a execução de todos os testes de aceitação nesse ambiente.
  • Se o banco de dados mudou, o upgrade do schema de banco de dados também é feito automaticamente.
  • Finalmente, quando todos os testes passam, é feito um deploy automatico para o ambiente “live”, que tem por objetivo ser o lugar onde se pode ver a última versão de desenvolvimento que passa em todos os testes.
  • Se precisarmos colocar a aplicação em produção, um script fará isso da forma mais simples, segura e instantânea possível.
  • Se um desenvolvedor precisar desenvolver nesse projeto, basta baixar o código do repositório e com um script tudo se configura e funciona automaticamente.
  • Se for preciso criar uma nova tela de cadastro padrão desse sistema, basta rodar um script e ela será quase toda criada automaticamente (apenas as particularidades precisam ser configuradas).
  • … e por aí vai.

Todas essas coisas juntas não foram simples de serem feitas, muito pelo contrário, foi bastante trabalhoso (e até chato algumas vezes). Porém, o resultado não deixa dúvidas: o ganho de performance é absurdamente alto e vale a pena cada minuto gasto investido.

No início levamos muito tempo automatizando tudo mas depois dos primeiros 3 ou 4 dias qualquer coisa passou a levar bem menos tempo do que levaria. Em pouquissimo tempo (algo em torno de 3 semanas, como eu disse) já é possível perceber resultados concretos dessa abordagem. Apesar de ainda termos um monte de coisas para melhorar, nossa agilidade para fazer coisas simples e vê-las funcionando é muito grande!

Não gaste seu nobre tempo fazendo coisas repetidas e chatas. Automatize tudo que puder! Faça os scripts trabalharem pra você!!!

Categories
Eventos

[Encontro de TI] Eu fui!

Ontem tive o prazer de fazer mais uma apresentação no 2o. Encontro de TI organizado pela Arteccom.

Dessa vez eu falei sobre desenvolvimento para web com agilidade. Nos dias de hoje nós desenvolvedores temos ao nosso alcance uma infinidade de ferramentas para desenvolver software com mais qualidade e agilidade, e o meu objetivo foi apresentar rapidamente algumas das opções mais usadas no mercado falando de suas vantages e desvantagens. Falei também um pouco sobre arquitetura de software usando o velho mito do “Rails não escala” como cenário. No final ainda deu tempo de falar sobre alguns dos princípios e mentalidades que eu acredito que qualquer desenvolvedor precisa ter para ser mais produtivo. O tempo foi pouco pra tanto assunto mas no final acabei conseguindo. Espero que quem assistiu tenha gostado! 🙂

O mais legal foi que a palestra do Fabio Akita – que foi logo depois da minha – encaixou perfeitamente no assunto e deu um belo arremate nessa mesma linha, falando sobre desenvolvimento com agilidade usando Ruby on Rails. Se nós tivessemos combinado não teria sido tão acertado! Outras figurinhas carimbadas também estavam presentes no evento como o Paulo SIlveira da Caelum e o Paulino Michelazzo da Fábrica Livre.

No fim do dia rolou um painel de discussões bem legal com alguns dos palestrantes e quem não teve tempo de fazer perguntas nas apresentações teve chance de participar. Poderia ter sido só um pouquinho mais longo mas mesmo assim valeu.

ETI2: Painel de discussões
* Painel de discussões no encerramento do evento. Foto de Patricia Haddad.

Mesmo já tendo palestrado em eventos anteriores organizados pela Arteccom ainda fico intrigado pelo empenho e organização de todos da equipe. O evento estava muito legal! Mesmo sendo “novatos” neste segmento de TI já estão batendo um bolão. Só falta agora eles aprenderem a escrever o meu nome direito! 🙂

Sei que algumas pessoas já pediram mas por enquanto não vou disponibilizar os slides para não fazer spoiler, afinal, o Rio de Janeiro foi apenas a primeira etapa do evento. Nos próximos meses estaremos em São Paulo, Florianópolis, Curitiba, Porto Alegre, Brasília, Belo Horizonte, Salvador e Recife.

Nos vemos lá!

Categories
Eventos

[Agile 2008 Conference] Henrik Kniberg: 10 ways to screw up with Scrum and XP

Gostei muito da apresentação do Henrik Kniberg “ensinando” 10 maneiras para arruinar seus projetos mesmo usando XP e Scrum. É óbvio que eu não quero acabar com os meus projetos, mas é legal debater sobre os erros mais comuns nas adoções de metodologias ágeis e seus motivos para poder evitá-los.

Uma coisa interessante é que o Henrik costuma usar com sucesso a mesma combinação de XP e Scrum que usamos na Globo.com. Não por acaso, tanto o seu livro Scrum and XP from the Trenches quanto a apresentação (mesmo quando ainda não tinha assistido) e o seu blog sempre foram boas fontes de referência para mim.

Resumidamente, as 10 maneiras mais comuns de arruinar projetos com XP e Scrum são:

  • Futilidades: debates homéricos sobre coisas como “vamos usar cartões ou post-its” quando o time sequer tem um P.O.! Os problemas devem ser atacados em ordem de importância. Além disso, a aplicação do processo não precisa ser perfeita desde o início. Good enough is good enough.
  • Definition of Done: muitos times não tem uma definição de pronto ou não respeitam essa definição. Isso não só é essencial como também é preciso que o cumprimento desta definição esteja dentro do controle do time.
  • Velocidade: não é conhecida, usada ou é muito variável ao longo das iterações.
  • Retrospectivas: não há retrospectivas e o time não evolui suas práticas ao longo do tempo aproveitando-se dos aprendizados obtidos nas iterações.
  • Comprometimento do time: time é cobrado e sempre culpado por erros em estimativas. Isso faz com que eles sempre se comprometam com menos do que podem fazer, com medo de serem culpados novamente.
  • Débito técnico: é totalmente ignorado e só cresce ao longo das iterações.
  • Trabalho em equipe: não há trabalho em equipe e existem tarefas fixas para determinadas pessoas, o que faz com que várias histórias sejam implementadas em paralelo.
  • Product Backlog: não existe ou não está priorizado corretamente.
  • Integrações da base de código: não existe um branch onde o código pode ser lançado em produção a qualquer momento e a gerência da base de código não é agil.
  • Sprint Backlog/quadro de tarefas: não existe, está longe do time, é muito complicado ou não é usado durante o Daily Scrum e atualizado diariamente.

É óbvio que essas não são as únicas maneiras de fazer besteiras em projetos com XP e Scrum e pode até ser também que tenham algumas maneiras mais “eficazes” que essas. No entanto esses problemas são muito comuns e acho que por isso mereceram destaque na apresentação.

Você pode encontrar os slides da apresentação no site do Henrik Kniberg. Esses slides são de uma apresentação um pouco mais antiga mas não há muitas diferenças.