Feeds:
Posts
Comentários

Posts Tagged ‘SCRUM’

Continuando o assunto do post anterior, dessa vez Uncle Bob resolve dar sua opinião sobre o booom de projetos ágeis” que estão aparecendo (e falhando) por todo lado.

Uncle Bob em Dirty Rotten ScrumDrels.

Read Full Post »

James Shore pra mim é um daqueles autores que quando ele fala em Agile, ele leva em consideração o que Agile é e não quanto dinheiro ele pode ganhar em suas consultorias, então é uma opinião a ser respeitada.

No Brasil, as listas de discussões viraram local para se fazer propaganda do curso X, da consultoria Y ou site Z faz tempo, a única lista onde esse pessoal não se criou, foi a xp-rio (lá você pode fazer perguntas sabendo que o pessoal vai te responder sem pensar que você é um possível cliente). Opiniões são completamente baseadas em “quantos clientes eu posso conseguir afirmando que X é melhor que Y?”.

Toda semana vejo aparecer um curso de Scrum novo, ministrado por alguém certificado PMP e “Certified Scrum Master”, acho que isso acaba gerando uma boa parte do problema. Sua empresa quer Agile com CMMI ? Sem problemas tá cheio de consultor por aí pronto para quebrar os valores ágeis somente para ganhar um dinheiro da sua empresa.

Como o Milfont já havia previsto, o Scrum está se tornando cada vez mais o PMBoK de jeans.

Sinceramente, se você esta querendo iniciar com desenvolvimento ágil, Scrum, extreme programming, Lean, crystal… utilize as listas de discussão para fazer perguntar e tirar suas dúvidas. Contudo filtre bem as respostas, tenha em mente que tem muita gente ali que precisa de convencer que X é melhor que Y ou que X é perfeito para seu ambiente, muitos vão mentir deformar o movimento ágil o quanto for necessário, somente para conquistar seu dinheiro 🙂

Isso não quer dizer que você não deva contratar um coach para ajudar com o desenvolvimento ágil em sua empresa, isso com certeza é algo que vai acelerar bastante as coisas. Contudo, preste atenção em quem você está contratando.

Voltando agora para o James Shore, ele escreveu um post que relata muito bem um fato que vem acontecendo devido a toda essa fama do agile, não vou repetir o que ele escreveu lá, então o link é esse The Decline and Fall of Agile.

Read Full Post »

Notícia rápida, a partir de 1º de janeiro de 2009, para você ser um Certified ScrumMaster você deverá fazer uma prova!

Parece que estão tentando dar algum crédito ao título, mas acho que vai continuar sendo somente um comprovante de participação em um curso.

Mais informações, você encontra aqui.

Read Full Post »

Continuando essa série de post (parte 1 e 2), hoje vou comentar como foi o final da primeira iteração/sprint, reuniões de review, retrospectiva e o planejamento da iteração seguinte.

Cheguei na empresa e antes de começarmos os trabalhos, reuni o pessoal e perguntei como foi a primeira semana utilizando scrum.  O desenvolvedor mais experiênte, comentou que gostou do sistema com o quadro, os cartões e post’it. Ocorria muito mudança de contexto (e mudança de contexto é algo ruim), pois as ordens vinham de cima e não havia uma preocupação de trabalhar em 1 projeto de cada vez. Ele disse que pode se organizar muito melhor. O desenvolvedor menos experiente (1 mês de empresa) também gostou muito do quadro, cartões e post’it. Segundo ele, é sempre complicado ao entrar em um projeto, entender os padrões e ter uma visão geral do sistema. Utilizando cartões, ele precisa aprender apenas pequenas partes do sistema a cada semana, se preocupando com as outras partes somente quando for necessário. O dono da empresa também está satisfeito, ele disse que foi produzido bastante nessa primeira iteração, terminaram todas as tarefas e realizaram o spike planejado.

Certo, depois da conversa inicial, fomos para o review, que na verdade serviu para eles entenderem como funciona um review (agora em mais detalhes do que na apresentação teórica inicial). Como eles trabalham para vários clientes durante a iteração, eles foram desenvolvendo e apresentando (disponibilizando no site) para os clientes. Ou seja, para esses projetos não irá ocorrer aquela apresentação formal durante o review (isto também seria dificultado pelo fato da maior parte dos clientes residirem em outras cidades).

O fato de não ter essa apresentação acabou gerando um problema. A funcionalidade é desenvolvida, atualizada no servidor e então o cliente é comunicado da mudança. O problema é que  nessa primeira iteração algumas funcionalidades (4 ou 5) não ficaram pronta, pois o cliente ainda não aprovou.

Além destes projetos menores, há o projeto maior, no qual o cliente pode estar presente para a reunião de review. Nessa primeira iteração não ocorreu, pois eu aproveitei pra explicar como fazer a review. Deve ser uma apresentação simples, utilizando diretamente o software (nada de slides, diagramas…) e que preferencialmente o cliente  fique utilizando o software durante a explicação do que foi desenvolvido.

Como a definição de pronto, inclui aprovação do cliente, nesta primeira semana, o que foi desenvolvido nesse projeto principal, foi apresentado para o cliente. Contudo ele achou muito mais interessante o review meeting. Segundo o cliente, ao ser informado que uma nova funcionalidade estava pronta, ele acessou o sistema utilizou de forma superficial e somente isso. Ele estava ocupado e não poderia perder muito tempo naquilo. Respondeu que estava tudo certo com a funcionalidade. Agora, com um horário reservado para essa apresentação, ele irá utilizar e (importante) fornecer um feedback muito maior para a equipe de desenvolvimento (o feedback anterior havia sido um “ok”). O cliente utilizou novamente a funcionalidade por alguns instantes durante nossa review e deu algum feedback, a funcionalidade não estava exatamente como ele queria e ele decidiu gastar algum tempo na próxima iteração melhorando isso.

Assim terminamos nosso review meeting. Já combinado para a próxima semana as funcionalidades serem apresentadas para o cliente.

Após o review, iniciamos a retrospectiva. Expliquei que a retrospectiva é a hora de melhorar. Melhorar o processo (avisando que primeiro você deve praticar corretamente o processo, somente depois pode melhorar –  Shuhari), melhorar o ambiente, melhorar o código, a documentação ou qualquer outra coisa.

Além de identificar o que pode ser melhorado, é importante atacar um ou poucos problemas em cada iteração, tentar resolver tudo em uma única iteração não é uma boa idéia, provavelmente você terá nada resolvido, ou vários problemas quase resolvidos (quase resolvido significa não resolvido). Após identificar o que será melhorado, deve-se definir quais ações/atitudes serão tomadas para melhorar o ponto escolhido. Finalmente, é importante que seja definida uma forma de saber se as ações trouxeram alguma melhoria ou não.

Por exemplo, você pode identificar que o problema que será atacado na próxima iteração é que somente um desenvolvedor pode trabalhar em alguns sistemas, porquê os outros não conhecem o sistema. Isso é seu problema, uma ação/atitude que você pode tomar é definir que a equipe irá utilizar programação em dupla, principalmente com esse desenvolvedor quando estiver trabalhando em um sistema que só ele tem conhecimento. Para saber se essa atitude/ação teve algum resultado, você (junto com a equipe) define que até a próxima retrospectiva deverá ser feito ao menos 20 horas dessa programação em dupla. Assim na próxima retrospectiva você checa quantas horas de programação em dupla foram feitas, podendo verificar se o problema encontrado na retrospectiva anterior foi atacado ou não.

Continuando… antes do tradicional “O que foi bom”, “O que pode ser melhorado” e “O que foi mal”. Fiz outra atividade. Comentei novamente sobre o que é desperdício no Lean e apresentei as 7 formas mais comum de desperdício no desenvolvimento de software:

  • Trabalho particialmente finalizado
  • Processos extras
  • Funcionalidades extras
  • Mudança de contexto
  • Espera
  • Movimentação
  • Defeitos

Depois disso, utilizei a idéia de votação por pontos, onde cada desenvolvedor pode escolher 2 desperdícios e votar neles, os mais votados (ou o mais votado) seria escolhido para discussão do porquê (análise da raiz do problema) ele ocorre e o que pode ser feito para que não aconteça mais. Os mais votado foi “Defeitos”. Ficamos alguns minutos discutindo sobre isso, você pode atacar esse desperdício de várias formas, por ser algo muito abrangente. Depois de alguma discussão, eles concluiram que se utilizassem melhor as funcionalidades do Zend Framework (o problema, não conhecem a fundo o framework utilizado), eles poderiam reduzir o número de defeitos. Como isso também estava muito vago, conversamos mais uns 3 minutos e ficou definido que para a próxima semana (a ação/atitude) eles irão estudar o Zend_DB_Table. Para verificar se o problema foi atacado na iteração atual, na nossa próxima retrospectiva além de verificar se as horas foram gastas estudando o componente, também ficou combinado que, se for vantajoso utilizar o componente, deverá estar escrito em algum lugar alguns exemplos das situações que serão mais utilizadas no dia-à-dia, facilitando assim a utilização. Se não for vantajoso, será discutido onde o componente falha.

Depois seguimos para o “O que foi bom”, “O que pode ser melhorado” e “O que foi mal”. Combinamos que faríamos essa atividade, mas não iríamos atacar nenhum problema levantado nessa atividade, pois para a próxima iteração o Zend_DB_Table já irá ocupar bastante tempo. Essa atividade foi mais leve e rápida, na coluna “o que foi bom” apareceram coisas como “utilizar quadro e post’it” até coisas mais específicas como “fazer a validação do usuário utilizando ajax”. Eu acho ótimo isso, nessa hora é preciso pensar desde o processo até detalhes de implementação. Os pontos negativos levantados foram a mudança de contexto, que segundo eles diminui bastante mas ainda incomoda, além de um cliente que parece ser daqueles bem chatos.

Além disso, durante a retrospectiva, resolvemos criar mais uma coluna no quadro de tarefas. Atualmente, enquanto uma funcionalidade estava esperando a aprovação do cliente, ela ficava na coluna “Impedimentos”. O problema é que essa coluna ficou com bastante itens (4 ou 5) que eram apenas aguardo de aprovação do cliente, e havia também um pequeno impedimento de verdade, que quase sumia no meio de tanta espera por aprovação do cliente. Como a idéia é que impedimentos existem para serem eliminados, essa dificuldade em ver facilmente que existe um impedimento além de aprovação do cliente me incomodou. Então agora o quadro tem mais uma coluna: “Aprovação”, que identifica os itens que estão pendentes de aprovação. Assim a coluna de impedimentos tem novamente a atenção necessária.

Depois disso, falei para eles que estava na hora do cafézinho!

Para finalizar, fomos para o planejamento da próxima iteração. Novamente algo foi alterado. Quem realiza o papel do cliente, também é desenvolvedor. Sendo assim, ele não precisa que a equipe estime uma user story (ou funcionalidade) para saber se é maior ou menor do que outra. Ou seja, ele pode organizar o product backlog (lista de funcionalidades) sem o auxílio da equipe, pois ele tem noção do quanto uma user story é maior que outra.

Contudo eu acho que é interessante que eles continuem estimando as user stories utilizando pontos, pois caso eles comecem a desenvolver outro projeto,  com outro cliente, eles já vão saber como funciona a estimativas por pontos. Esse é o único motivo pelo qual eles estão estimando por pontos as user stories, somente para conhecer bem o funcionamento para que possam usar, quando for necessário.

Então o planejamento ficou um pouco diferente, cada cartão contendo uma user story era apresentado, os detalhes eram explicados para a equipe. A equipe então estimava utilizando pontos (story points), em seguida quebrava a user story em tarefas e já estimava em horas ideais. Antes de iniciarmos o planejamento, foram calculadas quantas horas cada desenvolvedor tinha disponível, feito alguns descontos (suporte e horas ideais não representam horas reais) para chegar ao que acreditamos ser o total de horas ideais disponíveis essa semana. Então fomos estimando cada user story, quebrando em tarefas e estimando as tarefas até o total de horas disponíveis para a semana.

E foi isso, tudo devidamente estimado, cartões e post’it fixados no quadro, hora de trabalhar. Quinta-feira estarei de volta lá para ver  como as coisas estão andando.

Read Full Post »

Antes de começar, só vou adicionar algo importante que esqueci de escrever no post anterior. Antes da reunião para gerar as user stories, nós conversamos e geramos uma definição de pronto. Como são projetos diferentes, alguns mais antigos estão com códigos estruturados e os novos utilizando o Zend Framework, a definição de pronto ficou um pouco diferente para os dois tipos de projetos. Basicamente, a definição de pronto dos projetos utilizando o Zend Framework é a definição de pronto dos projetos estruturados, mais a necessidade de testes de unidade e de aceitação.

Bem, dito isto, vamos em frente. Hoje fiz novamente uma visita na empresa. Precisava corrigir um problema no subversion deles (esse problema estava corretamente identificado na coluna “Impedimentos” do quadro deles). Além disso também queria acompanhar o andamento semanal e o stand up meeting (ou daily scrum, ou reunião de pé).

Cheguei lá e vi que eles já tinham definido um horário para o stand up. 15 minutos após o horário de início de trabalho. Pude observar também que eles não ficaram enrolando, lendo emails e essas coisas até a hora da reunião, eles estavam trabalhando normalmente, quando um deles falou “Vamos lá?”, todos levantaram, deram uma rápida olhada para o quadro de tarefas e responderam as famosas perguntas, ponto positivo. Em 3 desenvolvedores a reunião demorou uns 4 minutos, outro fator positivo. Eles conseguiram entender que o espírito é manter o foco e gerar comprometimento. Distribuí apenas um aviso, (depois que a reunião encerrou) pois um deles aproveitou que estava de pé e foi ligar a impressora enquanto outro falava. Durante a stand up meeting, não se pode fazer outras coisas, nada de telefone, impressora, café, nada! É hora da stand up meeting.

Depois fui observar o quadro para ver como está o andamento da semana deles. Segundo eles, algumas estimativas foram bem diferentes do tempo que realmente levou. Tarefas estimadas em 3 horas ideais demorando 2 horas reais e algumas estimadas em 1 ou 2 horas ideais demoraram 4~6 horas reais. Mesmo assim o andamento está legal, provavelmente amanhã pelo meio dia eles devem terminar as user stories planejadas.

O único problema é que na definição de pronto deles, está a necessidade de aprovação do cliente. Essa necessidade de aprovação é porque eles trabalham com o design do site, e essa parte geralmente é mais complicada e o cliente acaba pedindo algumas pequenas modificações. Além disso, trabalhando com múltiplos clientes e as alterações são geralmente pequenas, não é possível fazer uma review meeting com todos eles, então para algo ser considerado pronto, é necessária essa aprovação. Continuando, o problema é que geralmente o cliente demora para fazer a aprovação. Não tendo aprovação, essa tarefa não está pronta nem em andamento, ela vai para a coluna de  impedimentos no quadro.

Claramente existe um problema aí, essa demora de aprovação do cliente está gerando muitos itens na coluna impedimento, contudo logo teremos nossa reunião de retrospectiva e vamos conversar sobre isso.

Read Full Post »

Desde semana passada estou trabalhando com uma empresa aqui da região para implantar desenvolvimento ágil no ambiente deles.

A empresa é pequena, atualmente são 4 (3 desenvolvedores) pessoas trabalhando internamente e outras 2 pessoas (designer e alguém que irá produzir os wireframes de um projeto) trabalhando externamente.

Atualmente a empresa desenvolve alguns sites e está iniciando um grande projeto (não posso comentar o que é eses projeto) e o dono da empresa veio conversar comigo, pois estava iniciando esse novo projeto e gostaria de aplicar desenvolvimento ágil desde o início.

Na semana passada eu apresentei a parte teórica do desenvolvimento ágil. Comecei com aquela introdução tradicional/histórica sobre o início com o sistema Toyota e processos empíricos. Falei do Agile Manifesto, falei várias vezes para eles se preocuparem com os valores e princípios, não as práticas. Continuei falando sobre princípios, agora os princípios do Lean, esses eu sugeri que eles imprimissem e colassem na parede da empresa.

Depois fui para o Scrum. Na verdade a parte de Scrum foi bastante sucinta, algo em torno de 2 horas. Expliquei os conceitos do Scrum, novamente sempre explicando que todas aquelas práticas tem um motivo para existir. Seguir somente as práticas é estar destinado a não alcançar os melhores resultados.

Nesta semana, na segunda-feira expliquei pra eles como funcionam as estimativas. Novamente comecei com uma introdução teórica de um pouco mais de 1 hora, onde falei sobre como estimar por tamanho, ao invéz da tradicional estimativa por tempo, o que é uma user story, estimativas em dias ideais, estimativas por pontos (story points), planning poker entre outros.

Assim que terminei essa explicação teórica partimos para a prática. O dono da empresa é o cliente (product owner), ele é quem tem a idéia do projeto principal. Quanto aos outros projetos (quase todos sites) ele é  quem conversa com o cliente e então toma a decisão sobre o que desenvolver na próxima iteração. Então a primeira tarefa foi gastar algum tempo escrevendo uma boa quantidade user stories.

Começamos escrevendo as user stories em um nível mais alto (epics) para o projeto principal, que ainda é somente uma idéia. Depois disso, ele decidiu qual user story ele gostaria de desenvolver primeiro e quebramos ela em user stories menores. Para os demais projetos (todos já existentes) escrevemos as demais user stories. Quando terminamos nós já tinhamos um product backlog.

O próximo passo foi fazer as estimativas. Convresei com eles e acertamos que iríamos utilizar story points para estimarem as user stories e dias ideias (horas, na verdade) para estimarem as tarefas. Então começamos identificando qual seria a user story com 1 ponto, que será utilizada como base para estimar as outras. Tendo identificado essa user story estimamos várias outras (utilizando planning poker), mas não todas, somente as que teriam chances de serem desenvolvidas nas próximas 3~4 semanas.

Durante o planning poker, houve somente uma situação interessante. Uma user story envolvia desenvolver algo bastante diferente, que nenhum dos desenvolvedores tem experiência ou poderia dar maiores informações de como desenvolver. Eles não tinham idéia do quanto de trabalho seria necessário para resolver aquele problema. Então conversei com eles e disse pra não estimarem esssa user story. Uma melhor solução será alocar algum tempo durante a próxima iteração e realizar um spike sobre esse problema, assim na outra reunião de planejamento (reunião para a 2ª iteração) eles vão poder estimar essa user story.

Devidamente estimadas, novamente o dono (que faz o papel do cliente/product owner) foi chamado para organizar o product backlog por ordem de importância, agora sabendo as estimativas de cada user story ele organizou a lista da maior para menor prioridade – da user story com maior valor para a user story com menor valor.

Antes de começarmos o planejamento da iteração, decidimos utilizar uma iteração (sprint) de 1 semana. É comum os clientes dessa empresa aparecerem com pedidos para um futuro bem próximo, iterações de 1 semana vai permitir que esses itens com maior urgência sejam atendidos, sem alterar a iteração atual. Certo, continuando fizemos as contas de quantas horas cada desenvolvedor terá de tempo livre na semana (descontamos algum tempo pois eles também prestam suporte), somamos as horas de todos os desenvolvedores, multiplicamos por 0,6 (consideramos que uma hora normal é igual a 0,6 de hora ideal, pois eles atendem telefones, trabalham em mais de um projeto e outras coisas que prejudica a produtividade). Com isso chegamos a um total de horas ideais livres que temos essa semana.

Então começamos o planejamento. Primeiro a user story com maior prioridade. Quebramos ela em tarefas e estimamos as tarefas em horas ideais. Continuamos por mais algumas user stories até que o total de horas ideais que tinhamos livre para a semana estava completa (sobrou umas 2~3 horas ideais, mas nenhuma user story era tão pequena, então sobrou esse tempo).

Depois disso, colocamos os cartões no quadro, cada desenvolvedor já pegou sua tarefa e começou a desenvolver.

Continuarei indo nesta empresa por mais alguns dias e vou colocando aqui no blog como anda a adoção do desenvolvimento ágil nesta empresa. Vamos continuar melhorando a adoção do Scrum e das práticas de estimativas e planejamento, depois vou começar com TDD, testes de aceitação e integração contínua.

Read Full Post »

Michael James escreveu um texto bem legal, com o título de Scrum and Risk Management.

Uma coisa interessante que ele escreve, é a forma que metologias tradicionais atacam os riscos sempre no início, contudo no desenvolvimento de novos produtos, você não pode atacar todos os requisitos com maior risco no início, porque você ainda não sabe quais serão.

Esse texto me lembrou uma conversa que tive, onde alguém interessado em Scrum perguntou “E qual é a diferença do Scrum? Como vocês fazem quando estoura o prazo do projeto?”.

Hmm, aparentemente o responsável pelos projetos nessa empresa estava muito preocupado em garantir como serão feitas as coisas, depois que o projeto estiver afundando e não em como evitar do projeto afundar

Read Full Post »

Older Posts »