Manifesto Ágil 2.0, será?

Olá pessoas,

Antes de mais nada eu gostaria de agradecer o WordPress, por ceder este espaço para que a gente possa, em alto nível, discutir a gestão de projetos (e demais assuntos) no Brasil… (protocolos e blá blá blás cumpridos, vamos ao que interessa)

Na era da “modinha do momento 2 ou 3.0”, o Manifesto Ágil não poderia ficar de fora… no exato momento em que eu começava a me achar por, após exaustivas reflexões, ter entendido que Indivíduos e Interações deve prevalecer ante a Processos e Ferramentas e que Software Funcionando é melhor que documentação dizendo como ele deveria funcionar… me deparo, nos meus estudos e pesquisas, com uma espécie de Modernização do Ágil. Pois é meu caro… lá se foi o meu pedido de aumento de salário por água abaixo, já que precisarei estudar mais um pouco para consegui-lo.

Mas o que é essa tal modernização do ágil?

Já vi, ouvi e li várias discussões sobre o que é ser ágil… e a definição que julguei mais razoável é a que diz que, para ser ágil, você precisa estar aderente ao que está escrito no Manifesto (Ágil). Como esta definição guarda coerência com a afirmação de que para ser cristão, você precisa seguir os ensinamentos da Bíblia Sagrada — o que concordo ipsis litteris — não tive como refutá-la. Contudo, pergunto aos meus curiosos botões, para ser ágil preciso estar, necessariamente, 100% aderente ao Manifesto, ou só em praticar algum dos valores, como por exemplo, responder à mudança mais que seguir um plano, já estaria eu (e a organização a qual trabalho) ascendendo à um certo grau de agilidade?

Enfim… independente do que você ou eu achamos sobre o que é ser ágil… membros da benfazeja comunidade agilista (ironias à parte), após terem consolidado as transformações que o pensamento ágil vem se propondo a fazer… e sensibilizados, modernamente, com os complexos desafios que a criação de produtos inovadores estão impondo à indústria de software… começaram a refletir sobre como poderiam reverter, o que eles entenderam como a obsolescência da pedra fundamental da agilidade: O Manifesto Ágil, propriamente dito. — Desta “evolução/melhoria” nasceu o Modern Agile, ou o Ágil Moderno… ou ainda o Manifesto Ágil 2.0 como assim, carinhosamente, sugeri no título do post… 🙂

Desta feita… e sem mais papo furado, detalhemo-lo.

Importante: o que você leu até aqui, e o que você lerá daqui em diante, trata-se da minha percepção sobre o tema… sinta-se livre para discordar e a vontade para expor sua visão nos comentários. 🙂

Tornar a Segurança um Pré-requisito (mais que) Indivíduos e Interações…

(Individuals & Interactions »»»» Make Safety a Prerequisite)

Como assim tornar a segurança um pré-requisito? Confesso que em primeira análise, tive que fazer um exercício mental lascado para tentar entender a mensagem por trás deste valor… e a conclusão a que cheguei é que somente quando todos os membros de um time se sentem seguros em modificar quantidade significativa de código, refatorar, integrar continuamente, deployar e falhar (se for o caso) — sem gerar grandes impactos negativos e retaliações — é que pode-se afirmar que este time (como um todo) está sendo ágil de verdade. Concluído isto, não há como discordar deste valor, sem que seja aberto um parêntese para algumas das práticas do XP, das quais me empodero para, novamente, indagar os meus sempre prestativos botões: 1) Como um time pode, de forma segura, entregar valor frequentemente, sem que, por exemplo, a propriedade coletiva de código faça parte do senso comum? 2) Como ter propriedade coletiva de código, sem programação em par? 3) Pra que parear, se não se vê valor em refatoração ou TDD? 4) Como deployar continuamente sem fazer uso de tecnologia que auxilie na segurança e na eficiência desta tarefa?

Se estas perguntas também lhe fizerem sentindo… Indivíduos e Interações só existirão de forma plena, quando a segurança na hora de construir um produto, se torna um pré-requisito¹.

(¹) Recomendo insistentes reflexões sobre este valor a fim de refinar e abstrair ainda mais o seu entendimento.

Entregar Valor Continuamente (mais que) Software Funcionando…

(Working Software »»»» Deliver Value Continuously)

Modern Agile é fortemente orientado pelo Lean Software Development (from concept to cash) de Mary e Tom Poppendieck. Neste sentido, construir software funcionando, com código de qualidade e sem bugs… mas que não agrega valor e que ninguém o utiliza, não passa de meras linhas de código. Não passa de inominável desperdício. É mais ou menos como se um engenheiro da indústria automobilística, desperdiçasse tempo e o dinheiro de sua companhia, projetando um cinzeiro para motocicletas. Neste sentido, software funcionando que não agrega valor é como um cinzeiro em uma moto, não presta para nada… mas, como saber se o software que estamos construindo agrega valor para o usuário? Simples. Entregando valor continuamente e capturando o feedback. 🙂

Encantar Pessoas (mais que) Colaborar com o Cliente…

(Customer Collaboration »»»» Make People Awesome)

Pois é… colaboração com o cliente, pura e simples, não é mais um raciocínio tão moderno assim. Se você tem um cliente e não colabora com ele, recomendo fortemente que você procure um lugar ao sol no permissivo e estável setor público. Lá, e sem generalizar, clientes, muitas vezes, não passam de mero detalhe. Ademais, o que está em voga hoje é encantar pessoas. Encantar, desde quem paga a conta (clientes) e quem constrói um produto (desenvolvedores), até que utiliza este produto (usuários). Há quem diga por aí que, um requisito ou uma features, só poderia ser considerada como tal, após validação e sabatina feita pelos usuários, ou seja, se elas tiverem, efetivamente, encantado os usuários agregando desta forma, valor real. Diz-se que Mr. Steve Jobs era obcecado por encantar os clientes… foi por conta desta obsessão, sistemática, que pudemos conhecer produtos como o iPhone.

Nota: a tradução proposta no site do Modern Agile é Tornar Pessoas Sensacionais. Tomei a liberdade, porém, de mudar para Encantar Pessoas, por entender que o encantar está mais na moda… 🙂

Experimentar e Aprender Rapidamente (mais que) Responder à Mudança…

(Responding to Change »»»» Experiment & Learn Rapidly)

Claro que responder à mudança é importante… não passa pela cabeça de nenhum apaixonado, que mudanças devem ocorrem apenas pelo desejo de mudar. Todavia, você já se perguntou quais fatores orientam suas mudanças? Imposições dos clientes, dos usuários, da organização… ou além disso, você e seu time tem experimentado novas possibilidades (nem que seja para falhar) e aprendido mais rapidamente? Neste contexto, não devemos pensar em mudanças como mudanças de requisitos ou de escopo apenas… necessitamos de experimentar novos designs, novos patterns, novos padrões de arquitetura, novas tecnologias, novas hipóteses e etc etc… pois é dessa miscelânea toda que sairão produtos realmente encantadores.

Concluindo…

A tal modernização do ágil não está vindo para anular tudo o que aprendemos até agora com o Manifesto original. Pelo contrário. Trata-se de uma linha/ponto de vista que pode enriquecer o debate e quem sabe melhorar o que já é bom. É um complemento. Em particular, como de praxe, faço uma leitura bastante positiva deste movimento uma vez que certamente ele ajudará aqueles que, refletindo com a mente aberta, estiverem ansiosos por melhorar os seus processos, por resolver os seus desafios e porque não dizer, por mudar a cultura de sua organização.

Saudações. Ψ