Disciplined Agile Delivery (DAD) vs Scrum vs SAFe

Já abordamos o Disciplined Agile Delivery (DAD) em posts anteriores, e um resumo de como está estruturado – em três fases: Inception, Construção e Transição. Os aspectos de arquitetura e design (Inception) e DevOps (Transição) são alguns dos pontos interessantes do DAD.

Também fornece mais flexibilidade nas recomendações do projeto, através dos melhores processos para cada tipo de projeto (dependendo do que será construído), ao invés de prover um plano prescritivo. O DAD possui quatro modelos de ciclo de vida: agile/basic, lean/advanced, continuous delivery, and exploratory.

Outros frameworks muito conhecidos e utilizados em agilidade são: o Scrum para desenvolver, entregar e manter produtos complexos e o SAFe (Scaled Agile Framework), que sincroniza o alinhamento, a colaboração e a entrega para um grande número de equipes.

Papeis

O DAD atribui o Team Lead como responsável por manter o time focado no cumprimento dos objetivos, remoção de impedimentos e a expertise em processos ágeis. Também inclui o Architecture Owner para decisões e prioridades técnicas. Os papeis secundários geralmente ocorrem em necessidade de escala.

DAD

Papeis primários
• Team Lead
• Product Owner
• Architecture Owner
• Team Member
• Stakeholders

Papeis secundários
• Independent Testers
• Specialists
• Domain  Expert
• Technical Expert
• Integrator

 

 

 

SAFe

Time
• Product Owner
• Scrum Master
• Time de desenvolvimento

Programa
• Product Management
• Release Train Engineer
• System Architect

Large Solution
• Solution Management
• Solution Train Engineer
• Solution Architect

Portfolio
• Lean Portfolio Management
• Epic Owners
• Enterprise Architect

Scrum

Time Scrum
• Product Owner
• Scrum Master
• Time de desenvolvimento

 

 

 

 

 

 

 

 

 

Artefatos

Enquanto o Scrum possui artefatos direcionados ao time (backlog do produto e da sprint, burn down e incremento), o DAD e SAFe são mais abrangentes em relação a perspectiva do projeto.

DAD

• Business and Technology Roadmap
• Initial Requirements and Architectural Vision
• Iteration Backlog

 

 

 

 

SAFe

Portfolio
• Investment Themes
• Business and Architecture Epics
• Portfolio Backlog and Vision

Programa
• Product Roadmap
• Program Backlog
• Architecture Runway
• Business and Architecture Features

Time
• Team Backlog
• Team PSI Objective
• Sprint Goals

Scrum

• Product Backlog
• Sprint Backlog
• Gráfico Burn Down
• Incremento

 

 

 

 

 

 

 

Processos

Em processos, o Scrum também possui uma boa estrutura a nível de time, enquanto o DAD e SAFe são mais abrangentes, por considerarem custos, sincronização entre times e estratégia de priorização de projetos.

DAD

Inception
• Formação de time, visão comum, escopo inicial, estratégia técnica, de custos, riscos e release plan

Construction
• Desenvolver a Potentially Consumable Solution, endereçando necessidades dos stakeholders (e mudanças) considerando a qualidade e uso da arquitetura acordada

Transition   
Deploy e o uso da solução
• Melhorias nos processos, ambientes e infraestrutura

SAFe

Portfolio
• Temas estratégicos, épicos, portfólio e budget aos value streams

Large Solution
• Capabilities, Large Solution (Backlog e Kanban)
e Solution Planning / Demo

Programa
• Features, Program Backlog, WSJF, PI (Program Increment) – System Demos e Inspect and Adapt

Time
• User Stories, Team Backlog, Sprint Backlog e conduzir as Sprints

Scrum

•  User Stories, Sprint Backlog e Sprints (Planning, Daily, Review e Retro) e criação do incremento

 

 

 

 

 

 

 

Por fim, vimos acima uma breve explicação e comparação entre DAD, SAFe e Scrum, que podemos resumir da seguinte forma:

  • DAD: é híbrido entre os métodos existentes e fornece flexibilidade para usar várias abordagens. Considera aspectos de iniciação e implementação (full delivery lifecycle). É people-first, learning-oriented e Hybrid agile.
  • SAFe: é mais prescritivo e fornece uma estrutura em diferentes níveis (time, programa e portfólio) que pode facilitar a transição para uma estrutura ágil, além de ser aplicável a um grande número de times (ágil em larga escala).
  • Scrum: aplicável a times individuais, usado para gerenciar o trabalho em produtos complexos. Consiste de times Scrum associados a papéis, eventos, artefatos e regras.

Service Design e o entendimento do perfil dos consumidores

Dentre as várias definições que encontramos sobre Service Design, o Wikipedia resume  como: “a atividade de planejar e organizar pessoas, infraestrutura, comunicação e componentes materiais de um serviço de forma a melhorar sua qualidade e a interação entre a empresa provedora do serviço e os consumidores.”

Fundamentado em práticas de Design, o Service Design visa o entendimento do perfil dos consumidores (todas as pessoas envolvidas no serviço) e suas necessidades para prover um serviço que atenda as expectativas e tenha relevância a quem utilizar. E assim, baseado em levantamentos (perguntas), cria-se um framework de como o serviço irá funcionar.

Onde está inserido o Service Design?

Enquanto o UI Design foca em como o usuário interage com o produto, o UX Design busca compreender os aspecto emocionais que fizeram o usuário a ter essa interação. Já o Service Design abrange com tudo e todos que interagem na entrega de um serviço.

service-design

 

Estágios do Service Design

Existem diferentes propostas de estágios para Service Design, de acordo com a adaptação ou autor referenciado. Um resumo do que tenho utilizado:

  • Pre-work: envolve a criação dos times, comunicação, objetivos, ground rules e planejamento das atividades.
  • Observation: compreender como os serviços estão sendo utilizados e obter os insights iniciais. Utiliza-se ferramentas de pesquisa, etnografia do público e personas.
  • Understanding/thinking: geração de ideias para cocriar soluções, protótipos, testes e visualizar comportamentos. Técnicas como customer journey mappingprototyping são utilizadas. Também role-playing, roteiros, entre outros, que possibilitem reconstruir um caso de uso do serviço com o máximo de fidelidade.
  • Implementing: implementação e testes. Quais métricas determinam o sucesso? Este entendimento direciona as mudanças necessárias para que o novo serviço seja operacionalizado. A ferramenta de Blueprint (Service Blueprint) é utilizada nesta fase.
  • Maintenance and continuing feedback loop: mesmo após a implementação, continuamente monitorar, aprender e refinar (se necessário) a próxima criação.

Princípios e leituras sobre o Service Design

service-design-thinking O livro This is Service Design Thinking aborda cinco princípios para maximizar a qualidade dos serviços:

  • Centrado no usuário
  • Cocriativo
  • Sequencial
  • Evidenciado
  • Holístico

Livros relacionados

  • This is Service Design Thinking
  • Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers
  • Design Thinking: Integrating Innovation, Customer Experience, and Brand Value
  • Designing for the Digital Age
  • Building Design Strategy: Using Design to Achieve Key Business Objectives

Ferramentas do Service Design

Algumas ferramentas muito utilizadas pelos Designers ou pessoas que estão utilizando o Service Design:

  • Service Blueprints
  • Customer Journey Maps
  • Design Ethnography
  • Value Proposition Canvas
  • Surveys
  • Scenarios

E muitas outras no site https://servicedesigntools.org/tools.

Concluindo

O Service Design mostra-se uma boa opção quando precisamos desenvolver ou otimizar serviços, afim de melhorar a interação com os consumidores, por exemplo aumentar o NPS seria um tema apropriado para ir com o Service Design.

E por que não utilizar o Design Thinking? O Design Thinking coloca o usuário ao centro e auxilia com a abordagem divergente e convergente para resolver problemas. Trata-se de empatia e human centricity, mais utilizada para o entendimento de usuários em particular.

NoOps é aplicável a sua organização?

Em 2011, a Forrester já publicava um artigo sobre NoOps e como a automação de algumas operações – build, deploy, testes, etc. levaria mudanças as equipes de infra, reduzindo a necessidade de interação com outras equipes e até mesmo da redução de recursos, substituídos por estes processos automatizados.

Claro que, após todos estes anos, e com os resultados obtidos pela disseminação do DevOps (foco na colaboração entre os times e automação) nas organizações, vimos que não é simples e tampouco mágica manter uma área de operações “rodando” em automático. E por isso, hoje o drive está muito relacionado ao trabalho eficiente, melhorando os resultados obtidos pela automação e forma de atuação no trabalho.

Agora em 2019, talvez o conceito de que DevOps possui foco em colaboração e NoOps em automação esteja mudando, pois é mesmo possível automatizar todas as tarefas de infraestrutura? E nas práticas DevOps já não existe forte colaboração entre os times mesmo com automação de inúmeros processos?

Aplicabilidade

Neste novo patamar atingido por serviços Cloud, os recursos podem ser abstraídos da infraestrutura subjacente, e as atividades de provisionamento e implantação de infraestrutura agora são gerenciadas por meio de serviços de infraestrutura e plataforma sob demanda.

O NoOps segue então como tendência ao ambiente que seja automatizado e abstraído da infraestrutura, podendo ser gerenciado por equipes menores e eficientes. Torna-se impossível viabilizar operações em grande escala com execução manual de atividades. A Deloitte Insights traz análises de adoção nas organizações.

É então mais recomendável a ambientes de TI homogêneo com pouca diversidade no nível da infraestrutura. O stack diversificado de tecnologia (aplicações e infraestrutura) e o comum histórico das mudanças no nível de infraestrutura (dinâmicas e distribuídas) tornam muito mais complexa a adoção NoOps nestes ambientes.

DevOps e NoOps

DevOps (by Microsoft) “É a união de pessoas, processos e produtos para permitir a entrega contínua de valor aos nossos usuários finais. A contração de “Dev” e “Ops” refere-se à substituição do Desenvolvimento e Operações em silos para criar equipes multidisciplinares que agora trabalham em conjunto com práticas e ferramentas compartilhadas e eficientes. As práticas essenciais do DevOps incluem planejamento ágil, integração contínua, entrega contínua e monitoramento de aplicativos”.

NoOps significa nenhuma operação. O foco é automatizar todas as tarefas de manutenção associadas ao desenvolvimento e à execução de uma solução. Isso não é uma missão simples, mas possível, considerando que os provedores de serviços terceiros podem executar tarefas de implantação, gerenciamento e manutenção, tal como o EKS da Amazon. E assim, não há necessidade de alta interação entre os times para tornar possível a conclusão do trabalho.

Os provedores de nuvem continuam subindo o stack, assumindo muitas tarefas de administração de sistemas, tais como aplicação de patches, backup e gerenciamento de banco de dados, entre outras. 

Fonte: Appdynamics 

Traditional Ops e NoOps

As operações de TI não desaparecem apenas com a adoção de plataformas em cloud  pública. Entre algumas evoluções na gestão operacional:

  • Automação: na maior parte das tarefas operacionais, sendo norma e não mais exceção.
  • Proativo: o uso de informações preditivas orientadas por IA para monitorar e otimizar serviços de TI, para que as equipes de Ops possam se concentrar em iniciativas voltadas para o cliente.

traditional-ops-noops
Fonte: https://blog.opsramp.com/devops-noops

Na prática

Além das considerações de aplicabilidade (citadas anteriormente) em relação a manutenção e ambientes legados, outro ponto de atenção é a absorção de novas atividades aos desenvolvedores. Além do interesse em administrar suas próprias soluções, vale verificar o processo para não gerar gargalos.

Como NoOps é habilitado por tecnologia, existem algumas opções PaaS como Heroku e serviços cloud na AWS e Azure. Serverless computing e replicable infrastructure são também boas soluções para resolver a parte da infraestrutura e as ferramentas tradicionais de implantação.

DevOps, Ikigai, Gamificação e F4P – despertando o propósito no CI/CD

O acordo do time é essencial para alavancar as entregas contínuas orientadas a valor. Como orquestrar então “processos – pessoas – ferramentas” neste contexto? Utilizando conceitos do Ikigai, Gamificação e Fit For Purpose (F4P), este trabalho demonstra como equilibrar o compromisso das entregas com o que gostamos de fazer. Também compartilha os resultados obtidos com a transformação cultural, envolvendo as boas práticas de desenvolvimento, o comprometimento com CI/CD e a gestão ágil.

Link de acesso do material: Agile Trends 2019 – Leonardo Matsumota.

  • Ikigai: contextualização da filosofia e correlação entre o ser humano e seu trabalho, em busca do propósito entre paixão, missão, profissão e vocação.
  • F4P: utilização do F4P Card (adaptado), Fitness Box Score e Matriz (aderência x identidade) para identificar a satisfação dos colaboradores com a empresa.
  • Hard Skill Canvas: traz alinhamento, transparência e melhoria contínua ao time, conhecendo as competências técnicas que o time precisa para os produtos da organização.
  • Engajando CI/CD: senso de pertencimento, cadência e gestão.
  • Gamificação: ampliando as boas práticas com senso de colaboração e conhecimento.
  • Formato de trabalho: Squads, OKRs e camadas de engajamento.

 

SAFe 5.0 – uma prévia do novo Scaled Agile

Com o ritmo acelerado das mudanças nos negócios, as organizações precisam ajustar seus modelos atuais de negócio, habilitando a inovação tecnológica e a entrega contínua de valor aos clientes. Devido à forte concorrência no mercado, os usuários estão cada vez mais exigentes, encontrando várias opções de produtos e ferramentas que auxiliam na hora da compra. As empresas precisam compreender melhor seus pensamentos e atitudes, conectando-se a seus valores.

Se antes, as organizações eram estruturadas com modelos de trabalho a longo prazo, na atualidade, o objetivo é tornar a organização mais flexível a mudanças (capacidade de adaptação rápida) com base na entrega contínua de valor, cultura, pessoas e modelo operacional. Tudo isso resume o conceito do Business Agility.

Na semana de 29/Set à 04/Out aconteceu o Global SAFe Summit 2019, onde foi apresentada a nova versão do SAFe (Scaled Agile Framework), o framework SAFe 5.0. Esta nova versão conecta o propósito do Business Agility, propagando práticas de Lean e Agile a toda organização para habilitar a entrega contínua de valor (citada anteriormente) com produtos e serviços inovadores.

E como ficou o SAFe 5.0? Ele foi estruturado com base em sete competências da Lean Enterprise, consideradas essenciais para implementação do SAFe. Cada competência é formada pelo conjunto de habilidade, conhecimento relacionado e comportamentos que habilitam as empresas no Business Agility. Em resumo, as competências ficaram seguinte forma:

Cinco competências
Introduzidas desde o SAFe 4.6, permanecem, mas com ajustes importantes. São elas:

  • Lean-Agile Leadership: possui foco na mudança organizacional, descrevendo como os líderes conduzem e capacitam indivíduos/equipes a maior produtividade e inovação.
  • Team and Technical Agility: o que as equipes precisam para criar soluções de alta qualidade? Esta competência descreve as habilidades e os princípios e práticas Lean-Agile para obter aumento da produtividade e qualidade.
  • Agile Product Delivery: abordagem centrada no cliente para criar produtos ou serviços de valor.
  • Enterprise Solution Delivery: descreve como aplicar os princípios e práticas Lean-Agile ao processo de desenvolvimento de software.
  • Lean Portfolio Management: visa o alinhamento da estratégia com a execução, aplicando conceitos de Lean e Systems Thinking aos investimentos da empresa.

Duas competências (adicionais)

  • Organizational Agility: descreve como os times otimizam seus processos de negócio (também utilizando Lean Thinking) e estruturam rápida adaptação a mudanças para aproveitar novas oportunidades.
  • Continuous Learning Culture: a promoção da cultura de aprendizado, descrevendo valores e práticas que incentivam os colaboradores a buscar continuamente novos conhecimentos e competências para contribuir com a inovação organizacional.

Outras mudanças

A estrutura anterior (SAFe 4.6) possuía o nível Program Level (coordenação das ARTs – Agile Release Train) e o nível Team (times multifuncionais que construíam e entregavam valor na ART) que foi unificado em um único nível Essential no SAFE 5.0. O nível Essential contém o conjunto mínimo de papeis, eventos e artefatos (agora com o time de negócios fazendo parte do trem) necessários para fornecer soluções de negócios continuamente através das ARTs. Utiliza três competências principais: Team and Technical Agility, Agile Product Delivery eLean-Agile Leadership.

Também adicionado um novo princípio #10 Organize around value que representa a vantagem competitiva na qual a organização pode responder as necessidades dos clientes e soluções inovadoras. Isso exige alta colaboração entre as áreas afim de gerenciar desperdícios, atrasos, dependências e handoffs.

Digital Engagement- Sistema de registro e engajamento

Continuando a abordagem do Bi-modal Gartner, outro conceito importante e mencionado no livro The DevOps Handbook é o Sistema de registro e engajamento. Entre os quatro fluxos de valor estão:

  • Serviço virgem: uma nova iniciativa de software.
  • Serviço abandonado: produtos que já atendem a clientes e estão no mercado há anos.
  • Sistema de registro: centralizados para gerenciar uma única fonte de dados na organização. Contém todo o suporte para a entrega de valor ao cliente . Inclui o gerenciamento dos dados, transações, segurança e privacidade.
  • Sistema de engajamento: interage diretamente com o cliente. Incentivam a interação dos clientes e usuários com a organização por meio de apps, portais colaborativos, etc.

E assim, segundo o conceito de TI Bimodal de Gartner (prática de administrar dois estilos de trabalho separados, mas coerentes: um focado na previsibilidade, o outro na exploração), classifica o sistema de registro e engajamento na seguinte tabela:

Sistema Tipo Bimodal Ritmo de mudanças
Registro Modo 1: fazer direito com foco em estabilidade e confiabilidade Mais lento e costumar ter requisitos normativos e conformidade
Engajamento
Modo 2: fazer rápido com foco em flexibilidade e inovação Mais rápido e permite experimentos em ambientes incertos

Enquanto no sistema de registro, a vantagem é lidar com tarefas burocráticas e demoradas, como conformidade, segurança e privacidade (por exemplo utilizando a telemetria e automação para gerar as evidências), por outro lado, o sistema de engajamento demonstrará a confiabilidade da inovação em ciclos de entregas rápidos, por exemplo, novas funcionalidades que melhoraram a conversão de clientes em 40% no e-commerce da empresa.

Samoore contextualiza que o engajamento digital certamente inicia com os sistemas de engajamento (as tecnologias que permitem aos usuários interagir com a organização), conectando aos sistemas de registro que mantêm os dados sobre a pessoa e sua história com a organização. Os sistemas de insight por fim executam as análises para apoiar essa individualização e tornar a interação relevante.

Técnicas de estimativas ágeis

Neste post, vamos abordar técnicas de estimativas ágeis, conceitos de planejamento adaptativo e recomendações de uso, baseado nas fases do ciclo de vida de gestão de projeto ágil. Também como prover visibilidade do projeto em múltiplos níveis da empresa.

O planejamento adaptativo, utilizado na gestão ágil, adota um processo contínuo (realizado ao longo do projeto) que oferece mecanismos de atualizações frequentes. Esta flexibilidade permite reduzir os riscos, entregar valor de negócio antecipadamente e maior visibilidade.

waterfall-agil-01

Na iniciação do projeto, as estimativas são feitas em alto nível para apoiar as análises de investimento. E são refinadas continuamente durante todo o projeto. As técnicas de estimativas são colaborativas, e assim, todas as pessoas apropriadas devem ser incluídas no processo.

A maioria das técnicas utilizam unidades relativas, por exemplo o uso de pontos facilita a comparação entre os itens que estão sendo estimados (ao invés de estimar em “dias” diretamente), evitando “prever o futuro”, onde algumas leituras sinalizam que é uma dificuldade do ser humano.

T-Shirt Sizes

Abordagem de estimativa em alto nível para backlog grande com muitos itens a serem avaliados. Os itens são estimados em PP, P, M, G e GG, de acordo com as discussões e decisão comum/colaborativa das equipes. É uma forma rápida de ter uma ideia do tamanho total do backlog.


Planning Poker

Recomendado para estimar user stories (ou das tarefas) em quantidade relativamente pequena de itens (até 10). Os participantes, em geral, realizam votações utilizando a Sequência de Fibonacci. Quando há grande divergência nas pontuações, a votação é repetida até o time obter um consenso sobre a precisão da estimativa. A boa prática é trabalhar com até 13 pontos.


Affinity Mapping

É uma técnica que envolve agrupar os itens em categorias ou coleções similares. Utilizada para garantir que as unidades de story points se mantêm consistentes ao logo de todo o projeto.

A forma de triangulação oferece uma visão comparativa das estimativas e permite verificação. Pode ser uma alternativa quando há um grande número de histórias a serem estimadas, acelerando o processo de estimativas consideravelmente.