Meu amigo Manoel Pimentel me fez este questionamento hoje e me pediu para que brevemente explicasse o que penso a respeito da essência do desenvolvimento ágil.

Penso que a real essência de ser ágil está em como nos relacionamos com o nosso próximo. Ao longo dos anos, aprendi que entender os princípios que sustentam as práticas, dominar as ferramentas de gestão, conhecer profundamente e aplicar as técnicas de engenharia são itens que estão entre os essenciais no desenvolvimento ágil. Entretanto, observo que ao aplicar o desenvolvimento ágil, muitas empresas pecam por não equilibrar corretamente as forças entre princípios, cultura, gestão e engenharia. Certamente, entender as necessidades em cada uma destas áreas é muito difícil e isto só pode ser alcançado com uma comunicação fluida entre os diversos setores da empresa. Comunicação fluida, todavia, não dignifica memorandos, e-mails, gráficos ou qualquer coisa do gênero. Comunicação fluida é a conversa franca e direta, de modo que possa criar relacionamentos fortes. Ainda, a predisposição de ambos os lados para entender os motivos alheios e a colaborar mutuamente em busca de um único objetivo é imprescindiível para se obter o sucesso. Portanto, concluo que não há como atingir o sucesso no desenvolvimento ágil de software sem que construamos relacionamentos empáticos e verdadeiros, sendo esta, em minha opinião, a pura essência do desenvolvimento ágil.

Samuel Crescêncio Sem categoria comunicação cultura essência ágil

No segundo grau todos aprendemos sobre o conceito de “entropia” na física e química. Entropia neste contexto está associada com a capacidade de um sistema mudar espontaneamente de estado. Quanto menor a entropia de um sistema, mais chance o mesmo tem de mudar; quanto maior a entropia, menos chances de mudar, ou seja, o sistema é mais estável.

Um fato importante sobre a entropia é que, em um sistema isolado, ela nunca decresce. Isso significa que o sistema sempre tende para o estado mais estável. Para exemplificar, considere uma mistura de água e açúcar: o açúcar tende a se dissolver na água (uma mudança espontânea), mas o contrario é improvável de acontecer, pois a entropia do sistema já dissolvido é maior do que a entropia inicial.

Mas o que isso tudo tem a ver com desenvolvimento de software? Encarando o software desenvolvido como um sistema físico, a conclusão lógica é que, se não houver um gasto de energia para manter a entropia baixa, o sistema tende à estagnação. Quanto maior a entropia do software, mais difícil ter mudanças no mesmo.

Aproximando a idéia de entropia para a metodologia Scrum, podemos fazer uma associação com as máquinas de movimento perpétuo. A idéia da máquina é que ela gere uma quantidade de energia igual ou maior do que a energia necessária para a mesma funcionar, formando assim um ciclo de retroalimentação infinito. Ora, como a entropia de um sistema isolado sempre cresce, uma máquina com este funcionamento é teoricamente impossível. E é por isso que no ciclo do Scrum existe o conceito de melhoria continua.

A melhoria continua representa uma injeção externa de energia que torna possível a existência de um processo como o Scrum. Essa energia é necessária para que a equipe de desenvolvimento consiga se adaptar e abraçar as mudanças (quem trabalha com desenvolvimento sabe que essas mudanças acontecem mais do que muitos desejariam).

Para deixar claro, imagine uma equipe X já estabelecida (com conhecimento no domínio e na tecnologia) que quer aumentar a velocidade de desenvolvimento. A velocidade sempre tende a se estabilizar; as pessoas não vão programar mais rápido por que um cliente pediu, ou por que um gerente fez uma ameaça. Se a velocidade mudou, alguma outra variável mudou no sistema. O exemplo mais óbvio é a perda de qualidade do código: testes deixam de ser escritos, a comunicação com o cliente é prejudicada (desenvolvedores fazem mais suposições sobre o domínio do que deveriam). Outras possibilidades são a mudança da tecnologia usada (frameworks, ou mesmo a linguagem), melhoria no conhecimento dos desenvolvedores, ou mudanças relacionadas ao processo de desenvolvimento.

As mudanças no processo são o que fazem o Scrum funcionar para equipes tão heterogêneas (e que geram reclamações relacionadas às certificações). O Scrum deve ser modificado para se adaptar as equipes, e não só no início de um projeto, mas durante cada iteração. O projeto deve servir como um laboratório: quando a equipe se sentir confiante, mudanças no processo devem ser inseridas (de preferência uma de cada vez) para gerar oscilações na entropia. Como os sprints no Scrum são relativamente pequenos, se a mudança for negativa ela pode ser rapidamente revertida. Se a mudança for positiva, ótimo! Em ambos os casos, a mudança serviu como experiência para a equipe, e ela agora tem mais conhecimento sobre o processo e sobre as suas próprias limitações. No pior dos casos, a mudança serve para que os membros da equipe não fiquem acomodados.

Para identificar possíveis mudanças pode-se usar as retrospectivas, identificando pontos fracos a serem remediados e também os pontos fortes a serem reforçados. Retrospectivas, porém, são um assunto para outro post.

Renato Besen Ferramentas, Metáforas Entropia, Mudanças

A OnCast Technologies em parceria com a TestAnyWhere traz à Florianópolis um especialista na área de usabilidade para agregar ainda mais know how para você. Faça parte do próximo Programa de Capacitação da OnCast!

CURSO: Avaliação de Usabilidade: Teoria e Prática

OBJETIVO: Este curso tem como objetivo capacitar os profissionais nos princípios e melhores práticas de usabilidade, bem como, nas técnicas de avaliação mais importantes da atualidade.

PÚBLICO ALVO: Profissionais da área de tecnologia da informação, como gerentes de projeto, analistas de negócio, analistas de sistemas, desenvolvedores, designers gráficos e profissionais da área de teste de software (líderes, analistas, arquitetos e testadores).

EMENTA:

1)  Usabilidade - Uma Introdução:

- O que é Usabilidade?

- Porque Usabilidade?

- Usabilidade e Negócios

- Design Centrado no Usuário

- Tipos de Avaliação de Usabilidade

2) Técnicas Preditivas:

- Introdução

- Avaliação Heurística (Nielsen)

- Avaliação Heurística (Bastien & Scapin)

- Aplicação de Checklists

3) Técnicas Objetivas:

- Introdução a Testes com Usuários: Planejamento de uma Avaliação – DECIDE; Escolhendo os Usuários; Métricas para Usabilidade; Planejando as Tarefas; Escolhendo os Avaliadores; Conduzindo uma Avaliação de Usabilidade; Questões Éticas.

- Card Sorting

- Testes Empíricos Tradicionais

- Protocolo Think-Aloud

- Teste de Comunicabilidade

4) Técnicas Prospectivas:

- Introdução

- Questionários

- Tipos de Questões

5) Ferramentas de Apoio:

- Keyloggers

- Capturadores de Tela

- Heat Mappers

- Eye Trackers

- Gerenciadores de Teste

- Prototipagem

- Questionários

- Storyboarding

- Card Sorting

INSTRUTOR:

Ezequiel Conceição Blasco - Consultor sênior de usabilidade da TestAnywhere - Fábrica de Testes. Mestre em Ciência da Computação pela PUCRS na área de Interação Humano-Computador (IHC), com ênfase em Avaliação de Usabilidade e Acessibilidade e Sistemas de Ajuda. Possui amplo conhecimento e experiência sobre Projeto de Interfaces e Avaliação de Usabilidade e Acessibilidade, tendo participado de projetos junto ao Laboratório de Usabilidade e Acessibilidade (LUA) - PUCRS.

PROGRAMAÇÃO:

Dias: 12 e 13 de Março de 2010 (16 horas)

Local: ACATE - Rua Lauro Linhares, 589 - Laboratório de Informática - Trindade - Florianópolis/SC

Horários: das 13h30 às 18h00 e das 19h00 às 22h30 (sexta-feira)

das 08h30 às 12h30 e das 14h00 às 18h00 (sábado)

INVESTIMENTO:

R$650,00 (à vista para inscrições até o dia 05/03) R$700,00

Confira descontos promocionais para estudantes, associados da Acate ou da Sucesu e para grupos empresariais!

Faça sua inscrição pelo site da OnCast: www.oncast.com.br/inscricao

INFORMAÇÕES:

cursos@oncast.com.br

Fone: (48) 3239-2275

Falar com Mirela

Mirela Rzatki Sem categoria

Com a minha própria autorização, replico aqui um post do meu blog:

Os DTOs (Data Transfer Object) tem como principal uso a transferência de dados entre diferentes camadas de uma aplicação. A principal característica desse tipo de objeto é falta de comportamento.

O problema: DTOs as vezes são usados além do seu propósito inicial, o que leva o desenvolvedor à programação estruturada. Considere por exemplo os seguintes exemplos, primeiro em Java:

public class User {
  private String login;
  private String passwortHash;

  [getters e setters]
}

public class UserUtil {
  public static boolean checkLogin(User user) {
    ...
  }
} 

Agora em C:

struct User {
  char* login;
  char* passwordHash;
};

int checkLogin(User user) {
...
} 

Nota: não compilei os códigos, mas são suficientes para objetivos didáticos.

Perceberam a semelhança? Apesar da keyword “class” estar presente na versão Java, isso NÃO é orientação a objetos.

DTOs têm usos justificados, porém muitas vezes acabam se espalhando pela aplicação. A consequência dessa difusão é que o comportamento que utiliza os dados de um DTO tem dois “destinos” principais:

• Uma “classe” com vários métodos estáticos;
• no pior caso, o comportamento é duplicado em cada lugar que é usado.

A duplicação do comportamento pode ser bem problemática. Muitas vezes um mesmo comportamento está replicado com pequenas variações (e.g. uma comparação de string case-sensitive e outra case-insensitive). Esse acoplamento com o DTO dentro da aplicação também dificulta a mudança do mesmo, pois dependendo da escala da aplicação os pontos de mudança são muitos, e como não há uma centralização dos comportamentos, refactorings automatizados estão fora de questão.

Outro problema que ocorre nos dois casos é que esse estilo de programação dificulta a criação de testes da aplicação. Ao invés de criar um mock do objeto (estendendo o objeto/interface ou com algum framework), é necessário criar um objeto real com os dados necessários para o comportamento desejado. Com isso, o teste que deveria ter um ponto da aplicação sendo testado possui uma dependência com o comportamento associado ao DTO (ou seja, os testes falham se o “comportamento do DTO” for alterado).

Muitas vezes os DTOs são uma dependência externa do projeto (e.g. equipes distribuídas, cada uma trabalhando em um módulo da aplicação). Neste caso, se não for possível colocar o comportamento junto com os dados, é interessante ter uma classe que encapsule o DTO, fornecendo os comportamentos do mesmo. Desta forma evita-se que toda a aplicação conheça o funcionamento do DTO (flags ou outros atributos internos), fornece um ponto centralizado com o comportamento e melhora muito a legibilidade do código, pois os dados estão juntos com o comportamento associado.

Renato Besen Arquitetura de Software

This post is a follow up to the first post, regarding our dashboard creation, but before digging into the specifics, I would like to a summarize few goals we had in mind when we (as a team) come up with the current solution we use at our daily scrum lives.

First some background: we are a medium size team, composed of six developers working usually in pairs and doing sprints of 2 to 3 weeks on a project that is already in production, most of our stories are about improving the existing code base while adding some new functionality, and our sprints are usually composed of 20 to 30 stories, demanding quite some space on our dashboard.

A recurrent issue was some small bugs popping up during our client demo, giving them a bad impression about the quality of our code while bringing the team moral down.

Based on these we established some few goals to out new dashboard design:

• More flexibility: writing your name and status on a story/task is not a good idea, since whose working on it can change over time;
• Focus on people: enforce the team members importance on the project;
• A dashboard that would breathe quality: more testing and validation;
• Sense of accomplishment: it should be pretty visible to see when tasks/stories are completed;
• Pleasant to the eye, after all we will be using it everyday.
• Support a good amount of stories/tasks to be done and completed;
• Impose a limit to our WIP (work in progress);

The result is the following design, that according to Eduardo Moreira, resembles the way a brains operates, concentrating the most important things on the core of the dashboard:

On the top we have all the stories in a flow that goes from:

	To Do: At the beginning of the iteration it has the usual 20 to 30 stories ordered by the Product Owner priority. All the impediments are marked with a red flag, and work should not be started until it is unflagged.
	Work In Progress: When a team member starts working on a story it should be moved here. This step contains a much smaller space than the To Do and Completed ones, enforcing the team to work on the fewest stories at the same time, preventing too much unfinished work from happening.
	Done and Waiting Validation: After finishing all the tasks on a story it is moved here, where it waits to be validated by another team member whose do not worked on it. After validation, it then must be marked with a Success or Failure tag, the latter requiring a bug task to be created and placed on the Unexpected space (more on that latter).
	Completed: With the same space as the To Do, here is where all the completed stories lie, giving the team a good sense of accomplishment.

On the middle we have pictures of all the team members and their name tags to be stick on whatever they are working on (tasks, validation,…):

Lastly there is the bottom, with all the tasks split from the stories on our Spring Planing II:

	To Do: Not much different from above but divided into two spaces, a tiny one, to hold all the unexpected tasks (such as bugs) which wore produced during this sprint, and a bigger one, containing all the regular open tasks with the same red flags when suited.
	Work In Progress: Same rules as the stories, except that here the team member working on a task must mark it with his tag.
	Done: When a task is completed, it should be placed here. This step was created, to give the visible difference between work in progress and completed.
	Reported: Composed of all the completed tasks reported on the daily meetings.

These should cover most of it, but if you have any doubt or tip to help us improve our dashboard don’t hesitate on dropping a comment.

This post can also be found at my personal blog: blog.pirelenito.org

Paulo Ragonha Ferramentas agile, brain, dashboard, management, scrum, story, tool

Olá.

Aproveitando o espírito natalino de fé e o final de ano que se aproxima, segue abaixo umas frases que estão no Guide Scrum.

Sei que muitos de vocês são verdadeiras feras mas sempre é bom lembrar de coisas legais em nossa profissão e que reforçam os valores que precisamos manter todos os dias.

Um forte abraço do Marcucci e um ótimo final de ano a todos!

O SCRUMMASTER

O ScrumMaster é responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, às práticas e às regras.

O ScrumMaster ajuda o Time Scrum e a organização a adotarem o Scrum.

O ScrumMaster educa o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver projetos e produtos de maior qualidade.

O ScrumMaster ajuda o Time Scrum a entender e usar o autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster não gerencia o Time Scrum; o Time Scrum é auto-organizável.

O time se auto-organiza para se encarregar e se responsabilizar pelo trabalho contido no Backlog da Sprint, tanto durante a Reunião de Planejamento da Sprint quanto no próprio momento da execução.

O ScrumMaster trabalha com os clientes e a gerência para identificar e designar um Product Owner. O ScrumMaster ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners que eles saibam como conseguir otimizar valor através do Scrum. Se eles não souberem, consideramos o ScrumMaster responsável.

PILARES

1) TRANSPARÊNCIA

A transparência garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. Esses aspectos não apenas devem ser transparentes, mas também o que está sendo visto deve ser conhecido. Isto é, quando alguém que inspeciona um processo acredita que algo está pronto, isso deve ser equivalente à definição de pronto utilizada.

2) INSPEÇÃO

Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas. A frequência da inspeção deve levar em consideração que qualquer processo é modificado pelo próprio ato da inspeção. O problema acontece quando a frequência de inspeção necessária excede a tolerância do processo à inspeção.

Os outros fatores são a habilidade e a aplicação das pessoas em inspecionar os resultados do trabalho.

3) ADAPTAÇÃO

Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado.

Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores.

Existem três pontos para inspeção e adaptação em Scrum.

3.1 A Reunião Diária é utilizada para inspecionar o progresso em direção à Meta da Sprint e para realizar adaptações que otimizem o valor do próximo dia de trabalho.

3.2 A Revisão da Sprint e de Planejamento são utilizadas para inspecionar o progresso em direção à Meta da Versão para Entrega e para fazer as adaptações que otimizem o valor da próxima Sprint.

3.3  A Retrospectiva da Sprint é utilizada para revisar a Sprint passada e definir que adaptações tornarão a próxima Sprint mais produtiva, recompensadora e gratificante.

A finalidade da Retrospectiva é inspecionar como ocorreu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas.

A inspeção deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composição do time, preparativos para reuniões, ferramentas, definição de “pronto”, métodos de comunicação e processos para transformar itens do Backlog do Produto em alguma coisa “pronta”.

No final da Retrospectiva da Sprint, o Time Scrum deve ter identificado medidas de melhoria factíveis que ele implementará na próxima Sprint. Essas mudanças se tornam a adaptação para a inspeção empírica.

SOBRE O TIME SCRUM

Se o time sentir que se comprometeu com mais do que podia, ele se encontra com o Product Owner para remover ou reduzir o escopo do Backlog do Produto selecionado para a Sprint.

Se o time sentir que sobrará tempo, ele pode trabalhar junto ao Product Owner para selecionar mais do Backlog do Produto.

Quando um Time começa com o Scrum, Sprints de duas semanas o permite aprender sem se afundar na incerteza. Sprints desse tamanho podem ser sincronizadas com outros Times adicionando-se dois incrementos juntos.

leandro.marcucci Sem categoria

Muitas vezes temos a necessidade de executar um mesmo teste repetidas vezes mudando apenas alguns parâmetros. A solução mais simples caso sejam poucos testes é replicar o método de testes e mudar as variáveis, ou então criar um método com as asserções desejadas e chamá-lo com os diferentes parâmetros.

Ambas as possibilidades apresentadas pecam, pois não respeitam o princípio DRY. Uma solução muito mais elegante é usar os testes parametrizados, uma possibilidade que para quem usa JUnit existe a partir da versão 4.

O funcionamento é simples: um método no teste, anotado com Parameters, deve retornar uma coleção de arrays, que serão os parâmetros de execução:

@Parameters
public static Collection<Object[]> parameters() {
    List<Object[]> list = new ArrayList<Object[]>();
    list.add(new Object[] {"asshole!", "jerk!"});
    list.add(new Object[] {"what the hell?", "what the heck?"});
    return list;
}

Cada array desta coleção fornecerá os argumentos para o construtor do teste, possibilitando assim que estes valores sejam salvos em campos da classe, e utilizados por quem precisar dos mesmos:

public ProfanityFilterTest(String input, String output) {
    this.input = input;
    this.output = output;
    filter = new ProfanityFilter();
}

A classe de testes deve ser configurada para rodar com um runner específico, o Parameterized:

@RunWith(Parameterized.class)
public class ProfanityFilterTest {
[...]

Com estes passos básicos, ao rodar a classe testes, cada teste será chamado uma vez com os parâmetros fornecidos.

Para conferir o código completo baixe ProfanityFilter.java e ProfanityFilterTest.java.

Renato Besen Sem categoria Java, junit, testes

Um pouco de psicologia no desenvolvimento ágil de software:

A motivação do grupo é fundamental no desenvolvimento ágil, se cada membro da equipe não revisar seu estado de ânimo a cada dia e a cada iteração acaba ocorrendo um fenômeno psicológico em que forças antagônicas ao trabalho em equipe surgem na psiquê da pessoa (um pequeno ódio do trabalho). A psicologia realmente é fundamental em qualquer ambiente de trabalho pois lidamos com pessoas que pensam vivem e possuem emoções. Concordo em aumentar o enfoque desta parte humana na comunidade ágil pois no processo de migração de metodologias “legadas” acabamos nos preocupando muito somente com o processo e deixando um pouco de lado a parte humana.

Os nutricionistas dizem: “Somos o que comemos” e nós como engenheiros de software dizemos: “Também somos o que pensamos” pois nos alimentamos emocionalmente dos nossos pensamentos. Nossas criações dependem muito da capacidade de raciocínio.

Intuitivamente nosso amigo Paulo Ragonha sugeriu uma nova forma de dash board, a idéia surgiu no início da iteração e apresentou resultados satisfatórios. Em alguns momentos filosóficos no puf chegamos a conclusão de que o novo dash board é uma abstração simplificada de como nosso cérebro funciona. O Cérebro possui uma gigantesca memória, e as informações comumente utilizadas ficam mais próximas do “mecanismo” de raciocínio, no caso do nosso Brain Dash Board (batizado pela equipe) as estórias e tarefas que estamos trabalhando no momento ficam distribuídas no centro (onde existe maior concentração de foco visual da equipe) enquanto as estórias e tarefas não utilizadas ficam na região periférica. Concluímos que existe uma forte tendência do ser humano em replicar fora o que leva dentro e ótimas idéias surgem quando a mente está organizada, como fazemos com o backlog no nosso dash board.

Layout de Dash Board que se parece com o cérebro humano.

Eduardo Moreira Auto-gestão, Ferramentas Dash Board, Motivação, Psicologia

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 Planejamento, Riscos falhas, gestão de projeto, programação, qualidade

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 orientação a objetos, padrões de projeto, programação