0

Scrum Setup Canvas no Agile Trends Gov 2017

Mais uma rodada de compartilhamento do Scrum Setup Canvas, desta vez na capital federal durante o Agile Gov 2017. Foi minha primeira apresentação usando como pano de fundo o Savana SCRUM, mas mantendo a pegada de diferenciação entre Go Horse e SCRUM.

Sala lotada, um bloco onde quem me precedeu foi o Allison Vale, iniciei apresentando uma das alegorias que mais curto, do Andy Glover onde o product backlog é um cesto enorme com todas as suas roupas sujas e o sprint backlog é a roupa que necessitamos para amanhã.

Valor é garantir ter a roupa adequada para seus compromissos do dia seguinte, de nada adianta lavar um cesto de cuecas ou as roupas mais caras ou as maiores ou menores, valor é ter aquela muda necessária e adequada para o dia seguinte, quer para frio, calor, longa ou curta.

SCRUM SETUP CANVAS

O mote do Scrum SetUp Canvas começa com as informações, combinações e restrições, como o tipo de máquina de lavar e secar, a capacidade de ambas, o tipo de sabão, para roupas brancas ou coloridas, se a expectativa é a entrega delas passadas e dobradas, …

Sempre trago minha maior convicção sobre o conceito de ToolBox 360º, que diz respeito a seu processo, ferramental, boas práticas, qualidade, excelência, destacando a certeza de que cada decisão acarretará ganhos ou perdas, que deverão ser transparentes e realistas.

Relembrei conceitos básicos sobre o Agilo romântico defendido por alguns e o Agila realista das grandes organizações, os conceitos básicos do SCRUM e suas variações, praticados em meio a complexidade e vicissitudes de empresas, governança de TI, PMO, GP e times.

  • Elevator Statement
  • Equipe e envolvidos
  • Aproveitamento e formato dos sprints
  • Arquitetura e Integrações
  • Indicadores e Métricas
  • Boas Práticas e Ferramentas
  • DoR (Definition of Ready)
  • DoD (Definition of Done)
  • Feriados e Férias
  • Sprint Zero
  • Reserva Técnica (%)

DESAFIO TOOLBOX 360°

Ao final dos 25 minutos, um convite ao jogo das 17:30 na mesma sala, quando 25 pessoas participaram até as 19:00 do Desafio ToolBox 360°, sempre com muitos insights, debates, argumentações e aprendizado. Tudo isso concorrendo com o happy-hour e cerveja no saguão ao lado.

SCRUM SETUP CANVAS
02/04/17 – Spoiler da minha palestra para o Agile Trends
13/04/17 – Apresentação em 25 min no Agile Trends
07/06/17 – Versão pdf tamanho A3 para impressão

TOOLBOX 360º
01/03/17 – Página Desafio ToolBox 360° / 5W2H  🙂
08/03/16 – ToolBox 360°, um guia de referência geral de boas práticas
03/04/17 – Desafio Toolbox – Agile Trends 2017 – ppt – relato

0

TecnoTalks – Pais e Filhos, projetos com amor incondicional

Se você tem um case de projeto fora da caixa entre pais e filhos, comenta aqui, em breve vai rolar um evento Tecnotalks sobre este tema e espero que possamos inspirar mais e mais parcerias desta natureza … uma forma de se divertir e estreitar laços, de desenvolver potencialidades e habilidades, de compartilhar e desmistificar nosso mundo profissional a nossos pequenos.

Cito meu grande guru e exemplo, o Paulo Caroli, que com sua filha lançou o Mistério do Colégio Alipus, seu relato é uma história inspiradora, assim como o trabalho com a minha pequena, desenhista e ilustradora, a Luisa Audy com o Savana Scrum. O Jackes Heck e a filha Ana Clara na Academia Mentes Audazes tem a parceria nos workshops e vídeos, enquanto o Giovani Rodrigues pareou com o filho Henrique em competições nacionais, infantil e adulta, de bike, onde cada um deles sagrou-se campeão nos circuitos.

Paulo & Duda – http://misteriodocolegio.com/autores/
Jorge & Luisa – https://jorgeaudy.com/savana-scrum/
Jackes & Ana – https://www.facebook.com/mentesaudazes/

Estão aparecendo outras histórias legais, como a do Fausto Vanin em que o casal e as crianças lançaram juntos o https://fifu.familyo vídeo disponível no link é muito fofo.

Tem também a do Andre Streppel em uma regata integrando gerações no Veleiros, com crianças, jovens e adultos (matéria) e vídeo abaixo …  muito legal.

https://www.youtube.com/watch?v=5M0Bp2iimxE

Pais e filhos, uma relação que pode desde cedo abrir portas, desenvolver vocações, que podem ser exemplo para outros pais e filhos na criação de novos mundos em histórias, livros, filmes, blogs, teatro, coleções, personagens, desenhos, culinária, …

Se você tem uma história, compartilhe aqui e vamos somar essa energia e compartilhar com o mundo, quem sabe não acaba gerando uma coletânea em um ebook relatando cada história singular, única, como essas \o/

A seguir, fotos que representam o lançamento do livro de sucesso, as tirinhas e seus personagens, workshops e seu canal de vídeo, pai e filho em um esporte de competição:

pais e filhos 1

pais e filhos 2

1

Não acredite em dogmas ágeis, seja ágil na agilidade

Ahhhh, não pode isso, não pode aquilo, só é ágil se for assim, só é ágil se for assado, as vezes agilidade fica parecendo um culto de tantos dogmas. É preciso ser ágil na agilidade, começar por algum lugar e deixar as retrospectivas gerarem a evolução desejada na velocidade possível.

Não confunda debates sobre mediadores e moderadores com a prática diária. A teoria tem a ver com crenças e argumentos, citamos gurus e boas práticas, pesquisas, erros frequentes e fatores críticos de sucesso. Na prática é um passo de cada vez, aprendendo, cada caso é um caso.

Uso como alegoria o uniforme de um time de futebol, o tal manto sagrado tem cores, brasões, o jogo tem regras, mas cada jogador possui biotipo e características que exigem ajustes, talvez uma chuteira diferente que o privilegie, especialmente em função de sua dinâmica de jogo.

A máxima é simples, no lugar de dizer que está errado ou procurar culpados, pergunte: Estamos melhorando? Melhores que 2 meses atrás? Piores que 2 meses a frente? Sim? Siga em frente sem desmerecer o esforço, evoluímos, seja positivo e apoie o time, o caminho é esse.

Sem esquecer da máxima das artes marciais – Shu Ha Ri – pois devemos no Shu começar tentando entender e escolher um método, seguir seus preceitos, para então aos poucos ir adaptando a nossas características, sendo ágeis na agilidade, para então finalmente supera-lo em resultados.

Karasek – Job Strain Model

No mestrado usei o modelo JSM de Karasek, onde pessoas com maior autonomia (controle) sobre seu trabalho (demanda), são mais felizes (satisfeitas). Queremos alta demanda com alto controle, isso é trabalho ativo. Baixa demanda gera acomodação, baixo controle gera frustração.

Acredito no modelo de Karasek, opondo-se a Taylor e Fayol, as pessoas gostam de trabalhar, sentirem-se úteis e competentes, orgulhosos em fazer a diferença. Afinal, estamos vivendo uma era de crescimento pessoal, desenvolvimento de competências, soft skills, empatia em sinergia.

Agile não é religião

Cada vez mais escuto dogmas, se o objetivo é debater métodos e boas práticas, sou parceiro, gosto de me provocar a pensar, mas algumas vezes nem discuto, porque fujo de dogmas. Não discuto com quem só tem dogmas, é porque é ou porque leu, mas não tem fatos e vivências.

Quem já interagiu comigo sabe que sou enfático em minhas convicções, tenho frases intensas, meu objetivo é desacomodar. Mas em cada implantação, cada empresa, área, equipe e pessoas possuem sua dinâmica. É preciso entendê-la para saber porquês e adaptar-se, baby steps.

Demoro um tempo para me posicionar, nunca só pela teoria, porque na prática a teoria é outra. Me ajusto à procura de um primeiro passo, sem ser disruptivo além da conta frente ao status quo, o importante é dar um primeiro passo firme e efetivo, para então irmos evoluindo.

As vezes iniciamos 100% acoplados ao método e já introduzimos boas práticas de interesse, as vezes um mínimo de boas práticas selecionadas para gerar valor no dia-a-dia e garantir algo que nos dê crédito adiante. Nenhum argumento é tão bom para seguir em frente quanto resultados …

. Não trabalhamos para o processo, é o contrário;
. Qual é a cultura da empresa? Qual o perfil dos líderes?
. Quais as restrições, exigências e expectativas reais?
. Está gerando valor? Qual a opinião de todos?
. É preciso acompanhar pessoas em sprints para entendê-las;
. Para avaliar melhor, use os cinco porquês (busque a causa);
. Não é aconselhável, vamos entender a motivação;
. Se eu penso diferente, me explica, se possível me mostra;
. Importante, o que tem aparecido nas retrospectivas?
. Não idealize, não tenha pressa demais, calma, baby-steps.

Mudança tem um tanto de Schein, Schneider, tem a ver com Tuckman e Yerkes-Dodson, impossível adotar Agile sem falar de soft skills, T shape e carreira proteana. Dá uma lida no ebook sobre teorias e modelos essenciais sobre os quais já postei, uma leitura fundamental para quem quiser entender melhor os porquês – Clique aqui para baixar no dropbox!

 

0

TTalks documentação – Debates não miram receitas, mas insights

Após o TecnoTalks do dia 26/07/17, algumas pessoas me mandaram mensagens e conversaram comigo sobre suas percepções de que esperavam outra coisa do debate proposto sobre documentação, eles queriam uma palestra sobre documentação. Uma em especial disse ter saído mais cedo porque achou caótico demais, percebeu que não obteria as respostas que procurava, um passo-a-passo.

Mas o formato quebrando em pequenos grupos para gerar debates e compartilhamentos finais entre eles era o objetivo desde o início quando propus um debate. Já temos receitas de bolo demais, métodos, frameworks e boas práticas, ao procurar mais uma receita de bolo, só o que acharemos é mais uma entre várias. Temos passo-a-passos em palestras, quando alguém apresenta ou resume um tema, como documentação por exemplo.

Um debate serve para nos tirar da zona de conforto, sua missão é o confronto de ideias, somente será um sucesso se seus participantes tiverem que se virar nos 30 para desenvolver suas argumentações. Pode debater aspectos teóricos ou ter base prática de seus debatedores, mas sua natureza é o debate. Documentação, por exemplo, é documentação de valor, conforme contexto, necessidade e valor que agrega.

Além de métodos, frameworks e processos, já há receitas e dogmas demais, tradicionais e ágeis. O que pesa mesmo são valores e princípios, de resto, cada vez mais acho que inexiste projeto ágil ou tradicional, existem projetos, apenas projetos bem ou mal gerenciados conforme a necessidade, não existe documentação ágil ou tradicional, o que existe ou não é documentação útil e efetiva, adequada a necessidade e realidade.

Dito tudo isso, a chave-mestra é Lean, é potencialização de valor e eliminação de desperdício em equidade, iniciando em algum lugar e melhorando continuamente, debatendo o que acontece no mundo, em outras empresas, seus acertos e erros, aprendizado vicariante, para então construir sua própria história … sem tantos dogmas, tabus e maldições.

Sobram operários e faltam filósofos na era do conhecimento
Poiesis, a arte da criação, da construção, do ser criativo

Os parceiros da noite na facilitação foram a Karina Kohl e o Vladson Freire, os dois deram uma aula de facilitação de um debate:
20292805_10155632525879443_1399579845555795983_n

A seguir os vídeos do debate sobre documentação no TTalks de 26/07 as 19:00, para a maioria foi uma oportunidade para debater, argumentar, refletir, colocar em cheque ou re-significar suas crenças sobre o assunto. Para mim, uma noite incrível de provocações, com dezenas de parceiros de viagem, muitos amigos, colegas e conhecidos de estrada. Pretendo fazer outro post mais adiante, mas por enquanto esse

 

3

Um guia de 12 páginas com o resumo do resumo

É preciso ser ágil na agilidade, por um lado tem a ver com a cultura Lean, sermos enxutos e objetivos, também tem a ver com capacidade absortiva e carreira proteana, tanto quanto criar ambientes sustentáveis e positivos. Para isso, precisamos ser criativos, planejar sucintamente, seguir MVP, validar e evoluir, é mais fácil do que parece.

IIAp

Sempre curti criar resumos, esquemas, diagramas, uma forma de fixar conhecimento, desde criança os faço para estudar, instigando minha memória visual e motora. Talvez dai venha minha paixão por registrar tudo o que aprendo e pratico aqui no blog e em livros, guias, encartes, canvas, acima de tudo escrevo para mim.

O guia de uma página A3 criado em 2014 foi crescendo (como esperado), a partir de cada livro, artigos, posts, fui incorporando conceitos e lembretes sobre diferentes métodos, frameworks e propostas, chegando a 12 páginas A3 que estão sempre comigo e compartilho com quem interajo em projetos pelo meu link no dropbox:

https:/dropbox.com/s/hp05qzvks54qad6/Super Guia Rápido.pdf

Já esta tudo aqui nos posts do blog a muito tempo, acessível em seus posts, páginas, BlogMap e links úteis, mas ainda não tinha compartilhado esta versão em pdf, talvez tenha passado desapercebido por quem acompanha os posts e não navega no blog, o conteúdo deste guia é:

  1. Estratégia e adoção Agile
  2. Papéis e carreira
  3. Pré-game e ideação
  4. Business Model Generation
  5. Preparação para o planejamento
  6. Planejamento
  7. Execução SCRUM
  8. Sustentação KANBAN
  9. Management 3.0
  10. Design Thinking
  11. DevOps
  12. Self-Assessment

O link é dropbox porque é lá que mantenho todos os pdf’s que compartilho por aqui, o link do guia A3 original onde este de 12 páginas começou é este aqui:

guiarápidoSCRUM360

0

Desafio ToolBox – POA e São Leo – 14/07/17

14/07/17 – DBTALKS Porto Alegre – TecnoPUC Sala 204 / 99a – Ao todo eramos cinquenta pessoas contando com a galera da DBserver, que chegou cedo para reorganizar asala em torno das mesas que trouxemos da 206, compondo 10 equipes de 5 integrantes. Muitos companheiros de viagem, de outras jornadas, que durante duas horas proporcionaram um ambiente barulhento enquanto negociavam suas cartas e preenchiam os tabuleiros. O feedback foi muito bom e novos insights para melhorar o jogo.

14/07/17 – TecnoSinos, Prédio UniTec 2, Mini auditório – Um evento organizado pela GVDASA, aberto ao ecossistema TecnoSinos-Unisinos. Foram mais de três horas com abertura do Marcos Arnoldo, a participação do Jonathan Stein, a parceria da Mayra Rodrigues de Souza. Muita energia, novamente cada grupo ao redor do tabuleiro debatendo, argumentando, todos entraram no jogo, ensinaram e aprenderam a medida que as rodadas iam distribuindo as cartas, cobrindo suas mais de 70 técnicas, frameworks e boas práticas.

 

0

Acredite, documentação é muito mais que as tais histórias

Acredito muito além das sábias palavras do Neil Ford, keynote no Agile Brazil de 2012, pois temos dois tipos de usuários em cada projeto, aquele óbvio, que utilizará e se beneficiará do produto entregue, mas também há um usuário oculto, aquele que dará manutenção, sustentabilidade, continuidade no que construímos, podendo até ser (feliz ou infelizmente) nós mesmos.

Como Agile Coach, consultor ou professor, insisto na necessidade de distinguir o romantismo de muitos livros e artigos de agilistas da realidade ou momentuum de sua empresa, área, equipe, tecnologia. Enquanto evoluímos no quesito de excelência em engenharia de software, devemos ter clareza do custo x benefício relativo a aceleração e redução do processo e custo de sustentação.

A tempo, a solução não é aquela encontrada pela maioria absoluta das empresa, que mascaram a sua ineficiência e péssimas práticas de desenvolvimento voltadas ao imediatismo da entrega a qualquer custo. Gerar uma alta OPEX recorrente para ter uma CAPEX reduzida amplia uma percepção equivocada de ROI, mas é fogo amigo, equivocado e inaceitável.

CAPEX (expenditure) ~ despesas ou investimentos em bens de capital; despesas de capital; aquisições. OPEX (operational expenditure) refere-se às despesas operacionais, recorrentes, continuadas.

Tenho uma extensão à Teoria da Agência, ou você está trabalhando para ficar amadoramente bem na foto e ser promovido ou tem a responsabilidade e transparência de um profissional? A entrega de hoje está gerando mais um legado a ser mantido com doses maciças de custos recorrentes ou tem baixo custo de operação por ter sido corretamente construído e documentado?

O volume reduz-se conforme a evolução de sua excelência em engenharia de software, você segue DDD, componentiza, usa BDD, especifica e automatiza por exemplos, constrói código limpo, segue boas práticas de desenvolvimento na sua arquitetura e plataforma, automação de testes e integração contínua.

Aos poucos a documentação vai se integrando ao ambiente, projeto e produto, mas não é mágico, não só porque sempre teremos registros importantes a fazer, mas porque muitos leem em um artigo que documentação é do mal e sem ter o menor critério ou escrúpulos, passam a defender um go horse documental e tem a desfaçatez de citar grandes nomes que relatam projetos de excelência …

1. Pré-game

Acredito no valor da existência de conceitos como Funil de ideias, Gestão de portfólio, programas e projetos, comitês gestores. Grandes empresas não podem prescindir disso, tanto quanto contam com os préstimos de uma governança corporativa, governança de TI, PMO, gerentes de projetos ou papel preocupado na transversalidade, em aquisições, alocações, indicadores gerenciais.

Todo o tempo e processo existente antes do projeto iniciar sua etapa de execução ou desenvolvimento é conhecido como pré-game, ideias, discussões, submissões, descartes e aprovações, culminando no planejamento que habilita a fase seguinte de game, composta por sprints, especificação, desenvolvimento, validação e entregas. Eu posso oferecer um mix flexível, mas consistente de planejamento:

1.1. Project Model Canvas Eu utilizo para a explicitação das informações básicas coletadas, um Termo de Abertura visual em uma folha grande e postits contendo o porque o projeto é necessário, o que ele é em sua essência, quem se envolverá e percepções sobre como será planejado, quando e quanto custará. Chamo a atenção para premissas, riscos, restrições e expectativas;

1.2. Elevator Statement Um ótimo aquecimento, uma abstrair e entender justificativa, quem são os clientes, qual o desafio, problema ou oportunidade, que tipo de solução imaginamos, qual o valor de negócio esperado, o que é utilizado hoje para atender esta necessidade e quais os diferenciais para que o cliente e usuário deixe a solução atual e apoie e use a nova;

1.3. Personas Quem são os atores envolvidos, seus perfis, necessidades e objetivos. Caso a caso, de 0 a 100, posso apenas caracterizá-los até utilizar de Value Proposition Canvas para identificar seus interesses, dores e expectativas de ganhos. Uma técnica dedicada a gerar empatia, tentar ver pelos olhos de cada parte envolvida, antecipando percepções de ganhos e perdas;

1.4. Customer Journey Map Uso variações simplificadas desta técnica de mapeamento, convergente a uma User Story Mapping, para entendermos os fluxos de atividades necessárias para as principais jornadas dos usuários da solução em estudo. Cada jornada, passos manuais ou informatizados. Queremos entender o passo-a-passo das personas, identificar funcionalidades do produto;

1.5. Scrum SetUp Canvas Artefato proposto para explicitar entendimento, combinações sobre tecnologia e metodologia, necessidades prévias/recorrentes a serem consideradas para efeito de modelagem, planejamento, execução ou entrega. Qual a composição de equipe, mapeamento de tecnologia, boas práticas necessárias, métricas, DoR e DoD, atividades e reservas para start e velocidade;

1.6. Release Plan É a combinação de diferentes técnicas para o planejamento, usando técnicas de estimativa e capacidade baseadas em valor e cronologia. Ao final teremos metas iniciais para cada sprint em relação a construção do produto. Conceitos como Minimo Produto Viável, histórias do usuário e histórias técnicas, culminando com o product backlog, uma lista priorizada e planejada;

2. Game | Sprints | Construção

A construção de software gera produtos e soluções que se perpetuam por muitos anos, décadas, conheço soluções construídas nas décadas de 80 e 90 que ainda hoje sustentam negócios complexos e críticos com sucesso. A maioria delas possui uma documentação excessiva e abrangente, defasada e inevitavelmente comprometida, a psicologia explica, frente a centenas de páginas a maioria acaba rolando e enrolando e fugindo de se atolar e dedicar dias da semana só a isso.

O segredo não é se amotinar, dizer que documentação é do mal, que ela é inútil, porque inútil é o exagero, redundância, complexidade, dificuldade. Como tudo na vida, o equilíbrio é o ideal e em agilidade as retrospectivas precisam fazer seu trabalho, identificar desperdícios e gargalos (Lean), gerar atitude, proposição de melhorias, sempre baseado em fatos e não em paixões e idealizações.

2.1. Para o DoR (Definition Of Ready):

Importante, o registro documental do nosso DoR é rico demais para não receber alguma atenção, talvez um grupo de trabalho que defina o que, como e onde. A documentação de funcionalidades deve ter esta orientação, uma árvore racional que permita rapidamente localizá-la, a orientação para sprints é temporária, a orientação funcional é permanente e deve deter informações cumulativas úteis.

2.1.1. User Stories – Narrativa e critérios de aceite, incentivando o uso de notações. Como <quem><o que><porque> para a narrativa e <dado que><quando><então> para critérios, que representarão de forma atômica diferentes regras, como as de negócio e integração. Uma linha para cada, ao invés de parágrafos embaralhados com várias regras, preferencialmente seguindo BDD.

user stories - sebastien frechina

2.1.2. Protótipos com explicações – Via de regra, na absoluta maioria dos projetos de que participo, materializando a necessidade, exponenciando o papel de um bom UX (user experience), a oportunidade de termos o desenho das telas com diferentes características de navegação e usabilidade, enxuta, simples e objetiva, que norteará de forma efetiva o desenvolvimento melhor possível;

2.1.3. Documento complementar – Diferentes empresas chamam de diferentes nomes, mas é um documento que explicita questões desde regras de integração, SEO, funcionais, alertas ou lembretes que registram questões intrínsecas que poderão gerar problemas futuros se não forem registradas. A regra é bem simples, escreva somente o que precisa escrever, o melhor documento é aquele curto, que explica o que se desconhece, evite explicar o óbvio e já acordado, conhecido (*);

(*) há quem coloque estas informações e regras complementares no mesmo documento da User Story, inclusive o protótipo, e sai por ai dizendo que só usa a User Story e é suficiente … mas só porque está tudo junto não quer dizer que é uma coisa só.

2.1.4. Cenário(s) de testes – Para mim, e é assim que conduzo em todas as empresas por onde passo, a construção pelo menos do cenário principal de testes é essencial. Este cenário fazer parte do DoR é um importante insumo para os desenvolvedores, que os revisarão antes de liberarem a funcionalidade para testes e homologação. Para o DoR eu recomendo garantir o cenário principal, o SQA ou tester pode trabalhar ou não depois os cenários alternativos a seguir;

2.2. Para DoD (Definition Of Done):

2.2.1. Código auto-explicado – Seguir boas práticas de engenharia de software, potencializada por conceitos básicos de aprimoramento do código gerado como paterns, pair programming, code review em suas diferentes formas. O código gerado por equipes ágeis e conscientes de tudo o que falei acima, esforçam-se para gerar código limpo, legível, componentizado, boa OOP;

2.2.2. Testes automatizados – O uso de boas práticas como BDD com o uso de ferramentas para geração de testes, TDD ou pelo menos testes unitários, testes funcionais. Todas estas boas práticas geram informações e conhecimento rastreável e seguro, vivo, que se mantém atualizado sempre. Bem feitos são um manual dinãmico e explicativo orientado a comportamento e engenharia;

2.2.3. Versionamento e integração contínua – A ideia é seguir uma boa arquitetura e engenharia de software, de forma que crie uma matriz e árvore passível facilmente de ser conhecida a partir de sua navegação. O uso de boas ferramentas integradas geram baixo custo de assimilação, facilita troca de responsáveis, acelera novos integrantes, pesquisas e mesmo refatoração;

2.2.4. Gestão de configuração – É uma prerrogativa inalienável a qualquer equipe, na minha opinião quaisquer scripts ou ações relacionadas a promoção daquilo que está sendo feito carece registro, aglutinação e versionamento. Algumas empresas de diferentes tamanhos deixa esta atribuição a tarefas manuais e pessoais, um erro que gera riscos e impede agilidade em ocorrências;

2.2.5. Métricas, indicadores e Status Report – O uso de boas práticas em métricas também envolvem métricas técnicas e indicadores, que devem ser escolhidos com cuidado, como as taxas de cobertura citadas acima, mas também de softwares responsáveis pelos builds e integração contínua, SONAR, a maioria são automatizadas a partir de scripts e mapas apresentados nas Sprints Review, acompanhando entregas e seus status report.

Cada um dos itens acima em teoria foram construídos dentro do próprio processo e mantidos atualizados, após o projeto encerrado é preciso mantê-los vivos, o que demanda mínimo esforço, quer em uma ferramenta ALM robusta, sharepoint, confluence, na dúvida se isso é possível, me manda uma msg …

Manual – Amaldiçoado por muitos, mas ainda úteis em casos específicos como software de prateleira, quer manuais físicos ou virtuais, conforme negócio. As vezes na forma de uma apresentação para replicação de treinamentos, as vezes vídeos, esporadicamente manuais em pdf, seguidamente virtuais, acessíveis durante a navegação, sensíveis a contexto. Pelo menos um FAQuizinho rola.