0

TecnoTalks – Oficina BDD e Example Mapping

Na 5ªfeira de 25/10 exercitaremos BDD e Example Mapping com a Ana Hermann, uma especialista no assunto e criadora do BDD Warriors, ela fará uma oficina sobre BDD e de Example Mapping do Matt Wynne.

Não haverá transmissão, é uma oficina prática das 19:30 as 21:00 na sala 306 do prédio 32. Quer você seja PO, SM, equipe ou usuário, vale muito a pena! Criei um evento lá no TecnoTalks para registro – https://www.facebook.com/events/873715292819477/

Para esquentar e chegar com perguntas e opiniões:

1. BDD Warriors – https://www.facebook.com/search/top/?q=bdd%20warriors

2. Dá uma olhada no blog do Cucumber sobre Example Mapping – https://cucumber.io/blog/2015/12/08/example-mapping-introduction

3. Também podes dar uma olhada no blog do Steve Tooke – https://cucumber.io/blog/2018/05/23/your-first-example-mapping-session

4. Ou mesmo dar uma assistida no Example Mapping Webinar – https://cucumber.io/blog/2018/02/27/example-mapping-webinar

Debate Entre Especialistas - BDD

0

Debate GP + SM + PMO + Agile Game

Um debate sobre papéis, compartilhando experiência e aprendizados, com profissionais de diferentes vivências e skills, debatendo a atuação de Gerentes de Projetos, Scrum Masters, escritório de projetos e agile coach.

Todos profissionais com participação em grandes projetos, nacionais e internacionais, locais e distribuidos, que atraiu uma galera muito pilhada, sala cheia, muita gente querida, conhecida, que muito contribuiu com boas perguntas e melhores contribuições.

  • Carol Veeck
  • Felipe Diehl
  • Juliano Acauan
  • Willian Ribeiro
0

Pipeline como gestão visual

Esse termo é utilizado em variados contextos, na minha adolescência o usávamos ao discutir sobre Surf, olhando as fotos da revista Fluir, comparando condições do mar com os míticos tubos rápidos, longos e secos, estilosos de Pipeline.

Entretanto, pipeline pode ser uma ferramenta que mostre o fluxo de um processo relevante do cotidiano de áreas e profissionais. Essa abordagem permite a fácil identificação, análise e ações em relação ao andamento, etapas, fluindo em relação ao nosso objetivo.

No RH, por exemplo, temos o pipeline de contratação, é possível explicitarmos em etapas cada passo desde a abertura, divulgação, recepção, avaliação, entrevistas, decisão, documentação, efetivação e integração.

Em vendas, temos análise de mercado, contato, visita, proposta, decisão, minuta, contrato, assinatura, encaminhamento, e assim como no RH, reproduzimos na parede uma visão tática de nosso trabalho.

Outras áreas, como Planejamento, Contratos, Consultoria, Marketing, Eventos, … se beneficiam ao assumir uma abordagem ágil ao materializarem em um quadro sua estratégia, tática e execução. Se falar Kanban eles dizem que não é para eles, mas se falar Pipeline, rola! \o/

Como construir um Pipeline Visual?

Lembre-se que feito é melhor que perfeito, seja ágil, iterativo-incremental-articulado, inicie rapidamente e evolua a cada aprendizado ou retrospectiva.

1. Aquecendo sinapses e conexões – Comece por uma boa técnica sobre “quem nós somos”, “missão”, “o que fazemos”, “como trabalhamos”, se utilizando de alguma das técnicas já compartilhadas e disponíveis no nosso Toolbox, como SWOT, É|Não É, Role Model Canvas, etc;

2. Mapeie seu fluxo de trabalho, foque naquele que queremos modelar no pipeline, como vagas até contratações no RH, como prospects até contratos em vendas, podendo usar Personas, Jornadas, Storytelling, Fluxos de valor, etc;

3. Faça uma checagem do fluxo a luz de passos adicionais de valor significativos a serem explicitados na alçada de “clientes”, parceiros ou “fornecedores”. Isso é importante para não olharmos só para dentro, mas ao fluxo de forma holística;

4. Desenvolva em cada uma de suas etapa mapeadas buscando as tarefas executadas em sua operação, isto permitirá eventualmente não só confirmar o fluxo e a divisão em etapas como alinhar um certo padrão formal ou informal de tarefas x etapas;

5. É muito significativo tentarmos materializar conceitos de WIP (work in progress), tempos médios esperados, baseados em histórico, e Throughput (número de entregas por período) … o que nos oferece cada vez maior auto-conhecimento de nossa capacidade e tática;

6. Registre lições aprendidas em uma linha própria, normalmente a última em destaque, registrando riscos e oportunidades, pontos de atenção. Está alinhado a proposta de regras explícitas do Kanban e ajudarão muito no dia-a-dia;

7. Desde o início explicite suas metas e indicadores, assim o quadro terá um forte apelo a ação, convergência, proporcionando boas reuniões diárias e semanais de alinhamento e geração de micro-planos de ações para maximização de resultados.

Parece muita informação ou em um espaço tão limitado, mas é apenas o caso de usar bom senso e evoluir (Kaizen) permanentemente a cada aprendizado, na prática é como dirigir, no começo parece difícil, mas depois abstraímos e nem percebemos o freio, pisca, acelerador, etc.

0

20/10 – quem ainda não fez o workshop de Toolbox?

Dia 20/10, 13h às 18h, debateremos nossa Toolbox através de 115 boas práticas para profissionais de todas as áreas – carreira, estratégia, modelagem, planejamento, execução, aprendizado, …

Inscrições em http://bit.ly/workshop-TB2010

A participação vale R$250, cada um receberá um kit contendo o tabuleiro e baralho colorido com mais de cem técnicas e boas práticas, certificado de participação, muita interação e aprendizados.

Haverá um email de confirmação do workshop, o quórum mínimo é de 20 pessoas. Uma experiência singular desde a chegada até o final, veja algumas fotos, relatos e conteúdo em http://bit.ly/relato-toolbox

2

DDD – Debate entre Especialistas 2018/2

Quinta-feira, 11/10 das 19:30 as 21:00, três grandes profissionais, um debate singular sobre DDD (Domain Driven Design) na Escola Politécnica promovido pelo grupo TecnoTalks aqui do TecnoPUC e protagonizado por profissionais da DBServer.

Não foi uma aula, mas um debate entre especialistas, um programa que entra em seu terceiro ano, a cada semestre discutindo temas de interesse da galera de desenvolvimento de software, o Antônio Castro, Fabrício Rissetto e Mauro Leal debateram DDD na prática:

  • O que é DDD? Quando usar/Quando não usar?
  • Quem do time deve adotar?
  • Design Discussions
  • DDD é só conceito ou código?
  • Como transformar linguagem ubíqua em código?
  • Design Estratégico e Tático
  • Lógica de aplicação e domínio
  • Como tratar de forma ágil as refatorações do código com sua evolução ao longo do projeto?
  • DDD com linguagens dinâmicas (Ruby, Python,…)
  • DDD com funcional existe?

Durante o debate, interagindo com o Cinttra Souza,  compartilhei alguns links do Martin Fowler e Eric Evans, o Cinttra um do AgileAndart:

2

Em uma hora, como gerar um início consistente = 5-10-15-30

Criei esta técnica com o objetivo de ajudar aqueles grupos que debatem muito desde o início e acabam esgotando o tempo antes de ter uma massa desejada de proposições, porque ao gastar muito tempo no primeiro, segundo, acaba não sobrando tempo pros demais.

Em reuniões propositivas, quer sejam possibilidades para um tema, direcionadores, ideias, projetos, etc, é possível gerar um mapeamento inicial bem consistente em uma hora usando uma técnica de brainstorming que eu chamei de 5-10-15-30.

O utilizei em várias facilitações, sempre que a discussão é sobre um tema ou contexto razoavelmente conhecido, mas com diferentes visões ou necessidades pelos diferentes players, recentemente em um planejamento estratégico 2019.

Os números representam minutos, que somados totalizam 60 minutos, a primeira meia hora garante a criação de uma lista consolidada, a segunda meia hora é suficiente para um rápido debate para manutenção, exclusão e eventuais novos.

É claro que depende de uma acordo inicial e engajamento, mas a técnica ajuda a direcionar de uma forma muito eficiente, operacionalmente falando. Faça o acordo e mantenha os participantes cientes do tempo que transcorre.

Os primeiros 15 minutos não tem debate e visa garantir a maior massa de proposições:

5 minutos – Os primeiros 5 minutos são para descarregar o buffer, cada um gera uma lista em uma folha, alguns já trouxeram listas e lembretes, cinco minutos são suficientes para lembrarem ou organizarem suas necessidades e proposições;

10 minutos – Nos 10 minutos seguintes eles criam os postits, de forma que um primeiro integrante dita a sua lista e um ou mais contribuem redigindo os postits, a cada ítem, os outros vão riscando da sua lista se coincidir. É possível imediatamente colocar palitinhos ou brotoejas para representar quantos propuseram. Assim que o primeiro acabar de ditar sua lista, os outros ditam o que não foi dito nas listas dos outros;

Os 45 seguintes há dois momentos para debate contido e o seguinte com maior tempo aberto:

15 minutos – O grupo debate o entendimento do que ali está, pode ser que algum dos itens lembrou de outro que não foi proposto, se discordam da manutenção de outro, se dois deveriam ser fundidos, um dividido, etc;

30 minutos – em apenas 30 minutos temos uma lista geral organizada, com algum entendimento, agora temos 30 minutos para perguntas e respostas, discutindo ideias e validade, mas já partindo de uma lista consistente;

Para ideias do zero há técnicas variadas como o crazy eight ou o uso da combinação inicial com um 5w2h e depois respostas, um storytelling com How Might We seguido de brainstorming cadenciando respostas, há canvas e direcionadores, mas o 5-10-15-30 é muito efetivo e produtivo em situações mais conhecidas.

Lembre-se que é muito importante quando do convite de participação gerar as provocações necessárias, elas gerarão um start de trabalhos aquecidos por reflexões, pesquisa, debates e talvez materializações prévias …

Recentemente usei em uma facilitação e a técnica foi usada para mapear direcionadores no início da manhã e inicativas no início da tarde, após cada uma delas usamos técnicas diferentes para geração de rankings e alinhar informações complementares.

Na prática o 5-10-15-30 é uma técnica de aceleração, como é o Crazy Eight para ideias, tenho conseguido bons resultados esporadicamente quando a uso  o/

1

11/10 – Debate entre especialistas sobre DDD

É HOJE, quinta-feira, 11/10 das 19:30 as 21:00, três grandes profissionais, um debate sobre DDD (Domain Driven Design) na Escola Politécnica promovido pelo grupo TecnoTalks aqui do TecnoPUC e apoiado pela DBServer.

Não é uma aula, é um debate entre especialistas, um programa que entra em seu terceiro ano, discutindo temas de interesse da galera de desenvolvimento de software, o Antônio, Fabrício e Mauro debaterão temas como:

– O que é DDD? Quando usar/Quando não usar?
– Quem do time deve adotar?
– Design Discussions
– DDD é só conceito ou código?
– Como transformar linguagem ubíqua em código?
– Design Estratégico e Tático
– Lógica de aplicação e domínio
– Como tratar de forma ágil as refatorações do código com sua evolução ao longo do projeto?
– DDD com linguagens dinâmicas (Ruby, Python,…)
– DDD com funcional existe?

https://www.facebook.com/events/873715292819477/

 

A cada semestre rola um programa de Debate Entre Especialistas, convidando não só profissionais de muita experiência para montar um painel ou storytelling sobre um tema de grande interesse, como BDD (Behavior Driven Development), DDD (Domain Driven Design), DevOps e GP em projetos ágeis.

O objetivo é aproximar alunos e profissionais experientes para uma hora de interação, troca de percepções, muito aprendizado vicariante. As contribuições são em 360º, além dos debatedores ou palestrante, a aula é aberta, mesclando alunos com profissionais da comunidade TecnoTalks de empresas do parque TecnoPUC.

Não só em 2018, mas em anos anteriores sempre tive a oportunidade de contar com grandes profissionais, contando com a presença e contribuição do Sr Lincolm Aguiar, Matheus Alagia, Paula Martins, Patrícia Garay, a cada ano conforme o tema e interesse das turmas nas disciplinas de GP e Tópicos Especiais em Engenharia de SW.

Sobre DDD, na apresentação do livro do Evans na Amazon, referência base de quem pratica, temos:

“A comunidade de desenvolvimento de softwares reconhece que a modelagem de domínios é fundamental para o design de softwares. Através de modelos de domínios, os desenvolvedores de software conseguem expressar valiosas funcionalidades e traduzi-las em uma implementação de software que realmente atenda às necessidades de seus usuários. Mas, apesar de sua óbvia importância, existem poucos recursos práticos que explicam como incorporar uma modelagem de domínios eficiente no processo de desenvolvimento de softwares. O Domain-Driven Design atende essa necessidade. Este não é um livro sobre tecnologias específicas. Ele oferece aos leitores uma abordagem sistemática com relação ao domain-driven design, ou DDD, apresentando um conjunto abrangente de práticas ideais de design, técnicas baseadas em experiências e princípios fundamentais que facilitam o desenvolvimento de projetos de software que enfrentam domínios complexos. Reunindo práticas de design e implementação, este livro incorpora vários exemplos baseados em projetos que ilustram a aplicação do design dirigido por domínios no desenvolvimento de softwares na vida real. Com este livro em mãos, desenvolvedores orientados a objetos, analistas de sistema e designers terão a orientação de que precisam para organizar e concentrar seu trabalho, criar modelos de domínio valiosos e úteis, e transformar esses modelos em implementações de software duradouras e de alta qualidade.”