O que é agilidade em negócios? Esta foi a pergunta inicial da Rebecca, provavelmente o principal ponto é fazer entregas mais rápido com mais valor, onde o negócio alcance mais eficiência, com medições constantes de hipóteses, e assim que conseguimos confirma-las, então podemos incorpora-las.
E isso é muito interessante, porque apesar de toda esta ideia envolvida no ciclo de lançamento de um produto, ainda não voltamos a fonte após a entrega para descobrirmos o que fazer em seguida, ou se foi realmente eficiente esta entrega.
Para que isso passe a acontecer, a Rebecca diz que não só é necessária uma preparação em nível de tecnologias, de entrega continua ou construção continua, ainda assim precisamos alinhar e explorar como unir as suas suposições a constância da aprendizagem do ciclos ágeis.
Já se passou o tempo da bola de cristal, agora precisamos tomar decisões fundadas e estrategicamente alinhadas.
O desenvolvimento destes times ágeis, precisam iniciar sua jornada com definições de pronto(DoD), alinhando não só o quão próximo se está de entregar aquela nova funcionalidade ou não. O negócio deve estar sempre alinhado. Rebecca ressaltou que ser ágil é uma questão de princípios! Devemos tê-los sentidos e não forçados. O segundo passo para estes times é a priorização e o trabalho na qualidade interna, porque desta forma refletindo sobre as métricas, intendendo as dependências internas do sistemas ou quão bagunçado ou atrasado estamos. Saber isso poderemos prover mudanças nos lugares corretos, sem receio sobre as mudanças que estão acontecendo, sobre oque irá impactar ou quando a decisão de entrega de uma funcionalidade será impactada pela impossibilidade de acontecer. A Rebecca sugere o uso de métricas para que o time e a equipe de negócio saibam quão bagunçado está o código, as vezes no mundo real existem datas, e precisamos correr para atingi-las, mas não podemos perder a noção de quando as coisas estão ficando ruins.
O terceiro ponto segundo Rebecca para atingir este ambiente produtivo passa pelo aprendizado e aplicação de princípios das arquiteturas evolucionárias. Para seguir nesta tarefa é necessário prestar atenção sobre a testabilidade do código, porque poderemos descobrir e evoluir com menos restrições. Precisamos também prestar atenção no mínimo possível de informações necessários para o funcionamento completo, como endereços e CEPs, não precisamos restringí-los todos, a parte importante desta informação ó CEP.
O quarto ponto é que os times conheçam e compartilhem a ideia de último momento responsável, precisamos saber até quando podemos esperar para tomar aquela decisão, porque quanto mais tempo temos para aprender, maior o número de informações que teremos para tomar nossa decisão. Além disso quanto menos fazemos, menor será o número de restrição. A Rebecca não sugere que sigamos um modelo de BDUF, mas que tomemos a decisão no momento correto e compartilhemos as expectativas de quando precisaremos tomar estas decisões; que sejam tão tarde que tenhamos informações para tomar decisões mais que não tão longe que interfiram nas entregas. A arquitetura evolutiva é a base para este momento, porque só assim poderemos trocar partes no momento que foram corretos.
O quinto ponto é a entrega contínua(continuous delivery), ou seja ter o código fonte sempre pronto para ser entregue e ser jogado em produção. Para fazer isso precisamos fazer com que as entregas sejam menores e mais constantes, assim não teremos grandes impactos em questões de treinamento e de aprendizagem, aprender/ensinar aos poucos é bem mais eficiente e lucrativo do que em uma única vez. Depois temos que automatizar tudo, todos os níveis de teste, de construção(build) e de lançamento(deploy), mas isso não significa que isto tenha de ser feito sempre sozinho, para Rebecca ter um grande botão vermelho que quando apertado coloquem o código em produção não infringem a noção, definição ou objetivo da entrega constante. Não podemos esquecer que precisamos manter o risco sobre controle, e para Rebecca isso significa uma rede de segurança, que nos mande rápido para frente mas que volte o mais rápido possível para a última versão estável tão rápido quanto.
O sexto ponto começa a envolver os membros do time de Design, e isso tem que estar totalmente alinhado ao sentido continuo de criação(Continuos Design), e transformação da forma de interagir e tratar com a experiência do usuário(UX), precisamos pensar, criar, publicar e despublicar nossas suposições o quanto antes e o máximo possível.
Quando temos todos estes pontos alinhados e resolvidos caímos em um dilema, por que previsão de custo está relacionado com estabilidade, e mudar mesmo que ordenadamente não é sempre assim tão eficiente. Cada empresa tem seu ponto de equilíbrio assim como sua fonte principal de lucro. Então precisamos encontrar este ponto, e separá-las em atividades entregáveis e valorizadas a sua medida.
Uma boa jogada pode ser o inicio do trabalho gerenciado de portfolios, onde cada bloco tem seu valor e podemos pesá-los, medí-los e priorizá-los.
Assim com sistemas realmente adaptáveis, que tenham menos custo e risco para que a equipe de produto possa experimentar mostrando ao termino como estamos com feedback, provavelmente atingiremos melhores resultados que sirvam a toda a organização.