Arquivo da categoria: Engenharia de SW

0

Planejamento – Quase sempre as preliminares são cruciais

|

Há alguns anos eu propus e uso de um canvas para pré-inception, entretanto, não é só em software que esta abordagem faz sentido, isso vale para a vida. O canvas em questão é o SCRUM SETUP CANVAS, destinado a materializar, debater ou refletir sobre questões básicas relacionadas ao planejamento de um software corporativo.

Há exceções, reunir um grupo de pessoas para discutir um projeto de software em uma organização pode seguir um viés de inovação tal que não temos nem ideia de qual a tecnologia, quem serão as pessoas envolvidas, metodologia, bem como arquitetura ou plataforma … mas essa não é a regra, nem para tecnologia, nem boas práticas.

Em 95% dos projetos que me envolvo há um domínio e tecnologia implícita, usualmente há uma equipe envolvida, há padrões e limitações. Em sistemas financeiro, de RH, logística, varejo, entre outros, a inovação via de regra está nas histórias, nas características, ergonomia, usabilidade, etc.

A tempo, clique no link para acessar o manual com o canvas em A3 para impressão – https://jorgeaudy.com/manual-ssc-scrum-setup-canvas-ed-5/

A Mayra de Souza Machado incrementou alguns campos adicionais relacionados a outras combinações, como times remotos, ajustado a realidade do ZAP em https://medium.com/guma-rs/alinhamento-teamrules-facilita%C3%A7%C3%A3o-agreements-teams-canvas-acordos-do-time-cee832b65ba3

Nem sempre preencho todos os campos, as vezes alguns campos possuem seu próprio quadro ou canvas, como o Elevator Stetement ou um Mapa de Tecnologia, mas a intenção aqui é registrar o contexto metodológico e tecnológico em que o projeto transcorrerá.

Arquitetura e tecnologia

Um amigo meu defende que não vale a pena perder tempo mapeando a arquitetura e tecnologia no início, diz que isso deve acontecer conforme o projeto anda e decisões vão sendo tomadas, mas a minha experiência em projetos de software é que poderão haver experimentos, mas sempre temos um mapa amplamente conhecido.

Digo isso, porque frameworks, bibliotecas, linguagem, automação, boas práticas e técnicas influenciam em tudo, desde expectativas, estimativas até a aceitação, algumas vezes já prevendo possíveis variações entre MVP’s e Releases. Normalmente é rápido e muito elucidativo a todos os envolvidos – riscos e oportunidades.

Planejamento Estratégico ou Tático

Sempre que posso, saber quem somos é fundamental, já conduzi várias dinâmicas de planejamento estratégico, portfólio, programas, meu primeiro passo sempre é mapear quem são as partes envolvidas, seu dimensionamento e ao que estão dedicados, se possível, com um mapa de dedicação e portfólio.

Eu chamo estas prévias de aquecimento de sinapses, conheço muita gente que acha que ser inovador é partir de uma página em branco, mas estes casos sempre demoram mais para chegar no ponto de largada e com frequência esquecem coisas importantes que inviabilizarão suas conclusões.

O mais surpreendente e positivo em um bom briefing e combinações sobre o contexto em que estaremos planejando algo é que com frequancia não há um consenso fácil e alguns termos precisam ser pactuados, as vezes, alguém tem que ceder ou decidir para que uma só percepção seja estabelecida coletivamente.

Desperdício

Planejar a revelia de quem somos, o que somos, nossas competências e deficiências, é sinônimo de querer não perder tempo alinhando percepções essenciais, expondo conhecimentos e domínios relevantes, normalmente isso é sinônimo de engavetamento, porque na hora de fazer, surgem questões que foram deixadas de lado.

Para qualquer tipo de planejamento, quer estratégico, tático ou técnico, auto-conhecimento e alinhamento de quem somos e quem queremos ser é fundamental, porque gera uma percepção de realidade e desafios, pontos de atenção e viabilidade. O maior valor é o debate, resultando em um pacto em torno de termos de contexto.

Por exemplo, em Design Thinking se diz que um MVP (Minimum Viable Product) é a intersecção entre algo que é Desejável, Factível e Viável. Logo, é de se pressupor ser importante um bom mapeamento e auto-conhecimento para balizar o que é factível e o que é viável, ou pelo menos o que não é e exigirá mais recursos ou tempo.

0

Diferentes alegorias para Débito Técnico

|

Em meio a um debate sobre Débito Técnico no curso de PSPO no TecnoPUC neste mês de Dez/2018, o Alejandro Olchik da Ionatec compartilhou uma alegoria categórica que merece estar aqui registrada no blog junto a outras que já compartilhei para ilustrar Débito Técnico.

1. Alejandro Olchik e a alegoria do Restaurante

Débito técnico equivale a um restaurante optar por ser mais “ágil” abrindo mão de perder tempo em lavar a louça que suja na cozinha e durante o atendimento, vai chegar uma hora em que não terá mais loça para fazer os pratois ou atender os clientes.

Se não tomar o cuidado de manter a cozinha, louça e instalações limpas, esta decisão oportunista começará a gerar problemas de forma cumulativa e chegará uma hora em que sua operação será paralisada porque de tanto acumular chega-se à inflexão.

2. Ward Cunningan e a alegoria do empréstimo bancário

Ward Cunningham apresentou em 1992 uma metáfora onde o débito técnico de um projeto é como se endividar, decisão que pode acelerar o desenvolvimento e entregas em determinados momentos, mas que deve ser seguido de resgates e quitação.

Sem executar os devidos refatoramentos para reduzir o endividamento, podemos perder o controle e esta dívida não mitigada pode acumular, dívida sobre dívida, colocando em risco todo o projeto.

3. Martin Fowler e seu canvas do Débito Técnico

Eu tenho utilizado uma canvas de mapeamento e planejamento de riscos, quando sob controle é o mesmo canvas – Probabilidade x Impacto. Mas Martin Fowler propõe uma nova perspectiva visual – Domínio (conhecimento prévio) x Risco (prudência).

Fowler propôs um canvas para diagnosticar débito técnico que busca explicitar os fundamentos ou explicações racionais acordadas que o originam, explicitando ser aconteceu(rá) por pressa ou conveniência, um risco calculado ou desconhecido.

4. Neal Ford e a alegoria da Dietzler’s Law

Vale a pena citar Neal Ford da TW, keynote no primeiro dia do Agile Brazil de 2012, ele diz que nós temos 2 usuários, um visível que se beneficia do software que vamos construir e um usuário oculto, que são os próximos profissionais que irão dar continuidade e manutenção futura no software que construímos.

Ele provocou uma reflexão sobre as distrações das abstrações, como a Dietzler’s law sobre o paradoxo de soluções que abstraem e facilitam a construção de uma solução, agilizando resultados iniciais, mas que podem tornar o projeto inviável na reta final, quando exigir especialização ou flexibilidade do framework inicialmente abençoado. Exemplificou alguns que ajudam nos primeiros 80%, dificulta nos 10% seguintes e inviabiliza nos últimos 10%.

5. Uncle Bob e a primazia do Refactoring

Uncle Bob afirma que código de má qualidade NÃO é dívida técnica, a premissa para dívida técnica é uma decisão calculada, uma estratégia não desejável e não sustentável, mas que gera valor antecipado, garantindo uma entrega importante para o cliente, mas sujeito a refactoring.

Este conceito está ligado a boas práticas de engenharia relacionadas à XP (Extreme Programming), a refatoração, ação recomendada como parte importante do processo de desenvolvimento, de forma a ter-se uma visão evolutiva contínua do software.

6. As 8 leis de Lehman (’70)

O conceito de evolução contínua e “refatoração” não é novo, nos anos 70 haviam as 8 leis da evolução de software de Meir Lehman. Com uma abordagem técnica, por 30 anos a Lei de Lehman esteve para o Software do século XX assim como a Lei de Moore esteve para o hardware.

A lei #2 tratava da complexidade crescente e afirmava que se não forem tomadas medidas para reduzir a complexidade do software conforme ele é alterado sua complexidade irá aumentar progressivamente. Deve haver um esforço para reduzir a complexidade final de um sistema enquanto este recebe alterações.

E-Type é um conceito ou categorização proposta por Lehman que caracteriza sistemas que resolvem ou contribuem com um desafio do mundo real, desta forma, sua evolução precisa ser orgânica, conseqüência direta de existir em um mundo real e dinâmico, mutável, evolutivo.

Acordos e estratégias para o Débito Técnico

Débitos técnicos devem ser mapeados e uma estratégia deve ser estabelecida pelo Time Scrum para mitigá-lo permanentemente, eventualmente incorporando-o ao product backlog, sendo reduzido dentro do fator de ajuste ou reserva técnica.

Algumas equipes, após alguns sprints e primeiras entregas, combinam que a cada novo sprint será incluído algo de refactoring, como história ou ocupando um % dedicado a sustentação (reserva técnica).

Alguns desenvolvedores reclamam muito do débito técnico, mas é para ser uma estratégia envolvendo entrega + refactoring, cabe ao time manter explícito em um canvas, mapa ou categorizado no product backlog restante.

Já vi times com uma enorme lista de débito técnico, mas aí a primeira pergunta não é como reduzí-lo, mas porque ele existe, para que serviu plannings, reviews e retrospectivas se esta dívida foi-se acumulando tanto.

Um dos soft skills mais relevantes para um time ágil é a arte da negociação, do poder de argumentação, base para a auto-organização. Afinal, se temos problemas e não sabemos explicá-los, dimensioná-los ou priorizá-los … a culpa não é dos outros.

1

Debate Entre Especialistas – DevOps e Pipeline

|

Um debate com a presença de integrantes da equipe de plataforma e arquitetura da DBServer protagonizaram um debate sobre Pipeline e DevOps na disciplina de Tópicos Especiais em Engenharia de Software do curso de Sistemas de Informação na Politécnica da PUCRS.

Este é o quinto Debate Entre Especialistas de 2018/2, após Domain Driven Design (DDD), Behavior Driven Development (BDD), GP + Scrum Master + PMO + Agile Coach, Product Owner (PO) e por último este sobre DevOps e Pipeline.

O material utilizado está em https://www.slideshare.net/secret/spy80GbsPNOnKg.

3

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

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

0

Impact Mapping & Example Mapping

|

Já havia falado sobre Impact Mapping do Gojko Adzic, um consultor estratégico te TI que ganhou o prêmio Jolt Award de melhor livro de 2012. Eleito como o profissional de testes ágeis mais influente em 2011, seu blog ganhou o Agile Award UK pela melhor publicação on-line em 2010.

A questão não é executar a técnica de Impact Mapping ou Example Mapping para construir nossas histórias, mas o quanto exercícios como esse nos ajudam a estabelecer um mindset focado na necessidade, entendendo as personas, para só depois discutir o como e o que.

Pode até mesmo ser usado como um jogo de quebra-gelo ou aquecimento ao propormos um desafio, talvez usando um brainstorming em busca das mais importantes e valorosas necessidades, para quem sabe fazer um rodízio tipo Dojo ou World Café bem dinâmico.

IMPACT MAPPING (Gojko Adzic)

IM-Adzik

No Impact Mapping, partimos sempre de necessidades e desafios, evitando começar por software e contornando o que não precisa ser feito. É preciso entender cada objetivo e alternativa, este é o primeiro passo, depois teremos PDCL, melhoria contínua em ciclos iterativo-incrementais-articulados.

As principais vantagens inerentes a técnicas colaborativas são baseada em comunicação verbal e visual entre todos os envolvidos em tempo real, gerar modelagem consensuada a partir de diferentes prismas e expertises, mitiga ou remove pressupostos inconsistentes e gera forte compromisso e senso de pertença a todos.

Dito isso, técnicas colaborativas e visuais estabelece fortes “pactos” focados em valor real ao cliente, esclarece uma visão estratégica de seus entregáveis, prioriza explicitamente seus critérios de valor e qualidade, tudo sob uma abordagem iterativo-incremental-articulada, permitindo desenvolver-se em camadas.

impact-mapping-for-startups-4-638

1. O que é Impact Mapping?

  • É um mapeamento de escopo e pressupostos de necessidades;
  • Uma técnica colaborativa tal qual uma User Story Mapping;
  • Um mapa que materializa Quem, Como e Valor frente a Objetivos;
  • Entender os porques, a necessidade primária antes da solução;
  • Identificar o que realmente precisa ou não ser feito.

2. Principais Quesitos dos principais entregáveis?

  • WHY? Para cada Objetivo representado como nodo, abriremos um mapa com quem, como e o que deve ser feito para atingi-lo;
  • WHO? A partir dos objetivos, mapeamos as personas que impactam ou são impactadas na busca por estes resultados;
  • HOW? A partir das personas, ações e comportamentos, tentando entender como podem eles impactar o atingimento dos objetivos;
  • WHAT? Finalmente, o que precisa e pode ser feito, qual a solução a ser entregue ou construída.

3. Benefícios e regras dos mapas de impacto?

  • Entendimento das motivações, causas, meios e desejos;
  • Não se preocupa com priorização e cronologia, mas com valor;
  • É iterativo – módulos, funcionalidades ou histórias do usuário;
  • Estabelece desde o início uma linguagem ubiqua com os usuários.

impact-mapping-for-startups-3-638

EXAMPLE MAPPING (Matt Winne)

Winne propôs uma técnica muito poderosa para a modelagem de histórias a partir de necessidades e comportamentos desejados, estabelendo um diálogo colaborativo para estabelecer e confirmar os critérios de aceitação.

Pode ser feito durante o trabalho de construção do DoR (Definition of Ready) de cada história, em reuniões de refinamento ou no planejamento das Sprints. Certo de que esta modelagem gera muito valor agregado, propôs algo que chamou de Example Mapping:

1. Selecione uma história do usuário por vez, quer seja um exercício ou para a definição do DoR (Definition of Ready), pode ser utilizada em um Sprint Planning, pode ter sido previamente debatido em um refinamento;

2. Inicie sempre pelo compartilhamento daquilo que já se sabe, não é uma técnica para envolver gente demais, é uma técnica para o trabalho de modelagem das nossas histórias. Importante é ter diferentes papéis representados para termos múltiplos prismas e conhecimentos;

3. Queremos estabelecer pertença e entendimento, mas se alguma questão não tem resposta ou é polêmica, registre no cartão de pergunta (rosa) e siga adiante. Importante usar textos simples e imagens, algo que incite a o domínio mínimo suficiente da história;

4. A partir da construção do Example Mapping, é possível pedir para um dos presentes ou pares construirem como cenários Gherkin o mapa de uma história. Importante entender que BDD inicia no mapeamento original e colaborativo dos comportamentos, a automação é consequência.

A cada rodada, não esqueça de praticar Kaizen, estabelecendo eventuais lições aprendidas, melhorando a facilitação e a técnica para as próximas.

0

Comece entendendo e delimitando os domínios

|

Quinta-feira, 19:30 as 21:00, Debate Entre Especialistas sobre DDD (Domain Driven Design) – qual a práticade mercado, acertos e erros, como e por onde começar, como persistir e evoluir.

Ajude compartilhando com sua rede … e se você é um especialista no assunto o convite não é só para assistir, mas esta convidado a agregar seu case e debater com o Antonio Castro, Tiago Totti e Mauro Leal.

Não é um evento teórico, este trio tem muita experiência além de serem estudiosos sobre o assunto – https://www.facebook.com/events/201645133982313/

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