A frase que ficou foi: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Ou seja, não existe nada melhor do que pessoas trabalhando juntas, conversando, cooperando.

A palestra era para aprendizes dos métodos ágeis. Nesse sentido a palestra foi perfeita. Ele expôs de maneira bem clara e detalhada as principais ideias e práticas do desenvolvimento ágil. Era um workshop e a atividade desenvolvida foi o desenvolvimento de um produto ( que envolvesse um software claro! ). Vou descrevendo a dinâmica tentando explicar pra vocês alguns conceitos, beleza!?

Dinâmica feita com os participantes: foram formados grupos de até nove pessoas, desses pelo menos um precisava ter algum  conhecimento em desenvolvimento e outro conhecimentos em testes. O grupo deveria eleger um Scrum Manager e desenvolver um produto do zero. Algo que envolva um software e  sem qualquer relação com o que eles trabalham. A primeira tarefa era escrever as User Stories. Essas histórias são sentenças de até 15 palavras focadas no consumidor, numa linguagem simples que os usuários, desenvolvedores, gerentes, enfim  qualquer um possa entender. Aqui queremos o  “what” e não o “how”.

Outra observação feita aqui foi que o MARKET/CUSTOMER ( mercado/consumidor) e YOUR OFFER { BUSINESS PEOPLE AND DEVELOPERS)/ seu produto ( gerentes e desenvolvedores ) devem trabalhar juntos. Conversar frequentemente para que qualquer dúvida ou mal entendido seja sanado o mais rápido possível. Para começar a criar essas histórias  uma boa alternativa é realizar um braimstorm. O formato geral dessas histórias é: As a <user role> I want <perform some action> so that < I achieve some goal> / Como um <papel do usuário> Eu quero <desejo do usuário que será sanado> então <objetivo alcançado>

Para criar essas histórias devemos pensar em INVEST. Ele será nosso guia. Mas o que é isso? Vou explicar…INVEST é um acrônimo para as necessidades dessas historias.

Elas devem ser:

Independent/Independentes;

Negotiable/Negociáveis, essas histórias são o ínicio da conversa e não uma definição;

Valuable, ou seja, devem ter algum valor para o usuário;

Estimable, ou seja, ninguém vai precisar pesquisar para entender o que ela signfica;

Small/Sucintas;

Testable/Testáveis, ou seja, deve ser possível implementar e testar cada uma delas.

Depois de já terem tentado criar as histórias sem saber disso, eles criaram mais, agora, pensando nesses conceitos.

Com todas as histórias escritas e “corretas”, eles as organizaram numa escala crescente de Most Value – > Least Value, ou seja, das de maior valor  para as de menor. O objetivo aqui era criar uma ferramenta de negociação, uma maneira de visualizar as ideias, por exemplo, se temos uma nova ideia basta ver onde o  cartão com a nova ideia entra na escala feita e rapidamente conseguimos integrar essa ideia nova ao projeto.

Tentando explicar o conceit de backlog o seguinte exercício foi proposto:TURN YOUR STORIES INTO BACKLOG; NO TIES OR BUCKETS; SINGLE FILE BACKLOG ONLY; TOP TEN USER STORIES.

Traduzindo…

Coloque suas histórias, independentes, no backlog. Escolher as 10 primeiras e montar o release. Com essa configuração em mãos, a abordagem é onde e quando investir seu tempo e dinheiro. Quais devem ser as primeiras histórias? Por onde começar? Por exemplo, não devemos só olhar qual tem o melhor custo beneficio ( analisar somente valor x custo), precisamos ver quando terminaremos por exemplo,  pois pode demorar muito para um primeiro retorno e isso acabar inviabilizando o projeto ou apenas atrapalhar o projeto, pois se planejar para longos períodos de tempo é bem complicado. Muita coisa pode mudar, ainda mais no mundo da tecnologia.

Por isso a tarefa de dividir as histórias has men ores unidades com album valor possíveis e depois agrupá-las em sprints é tão complicada e tão necessária. Uma frase que ilustra bem isso e que merece destaque é:  “Simplicity –the art of maximizing the amount of work not done — is essential”

Esse foi um dos exercícios para a audiência…eles tiveram que identificar duas histórias que poderiam ser divididas em duas que ainda tinham valor para o usuário. Remover a ideia anterior e colocar no lugar as duas outras que ela criou. No final serão 12 histórias, certo!? Tiveram que decidir qual é a mais simples de fazer, pensando tanto em implementação quanto no teste. Assim escolhemos a primeira história e desenvolveremos o resto do exercício em cima dela. O próximo exercício foi o: Planning Poker, que era mais ou menos assim…o desenvolvedor e o tester pegam um conjunto de cartões. Estimam o tempo que gastarão, considerando o custo incremental e não dependente. Com as estimativas feitas em mãos cada um dos membros faz a sua estimativa, quem fizer a estimativa mais baixa e a mais alta explicam o porquê da escolha. Quando houver consenso sobre as estimativas  esta é adotada.

O próximo exercício fazia referência ao sistema de interação. As conhecidas INTERATIONS, tem por regra sempre produzir algo que funcione, em todas elas, senão não temos uma interação. Devem ser curtas. Períodos estabelecidos de tempo, normalmente variam de 1-4 semanas. Chamamos esse período de tempo de “sprint”. Como exercício eles tiveram que fazer a divisão de sua histórias. Baseados na velocidade que eles acreditavam que iriam desenvolver, assim criaram uma release com 2 sprints.

O próximo exercício é uma simulação de implementação bem bacana. Tinham adesivos e post-its. O “usuário” colocava duas bolinhas num post-it que representa cada uma das historias de maneiras diferentes, as bolinhas tem cores diferentes, uma é para representar o teste e a outra a implementação que o usuário espera. Essa é uma tentativa de criar os desejos do cliente. Teremos uma replicação dos padrões aleatórios criados  para representar o work in progress. Depois só um dos cartões novos vai se tornar o produto de fato, quem vai escolher qual deles será é o dono do produto. Exatamente como  ocorre na “vida real”. Depois, para mostrar como fazer uma retrospectiva ( uma das praticas bem comuns no mundo ágil. A descrição do palestrante para isso foi: “At regular interval, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”/ Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, em seguida, sintoniza e ajusta seu comportamento para ficar de acordo com o que propuseram. Para fazer isso, criamos 3 colunas: Good/Bom, improve/Melhorar,  idea/ideias. Todos os envolvidos no projeto criam cartões com sentenças para ir para cada uma das colunas. Fazem uma discussão e produzem cartões de ação.

A palestra acabou com com a visão do palestrante de gerenciamento de projeto. Aí vai ela:

“Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done. The best architectures, requirements, and designs emerge from this self-organizing teams”/ “Construir projetos em torno de indivíduos motivados, dar-lhes o ambiente adequado, dar o apoio que precisam, e confiar neles para fazer o trabalho. As melhores arquiteturas, requisitos e projetos emergem dessas equipes auto-organizáveis​​”

É isso…desculpe a demora pra postar, é que o ritmo aqui na conferência esta frenético. Mas fiquem tranquilos que aos pouquinhos eu vou postando e vocês vão ficar sabendo de tudo.

O contato do palestrante está aí:

blog: damonpoole.blogspot.com

Ele tem um livro free na internet….é só procurar e baixar: Do it yourself agile.

beeeeeijos diretamente do estado da estrela única!