Chegou a hora para o ALM Lean

O uso de software vem se tornando o "toque especial" na inovação dos negócios. Os softwares de apoio a processos de negócio estão em fase de transição: de algo acessório para algo de importância crítica (I). A entrega de software, para muitas empresas, é um processo de negócio crítico que deve ser integrado, mas infelizmente, muitas organizações são mal equipadas para tratar os ciclos de vida de suas aplicações como algo de importância fundamental para o negócio, frequentemente tratando o processo de entrega de software como uma arte obscura praticada por gente estranha (II). Nesse artigo examinaremos as razões pelas quais as empresas precisam adotar o ALM (Application Lifecycle Management) e o que queremos aprender do pensamento Lean para transformar o ALM de uma abordagem inflexível, cara e dogmática para uma mais apta a reduzir desperdícios e entregar valor mensurável.

As abordagens tradicionais não funcionam

Hoje em dia, a gestão da entrega de software e da manutenção de aplicações nas empresas é feita de uma forma projetizada bastante tradicional. Um projeto é identificado, os recursos então são alocados e o trabalho é feito. O trabalho flui pela linha de produção do desenvolvimento, passando em todo seu caminho pelo levantamento de requisitos, pela análise, desenvolvimento, testes e implantação. Cada área especializada tem seu próprio conjunto de objetivos em que se baseia a gestão. Frequentemente, contudo, os projetos parecem bem sucedidos ao fluir pela produção, mas acabam tendo problemas na hora de serem entregues. Dependendo de em quem se acredita, os projetos de qualquer atividade ligada ao desenvolvimento de software fracassam em pelo menos 15 % das vezes e os desafiados representam pelo menos outros 50 % (III). A realidade é que quanto maior o projeto, maior a chance de fracassar. À medida que os desconhecidos e a complexidade aumentam, torna-se muito difícil otimizar um processo que funciona. Conforme o software flui pela cadeia de valor em termos de inovação de negócio, a complexidade e os níveis de desconhecido aumentam. É da natureza da inovação ter que lidar com os desconhecidos, o que significa que a abordagem tradicional falha das seguintes maneiras:

• O planejamento adiantado requer conhecimento adiantado - Ao se deparar com problemas novos, que a equipe nunca enfrentou antes, é muito difícil criar planos detalhados. Gastar mais tempo para criar planos supostamente melhores não dá bons resultados; a única forma de criar planos melhores é fazer o trabalho de fato e ajustar o plano com base na experiência.
• O negócio não necessita de perfeição, precisa de ação - Processos bem definidos tendem a dar ênfase demasiada na completude, sendo difícil deixar requisitos de lado durante o processo para entregar valor mais rápido. Negócios modernos dão ênfase no time-to-market e em entregar algo no lugar de entregar a perfeição. O negócio trabalha com visão de curto prazo, em geral medindo o valor trimestralmente, o que é bastante diferente da entrega de software que pode ser voltada a projetos em termos de anos, em vez de meses.

Abordagens de Cloud e mobile tornam os sistemas mais complexos

Abordagens tradicionais do desenvolvimento de software tendem a dar enfoque no desenvolvimento customizado. Os softwares totalmente internos da organização podem ser construídos utilizando linguagens de terceira geração. Mas o desenvolvimento de software moderno é muito diferente, com o software sendo montado a partir de um conjunto de serviços. O Mobile junta aplicações web com aplicações locais executando em uma grande variedade de infraestruturas, aumentando, portanto, a complexidade e os riscos. Perde-se controle porque seu software depende de muitas partes que não são gerenciadas por você nem por ninguém conhecido. Assim como ecosistemas na natureza, não se pode gerenciá-los, pode-se apenas observá-los e reagir a eles. Caso seu desenvolvimento de software comece a parecer um ecosistema, a recomendação é:

• Enfoque na visibilidade - Ganhar visibilidade sobre os assets, a estabilidade deles e como são utilizados oferece percepções valiosas sobre quais assets testar, qual a ordem de entrega do software e o risco inerente de certos serviços essenciais. Se um serviço possui uma grande quantidade de defeitos conhecidos, é importante escrever código defensivo ou pensar em utilizar outro serviço.
• Gerencie os trade-offs de forma explícita - No lugar de deixar isoladas as decisões dos engenheiros de software sobre quais assets utilizar ou quais serviços conectar, torne a arquitetura um conjunto de assets visível e gerenciável. As decisões sobre comprar, construir e utilizar precisam ser centrais a qualquer atividade de planejamento.
• Esteja conectado ao ecossistema - É muito fácil utilizar um serviço e nunca mais olhar sua fonte para se manter a par do trabalho mais atual, dos defeitos conhecidos, ou das observações feitas pela comunidade. É importante não ser apenas um consumidor de um produto, mas também um membro ativo de uma comunidade maior. Isso requer que seu processo de desenvolvimento de aplicação seja conectado ao processo da comunidade ou do fornecedor.

O Agile não é suficiente

Para muitas pessoas, a utilização de algum método ágil resolverá esses problemas ao criar uma abordagem flexível com enfoque na equipe para entregar valor. Há alguma verdade nisso (IV); Os métodos ágeis oferecem às organizações um framework que permite às equipes responder às mudanças e entregar valor aos seus clientes. Na realidade, a adoção do Agile não é profunda nem larga o suficiente. Muitas equipes ainda têm dificuldades com os conceitos do Agile, com suas práticas tão diferentes das tradicionais com a qual estão acostumados. E o Agile no nível de equipe é fundamentalmente diferente da adoção do Agile no nível organizacional, no qual o tamanho, a complexidade e os modelos de governança dificultam a adoção. As empresas podem até querer ser ágeis, mas ainda exigem planos detalhados, organizam-se em modelos departamentais e são resistentes à ideia de entregar software frequentemente. Para muitas empresas, "water-scrum-fall" (uma mistura do método cascata com scrum) é a realidade (V). A adoção do Agile é limitada por:

• O desenvolvimento de software está organizado em departamentos especializados - Quebrar a estrutura departamental e descartar modelos organizacionais existentes exige mudanças importantes, o que para muitas organizações centralizadas de entrega de software está além da sua capacidade ou mesmo de sua vontade. Alinhar as equipes ágeis às áreas de negócio requer a criação de novas equipes ou então estruturar a entrega de software de uma forma muito diferente.
• Os "donos do dinheiro" necessitam de detalhes antes dos projetos começarem - Ao enfrentar o clássico dilema de se precisar de conhecimento para planejar e precisar de um plano para obter conhecimento, muitos grupos de entrega de software dependem da análise detalhada de requisitos para determinar o tamanho e o escopo do projeto. Os requisitos frequentemente mudam logo que se começa o desenvolvimento, o que causa um grande atrito entre a equipe ágil e o plano original.
• O trabalho costuma ser uma coleção de projetos - O Agile tem como base a ideia de que equipes auto-gerenciadas, motivadas e talentosas podem resolver qualquer problema, desde que sejam empoderadas para tanto. A realidade é que as pessoas trabalham em diferentes localidades e equipes trabalham em toda sorte de entregas e projetos. O desenvolvimento de software está cada vez mais parecido com uma linha de montagem, em que serviços, muitas vezes de terceiros, são agregados. Esses terceiros não podem ser parte da equipe ágil, pois são de um fornecedor externo, de um projeto de código livre ou de uma parte diferente da sua própria organização.

Uma junção de ALM e Lean parece ser a solução...

Vimos que a abordagem não pode ser meramente ágil e que as abordagens tradicionais não funcionam. O que é necessário é uma abordagem de entrega de software que apoie a melhoria e ao mesmo tempo não considere o Agile como a única forma de se entregar valor. Tal abordagem deveria levar em conta as melhores práticas da gestão, sem deixar de adaptá-las dado o ambiente altamente fluido no qual o software está sendo entregue ultimamente. Chegou a hora para o Lean ALM, ou seja, a aplicação da disciplina da gestão à pratica da entrega de software para adotar o pensamento Lean, uma abordagem com enfoque no aumento do valor e redução dos desperdícios. O Lean ALM irá:

• Considerar a disciplina da entrega de software como um processo chave para o negócio - Para muitas organizações, tomarem ciência de que são uma empresa de software, ou que o software está se tornando uma peça chave em seu negócio, é de extrema importância. Essa percepção exige delas uma abordagem em relação à entrega de software igual à de outros processos chave de negócio. Não se trata de uma busca por mais recursos financeiros, pois é comum que esse não seja o problema, mas de uma busca por mudanças na própria filosofia.
• Oferecer ferramentas para melhorar a entrega de software - O Lean possui uma coleção de ferramentas para ajudar as pessoas a melhorar seus processos. Técnicas como os Cinco Por quês, o Kanban e Gemba; encorajam os praticantes a explorar seus processos de uma forma diferente (VI). Com essa "melhoria no processo", como mais uma KPI(Key Performance Index) para muitas empresas, isso não seria algo inteiramente novo. Para muitas empresas, contudo, exceto uma marcação no projeto como finalizado, não há foco em melhorias mensuráveis. Ao introduzir técnicas e uma organização que apoia e ajuda as pessoas a usá-las, uma organização Lean deveria sempre estar sempre se melhorando continuamente. Melhorias Lean de processo não dão enfoque nos processos, mas sim nas pessoas, ao fornecer técnicas necessárias à entrega de valor e à redução de desperdícios.
• Visualizar a entrega de software como uma série de fluxos - No lugar de dar enfoque nas disciplinas, artefatos ou papéis, pense na entrega de software como um fluxo, ou uma série de fluxos. Ao visualizar os fluxos, é possível entender como o trabalho se movimenta pelo sistema, identificar problemas relacionados ao tamanho dos lotes, filas e desperdícios. Isso significa que a abordagem tradicional, com foco departamental, ou disciplinar, para organizar a entrega de software foi dividida. Disciplinas especializadas ainda existem como parte de um fluxo conectado, não isoladamente.
• Dar ênfase nos resultados - Ter um foco claro nos resultados que fazem sentido para o negócio e para organizações de entrega tem como direção clara. Para muitas organizações, ter um conjunto claro de métricas descrevem não apenas os objetivos para a equipe, mas os resultados desejados. Contudo, muitas cadeias de entrega de software são fragmentadas, com cada grupo tendo suas próprias métricas. O negócio, os analistas de negócio, o desenvolvimento, os testes, operacões etc têm todos métricas claras, mas frequentemente contraditórias. Talvez, a maior discrepância esteja entre o desenvolvimento e operações. Operações é medida por estabilidade, SLAs, mudanças de desenvolvimento, tempo e custo. A tensão tem o objetivo de criar acordo entre as partes para entregar software de alta qualidade a um custo apropriado. Infelizmente, devido ao fato dos trade-offs no desenvolvimento serem difíceis para muitas empresas, a qualidade é a única métrica ativa, o que quer dizer que software de alta qualidade é lançado, mas frequentemente tarde, pobre em features e caro. O movimento de DevOps, não discutido aqui, emergiu como uma resposta direta a essa tensão, levando as empresas a integrar processos, métricas e ferramentas (VII)

I O software está consumindo o mundo

II Um excelente artigo sobre as razões da entrega de software ser tão difícil

III O frequentemente citado relatório sobre fracasso nos projetos é o relatório Standish

IV Existem várias fontes que descrevem como o Agile está melhorando a entrega de software; um artigo do Mike Cohn sobre o relatório CHAOS oferece informações excelentes sobre as taxas de sucesso do Agile

V Cunhei o termo Water-scrum-fall ao trabalhar na Forrester Research.

VI Existem muitos ótimos livros e sites sobre Lean, além de excelentes organizações Lean. Um ótimo ponto para começar é o site do Lean Enterprise Institute

VII Veja mais sobre DevOps no site DevOps.com