Adolfo Sousa

Quando o assunto é desenvolvimento de software, existem basicamente duas grandes “escolas” a se conhecer: a tradicional e a ágil. Cada uma delas enxerga e trata o processo de desenvolvimento de software e, consequentemente, qualidade de maneiras bem distintas.

Para os adeptos das metodologias tradicionais, que encaram o processo como uma cascata (primeiro alguém tem a visão do produto, depois algumas pessoas especificam o software, outras implementam, umas outras testam, a próxima coloca tudo isto em produção de uma vez para que então uma outra equipe não possa manter o software vivo, gerando algum tipo de valor), o conceito de qualidade se assemelha ao usado em processos de produção industrial: conformidade com requerimentos definidos na fase de design ou em alguma “receita”. A palavra chave que define qualidade neste cenário é conformidade. Espera-se que haja uma pré-definição clara do que é qualidade, do que é esperado, e se o software estiver “conforme” é possível dizer que o usuário dele estará lidando com um software de qualidade. Como é possível notar, variabilidade e diversificação não são desejáveis aqui.

Já os adeptos das metodologias ágeis tendem a enxergar qualidade de forma parecida com a qual prestadores de serviços a enxergam. O cliente de um software não sabe o que é ou não está preocupado com a qualidade, pelo menos não de uma forma definida, exata e clara. Ele pode estar em busca uma boa experiência ou esperando que o software lhe ajude a resolver algum problema. Talvez queira que o sistema lhe entregue algum valor mas também pode ser que diversão ou experimentação/inovação sejam o seu fim. Aqui, nenhum requerimento, documento ou receita definida previamente serve para atestar a qualidade do software. Então se não podemos definir, quer dizer que não há qualidade? De forma alguma. Neste cenário, qualidade não precisa ser exata, imutável, não precisa ter uma definição clara, não é possível lhe darmos um nome. O que buscamos, na verdade, é Qualidade Sem Nome, ou QWAN (Quality Without a Name).

Neste contexto, em que tratamos qualidade de forma não determinística, em que as expectativas mudam de usuário para usuário, alguns cuidados devem ser tomados para que, quando perguntarmos a um deles se determinado software tem qualidade, tenhamos como resposta algo do tipo: “hum, deixe-me ver… eu sinto que sim. Ele me ajuda, gosto dele, sinto confiança, ele é, como posso dizer, consistente”. Tarefa difícil, não? Difícil porém possível se entendermos dois conceitos extremamente importantes [1]:

1. Integridade Percebida - o produto como um todo alcança um equilíbrio entre funcionalidades, usabilidade, confiabilidade e economia que agrada os clientes.
2. Integridade Conceitual - os conceitos e partes centrais do sistema trabalham harmonicamente, de forma coesa, como um todo. Os componentes ou módulos se integram e trabalham bem conjuntamente.

Como você pôde notar, a Integridade Percebida e a Conceitual estão intimamente ligadas e têm papel fundamental na qualidade do software desenvolvido. Por esta razão, vou dedicar o próximo post desta série para discuti-las mais a fundo.

Até a próxima.

[1] - Os conceitos de Integridade Percebida e Integridade Conceitual foram extraídos do excelente livro Lean Software Development - An Agile Toolkit da Mary e do Tom Poppendieck. Eles, por sua vez, adaptaram os conceitos de “Internal Integrity” e “External Integrity” contidos no livro Product Development Performance de Kim Clark e Takahiro Fujimoto

Qualidade de software é um assunto pouco discutido por nós, profissionais da área. Já ouvi repetidas vezes o argumento de que este fenômeno acontece porque se trata de uma “indústria” ainda muito nova. Pode ser nova se comparada com outras como a têxtil ou a automobilística. Entretanto, não podemos aceitar argumentos conformistas como este e nem tampouco encarar desenvolvimento de software como indústria, sob pena de nos colocarmos num ambiente pouco adaptável, repetitível, prescritivo e de inovação lenta e cara. Não acredito que esta seja a natureza dos projetos de software.

Independentemente da maturidade deste nosso ofício, ou melhor, arte, qualidade deve fazer parte do seu processo de desenvolvimento e, portanto, não há motivo algum para não discuti-la com a mesma frequência que discutimos outros assuntos como linguagens, frameworks, metodologias, arquiteturas, etc.

Pretendo iniciar uma série de posts para falar de qualidade de software. Sejam bem-vindos e sintam-se livres para fazer parte da discussão.

—————

Parte 2 - http://www.adolfosousa.com.br/blog/2010/02/10/o-que-e-qualidade-de-software/

Já faz algum tempo que não tenho tanta paciência para ficar discutindo metodologias ágeis para desenvolvimento de software. A minha cabeça de alguma forma passou a pensar que tudo se resume a aplicar bem o manifesto ágil. E isto, por si só, não é nada fácil. Exige muita disciplina, capacidade, atenção e profissionalismo. Nenhuma metodologia, ferramenta ou gerente vai resolver o real problema do nosso mercado: escrever software útil e de qualidade.

Danem-se os selos CMMI, as certificações do PMI e da Scrum Alliance, os programadores que enchem currículos de siglas e código de sujeira. O que vai resolver o nosso problema é gente competente, disciplinada (no sentido dado pelo Uncle Bob no seu keynote da RailsConf), capaz de ouvir o cliente e criar uma relação verdadeira de parceria com ele, com características para evoluir constantemente. Se você ou a sua empresa são capazes de fazer isso bem, não se preocupe em dar um nome para os métodos que você usa para fazer o seu trabalho. É feio sair por aí dizendo que aplica scrum (ou qualquer outra coisa da moda), encher o bolso de dinheiro e se esquecer os princípios básicos do manifesto ágil.

Esta introdução longa é para desabafar a raiva acumulada pelo monte de besteiras que eu ouvi em algumas palestras no Scrum Gathering 2009. Muita gente já escreveu e/ou tocou em pontos polêmicos sobre o evento. Quero dar os meus pitacos, então vamos ao que mais me irritou naqueles dois dias:

• Times auto-gerenciáveis - pelo menos 2 palestrantes (Ricardo Vargas e Fábio Câmara) afirmaram categoricamente que nunca viram um time capaz de se gerenciar. E somente isso. Não contaram alguma experiência ou analisaram o motivo pelo qual isso é impossível no ambiente deles. Este é um assunto muito interessante e qualquer discussão é válida.
• Ken Schwaber - imagine que você vai ter uma aula de futebol com o Ronaldinho Gaúcho e o cara gasta o tempo falando que no futebol a bola é redonda, os times têm 11 jogadores, o objetivo é fazer o maior número de gols, etc, etc, etc. Pois é, assim foi a palestra de um dos criadores do scrum. O sujeito ficou quase uma hora falando o básico e o óbvio, fez uma brincadeira mais do que manjada para falar de “comando e controle” versus “times auto-gerenciáveis” e finalizou anunciando que a Scrum Alliance vai lançar o treinamento para CSD (Certified Scrum Developer) e que este vai ser baseado em ferramentas da Microsoft. Precisa falar mais alguma coisa?
• Fábio Câmara - a palestra do Fábio foi a mais polêmica, ainda mais sabendo que ele é um CSP (Certified Scrum Practitioner). Li o título “Usando scrum com o Visual Studio Team System” e fiquei curioso para saber o que faz alguém precisar tanto de uma ferramenta para usar scrum. No meio da palestra o Fábio algumas afirmações, dentre elas: “eu questiono o uso de testes, principalmente os unitários, em projetos time-driven”; “eu tinha um estagiário que eu chamava de controller porque ele ia todo dia de manhã de mesa em mesa perguntando para o desenvolvedor se ele estava fazendo a tarefa que ele deveria estar fazendo. O VSTS me diz isso, uma vez que ele cria um link entre o requisito e o pedaço de código que foi escrito para atender aquele requisito. Eu também consigo saber quem escreveu cada linha, porque quando você pergunta numa sala ‘quem escreveu essa linha aqui?’ fica todo mundo assobiando”; “é incrível como o princípio de pareto se aplica em quase todos os projetos de software. 20% das pessoas fazem 80% do trabalho”; “os desenvolvedores, no final do dia de trabalho, fazem check-in do que eles produziram. No VSTS eu consigo ver cada check-in e passar a mão no telefone pra perguntar por cara lá em Recife porque ele subiu só 25 linhas de código quando a média dele era de umas 200″; “o scrum master e responsável por distribuir as tarefas para o time”. Logicamente algumas pessoas começaram a questionar tudo isso e ele descreveu um cenário para ‘justificar’ tudo isso: “imagine uma equipe grande. Eu já gerenciei equipes com 60 pessoas, algumas trabalhando em outros estados, etc …”. As minhas sugestões para o Fábio são as seguintes: 1) demita umas 50 pessoas da sua equipe (olha o problema do princípio de pareto sendo resolvido) e forme um time com os 20% que fazem 80% do trabalho e no qual você possa confiar e não controlar (opa, pode mandar o controller embora também). Pare de procurar culpados, isso não resolve nada, é desperdício. Se alguém fez alguma coisa errada no código, esse alguém foi o time e ele mesmo resolve (você já deve ter ouvido falar de propriedade coletiva do código e programação em par). Você não vai precisar ficar bancando o detetive pra descobrir quem foi o infeliz que escreveu a linha 1567 da classe XXXX ou bancando o leão-de-chácara do repositório. Deixe os seus programadores escreverem muitos testes e automatizá-los. 2) se vocês estão sem tempo para escrever os testes, peça a colaboração do seu cliente; explique que o time precisa escrever testes para entregar um produto de qualidade, trabalhem com ele na priorização das histórias, mostre as vantagens de desenvolver um produto iterativamente, melhorando continuamente, respondendo às mudanças. 3) pare de valorizar mais o Visual Studio do que a sua equipe. 4) nunca, jamais, de forma alguma, esqueça do manifesto ágil 5) e, POR FAVOR, pare de falar que o que você está fazendo é scrum.

Na minha opinião, o evento contou com palestras muito boas (Juan Bernabó, Alexandre Magno e Luiz Cláudio Parzianello), mas estes 3 fatos citados bastaram para fazer do Scrum Gathering 2009 - Brazil e da Scrum Alliance um baita fiasco.

É bem provável que aqueles que se interessam por metodologias ágeis de desenvolvimento já leram (ou ao menos ouviram falar) do livro Scrum & XP from the Trenches. Ele é um excelente relato da experiência prática de Henrik Kniberg com estas duas metodologias. Inspirado pela idéia de Henrik, Bob Galen disponibilizou um “rascunho” do seu livro Becoming a Great Scrum Product Owner.

Mais uma fonte para quem se interessa pelo papel de PO do Scrum e sente falta de referências na literatura especializada. Aproveitem!

http://www.rgalen.com/publications.html

Além da excelente palestra do Obie Fernandez, eu assisti a outras memoráveis apresentações no Rails Summit 2008. Aqui vai a trilha que segui no evento e o que mais me impressionou em cada uma delas:

• David Heinemeier Hansson (DHH) - O criador do Rails participou do evento respondendo a perguntas da platéia por vídeo-conferência. A meu ver, a pergunta mais interessante foi a respeito de como a equipe que mantém o framework lida com as sugestões de novas features. A resposta pode ser interpretada como “nós respiramos Lean”; DHH contou que eles simplesmente incorporam ou implementam somente o que o framework necessita e se faz prioritário. Se não é necessário naquele momento, não fará parte do Rails, não importando se está na moda ou qualquer outra coisa.
• Chad Fowler - o escritor de “My job went to India” fez uma palestra muito motivadora. Com o título “Being Remarkable”, Chad deu dicas sobre como nós, desenvolvedores de software, podemos nos destacar. Dentre as dicas, gostei das “machuque-se” e “seja o pior músico da banda”. A primeira diz respeito a nos colocarmos em situações em que nossos conhecimentos, habilidades e capacidades são postos à prova. A segunda nos diz que trabalhar com programadores melhores que nós é uma excelente maneira de aprender e evoluir. Eu nunca havia visto uma apresentação do Chad Fowler, mas agora posso dizer que é sensacional.
• Dr. Nick - muito boa a apresentação desta figura simpática e brincalhona. “Path to awesomeness” é a palestra a que eu gostaria de ter assistido, juntamente com a “Being Remarkable” do Chad Fowler, no comecinho da minha curta carreira de programador. Ele, basicamente, deu dicas a respeito de como ser um bom profissional na nossa área. São elas: 1) aprenda sobre sistemas de versionamento de código (svn e git, atualmente) 2) aprenda a testar 3) comece um blog 4) aprenda a criar aplicações 5) melhore o seu código. Como julgo estas dicas muito importantes e tenho acréscimos a fazer, vou falar mais sobre isto num próximo post.
• Jay Fields - falou sobre a imaturidade dos testes de desenvolvedores. O palestrante fez uma interessante análise das mais famosas ferramentas de testes existentes para ruby/rails. Eu não conhecia o Jay Fields nem tenho muita experiência com ruby e rails, mas me pareceu que ele sabia muito bem o que falava. Expôs claramente pontos positivos e negativos de cada ferramenta, bem como suas opiniões. Respondeu a perguntas e não ficou em cima do muro ao citar quais são as ferramentas que ele usa e prefere: para testes unitários, Expectation. Para testes integrados, Rspec. Para smoke tests, Selenium. Outro ponto importante que o Jay Fields fez questão de reafirmar repetidas vezes é que a sua suíte deve rodar muito rapidamente. Para ele, uma suíte que demora mais de 1 segundo já é problemática e deve ser melhorada.
• David Chelimsky - David é o atual mantenedor do Rspec e falou, na sua primeira apresentação, sobre BDD. Quando comecei a ler sobre BDD, ainda estava tentando fazer TDD. Lá no comecinho, tinha muita dificuldade para começar a escrever um teste. Sempre parava e falava “e agora? que teste eu escrevo? o que eu faço?”. E o que me ajudou muito a vencer esta limitação foi escrever os meus testes à BDD com “should…”. Pra mim foi mais fácil desta maneira porque me ajudava a pensar a funcionalidade de fora pra dentro. Era mais fácil modelar e começar a escrever desta forma. E o David falou disso na sua excelente e didática a palestra.
• Danilo Sato - falou das motivações que o levaram e das dificuldades que teve quando começou a escrever testes automatizados para os seus programas. Algumas das importantes lições citadas pelo Danilo são: testes grandes são difíceis de manter (escreva testes pequenos no estilo arrange-act-assert), é bom cobrir a funcionalidade do ponto de vista externo, código de teste também é código e cuidado com mocks para libs externas.
• Vinícius Manhães Teles - a apresentação foi dividida com o Carl Youngblood da Surgeworks, que falou sobre o ambiente rails aqui no Brasil. Eu nunca tinha assistido a uma palestra do Vinícius, apesar de já o conhecer pelo seu livro de XP.  Foi uma ótima apresentação, mas o que me impressionou mesmo foi ouvi-lo falar sobre empreendedorismo. É impossível descrever ou expressar o valor daquilo falado por ele. É admirável o que o Vinícius fez como pioneiro e evangelizador de XP e vem fazendo, com o pessoal da Improve It, ao inovar o nosso mercado de software.

A primeira edição do Rails Summit foi um incontestável sucesso pelo valor de tudo aquilo falado pelos palestrantes. Tivemos verdadeiras aulas de empreendedorismo, inovação, idéias e agilidade. Tenho certeza de que todos os participantes do evento aprenderam muito. Mais uma vez, meus parabéns à Locaweb e ao Akita pela histórica realização.

Vou relatar aqui uma das palestras com as quais mais me impressionei no Rails Summit 2008, brilhantemente organizado pela Locaweb e pelo Fábio Akita. Pra quem não o conhece, Obie Fernandez foi um dos pioneiros e responsáveis pela adoção do Ruby on Rails na Thoughtworks, escreveu o famoso “The Rails Way” e fundou a Hashrocket. Esta figura simpática, didática e inovadora nos presenteou com o Keynote de encerramento do evento.

Obie listou os 4 princípios do Manifesto Ágil e explicou o que faz para aplicá-los em sua empresa. Em suma, foi uma aula a respeito de agilidade e boas práticas para quem já trabalha ou pretende trabalhar seguindo esta filosofia. Com vocês, o “Hashrocket Way”:

1. Valorizar indivíduos e interações mais do que processos e ferramentas

Nesta parte da apresentação, ele falou muito a respeito das pessoas com as quais trabalha. Mostrou muitas fotos do seu escritório (com vista para o mar), das reuniões diárias e alguns vídeos engraçados do pessoal se divertindo enquanto trabalhava. O mais marcante, porém, foram as suas idéas a respeito de pair-programming. Para Obie, é fundamental ter um monitor com dois teclados e dois mouses para se programar em par. Isto impede que a pessoa mais imperativa domine o teclado e força a participação das duas pessoas. Falou que uma pessoa pode escrever um teste e a outra o pedaço de código para passar aquele teste. Ficou claro que ele enxerga esta prática, quando bem aplicada, como um bem para as pessoas, já que elas aprendem e crescem com mais rapidez, as tornam mais produtivas e, por conseqüência, realizadas. Outro ponto interessante é o número de pessoas nos seus times: segundo Obie, em um time com mais de 4 pessoas você já pode ter problemas de comunicação e perder o auto-gerenciamento. Seus times são de 2 ou 4 pessoas. E sobre contratações, ele contou que publica um post no seu blog, as pessoas respondem, e ele convida algumas para trabalhar para eles por 1 semana. Ele não se importa se o sujeito tem bilhões de diplomas e títulos, se tem 30 anos de experiência ou se já passou por muitos empregos. Ele quer ver como a pessoa se comporta trabalhando num projeto real e em par. Ele não espera perfeição, mas a candidato deve ser capaz de trabalhar em pares, aprender rapidamente e lidar com a pressão de um projeto verdadeiro.

2. Valorizar software funcionando mais do que documentação extensa

Aqui ele deu o recado citando a divertida palestra de um rapaz chamado Brian Liles: TAFT - Test All The Fucking Time. É bem curta e divertida, assistam!

3. Valorizar a colaboração do cliente mais do que (re)negociação de contrato

Ele mostrou uma espécie de contrato em que o cliente não é obrigado a pagar pelo software caso não fique satisfeito. Porém, deixou bem claro que é preciso se proteger. Se o cliente não é obrigado a pagar, ele também não pode processar a Hashrocket e pedir uma indenização maior do que pagaria. Depois, mostrou fotos de alguns clientes realmente trabalhando com a equipe em alguns projetos especiais que eles chamam de “3, 2, 1, launch”. São projetos que eles fazem em 3 dias, desde que o cliente esteja presente e que eles tenham a parte visual da aplicação já definida; este é o único caso em que ele não segue uma prática da XP (design simples).

4. Responder às mudanças mais do que seguir um plano

Neste final da apresentação, ele mostrou a ferramenta Pivotal Tracker. Falou que sempre estimam as tarefas em pontos (com tamanho máximo de oito) e também sobre a importância das reuniões diárias.

Como não consegui os slides, estou escrevendo a partir daquilo que lembro e anotei, e com a ajuda do post que acabo de ler no blog do próprio Obie Fernandez. Pretendo escrever mais a respeito das outras palestras a que assisti e gostei no Rails Summit 2008.

Até mais!!!