Diego Pacheco Tech blog

Back into 2008 i was doing lots of scrum like everybody else. I spot several issues working purely with scrum like: Issues working with delivery dates, issues working with distributed work, or work beyond the team level, issues working with FAKE Pos, or pos who could not make any call or was really afraid to make calls because a specific corporate culture. In brazil CMMI and process, unfortunately are still strong, maybe there are not strong in a direct way but they are still into a indirect way.  People often go to new methods and practices but with old culture and that does not work because as Deming said once: Dont copy the tools copy the principles in order to get the principles it require to change culture and values, for brazil old values around process and quality.

I couple of weeks ago I gave some trainings about Lean/Kanban and Agile core values and mindsets , later I will provide several blog posts to cover with more details that presentations. Lean kanban View more presentations from Diego Pacheco Agile & lean View more presentations from Diego Pacheco Cheers, Diego Pacheco

Growing a team and developing people is a primary agile coach duty. Such of thing ain't happen easy. Take time and lots of actions to archive it. The main issue could be being part of a company that don't have the agile team culture and mindsets, so when you fight against bad mindsets you must be very persistent and make the right moves to make things happens. Agile practices from scrum and XP will help you BUT sometimes they are not enough, dealing with different people culture indeed its a big challenge. I don't see you promoting change only by changing the practices or the tools, I do see the changing slowly happening when you evolve people and let they be part of the change. Change is something people said they want but often they don't want do it. I talk by my self when I said that, I known how something are important and even that sometimes I don't do it, because I really don't care deep inside ? NO, because to follow...

DEMO sessions or Review session are skipped more offen then you can imagine. I do understand the reasons why people may skip this sessions, sometimes people don't have working software to show, team could be not happy with the sprint results or could be that you have so few stories to show. I worked in projects with lack of demos and this sticks as not only lack of demos but also lack of openness and really could be a sign of doing agile wrong. Because you don't have nothing to hide of your customers, right ? We don't need get paranoiac about that because in several adoptions team do daily meetings with the team everyday smooth integrated. If the team does regular daily meetings with the business(team + business(pos)) together, why bother to do DEMOs sessions, let's say you do have a great communication in place, I do really need regular DEMO sessions ?

Retrospectives are ones of the most critical must have agile practices. Is really easy to see the differences between a team who does retrospectives and other who don't. Unfortunately so many so called "Agile Adoptions" avoid doing teams retrospectives in regular basis. Unless you have a great Lean-like culture of continuous improvement in place in don't see sense killing retrospectives(Even if you have - IMHO the difference is that you do retrospectives in small batches and you don't need a especial day to do it). Retrospective Format & Styles There are several ways to perform an agile retrospective, some are time fixed like 1h or 2h. Other formats are very driven like the 6 hats, in this style of retrospective you have specific moment for talk good or bad about somethings. I found interesting work with these formats and for young and new agile teams they cloud help to focus on the right spot. IMHO i found really boring a...

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

O leitor que acompanha o meu blog de longa data sabe que tenho diversas críticas ao movimento ágil. Sempre expressei minha opinião de forma clara e embasada, mas acho que é mais do que justo eu ratificar as coisas boas que o movimento trouxe e o no que são melhores e mais fortes. Neste post vim falar sobre o que tem de melhor no Scrum. Não creio que o melhor seja a capacidade de entregar valor ao negocio rápido, pois isso diversos métodos o fazem. Esta é uma grande característica mas vários outros método como o RUP o OpenUP e até mesmo o EVO é capaz de fazer isso. A construção de uma Equipe O Scrum de maneira empírica é na verdade um grande protocolo para a construção de uma equipe. Isso mesmo construção de uma equipe. Todo projeto começa com um grupo e é uma necessidade básica transformar esse grupo em equipe. O Scrum prove através de um método simples, uma instância do PDCA uma forma de forçar a conversação na equipe e a reflexão dos atos das pessoas e claro do produto. Por que usar ...

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

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

Fazem quase 10 anos que o movimento ' agile ' apareceu, isso foi por volta de 2000. O que começou de uma maneira discreta hoje toma conta do mercado. Se fizermos uma consulta no site indeeed , sobre metodologias agíeis o resultado é o seguinte(pesquisa feita em 22/02/2009): Pesquisa por ofertas de emprego no site indeed (22/02/2009) Como podem ver é esmagadora a diferença do Scrum para os outros métodos. Muitos atribuem isso ao fato de Scrum ter um conjunto de certificações. Não tenho dúvidas de que esse é um dos principais fator de popularização do movimento através do famoso *pega-gerente*! Mas o que parecia ser muito bom para evangelizar sobre agile agora se torna contra os próprios. Pessoas estão culpando o Scrum pelo fracasso de projetos ditos 'agile'. Já vi vários agilistas falarem mais de certificações e da certificação de Scrum master mas o detalhe é que muitos deles tem essa certificação, quando não um botão grande no blog para mostrar isso! Veio a tona nos últ...

É possível ter um certo nível de predicatibilidade utilizando Scrum . Podemos realizar estimativas de valor com o método. Isso pode ser atingido mesmo com uma certa rotatividade de recursos humanos da equipe. O único requisito é que as iterações tenham o tamanho fixo. Falando de iterações com tamanho fixo isso é variável de projeto a projeto, empresa a empresa. O Recomendável é que isso fique de 1 a 4 semanas, pelo Scrum. Falando de RUP ou EVO por exemplo podemos ter iterações maiores, mas iterações mais curtas já se provaram mais produtivas. A grande questão a se balancear é o overhead de se fazer a retrospectiva do Scrum e abrir a nova Sprint pois esses processos comem tempo! Mas uma vez você escolhendo o tamanho de sua iteração ou como o Scrum chama: Sprint, você deve utilizar esse padrão sempre. Agora podemos estimar, o Scrum recomenda que utilizemos a sua medida abstrata que são os pontos, muitas pessoas utilizam isso em conjunto com User Stories ou até mesmo features. Eu parti...

Uma imagem fala mais que mil palavras. Muitas vezes usamos essa frase em diversas situações, mas as vezes esquecemos que isso pode ser útil em um projeto de TI Também. O Ron Jeffries um dos criadores do XP dá muito em foque nessa questão de sinalizar o que está acontecendo no projeto. Mas a questão não é apenas sinalizar isto para os stakeholders mas sim para a própria equipe do projeto também. Essa não é mais uma das coisas que vem do *Agile Hype*. Claro os caras fala nisso também, mas isso está ligado com uma questão muito maior e em muitas vezes mais perturbadora o Planejamento Estratégico. O Planejamento estratégico deve vir de cima, ou seja vir da aérea de negócio, assim ele pode ser cascateado para a TI e subseqüentemente cascateado para projetos de software através de uma técnica chamada Balanced Score Card . A partir do ponto que existe um planejamento maior por conta da organização a TI e os projetos derivados dela começam a ganhar sentido, sem esse alinhamento não garantia ...

Esse assunto é de natureza polêmica. O Scrum é uma metodologia ágil focada em gerência de projetos. Na minha opinião dentre as metodologias agéis disponíveis no mercado Scrum é a mais eficiente e mais realista. Porem o que acontece é que existem vários níveis de gerenciamento começando com o planejamento diário, passando pelo gerenciamento da Sprint(Iteração) e por fim no gerenciamento do projeto. Scrum atua no gerenciamento de tarefas, ou seja, no planejamento diário e no planejamento da Sprint. Isso por si em muitos casos não é suficiente. Em projetos de manutenção de sistemas, caso você não considere o uso do cliclo de projetos EUP, o Scrum é uma excelente opção. Em termos de desenvolvimento de sistemas pode ser uma boa opção também mas ai existem outros fatores na jogada. O que é bom no Scrum é a questão da escalabilidade, de fato ele pode suportar o crescimento de sua equipe, através de um S.O.S ( Scrum of Scrums). Além de poder ser aplicado em projetos grandes e pequenos provend...

Esse fim de semana eu estava me divertindo lendo o livro Agile Software Development: Evaluating theMethods for Your Organization do Alan S. Koch. Esse livro possui um ponto que ele fala sobre Processos, Ferramentas e Pessoas. Simplesmente fantástico. Ele simplesmente detona os Lunáticos do Agile que dizem que Pessoas é o que importa e o resto que se dane. Na verdade ele detona também os vendor de ferramentas e os processos. O que importa na verdade é as 3 coisas e o balanceamento entre elas. Como uma imagem fala mais do que 1000 palavras olha a imagem a baixo: Como você pode perceber se uma dos pés do banquinho for removido ele vem a baixo. Assim [e um projeto de software os três pés são fundamentais no sucesso de um projeto. Por mais que lunáticos do movimento ágil digam "Esqueça o processo e as ferramentas fique só com as pessoas " eles estão totalmente errados. Você consegue imaginar alguem trabalhando sem um IDE ou controle de versão ou uma ferramenta de Issue Tracking ...

Nos últimos 30 anos fomos bombardeados de processos e metodologias de desenvolvimento de software. Mas mesmo nos dias de hoje existe muita discussão sobre o assunto e bem como graves problemas de interpretação das coisas como elas são. Para começar gostaria de deixar bem claro que esse não é um artigo a favor do RUP e contra as metodologias ágeis ou vice-versa. Recomendo que os leitores que tem maior clamor religioso por metodologias que leiam a frase anterior pelo menos umas 10x. :) Agora gostaria de estabelecer dois marcos segundo o próprio Per Kroll . Uma coisa é o modelo de cliclo de vida de um projeto que pode ser cascata, sashimi, iterativo incremental, prototipação evolutiva , etc. Outra questão é o grau de formalismo de um projeto. No grau de formalismo as coisas podem variar do RUP ao XP. Essas metodologias tem um contraste de formalismo grande. Isso pode ser representado pela figura a baixo: Qual é um erro crasso que as pessoas cometem ao usar RUP? Não adaptar o processo. O ...

Estou participando de um projeto de Governança de TI. Nos últimos 2 meses venho estudando: XP , Agile , Scrum , Rup, metodologia, processos, universo e tudo mais :) Essa também é minha desculpa de TCR por não estar postando tanto como o de costume. Estou em um projeto de Governança de Ti e para criar processos e metodologia estamos usando Scrum entre outras práticas e valores agíeis. Venho lendo muito sobre o assunto, mas não me refiro apenas a métodos agíeis mais também ao Processo Unificado e tudo mais. Acredito que em determinados cenários uma metodologia seja melhor que outra, mas isso não é regra geral. Em projetos que Compliance é fundamental acredito que algo mais ágil como o XP de maneira pura seja bem complicado. Em outras vias em um projeto com uma equipe pequena e um escopo de 3 meses , acredito que usar Rup seria um tiro no pé. Do Processo unificado as metodologias ágeis existe um grande abismo de discrepâncias. O Rup tira muito peso das pessoas e coloca no processo, isso...