Viagens, opiniões e afins

Hoje a moda é dizer que sua empresa é ágil.  Todo mundo agora tem quadro branco nas paredes, um monte de  post-it coloridos espalhados por todos os lados,  etc.  Todo mundo faz Scrum, Kanban, entre outras coisas mais. A questão é quantas empresas de fato são ágeis. Quantas de fato estão trabalhando no sentido de mais qualidade (no produto e na vida dos funcionários)?

A um certo tempo atrás o “mercado”acreditava que deveria padronizar, engessar e burocratizar os seus processos como forma de agradar mais seus clientes. Assim nasceu uma miriade de teorias, livros, bíblias, padrões, siglas e etc. Qualquer empresa que quisesse competir teria que de alguma forma se adequar a algum deles.  Imagine então as consultorias que vivem de vender serviço? Me lembro bem das pilhas de papéis que eram feitos sem nem se questionar se valia a pena ou não. Lembro-me bem das inúmeras reuniões para fecharmos escopo antes de ter escrito ao menos uma linha de código, nem um protótipo para validarmos se havia razão em manter o investimento.  E nada disso acabou com o maior problema que temos no mercado de TI: clientes infelizes!

PAUSA : Isso mesmo que você leu. O maior problema do mercado de TI é que nossos clientes estão infelizes. Eles pagam caro por algo que não é bem o que eles queriam e que chega num prazo muito acima para ter algum valor.  Por isso, não é dificil de entender por que temos tantas empresas que simplesmente optam por não comprar ou desenvolver uma solução mesmo sabendo que ela poderá ajudar.

Trabalhei 3 anos em indústria num departamento de engenharia. Era responsável pela parte de TI mais próxima da máquina (chamado de supervisórios, scada, etc). Com isso tive a oportunidade de lidar com grandes projetos que envolviam números realmente impressionantes.  Os projetos, em todos, tinham ciclos de vida de até 4 anos… Isso mesmo os projetos duravam em média 2 a 3 anos desde a sua concepção até a sua entrega, devido a lidarmos com fabricação de máquinas, construção de prédios, e outros serviços parecidos.  Nesse tipo de ambiente é certo concluir que a pressão é grande e a margem de erro é pequena, por isso, muitos diriam que isso seria um “prato cheio” para processos rígidos, escopos fechados, etc.

Acredito que para a surpresa de todos, o que eu vi foi exatamente o contrário:  As coisas mudavam muito e isso era muito bem absorvido, pois todos sabíamos que isso poderia acontecer .  Não tínhamos quadros brancos, não tínhamos post-its (eu até tinha ) tudo era controlado por um cronograma.  Entretanto, sentia que de certa forma éramos ágeis.  Quando chegávamos mais perto da entrega (chamávamos de partida da fábrica), contávamos com uma reunião diária com todos os técnicos/engenheiros envolvidos onde discutíamos o que tinhamos feito, os problemas,  as soluções, etc.  O que realmente estragava toda a brincadeira era o fato dos administradores/diretores nos entupir de formulários a preencher e assim toda a agilidade de equipe ia “por água abaixo”.

Cito esse exemplo para dizer que agilidade nada tem a ver com a ferramenta ou processo adotado. Tem muito mais relação com RESIlÊNCIA, ou seja, a sua capacidade de aceitar um “porrada” sem se deformar; sua capacidade de aceitar que as coisas mudam e ser aberto a elas; sua capacidade de não esconder os problemas, entender que eles existem e fazem parte de tudo, e que o grande lance não é procurar culpados e sim formas de resolver. É entender que tudo é negociável (menos a qualidade por favor).

RÓTULOS SÃO BONS PARA EMBALAGEM NÃO PARA FAZER SOFTWARE

Tenho começado a vislumbrar que tudo não passa de rótulo. Empresa que antes eram CMM ou RUP doentes hoje dizem que usam SCRUM e são ágeis. O que mudou foi o  RÓTULO, nada mais.  Ainda tem um monte de gente fazendo coisas sem sentido (zero de valor para o cliente), equipes fazendo horas extras para caramba, chefes mega autoritários e por aí segue.  Tem uma palestra do Jeff Patton entitulada “Eu não quero seus processo estúpido” que fala algo nessa linha.

Dane-se o nome.  O que importa é gente feliz: cliente feliz, funcionário feliz, chefe feliz, enfim todos felizes. Não é o quadro branco ou a pilha de documentos que irá garantir isso É muito mais atitude!  O que importa que vamos entregar mais valor para o nosso cliente e com isso fazê -lo ganhar mais dinheiro. É termos um ambiente que propicie que o cara que está fazendo esteja feliz e motivado pois sei que com isso ele irá fazer o seu 100% para ter algo bom e de qualidade na ponta. E se tudo funciona todos ficam felizes.

Seus processo, solução ou de qualquer jeito que queira chamar, dever como um lubrificante: deve facilitar o funcionamento para obter o máximo rendimento.

NÃO IMPONHA PROVE QUE SERÁ MELHOR

Um dos maiores erros é impor. Nada imposto dura muito ou é feito com alegria. Prove que se fizer daquele jeito será melhor e esteja preparado para estar errado.  Não será em todos os lugares que fazer par para programar será a melhor coisa. Isso depende das pessoas quererem. Eu particularmente gosto.  Não será em todos os lugares que não ter cronograma será a melhor escolha.

Sugiro, experimente, erre, mude. Siga evoluindo. Um colega de trabalho, Bernardo Heynemann, num tech talk, falou que uma coisa legal da cultura japonesa que ajuda muito o jeito Toyota de fazer as coisa é que eles sempre buscam a excelencia e evolução continua. Isso para mim é ser ágil. Aceitar o movimento e fazer uso dele.

Muito tenho escutado neste últimos dias sobre a questão do sucesso ou não do uso de metodologias ágeis.Principalmente com relação a entregas. Primeiro preciso dizer que não sou um doutor no assunto, nem pretendo ser, muito menos um profundo conhecedor, mas considero que tenho uma pequena vivência no assunto que me permite tecer alguns comentários sobre o assunto.

A alguns dias atrás, fiz um workshop sobre metodologias ágeis com o Juan Bernabó na Globo.com. Recomendo fortemente a todos fazerem mesmo que já tenham certo conhecimento sobre o assunto, apliquem nos seus times ou qualquer outro caso.

Durante todo o workshop feito por ele, cujo o objetivo é de apresentar as metodologias principalmente o Scrum, vários jogos, dinâmicas e outras tantas coisas são feita. Entretanto, para mim, o mais interessante  foram as discussões que ocorreram entre as atividades.

Houve um momento que o pessoal colocou os problema encontrados no dia a dia de cada um e suas expectativas quanto ao uso de metodologias ágeis.  A primeira coisa que ficou bastante evidente foi uma expectativa que ao colocar em prático algo ágil todos os problemas desaparecerão, como que por mágica, e que todos serão felizes num ambiente super ideal.

A questão que o curso colocou, e que realmente achei genial, é que Scrum não é uma ferramenta somente de soluções. Ela tem muito mais um aspecto de mostrar os problemas e forma simples e rápida procurar resolvê-los.

Sendo assim, quem não está preparada para ver os problemas, gargalos, etc de sua empresa, ao adotar qualquer coisa no sentido, vai achar que a ferramenta não serve. Isso porque tem a expectativa errada. Verá muito mais problemas do que solução.

Uma outra coisa que o Bernabo falou que me fez mudar a forma de pensar foi que ser ágil não significa não ter problema : a questão é exatamente contrária, evidenciam os problemas e procura-se soluções. Contra medidas nas palavras do Juan.

Enfim, ao vermos a questão ágil não como mais um processo e sim como uma forma de levantar os problemas e buscar contra-medidas, fica claro a razão do sucesso e que simplesmente seguir uma cartilha não é o perfil ideal a buscar.

Jack Milusnk, em seu blog The Agile Buddy Blog, escreveu um excelente post sobre a questão da histórica técnica. Em tomei a liberdade de escrever uma versão (não tradução) em português do texto. Para quem quiser ler o texto original, acesso o post aqui. Comentários com ajuda na tradução e opiniões são bem vindo.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>

A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog.

Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:

“O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”

Então, qual é a resposta correta?

Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.

Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:

Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog. Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:”O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”Então, qual é a resposta correta? Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.