Diego Pacheco Tech blog

Estimar não é uma tarefa fácil. Porem vivemos em um mundo de estimativas. Queremos saber quando vamos ganhar um aumento, quando vai subir o preço das passagens, quando o taxista vai chegar no local que você solicitou. Enfim esse é o nosso mundo e em software não tem por que ser diferente. Essa é uma das práticas mais malhada dos últimos anos pelo pessoal do movimento ágil . De fato a técnica se trata de uma arte mais negra do que muitos rituais de magia. :) Mas não é tão negra assim como alguns devem estar pensando agora. Quantas vezes não vimos gerentes de projetos fazendo WBS detalhadas nos primeiros ciclos de planejamento de projetos? A WBS per se não é o problema, o problema é o uso que as pessoas fizeram dela. Os problema nesse tipo de abordagem são: Unico ponto de acerto Realizar planejamento especifico muito cedo Estabelecer Datas com requisitos muito instáveis Plano cria o efeito "Marcha da Morte" Unico ponto de acerto : Quando dizemos algo do tipo: "O Projeto i...

Nosso mundo esta em crise. Na verdade é difícil afirmar quando esta crise começou, não estou falando especificamente de desenvolvimento de software. Claro que isso se aplica ao desenvolvimento de software no Brasil. Não digo que outros países mão tenham problemas, mas como vivo no Brasil tenho que reduzir o escopo deste desabafo para o nosso pais. Alegoria da Caverna Este com certeza é o texto mais conhecido de Platão. Mas caso o leitor não o conheça vou tentar resumi-lo a baixo. Dois prisioneiros estão aprisionados em uma caverna. Estes prisioneiros estão virados de costas para a entrada da caverna, esta entrada é a única fonte de luz. Os prisioneiros sempre viveram na caverna acorrentados desta forma. Tudo o que eles conheciam, como por exemplo: Animais e plantas só eram conhecidos pelas suas sombras que eram projetadas na parede da caverna. Um belo dia um dos prisioneiros consegue se soltar das correntes e vai para fora da caverna. E adivinhem o que acontece? Ele fica maravilhado c...

Até dois anos a trás a comunidade e mercado Java só falava em frameworks. Em 2006 e 2007 o site The Server Side bombava muito. Nessa época veio a onda do Ajax e depois a onde de RIA( como Lazlo, GWT, Echo2, etc...) No momento se nos prestarmos atenção, quase não se fala mais em frameworks, será que o mercado está mudando de foco? Ou será que métodos ágeis são o novo Buzz? As duas frentes do movimento Existem duas frentes bem distintas no movimento ágil. Existem pessoas muito sensatas que valhe a pena gastar tempo com elas, como: Scott Ambler, Joseph Pelrine, James O. Coplien entre outros. Porem existe um outra frente de pessoas que eu acredito não ser necessário dar nomes, mas são aqueles que tem um fervor maior pela questão propriamente dita. Estou falando dos caras que acham que: Estimativas não servem para nada, UML e Caso de uso são Anti-Patterns, TDD é tudo, On Site Constumer Rules, Certificações estragam o time. Esse tipo de pessoal muitas vezes não aceita críticas e simplesme...

Muitas metodologias são baseadas em casos de uso. Casos de uso são muito eficientes na representação da voz do usuário. Quando estamos desenvolvendo ou revisando Casos de Uso devemos ter certas questões em mente para que o desenvolvimento/revisão ocorra de maneira efetiva. Vou abordar algumas questões quais eu julgo importantes na revisão de Casos de uso, como já disse antes essas questões são uteis pra o desenvolvimento de requisitos do usuário (Casos de Uso) e para a revisão dos mesmos. Confira as questões que serão abordadas: Forma de descrição de Casos de Uso Descrição e Utilização dos Atores Termos do Glossário Levantamento de cenários alternativos (nenhum ou a falta de) Reflexo do Domínio Contextualização Nível de Abstração Utilização de Protótipos A Linha tênue do Design com Requisitos Tamanho dos Casos de Uso (Muitas Páginas) Limitações dos Casos de Uso Conforme eu já disse em um post anterior . A metodologia RUP é baseada em casos de uso. Casos de uso são documentos que são f...

Não adianta, por mais que uma analista de requisitos estude, a única forma de ele escrever requisitos melhores é através de revisões de requisitos e o feedback que as mesmas podem propor. Mão estou dizendo que o Analista de requisitos não deve estudar técnicas e patterns de Requisitos, mas sim que somente através da revisão que será possível evoluir suas habilidades de desenvolvimento de requisitos. Além de assuntos pertinentes a revisões de requisitos irei descrever duas práticas ágeis para o desenvolvimento de requisitos. Por que Revisar? Afinal, essa tarefa não é barata e tempo é um luxo que ninguém possui. Pois é se vocês se lerem o post anterior . Está claro a importância do investimento em requisitos. Ao realizarmos revisões de requisitos estaremos ganhando em: Clareza de informações Remoção de ambiguidades Possíveis problemas que teríamos com modelagem Além de outras anomalias( Requisitos duplicados, requisitos não identificados) A revisão de requisitos pode e deve se dar de dua...

Diferente do que prega o XP, eu lhes digo o código é o que menos importa. Você até pode ter um código, lindo maravilhoso utilizando todos os patterns do nossa amigo Kent Back, tal qual ela fala no Implementation Patterns, mas de nada irá adiantar isso se a análise de requisitos já estiver comprometida. Por outro lado com os Requisitos bem levantados e com um devido processo de priorização, através de um mecanismo de CCB ou algo mais simples, é melhor do que ter código perfeito. Se os requisitos estão OK, é simples de se arrumar o código. A Lógica inversa O problema é que muitas empresas querem melhorar ou alavancar sistemas legados através do código, lhes digo que é possível melhorar um pouco, mas não será possível deixar o sistema 100% nos trilhos a partir do código. As coisas devem partir da análise. Uma vez a análise comprometida todo o sistema está comprometido. Por que gastar mais tempo com Requisitos? Por que estatísticas mostram que projetos que gastam menos de 5% do tempo em ...