0

Do A3 Report previsto à reinterpretação do Role Model Canvas

Retornei à Curitiba com o briefing de facilitar uma reunião da equipe de staff de uma associação internacional de médicos com foco em ensino, disseminação de conhecimento e melhores práticas. A primeira foi no início de 2017 e contou também com o board latino-americano.

Fui com a intenção de utilizar uma técnica de brainstorming para focar o(s) principal(is) pontos de melhoria e depois usar um A3 Report para instanciar um canvas contendo premissas, planejamento, plano de ação, comunicação e melhoria contínua, mas … chegando lá, mudei.

Estava previsto um alinhamento sobre objetivos, contexto, riscos e oportunidades no dia anterior ao evento. Não Teríamos um planejamento de projeto ou tarefas, mas focaríamos em auto-conhecimento e oportunidades de melhoria em quatro papéis e suas interdependências.

A partir de nossa conversa, me propus a utilizar para cada uma das áreas, envolvendo de dois a três profissionais, uma jornada de auto-conhecimento, reflexão e priorização, para então realizar um exercício de pontos de melhoria e priorização de ações até Janeiro de 2018.

De volta ao hotel, optei por usar um canvas alemão de modelagem de papéis, mas ajustado para focar em processos, fluxos de trabalho e suas oportunidades de melhoria. O canvas (alemão) “Role Model Canvas” foi desenvolvido por Christan Botta (abaixo um dos links, todos alemães).

Não o usei de forma literal, o adaptei a minha necessidade, mas mantive o mérito ao autor. O reinterpretei visualmente de forma a privilegiar o que era para nós mais importante, por isso reorganizei e propus uma abordagem dirigida para preenchimento e abstração, conforme segue:

1º. Missão, antes de mais nada, o que é esperado, resultados esperados, porque de sua existência;
2º. Restrições conhecidas, as principais, tendo surgido algo quanto a alçada, budget, equipe, dependências;
3º. Parcerias essenciais, internas ou externas com quem a área ou processo ou programa conta ou depende;
4º. Informação que lhes são cobradas, métricas, metas, indicadores e quem as solicita ou exige;
5º. Ferramentas, de forma a deixar claro quais são e eventual contextualização;
6º. Trabalho, principais jornadas, procedimentos, com selos de valor, oportunidade e prioridade.

Tivemos duas rodadas, uma com três grupos e depois com dois reagrupamentos. As diferentes áreas de atuação da equipe, sendo ensino, marketing, pesquisa e comunidade, também se optando por discutir um processo (ANA) e um programa específico de ensino;

Na verdade, iniciamos com uma lightning talk e objetivos esperados para o evento conforme o chair do board latino-americano, realizamos um quebra-gelo divertido remetendo a importância da interação e participação ativa de todos, para então fazer uma talk de uma hora com debates.

Durante a primeira hora fiz um overview metodológico, conceitual, debatendo algumas técnicas e métodos de trabalho baseados no Lean e Agile, com bastante interação e contribuições, inclusive relatos do uso de práticas semelhantes em eventos do board internacional.

Assim que decidiram os grupos de trabalho, a primeira rodada encerrou as 13:00, contando com uma apresentação e debate do mapeamento realizado por cada grupo, gerando muita interação, insights e cenários alternativos conforme percepções, conhecimento e vivências de cada um.

A tarde uma segunda rodada, redistribuindo os grupos para mais dois canvas e apresentações. Na sequência, um conceito de clusterização para tópicos mais relevantes, no quadro abaixo ao canvas, tivemos a manifestação dos pontos de melhorias mais relevantes por duplas ou individual.

O mais votado recebeu um exercício ilustrativo de brainstorming em grupo, mostrando o potencial de melhorias, certezas, dúvidas e suposições, concluindo com meia dúzias de ações distribuídas de hoje até Janeiro de 2018 para preparação de propostas de mudanças ao board ou mudar.

A ideai é estabelecer um novo mindset de equipe, baseado em princípios Lean e ágeis, com maior domínio sobre planejamento x execução x aprendizado x replanejamento, baseado em modelos PDCL e muita auto-organização.

Os feedbacks foram positivos, as perspectivas e expectativas são muito consistentes com a necessidade de mudança exigir tempo e esforço, não por deficiências, mas por realismo, em uma equipe que performa e é bem avaliada, introduzindo-se Lean Thinking para melhorar ainda mais.

Links relacionados:

 

0

Lencioni – As 5 disfunções passíveis de medir em um time

O mais famoso livro de Patrick Lencioni (2002) discorre sobre a existência de cinco disfunções a serem trabalhadas para o desenvolvimento de uma equipe de alta performance, um paradigma muito utilizado desde então, desde o meio esportivo ao de equipes em empresas.

Assim como tantas outras teorias e disciplinas que compartilho, ao convergirem aos mesmos princípios e fundamentos que balizam a formação de times ágeis, vem a corroborar metodologias e boas práticas fundamentadas em equipes auto-organizadas.

Parto do princípio de que o uso de uma metodologia ágil não garante a inexistência destas disfunções, mas um time que busca melhorar a partir dos princípios ágeis e o modelo mental cooperativo e colaborativo tende a resolver ou mitigar diariamente eventuais desvios.

É impossível não perceber o quanto cada disfunção tem a ver com princípios e fundamentos Lean, quanto a valor, auto-organização, gemba, kaizen, ainda mais se imaginarmos um time Scrum em seu ciclo contínuo de PDCL, iterativo-incremental-articulado.

Se falarmos de princípios, papéis, timeboxes, regras e artefatos, todos eles convergem para a constante pauta de uma equipe de alta performance, privilegiando confiança, confronto de ideais, comprometimento, responsabilidade coletiva e foco em entrega continuada de valor.

1. Ausência de confiança (Absence of Trust) – Confiança está no topo da pirâmide Lean do grande Samuel Crescêncio, base de qualquer princípio ágil, na transparência com realismo, inexistente se não houver confiança uns nos outros, entre os integrantes do time tanto quanto com todas as partes envolvidas e interessadas. É a base de cada reunião proposta pelo método Scrum, esperando que todos confiem uns nos outros;

2. Medo do conflito (Fear of Conflicts) – É estabelecer sempre uma saudável discussão de ideias a procura da melhor solução, base cíclica para melhoria contínua. É estabelecer objetivos comuns, fugir da zona de conforto e expressar sua opinião de forma positiva, evitar levar qualquer divergência para o lado pessoal, tanto quanto possível usar o aprendizado passado para resignificar e replanejar o futuro;

3. A falta de compromisso (Lack of Commitment) – O planejamento, a execução e resultados são comuns, coletivos, é fugir do status quo onde existe a “sua” parte e tomar consciência coletiva de que somos um time e que o resultado é a soma total de suas partes. É a base de qualquer time de alta performance, times ágeis, participar e sair de qualquer reunião com senso de pertença e compromisso uno;

4. Evitar a responsabilização (Avoidance of Accountability) – Se o resultado é de todos, se é colaborativo, cabe a cada um incentivar, apoiar, contrapôr, ajudar, questionar tudo sempre que necessário, até que a soma de conhecimentos e expertises gere a cada dia o máximo de sinergia possível. É acima de tudo relembrar o engajamento coletivo em seu máximo potencial e resultados, diferente de pressão ou imposição;

5. Falta de atenção aos resultados (Inattention to Results) – Evitar o individualismo, dispersão e desperdício, é comprometer-se do início ao fim a entrega de valor, com qualidade, de forma sustentável, mas privilegiando sempre resultados e entregas significativas. Para isso usamos ciclos iterativo-incrementais-articulados, privilegiando feedback constantes e planos de ação com foco em valor.

Em um modelo mais tradicional de liderança, a opção era estabelecer metas, métricas e monitoramento, durante décadas estabelecer pressão e exigências era a estratégia recomendada. Em Agile o investimento é no desenvolvimento de equipes e pessoas, cerne da auto-organização.

Uma tradução não literal está proposta abaixo:

1. Somos apaixonados e abertos a discussão sobre questões do time.
2. Apontamos deficiências uns dos outros de forma sincera e livre.
3. Sabemos no que colegas estão trabalhando e como contribuem para o todo.
4. Pedimos desculpas imediatas e genuínas entre nós se necessário.
5. Fazemos voluntariamente sacrifícios para o bem do time.
6. Admitimos abertamente nossas fraquezas e erros.
7. As reuniões da equipe são atraentes (não são chatas).
8. Estamos comprometido com as decisões, mesmo com inicial desacordo.
9. A moral é significativamente afetada pela incapacidade de atingir os objetivos.
10. Em reuniões, as questões mais relevantes são colocadas a mesa.
11. Nos preocupamos frente a perspectiva de não poder ajudar nossos pares.
12. Sabemos das predileções uns dos outros e estamos confortáveis em discuti-las.
13. Terminamos as discussões com resoluções e chamadas claras à ação.
14. Os membros da equipe desafiam uns aos outros sobre seus planos e abordagens.
15. O conjunto fica acima do individualismo.

1

Ao iniciar, mapeie seu contexto técnico, humano e metodológico

Um planejamento de Releases é feito em alto nível de abstração, baseado na percepção de complexidade sobre algo minimamente conhecido, mas para fazê-lo com sucesso é preciso estabelecer prévias combinações sobre tecnologia, humanas e metodológicas. No início, mapear quem somos e o que temos, maior será a probabilidade de cumprir entregas de valor. Muitos focam em histórias e Sprints, mas o que mais vejo pegar é pacto de time, transparência, autoconhecimento com realismo, desarmar egos e máscaras.

Usar metodologias ágeis não isenta da responsabilidade com o que está a sua disposição e que faz a diferença. Domínio? Restrições? Riscos? Tecnologia? Mapa de competências e expertise? Oportunidades? Expectativas? Buscar conscientemente o ponto de equilíbrio disso tudo. David Hussman propôs a Lei de Dude [Value = Why / How], se fizermos uma analogia com futebol, para jogar é preciso saber as regras e a mecânica de jogo, habilidades necessárias para montar um time, treinar fundamentos, acima de tudo é um exercício de trabalho em grupo.

dude-s-law

1. Dedique um turno para discutir e explicitar um diagrama de blocos ou mapa de tecnologia, esclareça arquitetura, ferramentas, boas práticas, método, como vocês irão construir software de qualidade e valor, cada opção tem riscos e oportunidades, acelera ou contêm. Isso pode ajudar a planejar Sprint Zero, Provas de Conceito, Spikes, incluir Buffers, parear com especialistas, treinamento, técnicas possíveis e factíveis, enquanto alguns preferem “ter pressa” e mascarar, auto-enganar-se por medo ou arrogância, alguns assumem, outros vão enrolando.

2. De posse de um mapa tecnológico, na forma que for, de blocos, hierárquico, floco de neve, podemos nele próprio identificar riscos e plano para aceitação, mitigação, transferência, o que evitar ou explorar, uma das opções é desdobrar em um mapa de competências. Uma técnica vencedora foca em todas estas competências em um time, quer conhecimentos, habilidades, atitude, cognição, modelos lastreados no interesse em sermos sinceros e realistas com o que somos e sabemos, alimentando planos de ação (use postits pequenos verdes, amarelos, vermelhos).

3. Finalmente, como regra para equipes ágeis que pretendem planejar um projeto, é preciso estabelecer formalmente os acordos sobre os quais balizaremos nossas estimativas e técnicas de planejamento, de forma assertiva sempre, clara, realista. Minha sugestão é o artefato abaixo, um canvas para as combinações iniciais, vivas, que sustentarão o racional para uma inception ou técnica que se escolha para planejamento. O objetivo não é um contrato, mas consenso naquilo que é mais importante, porque tecnologia em projetos também devem ter seu MVP.

Uma dica importante, evite incluir em um mesmo início de projeto novidades demais, se uma equipe idealizar demais assumirá o risco de nada entregar, pode até ser desejável, mas não é responsável. Garanto que as equipes que não procedem desta forma, sempre acabam achando como solução culpar alguém, um arquiteto, gestor, cliente, PO, SM. Não há agilidade que resista a só quando tudo der certo.

Agilidade é antecipar e acordar o que fazer com cada risco e oportunidade, não é disputa nem transferência, é convergência responsável! Um bom quebra-gelo pode ser uma SWOT com a imagem do barco (forças/fraquezas) com o iceberg (riscos) e a ilha (objetivo), desconheço o autor original, talvez o Paulo Caroli, mas eu curto muito a plasticidade da imagem.

 

0

Desculpa, mas agile não é trincheira … pronto, falei!

A maior quebra de paradigma do nosso tempo não é usar design thinking, lean startup ou métodos ágeis, nem Angular, NodesJS ou microserviços, o desafio é termos profissionais mais conscientes, colaborativos, transparentes e realistas.

Mudar de método de trabalho e adotar novas práticas é sim um desafio, porém se não mudarmos o modelo mental e hábitos ancestrais, será tão somente um novo processo de trabalho para servir de zona de conforto, cada um no seu quadrado.

A pergunta não é se somos ágeis, mas se trabalhamos para nos tornarmos equipes de alta performance, porque agilidade é meio, trabalho em equipe, valoroso, colaborativo, sustentável, positivo, os resultados são o fim.

Nossa crença é que esse meio, com ambientes e equipes ágeis, suscitaremos melhores resultados a todos. Sem resultados e valor, sua agilidade não se sustentará muito tempo.

Trincheiras

Mesmo entre aqueles que se dizem ágeis, muitos misturam “reclamação” com transparência, apontar culpados com “eu fiz a minha parte”, “alertam” problemas esquecendo que nosso papel é mitigar, contornar, resolver … ver um problema é só o primeiro passo.

Eu acredito muito na frase “Esperamos que as retrospectivas façam o seu trabalho!” mas, se o resultado recorrente de uma retrospectiva é listar problemas dos outros, não é retrospectiva, é trincheira.

Muitos agilistas reclamam de problemas que eles próprios viram começar, crescer e se estabelecer, apenas assumindo o papel de arautos da verdade dos outros, apontando o dedo e deixando o seu projeto ir pro beleléu, mesmo com opções de contorno.

Construção

Há uma estrada longa para colher o que não plantamos ainda, caso ainda não usemos Lean Business Analisys, DDD, BDD, clean code, XP, DevOps, haverá muito o que fazer e consolidar para aos poucos estabilizarmos nossa realidade.

Muitas vezes eu escuto de equipes que o seu cotidiano é estressante, mas ao averiguar, não é nada além do cotidiano de uma área que lida com a complexidade inerente a software e ao imediatismo no caso de problemas em produção (legados).

Se vamos trabalhar 8 horas por dia em projetos que mexem com os destinos de empresas, áreas, produtos, serviços, mas ainda não temos um bom pack de boas práticas, querer que não hajam momentos de tensão é impossível, temos que saber lidar com eles enquanto evoluímos.

Poupança

Muitas vezes eu comparo uma empresa ou equipe que começa a adotar Agile como alguém que abre uma poupança, teremos que fazer vários depósitos pequenos para hora dessas termos um montante legal … não é imediato.

Projetos e tecnologia é igual, temos um débito técnico gigantesco, legados, falta de boas práticas variadas a cada passo, mesmo assim muitos acham que o simples fato de decretarem que se tornaram ágil esse histórico desaparecerá …

Desculpa aí, mas é o mesmo que um eu de repente decidir usar calça número 39, para isso acontecer vou ter que me empenhar a baixar do 42 para o 39, melhorar hábitos alimentares, academia, retomar os percursos diários de bike.

Adotar Agile para o modelo de fluência do James Shore pode exigir de 4 a 5 anos de dedicação, porque envolve cultura, envolve gente, hábitos, costumes, é preciso crença e dedicação, flexibilidade, jogo de cintura, é preciso ser ágil na agilidade.

Agile é valor entregue

Se há algo errado, propomos alternativas, qual a melhor delas e argumentos, mesmo assim, quem decide as vezes pensa diferente, reclamar e emburrar não é solução, só piora, é preciso tentar fazer dar certo … o que estiver ao nosso alcance!

Toolbox, foco na entrega de valor, o objetivo é sempre buscar uma técnica que melhor enderece, o que pode ser feito para resolver ou mitigar? Se necessário, excepcionalmente, stop the line e replanejar.

Trabalhar em equipe ágil não quer dizer unanimidade de opinião, mas debate e tomada de decisão coletiva e colaborativa … depois é trabalhar nos termos que ficaram definidos, mantendo um ambiente positivo e profícuo.

Quer saber? Gostaria de ser uma mosca e poder assistir incógnito alguns agilistas de boutique se “adaptando” as idiossincrasias de suas empresas, contratos e clientes … porque agilidade na vida real exige muita resiliência até que teoria e prática se encontrem. Agilidade, sustentabilidade e sinergia não são disciplinas que acontecem por decreto … é algo que construímos aos poucos, um passo de cada vez, as vezes para a frente, as vezes para os lados ou mesmo para trás. Ficar idealizando, de mi-mi-mi, só empata mais ainda. Pode demorar anos, enquanto isso, temos que ir lá e fazer, ganhando créditos, avançando, baby steps, menos mi-mi-mi e mais pés no chão por favor!

mosca

Post difícil, tabu, dá vontade de escrever mais 2 laudas, mas até aqui já expressa por alto meu sentimento.

2

Microgerenciamento leva à Paralisia de Análise

De onde saem meus posts? De minha inclinação a filosofia, sexta estava conversando com a Ana Hermann e ela citou o conceito de analysis paralysis em jogos. Acabei dedicando a noite de sexta à leitura, reflexões e derivações que me fizeram refletir sobre microgerenciamento.

“gestão com controle ou atenção excessivos nos detalhes” – Merriam Webster’s

“gestão ou controle com excessiva atenção aos menores detalhes” – Reference.com

“atenção a pequenos detalhes na gestão: controle de uma pessoa ou situação prestando extrema atenção a pequenos detalhes” – Encarta

“A noção de micro-gerência pode ser estendida a qualquer contexto social em que uma pessoa adota uma abordagem agressiva ao nível de controle e influência sobre os membros de grupo. Frequentemente, esta obsessão com os menores detalhes causa uma falha de gestão direta na habilidade de focar nas questões maiores” – Harry Chambers em My Way or the Highway (2004)

Inexiste agilidade lastreada em microgerenciamento, impossível falar de auto-organização e equipes de alta performance sem pressupor liderança ágil e delegação. Microgerenciamento destaca o líder, porque suas equipes acabam sendo dependentes, com medo de errar.

Você já ouviu falar no “Dilema da Centopéia” como alegoria ao equivoco de tentar controlar algo que deveria ser fluido, dinâmico e descentralizado? O cérebro consciente deve decidir sobre a direção, mudanças, não sobre a posição de cada dedo do pé conforme o terreno.

Qualquer controle não deveria impedir que decisões do dia-a-dia sejam tomadas, centralizando decisões de trabalho. Aquelas atividades que deveriam acontecer naturalmente não devem exigir esforço de adivinhação ou auto-proteção, acarretando desperdício de tempo e recursos.

O Dilema da Centopéia

Um poema do século XIX fala de um sapo espertinho que pergunta a uma apressada centopeia que passava ao largo: Qual a próxima pata que ela iria mover? A centopeia faceira ao tentar racionalizar seus movimentos para responder a pergunta, tropeça e cai no charco.

Líderes não deveriam recorrer a microgerenciamento, declarando não confiarem na capacidade de seus liderados, apenas na sua própria decisão. Nestes casos, aos times resta tentar antecipar o que o líder vai decidir ou tropeçar, “cair no charco” com atrasos e retrabalho.

Microgerenciamento

Meu estudo no mestrado usou o modelo Job Strain Model de Karasek, que estabelece trabalho ativo como aquele onde há alta demanda e autonomia do executor sobre a forma como melhor pode realizar, o oposto é trabalho passivo, reduzindo o controle e gerando desperdício.

O microgerenciamento gera trabalho passivo e zona de conforto, mesmo não transparecendo, o foco é entregar aquilo pelo qual vai ser cobrado, evitar riscos e pró-atividade, pois ela pode não ser bem aceita, uma situação que é a antítese de equipes auto-organizadas.

A obsessão por controle cria feudos (silos) e demonstra desconfiança da liderança na capacidade e qualificação de suas equipes em fazer o seu trabalho e tomar decisões cotidianas, gerando um ciclo vicioso de comando-controle, ações reativas, stress, atraso e zona de conforto.

Paralisia de Análise

Chamamos de paralisia de análise situações que poderiam ser fluidas, dinâmicas, seguindo pressupostos e modelos que mostram que profissionais do conhecimento necessitam de espaço e alçada para fazerem seu trabalho da forma melhor e otimizada, ainda mais em equipe.

O overhead gerado por muitos controles e restrições em atividades e tarefas do dia-a-dia gera apenas demora nas tomadas de decisão, coisas simples e imediatas geram tensão e dúvidas, não sobre o que é o melhor, mas o que o gerente espera ou exige de fato naquela situação.

É o oposto dos princípios iterativo-incrementais-articulados propostos pelos princípios e métodos ágeis, baseados em equipes auto-organizadas, até mesmo porque comando-controle e pressão só é eficiente em atividades braçais, repetitivas, onde o capital intelectual não é o diferencial.

Reflita, com o passar do tempo deixamos de ouvir falar sobre CMMI e MPS-Br, enquanto é crescente e onipresente DevOps, Management 3.0, Agile e TI-Bimodal, temos o PMBOK Ed 6 e seu apêndice ágil, estudos cintificos crescentes sobre Agile Governance e Agile PMO – porque será?

 

0

Guia de uso para o SSC – Scrum Setup Canvas – Ed 5

Fiz um manual(zinho) para iniciantes, justificando cada campo do Scrum Setup Canvas, exemplificando estas definições pouco antes da realização de um Release Plan. Elas poderão mudar, mas precisam ser conscientes para embasar o planejamento e execução.

Boa sorte, customize, me avise se fizer alterações pois eu mesmo já o alterei bastante desde a primeira versão, agradeço a oportunidade de melhorá-lo ou pelo menos de saber de variações existentes. Coloquei lá no Dropbox, como fiz com os outros, é só baixar.

Manual do SSC – https://www.dropbox.com
Canvas em A3 – https://www.dropbox.com

  • 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

Clique aqui para assistir a apresentação gravada por colegas no Agile Trends 2017.

 

1

Documentação é inversamente proporcional às suas boas práticas ágeis

O volume de documentação que uma empresa precisa é inversamente proporcional ao número de boas práticas ágeis que pratica, desde a relação de confiança com o cliente, interação entre as pessoas, auto-organização, qualidade, especificação tardia e excelência técnica.

No século XX tínhamos contratos rígidos, escopo prévio, preditivo e extensivo, muita desconfiança, bônus e penalidades, comando-controle e muito tempo em change management. Isso gerava baixa efetividade e qualidade, decorrente do stress e zonas de conforto gerados por isso.

No século XXI temos orientação à relacionamento, equilibrando valor e excelência, buscando eliminar todos os desperdícios visíveis em prol de valor entregue no tempo e custo, com documentação mínima, necessária e viva, valorizando boas práticas em engenharia de SW.

Confiança é a base

A mudança de paradigma faz com que clientes e usuários apropriem-se de seus projetos, participando ativamente ao invés de terceirizar o trabalho com a TI. A TI ao invés de se ver como fornecedor, assume o papel de parceiro, colaborando ativamente para seu sucesso.

O vetor mais relevante é a retirada do teatro das relações interpessoais e comerciais, assumindo-se uma posição cooperativa, mitigando a Lei do Gerson (tirar vantagem), a Lei Ricúpero (enganação), na troca de uma relação pautada na desconfiança por uma de confiança e sinergia.


imagem – http://nathandonaldson.com

Temporário ou Perene

É importante saber distinguir para si o que é documentação temporária ou documentação perene, pois usamos documentos, quadros e mapas mentais no dia-a-dia, a maioria deles de utilidade volátil a medida que o projeto segue adiante, então: Descarte o descartável.

Quanto a necessidade, é preciso entender o problema, ao invés de perguntar o que se quer, usar de empatia para colocar-se no lugar do cliente, usuários, stakeholders e equipe, entender o 5W2H dos desafios, a cada passo, temos um entendimento, alternativas e best choice.

Se você não usa conceitos convergentes, tal como domain driven design (DDD), behave driven development (BDD), Service-Oriented Architecture (SOA), código limpo e auto-documentado, … é pouco provável que documentação mínima e mapas mentais sejam suficiente;

O que vejo por aí? Documento de visão, termo de abertura, inception, casos de usos, histórias do usuário, product backlog, mapa de arquitetura, integrações, regras de negócio, protótipos com principais regras funcionais, plano e cenários de testes, mapas mentais, canvas, etc.

Novos Paradigmas

O método, tanto quanto documentação trabalham para o valor a ser gerado, jamais o contrário. O contrato e combinações é para serem usados como baliza do trabalho do time e partes interessadas, empenhadas em fazer o seu melhor dentro do custo, tempo e escopo-base;

Agile – Planejamento baseado em alto nível de abstração e complexidade, ciclos iterativo-incrementais-articulados, detalhar e tomar decisões no último momento responsável, se a arquitetura e arquitetura for legível, a documentação será mais leve e talvez temporária;

Enxuto – Privilegiar o vital e não o trivial, registrar o óbvio é inútil, foquemos no desconhecido de alto impacto, é desnecessário registrar o óbvio. Quanto mais enxuto e relevante melhor. Valor está no uso e quanto maior, menor o uso, maior o custo relativo e mais rápido caduca;

5W2H – É fundamental mapear entre os envolvidos, racionalmente cada artefato ou documento, a quem ele interessa, qual a alternativa ideal, o que é e porque existe, quanto custa a sua atualização, por quanto tempo será útil, quando deve ser feita e se permanece ou será descartada.

Referências

Há algumas cláusulas pétrias quando falamos de documentação ágil, como YAGNI (You Aren’t Gonna Need It), KISS (Keep it simple stupid), auto-documentação enquanto excelência em engenharia de SW, menor assombro (seguir padrões), DRY (não redundância), garantia de links estáveis, especialização (foco), dependências estáveis, fácil de manter, fácil de encontrar – www.agilemodeling.comwww.smartics.eunathandonaldson.com.

Documentação tem a ver com a cultura da organização, relacionamento e tecnologia, por isso tem a ver com boas práticas ágeis. A regra é trabalhar de forma fluida, sem tanto desperdício, seguindo a máxima de Pareto – Poucos Vitais para muitos triviais.

Conclusão

Sem boa engenharia de software, domain driven design (DDD), behave driven development (BDD), arquitetura orientada a serviços, código limpo e auto-documentado, … é pouco provável que uma documentação mínima e mapas mentais sejam suficientes;

Use o conceito de “Gemba” do Lean, pergunte a quem está onde as coisas acontecem, não faça documentação por idealização de quem não as constrói, mantém ou usa. Documentação boa é documentação útil, ela tem que informar coisas relevantes e serem confiáveis.

Pare de buscar receitas mágicas e aprenda a cozinhar, estabeleça uma discussão sobre sua documentação atual, perenes ou temporárias, se está lendo este post é porque já sabe o suficiente para pensar Lean, experimentar, aprender e melhorar.