Archive for the ‘Scrum’ Category

Mingle Day São Paulo – Adam Monago

julho 6, 2009

Antes de começar a falar sobre o Mingle, ele falou um pouco sobre a Thoughtworks, esta empresa de consultoria tão falada no mundo de ágil.

A empresa surgiu 15 anos atrás construindo software customizados. Em 2000 estava em sérios problemas em um projeto. E eles foram em busca de algo novo. Falaram com Martin Fowler, como consultor, gostaram da forma, do resultado e continuaram a conversar.

Agile virou a forma deles fazerem projetos. E eles fazem muito coach em equipes também. De 15 pessoas do início até praticamente 1200 atualmente.
Lá na Thoughtworks eles não usam Scrum, XP, X ou Y, mas sim um conjunto de práticas ágeis que funcionam bem para eles.

MINGLE

A plataforma Mingle foi feita para trabalhar com a maioria dos projetos nas mais diferentes indústrias. na Thoughtworks, utilizam uma combinação de ferramentas, planilhas Excel e sem uma ferramenta que eles gostassem.

O desenvolvimento do Mingle começou a 2 anos e meio atrás e ele foi o primeiro cliente. Ele acha que foi escolhido para gerente de projetos da ferramenta por ter sido um cliente bem chato!

TUDO É UM CARTÃO

Tudo no Mingle é um cartão. Eles escolheram um cartão porque ele poderia representar qualquer coisa: um bug, uma feature, uma história…  Desta forma o usuário pode representar o que desejar.

Todas as visões do Mingle visualização os cartões de alguma forma. Todas as visões são, por padrão, abertas a todos. Isto porque a ferramenta foi feita com os princípios ágeis em mente. Toda visualização é a visualização de uma parte do backlog do sistema.

DEMONSTRAÇÃO
Ele começou mostrando um projeto básico, exibindo como se daria a utilização da ferramenta. O mingle é uma ferramenta muito intuitiva e fácil de usar.

A ferramenta tem um wiki embutido que deixa incluir texto, imagens e uma linguagem de macro para criação de gráficos e relatórios.  Além disso, expõe um plug-in em Ruby para cirar suas próprias visualizações.

TRANSIÇÕES DE CARTÕES
Este é um conceito muito poderoso que possibilita que uma ação seja executada toda vez que o cartão tem um estado alterado. Esta transição pode gerar alguma informação, alguma estatística.

FEATURE BREAKDOWN TREE
Dentro de um projeto podemos ter quantas árvores desejarmos. Estas árvores são úteis para dividir e agrupar as histórias, possibilitando ter um melhor acompanhamento do andamento do sistema.

O MINGLE É ENGESSADO?

Não. Eles não tem a intenção de ensinar ninguém a como ser ágil, como executar as tarefas. Mas sim, querem atender as pessoas que sentem necessidade de customização nas ferramentas atuais. O Mingle já vem com diversos templates adequado as mais variadas metodologias ágeis, mas o usuário pode customizar o que desejar.

Existem pessoas que utilizam o Mingle com Lean, colocando informações de filas de espera e filas de execução. Este é um exemplo de como a ferramenta pode ser customizada para algo totalmente diferente.

PLANEJANDO RELEASES

É muito fácil e intuitiva a forma de planejamento de releases do Mingle. Parece bem fácil e tranquilo de usar. E como fica tudo no mesmo lugar, diminui a necessidade de alguém ficar preparando relatórios que contém dados de várias ferramentas.

CONVERSE COM O PESSOAL DO MINGLE

Toda semana eles fazem sessões pela web onde as questões e o asssunto da reunião são dirigidas pelos participantes.

LICENCIAMENTO

Eles não falaram muito disto na palestra, mas é preciso falar disto:
* O Mingle é gratuito para projetos de até 5 usuários (acredito que por 1 ano somente)
* O Mingle é gratuito para projetos Open Source e de universidades
* Fora destas questões, ele é meio caro, saindo algo como 50 dólares por usuário, por mês.

Mingle Day São Paulo – Paulo Caroli

julho 6, 2009

Antes de Adam Monago começar a fazer a apresentação sobre o Mingle, Paulo Carolli deu algumas palavras sobre tudo que aconteceu até este evento. Paulo trabalha na Thoughtworks há alguns anos e atualmente trabalha no escritório indiano da empresa.

Paulo falou da importância de se criar uma comunidade, de trocar idéias, de se manter juntos e trocando idéias.

Outra coisa que ele disse foi da importância de Papo e Yoshima estarem discutindo os conceitos por trás das práticas. Para começar, nos apoiamos nas práticas para depois entender os conceitos.

Mencionou também que eles não estavam lá para vender o Mingle. Paulo iria trazer o Adam para um evento no Rio de Janeiro, onde ele falaria de User Stories e aproveitaram e organizaram um Mingle Day lá. Conversando com o Yoshima, eles aproveitaram e combinaram de trazer o evento para São Paulo.

Mingle Day São Paulo – José Papo

julho 6, 2009

PENSE DE UMA MANEIRA NOVA EM VEZ DE SÓ USAR FERRAMENTAS

Papo começou falando sobre a Semco, Toyota e outras empresas que são exemplo de auto-gerenciamento, mesmo fazendo tarefas repetitivas.
O menos importante são as práticas, mas sim a filosofia por trás das práticas.

Uma das bases do Scrum foi o artigo citado pelo Yoshima. O ponto central do Scrum é usar as poucas práticas com uma meta bem definida.

Parafraseando a Toyota, podemos dizer que:

“Antes de construir software, devemos construir pessoas”

Os líderes da Toyota têm um grande conhecimento do trabalho e focam no desenvolvimento das pessoas de baixo para cima. Papo mostrou um quadro com alguns tipos de líderes:
* Líder burocrático: não sabe e manda.
* Chefe de torcida: não manda, anima. Porém como não sabe, fica meio como líder de torcida.
* Task Master: Entendimento total do trabalho e já passa exatamente o que deve ser feito.
* Construtor de organizações que aprendem: Conhece profundamente o trabalho, mas trabalha mais como mentor, professor.

TAYLORISMO e PÓS-TAYLORISMO

* Taylorismo gera sistema empurrado, de dentro para fora.
* Pós-taylorismo gera sistema puxado. De fora para dentro. Melhoria na rede auto-gerenciada.

METAS FIXAS X METAS VARIÁVEIS

Ao trabalhar com metas fixas, a empresa não dá vazão às adapta~~oes que ocorrem no mercado. Geralmente, além de se definir uma meta fixa, já se define como o dinheiro será gasto. Na Toyota, você tem X milhões para gastar, não entra no detalhe. Além disso, a meta não é fazer X ou Y de dinheiro, mas sim, ganhar do mercado.

Defina metas aspiracionais e móveis e dê recompensas ao sucesso obtido em equipe.

Papo citou uma frase que navegar com metas fixas em águas desconhecidas é o mesmo que navegar de encontro a um iceberg.

VOCÊ é X ou Y ?

Existem dois tipos de pessoas, X ou Y.

  • X é o estilo de gestão autoritário e top-down. Pressupõe que as pessoas só se motivam por valores externos e tendem a evitar o trabalho quando possível.
  • Y é o estilo de liderança servidora. Acredita que as pessoas são auto-motivadas e podem cumprir por conta própria metas da organização.

Se você é X, nem perca tempo com metodologias ágeis, elas não foram feitas para você!

Ao final da palestra, Papo passou a lista de alguns livros (alguns bem famosos) que valem a leitura, veja no blog dele.

Mingle Day São Paulo – Rodrigo Yoshima

julho 6, 2009

Yoshima começou falando sobre o Besteirol Ágile e sobre pessoas que muito falam sobre as práticas ágeis e esquecem dos princípios. O problema desta falta de princípios chega ao ponto de 2 palestrantes do Scrum Gathering dizerem que não acreditam em auto-organização das equipes, justamente um dos pilares do Scrum.

Antes de pensar em Kanbam e reuniões diárias, é preciso pensar em auto-organização. Takeuchi e Nohara escreveram como as empresas estavam desenvolvendo produtos de eficiência e confiabilidade em 1986, no artigo The new new product development game. Este artigo foi uma das bases do Scrum. Podemos ver que o conceito não é novo, mesmo o Scrum já existe há um bom tempo.

Yoshima perguntou no que a platéia pensa quando falamos em auto-organização:

  • Bagunça
  • Comunicação
  • Auto-Gerenciamento
  • Pró-atividade
  • Comprometimento

Depois ele listou alguns dos princípios necessários para ter uma equipe auto-organizada:

DESCONFORTO

  • Auto-organização nasce do desconforto (muitos não concordam com isso), para atingir um objetivo insano (mais para frente na palestra Rodrigo disse que o objetivo insano havia sido um pouco exagerado)
  • Se a equipe sabe muito bem o dia de amanhã, não estã no desconforto. Sem uma ponta de desconforto, não há auto-organização. O karma é conciliar liberdade e desafio.

AUTONOMIA

  • Não dá para ter uma equipe auto-organizável somente com pessoas inexperientes. Tem que haver ao menos uma liderança técnica. Tem que ter um core experiente para o negócio fluir, e os membros da equipe ganharem maturidade.

INFORMAÇÃO ZERO

  • É muito importante as pessoas estarem no estado do não sei nada e não vou utilizar o passado no futuro. Porque senão você sempre irá tentar resolver o problema da mesma forma.

Sempre estamos tentando diminuir a variabilidade do processo. Desta forma, CMMI e RUP engessado seriam bons. Por isso, o palestrante se diz contra a departamentamentos de arquitetura e inspeção de qualidade.

TRANSCENDÊNCIA
Palavra bonita hein? mas na verdade, é querer saber o limite das coisas. É uma equipe que quer fazer coisas completamente inovadoras. Tente fazer da forma como você nunca tinha feito antes.
Ao desenvolver de forma ágil, você sempre está comprando um risco. Alguém assumiu um prazo com o cliente, assumiu uma incerteza… E nestes momentos, par resolver este risco, surge a inovação.

INTERFERTILIZAÇÂO

Não é só comunicação entre as equipes. é a comunicação entre pessoas de vários skills e experiências.
Muitas vezes as equipes nunca sentam para planejar o projeto juntos, justamente onde ocorre a troca de experiências. Mais importante do que cartas, números e prazos, o jogo de planejamento é um excelente momento para troca de experiências.

APRENDIZADO
Uma pessoa alimentando a outra com conhecimento, para que toda a empresa aprenda junta. A empresa tem que ter um direcionamento para o aprendizado.

AUTO-ORGANIZAÇÃO
Não somente em projetos inusitados para ter auto-organização. Projeto legal é projeto que desafia. Tente fazer projetos em outras áreas, diferentes do seu habitual.
Auto-organização é o cerne de uma metodologia ágil.

Mingle Day São Paulo – Thoughtworks e Aspercom

julho 6, 2009

Em um grupo de cerca de 80 pessoas: Rodrigo Yoshima, José Papo, Adam Monago e Paulo Caroli fizeram um encontro para falar de ágil e para o pessoal da Thoughtworks falando do Mingle.

Antes que alguém fale alguma coisa, não existe nenhuma relação comercial entre a Thoughtworks e a Aspercom, eles se uniram somente para fazer este evento. Claro que no futuro pode rolar alguma coisa, mas não tem nada acertado.

A palestra de cada um deles está descrita nos posts abaixo:

Foi um evento bem bacana, que reuniu diversas pessoas da comunidade ágil.  Depois o pessoal ainda foi para um barzinho, mas eu tomei o rumo de casa.

Próximo post: apresentação de Rodrigo Yoshima no Mingle Day

Veja mais informações no blog da Aspercom, que organizou o evento.

Retrospectivas

junho 25, 2009

Pessoal,

Seguindo a linha de posts relacionados ao Scrum Gathering, coloquei no InfoQ um outro post sobre a palestra de Restrospectivas do Boris Gloger.
Pessoal,

Temos que sempre tentar executar retrospectivas após o sprint, segue um artigo que fala bem sobre esta sessão do Scrum.

http://www.infoq.com/br/news/2009/06/6-segredos-executar-sucesso

Confiram lá !

Até mais

Scrum Gathering: tudo sobre a sessão de Review

junho 6, 2009

Pessoal,

Coloquei no InfoQ um post sobre a sessão de review do Scrum. A apresentação foi muito boa e feita por Rodrigo de Toledo, do Cenpes. Segue o link: http://www.infoq.com/br/news/2009/06/apice-ciclo-scrum .

Na apresentação ele fala sobre utilizar um PPT para guiar a apresentação. Compartilhamos aqui o que utilizamos em nossas apresentações de Review: http://docs.google.com/Presentation?id=dd2jxrvc_33c6nmwcg7 .

Qualquer dúvida ou problema é só comentar!

Scrum Gathering – Os desafios de escalar Scrum

maio 25, 2009

Palestra de Danilo Bardusco – Globo.com, a apresentação está disponível no SlideShare. Já havia assistido uma palestra dele e novamente foi muito competente e direto no assunto que tratava. Passando experiência de utilização e conceitos do Scrum na mesma palestra.

Antes de começar é bom saber, escalar desenvolvimento ágil é a única coisa que você deve fazer. Comece simples! A velocidade de decisão tem que ser rápida e menos pessoas decidem mais rápido.

Danilo Bardusco

Danilo Bardusco

O Scrum é auto-escalável, ele contém todos os elementos necessários para lidar com a complexidade. E para uma adoção de Scrum ser boa, ela não deve ter um único responsável, ela vai acontecendo gradualmente baseada em resultado.

De acordo com Ken Schwabber:

Scrum precisa de gerenciamento inteligente e mão na massa

Como é na Globo.com?

Na Globo.com existem dois cenários: um com equipes que trabalham independentes umas das outras e outro cenário com equipes diferentes que trabalham em um mesmo projeto.

Ao iniciar a adoção do Scrum, 7 departamentos foram transformados em 17 times Scrum. E uma lição que saiu desta adoção foi que quando se está transformando, é preciso mostrar para as pessoas porque será melhor. Ao escalar o Scrum em equipes independentes é importante lembrar de:

  • Simplicidade: é a arte de maximizar a quantidade de trabalho não feita. Se não tem certeza de que algo é necessário, não escreva o código.
  • Iterações: Ser simples significa ser incremental. O Scrum exige que você pense como uma artista, vá refinando a sua obra, vá refinando a sua idéia sobre o que deseja fazer. E você irá parar quando achar que já tem o suficiente. (Em sua apresentação ele utilizou um slide bem bacana, ilustrando esta diferença mostrando um quadro da Monalisa). Se você tem 3 dias para fazer um cadastro de clientes, faça o melhor cadastro possível em 3 dias, faça algo entregável.
  • Cliente e/ou usuário colaborando: Isto é difícil em empresas maiores. Não é para escolher nada do cliente.
  • Kaizen Mind: senso de urgência. Fazer as coisas de forma melhor.
  • Ambiente de confiança e aprendizado.Para aprender é preciso errar. As pessoas não se sentem confortáveis de apontar onde está errado. A principal coisa que gera confiançaé entregar software funcionando.
  • Entregar software funcionando a cada sprint: mesmo que seja pouco, você vai melhorando e corrigindo. Eles tinha dois problemas maiores para entregar software funcionando. Os times não eram 100% autônomos e a alta direção não se sente confortável de por algo que não está ainda pronto. Alguém pode copiar a idéia ou causar má impressão. Mas viram que é mais competitivo entregar antes do que ficar planejando.

Ao Implantar Scrum é importante saber que o Scrum não é fácil.

Escalando Scrum

No desenvolvimento da nova plataforma de gerenciamento começaram com 1 time em 12 sprints. As coisas não estavam indo bem, era preciso ser mais rápido. A direção colocou 6 times à disposição do projeto. Mesmo sabendo que 9 mães teriam um filho em um mês, eles começaram a escalar o Scrum.

  • Os times foram replicados: uma pessoa do time original foi colocada em cada um dos novos times.
  • O Product Owner original virou o Product Owner do Backlog geral.

Estes times tinham:

  • Sprint sincronizado.
  • Plannings individuais.
  • Daily meetings no mesmo horário, às 09:30.
  • Daily Scrum of Scrums às 09:50.
  • O Review é feito no auditório com todos.

Velocidade dos times

Algo que eles aprenderem neste projeto foi que é importante achar a velocidade local de um time antes de distribuir para outros times. É importante sentir se o time está desempenhando da forma que o projeto precisa antes de distribuir.

A arquitetura estava ruim, muito difícil de desenvolver. Outras coisas que aprenderam foi:

  • Integre os projetos ao menos uma vez por dia. Se a equipe demorar muito para fazer o Merge, corre o risco de ter muito retrabalho.
  • Cuidado com a automação de testes, evite gerar uma manutenção difícil. Eles gravavam muitos testes de web e depois tinham que regravar muita coisa. O mesmo cuidado que você tem com o código, deve ter com o teste.

Coordenação entre os times

É fundamental que as pessoas se falem, daily meetings e sincronismo entre os Product Owners. É preciso isolar uma user story de outra.Além disso, para facilitar a coordenação é importante não paralelizar trabalho, que nos dá os seguinte benefícios:

  • Diminui o estoque de produtos não acabados.
  • Ajuda na auto-gestão.
  • Regula o tamanho da equipe: não vai ter story para que 15 pessoas trabalhem na mesma.
  • Tira o time da zona de conforto.

Fez uma pequena observação: eles fazem reuniões semanais entre os especialistas de uma área que estão espalhados pelos times, (por exemplo designers), para que troquem experiências.

Seja preguiçoso

  • Só faça o absolutamente necessário para a meta.
  • Não reinvente a roda.
  • Simplifique.
  • Automatize depois que fizer algo, automatize tudo!

Ao fim das palestras, Danilo disse que a Globo.com é uma boa prova que se pode fazer software de qualidade sem burocracia.

Apresentação no SlideShare

Voltar para o resumo do primeiro dia

Scrum Gathering: Scrum para Desenvolvimento Interno e para Produtos de Software

maio 16, 2009

Antes de mais nada, confiram o relato do próprio palestrante aqui.

Quando cheguei na palestra o Rodrigo já havia começado, mas acredito que ainda peguei a palestra no começo.

Fez um panorama do Agile hoje, que conta com:

  • TDD – Test-Driven Development
  • Design e arquitetura emergente: somente uma parte dos desenvolvedores sabem desenvolver de forma emergente.
  • Documentação forte e executável
  • Ajuda de muitas ferramentas

Discutiu-se sobre a fama que os métodos ágeis, em especial o XP, que eles são contra a documentação. Ele lembrou que na verdade é o contrário. Nos métodos ágeis a documentação é tão rígida, tão formal, que até o compilador entende. Ele diz isto porque temos todo o sistema documentado em testes unitários.

Tipos de Empresas de software

Ele classificou as empresas de softwares em 3 tipos:

  • Tipo 1: Que fazem software para fora.
  • Tipo 2: Que fazem para elas mesma, ou que estão alocadas no cliente para quem trabalham.
  • Tipo 3: Desenvolve produto para o mercado.

Ele utilizou esta classificação para falar dos problemas em cada um dos tipos. Aonde você se enquadra?

Papéis do Scrum

Antes de continuar, conceituou os papéis do Scrum.

Que papéis precisamos para fazer software?

  • Desenvolvedores
  • Um cara de negócio, um cliente

E no Scrum, o que temos?

  • Product Owner: Quer produto funcionando, quer resultado. E de preferência, da maneira mais fácil e rápida.
  • Time: Quer o melhor ambiente possível para trabalhar e quer entregar o projeto com qualidade.

Os interesses do Product Owner e do Time são, por definição, conflitantes. A única coisa em comum entre eles é o fato de querer entregar o projeto.

O Scrum Master lidera tanto o time quanto oP.O.(Product Owner). Ele auxilia e freia o P.O. Ele tem que balancear este conflito de interesses. O time vai querer gastar mais e fazer menos e o PO ao contrário. Tem que chegar no melhor para o projeto, sem tomar partido de ninguém.

Falando no PO, se não acharmos um bom PO, o projeto corre riscos. O PO é orientado a ROI (Retorno de Investimento). Ele só pensa nisso! Afinal, o software tem que trazer dinheiro para o bolso de alguém.

O PO faz um meio campo entre o time e os stakeholders. É alguém capaz de controlar a demanda. E o PO é importante, porque a pior coisa é colocar desenvolvedor para resolver ROI.

Um bom PO é formado depois de ser responsável por pagar a conta. Ele quer ver aonde foi o dinheiro. E o PO precisa por dinheiro no bolso de alguém. Ao fim de uma sprint, temos que mostrar aonde foi gasto o dinheiro. Para maiores informações sobre o PO, leia este artigo do palestrante.

Feita esta excelente conceituação sobre os papéis, vamos aos tipos de empresas e o scrum:

Tipo 1 – Fábricas de software e o Scrum

Muita dificuldade nestes ambientes:

  • A forma de contrataão normalmente é de escopo fechado.
  • O ambiente, os clientes, não buscam o contrato aberto.

É difícil achar um PO:

  • O Cliente vai lá, compra e esquece do sistema até que tenha chego prazo para entrega. Só vê ao final do projeto.

É um modelo em declínio, afinal, o cliente está insatisfeito. Este modelo tem sido substituído pelo Body Shop. Lá fora existem fábricas de software ágeis, como a famosa ThoughtWorks. Aqui temos a CI & T e o pessoal da OnCast, de Florianópolis.

Tipo 2 – Empresas com desenvolvimento interno ou body shops

É mais fácil:

  • é mais fácil achar um PO.
  • aceitam o escopo negociável
  • estão melhorando suas arquitetura e práticas de engenharia

Problemas para o desenvolvimento interno:

  • PO não está envolvido e o dinheiro não sai do bolso dele.
  • Muitas vezes o projeto vai indo, sem o devido cuidado.

Tipo 3 – Desenvolve Produto para o Mercado

É muito fácil implementar neste ambiente. Estruturas simples, enxutas e orientadas a resultados.

  • O PO adora este papel.
  • Equipes menores e mais unidas.
  • Muitos já são iterativos.
  • Busca boas práticas de engenharia e arquitetura.

Problemas ISVs:

  • O desenvolvimento é mais complexo.
  • Carregam um legado pesado.
  • Não possuem boas arquiteturas.
  • Ainda há muito em melhorar nas práticas de engenharia.

Conclusão do Palestrante

Se você quer ser agile, terá que ir para os tipos 2 ou 3. No 1, no momento atual, é muito difícil. Você precisa ter boas práticas de engenharia, pense em teste e automação. Desta forma, você estará apto a dsenvolver e implantar as mudanças de forma ágil.

Cuidados com o Scrum

Tenha cuidado com seu ambiente:

  • Pense na definição de pronto
  • Tem testes automatizados? E/ou um especialista olhando o código? Tem uma clara documentação?
  • O que você faz com os resultados de suas perspectivas?

Lembre-se do que disse Ken Schwabber: “O Scrum é tua sogra: É bom para dar visibilidade, afinal ele joga o problema na sua cara o tempo todo.”

Se você faz um sprint de 1 mês e não entrega nada funcionando, tem algum problema:

  • Pessoal não qualificado.
  • Arquitetura fraca ou não é flexível.
  • Falhas ao atacar os riscos.
  • Falta de fluídez no ciclo de desenvolvimento.
  • Problemas de infra-estrutura.
  • Equipe desmotivada.

O Scrum não resolve nada, o seu sucesso estará na forma como irá resolver os problemas. Por exemplo, se um projeto tem práticas ruins de engenharia, deve ser detectado e corrigido após a retrospectiva. Se não corrigirmos, temos uma falha do time.

Scrum funciona bem como a porta de entrada no mundo ágil. o fim seria tudo casado com as práticas de XP.

Voltar para o resumo do primeiro dia

Scrum Gathering 2009 – Primeiro dia – Parte 2

maio 14, 2009

Continuando a transcrição do evento.

Apresentação do Ken Schwaber

Um dos criadores do Scrum fez sua apresentação através de vídeo-conferência, então por isso era uma apresentação mais parada e menos interativa.

Começou falando sobre o Manifesto Ágil, concebido em 2001, e sobre a importância de preferir os itens da esquerda sobre os da direita. Mostrou alguns gráficos mostrando que as empresas estão usando mais Agile que Waterfall. Outra coisa que vem crescendo também é o número de CSM (Certified Scrum Masters), de 8000 em 2006 até 54000 no ano passado. (Um outro ponto de vista pode ser encontrado aqui)

O que é o Scrum?

Segundo ele, é um framework bem leve, empírico, dependente da inspeção e adaptação. É iterativo, com times auto-organizáveis gerando incrementos.

Valores do Scrum:

  • Transparência
  • Ser empírico
  • Auto-organização
  • Integridade: assim que perceber algo, faça algo
  • Entrega de valor

Como o pessoal tem usado o Scrum?

Boas notícias

  • Timeboxes são bem usados e respeitados.
  • Menos uso de cascata.
  • Valores ágeis são bem conhecidos, públicos.

Más notícias

  • Desenvolvedores tem problemas ao fazer incrementos e entregar software realmente pronto.
  • Cliente joga uma lista de requisitos para o outro lado da parede, e só volta quando passou o tempo suficiente para ficar pronto.
  • Gerenciamento médio de TI é resistente ao Scrum. Fazem a pergunta: com Scrum, para que eu sirvo?
  • Transparência é evitada.
  • Comando-controle prevelece.

Muitos destes pontos ruins têm origem no método cascata. Um projeto cascata está completo quando tem todos os requisitos que você passou inicialmente. Já no Scrum, você começa com um approach de quem tem ainda muito o que fazer, só definimos um objetivo e coisas mais importantes e de maior valor. A principal diferença entre as duas abordagens estará no fato de que após 1 mês já temos algo pronto, fica mais fácil prever o futuro. Começamos pelas coisas que fazem mais sentido.

Como todo gringo, quando quer se aproximar do brasileiro, fez uma analogia com o futebol. O Scrum é como futebol. Traves, bolas e afins. Se você tiver um bom time, o jogo será melhor. Senão… é, você vai ter problemas.Pode-se encontrar maiores informações sobre Scrum no site da Scrum Alliance.

ScrumBUT

Scrum está sendo adotado por diversos tipos de companhias que enfrentam problemas. Muitas vezes, quando as empresas usam, elas criam razões para só usar parte do Scrum. E existem várias razões para não se utilizar.

O que é ScrumBut? É quando a empresa aplica uma adaptação do Scrum só para facilitar as coisas. O nome surge do diálogo:

– Você usa Scrum?

– Sim, mas… (em inglês, yes, but…) => aí surge o ScrumBUT

Um exemplo de ScrumBut seria o de não fazer reuniões diárias. Para ver se o fato de não fazer reuniões diárias está causando problemas na equipe, pergunte ao time como pretendem entregar a versão. A tendência é que as informações estejam desencontradas.

Outro exemplo de ScrumBut é o fato de não termos sprints entregáveis. É necessário um sprint de estabilização.

Comando-Controle

Depois ele fez um exercício utilizado em treinamentos de CSM. É um exercício para mostrar o uso do comando-controle. Neste exercício todos tem que levantar e andar pela sala. É engraçado porque causa desconforto nas pessoas. E o intuito do exercício é demonstrar que é mais produtivo e divertido trabalhar de forma auto-gerenciável. E o ponto da produtividade é um ponto muito importante para se vender para a gerência.

Certificação Certified Scrum Developer

Nestes posts, estou mais transcrevendo o que se passou do que dando opinião. Mas este foi um momento estranho.

Ele começou a falar que somente 25% dos desenvolvedores estão preparados para trabalhar em um projeto Scrum. Eles não estão preparados para entregar software entregável (ficou meio redundante, hehe). Até aí nada de novo. De repente ele começa a falar sobre uma certificação nova da Scrum Alliance.

Esta certificação seria um curso para times, para fazer software entregável em um sprint. Esta certificação seria baseada em .NET + Visual Studio Team System + um plug-in Cochango, se não me engano. Metade do auditório (eu entre eles) fez menção de rir, ainda mais porque se tratava de fazer em conjunto com uma ferramenta específica.

Depois, quando perguntado, ele disse que a idéia é ter diferentes técnicas de engenharia e metodologias sendo certificadas em conjunto com Scrum.

Ao final, ele disse que não era só sobre Scrum, mas sim, sobre melhorar a profissão.

Minha opinião

Ainda é preciso aguardar para ver o que vem daí, mas de cara parece um samba do crioulo doido. E a motivação principal parece ser o fato de ter uma demanda reprimida na área de aplicar engenharia com Scrum. A iniciativa parece louvável, mas alguns fatos como:

  • Vender uma nova certificação
  • Criar ferramentas certificadas pela Scrum Alliance
  • Criar práticas que estejam ou não de acordo com a Scrum Alliance

Vão contra o que até ele mesmo disse que o Scrum é um framework leve, que tem somente o necessário para sua empresa. Mas vamos aguardar!

Voltar para o resumo do primeiro dia