Building Minds - o Blog da OnCast

A OnCast finalmente rende-se a uma forma intuitiva de gestão. Fases em cascata é realmente a melhor solução para atendar às demandas do mercado, tanto emergenciais, quanto grandes projetos que, por terem uma extensa fase de planejamento, conseguem segui-lo à risca.

Nossos projetos agora terão um Gerente de Projeto, que irá centralizar a informação e as decisões. O GP irá delegar ao seu critério para seus subordinados. Caso haja algum problema ou descontentamento, os recursos serão ser trocados imediatamente, a fim de preservar o plano do projeto. O Gerente de Projeto irá comandar as alocações e desalocações de pessoal, com seu WBS e gantt chart, além da geração de artefatos, para todo o fluxo descrito a seguir:

• No início do projeto, com tudo formalizado em contrato, para segurança de todas as partes e definição clara de interfaces cliente/fornecedor, analistas de requisitos irão documentar claramente as necessidades do cliente.
• Em seguida, o analistas de sistemas, assessorados por arquitetos de sistemas, transformarão a visão de requisitos em uma visão de sistema. Tudo muito intuitivo!
• Um arquiteto da informação poderá colaborar com a documentação dos requisitos e entregar macro esquemas de tela junto com os artefatos do analista de sistemas.
• Os designers criarão todas as telas, para que tudo fique claro antes da mera programação.
• Os programadores poderão dividir responsabilidades, preferencialmente por módulos dos sistema. Assim ele será conhecedor do todo seu módulo, de fácil controle. Ferramentas case e proprietárias são priorizadas neste momentos, por sua agilidade e suporte.
• Agora só falta testar! Inicia-se a fase de verificação, quando planos de testes confrontam o resultado da programação e se por acaso algum erro for encontrado, é fácil localizá-lo dada a vasta documentação do projeto e às ferramentas de debug. Neste momento, todos os módulos programados são integrados. A equipe de testes deve ser muito pragmática e apaixonada por trabalho repetitivo e braçal em teclado.
• Em paralelo aos testes, com documentação farta do projeto, o produto começa a ser documentado.
• Por fim, e ainda intuitivamente, o software segue para homologação e produção.
• Após em produção, o sistema começa a sofrer manutenções que começam a torná-lo, muito aos poucos, usável.

O que antes era um tripé incerto na gestão de projetos, Tempo, Escopo e Custo, agora mantém-se fixo e a variável que soluciona a equação é a Qualidade:

• Prazo é impossível alterar, já que o projeto inicia com seu fim anunciado à diretoria, à imprensa e ao mercado.
• Redução do Escopo impossibilita um grande evento de lançamento, pois obviamente é feio o sistema estar incompleto, mesmo que a maioria das funcionalidades não sejam utilizadas nos primeiros meses.
• Quanto ao Custo, nem se fala: quanto menor o investimento, maior o ROI. Não há o que argumentar, pois é pura matemática!
• Já a Qualidade, dá-se um jeito! Boas práticas atrapalham o mundo real. Nem sempre é preciso 3 camadas, desacoplamento e automatização de build e testes. Depois da entrega isto pode ser visto… Em um projeto futuro…

A OnCast, que até agora estava melhorando continuamente, finalmente atinge um ponto de maturidade, finalizando o ciclo de aprendizado. Com a adoção do OnCascade, espero em breve poder dar más notícias…

Adriano Campestrini Metodologia, Riscos

Defino Débito Técnico como a distância entre o estado de um artefato técnico e como ele o seria em seu estado da arte. No ramo de desenvolvimento de software, é a medida de quanto uma deficiência técnica compromete o futuro do projeto e pode ser utilizado para antecipar problemas como bugs, baixa produtivadade, dificuldades com manutenção e dificuldades com transferência de tecnologia. Sua unidade é o spag (Sg), ou spaghetti :).

O termo foi cunhado em 1992 por Ward Cunningham, mas até hoje não há consenso de seu significado. Steve McConnell divide Débito Técnico em duas categorias: Intencional e Não Intencional (leia seu artigo). Uncle Bob em seu artigo “A Mess is not a Technical Debt” fala que um débito técnico não intencional (negligente) não deve ser considerado débito técnico. Martin Fowler subdivide débito técnico de duas maneiras: Prudente/Imprudente e Intencional/Inconsciente, gerando os quadrantes de débito técnico.

Minha classificação é algo como a de Steve. É muito útil determinar a existência de um Débito Técnico apenas avaliando o software em si, sem considerar as condições em que foi inserido. A separação entre intencional e não intencional não pode ser determinada apenas analisando o artefato. Um código mediano não é inapropriado se houve estratégia e todos estão conscientes das consequências da sua inserção.

Logo, a todo código ruim ou mediano dou o nome de Débito Técnico, a todo código que compromete o produto ou o futuro do projeto. É uma métrica direta da qualidade do software. Utilizo a subdivisão Intencional/Inconsciente para identificar se houve/não houve justificativas estratégicas para tal débito. As classificações Prudente/Imprudente dadas por Martin, credito mais à equipe, e não ao débito técnico em si.

Vamos descorrer um pouco mais sobre a distinção entre Débito Técnico Intencional e Débito Técnico Inconsciente.

Débito Técnico Intencional

Fazer o refactoring para abrigar a nova funcionalidade nos custará 5 dias, utilizar a arquitetura atual, mesmo que entortando alguns conceitos, nos custará 1 dia. Nossa entrega é no meio desta semana e a multa por atraso é indecente.

Qualquer gestor responsável diria:

1 dia! Faremos simplista agora! Agendamos um refactoring na próxima release, mesmo que nos custe 10 dias depois.

Existem momentos na vida de um projeto que atingir os deadlines é mais importante que a qualidade. O mundo está cheio de desafios: concorrência acirrada, time-to-market, pressões externas e internas… Não observar estes desafios é a pior das negligências de um projeto. De nada adianta um projeto que não atinge seus objetivos. Conhecer os prós e contras de suas estratégias é primordial para fazer a escolha correta.

Em uma boa equipe Scrum, o Product Owner tomaria esta decisão, principalmente porque conhece as necessidades do mercado. À equipe técnica (team) cabe o papel de levantar alternativas e alertar o Product Owner sobre os prós e contras de cada uma. O balanço entre qualidade e metas é o resultado esperado, bem como um agendamento de refactorings para amortizar o eventual débito técnico resultante.

Débito Técnico Inconsciente

Este débito técnico pode ser incorrido por algumas razões:

• Uma equipe técnica iniciante falha ao enxergar uma solução que não comprometa o futuro do projeto.
• O Product Owner é negligente ao considerar os riscos de suas ações, não considera os argumentos da equipe técnica e falha ao avaliar as necessidades de médio e longo prazo de seu projeto.
• O imponderável, algo que não pode ser antecipado nem por uma equipe sênior. Isto é comum a trabalhos de pesquisa e desenvolvimento de cunho científico.

De maneira geral, acredito que nem todo Débito Técnico não intencional seja negligente. Como visto acima, existem casos em que a complexidade do trabalho irá impor que débito técnico seja naturalmente inserido e permaneça desconhecido por algum tempo. Isto não configura negligência. Entretanto, ignorar o fato de que débitos técnicos serão inseridos é negligência. Cabe à equipe toda monitorá-los e corrigi-los a medida que sejam identificados.

Rodrigo Machado Metáforas, Riscos

Esse refactoring é muito interessante quando feito sobre condicionais que lidam com parâmetros  que podem mudar com freqüência. Esses parâmetros podem ser tipos de relatórios, comandos utilizados para invocar métodos remotamente, estados de uma máquina entre outros.

O objetivo da utilização do polimorfismo é justamente dar flexibilidade e permitir que o sistema evolua (mude) sem precisar adicionar novos blocos de else if no código toda vez que um novo parâmetro for adicionado, alterado ou removido! Sendo assim, não precisa sair alterando todos os blocos if else do sistema, apenas os pontos mais suscetíveis a mudança e que a flexibilidade fará com que as operações de manutenção possam ser mais agradáveis.

Nosso foco são estruturas que dependem de parâmetros para executar ações como por exemplo gerar um extrato. Os extratos podem ser de vários tipos: Semanais, quinzenais, mensais, completos e tantos outros quanto os clientes necessitarem ao longo da vida útil do sistema.

Abaixo, a classe responsável por gerar um extrato utilizando um tipo passado como parâmetro:

Estruturas como essa além de serem procedurais, diminuem a performance do sistema e com o tempo aumentam os custos de manutenção do projeto, contribuindo para um código ilegível (imagine com 50 tipos de extrato) e desmotivante.

Uma forma interessante de resolver o problema é mapear os estados em uma enum e utilizá-la para mapear os estados polimorficamente:

E finalmente podemos refatorar o método condicional da classe que gera extratos para delegar a geração de extratos para as subclasses:

Lembrando que essa é uma forma simplificada da utilização do padrão Strategy, no entanto evitamos a criação excessiva de artefatos (cada estratégia numa subclassse) e utilizamos a enum para fazer esse trabalho.

Rodrigo Branas Arquitetura de Software

Quem acompanha o que acontece no mundo das linguagens de programação, com certeza já ouviu falar de Ruby e não de hoje.

Mas o que essa linguagem realmente tem de especial. Com certeza um post seria pouco para explicar uma linguagem de programação. Além disso, existe um grande número de tutoriais, livros e ebooks que podem dar mais detalhes da linguagem.

Aqui será somente uma breve introdução e um fato importante que podem justificar porque Ruby pode ganhar ainda mais espaço.

Portanto não é a intenção desse post sintaxe, configurações, etc.

Como surgiu?
Ruby surgiu no Japão nos anos 90 e foi desenvolvida por Yukihiro “Matz” Matsumoto.

Matz desejava uma linguagem mais poderosa que Perl e mais orientada a objetos que Python, a partir disso Matz decidiu desenhar a sua própria linguagem de programação.

Um dos conceitos filosóficos de Matz era o de proporcionar ao programador produtividade e diversão ao programar.

Com certeza uma excelente aspecto motivacional, seja para o programador ou para o cliente.
Afinal quem não quer produzir mais em menos tempo e mais feliz?

Influências
É baseada em Perl, Smalltalk, Eiffel, Ada, and Lisp.

Características
Ruby é uma linguagem dinâmica de forma que objetos e classes podem ser alterados em tempo de execução.

Além disso é totalmente orientada a objetos, ou seja, em Ruby tudo é um objeto.

Possui suporte nativo de expressões regulares, sobrecarga de operador e garbage collector.

Isso são somente algumas das características da linguagem que vem sendo muito comentada, não somente pela comunidade Ruby mas também por pessoas influentes da área de desenvolvimento de software.

Recentemente Martin Fowler publicou um artigo descrevendo a experiência da ThoughtWorks com Ruby.

Bom só o fato de saber que Martin Fowler está interessado em Ruby e em Rails já é deveria ser motivo de atenção por parte da comunidade de desenvolvimento de software.

Porém o que realmente chama a atenção são os comentários positivos que Fowler fez em relação a linguagem e ao framework Rails de acordo com utilização de ambos na ThougtWorks.

We have found that Rails makes much of the repetitive part of web application easier and quicker to do - but the more involved stuff remains.
All of these questions sum up into the key question for us: is Ruby (and Rails) a viable platform for us and our clients. The answer thus far is a resounding “yes”.

Segundo Fowler Ruby favorece o desenvolvimento de software utilizando metodologias ágeis:

Ruby also fits in with our preference for using agile software development processes. The agile philosophy is one of rapid feedback by building software and reviewing it regularly with the customer. The more productive an development environment, the more frequently you can review progress, and the better the agile “inspect and adapt” process works.

Vale ressaltar também alguns aspectos sobre a relação de Ruby com produtividade e com os desenvolvedores:

One thing we have seen is that you shouldn’t expect these productivity increases to turn up right away. I’ve heard several times that people were alarmed in early weeks about the slow progress of a new Ruby team - a consequence of what I call the Improvement Ravine. It does take time for a Ruby team to get the hang of how the platform works and during that time they’ll be slower than you expect.

Our experience selling Ruby work is that using a dynamic language like Ruby fits in well with our overall appeal. Our strength is that we hire highly talented people who are difficult to attract to the typical IT organization. Ruby has a philosophy of an environment that gives a talented developer more leverage, rather than trying to protect a less talented developer from errors. An environment like Ruby thus gives our developers more ability to produce their true value.

Somente alguns itens do artigo foram citados, alguns aspectos negativos da linguagem e problemas que a ThoghtWorks teve também estão presentes do artigo original.

Obviamente a leitura do artigo e um estudo maior da linguagem, assim como a  utilização de Ruby e Rails podem dizer se essas ferramentas são adequadadas para o desenvolvimento de uma solução especifíca.

Fontes:
http://en.wikipedia.org/wiki/Ruby_(programming_language)
http://martinfowler.com/articles/rubyAtThoughtWorks.html

Links:
http://www.ruby-lang.org/en/
http://rubyonrails.org/

André Branco Ferramentas