Essa é uma das respostas do Márcio Tierno no grupo UML-FATEC, sobre a eterna discussão sobre qual a melhor plataforma de desenvolvimento: Java ou .NET.

Sei que esse assunto de quem é melhor Java x .NET é quase como discutir sobre religião. Mas o problema sobre produtividade no desenvolvimento de software é uma questão de foco, ou melhor, o problema não é tecnológico e sim estratégico.

“Um pouco de números para tentar dar um pouco de prumo a essa discussão:

1 – 80% dos negócios do mundo rodam em cima de programas COBOL. Nem Java nem .NET vão decidir o futuro da humanidade, portanto.

2 – Nunca vi um sistema que não pudesse ser implementado em qualquer linguagem que seja. Portanto, a discussão Java x .NET não se decide na esfera técnica.

3 – Produtividade – não é criando grids para acesso direto a tabelas que se mede produtividade, mas sim no tempo total que leva para uma idéia sair da cabeça do usuário de negócios até se transformar em um sistema rodando no ambiente de produção, testado, aprovado e homologado. Numa “competição” Java x .NET, é certo que ambas as tecnologias chegariam empatadas “na margem de erro” caso se considerasse todo o ciclo de vida de um sistema.

4- Ainda em produtividade, só de 15% a 20% do tempo é gasto efetivamente em implementação. O grosso do esforço é gasto em levantamento de requisitos e testes.

Por falar em produtividade, só 30% do tempo do programador é gasto em desenvolvimento de fato, em média. O resto é perdido em debugging ou reescrevendo requisitos que foram mal-entendidos (e mal-explicados, por conseguinte). Pare e pense na sua rotina diária e veja se vc discorda desses números.

Assim, 20% X 30% = 60% do tempo total de um projeto em desenvolvimento REAL. Supondo que uma das duas tecnologias fosse 50% MAIS PRODUTIVA do que a outra (e nenhuma delas o é), o impacto final seria de 3% sobre o tempo total do projeto. Quase indetectável.

Assim, o desafio proposto perde a validade em si. Até porque ninguém vai sair “convertido” de um evento desses. Agora, um desafio de ponta a ponta, num prazo de algumas semanas, por exemplo, esse sim teria valia. Mas já não seria mais um desafio Java x .NET, mas, talvez, um desafio MDA x AMD (tipo Together) x Agile (S. Ambler), por exemplo.

4 – Decisões estratégicas – Há uns 20 anos, mais ou menos , o Natural/ADABAS ganhou um grande mercado do COBOL, porque era muuuito mais produtivo e fácil de mexer. Hoje quem tem Natural/ADABAS quer morrer, porque a Software AG está cobrando os tubos (zilhões de dólares) pela renovação das licenças e a tecnologia é “imigrável”. Paralelo com .NET, proprietário como Natural/ADABAS. Erro estratégico.

Outro exemplo: há 30 anos, C prometia ser o que Java promete hoje. Se alguém algum dia teve um sistema de negócios escrito em C, então deve ter uma boa história de migração urgente para contar. Paralelo com Java, “assembleísta” como C. Outro erro estratégico.

Então, amigos, tecnologicamente falando, Java e .NET se equivalem.

Não consigo imaginar um sistema corporativo (que é o que interessa, afinal) que possa ser feito em um, mas não no outro. Ou que saia muito mais rápido em um do que no outro.

Portanto, o cerne da questão é estratégico, não tecnológico.

E todos os xiitas são gentilmente deixados de lado nessas discussões.

De minha parte, entre Java e .NET, fico com arquitetura de software, MDA e Governança de TI.

Na guerra entre as partes, prefiro vender a munição.

Márcio Tierno (mtierno.rm): é atualmente responsável por toda a divisão de testes funcionais da Inmetrics. Atua na área há 16 anos, tendo trabalhado em empresas como Compuware do Brasil, IBM, Rational Software, BCP Telecomunicações, entre outras. Cursou Ciência da Computação na Unicamp, é certificado ITIL Foundations e Rational Requirements Mngt. Marcio já prestou consultoria e ministrou dezenas de treinamentos em Ger. de Projetos, Requisitos e demais disciplinas de desenvolvimento para empresas como Serpro, Xerox, BankBoston, Banco Itaú, Banco Votorantim, Cargill, Porto Seguro e outras de grande porte, no Brasil e no exterior.

O Serpro liberou ontem, 14, o código-fonte do framework integrador Demoiselle para Java, solução que busca a padronizar o desenvolvimento de software para o governo federal.

O Demoiselle será utilizado como ferramenta base para desenvolvimento por todas as empresas que fornecerem software à administração pública. Seu principal objetivo é padronizar as soluções tecnológicas do governo federal, a fim de garantir interoperabilidade e geração de software livre.

“A adoção de uma única ferramenta que opera com reaproveitamento de códigos e utilização de padrões dará mais velocidade e interoperabilidade entre os sistemas dos diferentes ministérios e autarquias do governo federal”, informa Marcos Mazoni, diretor-presidente do Serpro.

Demoiselle
O Framework foi construído com as premissas de ser extensível, fácil de usar, estável, configurável, confiável e ter sua documentação publicada. A intenção do Demoiselle é atingir padronização, redução da curva de aprendizagem, maior produtividade, simplificação dos processos, reutilização de códigos e uma manutenção simplificada.

Para o Estado, significa dizer que a utilização de um Framework padrão gera celeridade nos serviços de governo eletrônico, independência tecnológica, redução de custos na construção e manutenção de sistemas de e-gov, investimento em informática pública e software livre.

Antonio Carlos Tiboni, coordenador do projeto Demoiselle, analisa que a nova tecnologia permitirá que pequenas empresas tenham melhores condições de prestar serviços ao governo. “Outro destaque é o aumento da eficiência, já que o reuso reduz significativamente as chances de erros na escrita de códigos”, completa.

A comunidade Demoiselle
O Demoiselle será mantido em comunidade, totalmente aberto e compartilhado, permitindo que diferentes entidades e instituições contribuam e sejam beneficiadas pelo reuso de código possibilitado pela componentização e pelos padrões e direcionamento tecnológico definidos pelo framework.

Acesse https://sourceforge.net/projects/demoiselle/ e conheça a comunidade.

Framework
O framework é um conjunto de classes utilizadas para auxiliar o desenvolvimento de um sistema, é uma abstração que une códigos comuns entre vários projetos de software provendo funcionalidades genéricas.

Fonte: SoftwareLivre.org

Criei uma comunidade no Orkut, que visa reunir os interessados nas metodologias ágeis aqui no Brasil, bem como servir como um canal na construção e disseminação de pensamentos e experiências sobre desenvolvimento de software, liderança de equipes e práticas ágeis.

Se você tem interesse em discutir assuntos relacionados a Agile, XP, SCRUM, Crystal etc, este é seu lugar. Participe. O link para a comunidade é:

http://www.orkut.com.br/Main#Community.aspx?cmm=79179953

Por Guilherme Chapiewski
em Abril 15, 2009

Ultimamente tenho feito uma brincadeira que todos ficam achando que eu sou maluco. Costumo dizer que o meu objetivo a cada dia é tentar fazer com que todo o trabalho que eu faria em 2 dias seja feito em apenas 1 hora, e assim eu posso aproveitar as outras 15 horas escrevendo posts no meu blog, estudando coisas novas, jogando Guitar Hero ou até mesmo dormindo (se eu não tivesse insônia).

Parece loucura mas não é. Quando eu ainda era um jovem Padawan um dos vários mentores que tive ao longo da minha vida me ensinou uma lição muito valiosa.

Há bastante tempo atrás, observando um amigo trabalhar percebi que ele passava horas e horas automatizando cada pequena tarefa que faziamos na empresa. Se precisavamos criar uma entrada no DNS, tinha um script para fazer isso. Se precisavamos fazer backup, existia um script para fazer isso e ele até já funcionava sozinho. E no caso dele, ele tinha scripts prontos até para facilitar fazer as compras do mês no Zona Sul online (isso é sério mesmo). Basicamente ele era obsecado por automatizar tarefas.

Como ele passava a grande maioria do tempo automatizando coisas, um dia eu resolvi perguntar porque ele perdia tanto tempo fazendo aquilo. Não era apenas uma obsessão sem sentido, tinha um fundamento muito simples. Ele disse: “Quanto mais você trabalhar para tornar a sua vida mais fácil automatizando as tarefas repetitivas, mais você terá tempo livre para fazer mais coisas que você quiser! Fazendo assim você vai ter tempo de sobra para investir nas tarefas realmente desafiadoras, que vão exigir toda sua intelectualidade e que vão te dar prazer. É por isso que eu sempre trabalho com a meta mental de reduzir todo o trabalho que eu faria em 2 dias para 1 hora, e fazendo assim todo o dia e a todo momento as coisas simplesmente vão acontecer; e eu vou produzir muito mais que qualquer um sem absolutamente nenhum esforço”.

Eu sempre achei isso genial! Obviamente ele não passava 15 horas de bobeira fazendo outras coisas. O objetivo era apenas estabelecer uma meta agressiva de automatização de tarefas para conseguir alcançar um nível onde muitas coisas podem ser feitas com pouquissimo esforço, e a brincadeira de “passar 15 horas de bobeira” serve apenas para ilustrar e tornar o exemplo mais divertido.

Desde essa época eu venho usando essa abordagem para o máximo de coisas que eu consigo. Meu problema sempre foi que eu nunca tentei de verdade ser tão extremo quanto ele (ao ponto de automatizar até as compras do mês), mas de uns meses pra cá eu tenho sido cada vez mais e mais radical e tenho me tornado cada vez mais produtivo (apesar de ainda ir fisicamente no mercado fazer compras).

“Radical” e “extremo” são palavras que têm uma conotação muito negativa, mas ser radical ou extremo pode ser muito útil quando se tem um propósito como esse (ou então para se fazer uma abordagem como a que eu postei sobre porque eu não gosto de escrever comentários no código).

Em projetos de desenvolvimento de software, os ganhos com uma abordagem desse tipo são impressionantes. No último projeto que comecei (e que estou atualmente) propús para os meu amigos do time que tentassemos fazer uma abordagem desse tipo – radical e extrema – em relação a automatização. A regra que criamos juntos e concordamos ficou bem simples: se alguma coisa precisou ser feita mais de uma vez então ela necessariamente deve ser automatizada.

Depois de aproximadamente 3 semanas de trabalho as coisas funcionam mais ou menos assim:

• Todos os testes unitários e de aceitação são automatizados e podem ser rodados com apenas um comando (desde criar/atualizar banco de dados até subir Selenium Server, colocar o sistema em um estado conhecido, executar os testes e depois desfazer isso tudo).
• Toda vez que é feito um push para o Git, o build server roda primeiro todos os testes unitários automaticamente.
• Se qualquer um dos testes falha, uma sirene toca automaticamente alertando que alguém fez besteira.
• Se os testes passam, o Capistrano faz um deploy em cada uma das máquinas do ambiente de testes de aceitação e dispara a execução de todos os testes de aceitação nesse ambiente.
• Se o banco de dados mudou, o upgrade do schema de banco de dados também é feito automaticamente.
• Finalmente, quando todos os testes passam, é feito um deploy automatico para o ambiente “live”, que tem por objetivo ser o lugar onde se pode ver a última versão de desenvolvimento que passa em todos os testes.
• Se precisarmos colocar a aplicação em produção, um script fará isso da forma mais simples, segura e instantânea possível.
• Se um desenvolvedor precisar desenvolver nesse projeto, basta baixar o código do repositório e com um script tudo se configura e funciona automaticamente.
• Se for preciso criar uma nova tela de cadastro padrão desse sistema, basta rodar um script e ela será quase toda criada automaticamente (apenas as particularidades precisam ser configuradas).
• … e por aí vai.

Todas essas coisas juntas não foram simples de serem feitas, muito pelo contrário, foi bastante trabalhoso (e até chato algumas vezes). Porém, o resultado não deixa dúvidas: o ganho de performance é absurdamente alto e vale a pena cada minuto gasto investido.

No início levamos muito tempo automatizando tudo mas depois dos primeiros 3 ou 4 dias qualquer coisa passou a levar bem menos tempo do que levaria. Em pouquissimo tempo (algo em torno de 3 semanas, como eu disse) já é possível perceber resultados concretos dessa abordagem. Apesar de ainda termos um monte de coisas para melhorar, nossa agilidade para fazer coisas simples e vê-las funcionando é muito grande!

Não gaste seu nobre tempo fazendo coisas repetidas e chatas. Automatize tudo que puder! Faça os scripts trabalharem pra você!!!

Fonte: Guilherme Chapiewski

Postado por Vikas Hazrati, traduzido por Acyr Tedeschi em 13 Abr 2009 11:29 AM

Tradicionalmente (o termo) Governança de Projeto é utilizado pra descrever o conjunto de regras e processos necessários para garantir o sucesso de um projeto. Tenta tratar o projeto de trabalho como um processo de trabalho. Entretanto, a importância dada à utilização de folhas ponto, custos e horário superam em muito questões mais importantes como: benefícios do projeto, controle de risco, envolvimento de recursos humanos, qualidade, escopo e controle de objetivos. À primeira vista os conceitos de governança e de Metodologia Ágil parecem ser incompatíveis, entretanto, muitos "Agilistas" concordarão que Governança pode fazer mais bem que mau aos projetos Ágeis.

Andrew Clifford sugeriu os seguintes benefícios da governança,

• Aumento do valor das ações porque sistemas de TI são tratados como patrimônio dos negócios.
• Melhora na relação de TI com a empresa porque as exigências de infraestrutura de TI são traduzidas para objetivos mensuráveis.
• Aumento no retorno dos investimentos em TI porque, com o gerenciamento, sua utilização é mais eficiente.
• Redução de erros de projeto porque assuntos técnicos e de aquiescência são identificados mais cedo.
• Custo com implementação de novas regras e padrões internos é reduzido porque são controlados em um ambiente de trabalho eficiente.
• Redução de riscos de longo prazo e de custos devido a fragmentação de padrões porque o gerenciamento tem visibilidade do grau de cumprimento.

Riscos e custos com ‘long-term’ são reduzidos devido a fragmentação de padrões porque o gerenciamento tem visibilidade da diminuição de aquiescência.

• O desempenho da TI é melhor medido enquanto atua como administrador dos sistemas de negócio, o que é particularmente importante para contratos de terceirização governamentais.

Matthew D. Laudato sugeriu que embora governança frequentemente seja um trabalho difícil de aceitar, os benefícios oferecidos à TI precisam ser contabilizados pelo VP ou CIO. Ele recomenda que Governança deve fazer parte do processo Ágil. De acordo com ele,

Faz sentido adicionar um passo ao processo de ‘Sprint Review Time’ (a avalização feita no final de cada sprint) para formalmente documentar o progresso do projeto de forma que seja útil para o resto do negócio. Neste relatório devem estar incluídos, pelo menos, quais características foram completadas, seus custos, seus planos de contingência e que percentual de requerimentos conhecidos foram satisfeitos até aquela data.

Takeuchi e Nonaka da Toyota, tiveram a seguinte opinião sobre governança

Apesar das equipes agirem por conta própria na maioria das vezes, não são incontroláveis. Gerenciamento estabelece pontos de checagem suficientes para prevenir instabilidade, ambiguidade e tensão que podem tornar em caos. Ao mesmo tempo, o gerenciameno evita o tipo de controle rígido que prejudica a criatividade e espontaneidade. Ao invés disso, a ênfase é em “auto-controle”, “controle através de pressão de pares” e “controle por amor

Segundo Ross Pettit, Agovernança Ágil veio pra responder duas questões:

• Estamos agregando valor ao nosso dinheiro?
• As soluções entregues satisfazem todas as expectativas?

A primeira questão trata sobre a efetividade do dinheiro gasto tentando responder às questões, com fatos, sobre medições com amplo escopo, trabalho completo, gastos totais e  verificando tendências com precisão. A segunda questão é sobre a capacidade que a solução tem em acompanhar a variedade de políticas corporativas, incluindo segurança, arquitetura, qualidade, riscos e etc. Ross sugeriu que uma boa governana deve conduzir a:

Uma redução de "surpresas," melhora na confiança e credibilidade, execução alinhada com a estragéia – faz a TI gastar menos esforços com seus próprios problemas e, consequentemente, ser mais responsiva ao negócio.

Desse modo, existem justificativas suficientes sobre a importância da governança e sobre os benefícios que ela pode trazer ao projeto, porém, qual é a melhor maneira pra introduzí-la em um projeto Ágil?

Ross sugere a seguinte abordagem,

• Se governança deve servir como facilitador para agilidade, não pode ser um fardo para as operações diárias. Pra resolver isso, devem existir maneiras consistentes e não-burocráticas de coletar dados pela organização.
• Para avaliar a plenitude da solução, a governança de TI deve manter participação ativa no departamento inteiro, incluindo segurança, infraestrutura, arquitetura, controle de riscos, gerenciamento de negócios, o PMO e etc. Subsequentemente, deve existir participação de todas as disciplinas de TI.
• Governança de TI não poder se transformar num esoterismo religioso, tão pouco transformar-se em "parte da decoração." Nós precisamos ser capazes de comunicar com todos os stakeholders usando a "língua deles," e mais importante, utilizar termos empresariais ao dirigir-se aos negócios.

Dean Leffingwell sugeriu a seguinte abordagem ao definir um processo de governança leve. Segundo ele, o modelo de governança deve.

• Criar diretrizes Ágeis definindo o quê a Metodologia Ágil significa para a empresa e definir, de modo inequívoco, mandatos em termos de testes unitários, retrospectiva, standups, etc.
• Possuir de 3-5 páginas.
• Recomendar mas não determinar.

Desta maneira governança Ágil serve como uma perfeita cola entre gerenciamento e TI. A chave é não exagerar até matar a criatividade e o entusiasmo do ambiente Ágil.

Fonte: InfoQ

13/04/2009 — Eros Viggiano

Atualmente, existe uma aparente tensão entre a comunidade de praticantes de métodos ágeis e arquitetos de software ortodoxos. Os chamados agilistas entendem que os arquitetos produzem “muito papel”, enquanto que mudança nos requisitos (principalmente arquiteturais) provoca incômodo a alguns arquitetos de software em qualquer estágio do projeto. Comentaremos rapidamente alguns mitos de agilidade versus arquitetura de software.

(*) Esta é uma resposta atribuída a Kent Beck em OOPSLA 1992, segundo Philippe Kructhen.

Nossa convicção é que a disciplina de arquitetura de software pode contribuir para a redução de riscos técnicos mesmo em projetos que empreguem métodos ágeis. Para tal, em primeiro lugar, os trabalhos arquiteturais devem respeitar a natureza evolutiva de tais projetos. Em segundo, deve se ater a comunicar modelos arquiteturais apenas na medida exigida pelo método. Por exemplo, se a filosofia de desenvolvimento prega abandonar diagramas após a realização no modelo através do código, o arquiteto assim deve proceder. Outra situação: caso a equipe não faça uso de ferramentas CASE ou de modelagem avançadas, o arquiteto pode considerar a modelagem coletiva usando um quadro ou flip chart. 

Fonte: De Architectura

CIO de provedora norte-americana conta os motivos que levaram à contratação e à demissão de um enterprise arquitect

Sunil Shah, da CIO Índia
Publicada em 13 de abril de 2009 às 08h05

Fora os jargões e as diferentes nuances do cargo, o arquiteto profissional (ou enterprise architect, em inglês) é basicamente o profissional que entende as necessidades do negócio e descobre tecnologias adequadas a essas demandas. Ele tem como objetivo abolir silos, melhorando os modelos de colaboração e alinhando a TI aos negócios. Além disso, deve traduzir o ‘tecniquês’ em uma linguagem compreensível para toda a corporação.

Todas essas atribuições não deveriam ser do CIO? Não, de acordo com Alok Kumar, CIO da Reliance Infosolutions – provedora de serviços norte-americana. Se, hoje, as organizações de grande porte têm centenas de bases de dados e muitos silos, ele analisa: “é o próprio CIO que criou esse cenário. Assim, existe a necessidade de que alguém do time dele corrija isso.”

Kumar conta que essa realidade levou a Reliance a contratar um arquiteto profissional em meados de 2007. De acordo com o executivo, na época, existia a necessidade de trabalhar com uma arquitetura que fosse mais robusta e escalável, mesmo com múltiplos departamentos e equipes.

Além dessas responsabilidades, o novo arquiteto foi alocado para analisar o hardware e a base de dados em uso, bem como as aplicações, com o intuito de garantir o máximo de eficiência para os casos de necessidade de atualização ou de incorporar novas funcionalidades. “A idéia foi garantir que todo o sistema fosse flexível”, reforça Kumar, citando que isso também facilita a criação ou a compra de novos aplicativos.

Apenas um ano depois da contratação, por conta do cenário de crise econômica, a Reliance decidiu dispensar seu arquiteto. “Existem pessoas que não agregam valor em momentos de emergência. Eles conseguem melhorar as coisas, mas não olham para as questões que, normalmente, são cruciais para a organização em períodos de crise”, cita o CIO.

Outro motivo para a companhia optar por abrir mão do arquiteto foi a dificuldade de provar o retorno sobre o investimento que esse profissional poderia trazer para a companhia. “É difícil para um enterprise architect mostrar o trabalho dele para quem define o destino dos investimentos e que tem pouco entendimento da TI”, cita Kumar, que complementa: “Na crise, as empresas pensam apenas em resultados e vão perguntar ao arquiteto o que ele faz? E a resposta vai ser: ele cria diagramas.”

Mesmo com todos os problemas para justificar a contratação de um arquiteto profissional, o CIO da Reliance acredita que essa figura é indispensável para o bom trabalho da TI em organizações que trabalham com muito desenvolvimento ‘in house’.

“Os arquitetos são uma boa escolha quando existem diversos sistemas, dados e regulamentações”, conclui Kumar, citando que o salário de um bom profissional nessa área começa em US$ 69 mil por ano.

Fonte: CIO

O CodePlex é um portal onde você pode hospedar, gratuitamente, projetos de software, gerenciar grupos de desenvolvimento, acompanhar problemas e tudo que envolve a criação de uma aplicação. Este repositório hospeda projetos gratuitos e pagos. A empresa proprietária deste repositório de projetos é a Microsoft (que já possui duas licenças open-source).

Sara Ford hoje é gerente de programas do portal CodePlex. Sara é mais conhecida como a moça das dicas diárias sobre Visual Studio em seu blog desde Julho de 2007.

Este post de Sara Ford narra sua experiência na transição de Gerente de Projeto do Visual Studio durante 6 anos, utilizando métodos tradicionais de gerência, para Gerente de Projeto do CodePlex, utilizando Agile.

Fonte: Sara Ford’s Weblog

Por Manoel Pimentel
em Abril 11, 2009

Durante o evento Maré de Agilidade em Salvador (Bahia) em março de 2009, tive a oportunidade de entrevistar Fábio Rilston (Consultor de Qualidade), sobre como que a empresa pública SERPRO adotou metodologias ágeis através de algumas combinações de Scrum, XP e OpenUP para melhorar o processo de desenvolvimento de alguns produtos usados na esfera governamental.

Fonte: Blog Visão Ágil

A comunidade brasileira está andando rápido, recentemente tiveram vários lançamentos muito legais para todos os rubistas.

Primeiro, o Rodrigo Urubatan lançou mais um livro em português de Ruby on Rails, o Desenvolvimento Fácil e Rápido de Aplicações Web.

O Carlos Brando e mais um pessoal criaram a versão brasileira do conhecido site Ruby Inside, que sempre trás as melhores notícias do mundo Ruby e Rails. A melhor forma de se manter atualizado. Esse site nasceu na Inglaterra, pelo Peter Cooper, e se tornou um grupo de sites de notícias especializado em Ruby, Rails, JRuby e mais.

Depois de quase 1 ano em tradução e revisão, o livro O Guia (Comovente) do Why, um dos melhores livros para iniciantes em Ruby também foi lançado. Você pode ler online todo o conteúdo em português e começar a aprender não só a linguagem mas também o “estilo” do _Why, um dos programadores mais irreverentes da comunidade.

Finalmente, saiu uma versão “beta” da tradução do Rails Guides. Se não me engano começou com o Cassio Marques e logo envolveu mais tradutores da comunidade. Para quem não conhece, o Rails Guides nasceu de um esforço paralelo do Pratik Naik, um dos Rails Core, como resposta à antiga reclamação de “Rails é mal documentado”. Pois bem, este guia definitivamente derruba isso pois ele cobre todos os aspectos do Ruby on Rails, em detalhes, de maneira simples de seguir. Qualquer um que estiver aprendendo Rails irá se beneficiar. Mas ainda não acabou, se você quiser participar, entre em contato com eles.

Se você está iniciando, estes são excelentes materiais. E não deixe de participar do grupo Rails-br, ou, se é de São Paulo, participe do Guru-SP. Além dos fórums do RubyOnBR.org.

Fonte: %w(Akita On Rails) * 2.0