Referências

Posted on: sex, 09/20/2019 - 15:46 By: Mônica Chiesa

Todas essas referências podem ser acessadas diretamente em http://brodtec.com/scrum.

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 nós 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, o artigo original, de 1968, de Edsger Dijkstra.
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html
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 em http://brodtec.com/scrum, 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.
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. http://brodtec.com/mindomo
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.crisp.se/file-uploads/10-ways-to-screw-up-with-Scrum-and-XP.pdf
Armadilhas do Scrum
http://goo.gl/p5P1H
O link acima leva você a uma pesquisa no Google equivalente a você digitar na caixa de busca exatamente o seguinte: intitle:”common-scrum-pitfalls”
Você já sabe, intitle ordena ao Google que busque no título da página exatamente o que está entre aspas. Para mais dicas de pesquisas qualificadas no Google, visite http://brodtec.com/google.
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 é dar uma olhada nas boas apresentações disponibilizadas no SlideShare.
http://goo.gl/jwOHV
Editais do governo brasileiro que contemplam a aquisição de desenvolvimento com a métrica de Pontos de Função
O link a seguir é o resultado de uma pesquisa do Google listando todos os editais do governo que referenciam a métrica de pontos de função. Refine-a para obter editais mais específicos que contemplem a sua área de atuação.
http://goo.gl/yFtXA

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.scrumalliance.org/community/articles/2011/march/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 da VersionOne sobre o uso de métodos ágeis.
https://stateofagile.versionone.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://brodtec.com/scrum, 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
Não sei o quanto você gosta de cozinhar. Eu gosto muito. Quem está acostumado a viver de avental conhece um temporizador movido a corda na forma de um pequeno cozinheiro, de um ovo, tomate ou em outras formas mais criativas. O Pomodroido, do link ao lado, é um temporizador desse tipo, mas que roda em um smartphone.
Há toda uma técnica de melhor aproveitamento do tempo, concentração e produtividade baseada nesse temporizador inocente (leia mais em http://www.pomodorotechnique.com/). O Scrum, por ser um método e um processo que visa à felicidade das pessoas, usa muitos elementos lúdicos (você já leu sobre o Scrum Poker, notas adesivas etc.), e o aplicativo Promodoido ou um desses temporizadores de cozinha são bem eficazes na limitação do tempo de reuniões, podendo auxiliar os que desenvolvem as tarefas a também estabelecer tempos benéficos de descanso durante o trabalho.
https://play.google.com/store/search?q=pomodroido

Figura Ref.2 – Um temporizador a corda no formato de uma joaninha, que pode ser usado para estabelecer limites de tempo nas reuniões do Scrum.

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”
O artigo original de Megan Tough sobre a criação de declarações de missão e visão.
http://www.sideroad.com/Business_Communication/mission-and-vision-statement.html

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

Lembre-se de verificar o link http://brodtec.com/scrum para a versão com os links clicáveis para todos esses recursos e eventuais atualizações, junto a recomendações de blogs interessantes e personalidades do mundo ágil para você seguir no Twitter.

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”
Estudo que produzi para a ONU (PNUD) sobre o processo de abertura de dados no Brasil.
https://milunesco.unaoc.org/mil-resources/the-promise-of-open-data-in-brazil-fostering-participation-building-local-capacities/

 

Leitura complementar

ANDERSON, David J.; CARMICHAEL, Andy. Essential Kanban Condensed. Estados Unidos: Lean Kanban University Press.

ANDERSON, David J. Kanban. Estados Unidos: Blue Hole Press, 2010.

BECK, Kent; ANDRES, Cynthia. Extreme Programming Explained: Embrace Change (XP Series). Estados Unidos, 2004.

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. User Stories applied. Estados Unidos: Pearson Education, 2004.

DEGRACE, Peter; STAHL, Leslie Hulet. Wicked problems, righteous solutions: a catalog of modern engineering paradigms. Estados Unidos: Yourdon Press, 1991.

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 12 de setembro de 2018.

FOWLER, Martin. Refactoring. Estados Unidos: Addison-Wesley, 1999.

GOLDSTEIN, Ilan. Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools & Tips. Estados Unidos: Addison Wesley, 2014.

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.

MARTIN, Robert. Código Limpo: habilidades práticas do agile software. Rio de Janeiro: Alta Books, 2012.

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.

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 14 de setembro de 2018.

TAKEUCHI, Hirotaka; NONAKA, Ikujiro. The new new product development game. Estados Unidos: Harvard Business Publishing, Jan. 1986.

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].”.

 

Comentar

CAPTCHA Nosso portal usa esse mecanismo para evitar spam.