Feeds:
Posts
Comentários

Posts Tagged ‘Lean’

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 »

Hoje foi o dia de apresentar Scrum para o meu gerente.

O meu gerente (aquele que ministra cursos CMMi) gostou do Scrum, gostou do funcionamento em iterações (sprints), a questão da melhoria contínua, o trabalho em equipe e adorou a reunião de planejamento da iteração e de retrospectiva… Ele será o product owner, pois como atualmente a equipe trabalha em aproximadamente 4 projetos, ele será responsável por conversar com os clientes (devem ser quase 15) para ver o que eles desejam que seja implementado e assim tomar a melhor decisão (ROI).

Apesar de ele ter gostado, eu acredito que ele ficou com uma pulga atrás da orelha. Ele pediu o nome de algumas empresas que utilizam Scrum na região de Blumenau ou Florianópolis, no ato eu pensei na Audaces, onde o Victor está ajudando a inserir Agilidade na empresa, além disso enviei alguns depoimentos de empresas que adotaram desenvolvimento Ágil. De qualquer forma, ele aprovou utilizar Scrum, inserindo as práticas aos poucos com a equipe. Amanhã vou conversar novamente com ele para deixar bem claro que o papel de product owner é fundamental para conseguirmos alcançar bons resultados.

Durante a conversa, além de falar sobre Scrum, eu citei os princípios do Lean e deixei bem claro que mais importante que as práticas, são os princípios, e é nisso que precisamos nos concentrar.

De uma forma resumida, acho que foi isso, a conversa deve ter demorado aproximadamente 90 minutos e tentei mostrar o quão poderoso o desenvolvimento Ágil é. No próximo post irei comentar como foi a apresentação do Scrum para a equipe…

Read Full Post »

Novamente com Mary Poppendieck

If your more than 10% of requirements are changing as you progress, you’ve specified them too early. If you have separate test and fix cycles you’re testing too late.

Read Full Post »

Hoje no Quote of day uma frase de Mary Poppendieck:

Change isn’t the enemy. Anticipate change. It’s there to make things flexible. The ‘soft’ in software is there for a reason. Software is meant to change so stop trying to nail everything down. Write change-tolerant software by employing change-tolerant practices.

Read Full Post »

Hoje (04/10) às 18 horas (GMT -3) a NetObjectives estará oferecendo outro webminar, desta fez o assunto é Designs Patterns.

O palestrante será o conhecido Alan Shalloway, que provavelmente irá seguir sua tradição de ótimas palestras. Maiores informações sobre o webminar assim como informações de como se inscrever podem ser encontradas aqui.

Read Full Post »

O post de hoje vai ser somente um quote de uma parte de um email do Skip Angel que eu gostei. Isso deveria estar colado em locais visíveis nas empresas 😀

Eat your own dog food. You should build what can be sustained over time. Knowing what you build could come back to haunt you should be some incentive to build the right thing.

Developers should think in terms of preventing defects (value) vs. fixing bugs (waste). Developers should think in terms of accommodating change (value) rather than making code difficult to change (waste in rewriting) or anticipating change (waste in building more than you need). If you start looking at building quality in instead of fixing/finding quality later, this is what you should understand to produce sustainable software products.

Read Full Post »

Post curto e direto!

Aqui você encontra entre outros artigos, um escrito por Alan Shalloway onde ele fala um pouco sobre “Lean anti-patterns and what to do about them”. Além desse artigo, tem alguns outros ali que também são interessantes.

Read Full Post »

Older Posts »