Agora que você já leu o livro até aqui, estas referências servirão, também, como um guia de revisão do que você aprendeu – junto ao incentivo para você seguir adiante. No audiolivro The genius formula, os autores Tony Buzan e Raymond Keene comentam a maneira como aprendemos a ler – sempre de forma linear, “narrando” com uma voz silenciosa, dentro de nossa cabeça, em vez de permitirmos que nosso cérebro capte as informações na velocidade em que é, de fato, capaz. Muitos de nós precisamos reaprender a ler, incorporando ao ato da leitura a retenção da informação. Em parte, isso se dá com a revisão daquilo que lemos e, especialmente, com a prática daquilo que foi aprendido.
E aí está um exemplo de referência! Os ensinamentos de Tony Buzan sobre as formas pelas quais aprendemos e como o nosso cérebro funciona têm tudo a ver com métodos ágeis. Olhe de novo a figura 4.2 apresentada no Capítulo 4, “Visão geral do Scrum”. Ela é, de fato, um mapa mental do processo. E mapas mentais foram, inicialmente, estruturados pelo Tony Buzan como uma forma de representar, em um papel (ou em uma representação na tela de um computador) a forma radiante, não linear, por meio da qual pensamos e criamos. Ainda no mesmo audiolivro, Buzan e Keene declaram que a criatividade é o resultado da energia aplicada à memória. Ou seja, quanto mais informações nós somos capazes de reter, mais alimentos estamos dando à nossa criatividade.
Na sua releitura ou revisão deste livro, sempre que você encontrar algo no qual queira se aprofundar, sugiro que você faça o seguinte exercício:
Acesse o Google e digite, na caixa de busca, o termo de pesquisa, mas limitando-o inicialmente a outros textos que eu possa ter escrito sobre o assunto. Por exemplo, digite o seguinte na caixa de busca (exatamente assim):
“Tony Buzan” site:brodtec.com OR site:cesar.brod.com.br OR site:dicas-l.com.br.
O termo entre aspas “Tony Buzan” instrui ao Google que faça uma busca exata (ou seja, ele não trará resultados que contenham só Tony ou só Buzan) e a chave site faz com que a busca seja feita apenas no domínio informado (como site:brodtec.com). O operador OR (em português, ou) pede ao Google que busque em brodtec.com ou cesar.brod.com.br ou dicas-l.com.br.
Claro que você não precisa limitar sua busca apenas ao que eu escrevi. De fato, se você fez essa pesquisa, já encontrou textos que não foram escritos por mim. No entanto, como você está lendo este livro, um caminho natural para o seu aprofundamento inicial é ler outras coisas que já postei na web sobre o assunto, como se o livro se expandisse além do exemplar físico que você tem em mãos. Sinta-se, porém, livre para modificar os termos e as chaves de busca como desejar. Antes, porém, experimente esta outra busca:
“Mapas mentais” site:brodtec.com OR site: cesar.brod.com.br OR site:dicas-l.com.br
Gostou? Para mais algumas dicas sobre buscas qualificadas no Google, visite http://brodtec.com/google.
Por que mais um livro sobre o Scrum?
Comecei a explorar o Scrum bem antes de existir material em português sobre o assunto. Entretanto, como expliquei nesta seção do livro, o Scrum foi o ponto culminante de toda uma aprendizagem que se deu a partir de uma vasta bibliografia. Aqui, alguns livros, junto a seus links, para que você possa adquiri-los, se desejar.
| Livro |
| O mítico homem-mês, de Frederick Brooks Jr. (Campus Elsevier, 2009): Esse livro é considerado por muitos, entre os quais eu me incluo, a obra seminal de engenharia de software. Tive a grande honra de traduzi-lo para o português, o que me levou a conhecer seu autor, que convidei para fazer uma palestra na Latinoware 2010. Mais informações neste link: http://brodtec.com/node/560. |
| O projeto do projeto, da modelagem à realização, de Fred Brooks Jr. (Campus Elsevier, 2010): Aqui Frederick Brooks Jr. disseca todas as fases de um projeto, desde a sua concepção até a sua efetiva realização. Mais informações neste link: http://brodtec.com/o-projeto-do-projeto-da-modelagem-realiza-o. |
| Scrum and XP from the Trenches – how we do Scrum, de Henrik Kniberg (InfoQ, 2007): Esse livro pode ser lido online ou baixado diretamente do portal InfoQ. Se você for ler apenas mais um livro depois deste que está em suas mãos, esse tem de ser o escolhido. http://www.freetechbooks.com/scrum-and-xp-from-the-trenches-how-we-do-scrum-t643.html |
| As palavras mais comuns da língua inglesa, de Rubens Queiroz de Almeida (Novatec, 2003): Estranhou a indicação? Pois não estranhe! Para aprimorar-se no Scrum e em outros métodos ágeis é fundamental o conhecimento da língua inglesa. Os blogs dos criadores e principais praticantes do Scrum estão em inglês, como você verá nos links a seguir. Esse pequeno livro do Rubens Queiroz de Almeida é um grande aliado na rápida aprendizagem do inglês. https://novatec.com.br/livros/palavras-mais-comuns-da-lingua-inglesa-2ed/ |
Agora, alguns links.
| Descrição |
| Página sobre o Scrum no portal da BrodTec: Esse link não é novidade para você. Nesta mesma seção do livro já falei da página http://brodtec.com/scrum. Essa é a página que faz companhia a esse livro e é nela que sempre coloco os links para artigos que escrevo sobre o assunto. |
| Blogs sobre Scrum e métodos ágeis: Ao longo dos anos, fui colecionando os blogs que têm sempre sido importantes em minha contínua aprendizagem sobre Scrum e métodos ágeis. Esse link é para uma Pearltree com a coleção atualizada de todos eles, incluindo o do Jeff Sutherland, Mike Cohn e de outros papas do assunto. http://www.pearltrees.com/cesarbrod/scrum-agile-blogs/id8291743 |
| “As raízes do Scrum”, por Jeff Sutherland: Ainda que um link para essa apresentação também esteja destacado em http://brodtec.com/scrum, referencio-a especialmente aqui com a recomendação de que, se você for seguir apenas um dos links recomendados, que seja esse link. Nada melhor do que ouvir da voz do criador os motivos que o levaram ao Scrum e à evolução do processo. http://brodtec.com/node/433 |
Guia de leitura
Aqui coloco como referência um pouco do que eu mesmo uso como meu guia de aprendizagem continuada, não só sobre Scrum, mas também sobre vários outros assuntos de meu interesse. Os blogs que mencionei anteriormente, por exemplo, não os acesso diretamente, mas, sim, por intermédio do Feedly, um agregador de notícias que tenho instalado em meu desktop, em meu smartphone e em meu tablet. A questão é que a quantidade de informações produzida é sempre maior do que a quantidade que conseguimos absorver. Assim, temos de ser muito criteriosos em nosso processo de filtragem e não ficarmos ansiosos em função da realidade de que jamais conseguiremos ficar por dentro de tudo. E o melhor filtro sempre é aquele das pessoas que conhecemos e confiamos e os de outras pessoas inteligentes e instigantes que conhecemos em encontros, eventos e mesmo em festas e botecos.
Capítulo 1 – Contratos em tempos ágeis
| Ferramenta |
| Feedly O Feedly é a página que abre imediatamente com meu navegador. Um recurso bacana dessa ferramenta é que você pode classificar suas fontes de leitura. Tenho uma categoria especial para Agile. O Feedly é, também, bastante inteligente em suas sugestões de fontes de notícia, e tive ótimas surpresas ao aceitar tais sugestões. https://feedly.com |
| Mapa mental de meu ambiente pessoal de aprendizagem Você já sabe, agora, que sou fã de mapas mentais. Em minha opinião, eles são a melhor maneira de capturar, interpretar e disseminar ideias e conceitos. Nesse link você encontra uma série de artigos que explicam como montei meu ambiente pessoal de aprendizagem, além do próprio mapa do mesmo. http://cesar.brod.com.br/post/40089227584/mapa-mental-de-meu-ambiente-pessoal-de |
| Descrição |
| “Quando o Bazar não funciona: custo total de ‘propriedade’ no desenvolvimento de um sistema complexo em software livre, o GNUTECA” Essa é a primeira vez em que menciono o uso de métodos ágeis no desenvolvimento de software livre, falando sobre a importância de formas de controle e compromisso, mesmo em desenvolvimentos que contam com uma massa desconhecida e incontrolável de desenvolvedores voluntários. http://livrozilla.com/doc/1614991/quando-o-bazar-n%C3%A3o-funciona–custo-total-de |
| “Engenharia de software livre” Esse é um trabalho escrito em conjunto com a Joice Käfer e pode ser considerado uma evolução daquele do link anterior. A orientação do trabalho foi do professor Marcelo Pimenta, da Universidade Federal do Rio Grande do Sul, grande referência em Engenharia de Software no Brasil. http://brodtec.com/node/559 |
Capítulo 2 – Métodos Ágeis
| Descrição |
| Manifesto Ágil A única referência aqui! Leia, decore e tatue na sua mente o Manifesto Ágil. http://agilemanifesto.org/iso/ptbr/manifesto.html |
Capítulo 3 – Extreme Programming
| Descrição |
| “Extreme Programming: a gentle introduction” Muitos links a seguir para aprender mais sobre XP e métodos ágeis em geral. http://www.extremeprogramming.org/ |
| “Go to statement considered harmful” Para você, que é bem nerd, uma boa referência ao artigo original, de 1968, de Edsger Dijkstra. https://en.wikipedia.org/wiki/Considered_harmful |
| A Catedral e o Bazar, de Eric Raymond Ensaio essencial de Eric Raymond, traduzido para o português, mantido pelo portal Domínio Público. http://www.dominiopublico.gov.br/pesquisa/DetalheObraForm.do?select_action&co_obra=8679 |
Capítulo 4 – Visão geral do Scrum
Imagino que esse seja o capítulo que você mais usará para explicar o Scrum a outras pessoas. As imagens que usei e os links para elas estão todos na versão online desse livro, mas talvez você queira usar outras imagens e referências nas suas apresentações e na motivação da sua equipe.
| Descrição |
| Como usar imagens do Google sem ser processado por ninguém Dicas de como obter imagens que podem ser reutilizadas, obtidas a partir de uma pesquisa por imagens no Google. http://cesar.brod.com.br/post/48866008362/como-usar-imagens-do-google-sem-ser-processado-por |
| Burndown chart Exemplo de um burndown chart criado na forma de um documento compartilhado do Google Drive. O Google Drive é uma excelente ferramenta para o trabalho com times geograficamente distribuídos. http://brodtec.com/scrum/burndown |
| Backlogs Exemplos de Product e Sprint Backlogs, também no Google Drive. http://brodtec.com/scrum/backlog |
Capítulo 5 – Construindo o Product Backlog
| Descrição |
| Apresentação reutilizável sobre o Scrum, por Mike Cohn Uma apresentação básica sobre o Scrum, traduzida em várias línguas, inclusive o português. http://www.mountaingoatsoftware.com/agile/scrum/resources/a-reusable-scrum-presentation |
| O Diálogo entre Sócrates e Íon Especialmente para você que é muito nerd. http://www.consciencia.org/platao_ion.shtml |
| Blog de David Churchville Infelizmente, o blog de David Churchville não é mais atualizado desde 2008. Seus textos, porém, em sua grande maioria, são atemporais e uma excelente referência para quem quer se aprofundar em User Stories. Obrigado, WayBack Machine! http://blog.extremeplanner.com/ |
| “INVEST in good stories, and SMART tasks” Excelente artigo do pessoal do XP123. https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ |
| Mapa mental proposto para o Portal Ibero-Americano de Software Livre Nesse link você encontra o mapa mental navegável. http://brodtec.com/diario/scrum-product-backlog-e-mapas-mentais |
| Use esse link para começar a criar os seus próprios mapas mentais Eu gosto do Mindomo para fazer meus mapas mentais. É uma ferramenta na nuvem, com aplicativo web para desktop e para dispositivos móveis. https://www.mindomo.com/pt/ |
| Poker do Planejamento O Mike Cohn criou o aplicativo web PlanningPoker.Com, que permite que se faça o planejamento online, via internet, de graça, desde que se faça o registro no site. https://www.planningpoker.com/. |
| Scrum Time (by Endava) Um aplicativo simples com as cartas do poker do planejamento (que podem ser customizadas) e um timer para impedir que suas reuniões diárias se prolonguem. https://appadvice.com/app/scrum-time-planning-poker/844162336 |
| Conjunto de cartas para o Poker do Planejamento A partir desse link você pode baixar o conjunto de cartas em formatos PDF e ODT para recortar e usar da forma como estão ou modificar para criar a sua própria versão. http://cesar.brod.com.br/post/48325850345/cartas-do-scrum-poker-que-usarei-na-oficina-com-os |
Capítulo 6 – Sprint Backlogs
É durante os Sprints que a maior movimentação do Scrum acontece. Você percebeu, na leitura desse Capítulo 6, que boa parte das ferramentas necessárias ao Scrum é encontrada na web. De fato, o Google Drive já oferece planilhas e documentos que podem ser compartilhados entre toda a equipe do projeto. Em Recursos, falaremos sobre outras ferramentas. Para os exemplos usados neste capítulo, acompanhe os links a seguir.
| Descrição |
| Product Backlog e Sprint Backlog Os exemplos utilizados nesse capítulo. Copie-os e modifique-os à vontade. http://brodtec.com/scrum/backlog |
| Burndown Chart As tabelas de consumo de horas de um projeto e o Burndown Chart gerado, automaticamente, a partir delas. Em Recursos você poderá acompanhar todos os passos de criação de um Burndown Chart como esse, aprimorando-o de acordo com suas necessidades. http://brodtec.com/scrum/burndown |
| Quadro resumo do Scrum É sempre uma boa prática deixar muito visível, junto a seu time Scrum, um quadro resumo do processo. Esses do portal ScrumPrimer.Org podem ser livremente reproduzidos. |
Capítulo 7 – Ah, o cheirinho de Scrum pela manhã!
Como praticante e incentivador do Scrum, é muito importante que você preste atenção logo aos primeiros cheiros que indiquem que algo está se deteriorando. O pequeno catálogo de cheiros apresentado nesse capítulo é um bom começo, mas os cheiros variam de acordo com o tempo e o ambiente. A seguir, alguns links para você buscar mais informações sobre o assunto.
| Descrição |
| “10 ways to screw up with Scrum and XP” Essa é uma apresentação de Henrik Kniberg, autor de Scrum and XP from the Trenches, que você já sabe que é um livro obrigatório para quem está aprendendo Scrum, XP e métodos ágeis em geral. Aqui, Kniberg conta uma série de maneiras pelas quais podemos errar na implantação do Scrum em uma ótima coleção de maus exemplos a não serem seguidos. https://www.infoq.com/presentations/Fail-Scrum-Henrik-Kniberg/ |
| Porcos e Galinhas Para um alívio cômico, que tal acessar o link abaixo e ver uma tirinha que resume a fábula do porco e da galinha, traduzida em várias línguas? https://www.implementingscrum.com/cartoons/ |
Capítulo 8 – Estimativas de tempo, esforço e investimento
Esse foi o capítulo mais árido do livro, concorda? Porém você também há de concordar que agora possui elementos para começar a medir, efetivamente, o quanto o uso do Scrum melhora a sua produtividade. É importante estabelecer um ponto inicial de medida para que você possa comprovar essa melhora. Se você não mede, como poderá saber se piorou ou melhorou? E, mesmo que você saiba e perceba, como provar isso a outras pessoas quando for necessário?
| Descrição |
| “Learning how to estimate” O blog Notes From a Tool User é uma das minhas fontes de atualização constante. Nesse artigo, da série Scrummaster Tales, Mark Levison apresenta uma excelente crônica sobre estimativas no Scrum. https://agilepainrelief.com/notesfromatooluser/2012/06/scrummaster-tales-learning-how-to-estimate.html |
| User Stories Nesse capítulo, as User Stories voltaram à tona. O melhor livro sobre esse assunto é o User Stories Applied: For Agile Software Development, do Mike Cohn (Addison-Wesley, 2004). Siga o link a seguir e motive-se a adquirir o livro. https://www.mountaingoatsoftware.com/agile/user-stories |
| Pontos de Função Esse é um assunto bastante complexo, e você pode desejar aprofundar-se nele caso deseje vender projetos de desenvolvimento para o governo ou para grandes empresas. Uma boa forma de começar a entender melhor o assunto é pesquisar os trabalhos acadêmicos disponibilizados no Google Acadêmico, nesse link. |
Capítulo 9 – Product Backlog Refinement
A prática de Product Backlog Refinement, ou o refinamento do Product Backlog, é considerada uma GASP (Generally Accepted Scrum Practice – prática geralmente aceita no Scrum). GASP é um termo cunhado por Mike Cohn, autor dos livros User Stories applied for agile software development, Agile Estimating and Planning e Succeeding with Agile, além de cofundador das organizações Agile Alliance e Scrum Alliance. Considero importantes as práticas definidas para o Product Backlog Refinement a ponto de ter incluído esse capítulo no livro, buscando ilustrar com um exemplo prático (o Jogo dos Tronos) para fixar, ainda mais, o processo do Scrum. Ressalto, porém, que prefiro incluir as atitudes do Product Backlog Refinement aos ritos já consagrados do Scrum.
| Descrição |
| “How to hold an effective Backlog Grooming session” Os artigos do ScrumAlliance.org são excelentes fontes de referência. Esse é o que considero fundamental (incluindo os comentários ao final dele) no que diz respeito a atitudes para o bom refinamento de um Product Backlog. Ficará muito evidente, após a leitura desse artigo, o quanto a prática que prego é influenciada por essas dicas da autora Angela Druckman. https://www.thedruckmancompany.com/the-agile-mindset/articleid/19/how-to-hold-an-effective-backlog-grooming-session |
| “Grooming the Product Backlog” Esse artigo de Roman Pilcher propõe o uso do Product Canvas para o Product Backlog. Essa é uma alternativa interessante ao mapa mental que vale muito a pena conhecer, especialmente se sua empresa ou seus clientes já têm alguma familiaridade com metodologias como o Business Model Canvas. https://www.romanpichler.com/blog/grooming-the-product-backlog/ |
| Agile Training – Playlist da CollabNet Dentre os muitos vídeos dessa playlist da CollabNet, um é exatamente sobre o refinamento do backlog. Mas vale muito a pena assistir a todos os vídeos, sempre curtos e objetivos. https://www.youtube.com/playlist?list=PLF6BFA8BAEDF6CE70 |
| Protótipos de papel Para boas ideias sobre a construção de protótipos de papel, confira essa pesquisa no YouTube. http://goo.gl/89Bpr |
O que mais você pode modificar no Jogo dos Tronos? Há mesmo a necessidade de divisão do tabuleiro em duas áreas? E se, em vez de iniciar o jogo totalmente cercado de peões, o rei já começar com dois ou três flancos abertos? E, diminuindo a quantidade de peões, não seria possível colocar mais um ou dois “reinos” disputando o mesmo tabuleiro? Será que, a partir de níveis mais avançados, o próprio tabuleiro pode conter prêmios ou obstáculos (como casas que não podem ser utilizadas, ou outras que permitam “armas” que podem ser usadas para a paralisia de peças adversárias)? E se, em vez de capturar uma peça adversária cercando-a com seus peões, você transformar a peça em um aliado de seu reino?
Capítulo 10 – A definição de pronto
É importante se chegar a um acordo sobre o que todos os envolvidos em um projeto consideram “pronto”, mas também é preciso cuidado para não burocratizar o processo a ponto de impedir a dinâmica natural de seus requisitos mutantes. Você pode topar com muitos praticantes ainda tateando no mundo da agilidade, que ainda vivem o paradigma do “grande contrato”, que aprisiona o cliente em requisitos iniciais (definidos antes mesmo de ele ter o pleno conhecimento do que deseja).
| Descrição |
| “Done and undone” Esse artigo de Ken Schwaber e David Starr apresenta alguns cenários em que há interpretações diversas sobre o que está pronto ou não, os problemas causados por isso e as lições aprendidas. https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2012/hh765983(v=vs.110) |
| “Definition of done” Essa é a versão web do capítulo sobre Definition of done, do livro de Mitch Lacey, The Scrum field guide: practical advice for your first year (Addison-Wesley, 2012). O artigo inclui o link para o download de um workshop que leva à discussão e ao estabelecimento de um acordo sobre o que é o “pronto”. https://www.mitchlacey.com/intro-to-agile/scrum/definition-of-done |
Capítulo 11 – Sprint Zero
O Sprint Zero não é, nem de longe, uma unanimidade entre os praticantes do Scrum. Alistair Cockburn, autor do livro Agile software development – the cooperative game (Addison Wesley, 2007), declara:
Eu tenho a impressão de que alguém foi pressionado a responder sobre a forma como usava o Scrum quando fez algo que, obviamente, não tinha nenhum valor de negócio em seu primeiro Sprint e, por isso, usou a desculpa “Ah! Esse era o Sprint Zero”, inventando o termo para afastar seus detratores.
Ken Schwaber, ninguém menos que o cocriador do Scrum, concorda:
Sprint Zero tornou-se um termo mal utilizado para descrever o planejamento que ocorre antes do primeiro Sprint.
Mike Cohn é um pouco menos enfático em suas críticas ao Sprint Zero. Por isso mesmo relembro uma de suas frases:
Eu gostaria que todos os nomes desaparecessem. Chega de Scrum, XP, KanBan, Lean, DSM, Crystal. Deveríamos ficar apenas com o nome “agile”. Já vimos isso acontecer há duas décadas com objetos. Nós tínhamos vários enfoques e métodos de Rumbaugh, Booch, Meyer, Jacobson e outros. As diferenças foram colocadas de lado e hoje falamos meramente de objetos e de UML. Também gostaria que chegássemos a um ponto em que não precisássemos mais falar de “desenvolvimento ágil de software”, mas apenas “desenvolvimento de software” – e é óbvio que ele é ágil. Ninguém mais me pergunta se o código em Ruby que estou escrevendo é orientado a objetos. É claro que é! Espero que algum dia ninguém mais me pergunte se usei a metodologia ágil em um projeto. É claro que usei!
Como eu disse no início desse capítulo, o Sprint Zero pode servir como um conjunto de boas práticas motivacionais e preparação do ambiente para o Scrum. Use as práticas e chame o Sprint Zero do que achar melhor.
Não colocarei nenhum link aqui porque o Sprint Zero é algo novo, polêmico, e muitas coisas novas estão surgindo sobre o assunto. Procure por “Sprint Zero” no Google, junto ao nome das pessoas supracitadas, que você terá muita informação e muitos argumentos tanto com relação ao nome dessa fase quanto a seu uso ou não.
Capítulo 12 – Velocidade e produtividade no Scrum
A felicidade é a chave da produtividade. Eu confesso que cheguei a esse exato momento do livro para entregar a você a chave de ouro das metodologias ágeis. Proporcione tudo o que leva ao Ba (o estado supremo de criatividade e superprodutividade). Mas não se deixe levar puramente pelo entusiasmo. Meça o que é possível medir, tomando o cuidado para que as medidas não adicionem uma carga adicional a seus projetos. Esteja atento a percepções, mas compare-as com fatos reais e mensuráveis.
| Descrição |
| “Shock therapy: a bootstrap for hyper-productive Scrum” Íntegra do artigo de Jeff Sutherland, Scott Downey e Björn Granvik, apresentado no evento Agile Atlanta. https://www.researchgate.net/publication/220925909_Shock_Therapy_A_Bootstrap_for_Hyper-Productive_Scrum |
| Pesquisa completa sobre o uso de métodos ágeis. https://stateofagile.com/ |
Capítulo 13 – Ferramentas
O conjunto de ferramentas abordado nesse capítulo está longe de ser completo ou definitivo. Em suas explorações pelo mundo do Scrum e da agilidade, você certamente encontrará outras ferramentas auxiliares dignas de nota e eu ficarei muito feliz se você puder dividi-las comigo e com os demais leitores deste livro. Na página web que faz companhia a este livro, http://scrum.brod.com.br, você encontrará formas de compartilhar suas descobertas. A seguir, algumas ferramentas de caráter mais amplo ou genérico, que não servem apenas para o Scrum, mas que podem auxiliar muito seu pensamento ágil.
| Descrição |
| Pomodroido |
| Online Timer Todos os ritos do Scrum devem acontecer dentro de limites de tempo (time boxes). No caso dos ritos de maior duração é bom manter o cronômetro visível para todos em uma tela grande e o Online Timer é ótimo para isso. Esse aplicativo web é bastante customizável: pode-se trocar a imagem de fundo, o alarme (que pode ser carregado a partir de um vídeo no Youtube, por exemplo) e, claro, a quantidade de tempo alocada para cada atividade. http://www.timer-tab.com/ |
Capítulo 14 – Scrum e planejamento estratégico
No fim das contas, um Planejamento Estratégico é um produto. Um produto especial, dinâmico, mas um produto. E o Scrum aplica-se muito bem ao desenvolvimento de qualquer produto.
| Descrição | |||
| “Efficient development of mobile applications, test early, test often and keep testing” Apresentação do professor Pekka Abrahansson, do VTT Technical Research Centre, na qual propõe um formato de reunião de planejamento estratégico em três dias: um para o planejamento, outro para a execução do que foi planejado e um último para a entrega do produto. Essa apresentação influenciou muito minha prática de liderança em exercícios de planejamento estratégico. http://web.archive.org/web/20100602081009/http://www.ouka.fi/wirelesscities/Presentations/abrahamsson_wireless_public.pdf | |||
|
“Creating a mission and vision statement”
| Balanced Scorecard Ao final desse capítulo, mencionei – ou melhor, joguei ao vento! – uma metodologia da qual gosto muito para o acompanhamento e a evolução de um planejamento estratégico, o Balanced Scorecard. Nesse link, um vídeo do YouTube contendo outros links sobre o Geplanes, uma ferramenta livre para a implementação do Balanced Scorecard. http://goo.gl/CmHfB | Balanced Scorecard Ao final desse capítulo, mencionei – ou melhor, joguei ao vento! – uma metodologia da qual gosto muito para o acompanhamento e a evolução de um planejamento estratégico, o Balanced Scorecard. Nesse link, um vídeo do YouTube contendo outros links sobre o Geplanes, uma ferramenta livre para a implementação do Balanced Scorecard. http://goo.gl/CmHfB | |
| Balanced Scorecard Ao final desse capítulo, mencionei – ou melhor, joguei ao vento! – uma metodologia da qual gosto muito para o acompanhamento e a evolução de um planejamento estratégico, o Balanced Scorecard. Nesse link, um vídeo do YouTube contendo outros links sobre o Geplanes, uma ferramenta livre para a implementação do Balanced Scorecard. http://goo.gl/CmHfB | |||
| Balanced Scorecard Ao final desse capítulo, mencionei – ou melhor, joguei ao vento! – uma metodologia da qual gosto muito para o acompanhamento e a evolução de um planejamento estratégico, o Balanced Scorecard. Nesse link, um vídeo do YouTube contendo outros links sobre o Geplanes, uma ferramenta livre para a implementação do Balanced Scorecard. http://goo.gl/CmHfB |
Capítulo 15 – Scrum na escola, na família, na vida
| Descrição |
| Bruce Feiler: Programação ágil – para a sua família Palestra ministrada por Bruce Feiler em fevereiro de 2013 para o TED, onde o autor de The secrets of happy families propõe o uso de métodos ágeis para as famílias modernas. https://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family |
| “The promise of open data in Brazil: fostering participation, building local capacities” https://blog.raulza.me/wp-content/uploads/2018/11/Brazil-OD-2013-05-29.pdf |
Leitura complementar
ALMEIDA, M. Arte Coreográfica: Plasticidade Corporal e Conhecimento Sensível. (Org.). A cena em Foco: artes coreográficas em tempos líquidos. Brasília: Editora IFB, 2015.
ANDERSON, David J.; CARMICHAEL, Andy. Essential Kanban Condensed. Estados Unidos: Lean Kanban University Press.
ANDERSON, David J. Kanban. Estados Unidos: Blue Hole Press, 2010.
BAINBRIDGE COHEN, Bonnie. Sentir, Perceber e Agir: educação somática pelo método Body-Mind Centering®. Tradução de Denise Maria Bolanho. São Paulo: Edições SESC São Paulo, 2015.
BECK, Kent; ANDRES, Cynthia. Extreme Programming Explained: Embrace Change (XP Series). Estados Unidos, 2004.
BERTAZZO, Ivaldo. Corpo Vivo – Reeducação do movimento / Ivaldo Bertazzo; colaboração de Ana Marta Nunes Zanolli, Geni Gandra, Juliana Sorto e Liza Ostemayer; prefácio de Drauzio Varella; fotografias de Thales Trigo. São Paulo: Edições SESC SP, 2010.
BRECHNER, Eric. Agile Project Management with Kanban. Estados Unidos: Microsoft, 2015.
BROOKS, Frederick Jr. O mítico homem-mês. Rio de Janeiro: Campus, 2009.
BROOKS, Frederick Jr. O projeto do projeto. Rio de Janeiro: Campus, 2010.
CAROLI, Paulo; CAETANO, Tainã. Retrospectivas Divertidas: atividades e idéias para fazer retrospectivas ágeis mais envolvente. São Paulo: Editora Caroli, 2019 (previsto).
CHENG, Kevin. See What I Mean: How To Use Comics to Communicate Ideas. Estados Unidos: Rosenfeld Media, 2012.
CHIARA, Andressa. O Produto Ágil: Product Discovery: Um guia sucinto para criar um produto em um ambiente de agilidade. Brasil: Amazon Kindle, 2018.
COHN, Mike. Agile Estimating and Planning. Estados Unidos: Prentice Hall, 2005.
COHN, Mike. User Stories Applied. Estados Unidos: Pearson Education, 2004.
COHN, Mike. Succeeding with Agile: Software Development Using Scrum. Estados Unidos: Addison-Wesley, 2009.
DEGRACE, Peter; STAHL, Leslie Hulet. Wicked problems, righteous solutions: a catalog of modern engineering paradigms. Estados Unidos: Yourdon Press, 1991.
EDMONDSON, Amy C. A organização sem medo: Criando segurança psicológica no local de trabalho para aprendizado, novação e crescimento. Rio de Janeiro: Alta Books, 2020.
FEILER, Bruce. The secrets of happy families. Estados Unidos: Harper Collins, 2013.
FINEP. Guia de Métricas de Software. São Paulo: Editora FINEP, 2017. (Disponível online em http://www.finep.gov.br/images/licitacoes/2017/Consulta012017/II_GuiaDeMetricasDeSoftware.pdf). Verificado em 11 de agosto de 2023.
FOWLER, Martin. Refactoring. Estados Unidos: Addison-Wesley, 1999.
GOLDSTEIN, Ilan. Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools & Tips. Estados Unidos: Addison Wesley, 2014.
GREBLER, Maria Albertina Silva; PIZARRO, Diego. A somática e as artes da cena: fricções da experiência e sua influência no ensino superior e na cultura contemporânea – parte I e II. Repertório, Salvador, ano 21, n. 31. 2018.2.
HANNA, T. Dictionnary definition of the word somatics. Somatics, v. 4, n. 2, p. 1, 1983.
KNIBERG, Henrik. Scrum and XP from the Trenches – 2nd Edition. Estados Unidos: InfoQ, 2015.
LACEY, Mitch. The Scrum field guide: practical advice for your first year. Estados Unidos: Addison-Wesley, 2012.
LARMAN, Craig. Agile and iterative development: a manager’s guide. Estados Unidos: Addison-Wesley, 2004.
LARMAN, Craig; VODDE, Bas. Large-Scale Scrum: More with LeSS. Estados Unidos: Addison-Wesley, 2016.
LARMAN, Craig; VODDE, Bas. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Estados Unidos: Pearson Education, 2008.
LARMAN, Craig; VODDE, Bas. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Estados Unidos: Pearson Education, 2010.
MARTIN, Robert. Código Limpo: habilidades práticas do agile software. Rio de Janeiro: Alta Books, 2012.
MORIN, Edgar. A via para o futuro da humanidade. Tradução de Edgar de Assis Carvalho, Mariza Perassi Bosco. Rio de Janeiro: Bertrand Brasil, 2013.
NUDELMAN, Greg. The $1 Prototype: Lean Mobile UX Design and Rapid Innovation for Material Design, iOS8, and RWD. Estados Unidos: Design Caffeine, 2014.
PATTON, Jeff. User Story Mapping. Estados Unidos: O’Reilly, 2014.
PICHLER, Roman. Agile product management with Scrum. Estados Unidos: Addison-Wesley, 2010.
RAYMOND, Eric S. The Cathedral and the Bazaar. Estados Unidos: O’Reilly, 1999.
SABBAGH, Rafael. Scrum: Gestão ágil para projetos de sucesso. São Paulo: Casa do Código, 2013.
SALUS, Peter. A quarter century of Unix. Estados Unidos: Addison-Wesley, 1996.
SALUS, Peter. Casting the net. Estados Unidos: Addison-Wesley, 1995.
SANTOS, Angela. A biomecânica da coordenação motora. São Paulo: Summus, 2002.
SCHWABER, Ken. Agile project management with Scrum. Estados Unidos: Microsoft, 2004.
SUTHERLAND, Jeff. Scrum. A Arte de Fazer o Dobro do Trabalho na Metade do Tempo. São Paulo: Leya, 2016.
SUTHERLAND, Jeff; DOWNEY, Scott; Granvik, Björn. Shock Therapy: A Bootstrap for Hyper-Productive Scrum. Estados Unidos: scruminc, 2009. (Disponível online em https://www.scruminc.com/wp-content/uploads/2014/05/Shock-Therapy.pdf). Verificado em 11 de agosto de 2023.
SUTHERLAND, Jeff. First Principles in Scrum. United Stated: Publicação do autor.
TAILLE, Yves de La. Piaget, Vigotski, Wallon: teorias psicogenéticas em discussão / Ives de la Taille, Marta Kohl de Oliveira, Heloysa Dantas. São Paulo: Summus, 2019
TAKEUCHI, Hirotaka; NONAKA, Ikujiro. The new new product development game. Estados Unidos: Harvard Business Publishing, Jan. 1986.
THEBAS, Cláudio; DUNKER, Christian. O palhaço e o psicanalista: Como escutar os outros pode transformar vidas. São Paulo: Planeta. 2021.
VIGOTSKY, Lev Semenovich. A construção do pensamento e da linguagem. Tradução Paulo Bezerra. São Paulo: Martins Fontes, 2000.
Glossário
Aqui está um glossário resumido dos termos relacionados ao Scrum, aos métodos ágeis e a outros assuntos pertinentes abordados neste livro. Use o índice remissivo para aprofundar-se nesses e em outros termos discutidos neste livro e as referências para buscar mais informações além do que está contido aqui.
Ba
Termo de origem japonesa que Jeff Sutherland define como o zen do Scrum. É o conjunto holístico e sinérgico que envolve o ambiente de desenvolvimento, os membros da equipe, o tempo no qual o trabalho acontece e o conteúdo que é trabalhado e produzido. É o ponto de interação hiperprodutiva, do qual as ideias e soluções inovadoras e criativas emergem.
Burndown chart
Planilha e gráfico que mostram o consumo dos recursos do projeto (tempo, pontos de função ou qualquer outra medida adotada) à medida que ele avança, servindo como uma rápida ferramenta visual para a correção imediata de rumos.
Definição de pronto
Ou definição de concluído ou acabado. É o acordo ao qual chegam a equipe Scrum, o Product Owner e os patrocinadores do projeto sobre o que é quando algo pode ser considerado pronto por todos os interessados.
Engenharia de software
Área da computação voltada à especificação, ao desenvolvimento e à manutenção de sistemas de software, com aplicação de tecnologias e práticas de gerência de projetos e outras disciplinas, visando à organização, produtividade e qualidade. Atualmente, essas tecnologias e práticas englobam linguagens de programação, banco de dados, ferramentas, plataformas, bibliotecas, padrões, processos e a questão da Qualidade de Software. Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. Além disso, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento de um sistema computacional. (fonte: Wikipedia)
Equipe Scrum
Equipe multidisciplinar e autogerenciada que será a principal responsável pelo desenvolvimento do produto.
Extreme Programming
Método ágil que define uma série de práticas comumente adotadas em conjunto com o Scrum. O Scrum e o Extreme Programming foram criados praticamente em paralelo; o primeiro, mais voltado à atitude das pessoas, aos seus papéis, ritos e artefatos; e o segundo é mais orientado à engenharia de desenvolvimento.
GASP
Generally Accepted Scrum Practice, termo cunhado por Mike Cohn para as práticas que, embora não façam parte da definição original do Scrum, são adotadas e aceitas por seus praticantes. Exemplos de GASP são o Sprint Zero e o Product Backlog Refinement.
KanBan
Para efeito desse livro, KanBan é um quadro de tarefas dividido em três colunas: a fazer; em execução; feito. Nessas colunas são coladas notas adesivas com as histórias e anotaçẽs relativas a ela. Essas notas avançam no quadro à medida que as histórias progridem no Sprint. Leia mais sobre isso no quadro {{quadro}} no capítulo {{xx}}VER ISSO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
Lei de Brooks
Em sua obra seminal O mítico homem-mês, Fred Brooks Jr. enuncia a “lei de Brooks”, que, em resumo, diz que adicionar pessoas a um projeto atrasado apenas irá atrasá-lo mais ainda. Em sua análise sobre a razão disso, Fred aponta sobrecargas causadas por comunicação e gestão e sugere o uso de pequenos times para projetos bem definidos e contidos.
Manifesto ágil
Em fevereiro de 2001, 17 pessoas que já trabalhavam com Extreme Programming, Scrum ou outros dos chamados Métodos Leves (Lightweight Methods) de desenvolvimento de software reuniram-se em um hotel nas montanhas nevadas do estado norte-americano de Utah para trocar ideias sobre o que estavam fazendo.
Martin Fowler sugeriu o termo “agile” (ágil) para descrever aquilo que discutiam e apresentou a redação do Manifesto Ágil, assinado por todos os presentes e por muito mais pessoas a partir de então.
• Indivíduos e interações são mais importantes que processos e ferramentas.
• Software em funcionamento é mais importante que documentação abrangente.
• Colaboração com o cliente é mais importante que negociação de contratos.
• Responder a mudanças é mais importante que seguir um plano.
Métodos ágeis
São métodos de desenvolvimento e gestão de projetos que incorporam as declarações do Manifesto Ágil. Neste livro, falamos de dois deles: o Scrum e o Extreme Programming. Alguns outros que podem interessar a você são: Agile Modeling; Agile Unified Process (AUP); Dynamic Systems Development Method (DSDM); Essential Unified Process (EssUP); Exia Process (ExP); Feature Driven Development (FDD); Open Unified Process (OpenUP); Crystal Clear; e Velocity Tracking.
Product Backlog
Lista de tudo o que é necessário ao projeto na forma de User Stories. Os itens da lista devem ter seu foco no que o cliente (ou o usuário final) deseja e devem ser priorizados de acordo com a vontade do Product Owner.
Product Backlog Refinement
Reuniões de ajustes e refinamentos do Product Backlog, das quais a equipe de desenvolvimento, o Product Owner, o Scrummaster e, eventualmente, outros interessados podem fazer parte.
Product Owner
O dono do projeto, o cliente, aquele que está pagando por ele ou, dentro de uma empresa ou instituição, é o responsável principal por sua entrega.
Scrum
É o tema deste livro! Uma metodologia, um processo ou um conjunto de atitudes, ritos e artefatos que visam a permitir que as pessoas trabalhem felizes e de maneira produtiva, autogerenciável e garantindo entregas que satisfaçam plenamente aos seus usuários e clientes.
Scrummaster
Membro da equipe que garante o bom andamento do projeto, assegurando que seus ritos sejam cumpridos, que seus artefatos sejam usados de maneira correta e qualquer obstáculo ao trabalho da equipe seja removido. O Scrummaster não é um papel fixo, mas rotativo entre todos os membros da equipe, trocado a cada Sprint.
Sprint
Cada uma das fases dentro das quais um projeto Scrum se desenvolve. Um Sprint deve ter uma duração pequena (entre uma a quatro semanas) e dentro de cada Sprint a equipe realiza as tarefas do Sprint Backlog e não sofre interrupções externas.
Sprint Backlog
Lista de tarefas na forma de User Stories, extraídas do Product Backlog e escolhidas pelos membros da equipe. Estas tarefas serão descritas em termos técnicos e realizadas durante um Sprint.
Sprint Zero
Fase anterior ao Scrum, uma prática que serve para a capacitação da equipe nos ritos, artefatos e papéis do Scrum e, em especial, para garantir o apoio e comprometimento dos patrocinadores e da alta direção da empresa ou instituição que está adotando o Scrum.
User Stories
Histórias que representam o que o sistema deve fazer ou o que o produto final deve representar a seus usuários, evitando usar qualquer terminologia técnica, tipicamente na forma “Eu, no papel de [ator], desejo realizar [ação] para atingir [objetivo].”.
