AGILE2012 – Times ágeis!

Bom, aí vai um post que eu gastei um tempinho tentando simplificar ao máximo a ideia geral de duas palestras muuuuito bacanas de duas pessoas incríveis sobre times ágeis, que eu vi lá na conferência. Uma foi Influencing teams with psychology (  Influenciando times com psicologia) do Charles Suscheck e a outra Self-Organizing Teams ( Times que se auto-organizam ) da Esther Derby.

Olha eles aí…

Charles Suscheck

Esther Derby

OBS 1.: A segunda palestrante Esther Derby é uma Mulher da Computação para se orgulhar. Se quiser saber um pouquinho mais está AQUI.

 

Time montando um Kanban

 Top 10 – Como fazer uma equipe ágil bacana! : )

1. Capacitá-los – Incentivar seu time a estudar e se reciclar sempre. E além disso reconhecer quando conhecimentos adicionais são apresentados, isso motiva a equipe a querer sempre mais.

2. Ouça-os – A equipe está mais perto dos detalhes técnicos do projeto e também em melhor posição para determinar as soluções mais eficazes para problema. Além disso, incentivar a equipe a resolver os problemas tem duas vantagens principais: demonstra que a visão deles é valorizada, tanto quanto a produção, o que faz as pessoas se sentirem mais envolvidas; e as soluções sugeridas pela equipe são mais propensas a serem abraçadas e executadas com entusiasmo, por um motivo óbvio. É melhor ter uma solução 70% ótima executada com entusiasmo 80% do que uma solução 100%, ideal executada com entusiasmo 40%.

3. CONFIAR neles para fazer o trabalho – gestão e produção macro minam a confiança e sufocam os sentimentos de criatividade e capacidade que são justamente duas coisas que tentamos promover a todo custo.

4. Monitorar de perto e não intervir – decidir quando parar ou quando dar um passo atrás é missão do time. Muitas variações na velocidade da equipe e disputas de projetos podem ser bastante ruins para o desenvolvimento das atividades do time. Lembrando que as questões de origem externa ao projeto pedem a intervenção imediata do líder da equipe, por exemplo. Aliás é por isso que essa figura existe.

5. Criar um espaço de trabalho produtivo para eles – equipes ágeis necessitam de áreas com espaço aberto para facilitar a comunicação, espaço com pelo menos uma parede para cartas e cartões. Além disso é necessário prover ferramentas para isso, papeis, post-its, canetas ou pelo menos algum software de gerenciamento ágil de projetos.

6. Fornecer suporte para eles – uma parte importante de métodos ágeis é fazer com que as pessoas tenham o que precisam para ser produtivo e bem sucedido. Além do que eu já citei acima, que tem caráter prático, este abrange não só os computadores e softwares, mas também treinamento e orientação. Quando uma área problemática é identificada, discuti-la com os membros das equipes envolvidas, reconhecê-la como área de melhoria e em seguida, fornecer orientação e treinamento para cultivá-las. O projeto precisa de produtividade e muitas vezes a melhor maneira de conseguir isso é fazer crescer a capacidade de produção dos membros da equipe. Ele ajuda as pessoas a se sentirem valorizadas e melhora a retenção de funcionários também.

7. Estimular a reflexão e adaptação – Nenhum processo já é concebido de forma otimizada de primeira e nenhum plano sobrevive ao contato com o “inimigo”. Acelerar as melhorias do projeto pode ser feito por meio de simples comentários. As revisões de código e retrospectivas são ótimas maneiras de encontrar áreas para melhoria. Certifique-se de implementar as sugestões e volte para garantir que ele vão realmente entregar os benefícios esperados. Além disso, pergunte abertamente para a equipe coisas como “Onde estamos vulneráveis?”, “Onde é que mais precisamos melhorar?”

8. Recompensar e reconhecer-lhes – as equipes precisam recompensas regulares e de reconhecimento para manter o entusiasmo e combustível. Esperar o projeto ser entregue para comemorar é muito pouco, muito tarde e pode simplesmente nunca acontecer se o time ficar desmotivado ou membros abandonarem o projeto devido a falta de reconhecimento. Encontre freqüentes ( mas sempre reais) motivos para celebrar com a equipe. Reconhecer as conquistas individuais com um sincero “obrigado” já faz toda diferença, pode apostar.

9. Comunicação – compartilhar as notícias do projeto, boas e más, deve ser uma constante com a equipe, deve ser feito de maneira livre. Comunique a visão do projeto e dos sub-componentes para garantir que as pessoas tenham um entendimento comum dos objetivos finais que todos estão visando atingir.

10. Alinhar os objetivos e promover pessoas – Descubra em que as pessoas querem trabalhar e, em seguida, sempre que possível, encontrar formas de integrar este trabalho no projeto. Alinhar seus objetivos pessoais com os objetivos do projeto é uma ótima maneira de aumentar o compromisso e a produtividade. Finalmente, ajudar o progresso de pessoas em suas carreiras e promover os merecedores está acima e além de seu controle, senão acontecer com você, na sua empresa, no seu projeto, você simplesmente vai perder um bom recurso para outro.

 

É isso! Espero que tenham gostado!

Beijos!

AGILE2012: Hands on Agile Immersion – Damon Poole

Uma da sala de palestra

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!?

Blacão de Registro

Mais uma da sala de Palestra

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!

AGILE2012 – Bag Packing!

Sabe quando você vai para uma conferência ou um evento qualquer e te dão uma bolsinha cheia de panfletos, uns bacanas e outros desprezíveis??? Então…a partir de agora vou dar valor a cada um desses panfletos. E sabe porquê?! Alguém colocou tudo aquilo lá! rs

Ontem meu dia foi assim: pega folheto – guarda folheto – dobra camiseta – carrega caixa – come um cookie – pega panfleto….MAAAAAAS mesmo assim foi bem bacana, conheci um monte gente legal.

Aí vão umas fotinhos de ontem só pra vocês matarem a curiosidade do local e de como tudo foi montado para a conferência…mais tarde, no final do dia vou tentar postar sobre as palestras de hoje.

Reparem nos lustres! rs

Fizemos uma linha de montagem
voluntários

close na linha de montagem!

camisetas da conferêrencia.

nossos uniformes.

Só pra deixar vocês beeem curiosos vou adiantar que a  conferência está lotada e com gente do mundo todo. Temos uma maioria masculina, mas nada muuuito discrepante! rs.

beijos! Até mais tarde….