Diego Pacheco Tech blog

Você não precisa ser agile, você pode fazer um projeto e ter sucesso sem usar agile. Mais softwares foram feitos sem agile ou qualquer metodologia, leia-se AD-HOC, do que com métodos agéis. Neste posto gostaria de esclarecer o diversos enganos que os ditos "agilistas" erram quando falamos de processos tradicionais e desenvolvimento de software. Em outro post depois falar dos pontos positivos, ou seja, do que é bom mesmo. Mas neste post vou focar neste equívocos que o pessoal comente ou omitem de propósito. Vou falar de algumas falácias também... Hoje em dia muitos colocam como os métodos ágeis sendo a única solução que funciona para o desenvolvimento de software, será que isso é verdade, será que não existem outras opções? Será que esta é a única solução e será que isso funciona sempre e não tem defeitos. Primeiro Passo: Escolhendo as palavras mágicas Palavras Mágicas Não posso negar o marketing dos caras é bom. Qual metodologia você gostaria de usar, para facilitar a sua esc...

Com a crise econômica mundial, que tal reduzir 20% dos custos de sua empresa? Bom né? Pelo menos é isso que promete o Gartner se você usar BPM. Segundo ele seguirem a adoção de BPM podem ter esse lucro nos primeiros 12 meses, eu não duvido. 70% das empresas que usam BPM dizem que essa é a sua salvação, a idéia não é nova, com crise ou sem crise os preços tendem a ser ditados pelo mercado, então uma boa forma das empresas irem para frente é melhorar a qualidade dos seus processos internos e diminuir custos. O que é B usiness P rocess M anagement ? Esse é um modelo gestão baseado em processos, a idéia é mapear e modelar os processos da empresa para ter um conhecimento maior de como as coisas funcionam e poder otimizar o processo. Tal tarefa de mapeamento pode ser feita com qualquer ferramenta estilo fluxograma . Para mapear um processo não importa se a sua ferramenta é o MS Visio , IBM Modeler , BizAgi ou até mesmo o MS Excel . Quando falo em mapear não falo só no mapeamento, que é...

Neste post vim falar um pouco mais de FDD, que além de ser um método ágil tem uma grande eficiência e aderência a requisitos. Vou dar uma visão geral de como o método funciona e como podemos mixar o método com outro método ágil chamado de Scrum. Se você quiser saber mais sobre Scrum, pode ler outros posts que tenho sobre o assunto a baixo: Scrum O que faz a diferença usando XP, Rup, Scrum ? Scrum não substitui gerenciamento de projetos Estimando com Scrum Gerenciamento de Níveis com Scrum e RUP parte 1 Gerenciamento de Níveis com Scrum e RUP parte 2 O Melhor do Scrum Voltando ao FDD , o método é iterativo incremental e funciona muito bem com iterações curtas de duas semanas, você pode usar um timebox maior, mas eu recomendo muito o uso desse timebox, para mim o foi o que melhor funcionou. O FDD foi criado por Jeff De Lucca em 1997. FDD é um método que prega a visibilidade do estado projeto de forma consistente e honesta. Você consegue saber quantas funcionalidades já foram desenvolvid...

É Comum ver gerentes de projetos tradicionais utilizarem a ferramenta MS Project ou genéricos, mas muitos usam independente da marca do produto PERT e GANT . Acredito que em certos cenários em que as coisas são muito previsíveis é possível usar esse tipo de ferramentas, mas em muitos cenários de desenvolvimento de software isso pode se transformar em um problema. Muitos profissionais consideram a gestão baseada em Project um erro, por que alguma vez na vida alguem acertou aquelas datas? Por que isso acontece? Será que a gestão baseada nesse ferramenta pode ser catastrófica? Neste poste vou tentar responder essas e outros perguntas com a minha experiência com essa e outras abordagens de gestão de projetos. O que é gestão de projetos? Para muitos a resposta dessa pergunta é controle. Mas isso é herdado de outras áreas onde a gestão de projetos existe, o problema é que o pessoal não se fraga que desenvolver software é diferente de: Construção de um Planta Produção de um filme Construção ...

Quando eu era criança tinha uma brincadeira chamada de ovo podre. Hoje em dia essa brincadeira poderia se chamar de Ovo podre da TI. Além disso tinha outra brincadeira muito semelhante chamada de batata quente. O Objetivo da brincadeira era passar a batata quente a diante e depois de um tempo a batata ficava com alguém. Azar de quem estava com a batata, mas não sendo a "eu" não tinha problema. Esse é o pensamento que toda criança tinha na brincadeira, o problema é que isso existe na TI hoje em dia. Parece que muitos profissionais e se é que dá pra chamar assim só querem elevar o nível de TCR. A Explicação do que significa TCR você acha aqui . Passei a Bomba Bomba No post anterior eu estava falando de qual seria o foco dentro da TI, se seria de manter o TCR ou resolver os problemas, mas na verdade nem sempre é isso que acontece. Hoje em dia algumas pessoas tem o pensamento de que enviar um email é fazer com que eles sejam inimputáveis de qualquer crime e responsabilidade de re...

Existe um anti-pattern de comportamento nas empresa que trabalham com software de alguma maneira. De facto não é um problema só, são vários, este mal assola toda indústria de software, algumas empresas já estão livres desse mal e outras não, as vezes só algumas pessoas nas empresas tem esse tipo de comportamento em outras isso é como colocar veneno no ar condicionado. Acontece o Problema Os problemas estão na natureza de qualquer trabalho, não existe profissão em que os problemas não ocorram, mas a grande questão é como você lida com esses problemas. Existem várias formas de lidar com os problemas, algumas delas(mais comuns em alguns cenários) são: Fingir que o problema não existe Empurrar o problema com a barriga e achar que do nada tudo ira se resolver Não reportar o problema, não discutir o problema com a equipe Fingir que o problema não é tão critico Usar uma solução que não resolve o problema, mas não incomoda ninguém E assim por diante, em muitos casos para resolver um problema v...

Em um post anterior comentei o que acho que existe de melhor no Scrum. Agora vim falar de XP. Tenho pontos de discordai em relação ao XP, principalmente em relação a requisitos, requisitos não são conversações em andamento como muitos do XP pensam, logo quando falamos de Casos de Uso não estamos falando meramente só de mais níveis de detalhamento. Você pode usar as estórias do usuário sem problemas, mas em certos contextos não será a melhor solução. Mas neste post não vim falar das diferenças sobre casos de uso e estórias do usuário, isso posso fazer em outro post, como disse antes aqui vi falar das coisas que acho muito saudáveis no XP, tais práticas em valores são concebíveis para vários projetos em vários contextos. Quatro Valores Acho muito válido uma metodologia de desenvolvimento de software como o XP focar em valores, é comum vermos papéis, práticas, guias, fluxo de trabalho, mas princípios? não é muito comum, mas acho muito válido, por que em certas situações somente a utiliza...

Você sabe onde você trabalha? Imagino que sim. Você sabe em que empresa Trabalha? Imagino que sim. Você percebe a diferença de uma base militar para o seu setor de TI? talvez a resposta seja não. Não é culpa sua, nem tudo a gente muda, querendo ou não certas coisas não valem a pena serem mudadas. Por que não valeria a pena mudar algo? Quantas vidas você tem? Uma só. Certas coisas não mudam, mas por que continuar pensando na caixa? É isso mesmo, você deve estar pensando dentro da caixa. Pensando dentro da Caixa Você não deve seguir as coisas como são em sua empresa. Esse pensamento vai colocar você centro de um caixa, essas rédeas mentais travam a evolução da organização e a melhoria do processo e dos produtos da empresa. Para inovar você precisa esquecer o que aprendeu, esqueça as regras, o cavalo só é livre e está sem rédeas. Como que você consegue se sentir bem com esse tipo de modelo? Só existe uma resposta se você falar que sim a resposta é você gosta de sofrer amigo. Mas nem todas...

Se você trabalha com desenvolvimento de software no Brasil pode estar vivenciando diversas épocas da história da humanidade. O mundo mudou, as coisas mudaram, mas as empresas ainda continuam com aqueles velhos hábitos e pensamentos sobre o passado. Isso mesmo. Existe uma grave inversão de valores nas empresas no Brasil e infelizmente não é a minoria das empresas. A maioria das empresas não tem equipes, tem grupos que trabalham de forma desordenada, atrapalhada e individual. O Individualismo no Desenvolvimento de Software... Ainda existe a cultura de que desenvolver software é algo individual. Tolice! Por que quando desenvolvemos software precisamos de diversas habilidades como lidar com pessoas, gerenciar riscos, gerenciar expectativas, remover impedimentos, testar, estimar, planejar, verificar o que foi feito e fazer o software. Para isso uma equipe multi-funcional é melhor e lida muito melhor com a complexidade existente nos sistemas. As empresas continuam a negar isso, achando que ...

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