Diego Pacheco Tech blog

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

Com esses quase 10 anos de *agile* algumas coisas mudaram. Antes o Agile era o ator coadjuvante e agora é o Ator principal da cena de desenvolvimento mundial. Esse fato vem sendo chamado de pós-agilismo . De facto o movimento ágil trouxe inovação ao desenvolvimento de software, mas essa inovação vem diminuindo cada vez mais. Tanto é que cada vez mais se vê a tentativa de Rebranding de Agile com Lean . Mas eu não estou criticando Lean neste ponto, acredito que ali existe muito valor e boas práticas que podem ser aplicadas a uma organização, mas o ponto é que Lean != Agile. Lean veio muito antes de Agile e não existe nenhuma linha histórica que mostra e evolução de um ao outro. Agile 2.0 ? Sim esse pode ser um dos efeitos do pós-agilismo. Agile 2.0 seria a nova versão do Agile, entrariam aqui coisas que ficaram faltando na versão 1.0. Na nova versão(2.0) existem tentativas de se aplicar coisas como: O ambiente Corporativo e manutenção de projetos. Qual é o marco para o Inicio do Agi...

Não sou adepto da política que trata o desenvolvedor como um desprovido de inteligência! Muitas vezes vejo que se criam arquiteturas e soluções para proteger os desenvolvedores dos frameworks ou sistemas. Isso é diferente de prover uma arquitetura adequada que diminui a complexidade do desenvolvimento, alguns chama isso de parede, outros chamas de uma grande desperdício de dinheiro. A Solução é evitar a arquitetura? No way! A arquitetura é sobre riscos e diminuir a complexidade do desenvolvimento. Isso significa que temos que pegar as maiores pedras no arquitetura, mas isso não elimina o trabalho do desenvolvedor. Tanto é que o arquiteto se envolve nos pontos mais importantes de Design e isso é diferente de se envolver em todos os pontos. Não se engane com os arquitetos de Frameworks! Já vi direto isso no mercado, muita gente acha que o arquiteto é o cara que mexe com frameworks. Acha que é o cara que decide se vai usar o JSF ou GWT, se vai usar Hibernate ou JPA. Arquitetura de softw...

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

Este não é um post sobre psicologia! Pode-se dizer que isso chega a ser um anti-pattern ou o mais puro desconhecimento de algo melhor. De qualquer forma já vi várias vezes no mercado frases do tipo: Os frameworks do mercado não nos atendem Os processos/metodologias do mercado não funcionam nesses contexto Esse tipo de arquitetura/metáfora não se aplica aqui Os usuários do meu sistema não pensam Os desenvolvedores são todos fracos Bom se você quiser podemos aumentar muito esta lista, com certeza você já deve ter ouvido algo assim em algum lugar ou pior em vários que nem eu :)! Um exemplo disso o Scott Ambler deu nesse post sobre adoção de agile . Não vou falar de agile ou criticar agile desta vez, mas só desta vez! Muitas vezes o ponto é a própria imaturidade da organização que ainda esta nas sombras da caverna ou simplesmente nem sonha o que são requisitos ! Esse tipo de egocentrismo é o legitimo tiro no pé! Por que a organização não dá espaço para que as coisas dos anos 60,70 e 80 e...

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