Desde 1º de Janeiro de 2012 estão valendo as novas regras para o exame de certificação para Scrum Master (CSM), de acordo com o comunicado da ScrumAlliance.org. O objetivo é o de tornar o processo mais rigoroso.

Assim, as novas regras são:

• O Content Outline and Learning Objectives — a base para a estrutura e conteúdo do novo exame de CSM — está disponível para download no site da Scrum Alliance.
• Todos os candidatos que prestarem o exame até o dia 31 de Março de 2012 serão automaticamente aprovados.
• A partir de 1º de Abril de 2012, os candidatos serão aprovados ou não de acordo com o seu desempenho no exame.
• A partir de 1º de Abril de 2012, os candidatos terão 60 dias para duas (2) tentativas gratuitas de aprovação. Após este período de 60 dias, o candidato deve pagar US$25 por tentativa. Após três (3) tentativas sem aprovação, é recomendado que o candidato faça um outro treinamento de CSM antes que sejam permitidas novas tentativas.
• O novo exame terá 35 questões, sem limite de tempo. Os candidatos poderão marcar questões, mudar as respostas das questões e até mesmo interromper o exame, retornando a ele posteriormente dentro do prazo de 60 dias.
• Ao final do exame, o candidato verá as questões respondidas incorretamente. A lista de opções não será exibida. Isto para encorajar os candidatos que não passarem na primeira tentativa revejam o conteúdo do curso antes de uma nova tentativa.
• Candidatos que não sejam aprovados na primeira tentativa podem refazer o teste imediatamente (não é necessário um período mínimo) ou a qualquer momento dentro do período de 60 dias.
• Depois de aprovado, o candidato pode renovar sua credencial a cada dois anos. A Scrum Alliance criará até Janeiro de 2013 o programa de Professional Development Units (PDUs). Os CSMs deverão obter estes PDUs para manter suas certificações. Maiores detalhes sobre o programa de PDUs serão informados em breve.

Boa sorte para quem ainda vai prestar o exame e um feliz 2012 para todos!

Tempos atrás, trabalhando em uma multinacional, fui chamado à uma reunião às pressas. Lá estavam o meu gerente, o gerente de parcerias e o rapaz, amigo meu, que foi apresentar um novo projeto que nos ajudaria a aproximar dos nossos clientes: manter um servidor de newsgroups dentro de nossas instalações, independente de nosso servidor mundial.

A ideia em si era muito boa — afinal, teríamos a oportunidade de discutir com nosso público local e obter informações que de outra forma, ficariam perdidas no meio de tantas outras de pessoas no mundo inteiro.

Depois das parabenizações, dos comentários entusiasmados, das possibilidades e oportunidades, pedi um pouco de atenção para alguns detalhes (na época, era, entre outras coisas, responsável por nossa rede interna, o que incluía o link com a internet): nossa conexão com a internet não era boa, e isso poderia aumentar o problema; teríamos que solicitar autorização para a matriz para podermos alterar as configurações dos roteadores… antes que eu pudesse dizer qualquer outra coisa, meu gerente me interrompeu e disse: dá para parar de ser tão negativo?

Por muito tempo evitei dar qualquer opinião sobre qualquer coisa. Era assim que as pessoas me viam, negativo? Eu errei em chamar a atenção para algumas coisas que poderiam impactar no resultado? Infelizmente, sou franco e transparente, mas pelo visto, estava fazendo um de-serviço.

Hoje, muitos livros, palestras e tempo depois, consigo me sentir um pouco mais aliviado. Afinal, Jeffrey Liker no livro “O Modelo Toyota” comenta que é função de qualquer um, quando apresentado a uma nova ideia, atentar aos pontos que precisam ser trabalhados para que a pessoa consiga refina-la antes de apresenta-la aos superiores.

E Jurgen Appelo, em seu excelente livro “Management 3.0″, fala sobre feedbacks positivos e negativos: ciclos de feedbacks positivos causam desequilíbrio, acelerando o sistema para longe do equilíbrio. Ciclos negativos de feedback causam estabilização, mantendo o sistema longe do caos.

Mas e você? Acha que fui negativo e estou achando justificativas? Qual a sua opinião?

Outro dia estava conversando com o @jonasabreu e ele comentou sobre a atual fase em que se encontra a consultoria que ele está prestando em uma empresa. Segundo ele, a parte crítica já havia passado, mas que haviam deixado a salinha de “guerra” onde estavam até então para irem para o “salão comunal” – um enorme salão, sem paredes, onde dezenas de outros desenvolvedores trabalham juntos.

Em treinamentos, consultorias, conversas de bar, etc., sempre que falamos sobre ambiente de trabalho para times, sugerimos que seja um ambiente que propicie muita interação. Programação em par. Conversas. E criar este tipo de ambiente nem sempre é fácil.

No caso do “salão comunal”, a interação é muito maior, inclusive com pessoas que não sejam membros do seu time de desenvolvimento, você pode ter a opinião de muito mais pessoas, sem contar a flexibilidade que um local assim proporciona. Mas por outro lado, por ser um ambiente compartilhado por muitas pessoas, fica muito mais difícil satisfazer a todos – questões como temperatura, som, iluminação podem ser bastante controversos.

Um ambiente assim, para mim, seria o caos. Barulho em excesso ou de forma contínua fazem com que eu perca a concentração e até conseguir retoma-la levo um certo tempo e exige uma boa quantidade de esforço de minha parte. No meu caso, o ambiente que temos na AdaptWorks funciona bem melhor: uma sala com uma mesa enorme, onde cabem até 8 pessoas tranquilamente. E muitos quadros brancos.

E você, qual o ambiente no qual melhor se adequa?

Nesta última terça-feira, 12 de Abril, tivemos mais um Codigo Dojo na AdaptWorks. Claro, a chuva que caiu no final da tarde atrapalhou um pouco, mas mesmo assim tivemos uma boa quantidade de participantes.

Desta vez resolvemos mudar o condutor do Dojo e o escolhido foi o Juliano Alves (obrigado, Juliano).

Jonas e Juliano, apresentando as opções para o problema

Apesar de algumas pessoas reclamarem, parece que Java continua sendo o “common ground” para a maioria dos participantes. Não que seja um problema, mas alguns gostariam de uma pequena mudança, conhecer uma outra linguagem.

Platéia atenta, mas participativa

Algumas pessoas talvez se sintam constrangidas em participar de um Coding Dojo – algumas por não se acharem com conhecimento suficiente ou por acharem que isso é para um nível mais alto de programação. E para estas situações, é importante lembrar que um Coding Dojo não é criado para mensurar o seu “traquejo” na linguagem, e sim mostrar (e usar) boas práticas em programação.

"Pair Programming", uma das práticas mais usadas

Inclusive, na Retrospectiva feita ao final da sessão, um dos comentários positivos foi a diferença positiva sentida quando praticando “pair programming”. E é por aí que as coisas se encaminham.

Sua empresa quer produtividade o tempo todo? Velocidade máxima em tudo?

Cuidado! Ao invés de melhorar, vocês podem estar piorando o cenário!

Isso é resultado do estudo realizado com 343 empresas pela Economist Intelligence Unit, que ao final concluíram que empresas que se lançaram a inciativas sem nenhuma trégua para tentar obter uma vantagem tiveram muito menos lucro e receita operacional que outras que “pararam para pensar”.

Este resultado foi publicado na Harvard Business Review, e corrobora com o pensamento que temos na AdaptWorks. Aliás, é um pensamento totalmente baseado em Scrum, onde de tempos em tempos fazemos uma retrospectiva, onde analisamos como tem sido nosso desempenho e tomamos ações para que a empresa como um todo melhore.

Claro, ainda precisamos melhorar muito, mas pelo menos sabemos que nossa forma de pensar é bastante parecida com a de muitas boas empresas por aí.

E a sua empresa, como ela pensa e age?

Em meu último post, falei um pouco sobre mudanças organizacionais e de como algumas empresas vêm percebendo a necessidade por mudanças nas atitudes, tanto dos dirigentes quanto dos funcionários.

A esse novo tipo de lidarança a imprensa especializada vêm chamando de “liderança sustentável“. E não é somente pela expressão “sustentável” estar muito em voga.

Analisando as necessidades das empresas, ter uma liderança que se sustente por muito tempo ou mesmo entre diferentes “times” (usando o jargão de Scrum), é realmente uma vantagem enorme.

Estas empresas que procuram este novo tipo de liderança não procuram somente “o retorno que o líder pode trazer a curto prazo“. Elas estão mais preocupadas na sustentabilidade da empresa, mesmo que o lucro não seja o maior possível. Este foi um ponto positivo que a crise econômica trouxe — as empresas realmente estão repensando sobre o que é importante ao invés de somente lucro imediato.

Como ScrumMaster (e até antes disso) sempre achei importante a capacitação dos funcionários. Afinal, não basta simplesmente dizer a uma pessoa o que ela deve fazer — é preciso realmente investir nos funcionários e colaboradores, uma vez que eles nos ajudarão a levar a empresa à frente. E mais ainda, eles podem nos ajudar a sempre melhorar nossos processos, uma vez que são eles que vivenciam isso todos os dias (quem leu “Toyota Talent” vai entender).

Quem sabe a partir de agora, pessoas que realmente tenham algo a oferecer às empresas tenham um pouco mais de chances de provar seu valor.

E que venham as pedras.

[img:hbrjun2009.jpg,full,alinhar_esq_caixa]Estive lendo um artigo interessantíssimo na Harvard Business Review sobre foco na confiança, “Chegou a hora de uma cultura da franqueza“, de James O’Toole e Warren Bennis. Interessante porque o artigo justifica muito do que pregamos em Scrum, mais especificamente a questão da mudança organizacional — o que me levou a rever o conteúdo da palestra do Alexandre Magno no Scrum Gathering Brazil 2009.

Em resumo, o artigo ressalta a importância de uma organização em ser sincera com o público, mas para que isso aconteça, é necessário ser sincera consigo mesma primeiro. E ter franqueza dentro de uma organização é muito mais difícil do que parece. Isso porque a maioria das pessoas já está habituada com a sonegação de informação, com groupthink (quando os integrantes de uma equipe não sabe discordar dos colegas), e principalmente, porque boa parte dos líderes não possuem a capacidade de ouvir seus seguidores, o que pode fazer com que se sintam inibidos e não tenham a coragem de contestar o chefe.

Quem trabalha com Scrum sabe a importância da franqueza no dia a dia. Afinal, essa é a base de uma framework colaborativa como Scrum — utilizar a franqueza para relatar impedimentos, no autogerenciamento, nas Sprint Reviews, etc. E é gratificante ver que algumas empresas já enxergam essa necessidade de transparência e franqueza dentro de uma organização.

De acordo com a palestra do Alexandre, para se atingir esta mudança é necessário mudar o comportamento das pessoas. Mas algumas empresas tentam fazer isso através de uma abordagem errônea. Vejamos:

Em 1971, o psicólogo social Philip Zimbardo conduziu um experimento na universidade de Stanford, que posteriormente foi relatado em seu livro The Lucifer Effect. No livro, ele conta como foi o experimento e como ele fugiu do controle: em um porão de um dos prédios da universidade, uma prisão de mentira foi criada e os voluntários foram divididos em dois grupos: um deles faria o papel de carcereiros, enquanto o outro seria de prisioneiros. Entretanto, os voluntários levaram a encenação tão a sério que o experimente teve que ser interrompido no meio. Isso porque os “carcereiros” começaram a cometer abusos físicos e psicológicos contra os “presos”.

A conclusão do psicólogo foi a de que “quase todo mundo está sujeito a passar para o lado do mal, pois a conduta humana é ditada mais pela situação e pela dinâmica do grupo do que pela natureza inerente do indivíduo“. Assim, ao invés das empresas gastarem milhões em aulas de ética na esperança de que as pessoas passem a se portar bem, seria muito mais eficaz criar uma cultura interna que premie o indivíduo que age corretamente.

Por isso, líderes devem sempre se policiar de forma a se manterem abertos a questionamentos e encará-los de forma positiva (ScrumMasters estão incluídos nessa).

O artigo termina dando algumas dicas para se criar uma cultura de franqueza — lembrando que antes de tentarmos mudar alguém ou algo, é necessário mudarmos nossa própria conduta para depois tentar isso externamente:

• Diga a verdade.
• Incentive as pessoas a falar a verdade aos líderes.
• Premie dissidentes.
• Aprenda a travar conversas desagradáveis.
• Diversifique suas fontes de informação.
• Admita seus erros.
• Gere apoio organizacional para a transparência.
• Liberte a informação

Pois é, isso só corrobora a idéia de que estamos trilhando o caminho correto. E você, o que acha?

Quando falamos sobre qualidade em software, surgem diversas dúvidas quanto ao que significa ter qualidade em um software: ter um código bem escrito? Código que não apresente falhas? Boa performance no que se propõe a fazer?

De acordo com a NBR 13596 (ISO/IEC 9126), existem algumas características que um software deve apresentar para ser considerado como um software de qualidade. Estas características são listadas na tabela a seguir:

A maioria das características que determinam um software com qualidade referem-se mais a boas práticas de engenharia de software ou eficiência da plataforma tecnológica. Entretanto, Scrum, como framework para gerenciamento de projetos, também é capaz de oferecer qualidade no processo de desenvolvimento.

Em Scrum, conseguimos uma melhora na qualidade através de diversos pontos. Entretanto, obter esta melhora na qualidade depende muito se Scrum está sendo bem implementado ou não.

Dentre estes pontos, podemos destacar:

• Iterações
• Remoção de impedimentos
• Inspeção e adaptação
• Autonomia
• Times multi-funcionais

Iterações

Qualidade em software também significa entregar para o cliente algo que lhe seja realmente útil, de acordo com suas necessidades.

Por ser uma framework ágil, Scrum trabalha com iterações, onde a cada iteração entregamos software, ou incrementos de software, potencialmente usável e de acordo com a necessidade do cliente. E a cada nova iteração, temos “feedback” do que foi entregue e que utilizamos para melhorar o produto (sempre de acordo com a prioridade do cliente).

O “feedback” do cliente haveria de qualquer forma, seja apresentando o produto ao final de uma iteração, seja ao final de todo o ciclo de desenvolvimento, o que normalmente acarreta em alterações no código. Entretanto, se estas alterações forem feitas no final do projeto, isto também pode acarretar efeitos colaterais indesejados, ao passo quefazê-las de forma antecipada impede este tipo de problemas.

Através das Sprints, times Scrum estão sempre desenvolvendo algo que realmente tenha valor para o cliente.

Remoção de impedimentos

Remover qualquer tipo de impedimento durante a execução de um projeto é essencial não importa qual metodologia seja utilizada. Em Scrum é esperado que estes problemas apareçam. Mas o que é feito após resolver este impedimento determina se um time está utilizando Scrum corretamente ou não.

Durante a execução de uma Sprint, é recomendável que a execução das tarefas seja feita item a item ao invés de cada membro executar tarefas de itens diferentes. Isso tem duas razões: a primeira é relacionada ao valor para o cliente. Para um cliente, um item somente tem valor caso tenha sido entregue completamente — uma funcionalidade que esteja funcionando 80% não lhe trará vantagem alguma. Além disso, executar um item completamente ajuda a manter o foco da equipe na meta e no item em específico. Desenvolvedores em geral tendem a ser mais orientados a tarefas ao invés de orientados a valor. Manter o foco na meta ajuda a aumentar a qualidade do item sendo desenvolvido.

A outra razão é em relação à forma como os problemas são resolvidos e suas correspondentes soluções são utilizadas. A execução completa de um item representa um fluxo completo de execução e faz parte do processo utilizado no desenvolvimento. Neste caso, problemas que poderiam se tornar recorrentes podem ser solucionados imediatamente, permitindo que isso não se repita na execução dos próximos itens. Desta forma estamos aprimorando o processo, o que também reflete na qualidade do produto.

Inspeção e adaptação

Ao final da execução de uma Sprint há a Sprint Retrospective, uma das cerimônias de Scrum. Nela, revisamos a Sprint (inspeção) e determinamos o que foi bom e o que precisa ser melhorado (adaptação). As adaptações podem ser individuais ou coletivas, mas de qualquer forma são uma forma de garantir a melhora do processo e consequente otimização, o que traz diversos benefícios.

Com um processo mais enxuto e mais eficiente, podemos ter um software com mais qualidade.

Autonomia

Times em Scrum são auto-gerenciados, o que significa uma menor pressão sobre eles. Desta forma, cada um dos membros pode selecionar o que fará e terá o tempo necessário parafazê-lo com qualidade. Estudos mostram que, sob pressão de prazos exíguos, a primeira coisa a ser deixada de lado pelos desenvolvedores é a qualidade.

Além disso, através desta autonomia, os membros do time passam a ter uma melhor qualidade de vida, o que reflete em uma melhoria na qualidade como um todo. Isso porque passam a ter mais tempo e disposição para pesquisar uma melhor forma de abordar e executar uma tarefa. Em um ambiente onde Scrum tenha sido bem implantado, este aprimoramento pessoal é compartilhado com os outros membros, o que traz mais incremento na qualidade.

Times multifuncionais

Quando montamos os times, procuramos sempre montá-los com membros que tenham diferentes características ou atribuições. Por exemplo, ao invés de um time formado só por desenvolvedores ou só de analistas de requisitos, procuramosmisturá-los e formar diversos times Scrum.

Isto porque a experiência de cada um é extremamente útil no planejamento das tarefas a serem executadas na Sprint. Entretanto, existe um conceito maior escondido por trás disto: qualidade desde o início.

Pude presenciar em diversas ocasiões a seguinte situação: empresas utilizando o modelo em cascata, faziam o levantamento de requisitos no início do projeto. Em seguida, arquitetos de sistema e especialistas no negócio modelavam as classes para atender a todos os requisitos levantados na etapa anterior. Depois (bem depois, por sinal), estes modelos eram passados para a equipe de desenvolvimento e o resultado era testado pela equipe de Q&A e homologação. No final do processo, isto era entregue à equipe de implantação.

Invariavelmente, o contato com o cliente era feito no início do projeto, onde este apresentava todos os requisitos possíveis e imagináveis para o produto. Embora saibamos que o cliente saiba o que precisa mas tenha somente uma vaga idéia do que quer, ele era obrigado a informar o que desejava que fosse desenvolvido, e por isso a quantidade de requisitos, algumas vezes desnecessários, era imensa.

Durante a modelagem, os analistas modelavam o que era necessário para a aplicação, muitas vezes deixando de lado alguns detalhes que poderiam facilitar o desenvolvimento ou ignorando outros detalhes que pudessem melhorar o acesso aos dados.

Os desenvolvedores, por sua vez, simplesmente executavam o que foi determinado pelos arquitetos e no prazo determinado pelo gerente de projeto.

Depois de devidamente codificado, o resultado era passado para a equipe de Q&A, que testava o que tinha sido produzido e retornava o resultado dos testes à equipe de desenvolvimento. Infelizmente, isto era feito invariavelmente aos lotes — os testadores eram obrigados a testarem diversos recursos de uma vez, muitas vezes impossibilitando testes com aspectos mais amplos.

Como tudo isso feito às pressas, em algumas situações, a equipe de implantação era informada com poucos dias de antecedência (e em uma situação, a equipe foi informada que tinha até o final da tarde para implantar um sistema). Com tão pouco prazo, muitas vezes a implantação era feita sem qualquer teste, simplesmente esperando que a sorte sorrisse para eles.

Note que os cinco parágrafos anteriores descreveram cada um dos estágios no desenvolvimento. E isto reflete como o desenvolvimento era feito — sem qualquer comunicação adicional entre cada uma das etapas que não fosse a documentação do sistema. É fácil descobrir o resultado disso.

Através de times multifuncionais, a cada Sprint temos a opinião de especialistas em diferentes áreas definindo o que será feito naquela Sprint. Enquanto não sabemos o que o cliente realmente quer como produto, sabemos o que é mais importante para ele, com estes especialistas definindo a melhor abordagem possível, levando em consideração os aspectos nos quais cada um é melhor. Assim, arquitetos podem começar definindo as classes levando em consideração a opinião de um especialista em banco de dados, de domínio, etc.

Utilizando o princípio de qualidade desde o início, o código tende a ser mais enxuto, mais adaptável, a ter mais performance. Como a interação com o usuário é constante, o produto estará sempre de acordo com a necessidade do usuário. E com a presença de um especialista em testes, cada tarefa executada já pode ser testada e eventualmente corrigida rapidamente.

E finalmente, um especialista em implantação já sabe antecipadamente o que deve testar e providenciar como ambiente de produção.

Conclusões

Existe uma beleza singular na simplicidade apresentada por Scrum. Entretanto, por trás desta simplicidade, existem conceitos que não devem ser ignorados, sob pena de obter somente parte dos benefícios de Scrum.

Um ScrumMaster deve estar sempre atento aos diversos sinais que o time apresenta, bem como motiva-los e desafia-los, sempre em busca constante do aprimoramento individual como seres humanos e o time como um todo. Além disso, buscar a melhoria contínua do processo permite que a qualidade passe a ser uma constante em futuros projetos de software.