Por que Scrum funciona?

• A natureza iterativa de desenvolvimento do Scrum(incluindo a reestruturação de prioridades entre as iterações)


• Celulas de desenvolvimento completas do Scrum (juntos todas as pessoas necessárias para realizar um trabalho)


• Pelo fato de muitas equipes utilizando Scrum tiveram a change trabalharem no mesmo ambiente físico


• Muitas equipes Scrum trabalham em um projeto por vez


• A maior parte dos relatorios chatos e pesados, além de formulários burocráticos estão sendo deixados de lado porque as equipes estão produzindo algo novo


• O Foco em definir testes de aceitação juntamente com os requisitos


• A disponibilidade de campeões(Donos do produto e entusiastas de Scrum)

Entenda a história Completa

[]s

Lean: Elimine o Desperdício

O que é Desperdício?

Desperdício(Waste) é tudo aquilo que não adiciona valor a um produto, valor este que deve ser percebido pelo usuário.

Se um componente de software não utilizado usuário é mantido no sistema, isto é disperdício. Se um ciclo de desenvolvimento de software se esforça para levantar um livro de requisitos que não é lido, isto é desperdício. Se os desenvolvedores produzem mais funcionalidades que o imediatamente necessário, isto é disperdício. Em desenvolvimento de software, transpor o trabalho entre equipes é disperdício.
Para o modelo Lean, o ideal é encontrar o que o cliente deseja, e então criar ou entregar exatamente o que ele necessita, virtualmente no exato momento da solicitação.
Qualquer coisa que entre no caminho de rapidamente satisfazer uma necessidade do cliente é considerado desperdício!

Encontrando desperdício

Por Mary Poppendieck: Eliminate Waste

Os sete desperdícios do Desenvolvimento de Software

Trabalho Particialmente Finalizado
Você deve possuir uma vaga idéia de como o sistema funcionará. Pode até ter uma noção de requisitos de negócio e condições de sucesso para uma funcionalidade. Quem sabe até mesmo algum código produzido.
Entretando, equanto este código não estiver integrado a sua base de código, tiver sido validado e aceito por seu usuário, não há como prever o seu comportamento. Funcionalidades pela metade apenas atravancam o caminho para trabalhos que poderiam ser feitos. Tornando-se facilmente obsoleto, trabalho parcionalmente concluído é pior do que trabalho nenhum... Funcionalidades e códigos parcialmente finalizados ampliam a complexidade de seu sistema, e amplificam os custos de manutenção de sua aplicação.

Processos Extras
Você já se perguntou se todo o papel utilizado é realmente necessário? Algum procedimentos para desenvolvimento de software requerem papeis para serem assinados por usuários, fornecendo rastreamento e permitindo a aprovação para uma mudança. Já verificou se o cliente realmente acha estes procedimentos valiosos? O fato de um documento ser um artefato de software não o torna valioso. Se você tem que esperar que um documento seja produzido para que você inicie o seu trabalho, reavalie a real necessidade de tal documento, e porque não, proponha mudanças. Lembre-se: procedimentos podem e devem ser questionados!

Funcionalidades a mais
Pode parecer ótimo entregar ao cliente mais funcionalidades do que ele está esperando... pegá-lo de supresa, e supreendê-lo... este é o desperdício mais śerio. Mais funcionalidades significa: Mais código para ser mantido. Mais testes para serem realizados. Mais documentos de especificação para serem criados. Mais conteúdo para gerar documentação. Mais bugs para aparecerem no sistema... enfim: jogar dinheiro no lixo... ainda mais se você pensar que 80% do total de funcionalidades de um sistema simplesmente não são utilizadas.

Troca de tarefas
Organizar pessoas em múltiplos projetos é outra forma de desperdício. Por ser uma atividade essencialmente intelectual, é necessário, toda vez que ocorrer a troca entre tarefas de projetos diferentes, que o desenvolvedores foque-se em algo completamente novo. Contexto de projeto diferentes, realidades diferentes, procedimentos muitas vezes diferentes...
O tempo que ele levará para estar realmente produtivo em cada projeto reduzirá muito! Sem contar que, normalmente, ocorrerá uma guerra de interesses entre os projetos pela atenção do desenvolvedor...
Minha vó já dizia: fazer muitas coisas ao mesmo tempo é um pretexto para não finalizar nenhuma

Espera
O maior ponto de desperdício em desenvolvimento de softwar é esperar para que algo seja produzido. Esperas em iniciar projetos, realizar testes, aguardar o levantamento de requisitos detalhistas, desenvolver uma funcionalidade são consideradas desperdício.
Atrasos distanciam seu usuário de receber um produto que satisfaça suas necessidades. Em muitos casos, atrasos são apenas a ponta do iceberg para problemas muito maiores. Em ambientes e mercados muito competitivos, atrasos e esperas podem significar milhões de investimento perdidos.
Poucos consideram custos realicionados a participação do mercado como sendo influenciada por atrasos... mas os principais líderes do mercado atualmente foram os pioneiros em seus nichos...

Movimento
Desenvolvimento de software é uma atividade que demanda muita concentração, e interrupções podem ser desastrosas no trabalho realizado. Quanto tempo um desenvolvedor leva para encontrar uma informação? Questões sobre requisitos de negócio ou informações técnicas levam quanto tempo para serem respondidas?
Documentos que transitam entre setores também são disperdícios. Quanto mais pontos um documento passar para iniciar sua implementação, maior será o ruído causado pela interpretação de informações (efeito telefone sem fio)

Defeitos
Você sabe o quanto custo a correção de um problema em fase desenvolvimento? e na integração? UM ABSURDO!!
Defeitos no sistema não agregam valor, não satisfazem o cliente, e definitivamente não são baratos. Qualquer tipo de retrabalho causado por problemas de implementação de requisitos, interpretação de necessidades e correção de documentação devem ser severamente combatidos. Neste ponto os métodos ágeis diferem muito dos modelos mais tradicionais: Construa com qualidade, não tente aferir qualidade após o produto pronto. Crie uma sistema que evite que os erros ocorram, e não que verifique se eles estão presentes em seu sistema para depois corrigí-los.



Tentar eliminar alguns dos desperdícios existentes no desenvolvimento de software é o primeiro passo para melhorar a qualidade de seu sistema... Tente!

"O" Melhor em OpenSource

A notícia de hoje foi enviada pelo amigo "anarquista" Ederson (boi):

2007 The World Bossies Awards

Traduzindo: "O" Melhor do OpenSource

Encontre respostas para estas perguntas:

• É possível que uma empresa progredir com software livre?


• Soluções em CRM, ERP, SAS, VoIP, Gestão de Conteúdo? Mesmo?


• E o que ganhamos com isso?

As categorias:

As melhores aplicações OpenSource
O principal em CRP, ERP, Portais, Gestão de Conteúdo e plataformas de colaboração

O Melhor em redes
Os ganhadores em VoIP, serviço de diretórios, streaming de mídia, analizadores de protocolo e sniffers wireless

O Melhor em middleware
Os selecionados entre sistemas operacionais, servidores de aplicação, servidores web e plataforma de virtualização


O Melhor em segurança
Principais projetos em avaliação de vunerabilidades, prevensão de intrusão, anti-virus, anti-spam, firewalls, VPNs e testes de segurança

O melhor em desenvolvimento de software
As escolhas entre IDEs corporativas, rich Internet app platforms, AJAX toolkits, sistemas de gerenciamente de regras de negócio e servidores de integração contínua.

O melhor em storage
Sistemas de arquivos, servidores de arquivos, sistemas de storage via rede e ferramentas de benchmark




Leitura de cabeceira obrigatória nos dias de hoje...

[]s

Velocity? que tal Capacity?

Desabafo muito interessante de Tim Ottinger da Object Mentor, falando sobre um dos termos mais utilizados em scrum: Velocity

Complementando o post do Tim, vou aproveitar e tecer alguns comentários...

Trocando em miúdos: velocidade é a CAPACIDADE da equipe em produzir uma parte do sistema... simples?? Nem tanto.
Notou a ênfase no termo capacidade?

Isto quer dizer que, tendo em mente o conceito de funcionalidade finalizada:

Uma equipe deve medir a velocidade desde que este valor não seja tomado como um indicador de pressão. Vou explicar melhor: imagine-se numa equipe Scrum. Até ai, tudo lindo e maravilhoso... a quantidade de trabalho que a equipe consegue suportar com saúde é 35 pontos(ou horas ideais). Qualquer mudança neste número pode significar duas coisas: um desastre para seu gerente ou uma aparente evolução da equipe.

Quando for um desastre

Somos seres humanos, e qualquer gestor não identificará com bons olhos a menor variação para menos no valor da Velocidade da equipe. Por quê??? Oras, é muito mais fácil criticar e dzer que a equipe deixou de cumprir as "metas" e está fazendo corpo mole.
Entenda, nesta situação a Velocidade está sendo encarada como uma medida de produtividade, sem que explicitamente isto seja dito. Assim, a primeira atitude seria forçar o retorno ao estado anterior, mesmo que para isso seja necessário cortar qualidade. Isto fere completamente as Regras de Ouro do Desenvolvento Ágil e removerá muitos dos benefícios da abordagem.

Aparente evolução da equipe

É bom finalizar uma Sprint com o Burndown zerado... certo? Orgulha a equipe, dá direito a pizzas, talvez uma ida mais cedo pra casa... e assim, no próximo Sprint o melhor a fazer é conseguir "aquele pouquinho a mais", pra incentivar a equipe a se esforçar mais... para no proximo sprint, se tudo correr bem, forçar um pouquinho a mais as "metas"...


Moral das duas histórias: Onde está a preocupação com o quê foi produzido?? É muito fácil se perder em números e na tentativa de controlar a produtividade da equipe através de gráficos burndown que finalizam "na mosca" e pré determinando a velocidade dos sprint.
Velocidade é uma medida de estado/capacidade e não predição. Ela apenas determina o quanto, na situação da sprint, a equipe é capaz de fazer.

Meça produtividade de outras formas: label: Métricas

Uma sugestão interessante: você consegue analizar a relação:

Funcionalidades Finalizada X Valor de Negócio X Sprint

Não??? Antes de pensar em quantos pontos uma equipe faz ou deixa de fazer, meça o quanto a produção deles está lhe trazendo de retorno... vai se surpreender...
Metas, no desenvolvimento Ágil, são as funcionalidades que a equipe conseguiu alcançar, e não a estimativa que tais atividades possuem... Meça o que realmente importa, deixa a equipe cuidar do resto




Pra finalizar:

Treinamento Scrum SC - Teamware

12 e 13 de Maio - Florianópolis

Objetivos:

Cada individuo será treinado para ser capaz de assumir as seguintes responsabilidades:

• Utilizar Scrum para gerir o trabalho como membro de uma equipe de desenvolvimento de produtos.
• Remover as barreiras entre o desenvolvimento e o cliente, para que o cliente dirija o desenvolvimento.
• Ensinar o cliente como maximizar o ROI e alcançar os seus objetivos através de Scrum.
• Melhorar continuamente a vida da equipe de desenvolvimento através da liberação da criatividade e o fortalecimento.
• Melhorar continuamente a produtividade da equipe de desenvolvimento de todas as formas possíveis.
• Melhorar continuamente as práticas de engenharia e suas ferramentas, para que todo incremento de funcionalidades seja potencialmente entregável.

Mais informações: Gestão Ágil de Projetos com Scrum SC


[]s