Bolicho Ágil

To devendo para quem, se eu "rapo os cobre da guaiaca" para pagar as contas?

2010-07-25T11:59:00.005-03:00

Prezados

Após um post introdutório e outros dois falando de aspectos mais humanos e sociais, quero adentrar num tema que eu, de certa forma, já conhecia por experiência própria e é um pouco mais geek que os demais.

Aos amigos de fora do Rio Grande, explico: rapar os cobre da guaiaca significa, de certa forma, usar todo o dinheiro disponível para pagar todas as contas.

E é com essa metáfora que eu trago à tona o tema do Débito Técnico(ou Dívida Técnica, como alguns colocaram, em função da tradução). O tema foi lançado por Ward Cunningham, e ele mesmo faz menção ao uso da metáfora do mundo das finanças a fim de fazer uma analogia sobre o que acontece, ao longo do tempo, com um software que possui um design pobre.

Vamos usar a técnica da D. Maria para a metáfora ficar clara. Sim, a D. Maria, aquela senhora, dona de casa, que prepara seu chimarrão e senta ao final da tarde para assistir a novela e, no intervalo, dá uma lida aqui no Bolicho Ágil para se atualizar ;-).

Se pensarmos em termos financeiros, quando não cuidarmos das finanças da devida maneira, pagaremos juros, como uma consequencia dessa falta de cuidado. E esses juros podem tomar proporções impagáveis.

Uma situação semelhante acontece toda vez que precisamos inserir uma nova funcionalidade em um software. Podemos inserí-la sem nenhum cuidado com o design e de uma forma muito rápida, ou inserir a funcionalidade utilizando mais tempo, mas observando regras de boa prática de design e programação. De acordo com Cunningham, quando uma equipe utiliza uma abordagem simplista(chamo aqui de abordagem simplista toda aquela abordagem que queima etapas), acaba criando um débito técnico, pois tornará o trabalho de manutenção e inserção de novas funcionalidades desse software cada vez mais complicado, podendo chegar ao ponto de ser impossível e ter que recomeçar o software do zero. Voltando à visão financeira, isso é prejuízo na certa.

Existe uma discussão mais detalhista sobre o conceito e os tipos de débito técnico entre Martin Fowler, Steve McConnell e Uncle Bob. Porém penso que é importante destacar aqui alguns aspectos que envolvem o débito técnico, com o propósito de, muito humildemente, contribuir com a discussão.

O primeiro aspecto, ao meu ver, é a responsabilidade sobre o débito técnico. Incumbir a responsabilidade por A ou por B, sejam A ou B pessoas ou cargos, não resolve o problema. A responsabilidade é de TODA A EQUIPE.

O segundo envolve o estudo e o aprimoramento. Nós desenvolvedores devemos continuamente estudar, aprimorar conhecimentos e "afiar nosso machado", a fim de construirmos soluções cada vez mais robustas. Como vamos refatorar nosso código se não sabemos quais recursos temos nas mãos para reduzir duplicidade ou complexidade do código?

O terceiro aspecto é um comportamento que eu já vi bastante por aí. A separação de cargos entre analista e programador, e a consequente rejeição do analista conhecer código ou do programador conhecer análise, técnicas de requisitos ou UML. Os métodos ágeis tem trazido a tona a necessidade real de multidisciplinariedade de conhecimentos a fim de se construir boas soluções. Klaus Wuestefeld colocou, ao final do Agile Brazil 2010, de forma muito inteligente, que não construímos software, e sim aprendemos software. Traduzindo: Aprendemos sobre algo que transformamos em software. Como vamos aprender sobre algo fora da nossa área de conhecimento se não estamos dispostos nem a obter conhecimentos da nossa própria área? Como discutiremos aspectos do projeto, se ficarmos restritos a uma visão míope sobre como solucionar o problema?

Penso que todos nós, desenvolvedores de software, devemos pensar e ter cuidado com isso. Afinal, precisamos entregar software funcionando continuamente, e cada vez melhor.

Abraços a todos, e até a próxima.

Mas tchê, me diz uma "cousa", o que é essa tal de agilidade?

2010-07-18T11:14:00.020-03:00

Prezados

É com muito prazer que começo mais um post. Vamos ver o que acontece com esse. Perdoem-me aqueles que não são da TI, passaram por aqui, e se depararam com um post falando sobre a dimensão humana dos métodos ágeis, sem que eu tenha explicado que "bicho é esse". Pretendo agora corrigir meu lapso ;-).

Penso ser essa uma oportunidade interessante, inclusive aos "sabidinhos de plantão", pois tem muita gente por aí dizendo que usa métodos ágeis, mas "tá mais perdida que cusco em tiroteio". Aos que não conhecem o termo "cusco", esclareço: é como nós chamamos o cachorro aqui no sul, principalmente o cachorro campeiro.

Mas vamos ao que interessa, que é o software mesmo. O mundo da engenharia de software já passou por algumas crises. A mais famosa é a crise do bug do milênio. Mas até hoje temos problemas básicos, como:
1 - Apenas 1/3 dos projetos de software dão certo (entendam dar certo como cumprir o objetivo proposto dentro de um prazo e custo esperado). Segue o texto retirado do Standish Group sobre o Chaos Report 2010: The Standish Group's just-released report, "CHAOS Summary 2009," "This year's results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions" (http://www1.standishgroup.com/newsroom/chaos_2009.php).
2 - O Chaos Report 2002 mostra que aproximadamente 50% das funcionalidades desenvolvidas em um software nunca, ou quase nunca, são usadas. Olha o desperdício!

As primeiras crises relativas a problemas com os softwares desenvolvidos desencadearam uma reação natural de busca por meios de evitar que esses problemas tornem a acontecer, através da inserção de controles e "disciplinando" o processo de desenvolvimento de software. O termo "engenharia de software" deriva de uma busca, nas práticas da engenharia (civil, mecânica, ...), de técnicas e métodos capazes de organizar a construção de um software. Então passou-se a ver o processo como um meio importante de se chegar a um bom produto. A idéia era mais ou menos essa: Uma equipe com um processo ruim pode até conseguir construir um bom produto, mas não há garantias de repetir o sucesso. Uma equipe com um bom processo conseguirá fazer bons produtos e repetir o sucesso várias vezes.

Não há nada errado com essa idéia, de uma maneira genérica. O problema (mais uma vez) foi a inserção de controles, documentos, papéis e etapas em torno de um projeto que aumentou exponencialmente o número de tarefas a serem cumpridas em um projeto. Entretanto, não havia uma garantia que o cumprimento dessas etapas traria sucesso ao projeto.

Como dizem num programa de rádio aqui de Santa Maria, vamos exemplificar para que a D. Maria, que não entende patavina de software, possa entender: A D. Maria, dona de um estabelecimento comercial, quer um "programinha" para controlar as finanças da empresa. Então ela chama a empresa XYZ2010, uma das mais conceituadas empresas do país, para um orçamento. Senta na frente da D. Maria um tal de "analista de negócios" e conversa, conversa, conversa, conversa, conversa, conversa, conversa. Ele anota tudo. A D. Maria pergunta: Quando que você me entrega isso? A fim de não perder o negócio, o analista diz assim: Nós vamos projetar segundo as especificações do nosso processo e em alguns dias nós entregamos o orçamento. Umas duas semanas depois volta o cristão, crente que entendeu tudo o que a D. Maria quer, e depois de ter escrito umas 250 páginas de "especificação de requisitos" e vários diagramas, afinal ele precisa saber quantos "bits points" (ou outra unidade qualquer de medida de tamanho de software) o programa terá para estimar um prazo, e diz assim: Levará 4 meses e custará R$ 50.000,00. Como ela não entende nada de "computador" e confia, ela fecha o negócio.

Lá pelo terceiro mês do projeto, sem ela não ter nem ouvido mais falar da XYZ2010, ela liga para falar com o tal analista de negócio. Descobre que ele não trabalha mais na empresa. Ela se apavora. A secretária diz assim: Não se preocupe D. Maria! Nós usamos o processo ABC e somos certificados. Tudo o que a senhora relatou está a salvo e a equipe compreendeu perfeitamente. Vou transferir a ligação para o novo analista que está cuidando da sua conta. A D. Maria então conversa com o novo analista e, mais tranquila, pergunta se pode ser feita uma pequena alteração no projeto. O novo analista responde: D. Maria, se nós fizermos uma alteração agora, teremos que reprojetar tudo, analisar o impacto da mudança e enviar um novo orçamento. A senhora realmente quer? Com uma certa pena dos rapazes, D. Maria diz: Vou aguardar vocês entregarem o projeto então. Afinal, D. Maria contratou uma das melhores.

Quando o projeto foi entregue, a surpresa foi que D. Maria disse ao analista de implantação que foi instalar o produto na sua empresa e mostrar como tinha ficado o trabalho: Não foi nada disso que eu pedi. O rapaz, atônito, disse, ao mostrar o documento de requisitos: Mas está igualzinho ao que a senhora pediu aqui!!!! O final dessa história muitos já conhecem.

Em tempo: Essa realidade também acontecem com as equipes dos "pequenos rincões distantes da capital". Acontece até mesmo com o sobrinho do amigo que faz faculdade de informática ;-). Aconteceu comigo também :-(.

De olho na realidade da D. Maria (e de muitos outros), uns "caras" perceberam que a coisa não andavam bem e resolveram se encontrar para trocar umas idéias. Se isso fosse aqui no sul, esse encontro seria num galpão, a beira do fogo de chão numa roda de chimarrão. Mas isso foi no Norte. Mais precisamente nas montanhas geladas de Utah, entre os dias 11 e 13 de fevereiro de 2001.

Foram 17 mestres que se reuniram, esquiaram, descansaram, comeram e chegaram a um ponto em comum. Todos eles vinham trabalhando de forma diferente. Eram as vozes vivas do Extreme Programming, Scrum, Crystal, FDD e outros. Sim, estou falando do manifesto ágil. Uma forma diferente de ver o trabalho de desenvolver software. Segue abaixo os princípios e valores que eles encontraram:

"Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda."

São signatários desse manifesto:
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

Dentre os quais, tive a honra de ver a palestra do Martin Fowler, no Agile Brazil 2010.

Basicamente, os métodos ágeis de desenvolvimento de software constituem uma forma diferente (dos métodos tradicionais) de ver o desenvolvimento de software. Desenvolver software é basicamente um processo contínuo de resolução de problemas complexos. Demanda pessoas motivadas e com uma vontade muito grande de encarar problemas de frente todo santo dia! Então os processos de apoio devem ser vistos como algo necessário, útil e simples. As pessoas passam a ter um papel fundamental para o sucesso da empreitada.

Nesse tempo em que resolvi adentrar no mundo dos métodos ágeis, conheci muitas feras. Esses feras andaram conceituando agilidade lá em Pingos de Agilidade. Segue abaixo alguns desses conceitos que encontrei por lá.

Daniel Wildt: "Atitude, foco em entrega de software, trabalho em equipe e mehoria contínua."

Manoel Pimentel: “Em minha opinião, agilidade não é apenas um conjunto de práticas aplicadas para melhorar o desenvolvimento de software, mas sim uma verdadeira filosofia de vida, que nos faz encarar as questões do dia-a-dia, através do reconhecimento de nossas limitações e ao mesmo tempo, do desenvolvimento de nossas potencialidades como ser humano.”

Rafael Prikladnicki: "Eu gosto da definição do Philippe Kruchten: 'Agilidade é a habilidade de uma organização de responder à mudancas no seu ambiente de atuação mais rápido do que a taxa de ocorrência destas mudanças.' Além disso, a agilidade reforça a importância do fator humano em projetos de software, bem como inspeção constante e entregas rápidas."

Luiz Claudio Parzianello: "É engraçado, mas não sei mais como definir agilidade … Se eu tentar fazê-lo, acho que vou destruir o conceito! Para mim, agilidade é um caminho de descobertas que conduz à ética e ao aperfeiçoamento contínuo, tanto do indivíduo quanto da organização de software. Na primeira edição do Community Journal da Visao Ágil, pude escrever o seguinte sobre uma pergunta muito semelhante:
Muitos acreditam que o Manifesto Ágil não passa de uma piada, enquanto outros acreditam que ele marca o início de uma mudança na história do desenvolvimento de software. Alguns acreditam que tudo isso é um mero modismo, enquanto outros conquistam continuamente melhorias substanciais na qualidade e produtividade de suas equipes de desenvolvimento. Muitos acreditam que agilidade é assunto para pequenos, enquanto poucos já demonstraram que milhares de pessoas trabalhando de forma colaborativa e distribuída é coisa de gente grande. Pois bem, pude perceber ao longo dos últimos 10 anos, assessorando empresas e capacitando profissionais em projetos de implantação de Metodologias Ágeis, que a agilidade não está associada somente a uma nova cultura de crenças e valores, mas principalmente a uma nova busca de descobertas e iluminação. Iluminação no sentido de enxergar de vez que o desenvolvimento de software é um problema de logística que deve ser sustentado por uma forte cultura de comunicação e colaboração entre todas as partes interessadas num produto ou projeto de software. Logística no sentido de desenvolver competências para a entrega rápida de pequenos incrementos de software de alta qualidade, mantendo sempre um ritmo constante sustentável. Comunicação e colaboração no sentido de compreender como a menor quantidade de software irá aumentar a vantagem competitiva de nossos clientes (fazer cada vez mais com cada vez menos). Se você promover de forma honesta a melhoria contínua de pessoas, ferramentas e métodos, você com certeza encontrará o pensamento Ágil e descobrirá que esse é o único caminho para o sucesso e a satisfação de sua equipe de desenvolvimento."

Bom espero ter trazido a todos uma visão sobre o que são os métodos ágeis. Fico a disposição para sugestões, críticas ou até convites para festa.

P.S.: Havia colocado que o blog Pingos de Agilidade era mantido pelo Manoel Pimentel. Estava equivocado. É mantido pelo Rafael Helm e agora pelo Daniel Wildt. Procurei corrigir.

A dimensão humana dos métodos ágeis, vista por um praticante novato

2010-07-11T01:45:00.018-03:00

Prezados

É com muito prazer que volto a este canal para compartilhar o que venho aprendendo há algum tempo fora e dentro da comunidade ágil.

Fiquei lisonjeado pelo fato de existirem leitores que não são desenvolvedores ou que trabalham com TI. Por esse motivo, quero adentrar em questões humanas que fazem parte do nosso trabalho, mas também podem contribuir para nossa vida.

Permitam-me inserir meu mini-curriculum aqui a fim de situar nossa conversa no eixo tempo-espaço (Uau!!! Quem lê pensa que sabe...). Me formei em janeiro de 2006 em Sistemas de Informação pelo Centro Universitário Franciscano. Fiquei um ano sem estudar, mas desde 2004 tinha na cabeça que faria o MBA em Gestão Empresarial pela FGV. E não podia ser em outro lugar. Então em 2007 iniciei esse curso que me trouxe algumas lições.

Dentre as disciplinas cursadas, uma trouxe uma visão bastante interessante: Negociação. Ministrada pelo Prof. Gersem Martins, um mestre com formação internacional e experiência em negociação de exploração de petróleo pela nossa Petrobrás. Realmente ele tem alguma experiência profissional.

O que chamou a atenção nesse curso foi a seguinte colocação do Prof.: quando ensinamos uma matéria técnica, o aluno leva aquilo para o ambiente profissional, mas quando ensinamos uma matéria humana, o aluno leva para a vida. E ele relatou que houveram vários casos de alunos que melhoraram seus relacionamentos conjugais e familiares após passarem pelo curso.

Aqui vão alguns ensinamentos deixados pelo Prof. Gersem que passei a levar no meu dia a dia pessoal e profissional, e que compartilho com vocês nesse momento:
1 - Ao iniciarmos uma negociação, pouco ou nada sabemos sobre o outro lado. Diante de tal ignorância, precisamos sair da caverna e ir para a galeria a fim de adquirir uma maior compreensão do problema.
2 - Negociação por princípios
2.1. - Separar o problema das pessoas
2.2. - Manter o foco nos interesses
2.3. - Inventar opções para ganhos mútuos
2.4. - Utilizar critérios objetivos

Fica aqui meu agradecimento ao Prof. Gersem pelos valiosos ensinamentos.

Após esse passeio pelo mundo do business, estava eu de volta, totalmente imerso no mundo do software. Enquanto cursava o MBA, pensei em sair do mundo do software. Mas não adianta: Nessas veias e artérias correm 0s e 1s.

Com esse retorno, veio o mundo dos métodos ágeis. Para quem está chegando, o mundo dos métodos ágeis "engana", deixando transparecer que não passam de técnicas de programação e estruturação de projetos. Fui entrando, estudando, participando de eventos, conhecendo pessoas. E tal foi a minha surpresa que me dei por conta, em um primeiro momento, por observação e comentários, que o desenvolvimento de software é uma atividade social, e que a única coisa de exata ali era o compilador.

O segundo contato com uma dimensão mais humana da atividade de desenvolver software foi durante o curso de scrum, com o Rafael Prikladnicki, quando tive um contato mais consistente com o termo "Auto Organização". Simples de entender mas complexo de aplicar. Penso que essa complexidade vem do fato que temos que abrir mão do EU em preferência ao NÓS.

Adentrando mais nesse mundo, tal foi minha surpresa com o reencontro com a Programação Neurolingística (PNL). Há muitos anos havia assistido a vídeos e comprado um livro do Dr. Lair Ribeiro, mas isso foi um conhecimento armazenado em algum lugar do cérebro e deixado lá.

Esse reencontro foi durante o curso de Requisitos Ágeis, com o Parzianello. É uma ferramenta interessante, dentro do contexto da nossa indústria, de coleta de informações e gerenciamento de conflitos. Insisto: Sou um iniciante. Por esse motivo pode ser que existam outras aplicações para PNL, mas nesse momento eu vejo até aqui ;-).

Quando vivemos num momento em que aproximadamente 1/3 dos projetos de software no mundo dão certo (leia-se dar certo como entregue dentro do prazo e custo esperados), é nosso dever levantar a cabeça e ver o que podemos aproveitar do mundo em nossa volta.

Bom, considero que estou no nível de saber apenas que a PNL existe. Mas penso que é interessante resumir algumas coisas que aprendi, em PNL, visando o mundo profissional, e faço um esforço para levá-las para o mundo pessoal. São elas:
1 - Todos temos filtros de compreensão e processamento das informações que nos permitem entender o mundo de uma maneira única. Porém, como profissionais que trabalham com informação como entrada e saída de um processo, precisamos entender a realidade do outro a fim de entregarmos aquilo que trará valor ao cliente. Como pessoa, isso é importante, a fim de não ferirmos crenças e valores de outrem.
2 - Conseguir visualizar que por trás de comportamentos existem propósitos nos fará entender o contexto na qual aquela pessoa está inserida, o que trará uma riqueza de informação e um norte seguro ao tratarmos com ela, seja para adquirir informação ou para conduzirmos uma pessoa ou um time a outro rumo, sem que isso ocorra num contexto "comando-controle".
3 - Quando estamos diante de um dilema com outrem, quanto mais nos atermos aos detalhes, mais complicado será de alcançarmos um acordo. Se, ao contrário, enxergarmos as coisas de um plano mais elevado, será mais simples atingir o acordo.

Bom, espero ter cumprido o objetivo de levar um pouco do que eu aprendi aos demais, não restringindo esse conhecimento aos desenvolvedores e agilistas que por ventura passem por aqui.

Estou aberto a todas as sugestões e críticas que vocês tenham em relação a este ou outro post. Afinal, um dos valores da Extreme Programming, e por consequência dos métodos ágeis - tema deste blog, é o feedback. E eu quero recebê-los o mais breve possível.

P.S: Espero igualmente ter levado a todos um lado humano presente nos métodos ágeis e necessária a atividade vista como essencialmente técnica.

Sprint 0

2010-07-08T18:19:00.000-03:00

Olá a Todos

Sejam bem-vindos ao Bolicho Ágil.

Há algum tempo vinha pensando em escrever algo na web. Eis que chegou o grande dia.

Aos não gaúchos que visitarem o blog, explico desde já: Segundo o Babylon (http://dicionario.babylon.com/bolicho/), bolicho é "Casa de negócio de pequeno sortimento e de pouca importância". Resolvi colocar esse nome por dois motivos:

1 - Homenagem ao estado que nasci ;-) (Apenas homenagem, não é ufanismo!)
2 - Mostrar uma visão sobre métodos ágeis em equipes pequenas(1, 2, 3 desenvolvedores)

Há um ano descobri o mundo dos métodos ágeis de forma mais consistente num Workshop de Métodos Ágeis na Target Trust. Nesse workshop, descobri o nome de uma pessoa na qual acabaria me tornando um discípulo: Luiz Claudio Parzianello. Acabei depois conhecendo outros mestres, como o Daniel Wildt e o Rafael Prikladnicki.

Desde então foram muitas leituras, cursos, contatos com pessoas interessantes e, principalmente, posso dizer que depois de 11 anos de experiência na área de software, agora que estou aprendendo a fazer software de verdade. Quando falo de verdade, me refiro a compreender o manifesto ágil, seus princípios e valores, e aplicá-los no dia a dia, a fim de entregar softwares cada vez melhor.

Conforme coloquei anteriormente, ao escolher o nome desse blog, minha experiência sempre foi em equipes pequenas (máximo 5 pessoas), aqui em Santa Maria. Através da SICON, há pouco mais de um ano, participo do Centro Software , aqui em Santa Maria. É um grupo de empresas daqui da cidade que quer melhorar e crescer. Todas elas possuem poucos desenvolvedores. E querem implantar métodos ágeis. Por esse motivo, quero contribuir com a comunidade com essa visão de pequenas equipes.

Em relação à definição de Bolicho do Babylon, quero fazer uma pequena ressalva: Os itens podem até ser de pequena importância, mas a forma de fazer negócio de forma direta (com o dono colocando a barriga no balcão) e transparente é algo que todos precisamos. E essa é uma marca registrada dos "Bolichos desse rincão".

Bom, procurarei manter a frequência de um post por semana, tentando contribuir sempre com essa comunidade, que tem construído tanto conhecimento para minha vida profissional e pessoal. Pelo fato de conseguir fazer melhor minhas tarefas, tem sobrado um pouco mais de tempo. E como disse uma vez um cara que é fera em métodos ágeis, Daniel Wildt, tempo é vida! E essa é minha busca atual.