Diego Pacheco Tech blog

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

Recomendo a todos vejam esse vídeo do Waldez Ludwig .

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

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

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

Ambiente sempre foi sinônimo de problemas! Mas não estou falando de aquecimento global. Pode parecer besteira mais um ambiente efetivo pode reduzir até 40% da complexidade de se desenvolver algo. Isso vem vem de técnicas de estimativas como o UCP . Não estou aqui para falar de UCP ou de estimativas no geral. Se você esperava encontrar um post sobre estimativas posso criançola-lo com esses outros posts anteriores sobre estimativas. Estimando com Scrum Estimativa não Exatimativa! Realizando estimativas de valor com Wideband Delphi Qual o assunto deste post então? Foco e Produtividade! Mas o que diabos o ambiente tem a ver com isso? Tudo. Quando estamos falando de TI podemos falar de 3 tipos de ambiente, vou classifica-los da seguinte forma: Ambiente de Desenvolvimento Ambiente Sociotécnico Ambiente físico Ambiente de Desenvolvimento Este é o ambiente do desenvolvedor aqui estão as ferramentas de apoio ao desenvolvimento como servidor de build continuo , maven , debuggers , profiles, ser...

Desenvolver software não é uma tarefa fácil, existem diversos riscos em um projeto de desenvolvimento. Esses riscos são variam de projeto a projeto. Existem vários fatores que levam a necessidade de desenvolvimento de forma iterativa-incremental e risco é um deles. Desenvolvimento Ágil? Agile não tem nada a ver com isso. Estou falando de algo bem mais básico. Podemos dizer que isso já deixou de ser conhecimento explicito e virou tácito. Infelizmente nem para todos. Por que Desenvolver em pedaços? A resposta é bem simples, quanto mais você desenvolve mais risco tem. Isso mesmo desenvolver algo é um risco, quanto menos você desenvolver melhor, por isso toda a conversa sobre reaproveitamento, design , Arquitetura , SOA e Asset Management . Não interessa o quanto você pesquise, o quanto você teste, o quanto você faça peer-review! Enquanto você não colocar em produção o produto/serviço não existe! Somente quando o produto/serviço entra em produção que você começar a colher resultados. No ...

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.

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