Pontos Principais
- Muitas organizações enfrentam uma crise de transformação quando adotam novas formas de trabalhar sem ver os benefícios prometidos
- Tecnólogos e líderes empresariais continuam a falar idiomas diferentes e não estão conseguindo superar as lacunas de comunicação
- Ágil e DevOps são abordagens que apontam na direção certa, mas não vão longe o suficiente - mas é necessário
- Abordagens de projetos não são aplicáveis no mundo em rápida evolução do desenvolvimento de produtos
- O livro Project to Product apresenta o Flow Framework ™ como um meio de resolver esse problema, trazendo as três formas de DevOps, fluxo, feedback e aprendizado contínuo para a organização como um todo
O Dr. Mik Kersten publicou um livro intitulado Project to Product, no qual ele descreve uma estrutura para entrega de produtos na era do software. Com base na pesquisa e na experiência de muitas organizações em uma ampla gama de setores, ele apresenta o Flow Framework™ como uma maneira das organizações adaptarem sua entrega de produtos à velocidade do mercado e se adaptarem à evolução rápida de clientes, mercado, legislações e societais.
O livro pode ser adquirido aqui e os leitores da InfoQ podem acessar um capítulo de amostra aqui.
Mik falou com o InfoQ sobre suas idéias.
InfoQ: Por que você escreveu este livro - qual problema você está abordando?
Mik: Muitas organizações estão enfrentando uma crise de transformação. Direcionalmente, todos sabem que as formas de Ágil e DevOps são o caminho certo. Mas a empresa não está vendo resultados além de pequenas conquistas, a cultura continua sendo culpada, enquanto tecnólogos e líderes de negócios falam linguagens muito diferentes. O livro Project to Product mostra o ponto de vista que ambos os lados querem ter sucesso. Cada um deles quer que suas organizações prosperem e permaneçam relevantes por meio da disrupção e da economia mundial indo para os gigantes da tecnologia. O problema não é a vontade. O problema é que essas organizações estão usando a abordagem errada. O Project to Product introduz o Flow Framework™ como um meio de resolver esse problema, ele traz as três formas de DevOps, fluxo, feedback e aprendizado contínuo para a organização como um todo. Para fazer isso, precisamos de uma nova linguagem que cubra a distância entre negócios e tecnologia.
InfoQ: Para quem é o livro e quem deve lê-lo?
Mik: O principal público do livro são líderes de negócios e tecnologia em grandes organizações cujo sucesso depende de sua entrega de software. Se você já está satisfeito com a velocidade, qualidade e visibilidade de como você constrói software, este livro não é para você. Mas se busca um caminho melhor para a sua organização e sente que as abordagens existentes não estão avançando rápido o suficiente, o Flow Framework™ no Project to Product é algo que você deve examinar.
Note que, quando falo em liderança, não estou me referindo apenas aos gerentes. O livro Project to Product deve ser tão relevante para um colaborador individual que enxerga um caminho melhor para a abordagem da organização quanto à entrega de software, ele ficará frustrado com a incapacidade da organização de suportar esses esforços. Se você se enquadra nessa categoria, espero que o livro revigore você e ofereça uma nova abordagem para buscar apoio para seus esforços e visão.
InfoQ: No livro, você conta uma história sobre visitar uma fábrica da BMW. Como é que um fabricante de veículos automóveis pode fornecer inspiração para mudar a abordagem para construir produtos de software?
Mik: A história do BMW Group veio da minha visita à fábrica de Leipzig. Testemunhei o foco em fluxos e produtos de valor que conectam o negócio e a produção com eficiência e elegância incrível. Percebi então que, se as organizações de TI corporativas pudessem exibir até mesmo uma fração desse tipo de produto e fluxo, poderiam dobrar a produtividade de sua entrega de software. O grupo BMW tem uma perspectiva de fluxo de ponta a ponta e centrada no valor de negócios, é exatamente isso que todo software e organização de TI precisa.
InfoQ: Você diz que muitas das métricas que as organizações usam para mostrar o progresso do trabalho e a entrega do produto não são úteis - por que e quais são algumas equipes de medições alternativas que devem ser usadas?
Mik: O livro Project to Product especificamente chama a medida de atividades como "métricas de proxy", isto é, métricas que não tem foco nos resultados. Por exemplo, o número de equipes que utilizam o Ágil ou o número de implementações por dia são as duas métricas proxy. Isso não quer dizer que eles não sejam úteis para rastrear. Mas eles não informam se você está ou não fornecendo mais valor a seus clientes por meio do software que você está construindo. Pior ainda, a teoria das restrições nos diz que, se você está investindo em algum outro esforço além do gargalo, provavelmente está perdendo seu tempo. Por exemplo, pode ser que as equipes do Agile estejam constantemente esperando por wireframes, mas você não está percebendo que precisa se equipar rapidamente aos projetistas de UX. O Project to Product apresenta quatro métricas de fluxo de ponta a ponta para aumentar as métricas de Agile e DevOps e garantir que você tenha visibilidade de ponta a ponta do que está impedindo o fluxo nos vários fluxos de valor.
InfoQ: Como o "fluxo" pode ser um framework - quais são os elementos-chave da abordagem e como eles se conectam?
Mik: É uma estrutura porque fornece uma maneira prescritiva de organizar e medir sua organização de entrega de software. A estrutura fornece três camadas e um novo princípio de organização chamado Value Stream Network, que permite conectar as ferramentas técnicas, como Jira, ServiceNow e DevOps do Azure, e medir o fluxo de artefatos entre as pessoas, processos e ferramentas correspondentes.
InfoQ: Como isso se diferencia das ideias de Agile e DevOps, as quais parecem estar sendo baseadas?
Mik: O Flow Framework™ baseia-se no aprendizado de Agile e DevOps e não os substitui de forma alguma. Ele se encaixa em abordagens como Scrum e SAFe, que pode ser usado para estruturar sua abordagem para a entrega ágil. Ele depende do DevOps e das práticas e ferramentas de automação que estão sendo implementadas. Mas está em um nível mais alto de granularidade, e destina-se a reduzir a distância entre essas práticas, planejamento e o orçamento do negócio. Uma maneira de fazer isso é deslocar a prática do gerenciamento de projetos como uma forma de gerenciar a entrega de software. Embora seu objetivo seja fornecer um novo tipo de visibilidade da entrega de software, isso é feito de forma a colocar o poder nas mãos das pessoas que realizam o trabalho nos fluxos de valor do produto.
InfoQ: Você faz um ponto particular de que o mapeamento do fluxo de valor não é uma técnica particularmente útil para identificar a sequência de handoffs em um ambiente de desenvolvimento de software, por que isso ocorre e qual a alternativa?
Mik: Realmente acredito que a prática do mapeamento do fluxo de valor pode ser aplicada à arquitetura. No entanto, indico que tentar criar um mapa de fluxo de valor linear de entrega de software é fútil. A entrega de software é uma atividade colaborativa e criativa que é melhor representada por uma rede, não pelo tipo de entrega em lote que vemos em uma linha de montagem. Nossos fluxos de valor de produto se parecem muito mais com uma rede de linhas aéreas, uma que resiliente a interrupções em um nó, mas muito mais suscetível a problemas com filas e atrasos. É por isso que enfatizo a necessidade de focar na arquitetura do fluxo de valor para permitir a otimização do fluxo e das dependências por meio dessa rede.
InfoQ: Estas ideias aplicam-se fora do fornecimento de produtos de software?
Mik: Teoricamente, algumas dessas idéias poderiam ser aplicadas a outras atividades de trabalho de conhecimento altamente complexas e colaborativas. Mas não pensei muito nisso, todo o meu foco continuará ajudando o setor a aplicá-los para transformar a maneira como o software é construído.
InfoQ: Quão dependente de ferramentas é essa abordagem - as organizações precisam ter conjuntos de ferramentas específicos?
Mik: O Flow Framework™ é totalmente agnóstico em relação a ferramentas. Você poderia usar qualquer uma das dezenas de ferramentas populares de Agile e DevOps para implementar sua Rede de Ferramentas. Qualquer produto do Value Stream Management poderia ser usado, como o Tasktop ou equipes internas para conectar e inspecionar essa rede. O ponto principal do Flow Framework ™ e seus conceitos é que você está pensando em uma camada mais abstrata que a cadeia de ferramentas e se concentra em como você fornece o fluxo e o feedback necessários para permitir que suas equipes criem um ótimo software.
Sobre o autor do livro
Dr. Mik Kersten passou uma década criando ferramentas de desenvolvimento de software livre antes de perceber que a programação não era o gargalo da entrega de software em grande escala. Desde então, ele vem trabalhando na criação de um modelo e de ferramentas para conectar o fluxo de valor de software de ponta a ponta. Ele foi nomeado como palestrante do JavaOne Rock Star e um dos principais escritores do IBM developerWorks Java no top 10 da década. Ele foi selecionado como um dos negócios de 2012 em Vancouver 40 abaixo dos 40 anos e foi finalista do World Technology Awards na categoria de software de TI. Kersten é o editor do novo Departamento de Software do IEEE no DevOps. Em 2018, Mik lançou seu livro, Project to Product, introduzindo o Flow Framework™, com conceitos para ajudar a impulsionar o software no ritmo dos negócios da organização.