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.

Informações por adaptworks.com.br

Figura 1: Ciclo de um release em SCRUM (Mountain Goat 2011)

Existem três papéis principais que o compõem: a Equipe, Product Owner e Scrum Master.

• Equipe: Responsável por entregar soluções. Geralmente é formada por um grupo pequeno (entre 5 a 9 pessoas) multifuncional e que trabalha de forma autogerenciada e auto-organizada.

• Product Owner: Responsável pela visão de negócios do projeto. Cabe a este papel definir e priorizar o Product Backlog. Geralmente é o papel desempenhado pelo cliente ou por um gerente de produtos da empresa que desenvolve o software.

• Scrum Master: é uma mistura de gerente, facilitador e mediador. Seu papel é remover obstáculos da equipe e assegurar que as práticas de Scrum estejam sendo executadas com eficiência.

Como o SCRUM funciona ?

Definição do Product Backlog: Todas as funcionalidades ou mudanças no produto são definidas pelo Product Owner no Product Backlog. Esta lista é priorizada para refletir a necessidade dos clientes ou demandas do mercado. Os itens do topo possuem prioridade maior do que itens no final da lista.

Planejamento do Sprint: Ocorre em duas partes, cada uma delas com time-box[1] de quatro horas. Na primeira parte do planejamento, o Scrum Master reúne-se com o Product Owner para verificar qual é oProduct Backlog. Na segunda parte, o Scrum Master reúne-se com a Equipe para estimar o esforço necessário para os itens do Product Backlog (usando estimativa ágil como Planning Poker) e para planejar o Sprint.

Andamento do Sprint: Durante o Sprint, os itens do Product Backlog que devem ser entregues são tratados em um artefato conhecido como Sprint Backlog, que contém os itens do Product Backlogsubdivididos em tarefas menores. As tarefas são responsabilidade da Equipe, que tem autonomia para decidir como elas devem ser executadas.

Reuniões Diárias: O Scrum Master se reúne diariamente com a Equipe sempre em um mesmo horário. Nesta reunião, cada membro da equipe responde três perguntas básicas:

• O que foi feito ontem?
• O que se pretende fazer hoje?
• Quais são os impedimentos que estão atrapalhando a execução das tarefas?

Revisões: No final do Sprint a Equipe demonstra os resultados para o Product Owner e demais interessados em uma reunião chamada Sprint Review, de forma que os itens do Backlog sejam considerados prontos e então possa se iniciar um novo Sprint. A equipe também faz uma reunião de auto avaliação no final do Sprint chamada Sprint Restrospective. Nela discute-se o que aconteceu durante a iteração finalizada, identificando o que funcionou bem e o que pode ser melhorado.

Monitoramento do Projeto: Para reportar o andamento do projeto usa-se um Burndown Chart, que é um gráfico onde o eixo x é a linha de tempo do projeto e o eixo y é o número de pontos a serem vencidos, que representam os pesos das funcionalidades potencialmente implantáveis do Product Backlog.

1) Em treinamentos sobre Scrum, o próprio Boris Gloger costuma compará-lo ao jogo de Rugby. É muito comum este jogo ser citado quando explica-se o funcionamento do Scrum. Você poderia avaliar esta comparação, na prática, do método com o esporte?

Resp.: Como devemos pensar em um jogo, seja de Rugby ou algo mais brasileiro? _ é sábio se preparar para cada partida. A comparação é que devemos entender cada partida de um esporte como um SPRINT. Em outras palavras, não podemos proceder de  forma igual, robótica, sem inovação em cada SPRINT. E é justamente este o ponto do SCRUM com os times de esporte. É uma inversão da pirâmide, ou seja, os programadores são muito importantes para o projeto como os jogadores para o time naquela  partida. Não adianta o gerente do projeto trazer controles que mais parecem uma auditoria e “burocratizam” o desenvolvimento. No fim, quem faz a diferença no projeto são os desenvolvedores (ou jogadores do time).

2) Há ainda um medo muito grande dos gestores em mudar radicalmente o formato de gerenciamento de projetos. O que falta para que eles confiem nas metodologias ágeis? Como convencê-los a investir no Scrum?

Resp. 1: Primeiro devemos rever o termo “mudar radicalmente”. Sugiro pensarmos em aplicar novos métodos como uma proposta de atingir resultados diferentes dos atuais obtidos. O principal motivador de uma mudança é a vontade. Não adianta o melhor consultor de SCRUM se a organização contratante não tem vontade de mudanças. Em minha leitura não é uma questão de confiança, pois é normal desconfiar de qualquer coisa nova que não se conhece com responsabilidade. É uma questão da organização estar descontente com os seus atuais e próprios resultados, assim criando uma vontade de mudanças.

Resp. 2: Para investir em qualquer coisa, deve-se compreender com transparência quais os benefícios, quais os resultados práticos, deste investimento. Podemos também nos utilizar da comparação financeira entre propostas de SCRUM, tipicamente baratas e rápidas (entre 3 a 6 meses para implantar) e outras metodologias que normalmente são caras e levam mais tempo para serem implantadas.

3) O Scrum atalha caminhos, diminui custos, tempo e barreiras através de um processo iterativo, que promete entregar funcionalidades de negócios a cada trinta dias. É realmente fácil fazer isto acontecer? Ao apresentar o método a uma empresa, pode-se ter certeza de que o investimento para que seja aplicado o Scrum será bem sucedido?

Resp.: O SCRUM não faz mágicas, até porque mágicas em projetos de software não são funcionais. Se praticado corretamente, o SCRUM proporciona melhores resultados no gerenciamento de escopo e gestão de mudanças, além de promover a interação com o cliente de forma constante. Esta interação trará resultados benéficos na gestão da expectativa do cliente. Também a iteração praticada pelo time pode proporcionar resultados como produtividade, desde que pratique-se com cuidado não esquecendo a qualidade. Então, de maneira objetiva a sua pergunta, é de complexidade média implantar SCRUM e o investimento será bem sucedido se o protagonista da implantação for o contratante, e não o consultor.

4) O Scrum é adaptável a qualquer projeto, grande ou pequeno. Há uma grande diferença na gestão através desta metodologia em relação ao tamanho do projeto?

Resp.: Penso que respondo melhor sua questão com uma analogia metafórica. Você se prepara, se controla da mesma forma durante a competição quando vai correr 400 metros e quando vai correr uma maratona? Certamente não. Assim também são os projetos, independente da metodologia que se vai usar. Em minhas consultorias recomendo formalizarmos uma proposta de processos para projetos rápidos (até 320 horas), para projetos de médio prazo (até 960 horas), para projetos longos (acima de 1000 horas) e ciclos de manutenção corretiva – evolutiva. É um grande equívoco tratar estes projetos de tempos e complexidades diferentes de uma forma única, genérica.

5) No contexto do Scrum, o time deve ser autônomo. Quais as vantagens e desvantagens desta auto-organização, de forma que eles resolvam todos os problemas entre si, sem recorrer a membros mais experientes? Causa uma certa estagnação na equipe?

Resp.: Na minha leitura isso é maravilhoso, apesar de reconhecer o quanto é difícil a aplicação na prática. Um indivíduo colaborador de um time pode ser muito mais efetivo se for interdisciplinar do que sendo especialista somente. O problema é que o modelo tradicional de gestão criam os especialistas, nutrem os especialistas, engessam os especialistas. Quando se monta uma distribuição de atividades, denomina-se aquele tipo de atividade sempre para o mesmo recurso. Ou seja, a própria gestão do projeto vicia o código, vicia o conhecimento do projeto, especializando em poucos. A auto-organização é eliminar o pensamento de indivíduo e pensar no time como um único corpo; desta forma, todos podem trabalhar em todas as partes do projeto. Se todos conseguem ser produtivos no projeto, não há estagnação, há crescimento contínuo.

6) O Scrum foca na liderança e não na gestão. Qual o diferencial de um Scrum Master para um gestor de projetos?

Resp.: Esta é uma pergunta que dificilmente encontrará uma resposta inquestionável. Na minha opinião, o SM está comprometido com o projeto e com o time. O gestor tradicional está comprometido com os controles, com a administração, com os números e com o cliente. Não podemos desconsiderar nenhum dos comprometimentos expostos. O ideal é que o líder do projeto tenha um conhecimento interdisciplinar e possa aplicar o melhor método conforme a situação. A hierarquia de atitude do projeto deve ser: Satisfação do cliente, crescimento do time (como conhecimento, postura, resultado) e satisfação com o projeto. Esta hierarquia não é exatamente SCRUM ou gestão de projetos clássica, é minha posição conforme minhas realizações históricas.

7) Nas reuniões diárias, no começo de cada iteração, três perguntas são propostas (O que fiz ontem? O que farei hoje? Quais são os impedimentos?). Há também os Sprints semanais, mensais e trimestrais. Qual o objetivo de cada uma destas reuniões?

Resp.: Um dos maiores desafios na liderança de um projeto é obter um “feedback” real, uma informação binária de como está de fato aquela atividade no projeto. Se você como líder, ir todos os dias até determinado integrante do time para questionar o estado (status) da atividade – certamente criará problemas de relacionamento com o time. As reuniões diárias e todas as outras proporcionam métodos para obter o feedback sem os melindres de outras formas de obter esta informação. Por outro lado, estas reuniões também proporcionam um maior comprometimento do time com o projeto. É o conceito de inversão da pirâmide, ou seja, os integrantes operacionais do projeto são muito mais importantes e ativos que os stakeholders, e eles se sentem desta forma devido aos métodos proporcionados pela reunião.

Fonte: Marketing FCamara

Seu diretor liga para você e diz: “Esqueci os contratos em minha mesa e já estou no aeroporto de Congonhas, você poderia trazê-los para mim? Ficarei aguardando por você no saguão do aeroporto!”. Você está na região da Av. Paulista e precisa chegar o quanto antes no aeroporto. Decide então pegar um táxi e chama o Seu Manuel, taxista conhecido da empresa: “Seu Manuel, daqui para o Aeroporto de Congonhas quanto tempo levaria e qual seria o valor aproximado da corrida?”. Seu Manuel, de acordo com sua experiência, lhe dá uma estimava: “Olha, nesse horário creio que em 30 minutos estejamos por lá e sairá em torno de R$35″. Você acha a estimativa satisfatória e decide ir com seu Manuel até o aeroporto. Ao entrar na 9 de Julho você percebe que o trânsito está completamente parado até mesmo para ir pelo corredor de ônibus. Seu Manuel lhe sugere um atalho que corta sentido a Av. Tiradentes e que economizaria tempo. Como se trata de uma situação urgente você decide ir pelo atalho sugerido.

Algum tempo após ir pelo atalho sugerido começa a chover muito em São Paulo e além de o trânsito ficar complicado há alguns metros é possível ver que uma árvore caiu na pista, impossibilitando a passagem de qualquer veículo. Preocupado, você pergunta novamente a Seu Manuel se há alguma maneira de contornar este caminho e encontrar outra saída. Seu Manuel diz que se voltarem um pouco o caminho feito e tentarem ir por dentro do Centro é possível que não se atrasem tanto. Você aceita novamente a proposta de Seu Manuel, pois vocês realmente tiveram problemas durante todo o percurso.

Finalmente vocês conseguem chegar ao aeroporto, porém, você percebe que o táxi levou 90 minutos para chegar até o destino, e ao invés de custar R$ 35 (como previsto), custou R$ 130. O que você faria? Ficaria irritado? Nunca mais utilizaria os serviços prestados por Seu Manuel? Mas veja, você estava dentro do táxi o tempo todo e percebeu que ele fez o possível para chegar a tempo, e realmente se esforçou lhe oferecendo diversas opções, as quais você aceitou, pois percebeu que realmente eram situações de dificuldade. Você viu que o trânsito estava ruim, que a chuva complicou ainda mais e que um grave acidente no meio do caminho piorou as coisas. Você viu que quando isso aconteceu Seu Manuel tentou pegar outro caminho para fugir do trânsito e, por mais que a estratégia tenha sido boa, não foi suficiente para chegar a tempo. O que você fará? Há uma probabilidade muito grande de você, mesmo chateado, pagar o taxista e entender o lado dele, afinal você viu o quanto ele se esforçou.

Agora, no mesmo cenário, imagine que, ao invés de ir no táxi, você apenas contrata o Seu Manuel para levar os documentos para o aeroporto. Ele lhe deu a mesma estimativa de tempo e custo. No entanto, 90 minutos depois ele lhe liga e diz: “Olha, o trânsito estava muito complicado e só cheguei agora, o custo foi R$ 130 ao invés de R$ 35″. Qual será sua reação agora? O que você pensará?

Provavelmente você pensaria que Seu Manuel estava te enrolando, abusando de sua confiança, pois você não estava presente em cada uma das mesmas situações que iriam ocorrer se você estivesse com ele no táxi.

Uma situação como essa nos mostra a grande diferença entre “estar dentro do táxi” e “estar fora dele”, e esse é um dos grandes diferenciais que o Scrum pode agregar ao seu time tendo o P.O (Product Owner) presente em cada uma das evoluções do projeto, sentindo na pele as dificuldades junto com seu time e decidindo sobre o que deverá ser feito, pois o ele é o dono do projeto e o mais interessado em sua realização.

Devemos não apenas nos colocar no lugar do cliente, mas devemos colocá-los dentro do táxi! Fazer com que ele realmente sinta que estamos comprometidos e que realmente estamos juntos para que haja sucesso em seu projeto.

Nos últimos meses tenho refletido a respeito das dificuldades que temos enfrentado na adoção de agile em grandes empresas. Depois de muitas conversas com colegas de trabalho, uma das conclusões que chegamos é que o alto número de intermediários e cargos, e a política de aprovação de orçamentos emperra a adoção de agile em grandes empresas. Infelizmente em grandes empresas lidamos com intermediários que muitas vezes não estão preocupados em maximizar o ROI, e sim em contratar uma empresa que sirva de seguro para seu cargo.

Há uma frase do mundo de TI que diz “Ninguém nunca foi demitido por ter contratado a IBM” que frisa bem este espírito. Para quem não entendeu significa que quando o projeto não der certo a defesa da pessoa que contratou será “Mas eu contratei a IBM, se eles não resolveram o problema, quem resolveria?”, algo que não aconteceria, por exemplo, se este mesmo projeto fosse realizado por uma pequena empresa, a culpa pelo projeto falho cairia sobre o contratante que não soube escolher um bom fornecedor para realizar o seu projeto.

Este contratante que geralmente não é o dono, mas tem um cargo executivo, tem um budget pré-estabelecido para gastar com determinados projetos. Não interessa para ele investir tempo em quanto do escopo será realmente utilizado e qual a prioridade dos itens necessários para o projeto, para ele é muito mais fácil elaborar uma RFP (e aqui temos alguns dos problemas da RFP) informando quais itens a consultoria terá que assumir, e então passar o risco do projeto para a consultoria, que em troca colocará a famosa “reserva de contigência” – popularmente conhecida como gordura – no projeto, para se proteger do risco. É claro que se isto fosse feito de modo a diminuir o risco para a consultoria a empresa que contrata iria gastar menos.

É como contrair um empréstimo: quando a empresa contrai um empréstimo dando garantias, tal como patrimônios, que o empréstimo será pago o valor do juros é menor. Quanto maior o risco, maior o juros, e consequentemente maior o gasto que a empresa vai ter para ter o mesmo valor de empréstimo. Mas qual seria o interesse em investir tempo para economizar um valor que ele já tem aprovado para gastar? E o pior, este valor na verdade para ele é um valor virtual, pois não sairá do bolso dele… Será que existe uma forma para grandes empresas quebrarem este paradigma?

Existe um grupo chamado “Beyound Budgeting Round Table” que propõe não só uma nova forma de controle orçamentário, mas também uma nova forma de gestão, já aplicada em empresas como Toyota, Unilever e o banco UBS, entre outros. Para quem quiser se aprofundar um pouco mais, segue uma página sobre o que é beyound budgeting da MetaManagement, que através do Niels Pflaeging, representa o Beyound Budgeting no Brasil.

Não sei quanto tempo ainda levará para que presidentes de empresas despertem para este tipo de gestão que é cada vez mais necessário neste mundo tão dinâmico, mas acredito que as empresas que despertarem primeiro terão um diferencial em gestão de custos e investimento em capital humano. Para finalizar, deixo vocês com a palestra do Niels Pflaeging, e um artigo da HSM.

O objetivo deste artigo é demonstrar que algumas práticas de engenharia (como um bom design de domínio, refactoring e TDD) são peças fundamentais para que possamos colher os benefícios das metodologias ágeis. Vamos começar voltando um pouco no tempo e explicar como era o mundo antes das práticas ágeis:

Crise do Software

A “crise do software” foi um termo cunhado para descrever as dificuldades enfrentadas no desenvolvimento de software no fim da década de 60. A complexidade dos problemas, a ausência de técnicas bem estabelecidas e a crescente demanda por novas aplicações começavam a se tornar um problema sério. Foi nessa época, mais precisamente em 1968, que ocorreu a Conferência da OTAN sobre Engenharia de Software (NATO Software Engineering Conference) em Garmisch, Alemanha. O principal objetivo dessa reunião era estabelecer práticas mais maduras para o processo de desenvolvimento, por essa razão o encontro é considerado hoje como o nascimento da disciplina de Engenharia de Software.

Duas décadas depois, em 1986, Alfred Spector, presidente da Transarc Corporation, foi co-autor de um artigo comparando a construção de pontes ao desenvolvimento de software. Sua premissa era de que as pontes normalmente eram construídas no tempo planejado, no orçamento, e nunca caiam. Na contramão, os softwares nunca ficavam prontos dentro do prazo e do orçamento, e, além disso, quase sempre apresentavam problemas.

Custo das mudanças

Uma das consequências de tentarmos igualar metodologias de desenvolvimento de software a metodologias de engenharia tradicionais (como construção civil) é a visão de que o custo de modificar o programa aumenta exponencialmente ao longo do tempo, conforme gráfico abaixo:

Acolhendo as mudanças

A partir da metade dos anos 90 começaram a surgir discussões sobre se a forma faseada acima (cascata), como ocorre na construção civil era realmente o melhor modelo para o desenvolvimento de software???? As metodologias ágeis de desenvolvimento surgiram exatamente para permitir maior flexibilidade no processo de desenvolvimento de sistemas e minimizar o custo de mudanças ao longo dos projetos, fazendo com que o gráfico acima fique mais próximo do apresentado abaixo:

Mas afinal de contas, como isto é possível? Como podemos adicionar mudanças ao software sem implicar em altos custos para o mesmo? A reposta a esta pergunta é o título do artigo: Aplicando boas práticas de engenharia!

Muitos times adotam Scrum, mas deixam de lado as boas práticas de engenharia que são necessárias para que seja possível acolher as mudanças ao longo do projeto como pregam as metodologias ágeis. Este tipo de problema já foi discutido por Martin Fowler e James Shore . E meu objetivo com este post é despertar estes times para o estudo de práticas de engenharia como refatoração, boas práticas de design de domínio e TDD .

Se você usa scrum, mas não utiliza estas práticas, sugiro que comece com urgência a estudar estes assuntos.

Um bom caminho para iniciar são os 3 livros abaixo:

• Extreme Programming Explained
• Clean Code
• Domain Driven Design

Fonte: Blog Ricardo Fernandes Luiz

Público Alvo: Gerentes, desenvolvedores e estudantes.

Pré-requisitos: Noções de desenvolvimento e entrega de softwares ou produtos.

Após o término deste treinamento o participante estará imediatamente apto a: Implantar, desenvolver e gerenciar equipes utilizando o framework Scrum, exercendo qualquer papel dentro da metodologia.

Local: São Paulo
Mais informações: http://www.temporealeventos.com.br/?area=214

Apesar de não trabalharmos com a metodologia, decidimos estudá-la para tentar abstrair o que de melhor ela poderia oferecer especificamente para o Teste de Software.

O nosso trabalho tem o enfoque na apresentação da utilização da metodologia, ressaltando benefícios como colaboração, integração e boas práticas, auxiliando na qualidade e sucesso dos projetos. Apresentamos alguns modelos de adoção do Scrum em empresas e em equipes, demonstrando assim possíveis problemas de adaptabilidade, já que tende a ser uma grande mudança na forma de se trabalhar.

Foram realizados estudos de viabilidade de adoção do Scrum, incluindo a equipe de Teste de Software, já que a metodologia veio se opor ao processo cascata de desenvolvimento, que joga os testes sempre para o fim esmagando os prazos e comprometendo a qualidade.

Por fim, o nosso trabalho aponta também os riscos e vantagens da utilização da metodologia, bem como os resultados obtidos da análise das empresas que utilizam o Scrum.

Os benefícios da participação do Time de Teste no Scrum:

• Integração do time;
• Apoio de quem está desenvolvendo código durante a execução dos testes;
• Apoio de quem está testando código durante a codificação;
• Participação mais direta e ativa do profissional que está testando o software;
• Profissionais que estão desenvolvendo código interessados em aprender sobre teste;
• Profissionais que estão testando código interessados em aprender sobre programação;
• Agilidade, interação com testes;
• Acompanhamento de defeitos pelo profissional que está testando o software;
• Analistas de Teste deixam de ser reativos para serem pró-ativos.

Lições Aprendidas

Existem poucas empresas que utilizam processos realmente ágeis e o termo “Scrum” tem sido muito utilizado para qualquer projeto de iterações curtas.

Para as empresas que realmente utilizam, um fator que contribui para o sucesso do Scrum é a maneira como se trabalha em equipe, dividindo todos os recursos, em pequenos grupos, sendo sempre equipes pequenas, isso faz com que todos sejam mais participativos e se empenhem melhor em suas atividades. Com a participação ativa de todos, o andamento do processo acontece de forma clara, que de certa forma, gera também aumento de produtividade. O profissional “veste o chapéu do outro” de acordo com a fase do ciclo, desta forma, a equipe trabalha mais unida aumentando a qualidade e reduzindo o retrabalho consideravelmente.

Devido à flexibilidade, a organização pode ter que realizar alterações na sua estrutura organizacional, para melhor adequar ao funcionamento do Scrum já que, a metodologia exige certo nível de formação de todos os envolvidos.

O Scrum não é uma fórmula mágica, não resolverá todos os problemas da equipe, ou da empresa. Além disso, há uma grande dificuldade na implantação, a adaptabilidade é difícil e a resistência geralmente é grande. Fora a desvalorização da documentação, em função da informalidade.

Porém, nas empresas estudadas, as vantagens da utilização da metodologia pesaram mais que as desvantagens. Apesar da resistência inicial, no geral as empresas que aderem à utilização de um Processo Ágil como o Scrum tem boas experiências com ótimos resultados.

Para saber mais sobre o assunto e se inteirar a respeito, vale a pena investir alguns minutos na leitura do nosso trabalho: Scrum no Teste de Software

Fonte: Blog As Especialistas

Visite o portal da Add Technologies - www.addtech.com.br, parceira do PTI.

Em tempos onde tudo vira projeto, existem regras que ditam as melhores práticas, e metodologias que auxiliam a sua execução. Dentro desse contexto é totalmente aderente o uso de métodos ágeis que têm como principais características, a freqüente participação do cliente e ter grande flexibilidade.

O Scrum é uma das melhores metodologias ágeis para gerenciamento de projetos de desenvolvimento de softwares, e tem sido utilizada com sucesso na Add Technologies. Esse modelo de gerenciamento atribui um valor real aos negócios dos clientes, alta qualidade na entrega que é mensurada e acompanhada durante todas as etapas de desenvolvimento e permite a criação de equipes auto-organizadas, encorajando a comunicação verbal entre todos os membros da equipe e entre todas as disciplinas que estão envolvidas no projeto.

“Atualmente a Fábrica da Add Technologies conta com uma equipe multidisciplinar e uma estrutura física moderna, totalmente adaptada para a prática das reuniões Scrum, dispondo de diversos painéis de controle distribuídos nos diferentes ambientes e uma sala de descompressão para a equipe.”
Lucio Matias – Superintendente Operacional.

Em uma abordagem mais ampla, podemos dizer que um projeto Scrum tem como princípio chave o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando uma abordagem tradicional de “controle”. Assim, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes.

O Scrum se baseia em ciclos de entregas, que são chamados de Sprints. Os Sprints são marcos curtos de direção que agrupam conjuntos de atividades que devem ser executados. Essas atividades compõem o Product Backlog, que é uma lista das atividades priorizadas (tipicamente vindas do cliente). No início de cada Sprint é realizado o Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner (o cliente) prioriza os itens do Product Backlog e a equipe seleciona atividade que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Product Backlog são transferidas para o Sprint Backlog.

Diariamente, nossas equipes fazem uma breve reunião de alinhamento sobre as atividades do Sprint em questão. Esse encontro diário é o Daily Scrum Meeting, onde o objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar e priorizar o trabalho do dia que se inicia.

Todo esse processo é facilitado pelo Scrum Master, que não é o líder da equipe (já que as equipes são auto-organizadas), mas atua como um mediador entre o restante da equipe e qualquer influência desestabilizadora. E primariamente tem a função de remover qualquer impedimento à habilidade de uma equipe de objetivar uma entrega.

Ao final de um Sprint, as equipes de projetos apresentam as funcionalidades implementadas em uma Sprint Review Meeting. E finalmente, fazemos uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo.

Além de ser toda estruturada para a prática do Scrum, a fábrica da Add Technologies conta hoje com 14 profissionais CSM (Certified Scrum Master) com previsão de ter toda sua equipe certificada até o final do ano, o que torna a Add uma referência no mercado nacional.

A Add Technologies se apresenta no mercado nacional como uma empresa de soluções completa em TI através das suas cinco unidades de negócio: uma Fábrica de Projetos, Outsourcing, Produtora web, Consultoria, e uma área mais recente, que cuida das de soluções web prontas, atendendo à necessidades específicas de nichos de negócios.

Estudando sobre metodologias ágeis para desenvolvimento web, encontrei este vídeo excelente (em inglês) explicando em 10 minutos (na verdade menos) como funciona a metodologia Scrum.

É bem daquela “uma imagem vale mais que mil palavras”.

Quer saber mais sobre o Scrum? Leia o artigo de Luiz Aguiar dando uma introdução ao Scrum, depois não deixe de ler o e-book Scrum e XP Direto das Trincheiras (necessário cadastro).

Bônus: Adoção do Scrum na Globo.com.

Até…