wicz journal

Como bem sabemos, um dos princípios dos processos Ágeis é satisfazer o cliente, agregando valor ao produto final. De certa forma, para que essa tarefa possa ser realizada com sucesso, é preciso saber exatamente as necessidades desse cliente.

Felizmente com algumas estórias e feedbacks já é possível ter uma boa idéia de onde devemos chegar. Mas é importante ressaltar que a “qualidade” das estórias influencia diretamente em todo o processo.

As estórias apresentam três aspectos críticos, os quais devem ser obrigatoriamente lembrados no momento de sua criação. São eles: Cards, Conversation, Confirmation. Ou 3C.

Cards — Estórias são escritas em cartões ou post-its. Na verdade o que importa aqui é o tamanho! A sugestão dos cartões e post-its é pelo fato de serem pequenos. E cartões pequenos naturalmente forçam estórias pequenas, de duas a três linhas no máximo.

Conversation — A estória escrita no cartão serve como um lembrete, uma maneira de identificar uma funcionalidade que foi conversada e discutida entre os clientes e desenvolvedores.

Confirmation — Depois das funcionalidades terem sido discutidas e escritas nos cartões, o cliente define (implícita ou explicitamente) uma maneira de validar esse pedido. Geralmente essa confirmação é feita com testes de aceitação.

Para criar boas estórias, ainda devemos focar em seis atributos: INVEST

Independent — Estórias devem ser independentes uma das outras. Dependências entre estórias geram problemas de planejamento e priorização, sem falar que dificultam bastante nas estimativas.

Negotiable — Estórias não são contratos. Como dito anteriomente, estórias são lembretes para funcionalidades discutidas (negociadas) entre o cliente e os desenvolvedores.

Valuable — Na mesma linha dos processos Ágeis, como dito no início deste post. Estórias devem agregar valor para o cliente.

Estimatable — Os desenvolvedores devem ser capazes de estimar o tamanhos das estórias. Geralmente estórias incompletas ou muito grandes (complexas) são difíceis de serem estimadas. Portanto invista em discussões e quebre em estórias menores quando necessário.

Small — “Tamanho é documento”. Essa regra é valida para a criação de boas estórias. Como dito anteriormente, estórias grandes dificultam as estimativas. Bem como estórias muito pequenas. Quebre ou agrupe dependendo do caso.

Testable — Estórias devem ser possíveis de serem testadas. Um teste que é executado com sucesso, prova que a estória foi desenvolvida com sucesso, atingindo as necessidades do cliente. Estórias que não podem ser testadas geralmente especificam requisitos não-funcionais do software, e não uma funcionalidade diretamente.

Além do 3C e INVEST, vejamos mais alguns pontos. Foque as estórias no “O que” e não no “Porque”. Estórias não devem apresentar termos técnicos e nem os mínimos detalhes das funcionalidades. Lembre-se, elas são apenas lembretes do que foi discutido anteriomente.

Quando possível aplique o “Quem”, “O que” e “Como”. Por exemplo: “O visitante pode se cadastrar no portal pelo formulário”, “O visitante confirma seu cadastro por email”, “O usuário é capaz de salvar seus favoritos”. Mas cuidado com o detalhismo!

Use e abuse de metáforas. Você vai perceber como fica fácil de explicar (ou entender) suas idéias quando você consegue comparar com algo concreto, do dia-a-dia das pessoas. Sem falar que assim você consegue definir um vocabulário comum com o cliente.

Incentive o cliente a escrever as estórias. Assim você acaba forçando-o a explicar com clareza as suas necessidades e muitas vezes ajuda também a esclarecer possíveis dúvidas.

Para finalizar, abaixo um trecho retirado de [1], que explica quase tudo em um único parágrafo:

The story is the unit of functionality in an XP project. We demonstate progress by delivering tested, integrated code that implements a story. A story should be understandable to customers and developers, testable, valuable to the customer, and small enough so that the programmers can build half a dozen in an iteration.

Referências/Leitura recomendada:

[1] Planning Extreme Programming. Kent Beck, Martin Fowler
[2] Essential XP: Card, Conversation, Confirmation. Ron Jeffries
[3] User Stories Applied: For Agile Software Development. Mike Cohn

Loading mentions Retweet

Olá. Bem, é como dizem por ai: “Life got real!”. Mas, enfim, estou aqui de volta.

Ainda tratando de sprints. Seguindo na mesma linha do post anterior. Acho que ficou claro que não é sensato abraçar cegamente o que é sugerido pela literatura, e sim saber reconhecer a essência do que é proposto e conseguir adaptar e aplicar à sua realidade. E além do mais, saber aplicar tais conceitos a cada caso é o tipo de tarefa que só se consegue realizar com a prática do dia-a-dia. E foi justamente com a prática do dia-a-dia que eu percebi alguns detalhes nos meus projetos. Seguinte:

• Fixe os dias da semana para marcar suas reuniões de planejamento e retrospectiva (sprint planning e review). Por exemplo, todos os plannings acontecem na segunda-feira e todos os reviews na sexta-feira. Dessa forma você acaba criando um vínculo e fica mais fácil de todos se organizarem e dificilmente alguém vai esquecer da reunião;
• Certifique-se que os dias dos sprints planning e reviews estão “funcionando” pra você. O que eu quero dizer com funcionando, é se estão sendo reuniões produtivas. Nos meus primeiros projetos eu reservava a segunda-feira para o planejamento e a sexta-feira (da outra semana) para as retrospectivas. Tiro no pé! Ninguém, nem a equipe, nem o Product Owner estavam motivados para começar a semana com uma reunião. Estas sempre começavam atrasadas e era nítido que o pessoal ainda estava “regulando a marcha lenta”. Muito menos encarar uma retrospectiva de 4 horas em plena sexta-feira! Bastou trocar os dias e a coisa começou a funcionar;
• Lançar novas versões do produto na sexta-feira pode não ser uma boa idéia. Ninguém quer voltar para casa, muito menos correr o risco de perder o final de semana com aquela preocupação de que algo pode dar errado. Uma coisa que funcionou comigo foi definir um deadline na quinta-feira. E deixar a sexta-feira apenas para algumas tarefas administrativas e reviews;
• Crie tags no seu sistema de controle versão para cada sprint. Isso se você estiver utilizando controle de versão, pois se não estiver, você definitivamente deveria!
• Evite entregar tudo o que foi produzido apenas ao final da iteração. A medida que as tarefas forem sendo finalizadas, disponibilize para o cliente. Agilidade está diretamente relacionada a feedback. Se você deixar para entregar tudo que foi feito ao final do sprint, você só tera o feedback do cliente no próximo sprint, o que pode acabar atrasando as coisas, haja vista já existem tarefas definidas para esse (próximo) sprint. Esse assunto também foi abordado neste excelente artigo do Alisson Vale, inclusive batizado com um nome bastente adequado: “Síndrome da Iteração Inacabada”.

Bem, por hora é isso. Como cada empresa ou projeto, cada situação tem suas peculiaridades, eu gostaria que vocês compartilhassem suas experiências com relação a esse assunto. Os comentário estão abertos. Caso você não tenha passado por isso ainda, espero que esses tópicos possam te poupar algum tempo.

Sem mais.

Loading mentions Retweet

Antes que comecem as críticas, quero deixar claro que o título escolhido foi proposital. Não por provocação, pelo contrário, mas para tentar abrir os olhos de quem ainda acredita que seguir à risca a bibliografia é sempre a melhor solução. E acaba ferindo (mesmo que cegamente) um dos princípios mais importantes da Agilidade: Adaptação.

Não me recordo o número, mas posso afirmar que não foram poucas as vezes que ouvi ou li alguém questionando sobre o tamanho dos sprints ou iterações. Se eram obrigados a trabalhar com 30 dias, ou se optando por um valor diferente estariam certos ou errados.

Para quem esperava uma solução simples e objetiva, sinto muito. A verdade é que não existe bala de prata, nem certo ou errado. Não existe um tamanho ideal que se aplique a todas as ocasiões. Cada caso é um caso. Mesmo em uma equipe que não sofre alterações de pessoal, um tamanho adequado para um projeto, pode não ter a mesma eficiência em outro.

O Scrum sugere sprints com 30 dias (um mês) de duração (“Do I need to stick to a month time frame?” em Scrum FAQ, ou na versão traduzida). O XP sugere ciclos semanais. Durante meu treinamento Certified ScrumMaster foi proposto sprints de 28 dias, pois facilita visualização em termos de semanas. Além desses, eu já tive oportunidade de trabalhar com sprints de 1 e 2 semanas. O que eu sugiro pra você: Experimente! Só assim você vai ser capaz de dizer o que é apropriado para cada ocasião. No mais, eu só posso citar alguns pontos que devem ser levados em consideração para a sua decisão:

• Escolha uma duração a qual seja agradável trabalhar, tal que a equipe consiga manter um ritmo sustentável. Sprints muito longos podem levar à procrastinação (Síndrome do Estudante). Já sprints muito curtos conseguem ser bem estressantes quando algum imprevisto acontece;
• Requisitos mudam com freqüência (i.e., o cliente muda os planos constantemente ou é incapaz de especificar com clareza o que deseja). Se for pra algo dar errado, que seja agora e não daqui 15 dias. Ou seja, quanto antes você perceber que esta no caminho errado, o esforço para voltar atrás é menor. E você só conhece esse caminho a partir do feedback, o que (geralmente) acontece mais frequentemente em sprints curtos;
• Semelhante as incertezas do cliente, deve-se ponderar as incertezas da equipe. Pois esta pode ser incapaz de dizer o quanto consegue trabalhar por iteração ou desconhece de aspectos técnicos do projeto;
• Da mesma forma que os requisitos podem mudar, o mesmo pode acontecer com suas prioridades. O seu tempo de resposta para eventuais mudanças esta intimamente ligado à duração dos sprints;
• Preparação (overhead) para os sprints. Suponha que antes de cada sprint todo o sistema precise passar por uma bateria de testes, ou que todo desenvolvedor deva reinstalar seu sistema e ambiente de desenvolvimento por medidas de segurança da empresa. Sem dúvida sprints curtos não são a melhor escolha nesse caso. O ideal seria reduzir ou eliminar estes impedimentos, mas nem sempre isso é possível.

Bem, se você tinha dúvidas com relação o tamanho dos seus sprints, espero esses tópicos sirvam como ponto de partida para uma possível mudança. Mas não esqueça que até mesmo as mudanças visando melhorias têm seus efeitos colaterais. Portanto, uma vez definida uma duração apropriada para seus sprints, respeite esse valor, pois só assim você será capaz de manter um ritmo (velocidade) de trabalho.

Inspect and Adapt!

Loading mentions Retweet