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.

Tags: , , , , , , , , , , , , , , ,

46 Responses to “2 anos de Scrum e Agile na Globo.com e algumas coisas que eu aprendi”

  1. Guilherme foi muito bom ler o seu depoimento, você reuniu vários fatores para explicar que na verdade a grande vantagem de usar ágile, está na mudança de visão. O processo é customizável e os caminhos são infinitos, mas a postura e a essência são claras e não dissolvem com o tempo.

    Gostei muito do artigo.

  2. Muito bom! Com relação a conclusão do post lembro de uma frase que um antigo colega me falou quando “perdeu” uma discussão comigo: Que bom que perdi, sempre quem perde uma discussão é quem acaba ganhando.

  3. Excelente gc!

    Tenho os mesmos sentimentos que você. #gay

    []’s!

  4. Muito bom!

    Ser ágil e ser tão flexível que as regras podem ser quebradas (para o bem).

    Abraço!

  5. Adorei o artigo. É engraçado que o processo do Agile não é nada de outro mundo, mas tem que ter a vontade e a cultura senão não vai para a frente.

    Este artigo aumentou minha percepção do assunto, e com certeza, vou estudar mais para implementar na minha empresa tudo isso e muito mais.

    Parabéns! Valeu mesmo

  6. Pamela Gatinho says:

    Muito bom!!!

    Voce mostrou de mandeira clara o que vamos que enfrentar ao tentar adotar agile! Serve de motivação pra todos! Vou encaminhar a todos da minha equipe. Obrigada por compartilhar essa experiência!

  7. Ótimo artigo! Só espero que o pessoal não desanime no trecho que você menciona sua insônia :p

  8. Muito grande. Não li. Parece o Akita. hahá.

  9. Elber says:

    Muito bom mesmo! Gostei da parte de focar o produto, é um detalhe extremamente importante.

  10. Dudu P says:

    Muito legal, GC. Como recém chegado na Globo.com eu acho maneiro pegar este histórico e o contexto, e começo a entender muitas das resistências que encontro por aqui.

    Sobre as regras, eu não só concordo, como acho engraçado quando falam sobre elas, pois meu entendimento de scrum é justamente trocar artefatos, regras pela iteração constante e confiança. É hilário querer transformar scrum em processo.

  11. Parabéns Guilherme. Nós aqui na Bluesoft também já estamos chegando a quase dois anos de métodos ágeis e nossas conclusões estão muito bem alinhadas com as que você apresentou neste artigo. Novamente Parabéns e mantenha o excelente trabalho.

  12. Rodrigo Veiga says:

    Bom post Guilherme. Retrata bem a realidade de aprendizado e evolução a qual nos submetemos aqui durante esses dois anos e que, como você mesmo disse, felizmente não tem fim.

  13. Daniel Wildt says:

    Ninguém falou que ia ser fácil Guilherme! Parabéns!

    Vocês estão nos 25% que seguem usando Scrum (http://www.agilecollab.com/interview-with-ken-schwaber). E muito positivo ver a adoção de práticas de eXtreme Programming, Lean, um ambiente focado a colaboração e qualidade. E claro, de muito trabalho.

    A recompensa é sempre positiva para quem segue no foco da melhoria contínua!

    Segue em frente!

  14. Rafael Lima says:

    Chapiewski, Parabéns!!!

    Esse post está repleto de conhecimento e experiência e foi muito útil para mim. Já passei para todos da Myfreecomm ler!

    Obrigado por compartilhar este conhecimento.

    Um grande abraço.

  15. Fala Guilherme, concordo com tudo que você disse.

    Realmente as mudanças não são fáceis, mas quando se está comprometido com seu dever não se medem os esforços.

    O que mais me chamou a atenção foi esta parte: “…provavelmente o [Santo Graal] da minha empresa será diferente da sua…”

    Você disse “minha empresa”… isso me fez acreditar que está realmente satisfeito em trabalhar na Globo.com

    Abraço

  16. Elton says:

    Belo post Guilherme ! Boa sorte no seu caminho !
    Grande abraço

  17. Guilherme, como sempre digo creio que a Globo.com hoje é o maior exemplo de empresa grande que adotou Agile e vejo que estão indo além. Também odeio pessoas “by the book”, e acho que nós brasileiros podemos criar o nosso estilo de desenvolvimento de software e talvez apresentar alguma inovação verdadeira e não só copiarmos aquilo que vemos lá fora.

    Mantenham o excelente trabalho. Podem ter certeza que vocês influenciam muito o desenvolvimento de software nacional. A Globo.com e você são referência constante nas minhas palestras, treinamentos, mentorings e etc…

    Abraços!

  18. Guilherme, como sempre digo, creio que a Globo.com hoje é o maior exemplo de empresa grande que adotou Agile e vejo que estão indo além. Também odeio pessoas “by the book”, e acho que nós brasileiros podemos criar o nosso estilo de desenvolvimento de software e talvez apresentar alguma inovação verdadeira e não só copiarmos aquilo que vemos lá fora.

    Mantenham o excelente trabalho. Podem ter certeza que vocês influenciam muito o desenvolvimento de software nacional. A Globo.com e você são referência constante nas minhas palestras, treinamentos, mentorings e etc…

    Abraços!

  19. Muito bom o post, parabens.

  20. Welington Veiga says:

    Ótimo texto, é muito bem escrito, claro, e resume vários e vários dilemas no dia a dia do desenvolvimento, tem muito profissional aficcionado por uma forma de desenvolver que perdem mais tempo tentando seguir as regras do que ganham por ficar ‘na linha’.

  21. Norberto says:

    Excelente o post.Eu espero que um dia eu consiga também conscientizar as pessoas da minha equipe e quebrar as regras.

  22. Po Chapa!
    Agora que voltei? Injusto :P
    Boa sorte e que você continue sendo esse cara gente fina e carismático.

  23. Leonardo Quixadá says:

    GC,

    É um post maduro e sábio. Por isso acredito que humildade é importante: abre espaço para comunicação, estimula a confiança e se beneficia disso com troca de conhecimentos.

    No entanto, tenho uma consideração à respeito do que você disse sobre “o foco das pessoas deve ser o produto, não a sua função”. Existe uma linha tênue entre “não gostar de fazer” e “não fazer.”

    No meu primeiro contato com Scrum, acreditei que iria conhecer gente que gostava de tudo um um pouco, que amava o processo de desenvolvimento como um todo: experiência do usuário, testes de QA, programação orientada a objeto, criação de telas, negociação com o cliente, etc. Mas a realidade, como é de praxe, se desdobra de forma diferente. De fato, muita gente gosta de trabalhar com muitas coisas mas cada profissional tem suas aptidões e limitações. Se um DBA não gosta de criar layouts, não podemos forçá-lo a isso. Se um arquiteto não gosta de programar, não vamos criar expectativas. Não estou julgando se isso está certo ou errado. É apenas como as coisas são e temos que saber lidar com isso.

    No final do dia (agora concordando com vc), o que importa é se este profissional vai “marcar o gol” na hora em que o time precisar e isso sim vai revelar o quanto ele se importa com o produto.

    Um grande abraço.

  24. [...] Guilherme Chapiewski Blog sobre desenvolvimento de software e tecnologia « 2 anos de Scrum e Agile na Globo.com e algumas coisas que eu aprendi [...]

  25. [...] para mudar uma empresa tão tradicional como a Globo e de ter trabalhado diretamente num dos maiores exemplos de mudança organizacional e adoção de metodologias ágeis do Brasil. Trabalhei nos produtos de maior audiência da Internet brasileira, entreguei dezenas de projetos [...]

  26. Gostaria de agradecer por esse artigo(depoimento)… Há alguns minutos atrás eu tinha alguns receios quanto ao desenvolvimento de projetos.. E sabe graças a pessoas como você, que se dedicam a escrever um relato pessoal e profissional, que faz com que uma busca aleatória no tweeter sobre scrum.. Se tranforme em mais um motivo para empreender seus projetos de forma mais animadora.
    Meu nome é Tayshiro e tenho 23 anos estou começando agora meu empreendimento e agradeço sinceramente pelo seu artigo me motivar.
    Nada é por acaso. Muito sucesso na sua jornada!

  27. AkitaOnRails says:

    Grande Chapiewski, vai fazer estragos no Yahoo! :-) Eles fizeram uma excelente aquisição, e com certeza vamos continuar ouvindo falar muito de você.

    Excelente artigo, resumiu muito bem o que todo agilista já deveria saber. Pior ainda: tem muita gente que “acha” que entende ágil e não sabe o primeiro parágrafo do que você escreveu, o que é bem triste. Qual é a palavra logo do primeiro valor do manifesto Ágil que não as pessoas não entendem!? “_Pessoas_ em vez de Processos”! C’mon guys! :-)

    Continue evangelizando as boas práticas. Nos vemos por aí, Congratz! :-)

  28. Muito bom!

    Sempre quando lemos sobre determinado assunto ficam lacunas que só aprendemos na prática.
    Este artigo apresenta de forma clara muitos dos desafios que enfrentamos (e continuamos enfrentando) aqui na WebGoal.

    Reafirmo “o foco são as pessoas”. É difícil achar as pessoas certas, muitas vezes trabalhoso “evangelizá-las com as boas práticas” (citando o Akita!) mas são as pessoas que fazem a diferença.

    Abraço!

  29. Alexsandro says:

    Muito bom seu depoimento. Parabens.

  30. Alexandre Negrão says:

    Muito bom artigo. Muito bom mesmo! Fazia tempo que não lia algo do tipo.

    Cheers!

  31. Paulo Igor says:

    Muito loko esse post, parabéns Guilherme!

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

  33. MarcRic says:

    Guilherme,

    Como sempre, este seu post deixou grandes mensagens.

    Muito legal compartilhar esta experiência, que sem dúvida pode servir para abrir os olhos de muitos.

    Gostei muito da mensagem final, me identifico muito com ela:

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

    Grande Abraço.

  34. Gostei do teu jeito realista de por os fatos na mesa.
    Parabéns!

  35. Jandir Bezerra says:

    Um excelente depoimento. Arriscaria até dizer que profissionais de outras áreas deveriam ler. Pois acredito muito que determinados “gargalos processuais” podem ser eliminados adotando ações pontuadas nesse texto.
    Uma colega de trabalho me passou o link para leitura e já distribuiu para o restante da equipe. Estamos começando a trabalhar com metodologia Ágile agora, e ler este tipo de artigo nos ajudará muito.
    Parabéns!

  36. Sandra says:

    interessante, mesmo! concordo muito quando dizes, que quando adoptamos uma metodologia, não pode ser cegamente, como se fosse resolver todos os nossos problemas, e quando não dá certo querer culpar a metodologia!
    bjos

  37. [...] Vitória (Maré Vix, para os íntimos =P). O evento contará com nomes como Guilherme Chapiewski (Gerente de Desenvolvimento de Softwares no Yahoo! Brasil e um dos principais responsáveis pela impl…) e Guilherme Silveira (líder técnico da Caelum, responsável pelo conteúdo técnico dos cursos e [...]

  38. Ana Aquino says:

    Guilherme,

    Muito obrigada por compartilhar sua experiência lúcida e abertamente.
    Excelent post!

    Ana Aquino.

  39. Thiago Ghisi says:

    Guilherme, Sensacional!

    Compartilho de 100% dessas suas licões aprendidas que também aprendi, ou melhor, ainda estou aprendendo, sentindo na pele.

    Em Setembro de 2009 comecei a trabalhar oficialmente lá na empresa com melhoria de processos à la CMMI. (mesmo conhecendo XP desde 2007).

    E, eu também não tenho uma história muito romântica para contar até porque hoje nossos processos/projetos ainda estão centenas de vezes piores do que eu gostaria que eles estivessem. E eu também imaginava que a melhoria era uma coisa que eu iria perceber rapidamente, mas só hoje consigo ver o resultado do que foi mudado 1 ano atrás.

    Alguns centavos meus sobre alguns pontos que você fala no post:

    * Melhoria Empírica Contínua – Assim como você eu também aprendi que Melhoria de Processos (ou Mudanças Organizacionais) é uma atividade altamente empírica, isto é, baseada na experiência e na observação, metódicas ou não. Não tem como acertar da primeira vez. Você pode ficar 6 meses desenhando um processo, pensando em todos os prós e contras, apresentando a todo mundo, validando com todos mas você só terá um retorno quando a galera efetivamente colocar a mão na massa. Pode ser utilizando Agile, pode ser utilizando qualquer coisa, inclusive o CMMI. É usar/falhar, aprender/melhorar e usar novamente…

    Ou melhor, “Você sempre estará em transição.” = Melhoria eterna de tudo, esse é o tema e o lema.

    O próprio IDEAL Model do SEI deixa bem claro isso e só hoje eu entendo e enxergo o valor do que tem lá: http://www.sei.cmu.edu/library/abstracts/reports/96hb001.cfm (Pode me metralhar! Mas, eu acho o modelo IDEAL fantástico.)

    * Pessoas e Ambiente – Aprendi que quando você é o responsável por processos ou por conduzir mudanças a nível organizacional e não tem autonomia nenhuma para aumentar salário de algumas pessoas e demitir algumas fica bem complicado vencer a resistência delas a mudanças. Para ambiente é a mesma coisa.

    * Projetos inovadores – Desestabilizam tudo! Não tem jeito.

    * Práticas de engenharia – Se você não usa você não faz software você faz alguma coisa que poderá simular um software mas não um software de verdade.

    * Santo Graal – Nem Agile, nem CMMI, nem RUP, nem Kanban. (Não existe, ou melhor, quando você encontrar não deixe de me avisar para mim poder quebrar esse teste em uma ambiente diferente do seu com pessoas, tecnologias e restrições diferentes) Se o Santo Graal existe é em determinado lugar, para determinado tipo de projeto, para determinado tipo de funcionalidade e para um determinado número de pessoas.

    *”As pessoas são mais importantes que o processo. Foco nas pessoas.” Para essa lição aprendida fica duas frases clássicas de dois mestres:

    - Grady Booch (um dos “pais” da UML e da Orientação a Objetos) disse: “Pessoas boas com um bom processo sempre superam pessoas boas com um mau processo. Mas nada substitui pessoas boas.” //Eu gosto muito dessa frase dele.

    - Walker Royce (“pai” do processo cascata): “Pessoas, processo e ferramentas. Essas são as coisas onde as empresas devem investir dinheiro, nessa ordem, se quiserem aumentar as chances de sucesso dos projetos de software.”

    Mesmo 1 ano e meio depois esse post fica a cada dia mais atual e é de leitura obrigatório a todos que querem algum dia mudar alguma coisa na empresa em que trabalha.

    Mas, é isso aí. Aprendendo hoje para mudar de opinião amanhã. (Sempre em Melhoria Constante, ou melhor, Eterna, para dar mais ênfase) :)

    Valeu por compartilhar!

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

  41. [...] Ágil 5) Entrevista com Rodrigo Yoshima em Kanban no dia a dia: contexto e relação com Agile 6) Post do Guilherme Chapiewski de 2009 contando suas experiências no desenvolvimento ágil quando tr… 7) Minhas palestras: Scrun? WTF? e Scrum antes, durante e depois (com [...]

Leave a Reply