Aislan Fernandes

Numa das cenas do filme "Tron, O Legado", Sam Flynn tente convencer o pai, Kevin Flynn, a fazer alguma coisa porém o mais velho e maduro sabiamente responde: "Incrível como não fazer nada é produtivo". Simples assim! Kevin Flynn Um dos valores da metodologia XP tem tudo haver com isso: simplicidade. Normalmente um programador tem dificuldade de fazer a coisa mais simples que funcione e procura fazer antecipações. XP é contra esse hábito. Mudança é uma constante num mundo globalizado, mais ainda no ambiente de tecnologia da informação. Por isso, a XP defende que o custo da mudança hoje é o mesmo do amanhã. É preciso pesar bastante antes de fazer a mudança. Um critério é o valor agregado (ao cliente, claro!).  É frequente como os profissionais de TI procuram justificar a adição de novas funcionalidades ou  "melhorias" legais no sistema cujo valor agregado ou benefícios reais não compensam para a empresa. Vou descrever um caso hipotético que reflete ...

Em outro post, sobre Programação Extrema , o Kent Beck argumenta o suficiente para evitar uma flexibilidade demasiada e desnecessária: “O segredo é que risco é dinheiro da mesma forma que tempo é dinheiro. (...) Se existe incerteza suficiente, o valor da opção de esperar é alto o suficiente para que seja melhor esperar.”. “Quando você acrescenta mais ao projeto hoje, você aumenta a sobrecarga do sistema. (...) Há mais coisas para testar, entender e explicar.” “Você também não consegue avaliar o custo de algo que acontecerá amanhã. (...) e a probabilidade (...)”. “Assim, o custo de tomar uma decisão de projeto hoje é igual ao custo de tomar a decisão somada aos juros que pagamos sobre esse custo mais a inércia que isso adicionar ao sistema”. “Os problemas de hoje já são suficientes”. Fazendo uma leitura sobre o padrão Variações Protegidas ( Protected Variations ) encontrei um comentário muito interessante do Larman* alinhado a esse pensamento do Beck:   "Os desenvolvedor...

A edição mais recente do livro do Larman* está muito boa: várias atualizações e explicações de confusões relacionadas com outras metodologias como Scrum e XP. Mas particularmente uma me chamou a atenção: mitos do reuso (capítulo 37). Acolha as mudanças também no PU! Antes de continuar apenas deixar claro uma confusão comum entre as pessoas: UP x XP. Depois de ler XP por Kent Beck (posts anteriores) sem dúvida nenhuma é mais do que natural pensar que eles podem ser complementares (mesmo porque o próprio Larman já diz isso e faz várias referências diretas ao Beck!). O mito é bem interessante: as pessoas buscam tecnologia de objeto (TO) por causa do reuso, quando na verdade TO não foi feita para isso, apesar de ser usada para tal. Além disso, desenvolver pensando em reuso é entrar na mesma problemática de programar pensando em problemas do futuro (sem futuro?) que o XP combate (ver posts anteriores). O autor então questiona a real motivação dessas pessoas, se técnicas ou ...

Seguem comentários da minha leitura do livro "Programação Extrema (XP) Explicada – Acolha as mudanças" do Kent Beck* - última parte. SEÇÃO 3 – IMPLEMENTANDO A XP Adote a XP de forma incremental após o entendimento da metáfora do processo Comece pelas práticas mais difíceis Testes Programação em Pares Doloroso no começo Sob pressão todos retornarão às antigas práticas. Ciclo de Vida Ideal do Projeto XP – Fases: Exploração Necessário quando não há maturidade ou domínio suficiente Programadores nas tecnologias Cliente na escrita de histórias Tempo dedicado a experiências até que haja condições suficientes para programadores estimarem as histórias Pode durar até meses Planejamento Do projeto, de iterações e de tarefas Iterações da 1º Entrega Cada iteração finalizada com uma cerimônia Produção Testes paralelos são importantes aqui Manutenção Rodízio no help desk para entender melhor o “mundo” de produção As mudanças são mais conservadoras É recomendado ao...

Seguem comentários da minha leitura do livro "Programação Extrema (XP) Explicada – Acolha as mudanças" do Kent Beck* - segunda parte. SEÇÃO 2 – A SOLUÇÃO São doze práticas interdependentes que acompanham o XP assim resumidas: O Jogo do Planejamento Um jogo de decisões entre a área de negócios e área técnica Decisões sobre: Negócios - Escopo, prioridade, composição das versões, datas de entrega Técnica - Estimativas, consequencias, processo, cronograma detalhada Consequencias está relacionada com os impactos de negócios ter escolhido, por exemplo, uma tecnologia específica. Entregas Freqüentes Metáfora Todo projeto é guiado por uma metáfora A metáfora fornece uma visão geral e simples do software Uma alternativa à arquitetura que também fornece uma visão geral mas técnica do software Projeto Simples Executa testes a qualquer momento Não tem lógica duplicada Expressão todas as intenções aos programadores Menor número possível de classes e métodos (cada parte ...

Seguem comentários da minha leitura do livro "Programação Extrema (XP) Explicada – Acolha as mudanças" do Kent Beck* - primeira parte. INTRODUÇÃO O livro é dividido em três seções: O Problema – trata do entendimento dos problemas envolvidos no desenvolvimento de software; A Solução – trata das práticas XP necessárias para resolver os problemas; Implementando a XP – trata de como usar as práticas. SEÇÃO 1 – O PROBLEMA Lista de riscos inerentes a todo desenvolvimento de software e abordagens que podem tratá-las: Deslizes no cronograma – ciclos curtos diminuem a extensão do deslize; Projeto cancelado – menor release com maior valor possível; Sistema “azedo” – testes a cada modificação; Azedo = Quando o custo, a manutenção e os bugs são maiores que o lucro. Alta taxa de erros – testes do programador e do cliente; Compreensão negativa – colaboração do cliente; Mudanças negativas – menor ciclo de release; Funções “pobres” – foco nas prioridades Pobre = Excitantes ...

Não tive a oportunidade ainda de apresentá-la.