Publicado por Vinicius Manhães Teles há
mais de 3 anos.
Há pouco mais de um mês eu e minha esposa fomos a uma festa onde encontramos com um velho amigo em comum, Bruno Siqueira. Embora o Bruno, minha esposa e eu tenhamos todos formação na área de TI, nós nos conhecemos em outro contexto completamente diferente: a dança de salão. Então, raramente conversamos com o Bruno sobre Informática. Porém, dessa vez acabamos falando um pouco sobre isso e fiquei sabendo que ele tinha saído, há pouco tempo, de uma empresa que implantou ISO, MPS.BR e CMMI. Hoje em dia ele trabalha com Scrum. Uma mudança significativa que, obviamente, merecia ser discutida em um novo Improvecast.
Clavius Tales, da Fortes Informática, falou, no último podcast, sobre a experiência de ter passado pelo MPS.BR e depois abandoná-lo em prol do XP. Dessa vez é o Bruno que conta como foi deixar para traz ISO, MPS.BR e CMMI. Atualmente, ele trabalha com Scrum no Tecgraf, Grupo de Tecnologia em Computação Gráfica, criado em 1987 em parceria com o Cenpes (Centro de Pesquisas da Petrobras).
Nessa entrevista, Bruno afirma que aprendeu bastante com os modelos de qualidade, mas depois de ter a oportunidade de trabalhar com Scrum, acredita que está obtendo resultados iguais ou superiores ao que tinha antes, porém com maior velocidade e muito menos esforço. Se depender dele, modelos de qualidade, tais como o que ele tinha que usar no passado, permanecerão sendo apenas parte do seu passado.
Esses foram alguns dos assuntos tratados no Improvecast 17:
- Você trabalhou durante alguns anos em uma empresa que passou pela implantação da ISO, MPS.BR nível F e CMMI nível 3. Na sua opinião, o que motivou a empresa a buscar essas certificações?
- Quando você foi trabalhar nessa empresa, qual era o tamanho da equipe de desenvolvimento?
- Qual o perfil das pessoas?
- Que tipo de projeto vocês estavam fazendo?
- Que plataforma de desenvolvimento era utilizada?
- Qual foi o primeiro modelo adotado?
- Quanto tempo levou a adoção da ISO?
- Qual era a participação dos desenvolvedores no que se referia à ISO?
- O que é o TABA e para que você o utilizava?
- Qual foi o modelo adotado a seguir?
- Quanto tempo levou a adoção do MPS.BR?
- Qual foi a participação dos desenvolvedores durante o processo de implantação do MPS.BR?
- Em que o MPS.BR afetou a vida de vocês?
- Em que o MPS.BR contribuiu para a melhoria da qualidade dos sistemas.
- Como o MPS.BR afetava a motivação dos desenvolvedores?
- Qual a sua visão sobre a avaliação do MPS.BR? O que você observou?
- Depois do MPS.BR, veio o CMMI, certo?
- Quanto tempo durou a implantação?
- O que você identificou de diferente na implantação do CMMI, em relação ao MPS.BR?
- Qual a sua visão sobre a avaliação do CMMI? O que você observou?
- Quais os benefícios, para a empresa, que você identificou com a implantação desses modelos?
- Quais os benefícios, para você, como desenvolvedor?
- Como eram tratadas as mudanças nesses modelos?
- O avaliador tem que ser um exímio desenvolvedor de software para se tornar um avaliador?
- Modelos como o MPS.BR e o CMMI são complexos. Desenvolvimento de software, pela sua natureza, já é uma atividade bastante complexa. É correto tentar atacar essa complexidade intrínseca com mais complexidade?
- Você enxerga alguma situação em que modelos de maturidade como esses sejam realmente válidos?
- Recentemente, Marcos Pereira, desenvolvedor de software do Recife, nos concedeu um depoimento sobre a implantação do MPS.BR na empresa em que trabalha. Entre outras coisas, ele relatou:
- Dezoito meses gastos para obter o nível G.
- Pouca ou nenhuma participação dos desenvolvedores.
- Dezoito meses com grande preocupação com o processo, muito artefato para alimentar o processo, porém na visão dele, pouca contribuição para desenvolver software melhor.
- Outra coisa que ele observou é que quem define o processo não vive as conseqüências dele.
- Além disso, quem tem que seguir o processo, conhece pouco dele, portanto, sente dificuldades em propor melhorias.
- Ele também relatou que houve alta rotatividade dos desenvolvedores durante a implantação do MPS.BR. Ou seja, o MPS.BR, ao menos na empresa dele, não ajudou a reter pessoas.
- Dificuldade e lentidão para incorporar mudanças.
- Ele se queixou de que o processo não era voltado para tratar do aspecto humano do desenvolvimento. Segundo ele, o objetivo era sempre alimentar o processo, ao invés de alavancar o potencial das pessoas.
- Comitê formado por gerentes e pessoas da área de qualidade. Não havia desenvolvedores envolvidos. Pouquíssima participação dos desenvolvedores ao longo da definição do processo.
- Burocracia impele as pessoas a não mudarem de rumo. Então, como atingir qualidade? Na Toyota, por exemplo, qualidade é obtida através de melhoria contínua, ou seja, milhões de pequenas mudanças sendo feitas continuamente. Mas, que incentivos as pessoas têm para mudar em um ambiente considerado burocrático?
- Você também teve essas percepções trabalhando com esses modelos de qualidade?
- Por que você saiu da empresa que usava os modelos de qualidade?
- Agora que você está no Tecgraf, trabalhando com Scrum, quais as principais diferenças?
- Qual o tamanho das iterações?
- Vocês têm feito as reuniões diárias?
- Vocês têm um quadro com post its?
- Então trata-se de uma equipe autogerenciável, certo?
- Lá vocês estão trabalhando com desenvolvimento orientado a testes?
- Como é o processo de integração contínua?
- 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?
- O que mudou com a sua ida para o Tecgraf em termos de satisfação pessoal?
- Qual a sua percepção sobre a qualidade do seu trabalho?
- Você voltaria a trabalhar na empresa anterior?
- Você acha que é necessário ter uma avaliação para se produzir software com qualidade?
Tags agile, cmmi, iso, mpsbr, podcast, scrum, teste | nenhum comentário
Publicado por Vinicius Manhães Teles há
mais de 3 anos.
É 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á
mais de 3 anos.
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 | 9 comentários
