1) O documento apresenta o GUILD Driven Development (GDD), um framework para auto gestão de equipes de desenvolvimento de software. 2) O GDD propõe a organização das equipes em "guildas" que trabalham em demandas ("quests") de forma dinâmica e rotativa, promovendo a troca de conhecimentos. 3) O objetivo do GDD é melhorar problemas comuns em times de TI, como estagnação técnica e falta de compartilhamento de conhecimento.

1. GUILD Driven Development
Um framework simples para auto gestão de equipes
que atuam com produtos de alta complexidade.
Version 1.0
@capcmegadrom
linkedin.com/in/capcmegadrom/

2. Esta apresentação um OVERVIEW básico sobre o que é o GDD e como ele
funciona.
O GUILD Driven Development pode servir de inspiração para melhoria da cultura
de trabalho das empresas que já utilizam método ágil em desenvolvimento de
produtos e serviços.
O GDD pode ser implementado por meios físicos (com uso de quadros e post-its),
mas também pode ser implementado como um sistema para servir de ferramenta
de trabalho integrada, onde os PLAYERs podem consultar informações, skills, e
outras informações de seus colegas.
Foi idealizado para melhorar os pontos fracos comumente verificados em times
dedicados e na cultura de empresas de TI.

3. "Por que precisamos mudar nossa forma de trabalhar?
As coisas nunca são como desejamos, mas funcionam.. pra que mudar?"

4. E se nos permitirmos imaginar por um instante, que o trabalho pudesse ser um
“RPG do mundo real”, um pouco mais sério do que outros games é claro.. mas
ainda assim divertido!
Com regras simples e claras, objetivos bem definidos, onde todos os PLAYERS
tivessem condições iguais e pudessem se organizar para alcançar os objetivos, as
QUESTS do jogo! Ganhar XP, evoluir, subir o LEVEL, e quem sabe até realizar
alguns ACHIEVEMENTS e proezas lendárias!
Hum..... por que não? ;)
Era uma vez uma GUILDA de uma empresa grande... se chamava “P&D Email”...

5. E-mail GUILD (P&D E-mail)
Host GUILD (P&D Host)
Chat GUILD (P&D Chat)
Cloud GUILD (P&D Cloud)
UI/UX GUILD (P&D UI/UX)

6. PLAYERS (Developers, QA, Designers, etc)
MESTRE (People Manager) GUARDIANs (Product Manager / PO)
QUEST BOARD (histórias / demandas)

7. Os PLAYERS analisam e desenvolvem as QUESTs, negociam e se organizam para melhor formar as equipes
de acordo com seus conhecimentos e as necessidades técnicas de cada QUEST.

8. O MESTRE faz a gestão de pessoas, orienta os profissionais para os interesses da área de negócio, mede e
observa rendimento dos profissionais. Interfere para guiar e estimular.

9. Os GUARDIANs são os representantes das áreas clientes e cuidam para priorizar QUESTs e orientar
equipes. Ficam sempre disponíveis. Atuam com as equipes sem intermediações.

10. Nos BOARDs são dispostas no máximo 3 QUESTs para análise dos PLAYERs. O backlog não fica neste
board, nem tasks de agile board. Dessa forma objetiva e clara, ficam visíveis as próximas demandas.

11. Os PLAYERS são livres para formar equipes para a QUEST em que irão atuar. Após a entrega,
formam equipes com outros PLAYERS que estiverem livres. Equipes de 2 até 4 PLAYERS.

12. Os BOARDs representam “frentes de desenvolvimento contínuas de produtos” e é a partir da quantidade
de BOARDs que é limitado o “Work In Progress”: Exemplo: 3 Boards x 3 = maximo de 9 WIPs simultâneos.
“Alpha” Products “Beta” Products “Gama” Products
Kanban Scrum Scrum Kanban KanbanKanban

13. Os PLAYERS vão até o QUEST BOARD e procuram entender as demandas junto com os GUARDIANs dos
produtos. A priorização foi feita pelos GUARDIANs com pontos: mais pontos = mais prioritário.

14. As equipes escolhem a QUEST do BOARD levando em conta a priorização mas também são cautelosos ao
se comprometer com a demanda conforme as capacidades da equipe formada.

15. Ao escolher a QUEST, iniciam os trabalhos utilizando SCRUM ou Kanban. Ao executar a QUEST não criarão
dependências técnicas pessoais que vinculem estes profissionais no futuro.

16. A tendência natural é se manter em zona de conforto, mas com equipes dinâmicas, isso é superado pois
os PLAYERs vão atuar na próxima QUEST disponível. Evoluem tecnicamente e melhoram os produtos.

17. As equipes se formarão dinamicamente e são orientadas a atuar no mínimo 1 QUEST por BOARD para
que nenhuma frente fique parada. O MESTRE deve observar e estimular integrações.

18. Conforme as equipes se formam misturando os PLAYERS, o conhecimento dos requisitos e tecnologias
serão compartilhadas. Isso promove a maximização do capital humano.

19. O comprometimento será perceptivelmente maior, devido a rotatividade de equipes e atuações mais
focadas. Isso estimula troca de experiências entre PLAYERS com técnicas, ferramentas e conhecimentos.

20. As equipes poderão consultar outros PLAYERs de outras equipes, para com isto se apropriar mais de
conhecimentos técnicos específicos, legados ou mesmo mal documentados.

21. Como as equipes são dinâmicas, é recomendado a utilização de praticas e ferramentas que compartilhem
conhecimento de cada implementação ou modificação dos produtos. Exemplo: praticas de GitHub.

22. Também é recomendável haver instalações físicas e equipamentos portáteis onde os PLAYERS possam se
sentar bem próximos a cada formação de equipe.

23. GUARDIANs sempre disponibilizam próximas QUESTs nos BOARDs para desenvolvimento contínuo, já
com pontos de prioridade desejada. Tempo e complexidade pode ser consultado junto aos PLAYERS.

24. Regularmente farão a ponte com áreas de negócio para discussões e formulação das demandas. Poderão
consultar os PLAYERS a qualquer tempo para melhorar ou formular novas QUESTs.

25. Com a ajuda dos PLAYERS farão o dimensionamento correto das QUESTs para uma granularidade
adequada e também podem priorizar QUESTs técnicas dos próprios PLAYERs.

26. Ao final, a equipe faz review com o GUARDIAN, e depois seguirá com o Delivery da implementação. E por
fim é feita uma rodada de feedbacks entre os PLAYERS da equipe.

27. Com isto, os PLAYERS podem se aprimorar, e o GUARDIAN obtém feedback importante para condução
das próximas QUESTs.

28. Após terminada a QUEST, o GUARDIAN distribui os pontos de priorização da demanda entre os PLAYERS
como forma de premiação pela entrega. E isso se tornará XP para os PLAYERS.

29. XP: 25
Developer Name
+1
Ruby & Rails
Java
NodeJS
Developer Skills
Haskell
PLAYERS podem atualizar seu CARACTER pois ganharam experiências e isso ajudará os outros players a
perceber seus novos SKILLS. Podem também postar recomendações e etc.
Achievements
LV: 2

30. A cada X meses, os PLAYERS serão reunidos pelo MESTRE e GUARDIANs para confraternização dos
“feitos” ou “achievements” dos PLAYERS como um reconhecimento.

31. A cada ano, os PLAYERS são reunidos pelo MESTRE e GUARDIANs para confraternização e premiação dos
ROCKIES do ano. A data desse evento de premiação é combinada no inicio de todo os anos.

32. A premiação é baseada no XP acumulado no ano. E a cada quantidade de XP sobe 1 LEVEL no CARACTER
dos players. Com isto, haverá condições iguais para superação individual de cada PLAYER.

33. Equilíbrio na quantidade de BOARDs, QUESTS e PLAYERS é essencial. o MESTRE e GUARDIANs devem ficar
atentos a isso e fazer dimensionamentos adequados para atingir a melhor performance.

34. Em situações emergenciais, o MESTRE convoca toda a GUILDA. Os PLAYERS param tudo que estão
fazendo e de forma voluntaria atuam no incidente. O MESTRE recompensará com pontos XP.

35. O MESTRE poderá solicitar ajuda a outras Guildas. Pode também permitir a atuação dos PLAYERS entre
guildas para promover trocas de experiências e abrir oportunidades.

36. Com esta mudança de cultura, os profissionais de sua empresa vão “parar de fazer
projetos” e ao invés disso vão manter, desenvolver e evoluir PRODUTOS e
SERVIÇOS!
Haverá menos diferenças de conhecimentos por time; menos sucateamento
técnico por movimentação ou perda de talentos de times de projeto critico;
menos produtos legados; não haverá mais “projeto legal e projeto ruim” para
trabalhar, só haverá demandas; não haverá mais “o especialista do time x” ..
todos são especialistas!
Como migrar do sistema de TIMES DEDICADOS POR PROJETOS para
essa cultura de EQUIPES DINÂMICAS?
A seguir temos slides com nossa sugestão de como migrar para o GUILD DRIVEN
DEVELOPMENT de forma gradual e segura.

37. The dedicated team model is an alternative to a matrixed model of personnel
assignmen. There are also potential disadvantages to be aware of, such as:
• Stagnation of technical skill sets;
• Boredom and its associated morale problems;
• Reduced opportunities to learn about other areas of the company’s business,
with the risk of developing a narrow perspective on the work;
• Missed value from deep specialists;
Por que precisamos mudar nossa forma de trabalhar?
A evolução é o caminho natural de tudo!

38. "Por que usamos modelos antigos para tentar resolver problemas novos?
Afinal, desenvolvedores não são mais como antigamente..."

39. E-mail Division (P&D E-mail)
Host Division (P&D Host)
Chat Division (P&D Chat)
Cloud Division (P&D Cloud)
UI/UX Division (P&D UI/UX)

40. TEAM “A” TEAM “B”
IT Manager / Team Coordinator
Project “Alpha”
• System “ABC”
• System “ZYD”
• Database “XPTO”
Project “Beta”
• System “GHJ”
• Database “RTY”
Project “Gama”
• System “OPQ”
• Database “XPTO”
Project “Delta” (legacy)
• System “HJK”
• Database “XPTO”
Project “Epsilon” (legacy)
• System “IRT”
• System “OKM”
• System “RFV”
• System “TGB”
• Database “XPTO”
• Database “EDCW”
• Storage “QWE”
Project “Dzeta”
• System “RDS”
• Database “RTY”
PO / BO
O PO passa demandas para os times dedicados aos projetos. Os Times dedicados desenvolvem os
projetos utilizando metodologias ágeis. O Gerente coordena atividades e intervém quando necessário.

41. TEAM “A” TEAM “B”
IT Manager / Team Coordinator
Project “Alpha”
• System “ABC”
• System “ZYD”
• Database “XPTO”
Project “Beta”
• System “GHJ”
• Database “RTY”
Project “Gama”
• System “OPQ”
• Database “XPTO”
Project “Delta” (legacy)
• System “HJK”
• Database “XPTO”
Project “Epsilon” (legacy)
• System “IRT”
• System “OKM”
• System “RFV”
• System “TGB”
• Database “XPTO”
• Database “EDCW”
• Storage “QWE”
Project “Dzeta”
• System “RDS”
• Database “RTY”
PO / BO
PRODUCT “A”
PRODUCT “B”
SERVICE “C”
SERVICE “D”
Os produtos são compostos de partes complexas desenvolvidas em mais de um Time. Os profissionais
desconhecem boa parte das tecnologias e arquitetura aplicadas nos produtos como um todo.

42. EQUIPE “A” EQUIPE “B”
MESTRE (People Manager)
Project “Alpha”
• System “ABC”
• System “ZYD”
• Database “XPTO”
Project “Beta”
• System “GHJ”
• Database “RTY”
Project “Gama”
• System “OPQ”
• Database “XPTO”
Project “Delta” (legacy)
• System “HJK”
• Database “XPTO”
Project “Epsilon” (legacy)
• System “IRT”
• System “OKM”
• System “RFV”
• System “TGB”
• Database “XPTO”
• Database “EDCW”
• Storage “QWE”
Project “Dzeta”
• System “RDS”
• Database “RTY”
GUARDIAN (PO)
PRODUCT “A”
PRODUCT “B”
SERVICE “C”
SERVICE “D”
Para migrar para o GAME, os profissionais se tornam PLAYERs, o Gerente se torta MESTRE e o PO se torna
GUARDIÃO, e os PLAYERs elegem qual é o sistema mais importante que estava nos times dedicados.

43. EQUIPE “A” EQUIPE “B”
MESTRE (People Manager)
Project “Alpha”
• System “ABC”
• System “ZYD”
• Database “XPTO”
Project “Beta”
• System “GHJ”
• Database “RTY”
Project “Gama”
• System “OPQ”
• Database “XPTO”
Project “Delta” (legacy)
• System “HJK”
• Database “XPTO”
Project “Epsilon” (legacy)
• System “IRT”
• System “OKM”
• System “RFV”
• System “TGB”
• Database “XPTO”
• Database “EDCW”
• Storage “QWE”
Project “Dzeta”
• System “RDS”
• Database “RTY”
GUARDIAN (PO)
PRODUCT “A”
PRODUCT “B”
SERVICE “C”
SERVICE “D”
Na primeira etapa, os PLAYERs permanecem em seus TIMES resolvendo QUESTs dos sistemas prioritários.
Paralelamente irão formar EQUIPES no sistema de GUILDA para resolver QUESTs dos demais sistemas.

44. Por um tempo, as “demandas dedicadas” serão desenvolvidas pelas “equipes originais”. Mas, após
entregar a demanda, os PLAYERs formam equipes para atuar nas outras QUESTs do BOARD livre.
PRODUCT “A”
PRODUCT “B”
SERVICE “C”
SERVICE “D”
EQUIPE “A” EQUIPE “B”
Project “Alpha” Project “Epsilon” (legacy)

45. Com o tempo, “as antigas demandas dedicadas” serão terminadas e naturalmente, as próximas QUESTs
estarão nos BOARDs para atuação no GUILD Driven Development. Os PLAYERs já conhecem o GAME.
SERVICE “D”
EQUIPE “A” EQUIPE “B”
Project “Alpha” Project “Epsilon” (legacy)
SERVICE “C”PRODUCT “B”PRODUCT “A”

46. A velocidade para migrar do sistema de TIMES DEDICADOS POR PROJETOS para a
cultura de EQUIPES DINÂMICAS pode variar conforme as condições, complexidade
de sistemas e timing para atendimento das demandas da área de negócios.
Para os melhores resultados, é interessante que todos se envolvam e possam
contribuir com ideias, discutindo sobre esta cultura, fazendo comparações e se
aprofundando no tema a partir de casos e materiais que existem na internet.
Assim poderão tomar decisão sobre essa mudança interessante para todos e para
as empresas e seus negócios.

47. Existem processos/ferramentas para desenvolvimento de software. Então por que não
pode existir uma forma simples, uma receita, um modelo de trabalho, que possa ajudar a
criar um ambiente ideal para que os profissionais possam criar a cultura e mentalidade de
alta performance que desejamos?
O GDD, "framework de trabalho por guildas“, foi idealizado para criar condições e espaço
para resolver a raiz de muitos problemas que passam despercebidos na governança de TI.
Este framework promove os seguintes benefícios de forma natural:
• Oxigenação dos produtos dedicados a profissionais de times dedicados;
• Potencialização da atuação full-stack e devops;
• Diminuição dos débitos técnicos e aumento da qualidade;
• Troca de experiências, aprendizados e mais oportunidades técnicas para todos;
• Desperta maior compromisso e responsabilidade dos profissionais;
• Evolução das habilidades e experiências técnicas;
• Conhecimentos compartilhados e menor dependência de “profissionais chave”;
• Constância na performance e integração dos profissionais;
• Melhoria no desempenho de entrega de valor e menor desperdício;
• Cultura auto-sustentável de motivação profissional;
• Menor evasão de talentos e melhoria do hank da empresa entre as melhores;
Considerações Finais:

48. Vamos trabalhando!
LET'S PLAY!
@capcmegadrom
linkedin.com/in/capcmegadrom/