Diego Pacheco Tech blog

Por mais estranho que pareça ainda é comum achar empresas que não testam seus produtos de software. Isso chega a ser muito diferente se falarmos de outras áreas como a indústria de automóveis por exemplo. Você já pensou se você compra um carro zero na concessionária e ao sair com o carro ele nem liga, ou pior a porta do carro nem abre? Imagine então andar 10 metros e furar o pneu? Novo e não funciona! :( Isso é horrível, não digo que nos dias de hoje isso é improvável que aconteça mas é difícil, mas por que é difícil por que eles testam o carro e as partes do carro. Ao desenvolver software você está fazendo algo que não existia e você precisa sim testar e muito. Por que Testar Software? Por uma questão extremamente básica. Como você sabe que funciona? Se não testar não sabe, bugs são inevitáveis, mas isso não significa que você pode entregar um produto de baixa qualidade pra seu cliente. Os testes não garantem a qualidade do produto, mas ajudam nesta garantia, para garantir a qualidade...

Na primeira parte destes artigo s falei sobre o modelo de gestão em níveis e como ele poderia ser mixado com métodos ágeis como o Scrum. Neste post vou mostrar mais detalhes do método através de uma apresentação power point. Planejamento Niveis View more presentations from Diego Pacheco . Você pode conferir exemplos de dashboard do método que fiz aqui no meu quarto com post-its e uma parede, você acessa isso no meu flicker .

Scrum é um excelente framework para a condução do micro-ambiente. Suas práticas ágeis são fantásticas para aumentar a colaboração e levantar problemas e resolver impedimentos da equipe. Scrum ajuda muito no dia-a-dia da equipe de desenvolvimento de software, através das reuniões diárias, conseguimos tanto antecipar e corrigir problemas como ter o posicionamento do que a equipe está fazendo. A visão compartilhada de uma equipe é essencial. Se você tem pessoas trabalhando para sua empresa em uma sala, não necessariamente você tem uma equipe. Para ter uma equipe você precisa de indivíduos que compartilhem o mesmo goal. Assim como em equipes esportivas, não existe possibilidade de um ganhar e os outros perderem, ou todos ganham ou todos perdem. O Scrum possibilita que a equipe evolua e cresça como equipe através de retrospectivas e momentos de planejamento de prestação de contas sobre o que foi desenvolvido. Dashboard O Dashboard é um elemento fundamental na adoção de práticas do Scrum, e...

Hoje em dia esta na mídia falar de TI. Isso inclui des das ferramentas, linguagens de programação e até mesmos métodos e processos . Nas ultimas semanas venho tendo boas discussões sobre todo esse tipo de coisa. Muito se fala em qual seria a melhor solução ou o que a grama do vizinho tem que a minha não tem. Nesse ponto vem todo o tipo de coisa, des da retórica religiosa até mesmo ao lado emocional. Paixão é um ingrediente importante para o sucesso e a realização de qualquer profissional mas neste mundo que estamos vivendo as vezes temos que deixar isso um pouco de lado e partir para abordagens mais racionais do que emotivas. O que escolher? O que usar? O que estão falando? Hype? Muitas Palavras? De facto o que esta na mídia pode estar longe de ser o que você procura ou o que você de fato precisa. Dificilmente uma única solução ira resolver todos os seus problemas, é mesmo não existe a bala de prata. Os seus problemas podem ir des de um Servidor de aplicação mal configurado até mesmo c...

A proveitando a Dúvida de um leitor vim neste post para falar das diferenças do RUP e do OpenUP . Vou focar nos pontos que considero mais importantes destes grandes métodos de desenvolvimento de software. Vamos aos pontos em comum. Ambos são métodos para desenvolvimento de software, o foco desses métodos é a fase de projeto, ou seja, até o momento de colocar o software em produção depois disso é outra história e já não é não é o foco desses métodos. Se você procura um método de desenvolvimento de software baseado em RUP mas está mais preocupado com a pós-construção, manutenção e desativação do mesmo recomendo que você confira o EUP do Scott Ambler . RUP não é cascata! Do contrário de que muitos pensam RUP é um método de desenvolvimento de software iterativo e incremental . O OpenUP também não é um método em cascata. Apesar de muitas vezes ambos serem usados de maneira errada. A proveito para dizer nesse post que RUP/OpenUP tem defeitos sim! E não são dois tipos de bala de prata que r...

Todos os projetos de desenvolvimento de software tem riscos. Não interessa tamanho, domínio, experiência da equipe ou recursos, os riscos estão ai, sempre estiveram e sempre vão estar. Alguns acreditam que gerenciar riscos é gerenciar projetos eu discordo dessa opinião, pois deixa as coisas de uma maneira muito simplista e de facto não é. Não estou falando de rabiscos quando falo de riscos. Estou falando de perigos, ameças e tudo aqui lo que pode prejudicar o sucesso do seu projeto. Então vamos associar a palavra riscos com a palavra perigo ou se você preferir: danger ! Um exemplo de Risco Mas cuidado! Essa é boa não? Bom você não pode ficar entrar em paranóia, mas também não pode seguir o seu projeto sem pensar em como mitigar riscos. Alguém sabe o problema dessa figura? Ela é extrema, claro que é uma sátira. Não existe a menor possibilidade de você estar lidando com todos os riscos do projeto é simplesmente impossível ! De forma divertida é isso que a figura a cima mostra. Mas voc...

D e certa forma me sinto até meio marginalizado ao falar desse assunto, uma por que já se passaram muitos e muitos anos que todo o método de desenvolvimento de software fala em desenvolver um software de maneira iterativa e incremental. Outra por que os agilistas já fizeram um alarde muito grande em cima do assunto, mas mesmo assim começo achar que ainda existem dúvidas para as pessoas. D esenvolver um software novo é muito mais fácil do que desenvolver uma solução que substitua um sistema existente e essa complexidade aumenta ainda mais quando estamos falando de arquitetura corporativa. Que seriam sistemas de sistemas e como cada sistema conversa um com o outro, sim você pode usar SOA . Desenvolvimento Tradicional? Os agilistas costumam chamar de desenvolvimento tradicional todo método que usa cascata! E com certeza você já ouviu falar que RUP foi muito utilizado em cascata apesar do método não ser cascata! Hoje começo a ver o projetos pelo mercado que são cascata e se dizem ágeis! ...

Ultimamente a comunidade ágil vem falando sobre o " Fail Fast ". Que seria em prática algo do tipo: "Se tiver que errar erre o mais rápido possível para corrigir" eu discordo dessa visão. De novo estamos falando de riscos, essa é uma afirmação muito forte para ser declarada livre de um contexto. O importante na verdade é avaliar e fazer alguma coisa e isso que deve ser feito rápido e muito rápido. Isso dá um foco diferente a essa visão do *agile*. Muitas vezes em um projeto não podemos dispersar nem tempo nem dinheiro. Tudo é sobre custo e riscos! Quando se trabalha com um planejamento estratégico e você tem o cascateamento de custos e objetivos é necessário reavaliar e corrigir rumos e isso deve ser feito de forma não linear. Isso significa que o nível tático não é o suficiente. O Scrum estaria nesse nível mais tático. Olhando para o RUP O RUP possui o conceito de fases, de facto muito pouca gente entende de verdade para que elas servem e por que é importante us...

Hoje(26/02/2009) saiu minha 2ª publicação OpenUP/Basic: Um framework Ágil e Unificado no UOL ( iMasters ) no canal de Gerência de Projetos . Esta publicação foi um post que fiz no meu blog em 21/06/2008.

Ontem(18/02/2009) saiu minha publicação RUP - Verdade e mitos no UOL ( iMasters ) no canal de Gerência de Projetos . Esta foi a minha publicação para o UOL a idéia é que eu publique para eles uma vez por semana. Esta publicação foi um post que fiz no meu blog em 05/07/2008. Vou continuar publicando nos dois lugares. Mas os comentários ficam separados, ou sejá, comentários aqui não são os mesmo comentário de lá :(! Até a próxima.

Hoje no Brasil posso dizer que estamos transcendendo já aos poucos a faze da orientação a Dados. Não que isso seja necessariamente uma coisa ruim. Para certas situações o bom e velho ORACLE Designer e conjunto com o ORACLE FORMS produzem uma solução viável. Mas o ponto que eu quero chegar com isso é que nos estávamos em um paradigma orientado a dados. Não digo por si só um paradigma orientado a dados mas estruturado também. Não tenho como objetivo neste post falar sobre OO . Mas sim falar em paradigmas. Utilizar uma linguagem como Java ou C# não deixa o sistema OO por si só. Utilizar classes ou até mesmo interfaces também não deixam o seu sistema OO? O que deixa um sistema OO? É a maneira que você pensa. É como você faz o Design da coisa toda . Uma coisa que me marca muito é que uma prova cabal sobre a transadencia da faze de dados a uma outra faze é a questão do banco de dados. Muitas vezes é lá que o bixo pega. Muitos sistemas quando são colocados em produção geram diversos proble...

Acho que uma das primeiras coisas que todos aprendemos ou deveríamos ter aprendido na faculdade ou em uma curso técnico (sou do antigo PD) ou até mesmo trabalhando é que o modelo em Cascata é ruim. De facto não é um modelo ruim por natureza, só que para o desenvolvimento de software não funciona! Muitos sabem disso ou pior pensam que sabem, provavelmente qualquer pessoa que você falhe vai concordar com você sobre isto, porem na prática na hora de executar as coisas , o que eu vejo por ai é muito projeto em Cascata até mesmo projetos que se dizem ágeis . É o velho desenho do balanço. Mas a grande questão que esse desenho nos trás é a seguinte palavra: Requisitos . Também não é nenhuma novidade que cada real gasto em requisitos pode ser 60% mais caro em produção. Muitos falam que sabem disso mas na prática eu vejo justamente o contrário. Um sintoma de que as coisas não estão indo bem, sinal de confusão :) é separar as disciplinas em fases ou momentos. Não existe um momento de análise o...

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...

O título desse post pode chocar muito as pessoas :) . Mas de fato RUP é tão diferente de eXtreme Programming assim? O propósito desse post é estabelecer os aspectos em que essas duas metodologias tem em comum e também aqueles aspectos que ambas seguem a mesma idéia porem muitas vezes com abordagem totalmente distintas. Se você quiser conhecer mais o RUP pode começar lendo dois post anteriores que fiz sobre o assunto. Os links são estes: http://diego-pacheco.blogspot.com/2008/07/rup-importncia-dos-marcos.html http://diego-pacheco.blogspot.com/2008/07/rup-verdades-e-mitos.html De fato existe muito atrito quando falamos de metodologias/processos por que normalmente as pessoas tem um posição mais a esquerda (XP) ou mais a direita (RUP). Essa minha classificação de mais a esquerda ou mais a direita não é atoa e de fato não é minha :) A figura a cima demonstra o que estou falando. O RUP é mais formal do que o XP. Eu já mencionei isso antes nesse post . Todos já devem saber a recomendação q...

Seguindo a linha do post anterior , vou descrever pra vocês um pouco mais dos marcos do RUP bem como o propósito e como eles podem ajudar em termos de gerência de projetos e colaboração entre a equipe. Ciclo de Vida O processo tem basicamente 4 marcos no seu ciclo de vida são elas: Iniciação, Elaboração, Construção e Transição, no RUP corporativo criado pelo Scott Ambler ele adiciona mais dois marcos que são: produção e desligamento. Dentro de uma empresa que mantém o produto de software por anos realizando ajustes referentes a Change Requests e mudanças de legislação e tudo mais o ciclo de vida do EUP(RUP Corporativo) é o ideal. Muitas empresas não utilizam esse tipo de cliclo de vida, algum tratam o 'fato' do sistema estar em produção como 'operação/manutenção' e acabam endereçando os problemas dessa fase com diversos problemas. Mas como o objetivo desse post não é falar de EUP (Fica para outro post) vamos voltar ao RUP. Na figura a cima você pode perceber as fases...