Diego Pacheco Tech blog

It's normal for engineers to think of the best solution possible when we think of solutions. A bad engineer would deliver as fast as possible without even considering whether his work is good enough or right. A "good" engineer would think a lot about how to do it and be very slow. A great engineer does both things. So, how can you be fast and slow at the same time? When we are working on a pretty small problem, or in a green field(a new project where you can do whatever you want), and/or a small company or startup with very little software. We all want to have success, and we want companies to thrive; success means more software, and more software often means more technical debt, and it becomes impossible to change everything all the time.

Software is very interesting, it's amazing how little things make a huge difference, being able to see all the small intricacies and how the pieces fit together is a complex and fascinating task. The more we understand, the more we learn effectively, better we can do it. Software complexity does not reduce, it only grows, working with a relentless mindset of continuous improvement is the only way to go forward. Refactoring is often seen as a "bad word" a big spooky thing because everybody believes is busy, so why are you risking breaking a lot of things if you can move forward and "live" with the problems. XP (Extreme Programming) got this right from the get-go, you need the principles and values. XP has a value called: courage; courage to do refactoring, especially when the conditions are not in your favor, considering monoliths and distributed monoliths the odds are never in your favor. Once you start doing so, slowly put all guardrails in place, would such c...

Today everybody talks about agile, yeah agile is mainstream. Agile become "Management", scrum is better than waterfall but things are not working as they should. I`m not staying you not need management. As you grown into a complex structure you will need coordination, costs control, and management is need as you get something bigger and complex. But in order to get it right you need realize when and where you fit management. People talk a lot about scaling agile and i think is funny so little is about engineering. People talk about multiples teams, multiple Product owners, multiple work streams, multiple timezones and cultures but where is the engineering? Deming(The Big mind behind Lean) talk a lot about psychology and the ability to understand systems and they nature.  Go Google you will lots of things talking about teams and so little talking about stuff like: Culture, Engineering practices, software architecture(real one, not power points) and principles.

XP is about getting the right values and practices and maximize it to the extreme. CODE it's essential and practices like pair programming and unit testing / test driven are a must have. I don't think they are enough, so i like to work a lot with team code reviews and design sessions. As a Software Architect I found such techniques very effective specially in scenarios that the team is beginning with XP and don't do pair programming effective or the team technical skills have a huge contrast.  I'm not against pair programming of testing BUT this old fashion techniques work as well.

Workplace it's a critical factor of people satisfaction, create agile workplace its not just put a bunch of post-its on the walls but create a environment that some behaviors can emerge and people are able to do they're best on the work, Environment and workplace are not the same thing to me :-). Many companies say they care about good workplace and I believe they do but not always a good workplace is a good agile environment. You deserve a good workplace, it's amazing how at least one time in life (or several) we end up working in such a terrible workplaces. No body deserve it work on a bad workplace, in fact I think(this is my devil side) it's good, so this serve to teach us to value a great workplace. 

Agile is really about culture. Culture not only means how we approach on software development but how we tech teams and customer the new mindsets.  Change culture is hard, growing teams its harder, culture is something really powerful and yet danger. Training is a must have, to promote change, but is not the only thing and is far to the be game change act, don't get me wrong, I'm totally pro training BUT I'm just saying that training is the basic not the big deal nor the big turning point. The title of this should should be actually: "Promote the culture and keep doing it". That's key element of changing culture, every meeting, every retrospective, every planning, every training, everything 'ts a opportunity to keep promoting the culture. It's like that great quote says: “We are what we   repeatedly   do. Excellence, therefore,   is not an act ,  but a   habit .” There is a implicit thing here, I m...

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

Pair Programming is one of the most simple and yet harder on XP practices. It's amazing how much sense of private ownership we built before embracing XP practices, lots of folks argue that private ownership is better or fits better for they believes. For years I had this thoughts about my classes are not yours. Some mindsets are harder to get, like developer written tests, that's hard one too but I will not talk about tests today, this is another conversation :D Ownership has power and this is one of the compelling reasons what should you care about pair programming.

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

Em 20 de Novembro de 2010 eu participei do Agile Day 2010 Porto Alegre. O evento estava muito bom e de muito nível. Neste evento eu fiz um Lightning Talk sobre XP em projetos Offshore. Pairing with the queen View more presentations from Diego Pacheco .

Apresentação que fiz no TDC 2010 em Florianopolis. SOA com XP: Um Bom remédio - TDC 2010 View more presentations from Diego Pacheco .

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

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

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

Mesmo que você não esteja utilizando XP ou até mesmo Agile , você pode reduzir boa parte da carga de trabalho de gerenciamento de projetos! Um gerente de projetos normalmente tem que ficar atualizando uma seria de artefatos que são utilizados para acompanhar tanto o status do projeto como riscos, requisitos e entre outras coisas. O XP determina uma role que ele chama de Tracker . Essa pessoa normalmente faz a atualização de gráficos, de riscos, do próprio backlog se você utiliza Scrum por exemplo. O XP determina que essa pessoa seria o Tracker de todo o projeto. Eu vejo uma aplicação mais nobre para esse papel, se você desenvolve de maneira iterativa com iterações de 1-4 semanas você pode fazer um roteamento de Tracker. O Tracker não precisa ser a mesma pessoa sempre, o ideal é que esse papel seja um papel rotativo, assim todos ficam mais ciente do que está acontecendo no projeto e um bom peso é removido do gerente. Sem falar que com a rotatividade todos da equipe irão participar das...

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

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