Transferir como PDF, PPTX
Carregado porRoberto Brasileiro
[AgileTalk] Do Caos ao Resultado
Roberto Brasileiro é um especialista em agilidade e ScrumMaster há mais de 10 anos. Ele fundou a Agilhes, uma empresa de consultoria e treinamentos em métodos ágeis. A Agilhes oferece serviços de adoção de práticas ágeis e também treinamentos sobre agilidade.
![[AgileTalk BH]Agilidade na Atualidade](https://cdn.slidesharecdn.com/ss_thumbnails/agiletalkagilidadenaatualidade-120110052422-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
[AgileTalk] Do Caos ao Resultado
- 2. Prazer... Roberto Brasileiro, CSM Atua com TI desde de 1999, sempre com desenvolvimento de software. Desde de 2008 é entusiasta da agilidade. Atualmente é ScrumMaster na Ci&T e atua como Agile Coach e Instrutor pela Agilhes, empresa que fundou em 2011. @_rbrasileiro roberto@agilhes.com Consultoria na Adoção de Metodos Ágeis Consultoria e Treinamentos, visite nosso site. www.agilhes.com www.facebook.com/agilhes info@agilhes.com
- 3. Agilidade está crescendo no Brasil! • Empresas estão mais receptivas • Existem mais pessoas interessadas e envolvidas • Mercado profissional já existe • AgileTalk cresceu 300% em 01 ano!
- 5. • DoS nãoestá ligada a entrega do projeto e sim a qualidade do seu processo. • DoS determina qual caminho a seguir. • Não devemos resolver problemas que não temos. • Os problemas/desafios são consequência do caminho que seguimos.
- 6. Vilões da Agilidade! Cultura não é next, next, finish! Gestores devem se reinvetar Planejamento realizado e, lógico, não executado. Cliente não tem nem idéia do que é agilidade!
- 7.
- 8. Principais Sintomas doCaos #01 - Qualidade é #02 - Produtividade é “excelente”, só que o “boa”, só não é melhor cliente homologa porque não temos os cenários não previstos! requisitos Ready. #03 - Esse cliente é complexo! Não #04 - Seguimos o entende que ele tem Scrum, mas não temos que mudar. Demo Review. Esconder os problemas é o maior sintoma do Caos. Temos que ser cuidadosos, para não entrar em uma zona de conforto.
- 9. Combatendo o Caos!
- 10. FALHAR NO PLANO É PLANEJAR A FALHA
- 11. Planejando a Falha •Planejamento de entregas sem conseso e/ou participação do time. – Eu estimo e você executa. • Banco de Horas cheios! Hora Extra é normal. – Planejamento já conta com HE, FDS, Natal, Nascimento do Filho e por ai vai... • Quanto mais pessoas, mais rápido a entrega. – Quanto mais pessoa no time, mais problema você vai ter! • Data acordada é data não cumprida. – Vamos testar menos! Assim a gente entrega! – Riscos/Blocks não estão claros.
- 12. Consequências... • Pessoas – Atrito e desgaste entre time e gestores. – Provavelmente o GP se tornará o inimigo número 01, de todos! – Desmotivação das pessoas. – Sentimento de incapacidade. – Todo problema vai se tornar grande! • Custo/Margem – HE vai impactar os custos/margem do projeto. • Time – Novas pessoas, significam menor produtividade (Apoio) • Prazos – Nunca serão cumpridos. – Falta de visibilidade dos riscos do projeto.
- 13. Evitando problemas noplano • Planejamento colaborativo – Envolver o time ou parte do time é fundamental. – Deixar transparente para o time qual o objetivo de cada entrega e desejos do cliente. – Comprometimento nasce no planejamento. – Entender todos os lados, Time, Gestores e Cliente. • Definitivamente, evite hora extra – HE serve para correr atras do prejuízo e não para antecipar datas. • Planejar com o que temos, evitar mudanças no time. • Prazos possíveis! – Descobrir a capacidade de produção do time. – Planejar sempre com a capacidade do time. – Não assumir riscos sozinho. • Deixe o cliente ciente de tudo! – Mostre os riscos, capacidade de produção e tudo que puder.
- 14.
- 15. • User StoryReady? Vai direto pra Planning. – Falta o Pré-Game/Grooming/Entendimento/Refinamento/Qualquer nome que quiser... • Planning falha = Review furado! – Time sem planejamento “tático” do Sprint. • Daily técnica e longa, até demais! – Ninguém nem presta a atenção. • Demo Review?!? • Restrospectiva, sem plano de ação? – Realiza a retro e não gera insumos de melhoria. – Lavagem de roupa-suja e mais nada! – Caças as bruxas! • Done? Que isso?
- 16. • Construção/Qualidade – Critérios de aceites são rasos, vai gerar defeito. – Vários conceitos de Done. • Produtividade – Várias atividades não planejadas aparecem dentro do Sprint. – Blocks! • Dia-a-dia do time – Não existe alinhamento nas atividades. – Não atua na prioridade. • Melhoria Continua – Não existe! Sempre os mesmo problemas e culpados. – Não sobra tempo para melhorar.
- 17. • Se planejarpara a Planning (validar os requisitos). • Estruturar com o time a Planning dos sonhos!! – Conceito de Ready • Metas diárias, ajudam no alinhamento. – Metas ajudam a atuar na prioridade e dão visibilidade de progresso. • Conceito de Done = Chave do Sucesso! • Melhoria Continua – Gerar ações na retro com data e owner! • Gestão Visual – Exponha os problemas, deixe tudo a mostra!
- 19. • Não existetime. – Não existe dialogo sobre o projeto. • Acomodação é geral. – Se não entregou hoje, entrega amanhã. • Despersão é a principal característica do time. • Auto-Desorganização – Cada um por si! • A pessoa mais comprometida é a “chata” do projeto. • Todos se acham os melhores dos melhores! – Não tenho mais nada para aprender. – Esse projeto é fácil.
- 20. • Entrega/Prazo – Time não se incomoda com os problemas. – Não se importa se não cumpriu objetivos/metas. – Erra em todas as estimativas. – Não sinaliza os blocks que encontra. • Produtividade – Desviar as atividades é normal. Estimei 2 horas e faço em 20 horas. • Qualidade – A velha máxima de: Na minha máquina funciona! • Não vê desafios no projeto – Acomodado com a situação, não consegue mais pensar “fora da caixa”
- 21. • Trazer arealidade a todos. – Traçar ações de melhoria. – Envolver o time em tudo! (Comprometimento nasce aqui) • Ajustar e descobrir o fluxo de trabalho do time. • Conceito de Ready e Done • Testes, Testes e mais Testes! – Ensinar o time a testar. – Criar metricas de qualidade. • Desafiar o time – Integração Continua, Builds, Teste Automatizados e por ai vai...
- 22.
- 23. • Cliente écontra o agile! • Só quer saber de quando e quanto. • Não entende meus problemas e não me ajuda a resolver. • Sempre os mesmos blocks. • Ele não entende, que tem que mudar.
- 24. Insatisfação e desgastedos dois lados!
- 25. Seu cliente nãovai mudar por sua causa. Mas, ele pode aprender com você.
- 26. • Demonstre osimpactos de forma clara – Blocks e Atividades não planejadas. • Compartilhe o planejamento com ele, deixe ele planejar também. • Mostre os problemas dele. • Proponha soluções para os problemas dele. • Coloque ele dentro do Taxi!
- 27.
- 28. Scrum Master, doente • Acomodado com a situação. • Resistênte/Cansado em buscar melhorias. • Tem medo de mostrar a realidade. • Os problemas não o incomodam mais. • Se sente incapaz. • Não acredita no Scrum/Agile! • Influência negativa ao time.
- 29. Consequências... • Entrega/Prazos – Não entrega ou “entrega” tudo a 90%. – Datas sempre mudam ao 48 do segundo tempo(Sem gestão de Blocks). – Cliente insatisfeito e sem confiança. – Não se sabe o que tem q entregar. • Qualidade – Poucos defeitos internos e muitos externos. – Engenharia de Software fraca. • Custo • Time perdido e desmotivado • Pra que SM? • Não existe Agile! • Se torna um influência negativa ao time.
- 30. Curando o ScrumMaster! • Entender os problemas do SM. – Entender a causa raiz e buscar resolver em conjunto. • Demonstre as situações que precisam ser melhoradas. • Alinhar expectativas – Feedback deve acontecer on-line – Acompanhe os passos, fique sempre por perto. • Problemas devem ser priorizados • Coloque SM para conversar com SM. – Trocar experiências e práticas é uma excelente ferramenta. • Faça o SM se expor, se sentir dono da situação novamente. • Envolva na resolução de problemas do Projeto. – Estreite a relação entre Gestores, SM e PO.
- 31. Cuidado! Conteúdo apresentado, nãoé receita pronta.
- 32. Conclusão Não se acomodeaos problemas.
- 33. Obrigado! Visite nossosite www.agilhes.com info@agilhes.com