Na noite de 5ªfeira fomos todos para um restaurante a beira do lago, onde creio que mais de 100 pessoas confraternizaram e discutiram agilidade e viés ágeis para a política, graduação e mestrado, falamos de futebol e muito mais, nós da RBS estávamos junto com a galera da DBServer e Ionatec.
Alexandre Gomes- KeyNote – 3º Dia – 29/06/2013
“Alê Gomes acredita no software como instrumento de transformação social. Já foi servidor público, trabalhou em multinacionais e leva hoje uma vida de equilíbrios administrando seu próprio negócio. Em Brasília, junto com sua equipe, foi pioneiro na prestação de serviços profissionais em Software Livre e Métodos Ágeis para o Governo Federal.”
O Alexandre fez uma palestra inflama e cheia de nacionalismo, falando sobre democracia participativa, representatividade, tecendo ilações entre princípios ágeis e o momento socio-político-econômico do Brasil, o quanto o Agile Brazil 2013 poderá ser um divisor de águas, posto que tínhamos um grande números de profissionais do estado e que “um deputado visitou o evento no dia anterior”.
Levantou uma reflexão sobre a Internet ser a nova Ágora, um espaço público para debates políticos e sociais, onde as pessoas podem manifestar-se e debater questões de interesse de todos, falou das manifestações e o quanto há para mudar, mas que o momento é um primeiro passo … chegou até a falar em uma revolução a caminho.
Ari Amaral – lightning talk sobre agilidade na educação
Ele é professor e mostrou que é possível um novo paradigma mais colaborativo, vendo o aluno como um potencial a ser desenvolvido e não uma estante a ser preenchida, mostrou um case de um site de gestão de turmas (achei semelhante ao Moodle, mas não perguntei se esta seria a base) chamado SOLAR.
- “Ensinar a aprender é aprender a ensinar!”
Reportou técnicas ágeis participativas e auto-organizadas em sala de aula com agenda e conteúdo debatidos e organizados pelos próprios alunos, uso de planejamento, acompanhamento, entrega contínua e retrospectivas a cada ciclo ou trabalho e algo muito peculiar, os próprios alunos se avaliavam, algo tipo uma avaliação 360°.
Samuel Crescêncio – OnCast – 7 disfunções do Scrum
Foi impressionante, pois em uma sala para 150 pessoas acho que tínhamos mais de 200, ocupando todas as cadeiras, de pé em todo o perímetro e sentadas no corredor central, não sobrou nenhum espaço livre.
Introduziu a palestra falando sobre a carência de uma orientação no aspecto de arquitetura e engenharia e esta foi a deixa para reapresentar a Pirâmide Lean, uma racionalização sobre a necessidade de manter no radar um equilíbrio entre princípios, método e engenharia, lembrando que esta última é a que exige mais esforço por tratar-se da base da pirâmide.
1ª. Engenharia – Retrospectiva, que a seu ver todo o time deve estar presente, apesar de o Scrum Guide apontar a ausência do Product Owner, além de que muitas empresas tratam retrospectivas como um feedback de pontos positivos e negativos, focando em problemas mais que em soluções;
2ª. Daily – Muitos times ágeis tem reuniões diárias demoradas, improdutivas, demonstrando falta de interesse e de engajamento, muitos no uso de celulares, apenas de corpo presente, sugerindo que isto tudo são indicativos de que algo vai mal e que deve ser trabalhado e melhorado;
3ª. Timeboxes – Há em muito times uma total displicência e descaso em relação as timeboxes, quer pela sua natureza (falta de entendimento), cadência (atrasos, cancelamentos, esticadinhas, gambiarras, …) e chamou a tudo isto de puro desperdício, relembrando os conceitos de desperdícios que tanto o Lean trabalha (muri – mura – muda);
4ª. Product Owner despreparado – No Lean há o conceito de Product Champion, pois o profissional que atua neste papel possui conhecimento técnico e de negócio, pois ele deve ter habilidades próprias para entender o negócio e o produto, dada a relevância disto para a abstração, detalhamento e priorização das histórias.
5ª. Sprint Planning – O Scrum não recomenda, mas acha produtivo sempre que necessário realizar uma segunda reunião de planning, que ele chamou de Sprint Planning 2, onde é possível fechar algumas pontas que no primeiro careceram de análise ou mesmo pesquisa, permitindo a equipe revisar e atualizar suas estimativas de forma mais assertiva.
6ª. Scrum Master compartilhado – Um scrum master que seja desenvolvedor, analista, arquiteto ou outra função que não lhe permita dedicar tempo ao trabalho de Scrum Master ou gere conflitos de interesse é altamente prejudicial ao sucesso a atuação e desempenho esperado dele;
7ª. BurnDown NÃO desce – Há uma infinidade de possibilidades, todas elas muito danosas para o time e negócio, granularidade inadequada das User Stories, falta de confiança e transparência entre os integrantes e negócio, desconhecimento e necessidade de determinar foco e convergência, talvez com a adoção de WIP (work in progress) para as colunas do quadro de tarefas, etc.
Raphael e Victor da Lambda 3 – Experiência, Erros e Acertos
Eu classificaria esta palestra de “corajosa”, pois o pessoal da Lambda3 (assim como o fizera o Samuel falando sobre o projeto do OnTrack) discorreu sobre erros e acertos de vários serviços prestados a seus clientes a partir das experiências de uma de suas equipes, citando casos reais e abaixo listo os aprendizados debatidos:
1. De nada adianta ter uma equipe muito boa tecnicamente e um cliente presente, gerando muita entregas e um “ótimo” produto que acabou não vendendo nada … só excelência técnica não garante nada!
2. Muito cuidado com a complexidade, pois eles criaram um produto em que tudo o que foi pedido pelo cliente foi desenvolvido e que no final o próprio cliente não usava porque mais parecia um grande canivete suiço cheio de funcionalidades e campos, complexo demais para qualquer um usar;
3. Automação de passos que mascaravam outros problemas, em especial, informatização não resolve problemas existentes com pessoas ou ausência delas, há momentos que é necessário um Stop the Line e mergulhar de fato no negócio, para isto citaram a técnica “Business Analisys Role”;
4. Não podemos esquecer jamais de manter a análise de releases, devemos trabalhar no Sprint, mas é papel do PO manter os olhos no horizonte e manter a cada novo Sprint todo o time e interessados atentos não só ao que já fizemos mas para onde estamos indo;
5. Não basta ter alguém que o contrate e assine o cheque, é preciso saber quem são todos os interessados, citaram um caso em que o principal Sponsor foi demitido e que o projeto ficou órfão porque os seus superiores e pares não sabiam ou não concordavam com ele;
6. Comunicação através de reports de status ao nível executivo da organização é importante, ser ágil não quer dizer que é vergonha fazer reports periódicos a interessados indiretos mas relevantes ou a diretoria executiva.
7. Todo projeto tende a se transformar em um WaterFall e na medida em que os próximos passos ganham contornos de previsibilidade, é natural as pessoas relaxarem e entrarem em suas zonas de conforto;
8. Agilidade tem muito de militância, não da para relaxar, a difusão de conhecimento, relembrar princípios, utilizar-se de dinâmicas, tudo isto potencializa a continuidade e melhoria contínua;
9. Muito cuidado com o MVP, pois alguns clientes e até mesmo equipe podem acabar vendo ele como um contrato de escopo fechado e imutável após definido;
10. É fundamental que NÃO tentemos resolver todos os problemas que ainda NÃO existem e que “todos nós precisamos mais de análise de negócios que de um analista de negócios!”
“The Agile Inception Deck:
10 reflections you’d be crazy not to ask before starting”
Conversando com o Samuel pouco antes dele iniciar a sua palestra, ele me recomendou dar uma olhada nesta técnica de levantamento e registro do que exatamente o cliente quer, além dele outros palestrantes também citaram o Inception Deck e então fui atrás de um post que o explicasse direitinho, clique no link abaixo ou sobre a figura para entender o que é:
http://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/
Adivinha qual a empresa por trás deste post ? É óbvio, a ThoughtWorks! A técnica consiste em ter-se um pack de perguntas ou reflexões que deixem claro o que se quer e como se quer:
1. Why Are We Here?
2. Create an Elevator Pitch
3. Design a Product Box
4. Create a NOT List
5. Meet Your Neighbors
6. Show the Solution
7. Ask What Keeps Us Up at Night
8. Size It Up
9. Be Clear on What’s Going to Give
10. Show What It’s Going to Take
Jorge Horácio "Kotick" Audy 