{"id":7154,"date":"2018-01-31T15:50:55","date_gmt":"2018-01-31T17:50:55","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=7154"},"modified":"2018-01-31T18:13:41","modified_gmt":"2018-01-31T20:13:41","slug":"disciplined-agile-framework-primeiras-impressoes","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2018\/01\/disciplined-agile-framework-primeiras-impressoes\/","title":{"rendered":"Disciplined Agile Framework – Primeiras Impress\u00f5es"},"content":{"rendered":"

Escalar \u00c1gil \u00e9 um assunto cada vez mais em voga, especialmente ap\u00f3s quase uma d\u00e9cada de experimenta\u00e7\u00e3o desses m\u00e9todos, j\u00e1 n\u00e3o \u00e9 mais necess\u00e1rio provar que a abordagem d\u00e1 certo. <\/span><\/p>\n

O desafio agora \u00e9 outro: como adaptar os m\u00e9todos adapt\u00e1veis para necessidades, digamos assim, de gente grande? As startups come\u00e7am a crescer e empresas tradicionais percebem a oportunidade. Agile come\u00e7a a chamar a aten\u00e7\u00e3o como um diferencial para o neg\u00f3cio e n\u00e3o apenas mais para TI. Projetos (ou iniciativas) de software isoladas s\u00e3o relativamente simples; Conversar com \u00a0o pessoal de opera\u00e7\u00f5es, auditoria, times remotos, fazer terceiriza\u00e7\u00f5es, gerenciar projetos maiores, ter uma vis\u00e3o hol\u00edstica de programas, portfolio, trazer previsibilidade, alinhar as iniciativas \u00e0s necessidades de marketing e jur\u00eddicas etc. Esses e outros fatores trazem uma complexidade maior que, a princ\u00edpio, os primeiros m\u00e9todos \u00e1geis n\u00e3o eram capazes de responder ou pelo menos n\u00e3o o faziam de maneira muito simples. <\/span><\/p>\n

A pergunta da vez ent\u00e3o era: “como eu escalo isso?\u201d Uma s\u00e9rie de iniciativas surgiram para provar que tal m\u00e9todo escalava e tamb\u00e9m alguns frameworks voltados exclusivamente para escala. Num mapeamento n\u00e3o exaustivo recente, levantei algumas abordagens: SAFe, LeSS, Nexus, Scrum at Scale, o pr\u00f3prio DAD e at\u00e9 mesmo o controverso Case Spotify. Nesse artigo, vou discutir minhas percep\u00e7\u00f5es sobre o Disciplined Agile Framework. <\/span><\/p>\n

De antem\u00e3o, acho honesto informar que minha experi\u00eancia em escalar Agilidade vem de necessidades espec\u00edficas de contextos onde trabalhei: necessidades regulat\u00f3rias (SOX, Basileia etc, PCI entre outros), necessidades de terceiriza\u00e7\u00e3o com times remotos \u00a0e limitadas por requisitos trabalhistas e tamb\u00e9m limita\u00e7\u00f5es impostas por estruturas funcionais r\u00edgidas com alta especializa\u00e7\u00e3o (banco de dados, opera\u00e7\u00f5es etc.). N\u00e3o cheguei a usar o DAD em profundidade e, apesar de ter estudado o framework, n\u00e3o passei por nenhum dos cursos oficiais e n\u00e3o me aprofundei o suficiente para conhecer todas as suas nuances. Esse artigo \u00e9 apenas opinativo. Dito isto, vamos em frente.<\/span><\/p>\n

O DA Framework<\/strong><\/span><\/h2>\n

Segundo a defini\u00e7\u00e3o, O Disciplined Agile (DA) Framework de decis\u00e3o \u00e9 uma estrutura que fornece orienta\u00e7\u00e3o para ajudar organiza\u00e7\u00f5es a simplificar seus processos, de maneira sens\u00edvel ao contexto, dando uma funda\u00e7\u00e3o s\u00f3lida para a agilidade nos neg\u00f3cios.<\/span><\/p>\n

Historicamente, o Disciplined Agile Framework \u00a0nasceu em 2009 como um framework propriet\u00e1rio da IBM, voltado exclusivamente para estrat\u00e9gias de delivery de software, com sua primeira vers\u00e3o “madura” lan\u00e7ada para o mercado em 2012, por ocasi\u00e3o da publica\u00e7\u00e3o do “livro do veleiro”. Mais ou menos na mesma \u00e9poca que o SAFe veio \u00e0 tona. <\/span>Naquela \u00e9poca, ao procurar por vis\u00f5es de agilidade em escala, n\u00e3o eram raras as representa\u00e7\u00f5es do DAD (Disciplined Agile Delivery) como o kernel do SAFe; Enquanto o DAD fava uma vis\u00e3o de como entregar, o SAFe tentava organizar isso em vis\u00f5es t\u00e1ticas e estrat\u00e9gicas. Em 2014 o DAD passou oficialmente para as m\u00e3os do DA Consortium, teoricamente rompendo seus la\u00e7os com a IBM e finalmente, no final de 2017, com a publica\u00e7\u00e3o do DA Framework, o DAD tornou-se independente da vis\u00e3o do SAFe, fornecendo sua pr\u00f3pria abordagem de agilidade para as vis\u00f5es em n\u00edveis de opera\u00e7\u00e3o, \u00e1rea de TI e para a organiza\u00e7\u00e3o como um todo.<\/span><\/p>\n

\"\"<\/p>\n

Escala na vis\u00e3o do DA Framework<\/strong><\/h2>\n

O DA Consortium tem uma abordagem bem pragm\u00e1tica para aquilo que considera escalar \u00e1gil. Ele cita diversos fatores de escala: tamanho do time, distribui\u00e7\u00e3o geogr\u00e1fica, distribui\u00e7\u00e3o organizacional, compliance, complexidade t\u00e9cnica, complexidade de dom\u00ednio. Eu particularmente concordo com essa abordagem pois, dentro da minha experi\u00eancia, s\u00e3o esses os fatores que tendem a complicar o uso do \u00e1gil.<\/span><\/p>\n

\"\"<\/p>\n

O que eu senti falta, ou pelo menos n\u00e3o encontrei de forma t\u00e3o expl\u00edcita, foi uma maneira de endere\u00e7ar especificamente os fatores de complexidade explicitados na teia acima. Como o DA Framework se posiciona como um “framework de decis\u00e3o sens\u00edvel ao contexto”, acho que essas decis\u00f5es poderiam ser mais direcionadas de acordo com um assessment feito com base na escala desses fatores.<\/span><\/p>\n

Um novo Manifesto \u00c1gil<\/strong><\/h2>\n

Uma coisa legal que eu achei na iniciativa \u00e9 a no\u00e7\u00e3o de que a agilidade n\u00e3o deveria ficar restrita \u00e0s necessidades do cliente e nem \u00e0s iniciativas de desenvolvimento de software. Nesse sentido, o DA prop\u00f5e uma evolu\u00e7\u00e3o do Manifesto \u00c1gil.<\/span><\/p>\n

O termo “software em funcionamento” seria substitu\u00eddo por Solu\u00e7\u00f5es Consum\u00edveis, para dar visibilidade de que nem sempre software \u00e9 o que agrega valor para a organiza\u00e7\u00e3o. Nesse contexto, solu\u00e7\u00f5es consum\u00edveis \u00e9 um termo bem mais abrangente, numa primeira iniciativa para expandir a agilidade para al\u00e9m da TI.<\/span><\/p>\n

O termo “colabora\u00e7\u00e3o com o cliente” seria substitu\u00eddo por “colabora\u00e7\u00e3o com stakeholders”, para dar visibilidade de que num contexto corporativo, \u00e9 preciso interagir com uma gama de outras partes interessadas n\u00e3o restritas apenas ao cliente da solu\u00e7\u00e3o. Nesse sentido, a palavra stakeholders \u00e9 bem mais abrangente e ajuda a dar um contexto da complexidade enfrentada nas iniciativas de desenvolvimento das solu\u00e7\u00f5es consum\u00edveis.<\/span><\/p>\n

Particularmente, acho que mais do que as palavras escolhidas para o manifesto \u00e1gil, o que deve ser valorizado \u00e9 o mindset, e nesse sentido, seria desnecess\u00e1ria qualquer evolu\u00e7\u00e3o do manifesto original. Por outro lado, essas pequenas altera\u00e7\u00f5es podem ser interpretadas como uma licen\u00e7a po\u00e9tica para explicar o conceito do DA, e realmente me ajudaram a pegar o tom da proposta.<\/span><\/p>\n

Os 7 princ\u00edpios<\/strong><\/h2>\n

Num aprofundamento dos conceitos por tr\u00e1s do manifesto modificado, o DA prop\u00f5e 7 princ\u00edpios. Esses princ\u00edpios s\u00e3o os direcionadores para a mentalidade que algu\u00e9m buscando escalar a agilidade em sua organiza\u00e7\u00e3o deveria ter.<\/span><\/p>\n

Existe um princ\u00edpio core que faz com que o foco seja mantido nos clientes – “Delight Customers<\/em>” e outros 6 princ\u00edpios que orbitam, ou melhor, habilitam este princ\u00edpio. <\/span>Inicialmente eu achei a ideia um pouco contradit\u00f3ria com o “novo manifesto”, melhor seria se o princ\u00edpio \u00a0fosse “Delight Stakeholders<\/em>“. <\/span>Mas depois eu entendi que \u00e9 preciso colaborar com os stakeholders para no final poder encantar os clientes das solu\u00e7\u00f5es consum\u00edveis. Um outro ponto de desconforto em rela\u00e7\u00e3o a esse princ\u00edpio \u00e9 que em alguns momentos o DA parece defender que o cliente seja surpreendido positivamente. Eu particularmente discordo dessa abordagem de gold plating. Eu sou muito mais adepto \u00e0 gest\u00e3o de expectativas e \u00e0 abordagem de customer success do Lincoln Murphy, por exemplo.<\/span><\/p>\n

Alguns princ\u00edpios como “be awesome, optimize flow e choice is good<\/em>” n\u00e3o definem muito o DA Framework al\u00e9m do que os princ\u00edpios fundamentais do Agile j\u00e1 fazem, por isso n\u00e3o vou entrar muito nos detalhes.<\/span><\/p>\n

Outros princ\u00edpios como Enterprise Awareness, Pragmatism e Context Counts por outro lado, v\u00e3o de encontro \u00e0 ideia principal do framework.<\/span><\/p>\n

Enterprise Awareness<\/em> chama a aten\u00e7\u00e3o para os times das iniciativas de que existe um mundo l\u00e1 fora, e \u00e9 preciso ter consci\u00eancia de que esse mundo impacta a maneira como voc\u00ea trabalha e vice-versa.<\/span><\/p>\n

Context-Counts<\/em> chama a aten\u00e7\u00e3o de que n\u00e3o \u00e9 poss\u00edvel que um framework prescritivo se encaixe em todos os contextos, principalmente naqueles de maior complexidade. Pragmatismo, outro princ\u00edpio, complementa o Context-counts \u00a0no sentido da falta de compromisso com um framework espec\u00edfico, e o princ\u00edpio “choice is good<\/em>” fecha o quebra cabe\u00e7a, fornecendo estrat\u00e9gias para escolher as melhores ferramentas dado determinado contexto.<\/span><\/p>\n

\"\"<\/p>\n

Conceitualmente, a ideia me pareceu bastante consistente, embora na pr\u00e1tica eu n\u00e3o tenha conseguido enxergar muito como isso funcionaria. Por exemplo, o DA vende sua ideia de ser um “agregador de todos os m\u00e9todos”, chegando inclusive a criticar corpos de conhecimento como ITIL e PMBoK. \u00a0<\/span><\/p>\n

\"\"<\/p>\n

Contudo, a parte de “choice is good<\/em>” e a estrat\u00e9gia de utilizar “l\u00e2minas de processo<\/em>” que podem ser escolhidas conforme a necessidade, fazem do DA Framework um grande “AgileBoK”, adotando exatamente a estrat\u00e9gia criticada. O fato de referenciar o PMBoK por PMIBoK e o fato de utilizarem a mesma estrat\u00e9gia criticada denotam uma poss\u00edvel falta de conhecimento dos autores sobre o assunto, \u00a0tornando um pouco fr\u00e1geis seus argumentos de venda.<\/span><\/p>\n

A Big Picture<\/strong><\/h2>\n

\"\"<\/p>\n

Nesse ponto, o DA come\u00e7a a apresentar suas “Disciplinas”, exatamente como fazem os corpos de conhecimento. Eu gosto de corpos de conhecimento, os BoKs da vida, pois acho legal agregar ferramentas e t\u00e9cnicas e permitir sua compara\u00e7\u00e3o. Minha \u00fanica cr\u00edtica, mais uma vez, \u00e9 que fica parecendo que o DA Consortium criou exatamente aquilo que jurou combater.<\/span><\/p>\n

Essencialmente, o Framework atua nos n\u00edveis de entrega, DevOps, \u00c1rea de TI e Organizacional, sendo que originalmente direcionava apenas a parte de entrega.<\/span><\/p>\n

No n\u00edvel de Delivery, a estrat\u00e9gia \u00e9 fornecer fluxos completos de ciclo de vida, com v\u00e1rias estrat\u00e9gias que podem ser escolhidas levando-se em considera\u00e7\u00e3o desde a maturidade do time at\u00e9 mesmo a estrat\u00e9gia de neg\u00f3cios: h\u00e1 sugest\u00f5es de fluxos de agile b\u00e1sico usando Scrum, e at\u00e9 mesmo fluxos explorat\u00f3rios para startups. O que \u00e9 bem legal e pertinente. Tenho visto Agile Coaches for\u00e7ando a barra de processos em cima de times que ainda n\u00e3o t\u00eam \u00a0condi\u00e7\u00f5es de adotar pr\u00e1ticas mais avan\u00e7adas e realmente a abordagem do DA traz essa reflex\u00e3o.<\/span><\/p>\n

No n\u00edvel de DevOps, a ideia \u00e9 discutir boas pr\u00e1ticas na intera\u00e7\u00e3o do desenvolvimento junto com opera\u00e7\u00f5es. As abordagens s\u00e3o bem interessantes, discutem agilidade do ponto de vista de Seguran\u00e7a, Help Desk, Administra\u00e7\u00e3o de Dados, Opera\u00e7\u00f5es e gest\u00e3o de releases. Entretanto, foi ao subir para esse n\u00edvel que fiquei decepcionado, pois, sinceramente, esperava a apresenta\u00e7\u00e3o de uma estrat\u00e9gia para aplica\u00e7\u00e3o de agilidade al\u00e9m da Tecnologia, o que n\u00e3o aconteceu.<\/span><\/p>\n

No n\u00edvel de \u00c1rea de TI, s\u00e3o apresentadas estrat\u00e9gias em n\u00edvel t\u00e1tico e estrat\u00e9gico de gest\u00e3o de tecnologia, assim como a intera\u00e7\u00e3o da \u00e1rea de TI com o restante da empresa. S\u00e3o apresentadas estrat\u00e9gias de gest\u00e3o de pessoas, produtos, portfolio, governan\u00e7a, arquitetura organizacional e engenharia de reuso, contudo, num n\u00edvel bem mais raso do que DAD e DevOps.<\/span><\/p>\n

Finalmente, no n\u00edvel Organizacional (Disciplined Agile Enterprise), a coisa ficou bem confusa pra mim. Minha impress\u00e3o \u00e9 que foram ultrapassados os limites de um framework, invadindo disciplinas como Marketing, Vendas, Financeiro, Jur\u00eddico e Compras, para as quais j\u00e1 existe muito conhecimento e pr\u00e1ticas que foram desenvolvidas ao longo de d\u00e9cadas. Eu esperava que a abordagem simplesmente citasse alguns requisitos, pontos de contato dos outros n\u00edveis mas em alguns momentos o DA Framework. Entretanto, o as diretrizes do DA parecem tentar ensinar para esses departamentos qual \u00e9 o jeito correto de se trabalhar. Resumindo, passou do ponto.<\/span><\/p>\n

Conclus\u00e3o<\/strong><\/h2>\n

Juntando tudo, me pareceu que: <\/span><\/p>\n