31 outubro 2008

Aparando arestas

Quando aplicamos Scrum em uma empresa, sempre tomamos o cuidado de inserir na cultura dela a importância de se adaptar e melhorar. Contudo, existem situações que podem atrapalhar e muito o fluxo dentro de uma empresa. Uma delas é quando existem rixas entre diferentes equipes.

Infelizmente é uma situação bastante comum em empresas que mantém "silos", principalmente quando promovem a competição entre eles.

E claro, isso acaba com o comprometimento entre as equipes, conseqüentemente eliminando qualquer tipo de colaboração que deveria haver. A empresa deixa de ser um "todo".

Mas o que pode ser feito para acabar com isso?

  • Eliminar os silos. E somente a direção da empresa tem o poder de fazer isso. Desta forma deixam de existir a "equipe de analistas", a "equipe de testes", "equipe de arquitetos", e assim por diante.
  • Criar equipes multi-funcionais. Em uma equipe entre 7 a 9 pessoas é possível ter um arquiteto, um analista, alguns desenvolvedores, um testador, etc.
  • Se mesmo assim ainda houver equipes com problemas de relacionamento entre elas, faça com que trabalhem juntas. Para se resolver um problema, o primeiro passo é encará-lo como tal e a partir daí encontrar a raiz dele.
  • E claro, mantenha sempre a visão do produto bem clara e aparente. Nunca confie em subjetividades.

Claro, isto não é um estudo aprofundado sobre a natureza humana e muito menos um guia para resolver este tipo de problema. Mas serve como ponto de partida para resolver este tipo de problema que atrapalha e muito qualquer tipo de empresa.

27 maio 2008

Foco no Valor

Quando implantamos Scrum em uma empresa, podemos notar diversas mudanças no time logo nos primeiros Sprints: um nível maior de comprometimento, maior auto-estima, motivação. Entretanto, no decorrer das Sprints, devemos ter o cuidado de manter o foco do time no valor para o cliente.

Isso porque depois de anos e anos executando tarefas designadas por um gerente de projeto, é normal no calor de uma Sprint os membros do time passarem a trabalhar na forma "orientada a tarefas".

Mas isso realmente acaba se tornando um problema? No fundo não é desejável que o time execute todas as tarefas da Sprint Backlog? Sim, em termos.

Uma das prioridades em Scrum é entregar valor para o cliente, e isto só é possível através da realização de recursos de mais alto valor definidos por ele, com qualidade. Executar as tarefas pura e simplesmente, utilizando boas práticas de engenharia de software (testes unitários, design patterns, etc.) asseguram uma boa qualidade de código, mas não garantem qualidade no valor para o cliente.

Ao se desenvolver um item completamente, temos a garantia de que o fluxo do item está funcionando de acordo com as necessidades do cliente, o que se traduzirá como real valor para o cliente ao final da Sprint.

Então, como fazer com que o time enxergue a necessidade de se executar a Sprint de forma "orientada a itens ou features"? Obviamente uma das formas é explicando e mostrando a necessidade. Mas nem todo mundo entende a real necessidade desta forma.

Em uma recente implantação de Scrum em um cliente, me deparei com esta situação e resolvi propor um exercício para todos os "pigs": criarem User Stories juntamente com o Product Owner. E o exercício se revelou bastante interessante.

Utilizando algumas dicas postadas no artigo Focus on Value de Chris Sterling, pedi que todos os membros criassem uma declaração de valor para o produto, respondendo à seguinte pergunta:

"Quais valores ou benefícios este produto trará ao usuário?"

Em seguida, pedi que identificassem possíveis perfis de clientes para o produto e conforme os perfis iam surgindo, os discutíamos e se fossem válidos, os listávamos no quadro.

Finalmente, pedi que se separassem em grupos de acordo com a quantidade de perfis e cada grupo tratou de criar um User Story para o seu perfil, preenchendo as lacunas da seguinte frase:

"Eu, como <perfil>, gostaria de <recurso> para que eu possa <valor>!"

Quinze minutos depois, pedi que todos se reunissem novamente, e solicitei que cada grupo expusesse as User Stories criadas, uma por vez. Cada vez que o grupo expunha uma User Story, todos os outros membros discutiam sua validade e em caso positivo, passávamos a estória para uma lista que depois poderia ser utilizada pelo Product Owner gerar mais itens para o Product Backlog.

Embora alguns itens ainda não tenham sido aproveitados, o time pôde compreender um pouco melhor o conceito de "valor" para o cliente. E assim ficou mais fácil explicar a diferença entre o trabalho "orientado a tarefas" e "orientado a features". Ou User Stories.

23 maio 2008

Qualidade com Scrum

Quando falamos sobre qualidade em software, surgem diversas dúvidas quanto ao que significa ter qualidade em um software: ter um código bem escrito? Código que não apresente falhas? Boa performance no que se propõe a fazer?

De acordo com a NBR 13596 (ISO/IEC 9126), existem algumas características que um software deve apresentar para ser considerado como um software de qualidade. Estas características são listadas na tabela a seguir:













CaracterísticaDescrição
FuncionalidadeSatisfaz as necessidades?
ConfiabilidadeÉ imune a falhas?
UsabilidadeÉ fácil de usar?
EficiênciaÉ rápido e "enxuto"?
Manutenibilidade
É fácil de modificar?
PortabilidadeÉ fácil de usar em outro ambiente?

A maioria das características que determinam um software com qualidade referem-se mais a boas práticas de engenharia de software ou eficiência da plataforma tecnológica. Entretanto, Scrum, como framework para gerenciamento de projetos, também é capaz de oferecer qualidade no processo de desenvolvimento.

Em Scrum, conseguimos uma melhora na qualidade através de diversos pontos. Entretanto, obter esta melhora na qualidade depende muito se Scrum está sendo bem implementado ou não.

Dentre estes pontos, podemos destacar:
  • Iterações
  • Remoção de impedimentos
  • Inspeção e adaptação
  • Autonomia
  • Times multi-funcionais

Iterações

Qualidade em software também significa entregar para o cliente algo que lhe seja realmente útil, de acordo com suas necessidades.

Por ser uma framework ágil, Scrum trabalha com iterações, onde a cada iteração entregamos software, ou incrementos de software, potencialmente usável e de acordo com a necessidade do cliente. E a cada nova iteração, temos "feedback" do que foi entregue e que utilizamos para melhorar o produto (sempre de acordo com a prioridade do cliente).

O "feedback" do cliente haveria de qualquer forma, seja apresentando o produto ao final de uma iteração, seja ao final de todo o ciclo de desenvolvimento, o que normalmente acarreta em alterações no código. Entretanto, se estas alterações forem feitas no final do projeto, isto também pode acarretar efeitos colaterais indesejados, ao passo quefazê-las de forma antecipada impede este tipo de problemas.

Através das Sprints, times Scrum estão sempre desenvolvendo algo que realmente tenha valor para o cliente.

Remoção de impedimentos

Remover qualquer tipo de impedimento durante a execução de um projeto é essencial não importa qual metodologia seja utilizada. Em Scrum é esperado que estes problemas apareçam. Mas o que é feito após resolver este impedimento determina se um time está utilizando Scrum corretamente ou não.

Durante a execução de uma Sprint, é recomendável que a execução das tarefas seja feita item a item ao invés de cada membro executar tarefas de itens diferentes. Isso tem duas razões: a primeira é relacionada ao valor para o cliente. Para um cliente, um item somente tem valor caso tenha sido entregue completamente -- uma funcionalidade que esteja funcionando 80% não lhe trará vantagem alguma. Além disso, executar um item completamente ajuda a manter o foco da equipe na meta e no item em específico. Desenvolvedores em geral tendem a ser mais orientados a tarefas ao invés de orientados a valor. Manter o foco na meta ajuda a aumentar a qualidade do item sendo desenvolvido.

A outra razão é em relação à forma como os problemas são resolvidos e suas correspondentes soluções são utilizadas. A execução completa de um item representa um fluxo completo de execução e faz parte do processo utilizado no desenvolvimento. Neste caso, problemas que poderiam se tornar recorrentes podem ser solucionados imediatamente, permitindo que isso não se repita na execução dos próximos itens. Desta forma estamos aprimorando o processo, o que também reflete na qualidade do produto.

Inspeção e adaptação

Ao final da execução de uma Sprint há a Sprint Retrospective, uma das cerimônias de Scrum. Nela, revisamos a Sprint (inspeção) e determinamos o que foi bom e o que precisa ser melhorado (adaptação). As adaptações podem ser individuais ou coletivas, mas de qualquer forma são uma forma de garantir a melhora do processo e consequente otimização, o que traz diversos benefícios.

Com um processo mais enxuto e mais eficiente, podemos ter um software com mais qualidade.

Autonomia

Times em Scrum são auto-gerenciados, o que significa uma menor pressão sobre eles. Desta forma, cada um dos membros pode selecionar o que fará e terá o tempo necessário parafazê-lo com qualidade. Estudos mostram que, sob pressão de prazos exíguos, a primeira coisa a ser deixada de lado pelos desenvolvedores é a qualidade.

Além disso, através desta autonomia, os membros do time passam a ter uma melhor qualidade de vida, o que reflete em uma melhoria na qualidade como um todo. Isso porque passam a ter mais tempo e disposição para pesquisar uma melhor forma de abordar e executar uma tarefa. Em um ambiente onde Scrum tenha sido bem implantado, este aprimoramento pessoal é compartilhado com os outros membros, o que traz mais incremento na qualidade.

Times multifuncionais

Quando montamos os times, procuramos sempre montá-los com membros que tenham diferentes características ou atribuições. Por exemplo, ao invés de um time formado só por desenvolvedores ou só de analistas de requisitos, procuramosmisturá-los e formar diversos times Scrum.

Isto porque a experiência de cada um é extremamente útil no planejamento das tarefas a serem executadas na Sprint. Entretanto, existe um conceito maior escondido por trás disto: qualidade desde o início.

Pude presenciar em diversas ocasiões a seguinte situação: empresas utilizando o modelo em cascata, faziam o levantamento de requisitos no início do projeto. Em seguida, arquitetos de sistema e especialistas no negócio modelavam as classes para atender a todos os requisitos levantados na etapa anterior. Depois (bem depois, por sinal), estes modelos eram passados para a equipe de desenvolvimento e o resultado era testado pela equipe de Q&A e homologação. No final do processo, isto era entregue à equipe de implantação.

Invariavelmente, o contato com o cliente era feito no início do projeto, onde este apresentava todos os requisitos possíveis e imagináveis para o produto. Embora saibamos que o cliente saiba o que precisa mas tenha somente uma vaga idéia do que quer, ele era obrigado a informar o que desejava que fosse desenvolvido, e por isso a quantidade de requisitos, algumas vezes desnecessários, era imensa.

Durante a modelagem, os analistas modelavam o que era necessário para a aplicação, muitas vezes deixando de lado alguns detalhes que poderiam facilitar o desenvolvimento ou ignorando outros detalhes que pudessem melhorar o acesso aos dados.

Os desenvolvedores, por sua vez, simplesmente executavam o que foi determinado pelos arquitetos e no prazo determinado pelo gerente de projeto.

Depois de devidamente codificado, o resultado era passado para a equipe de Q&A, que testava o que tinha sido produzido e retornava o resultado dos testes à equipe de desenvolvimento. Infelizmente, isto era feito invariavelmente aos lotes -- os testadores eram obrigados a testarem diversos recursos de uma vez, muitas vezes impossibilitando testes com aspectos mais amplos.

Como tudo isso feito às pressas, em algumas situações, a equipe de implantação era informada com poucos dias de antecedência (e em uma situação, a equipe foi informada que tinha até o final da tarde para implantar um sistema). Com tão pouco prazo, muitas vezes a implantação era feita sem qualquer teste, simplesmente esperando que a sorte sorrisse para eles.

Note que os cinco parágrafos anteriores descreveram cada um dos estágios no desenvolvimento. E isto reflete como o desenvolvimento era feito -- sem qualquer comunicação adicional entre cada uma das etapas que não fosse a documentação do sistema. É fácil descobrir o resultado disso.

Através de times multifuncionais, a cada Sprint temos a opinião de especialistas em diferentes áreas definindo o que será feito naquela Sprint. Enquanto não sabemos o que o cliente realmente quer como produto, sabemos o que é mais importante para ele, com estes especialistas definindo a melhor abordagem possível, levando em consideração os aspectos nos quais cada um é melhor. Assim, arquitetos podem começar definindo as classes levando em consideração a opinião de um especialista em banco de dados, de domínio, etc.

Utilizando o princípio de qualidade desde o início, o código tende a ser mais enxuto, mais adaptável, a ter mais performance. Como a interação com o usuário é constante, o produto estará sempre de acordo com a necessidade do usuário. E com a presença de um especialista em testes, cada tarefa executada já pode ser testada e eventualmente corrigida rapidamente.

E finalmente, um especialista em implantação já sabe antecipadamente o que deve testar e providenciar como ambiente de produção.

Conclusões

Existe uma beleza singular na simplicidade apresentada por Scrum. Entretanto, por trás desta simplicidade, existem conceitos que não devem ser ignorados, sob pena de obter somente parte dos benefícios de Scrum.

Um ScrumMaster deve estar sempre atento aos diversos sinais que o time apresenta, bem como motiva-los e desafia-los, sempre em busca constante do aprimoramento individual como seres humanos e o time como um todo. Além disso, buscar a melhoria contínua do processo permite que a qualidade passe a ser uma constante em futuros projetos de software.

24 abril 2008

Scrum nosso de cada dia

"Apofenia" é um termo utilizado para descrever o fenômeno cognitivo de percepção de padrões ou conexões em dados desconexos.

Mas o que isso tem a ver com metodologias Ágeis? Como suas práticas são empíricas, diversas destas práticas são utilizadas por nós no dia a dia. E quem utiliza metodologias Ágeis no dia-a-dia, passa a notar que não somente em gerenciamento de projetos suas práticas são utilizadas. Na verdade, metodologias Ágeis foram inspiradas na forma como lidamos com os problemas do cotidiano para nos disciplinarmos no desenvolvimento de software. Quer um exemplo?

Um outro dia cheguei um pouco mais cedo em casa e decidi fazer uma visita a um primo meu, dentista, cujo consultório fica próximo de minha casa.

Quando cheguei, sua ajudante estava de saída, pois o último cliente chegaria somente depois. Assim, ficamos conversando durante um tempo até que o paciente chegasse. Decidi ficar mais um pouco enquanto ele atendia o paciente, embora o máximo que ajuda que eu pudesse fornecer fosse contar piadas enquanto o paciente estivesse com a boca aberta (já repararam que os dentistas escolhem justo essa hora para conversar ou contar uma piada?). E foi aí que percebi que meu primo utiliza práticas de Scrum em sua profissão também!

Antes do paciente chegar, meu primo reviu o histórico e separou todo o material para fazer uma restauração. Depois de acomodado na cadeira, meu primo dá uma olhada na boca na boca do paciente (deve haver um termo específico para isso) e nota que um dos dentes apresentava cáries. Mudança nos planos:

- Hmmm, só porque peguei o equipo para restauração, vamos ter que mexer nesse outro dente

Para quem ainda não notou os padrões, explico: o paciente apresentou um item de maior importância, o que fez com que a meta da iteração (a consulta) fosse diferente da que ele havia planejado previamente. Ao final, mostrou o que foi feito ao paciente e os cuidados que o mesmo deveria tomar, marcando a próxima iteração, digo, consulta.

E claro, não somente em outras profissões, mas em nossas vidas como um todo somos obrigados a mudar nosso planejamento por conta de algum imprevisto. E imprevistos sempre ocorrem. Afinal, já tivemos que mudar o roteiro de casa para o trabalho ou do trabalho para casa por conta do trânsito, ou postergar a aquisição de um bem porque alguém em casa usou muito o telefone ou aprendeu a cantar ópera no chuveiro. Quem já não teve que encarar e aceitar alterações e reagir de acordo, planejar o que é possível fazer em um curto período de tempo, ou parou para pensar nas lições que aprendeu depois da ocorrência de um fato? Este texto mesmo sofreu diversas modificações até chegar a este ponto.

Bem, se isto é comum às metodologias Ágeis, por que o título refere-se a Scrum?

Porque Scrum é a metodologia (ok, framework) que mais se assemelha ao nosso comportamento natural. Isso porque em Scrum, a engenharia (o "como fazer") é uma implementação que pode ser decidida caso a caso. E por ser uma framework, algumas de suas práticas podem não ser utilizadas em determinadas situações. Mas a essência permanece a mesma: visão, processo iterativo, adaptabilidade e interação/cooperação.

Alguém mais enxerga outros padrões por aí?