Publicado por Vinicius Manhães Teles há
aproximadamente 1 ano.
É cada vez mais comum discutirmos sobre as diferenças e semelhanças entre abordagens ágeis de desenvolvimento de software e outras mais tradicionais, tais como o MPS.BR e o CMMI. Entretanto, poucas pessoas tiveram a chance de vivenciar os dois mundos para poder relatar o que aprenderam com cada abordagem.
Clavius Tales, Diretor de Desenvolvimento da Fortes Informática, é uma dessas poucas pessoas. Ele participou ativamente do processo de implantação do MPS.BR na Fortes Informática. Segundo ele, sua empresa colheu ótimos frutos da utilização dos conceitos trazidos pelo MPS.BR. Entretanto, depois que sua equipe adotou o Extreme Programming, os ganhos foram ainda maiores. Por conta disso, a empresa substituiu as práticas do MPS.BR pelas do Extreme Programming com excelentes resultados.
O relato do Tales acaba de ser publicado no Improvecast 16 que, devido ao tamanho, foi dividido em duas partes.
Esses foram alguns dos assuntos tratados no podcast:
- Quem é a Fortes Informática e o que ela faz?
- Que tipo de problemas vocês tinham antes de adotar o XP e o que o levou a querer adota-lo?
- Antes de adotar o XP, vocês participaram de um processo de avaliação para o MPS.BR nível G. O que motivou vocês a buscarem o MPS.BR?
- Como foi o processo de implantação do MPS.BR na Fortes?
- Quanto tempo foi necessário até se atingir o nível G?
- Quais os benefícios obtidos com o uso dos conceitos do MPS.BR?
- Qual o custo total da implantação e avaliação do MPS.BR?
- Apesar dos avanços conquistados com o MPS.BR, o que levou vocês a buscarem mais conhecimento sobre XP?
- Como você conheceu o XP?
- Que abordagem vocês utilizaram para adotar o XP e quando começou a adoção?
- Qual era a plataforma de desenvolvimento utilizada na época em que vocês começaram a adotar o XP?
- Que treinamentos vocês fizeram antes de iniciar o primeiro projeto XP e como eles foram conduzidos?
- Qual foi o primeiro projeto XP de vocês?
- Quantas pessoas havia na equipe?
- Quem atuava como cliente desse projeto?
- Qual o tamanho das iterações?
- Que práticas do XP mais se destacaram nesse projeto?
- Quais foram as mais fáceis de serem adotadas?
- Quais as mais difíceis?
- Que tipo de transformações você notou no relacionamento com o cliente a partir da adoção do XP?
- Que tipo de transformações você notou no entrosamento e motivação da equipe?
- Como a programação em par vem sendo usada?
- Como vocês estão trabalhando com desenvolvimento orientado a testes?
- Como tem sido o processo de integração contínua?
- Vocês têm utilizado retrospectivas? Elas têm se revelado benéficas para o projeto?
- Qual a sua avaliação sobre a qualidade do software produzido?
- Que tipo de adaptações vocês tiveram que fazer no processo?
- No Improvecast 8, Carlos Barbieri fala sobre os "ninjas". Você acha que XP só poderia funcionar se a equipe fosse repleta de "ninjas"?
- Na sua opinião, quais são as principais diferenças entre a filosofia por trás do MPS.BR e a das abordagens ágeis?
- Qual a sua visão da influência de "certificados" como o MPS.BR nas licitações públicas?
- Como você avalia a forma como o MPS.BR trata as questões humanas no desenvolvimento de software?
- Como XP trata essas questões?
- Como você compararia a forma como o MPS.BR lida com mudanças nos requisitos, em relação ao XP?
- Como vocês têm tratado essa questão no que se refere aos contratos de desenvolvimento de software?
Na implantação do Extreme Programming, a Fortes Informática contou com treinamento e apoio da Improve It. Veja algumas fotos do treinamento e o que nossos clientes acham dos treinamentos.
Finalmente, veja abaixo algumas fotos de uma reunião de planejamento realizada na Fortes Infomática há um mês.
Tags agile, cmmi, fotos, mps.br, par, podcast, qualidade, refactoring, retrospectiva, teste, treinamento, workshop, xp | 2 comentários
Publicado por Marcos Tapajós há
aproximadamente 1 ano.
Ontem recebi um e-mail do meu amigo Mestre, também conhecido como Rodrigo Lemos, me questionando sobre Ruby ser ágil ou RAD e então se iniciou um bate papo bem legal sobre essa linguagem e sobre o framework rails. Pensei em escrever um artigo sobre isso mas achei mais válido compartilhar com vocês apenas retirando o nome do lugar onde ele trabalha e de onde trabalhamos juntos.
E-mail original:
As pessoas costumam confundir muito os dois conceitos (Ágil X RAD). Aqui no meu trabalho tem um pessoal que AMA Delphi sobre todas as coisas. Daí eu resolvi dizer que preferia as plataformas "ágeis" e começaram a dizer que não havia nada mais "ágil" do que Delphi, que era muito mais "ágil" do que Java (em tempo: Java sozinho não é ágil; só o é em conjunto com outras tecnologias, tipo junit, cruisecontrol, mock objects, IDE com refactoring, entre outras ferramentas).
O exemplo típico que essa tribo dá pra dizer que isso Delphi é "ágil" é dizer que é possível montar uma aplicação com cadastro completo (Create, Read, Update, Delete), validação de dados e emissão de relatórios com meia-dúzia de cliques, em 5 minutos.
Só que esta é, na verdade, a descrição de RAD (Rapid Application Development é você conseguir montar uma aplicação em pouquíssimo tempo, com pouquíssima redundância de codificação; é algo típico de ferramentas visuais em que você arrasta meia dúzia de controle e preenche umas propriedadezinhas).
Daí expliquei que "desenvolvimento ágil" era algo muito maior, que era agilidade na hora de fazer uma modificação monstruosa num sistemão que já está no ar, funcionando há séculos. Acho que sempre funcionou muito bem no caso do nosso antigo trabalho: Java (biblioteca maravilhosa) + Eclipse (refactoring) + jUnit/dbUnit/easyMock/cruisecontrol (bateria de testes automatizados) + ant (automação) + CVS/Subversion (controle de alterações). Sempre fizemos modificações estruturais importantíssimas, que simplesmente não dá pra fazer nessas aplicaçõezinhas RAD geradas literalmente PELO Delphi. Essas tralhas RAD, uma vez que tenha sido feito, é quase impossível modificar porque fica tudo quebrado. No máximo fazem modificações de labels, fórmulas de validação simples etc.
No final se convenceram que Delphi não é "ágil" (pode ser como uma palavra genérica da língua portuguesa, que quer dizer algo como "rápido"... mas definitivamente não no conceito de desenvolvimento de software).
Também aqui no meu trabalho usa-se muito desenvolvimento de sistemas sobre Lotus Notes. Que é muito ruim. As ferramentas de edição são uma porcaria (muito mais porcaria que o Delphi). O modelo de dados é horrível e ultrapassado. Mas o pior de tudo, pior de tudo mesmo é que esta é RAD.
Ou seja, provavelmente um despreparado veio aqui no trabalho e mostrou pra não sei quem (um diretor, superintendente ou coisa que o valha) como era possível fazer "aplicações" no Notes em 10 minutos. Claro. É ridículo montar uma aplicação do zero no Notes. É realmente muito rápido: basta criar meia-dúzia de forms, colocar validação e uns botões de ação e pronto. Tá tudo pronto. Ele faz toda a renderização, armazenamento e recuperação, criação e remoção de registros, impressão de formulários, visões de resumo, envio de e-mail e um monte de outras coisas.
O problema que temos é: vai mudar tudo o que foi feito.... I-M-P-O-S-S-Í-V-E-L. Não tem como. É tudo amarrado demais e ao mesmo tempo mal-amarrado. Dá medo (muito medo) de mudar uma vírgula de lugar, porque ninguém sabe o que vai acontecer no resto do "sistema".
Aí, quando recebi seu e-mail, lembrei que esse tipo de apresentaçãozinha mostrando como montar uma aplicação em Ruby (ferroviário ou não) em 5 minutinhos era a forma mais comum de mostrar seus pontos fortes. Como não conheço nada de Ruby, fiquei pensando se não era só mais um hype, como foi o Notes, e como ainda é o Delphi (na minha humilde opinião). Por isso te perguntei.
E volto a perguntar: e aí, Ruby é RAD ou Ágil? A plataforma Ruby suporta os processos de desenvolvimento ágil (teste, refactoring etc.)? É fácil fazer uma mudança estrutural (ou seja, uma mudança gigante) e garantir que tudo continua funcionando? Ou depende só do talento/experiência do programador (como era há 30 anos atrás no mainframe)?
Minha resposta:
Muito boa sua explicação e melhor ainda o seu questionamento.
Acho que o Ruby é tanto RAD quanto Ágil!
O Ruby, assim como o java, possui uma ótima ferramenta de testes que trás todas as vantagens que a gente já sabe.
Quando se fala de rails as coisas melhoram ainda mais, pois não só existe a parte de testes como ele já tem na sua estrutura tudo organizadinho para os testes, com separação de testes unitários, funcionais e de aceitação.
Existe ainda o conceito de fixtures que nada mais é do que aqueles cenários de testes que a gente escrevia em XML no nosso antigo trabalho só que com o formato YAML. Sem contar que com o uso de um plugin você passa a ter testes no selenium com a possibilidade de escrevê-los em Ruby usando recursos não disponíveis quando se escreve em html.
Existe o mocha, que é o equivalente ao Easy Mock, para auxiliar nos testes.
Devido a característica dinâmica da linguagem podemos fazer algumas coisas em testes que em java ou não são possíveis ou são muito complexas. Para exemplificar:
1 - Algo impossível (nunca consegui fazer) em java e simples em Ruby é "mockar" métodos estáticos.
2 - É possível trocar a visibilidade dos métodos privados facilmente e assim testa-los. Em java é possível, mas muito chato pois envolve reflexão.
Para finalizar em Ruby existe o cruisecontrol.rb que é exatamente a mesma coisa que o de java só que com uma interface web mais bonitinha.
Bem, acho que na parte de testes podemos dizer que é Ágil, de acordo ?
Agora com relação a ferramenta de refactoring realmente o Ruby ainda deixa a desejar pois não faz as coisas de forma tão automatizada quanto o java. Por exemplo, não existe como extrair um trecho de código para um método de forma automática.
Isso é chato? SIM, muito! Porém não é o fim do mundo pois temos o suporte dos testes e como escrevemos MUITO menos código isso acaba ficando mais simples de se fazer.
Então nesse aspecto Ruby não é tão ágil assim mas também não deixa de ser por isso! Certo?
Na parte de automação existe o RAKE que é um similar ao ANT só que novamente o XML é deixado de lado e escrevemos nossas tasks em Ruby mesmo. Acho que nessa parte podemos dizer que é Ágil.
A parte de controle de versão nem precisamos discutir.
Expliquei o porquê considero Ruby ágil, agora tenho que explicar porque ele também seria RAD.
Creio que o Ruby sozinho não seria RAD mas o framework Ruby On Rails definitivamente é. Realmente aquelas apresentações que escrevem aplicações em 10,20 ou 25 minutos deveriam ser encaradas como uma motivação e não para mostrar tudo da linguagem nem do framework pois em quase todas esses aspectos que você questionou são deixados de lado.
É perfeitamente possível se escrever aplicações de forma rápida e bem estruturada com testes, integração continua automatizada e muito mais.
É provável que você não entenda como isso é possível por não conhecer muito a fundo o Ruby e o rails mas vou te explicar umas coisinhas para você ficar mais dentro do contexto.
Um dos principais fatores que permite esse desenvolvimento rápido é o principio de Convention over Configuration onde poupamos muito tempo com configurações simplesmente por obedecer padrões bem simples, como localização de classes, nome de métodos, tabelas e assim por diante.
Além disso o Ruby possui algumas bibliotecas que facilitam muito o nosso trabalho e vou destacar duas que estão presentes no rails (na verdade elas vieram do rails).
1 - Active Record: Ele nos permite relacionar nossas classes de modelo com o nosso banco de dados. Seria algo semelhante ao EJB, HIBERNATE só não é necessário fazer nenhum mapeamento com XML, basta criar a classe com nome composto pelo singular do nome da tabela e herdar do Active Record. Mas isso não é tão engessado como pode parecer, podemos não usar plural e singular, assim como usar um nome de tabela diferente mudando-se duas linhas de código. Ele também permite o mapeamento de relacionamentos de forma bem simples.
Não é necessário mapear os campos com get and set pois ele utiliza o conceito de method_missing para descobrir diretamente no banco de dados os campos e gerar em tempo de execução.
Só para você entender um pouco melhor vou te dar o exemplo de duas classes que estão relacionadas e de uma operação de Create.
class Estate < ActiveRecord::Base
belongs_to :city
validatespresenceof :city_state, :message => "Cidade inválida"
end
class City < ActiveRecord::Base
has_many :estate
end
e = Estate.new
e.name = "Blah"
e.city = City.find_by_name("Rio de Janeiro")
e.save
Com relação ao find usado é semelhante a historia do get and set, ele te disponibiliza em tempo de execução métodos findby_campo. Para resolver o problema do relacionamento basta que na tabela Estate exista a coluna cityid.
2 - Action Pack: Com ele temos uma junção do seu chamelleon com o LABASE, onde temos os conceitos de controller e actions e ao mesmo tempo podemos ter um, ou mais, layouts que dá a cara geral da aplicação e onde só escrevemos o trecho de tela que nos interessa. Ele nos oferece vários helpers para facilitar a construção das nossas views que são chamadas de rhtml e são similares ao JSP e as telas de PHP.
Acho que vale destacar também que em Ruby existe o RJS, onde escrevemos código em Ruby e eles são transformados em javascript tornando mais fácil fazer determinadas coisas em AJAX. Falando em AJAX ele já tem todo o suporte ao scriptaculos, tornando trivial gerar uma tela usando AJAX.
Mestre, eu achei realmente válido esse seu questionamento e espero ter explicado um pouquinho de várias coisas e que você entenda que não é apenas hype, a coisa é realmente boa!
Várias pessoas criticam e defendem outra linguagem sem conhecer e você foi bem coerente em questionar sobre alguma coisa que você não conhece tão a fundo.
Resposta dele:
Ah bom. Legal que as coisas sejam assim. É que eu fico muito, muito preocupado mesmo com o hype que se cria em torno de uma nova tecnologia. E fico com a pulga atrás da orelha sempre que vejo essas apresentações RAD, que pra mim parecem uma enganação (não que o fato de ser RAD em si seja ruim; acontece que estamos fartos de sistemas que começam RAD e viram uma dor-de-cabeça, uma âncora que arrasta uma instituição). Eu gostaria até de sugerir, mais pra vocês do que pra mim (que dificilmente vou usar Ruby algum dia por aqui), que façam apresentações mostrando o lado ágil da plataforma; que comecem com um sistema pronto, que seja grande, e façam alterações PROFUNDAS no mesmo, pra mostrar que aquilo não vai virar um peso com o tempo. Da minha parte (ok, sou uma minoria aqui), eu olharia com bons olhos uma tecnologia que começasse a ser apresentada desta forma, e não da forma RAD.
É uma pena não ter ainda a parte de refactoring bem resolvida. Na verdade, Java também não tem refactoring, quem tem é o Eclipse, o IDEA (será que o JBuilder já tem alguma coisa) etc. O povo do Eclipse não está fazendo nada pra Ruby não?
Quanto ao "Convention over Configuration", já tinha notado que algumas tecnologias caminhavam nesta direção (por exemplo, o XDoclet, que "infere" coisas a partir da cara da classe, mesmo que não estejam explicitamente configuradas como tags). Acho que podiam avançar ainda mais.
Sobre o ActiveRecord, muito legal que uma camada de persistência possa ser construída de forma tão simples. É realmente algo de que qualquer linguagem carece... e o pior é que persistência nem é um problema novo nem raro... TODOS os sistema de informações (e HÁ DÉCADAS) PRECISAM persistir informações. Meu sonho era que isso fosse ainda mais um passo adiante: que só o fato de existir uma tabela no banco de dados já criasse a classe on-the-fly (obviamente com a possibilidade de se programar algum comportamento específico de validação/verificação/aviso/notificação para alteração/criação/remoção de registros) sei lá de que forma, seja por uma máquina virtual pirada, ClassLoader malandreado ou sei lá o quê.
Mas, ainda sobre o ActiveRecord, me chama atenção a necessidade de herdar de uma classe. Espero que Ruby tenha herança múltipla (uma grande falha do Java); porque se só for permitida a herança simples, então o conceito de "super-classe" é um artigo de luxo (já que cada classe pode possuir apenas uma super-classe) e não deveria ser desperdiçado na implementação de um aspecto puramente tecnológico (ao invés disso, esse artigo de luxo deve ser gasto para fins mais nobres, como a implementação da verdadeira hierarquia objetos do mundo real no modelo de dados da aplicação). Obviamente essas considerações morrem se for permitida herança múltipla.
Valeu pelos esclarecimentos.
Mais uma resposta minha:
Mestre, em Ruby existe um conceito de mixin que permite que você faça a herança múltipla. Então esse problema estaria resolvido. Vou bolar um exemplinho e te mando em breve. Me cobra !
Com relação ao seu sonho de on-the-fly ele existe em Ruby! Existe um plugin chamado Magic Model que permite isso.
Tags agile, rails, refactoring, ruby, teste | 8 comentários
Publicado por Marcos Tapajós há
aproximadamente 1 ano.
ERRADO ! Desde pequeno escuto essa frase e acho que nunca tinha parado para pensar muito nisso mas hoje algumas coisas me chamaram atenção. Na verdade acho que tudo começou na semana passada mas como só hoje tive um pouco mais de tempo comecei a organizar minhas ideias.
Como fiquei preso fora da minha garagem e tive que ir trabalhar de metro resolvi ocupar meu tempo na leitura do livro Transformando suor em ouro do Bernardinho que é um livro muito bom pois é muito mais do que uma biografia, é uma lição de vida. São inúmeras as lições que ele escreve nesse livro e sabiamente ele diz que em time que tá ganhando se mexe sim, para continuar ganhando.
Semana passada, em um dos projetos da empresa vimos claramente a importância de mexer em um time que estava ganhando. Após "perder" um tempo numa refatoração possibilitamos que nosso código ficasse tão claro que em poucos minutos tínhamos duas novas funcionalidades com pouquíssimo custo.
É muito fácil entender esse paradigma se você olhar para alguma empresas que eram modelos de sucesso e hoje ou estão falidas ou estão em sérias dificuldades financeiras. Alguém poderia imaginar que empresas como a Mesbla, Estrela ou Mappin fossem falir ? Seria um pensamento do tipo “Já tenho uma marca conhecida, ninguém me pega mais” ?
No desenvolvimento de software constantemente vemos esse tipo de pensamento. É muito comum ninguém querer mexer no que está funcionando mesmo que esse trecho de código esteja completamente confuso ou mal implementado pois afinal de contas ninguém quer ser responsável por quebrar algo que estava funcionando.
Com certeza esse é um pensamento errado, porém compreensivo se você analisar o contexto onde a maioria dos desenvolvedores trabalham. Frequentemente eles estão subordinados a prazos impossíveis onde "perder" tempo numa refatoração é algo inaceitável e com isso esses códigos vão se acumulando tornando qualquer mudança muito arriscada.
Em desenvolvimento de software devemos encarar a refatoração como cuidar da nossa casa. Quando deixamos de cuidar de nossa casa rapidamente teremos uma zona completa. Para evitar que isso ocorra, frequentemente perdemos tempo com pequenas arrumações que tornam nossa vida mais fácil naquele ambiente e nos permite que utilizemos a nossa casa para o que desejarmos sem muitas preocupações.
É necessário ter muita coragem para se mexer em "time que está ganhando" porém em software isso é muito fácil se você fizer as coisas da forma correta. É muito tranquilo fazer modificações no seu código se você tiver uma rede de proteção em testes que garanta que tudo que você está modificando ainda está funcionando da forma esperada.
Tags refactoring, teste, xp | 8 comentários
Publicado por Vinicius Manhães Teles há
aproximadamente 1 ano.
A maioria dos projetos de software se comporta assim:
No gráfico, o eixo vertical representa a velocidade do desenvolvimento, enquanto o horizontal representa o tempo. Interpretando, notamos que a velocidade é alta no início do projeto e cai drasticamente algum tempo depois.
À medida que o tempo passa e mudanças vão chegando, os desenvolvedores começam a fazer alterações na aplicação, sem refatorar o código. Duplicações começam a surgir, métodos começam a crescer, classes passam a conter mais responsabilidades do que deveriam etc. Tudo vai "bem", até que a equipe começa a perder velocidade. Cada alteração no código se torna mais complicada e gera mais bugs. A velocidade, que começou alta, reduz-se rapidamente, até que a equipe não é mais capaz de alterar o software sem causar estragos significativos. Assim se criam os sistemas legados.
Essa é uma armadilha comum, que me faz lembrar uma passagem de Frederick Brooks no livro The Mythical Man-Month:
- Como um projeto atrasa dois anos?
- Um dia de cada vez!
A partir dessa questão, pode-se formular outra:
- Como o código de um aplicativo torna-se impossível de ser alterado?
- Um dia de cada vez!
O problema está nas pequenas decisões que nós, como desenvolvedores, tomamos várias vezes por dia. Toda vez que introduzimos uma gambiarra, estamos incorrendo em débito técnico. É como se pedíssemos dinheiro emprestado. Como em todo empréstimo, um dia a conta tem que ser paga e com juros. Em programação, os juros são altos. Cada pequena gambiarra leva o software em direção a um estado de caos.
Sabe o que acontece quando uma pessoa está sempre endividada? Ela começa a pedir dinheiro emprestado para pagar os juros de empréstimos anteriores. Ou seja, a coisa vira uma bola de neve. O mesmo acontece com o código. O efeito de várias gambiarras sucessivas não é linear, é exponencial. A complexidade que elas adicionam cresce mais rapidamente do que se possa esperar e, eventualmente, a equipe é pega de surpresa quando, "inesperadamente" não consegue mais avançar.
Existem algumas coisas que podem ser feitas para evitar essa armadilha. A primeira é começar o projeto mais lentamente, criando uma boa estrutura de código, especialmente com alta cobertura de testes automatizados. A segunda é aprimorar o design permanentemente, durante todo o projeto, através de freqüentes refatorações.
No produto em que estamos trabalhando, não queremos vivenciar a curva anterior. Ao invés dela, preferímos o gráfico a seguir:
A idéia é produzir pouco código no início do projeto e avançar gradativamente, à medida em que a equipe se integra, compreende melhor o que precisa ser feito, aprende a usar adequadamente as ferramentas e começa a criar uma estrutura que é suficiente para as fucionalidades que estão sendo criadas e mantém-se de forma sustentável ao longo do tempo.
Decidimos que nosso produto será escrito em Ruby on Rails. Por essa razão, investimos boa parte do nosso tempo, no mês de dezembro, implementando algumas funcionalidades prioritárias e experimentando algumas ferramentas, sobretudo ligadas à automação de testes. No ponto em que estamos agora, temos algumas das funcionalidades mais importantes implementadas e 100% de cobertura de testes em toda a aplicação.
Outro ponto importante é começar com uma equipe pequena. Nada é pior do que começar um projeto com uma equipe grande, já que em uma base de código pequena, inevitavelmente "um começa a pisar no pé do outro". No nosso caso, começamos com uma equipe de apenas três pessoas e a idéia é mantê-la nesse tamanho durante muito tempo.
Tags rails, refactoring | nenhum comentário
