Rafa Nascimento

Manifesto para Transformação Ágil

Posted in mudança by Rafa Nascimento on 19/05/2013

Imagem

Um dos maiores desafios de consultorias e departamentos de TI hoje em dia é a transição de um paradigma tradicional de gestão e desenvolvimento de software pautado no Waterfall para o paradigma Agile. Como já vimos em um post anterior, não há mudança rápida e fácil quando lidamos com a cultura corporativa. Em 5 anos de experiência e observação usando métodos ágeis para gerenciar projetos e desenvolver software, ajudando empresas a aprender métodos ágeis e a iniciar seus processos de transição para um paradigma de desenvolvimento de software mais ágil, apresento-lhes um padrão que percebi e eu mesmo venho aplicando recentemente para auxiliar no processo de transição de paradigmas e proporcionar uma transformação cultural mais consistente e menos dolorosa para consultorias e departamentos de TI, além de criar um mindset que permite espalhar o novo paradigma organização/cliente adentro. Abaixo, o Manifesto para Transformação Agile:

Cristalizar, para enxergar os problemas
Conscientizar, para identificar o impacto causado pelos problemas
Educar, para aprender novas abordagens de resolução dos problemas
Experimentar, para confrontar as novas abordagens com a realidade
Cristalizar, para enxergar os problemas
Adaptar, para adequar a teoria à realidade
Reagir, para sensibilizar e motivar a mudança
Estabilizar, para combater o status-quo
Cristalizar, para enxergar os problemas

Quando escolhemos mudar o paradigma da nossa equipe, departamento ou organização, o primeiro passo que precisamos dar é o de Cristalizar o ambiente, com o objetivo de enxergar os problemas que residem no processo e no ambiente. Sem saber que problemas existem no nosso ambiente, não há motivos para promover uma mudança. Independente das práticas que serão utilizadas para visualizar os problemas que queremos resolver (Kanban, enquetes, profiling de equipes, etc.), o objetivo deste passo é responder à pergunta: Que problemas existem no meu ambiente/processo?

Com os problemas à vista, ainda não é hora de promover mudanças. Isso porque há um status quo, uma zona de conforto que permite que os problemas sobrevivam. Permite que os problemas assumam o status de “normais” naquele ambiente e assumam um espaço importante entre os valores culturais da organização ou da equipe. É preciso, então, Conscientizar quem compartilha desta cultura e, assim, sensibilizar através do questionamento do status quo atual as pessoas que estão envolvidas na mudança, fazendo com que outros valores também existentes na cultura predominante tornem-se mais importantes do que aqueles que permitem a sobrevivência dos problemas. Isso gera um senso de urgência em prol da mudança. O objetivo deste passo é responder à pergunta: Que impacto os problemas causam às minhas cadeias de valor?

Neste ponto, convencidos de que a mudança de fato é necessária e benéfica, mesmo sem dados que comprovem tal convicção, muitas empresas e equipes optam por já promover a mudança, “na cara e na coragem”, e, obviamente, passam por inúmeros problemas pois não há conhecimento suficiente fundamentando o desenvolvimento de um novo paradigma. É preciso, agora, Educar os envolvidos lna mudanças para que eles agreguem o máximo de conhecimento possível relacionado ao novo paradigma e possam, assim, resistir à tentação de retornar à zona de conforto, onde o conhecimento já está enraizado, “no sangue”. O objetivo deste passo é responder à pergunta: Como posso melhorar meu processo e ambiente?

Quando todos os envolvidos na mudança possuem o conhecimento necessário para que possam seguir em frente com o movimento, é hora de Experimentar a nova abordagem. É hora de adotar novas práticas para resolver problemas, gerenciar projetos e desenvolver produtos. É hora de gerar novos dados que nos ajudem a avaliar como o nosso ambiente está se comportando frente à nova abordagem. O objetivo deste passo é responder à pergunta: As ferramentas que escolhi são as melhores para resolver os meus problemas?

Neste ponto, precisamos Cristalizar novamente o nosso ambiente. Isso porque novos problemas estarão presentes em nosso ambiente, e precisamos enxergá-los para que possamos mitigá-los, já com uma nova abordagem em mãos.

Com os dados colhidos durante a nossa experimentação e os problemas que surgirão frente à nova cristalização, é hora de Adaptar as novas práticas à realidade do nosso ambiente. Agora, todos os envolvidos na mudança tem o conhecimento teórico e prático que permitem que nenhuma abordagem seja deturpada, permitindo uma adaptação à realidade segura e resultados promissores. O objetivo deste passo é responder à pergunta: Como posso manter o valor das ferramentas escolhidas sem engessar minhas atitudes?

Após diversos experimentos e adaptações, que nos geram cada vez mais dados relativos às nossas diversas cadeias de valor, é hora de Reagir. Esse é o momento de confrontar os novos dados, colhidos durante a utilização de uma nova abordagem, e confrontar com os antigos dados colhidos enquanto cristalizávamos o ambiente em seu estado inicial. É o momento de expandir o senso de urgência e contagiar mais pessoas e departamentos perante os resultados provenientes de uma nova abordagem para desenvolver produtos e gerenciar projetos. O objetivo desta passo é responder à pergunta: Meu estado atual é realmente melhor que o meu estado inicial?

Se a reação é bem-sucedida, e há um contágio com a nova abordagem, a mudança ganha um caráter natural e um novo status quo começa a surgir, mas os valores que mantinham o antigo status quo vivo ainda existem e não descansam enquanto não trazem a zona de conforto de volta. Além disso, há o aspecto da “novidade” que começa a dissipar-se, abrindo mais espaço para a a volta do antigo status quo. Neste ponto, considero importante o trabalho de pessoas com um perfil mais controlador, porém, que também tenho o mesmo nível de conhecimento que os demais envolvidos na mudança, e sejam capazes de Estabilizar o novo status quo sem trazer de volta o antigo status quo travestido de novidade. O objetivo deste passo é responder à pergunta: Meu estado atual é realmente consistente?

Por fim, é necessário Cristalizar o novo ambiente e identificar os novos problemas, e passar novamente pelos mesmos passos que ajudarão a promover novas mudanças no ambiente e no processo, ajudando a germinar uma nova cultura de melhoria contínua, suave e indolor.

Baby Steps: os passos mais firmes para a melhoria contínua

Posted in mudança by Rafa Nascimento on 13/11/2012

Comentei neste post sobre a impressão que tenho de que a prática dos métodos ágeis e, principalmente, a transição para uma cultura mais favorável aos trabalhadores da informação, está dando sinais de que está andando para trás. Como uma mola, que estica ao seu máximo e volta com toda a força. Uma reação sistêmica causada pela falta de novos princípios e valores bem enraizados nas empresas. Princípios e valores mais aderentes a uma nova cultura. Princípios e valores que, quando bem enraizados, permitem que uma empresa seja capaz de superar as dificuldades de uma transição cultural. E á isso que representa uma transição para Agile ou Lean. Transição cultural. Diante desta minha impressão, fica a comprovação de que a aplicação de práticas de forma mecanizada fica a mercê de preferências. E se a cultura, a forma de pensar, não muda, o status quo prevalece. E práticas antigas também.

Que fique registrado: quem diz que a transição para uma cultura Agile ou Lean é fácil está mentindo. E nenhum dos profissionais sérios que conheço afirmam tal coisa. Toda mudança corporativa é complexa. Muito mais é uma transição cultural. Porque a cultura emana de pessoas, de comunidades, de sociedades. E o mais importante de tudo: tais mudanças são demoradas. Parece-me que, quando envolvidos em uma transição, em uma mudança, esquecemos de um princípio básico abraçado por uma prática de um dos métodos ágeis mais bem-sucedidos que existem: baby steps, presente na prática de Test-Driven Development (TDD), presente no Extreme Programming (XP).

Baby Steps significam nada mais que “um passo de cada vez”. Ser paciente em prol da qualidade. Ser atencioso e focado em prol da melhoria contínua. Enquanto os orientais, precursores do Lean, pensam em melhoria contínua como uma questão de meses ou anos, nós, ocidentais, pensamos em semanas ou dias. E perdemos os resultados de longo prazo. Perdemos a consistência de uma mdança embasada pela real melhoria contínua. Embasada por baby steps.

Em seu livro An Agile Adoption and Transformation Survival Guide, Michael Sahota adota uma abordagem mais suave para a transição cultural, sugerindo que as empresas devem dar os passos que estejam dispostas a dar e assumir as consequências que estejam dispostas a assumir durante uma transição. Porém, esses passos devem ser firmes, focando em uma transição consistente baseada em novos princípios e valores e que não agridam os resultados.

Em seu livro Leading Change: Why transformation efforts fail, John P. Kotter, especialista em gestão de mudanças, defende: “A maior lição que pode ser aprendida dos casos mais bem-sucedidos de mudança é que o processo de mudança transcorre por uma serie de fases que, no total, exigem uma quantidade considerável de tempo. Pular passos somente cria a ilusão de velocidade e nunca produz um resultado satisfatório.”

Tenho visto cada vez mais times de desenvolvimento e líderes tentando empurrar as mudanças “goela abaixo”, o que gera um resultado de curtíssimo prazo, resistência e estresse. Vejo muita impulsividade no que diz respeito à adoção de métodos ágeis, e um dos resultados mais frequentes de tal impulsividade é a falta de resultados consistentes da transição cultural. E a posterior desistência da empresa que estava, no mínimo, curiosa para analisar o resultado do esforço. Desistência muitas vezes irreversível e geradora de rótulos como “o Scrum não funciona” ou “Agile é para mimar os desenvolvedores”.

Enfim, é preciso muita paciência, disciplina e perseverança quando falamos de qualquer tipo de mudança que envolva pessoas e cultura. Da menor à maior. Porque pessoas são complexas e reagem de diversas formas diferentes aos mais diversos estímulos que o ambiente pode lhes gerar. Cuidado com a sua transição. Cuidado com a sua mudança. Foco nas pessoas, e menos nos processos. E Baby Steps!

Manifesto Ágil, explicado

Posted in ágil, manifesto by Rafa Nascimento on 14/03/2011

Os Valores Ágeis

O importante de compreender sobre os quatro valores ágeis é que enquanto você deve valorizar os conceitos sobre o lado direito, você deve valorizar as coisas do lado esquerdo ainda mais. A boa maneira de pensar sobre o manifesto é que o mesmo define preferências, não alternativas, estimulando um foco em determinadas áreas, mas não eliminando 
em outras. Os valores do Manifesto Ágil são:

Indivíduos e interações sobre processos e ferramentas
Times de pessoas desenvolvem software, e para isso eles precisam trabalhar de forma eficaz – incluindo, mas não limitado, a programadores, testadores, gerentes de projetos, modeladores, e seus clientes. Quem você acha que desenvolveria um sistema melhor: cinco desenvolvedores de software com suas próprias ferramentas de trabalho juntos em uma sala ou cinco pessoas com poucas qualificações, com um processo bem definido, as ferramentas mais sofisticadas, e os melhores escritórios que o dinheiro poderia comprar? Se o projeto for razoavelmente complexo meu dinheiro seria sobre os desenvolvedores de software, e o seu? O ponto é que os fatores mais importantes que você precisa considerar são as pessoas e como elas funcionam juntas, porque se não acertar nisso, as melhores ferramentas e processos serão desnecessários. Ferramentas e processos são importantes, não me interpretem mal, só que eles não são tão importantes quanto trabalhar em conjunto de forma eficaz. Basta lembrar o velho ditado: um tolo com uma ferramenta ainda é um tolo. Como Fred Brooks pontua em “O mítico homem-mês”, isso pode ser difícil para a gestão de aceitar porque eles muitas vezes querem crer que as pessoas e o tempo, ou os homens e os meses, são intercambiáveis.

Software funcionando sobre documentação abrangente
Quando você pergunta a um usuário se ele gostaria de ter um documento de cinquenta páginas descrevendo o que você pretende construir ou o software em si, o que você acha que ele escolheria? Meu palpite é que 99 vezes entre 100 ele vai escolher software funcionando. Se for esse o caso, não faz mais sentido trabalhar de forma que você produza software de forma rápida e, muitas vezes, dando aos usuários o que eles preferem? Além disso, eu suspeito que os usuários teriam uma facilidade maior de compreender qualquer software que você produz no lugar de diagramas técnicos complexos descrevendo o seu funcionamento interno ou descrevendo uma abstração de sua utilização, não é? Documentação tem o seu lugar, por escrito corretamente é um guia valioso para a compreensão das pessoas de como e porque um sistema é construído e como trabalhar com o sistema. No entanto, nunca esquecer que o principal objetivo do desenvolvimento de software é criar o software, e não documentos – caso contrário, seria chamado desenvolvimento de documentação, não seria?

Colaboração do cliente sobre negociação de contrato
Apenas o seu cliente pode dizer o que ele quer. Sim, ele provavelmente não tem habilidades para especificar exatamente o sistema. Sim, ele provavelmente não sabe o que quer de primeira. Sim, ele provavelmente vai mudar de ideia. Trabalhar juntamente com seu cliente é difícil, mas essa é a realidade do trabalho. Ter um contrato com seu cliente é importante, ter uma compreensão dos direitos e responsabilidades de cada um pode formar a fundação do referido contrato, mas um contrato não é um substituto para a comunicação. Desenvolvedores de sucesso trabalham em estreita colaboração com seus clientes. Eles investem o esforço para descobrir o que seus clientes necessitam, e eles educam os seus clientes ao longo do caminho.

Responder a mudanças sobre seguir um plano
As pessoas mudam de prioridades por uma variedade de razões. Conforme o trabalho progride em seu sistema, a compreensão do dono do projeto sobre o domínio do problema e do que você está construindo muda. O ambiente de negócios muda. A tecnologia muda ao longo do tempo, embora nem sempre para melhor. Alterar é uma realidade de desenvolvimento de software, uma realidade que o seu processo deve refletir. Não há nada de errado em ter um plano de projeto, na verdade, eu estaria preocupado com qualquer projeto que não tenha um. 
No entanto, um plano de projeto deve ser maleável, deve haver espaço para mudar conforme a sua situação muda. Do contrário, seu plano torna-se irrelevante rapidamente.

Os Princípios Ágeis

Para ajudar as pessoas a obter uma melhor compreensão do que é o desenvolvimento ágil de software, os membros da Agile Alliance refinaram as filosofias capturadas em seu manifesto em uma coleção de 12 princípios. Estes princípios são:
Nossa maior prioridade é satisfazer o cliente através entrega breve e contínua de software de valor
Por alguma razão, muitas pessoas em TI parecem ter esquecido que o objetivo do desenvolvimento de software deve ser o desenvolvimento de software. Ou, talvez, o problema é que eles pensam que eles precisam definir tudo na frente antes que eles possam iniciar a construção do software, ao passo que uma abordagem evolutiva para o desenvolvimento parece funcionar muito melhor.

Mudanças nos requisitos são bem-vindas, mesmo que tarde. Processos ágeis absorvem mudanças em prol da vantagem competitiva do cliente
Goste ou não, os requisitos vão mudar durante um projeto de desenvolvimento de software. Desenvolvedores de software tradicionais, muitas vezes, adotam processos de gestão de mudanças que se destinam a evitar ou reduzir aumento de escopo, mas quando você pensa sobre isso, estes são realmente processos de prevenção de mudanças, e não processos de gestão de mudanças. Agilistas abraçam as mudanças e, ao invés, seguem uma abordagem de gestão ágil de mudanças que trata requisitos como priorizados em uma pilha, que pode variar ao longo do tempo.

Entregar software funcionando frequentemente, de um par de semanas a um 
par de meses, com preferência para o período de tempo mais curto
Entregas frequentes de software funcionando fornecem aos donos do projeto um feedback concreto, tornando o estado atual de seu projeto transparente e permitindo que eles forneçam um melhor direcionamento ao time de desenvolvimento.

Especialistas de negócio e desenvolvedores devem trabalhar juntos diariamente durante 
todo o projeto
Seu projeto está em sérios apuros se você não tem acesso regular aos interessados. Os desenvolvedores ágeis adotam práticas como manter o cliente no local do desenvolvimento e incentivar a participação ativa do mesmo, além de adotar ferramentas inclusivas e técnicas que permitem que os interessados se envolvam ativamente com o desenvolvimento do software.

Construir projetos em torno de indivíduos motivados. Dê-lhes um bom ambiente e o suporte que precisam, e confie neles para realizar o trabalho
Muitas organizações têm uma visão de que eles podem contratar hordas de 
pessoas relativamente não-qualificadas, dar-lhes uma descrição de processo compatível com CMMI / ISSO que eles vão desenvolver com sucesso o software. Isso não parece funcionar muito bem na prática. As equipes ágeis, por outro lado, percebem que você precisa criar equipes de pessoas que estão dispostas a trabalhar de forma colaborativa e aprender uns com os outros. Eles têm a humildade para respeitar um ao outro e perceber que as pessoas são um fator primário de sucesso no desenvolvimento de software.

O método mais eficiente e eficaz de transmitir informação para um time e dentro de um time é a conversa cara-a-cara
Para um time de desenvolvimento de software ser bem-sucedido seus membros devem se comunicar e colaborar de forma eficaz. Há muitas maneiras de as pessoas se comunicarem em conjunto, e como você já deve ter percebido, a comunicação cara-a-cara em um ambiente de desenho compartilhado (como papel ou um quadro branco) é a maneira mais eficaz de fazê-lo.

Software funcionando é a medida primária de progresso
A principal medida progresso no desenvolvimento de software deve ser a entrega software funcionando que atenda as necessidades mutáveis de seus donos, não alguma forma de mensuração de “valor agregado” com base na entrega de documentação ou na realização de reuniões.

Processos ágeis promovem o desenvolvimento sustentável. Os clientes, 
desenvolvedores e usuários devem ser capazes de manter um ritmo constante 
indefinidamente
Assim como você não pode dar um sprint por uma maratona inteira, você não pode desenvolver software com sucesso forçando as pessoas a trabalhar horas extras durante meses em um determinado momento. Minha experiência é que você só pode realizar trabalho intelectual de alta qualidade intelectual por 5-6 horas durante um dia antes de começar a se cansar. Sim, o resto do dia pode ser preenchido com e-mails, reuniões, discussões informais, e assim por diante, mas a capacidade das pessoas para fazer “trabalho real” é limitada. Sim, você pode ser capaz de fazer um trabalho de alta qualidade a 12 horas por dia, e fazê-lo por alguns dias seguidos, mas depois de algum tempo você esgota-se e tudo o que você tem são 12 horas de um trabalho medíocre por dia.

Atenção contínua à excelência técnica e bom projeto melhoram a agilidade
É muito mais fácil de compreender, manter e evoluir código-fonte de alta qualidade do que é trabalhar com código de baixa qualidade. Portanto, agilistas sabem que precisam começar com um bom código, mantê-lo bom via refatoração, e adotar uma abordagem orientada a testes de forma que eles saibam a qualquer momento que seu software funciona. Nós também adotamos e seguimos diretrizes de desenvolvimento, particularmente orientações de codificação e até mesmo diretrizes de modelagem.

Simplicidade – a arte de maximizar a quantidade de trabalho não feito – 
é essencial
Os desenvolvedores ágeis focam em atividades de alto valor. Nós nos esforçamos em maximizar o retorno sobre os investimentos em TI de nossos clientes, e cortamos ou automatizamos o trabalho pesado.

As melhores arquiteturas, requisitos, e projetos emergem de times auto-organizáveis
Este é um dos princípios mais radicais do manifesto. O Modelo de Desenvolvimento Ágil de Software (AMDD) e o test-driven design (TDD) são os enfoques principais dentro da 
comunidade ágil para garantir o surgimento de arquiteturas, requisitos e projetos eficazes.

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, e ajusta seu comportamento em conformidade
Melhoria do processo de software (SPI) é um esforço contínuo, e técnicas como 
retrospectivas devem ser adotadas para permitir a melhoraria da sua abordagem 
ao desenvolvimento de software.

Escrito por Scott W. Ambler

Referência: http://www.ambysoft.com/essays/agileManifesto.html

Tagged with: ,
%d blogueiros gostam disto: