Posts Tagged ‘Scrum Master’

Yahoo! procura Ninjas

Thursday, January 14th, 2010

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. :)

Como estamos indo com a adoção de Scrum na Globo.com

Tuesday, May 27th, 2008

Muita gente têm me perguntado como estamos indo atualmente com a adoção do Scrum na Globo.com. Acho que já é hora de falar alguma coisa sobre isso. Esse não é um case oficial assinado pela Globo.com, são apenas alguns relatos do meu ponto de vista sobre o assunto.

Nossa história no início foi bem parecida com as histórias tradicionais. Sabe aquelas empresas que gastam uma semi-fortuna com uma consultoria para desenhar um processo de desenvolvimento de software? Assim estávamos nós no início de 2007. Poucos projetos eram entregues nas datas acordadas e muitos deles falhavam ou não satisfaziam as necessidades dos clientes. Contratar uma grande consultoria de software parecia ser uma boa tentativa de arrumar as coisas, mas o resultado do trabalho foi um documento que descrevia um processo com algumas centenas de páginas que devia ser seguido á risca, isso sem contar as dúzias de documentos padrão para todos os tipos de requisição e comunicação que se possa imaginar. Dezenas de páginas descreviam quem deveria falar com quem e quem entrega qual documento em qual momento. O processo foi feito para lidar com todas as complexidades, burocracias e exigências que nós mesmos criamos dentro da empresa.

Resumindo a história, isso não funcionou na Globo.com e acho que existem poucas chances de algo tão complexo assim funcionar em algum lugar. E por incrível que pareça, no fim das contas ninguém havia pensado em nada para resolver o problema principal: como entregar o software que nossos clientes querem no menor tempo e com a maior qualidade possível?

Um pouco de história

Ao contrário do que acontece em muitas empresas, as metodologias ágeis na Globo.com vieram de baixo para cima. Tudo começou com um movimento tímido entre alguns desenvolvedores de aplicar práticas de desenvolvimento ágil do XP (Extreme Programming) nos projetos. A porta de entrada foi a oportunidade de melhorar a qualidade dos nossos sistemas, pois tinhamos uma incidência muito grande de bugs em produção e poucas aplicações eram testadas adequadamente.

Alguns desenvolvedores mais experientes começaram a desenvolver usando desenvolvimento guiado por testes (TDD), e com isso houve uma melhora nítida na qualidade do que era entregue. Aos poucos, enquanto isso acontecia, algumas seções de programação em par aconteciam de vez em quando para difundir o conhecimento e ensinar a técnica a outros programadores, mas ainda de forma muito tímida e sutil (afinal às vezes é difícil convencer que dois programadores fazendo apenas um código é uma coisa boa).

Em seguida foi a vez de organizar as demandas de clientes e os ciclos de desenvolvimento. Lembro-me de ter colocado nessa época o mesmo software em produção quatro vezes em duas semanas, e depois disso o mesmo software foi trabalhado durante dois meses para só depois poder ir novamente para produção. Para piorar, nossos clientes nos traziam todo tipo de demanda que se pode imaginar, sempre em lotes e com prioridade máxima. Por exemplo, acontecia frequentemente do mesmo cliente demandar cinco coisas e todas elas com máxima urgência. Resumindo, os ciclos de planejamento, desenvolvimento e entrega eram totalmente irregulares e afetavam o desempenho de toda a equipe. Explicando todas as dificuldades que tinhamos para nos organizar nesse caos, conseguimos acordar que fariamos entregas constantemente de duas em duas semanas, e que dentro desse período não haveria nenhuma mudança no planejamento, que seria feito no início de cada período. Antes de iniciar cada ciclo de desenvolvimento, os clientes tinham a oportunidade de escolher quais seriam as prioridades da equipe de desenvolvimento nas duas semanas seguintes. Sem perceber eles haviam aceitado a idéia de desenvolvimento iterativo e jogo do planejamento, e nós teriamos alguma organização e paz para fazer o trabalho.

Em meados de Julho de 2007 a empresa decidiu bancar um curso de Scrum com o Boris Gloger para alguns membros da nossa equipe e o resultado foi ótimo! Na semana seguinte mesmo já começou a mudança. Todos voltaram com um novo gás e dispostos a mudar a empresa. Me lembro de nessa época alguém ter falado a seguinte frase: “Agora eu acredito em desenvolvimento de software”.

Desse momento em diante passamos a aplicar Scrum no nosso time de desenvolvimento. O problema é que estávamos no meio de um projeto feito da forma “tradicional” (leia-se waterfall) e toda a fase de análise e especificação já tinha sido concluída. Tudo indicava que seria melhor esperar uma oportunidade melhor para começarmos a adoção, só que nós sabiamos que tinha que ser “naquela hora ou nunca” e então começamos a desenvolver nosso principal projeto usando práticas do Scrum.

Quase ninguém na equipe havia trabalhado com desenvolvimento ágil, então achamos que seria mais fácil não falar de Scrum, XP ou qualquer nome diferente. Simplesmente começamos a praticar e durante o desenvolvimento o time foi introduzido às práticas e à forma de trabalhar. As regras são muito simples e por isso foi muita fácil de adotá-las. Ao longo dos cinco Sprints o time foi amadurecendo, entendendo como trabalhar e também foram nascendo algumas adaptações necessárias ao funcionamento do projeto dentro da estrutura da empresa. Por exemplo, tivemos que resolver como seriam criadas as histórias e como isso seria integrado com o nosso sistema de tracking, como integrar com a equipe de QA, como colocar os projetos em produção e diversas outras questões. O Phillip falou bastante sobre essa fase introdutória no seu blog no ano passado.

Hoje, o Globo Vídeos 4.2, que é o tal projeto, está em produção. Para os padrões da empresa na época, ele foi um projeto surpreendente do ponto de vista de qualidade. Na versão anterior do Globo Vídeos (4.0) foi necessária uma janela de mais de 24 horas para colocá-lo no ar e ela aconteceu aos trancos e barrancos. Além disso a semana seguinte foi infernal, com muitos bugs para serem corrigidos e várias mudanças arriscadas durante o dia para corrigi-los. Já a versão 4.2 foi colocada em produção em pouco mais de uma hora e na primeira semana nem ouviamos falar do Globo Vídeos. Nem parecia que um dos sites de maior audiência da empresa havia sido quase totalmente substituído por um totalmente novo e com grandes mudanças arquiteturais!

Ao mesmo tempo que acontecia o Globo Vìdeos, o site de inscrições para o Big Brother Brasil 8 foi desenvolvido de cabo a rabo usando Scrum, da forma estrita, como está nos livros. O projeto simplesmente não teria sido feito considerando-se a complexidade e o tempo disponíveis. No final, ele foi um sucesso e além de ter sido entregue no prazo houve uma percepção de muita qualidade por todos – mais uma prova viva de que o Scrum era uma possível resposta para os nossos problemas. O Danilo inclusive fez uma apresentação sobre esse projeto na semana passada num evento do C.E.S.A.R. em Recife.

Esses dois projetos serviram de aprendizado e base para a estruturação de todos os projetos seguintes na empresa. O sucesso deles foi o grande responsável para ganharmos carta branca e começarmos a implementação de Scrum em massa na Globo.com.

Como estamos hoje

Após um ano de metodologias ágeis a empresa já está bem mais madura nas práticas e já temos mais de 10 times usando Scrum.

No fim do ano passado, após um treinamento para pessoas de todas as áreas da empresa, começamos todos a usar Scrum da forma estrita (obviamente houve uma curva de aprendizado até todos estarem mais seguros e praticando melhor). Hoje, alguns meses depois, já é possível perceber diferenças entre alguns times, que acabaram se adaptando de forma diferente por terem problemas e questões diferentes.

Sobre a duração dos Sprints, estamos trabalhando com duas semanas porque achamos que quatro semanas é muito tempo e poderiamos acabar nos tornando lentos na resposta às mudanças. Além do mais já vinhamos usando iterações de duas semanas desde que começamos a adotar desenvolvimento iterativo e continuar com este tamanho de ciclo seria mais fácil para nós.

Em virtude disso, como temos a metade do tempo de desenvolvimento recomendado pelo Scrum, decidimos que só precisamos da metade do tempo de planejamento. A recomendação é que o Sprint Planning tenha 8 horas para um Sprint de 4 semanas, e como nosso Sprint é de 2 semanas decidimos fazer um planning de 4 horas. As outras reuniões (Sprint Review, Retrospective, Daily Scrum, etc) permaneceram com a mesma duração, lembrando que essa duração não é obrigatória mas sim um limite para não ficarmos discutindo as coisas indefinidamente.

Nossos Sprint Plannings têm melhorado constantemente. No início sempre estouravamos o tempo da reunião discutindo um monte de coisas que não eram necessárias mas agora já estamos mais focados e a reunião tem funcionado bem melhor. As estimativas com planning poker também evoluiram um bocado e em várias ocasiões todos os desenvolvedores colocam o mesmo número sem combinar, o que indica que estamos evoluindo na sensação de esforço necessário para desenvolver as coisas.

A equipe, que antes era só de desenvolvedores, agora tem também um designer, um arquiteto de informação, um especialista em programação client-side (JavaScript/CSS/HTML), uma pessoa da equipe de testes e homologação e uma pessoa focada em negócios e ROI (que é o Product Owner). Todas essas pessoas sentam próximas umas das outras, e isso efetivamente aumentou muito a produtividade delas e o ritmo do projeto. Aos poucos todo o conhecimento específico está sendo difundido entre os membros da equipe. Infelizmente nem todas as equipes estão completas dessa forma por diferentes motivos (espaço físico, distância entre os prédios da empresa, etc), mas estamos trabalhando duro para resolver isso. Inclusive temos uma reunião chamada de Scrum Of Scrums, onde todos os Scrum Masters se reunem para se ajudarem a resolver esses tipos de problemas, que muitas vezes são comuns a várias equipes.

Já que o Scrum não fala nada sobre práticas de desenvolvimento de software, acabamos adotando muitas práticas do XP. Isso fica por conta de cada equipe e cada uma faz o que julga mais adequado para entregar o melhor software possível, mas muitas equipes usam desenvolvimento guiado por testes, integração contínua, programação em par, metáforas e várias outras práticas de Extreme Programming com muito sucesso. De fato a integração entre Scrum e XP funciona muito bem.

Definimos o nosso conceito de “done” (finalizado), que é a parte mais divergente entre as equipes. Na equipe de desenvolvimento de vídeos (minha equipe), uma história ou funcionalidade está pronta quando foi desenvolvida (incluindo testes unitários), integrada à base de código, testada novamente (fazemos testes de aceitação com critérios definidos no Sprint Planning ao criar as histórias) e homologada. Como nosso time tem uma pessoa da área de QA, podemos incluir a homologação da aplicação dentro do Sprint (nem todos os times fazem dessa forma).

Temos na empresa uma equipe que é especializada no ambiente de produção e por isso colocar os sistemas no ar fica fora do nosso Sprint. Quando nosso Sprint termina, entregamos um pacote fechado, testado, homologado e pronto para ser colocado em funcionamento, e então agendamos uma data e hora para que a subida seja feita acompanhada por um ou mais desenvolvedores do time. Todas as alterações de arquitetura e ambiente de deployment, quando necessárias, são feitas dentro do Sprint, somente as mudanças que envolvem risco de indisponibilidade nos sistemas que são feitas numa data que agendamos após o termino do Sprint, geralmente no meio da madrugada (as famosas “janelas”). Alguns times, por terem menos criticidade no seu ambiente de deployment, consideram que um Sprint está concluído quando o software está no ar, e o seu último dia do Sprint sempre é uma subida para produção. Como já havia falado anteriormente, cada time se adaptou para funcionar da melhor forma possível de acordo com suas peculiaridades.

E por último, nossas retrospectivas têm sido uma base forte para adaptações no processo e na forma de trabalhar. Para mim foi um aprendizado enorme quando o Boris Gloger veio na Globo.com e acompanhou uma retrospectiva inteira do nosso time – ele deu excelentes toques importantissimos. A última retrospectiva em especial, que aconteceu após uma grande entrega de um projeto interno, mostrou nitidamente a evolução do time e como estamos efetivamente conseguindo aos poucos achar e resolver todos os problemas. Estamos evoluindo devagar mas constantemente e já temos várias equipes com um bom nível de maturidade e evolução na empresa.

Concluindo…

Não só o Scrum como todos as metodologias ágeis dependem muito das pessoas. Na Globo.com não foi diferente e as pessoas certas fizeram toda a diferença. Também existe o outro lado da moeda: algumas pessoas simplesmente não se adaptam a essa forma de trabalhar. Desde o início da adoção nós já perdemos muitos desenvolvedores e acredito que ainda perderemos muito mais. Por conta disso nossos processos seletivos se tornaram mais exigentes e demorados, porque agora não só precisamos de pessoas que sejam ótimas tecnicamente mas também que tenham um perfil adequado para trabalhar no tipo de ambiente que criamos dentro da empresa.

Além disso é essencial que haja apoio da gerência e “carta branca” para que as equipes de desenvolvimento tenham a autonomia necessária para levar o projeto da forma correta. Como estes “processos” são muito diferentes dos tradicionais, algumas empresas acabam fazendo modificações antes do tempo por puro medo ou falta de conhecimento, que acabam atrapalhando ou até mesmo arruinando a adoção de uma metodologia ágil. Ainda em relação aos times de desenvolvimento, é essencial que os líderes de equipe (ou Scrum Masters no caso do Scrum) sejam muito bem capacitados e que conheçam profundamente as práticas/regras/princípios, não só para que tenham capacidade de argumentação com a empresa mas também para que não façam adaptações que violem os princípios básicos das metodologias ágeis.

Por fim, acho que ainda estamos muito longe do ideal e vejo muitas oportunidades de melhoria na nossa forma de trabalhar, mas o mais importante é que agora acreditamos que estamos no caminho certo.

Perfil de um líder técnico

Saturday, May 10th, 2008

No mês passado eu havia escrito sobre como eu acredito que um Scrum Master deve atuar em um projeto de software, e o Phillip complementou em seguida com mais alguns pontos, não se restringindo apenas a Scrum Masters mas líderes de processos ágeis em geral.

O Patrick Kua postou agora há pouco sobre o que ele acredita que sejam algumas das responsabilidades de um líder técnico e colocou um link para um “Tech Lead Manifesto” escrito por Sam Newman em 2006:

A Tech Lead Should…

  • Ensure the creation of a clear and consistent technical vision for the project which can best result in a successful project
  • Ensure all members of the team have a proper understanding of the technical vision
  • Ensure that the technical vision updates to reflect new requirements
  • Track and resolve issues where the code deviates from the technical vision
  • Create an environment in which all members of the team can contribute towards the technical vision
  • Understand and address skills gaps in the team which would result in difficulties implementing the technical vision

A Tech Lead Should Not…

  • Tell everyone what to do
  • Necessarily be the best at everything
  • Write no code
  • Write all the hard code

Esse manifesto resume muito bem algumas características altamente desejáveis para líderes de times de desenvolvimento de software e é totalmente aderente a todas as metodologias ágeis, incluindo o Scrum.

Fica como complemento para a discussão anterior.

Scrum Master técnico?

Sunday, April 6th, 2008

Há algum tempo que tenho pensado muito sobre o que um Scrum Master pode/deve ou não fazer dentro de uma equipe Scrum.

Lendo vários livros e artigos sobre o assunto, percebi que todos eles enfatizam várias características do Scrum Master. Ele deve ser influente dentro da empresa, corajoso, comprometido com o projeto, deve ajudar o time a entender as práticas do Scrum e assegurar que elas não sejam violadas, dentre outras coisas.

O Scrum Master não precisa ser técnico. Todas as tarefas principais exigidas pela função podem perfeitamente ser realizadas por uma pessoa sem nenhum conhecimento técnico. Porém isso não significa que é ruim quando ele tem conhecimento técnico e usa-o em favor do time ou do projeto. Mais do que isso, acredito fortemente que os melhores Scrum Masters necessariamente devem ter conhecimento técnico e do negócio, pois isso os ajuda a entender melhor os problemas do projeto e ajudar melhor o time.

Essa não é uma opinião só minha. Mike Cohn, um dos grandes nomes do mundo ágil, escreveu no ano passado um artigo sobre o que ele considera que sejam as seis principais características dos melhores Scrum Masters. Uma dessas características é:

Knowledgeable

The best Scrum Masters have the technical, market, or specific knowledge to help the team in pursuit of its goal. LaFasto and Larson have studied successful teams and their leaders and have concluded that “an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed.” Lockhart, K. 2006. Responsibility Junkie. Harvard Business Review (October): 30.

A princípio o Scrum Master não deve estar comprometido com tarefas dentro do projeto e deve evitar se intrometer tecnicamente. Primeiro, porque impedirá que ele se concentre em resolver os impedimentos e problemas que estão no caminho do time, que no início da adoção são muitos e muito graves. Segundo, porque ele pode acabar tirando o compromisso do time. Ele pode acabar tomando decisões que nem todos concordam exatamente, mas farão porque alguém acima na hierarquia determinou e aí voltamos ao gerenciamento command-control onde as pessoas só fazem o que são mandadas. Para evitar esses problemas, no início da adoção é recomendável que o Scrum Master siga as recomendações e as práticas à risca e que se concentre em cuidar só disso.

Porém, vejo que depois de um certo tempo o time e o Scrum Master se adaptam tanto à empresa e a forma como ela trabalha (assim como a empresa se adapta às necessidades do time) que o time precisa cada vez menos do Scrum Master. Ele continuará sendo necessário na hora em que aparecerem problemas fora do alcance do time, mas penso que isso aconteça na menor parte do tempo e cada vez menos. O time e a empresa amadurecem sua relação e evoluem tanto que o time entra num ritmo de alta produtividade e sofre cada vez menos interferências.

E quando isso acontecer o Scrum Master deverá ficar sentado esperando o próximo problema/impedimento a ser resolvido? Certamente isso não seria bom para a empresa.

Todos os Scrum Masters ou líderes de projeto que conheço são pessoas excelentes tecnicamente. Muito modestamente e humildemente falando, eu me incluo neste grupo. Eu e todos esses líderes/Scrum Masters que conheço chegaram nesta posição por terem sido ótimos técnicos e se destacarem entre os demais. Como é que se pode ignorar este fato e pedir que eles simplesmente deixem de fazer o que mais sabem? Porque o Scrum Master não pode trabalhar com impedimentos técnicos? Ou programar? Desde que se concentre primariamente em exercer seu papel de Scrum Master, que não atrapalhe o time e que não atrapalhe o projeto, é totalmente aceitável que ele faça isso. Aliás, nenhum livro sobre Scrum fala o contrário.

Hoje, por exemplo, eu diria que uso metade do meu tempo exercendo ativamente o papel de Scrum Master. Na outra metade, eu não fico parado esperando o próximo problema acontecer.

No último Sprint do meu time, por exemplo, trabalhei para resolver um impedimento técnico gigantesco do próximo Sprint. Estamos no meio de um projeto importante para a empresa e a história que talvez seja a mais importante de todas acabou ficando de fora do Sprint. Já é certo que ela será a primeira história do próximo Sprint, porém, existe um grande impedimento técnico relacionado à forma como funciona uma API de busca interna da empresa, e eu trabalhei para contornar este problema e o time possa trabalhar tranquilamente na próxima semana. Outro exemplo, foi quando parei uns três dias para reconfigurar todo nosso ambiente de integração contínua e fazer um refactor agressivo no build. Ou então, para não desfocar o time do seu trabalho, eu resolvo silenciosamente vários bugzinhos chatos.

Muitas pessoas discordam dessa atitude simplesmente porque eu tive que codificar alguma coisa. Mas eu não estou facilitando o trabalho do time? Não estou resolvendo problemas e fazendo com que o time só precise se concentrar em entregar seu trabalho? O Scrum é um framework onde a cada período de desenvolvimento temos oportunidade de avaliar o que fizemos e nos adaptarmos às circuntâncias do projeto/time/empresa. Refletindo sobre o meu trabalho, percebi que se eu me adaptasse para trabalhar desta forma poderia contribuir muito mais com o time e a empresa do que simplesmente fazendo o feijão-com-arroz do Scrum.

Coincidentemente (ou não), o Phillip Calçado escreveu um post que vou usar como argumento para outro ponto importante. O manifesto ágil, base para todas as metodologias ágeis que conhecemos, coloca pessoas acima do processo. Ou seja, o processo importa menos do que as pessoas que participam dele. Parafraseando o Phillip, você não pode fazer que o processo –ágil ou não- vença à razão e você tenha um desenvolvedor (ou Scrum Master) completamente desestimulado e frustrado na equipe. Mais ainda, você não pode fazer com que o processo deixe de lado pessoas técnicas altamente capazes.

A verdade é que não existe uma regra. Você faz a regra, mas faça com consciência e sabedoria.

Certified Scrum Master!

Monday, December 10th, 2007

Curso de ScrumNa última semana tive a oportunidade de assistir ao treinamento de Scrum da Sprint iT. O instrutor foi ninguém menos que Boris Gloger, que foi o primeiro Scrum Master treinado pelo Ken Schwaber em pessoa!

Nem preciso dizer que o curso foi sensacional – fora o fato de ter me tornado o mais novo Scrum Master do pedaço! O Boris têm uma didática excelente e tive a oportunidade de tirar várias dúvidas que vinham me perturbando há algum tempo. Apesar de já ter lido alguns livros sobre Scrum esse treinamento conectou vários conhecimentos na minha cabeça e eu me sinto agora com uma visão clara como cristal de como tudo funciona.

Para ter uma idéia melhor de como é o treinamento você pode ler dois posts do José Papo resumindo a agenda e dando suas opiniões em seguida.

O curso é cheio de surpresas e eu não vou contar nada aqui para não estragar a experiência. Mas o ponto é que através de exemplos extremamentre simples e didáticos a mensagem é transmitida. É impossível não sair da sala no fim do dia extremamente motivado a mudar!

WUFF!