Débito Técnico

Nesta semana eu e o Phillip Calçado compartilhamos uma coisa: nós lemos artigos numa revista fora do mundo de tecnologia (se é que existe isso hoje em dia) e achamos conceitos ágeis lá. Veja este post no blog gringo dele:

BigPharma Problems & Solutions: Have You Seen This Before?

Na edição brasileira da Harvard Business Review de junho/2008, Tim Brown escreveu um artigo apresentando o “Design Thinking”. Ao ler o artigo ví que Design Thinking é recheado de conceitos ágeis. Muito recheado! É praticamente uma abordagem ágil para a inovação em todas as esferas empresariais.

A abordagem de [Thomas] Edison é um dos primeiros exemplos do que hoje se chama design thinking - metodologia que imbui todo o espectro de atividades de inovação de um etos de concepção centrado no homem… Edison não era um cientista especializado num campo apenas - era, antes, um generalista com aguçado tino comercial. Em seu laboratório em Menlo Park, New Jersey, Edison se cercava de gente com talento para improviso e experimentação. Na prática, derrubou o mito do “inventor genial e solitário” ao criar uma abordagem de equipe à inovação.

Preste atenção nesta parte:

A idéia era justamente não corroborar hipóteses preconcebidas - mas ajudar o investigador a aprender algo a cada lance iterativo.

(grifo meu)

É interessante ver como pragmatismos estão florescendo dentro no mundo empresarial das pessoas espertas e como mais e mais rigidez e controle estão obscurecendo a vida das empresas burras. Design Thinking é uma perspectiva humana para a solução dos problemas. É o envolvimento de cada indivíduo, de cada mente, na busca de uma solução viável e criativa. Isso envolve empatia, raciocínio integrativo, otimismo, experimentação e colaboração. O Design Thinking é a dinâmica de um processo colaborativo de inovação. Relatando um caso de solução para um problema de um grupo de enfermagem da Kaiser (não é a fábrica de cervejas), Tim Brown acrescenta o que colaborou para a solução:

…as equipes de inovação exploraram soluções potenciais por meio de brainstorming e prototipagem rápida… Um teste com protótipos não precisa ser complexo e nem caro. Um protótipo deve consumir apenas a quantidade de tempo, esforço e investimento necessária à geração de um feedback útil a evolução da idéia - nada mais. Quanto mais “acabado” parecer um protótipo, menor a probabilidade de que seus criadores ouçam o feedback - e se valham dele.

Olha que engraçado! A HBR, uma revista tradicionalíssima, está dizendo que meus protótipos visuais estão certos! Quando aquele gerentinho metido torcer o nariz poderei falar: “- Você leu o artigo sobre Design Thinking na Harvard Business Review?”

…o que ocorreu na equipe de enfermagem da Kaiser não foi um avanço súbito e revolucionário, nem o estalo de um gênio - foi fruto do trabalho árduo realçado por um processo criativo de descoberta centrado no ser humano, seguido de ciclos iterativos de testes com protótipos e aperfeiçoamento.

Esta é a parte que mais gostei (comentários meus entre parênteses):

O melhor jeito de descrever o processo de design é metaforicamente (Beck?) - como um sistema de espaços, em vez de uma série predefinida de passos ordenados (Gantt?). Esses espaços delimitam tipos distintos de atividades correlatas que, juntas, formam o continuum da inovação. O Design Thinking pode parecer caótico para um marinheiro de primeira viagem (seu chefe?). Mas, no decorrer de um projeto, os participantes acabam entendendo que o processo faz sentido e produz resultados (um release?), ainda que sua arquitetura seja distinta do processo linear fundado em marcos intermediários característico de outras atividades empresariais.

Este parágrafo no artigo é uma das melhores definições que já ví a respeito da natureza de um processo de design. Desenvolver software é 100% design. Isso foi tão contundente pra mim que contactei o Tim Brown - o autor do artigo - perguntando se ele tinha sido influenciado pelas práticas do Agile Software Development. Veja a resposta dele entre outras coisas:

From: Tim Brown
Date: 2008/7/2
Subject: Re: Article about Design Thinking on Harvard Business Review
To: Rodrigo Yoshima

Hi Rodrigo,
It doesn’t surprise me to hear that software design shares many of the same characteristics as design thinking. You are right that there has not been a lot of interaction between these two communities other than through the computer human interaction folks where I think a lot of these same issues have been discussed.

Thanks for making the link.

Best regards
Tim

On 6/30/08 5:53 PM, “Rodrigo Yoshima” wrote:

> Hi Tim,
> I’ve just read your article about Design Thinking and I’m
> just very very curious about how you put Design Thinking
> pratices together. Design Thinking concepts are very close
> to Agile Software Development Practices. Have you ever
> heard about it? Take a look at www.agilemanifesto.org.
>
> I see that the values of the Agile Manifesto is our flag of
> Design Thinking on Software Development. 100% of the
> software construction is design. Agile Practices are:
>
> - Human centered / Focused on Team Work
> - Iterative / Cyclical / Feed-back based
> - Use a lot of Prototypes / Sketches
> - Empirical
>
> I guess that you can really benefit from the contents
> that our community have being studying for the last 20 years.
>
> Cheers.
>
> Rodrigo Yoshima
> ASPERCOM / MundoJava

Sim! Mais uma vez provamos que o futuro do mundo empresarial é empírico e pragmático. Mais uma vez está provado que rigidez e processos inflexíveis impedem a inovação. Quem só tem martelo na mão só vê pregos pela frente… e sai martelando tudo.

Este conteúdo que postei só pra iniciar o blog faz críticas duras a maneira como projetos de software são construídos ou gerenciados. Muitas empresas utilizam essas má praticas e já esperava que a opinião de muitos leitores iriam divergir. Vou tentar explicar um pouco mais meu ponto de vista.

De qualquer forma, desculpem a sinceridade, desculpem se isso pode ofender alguém, desculpem falar “na lata”, mas SÓ AGILIDADE FUNCIONA.

Desde 2005, quando iniciei a área de treinamento da ASPERCOM ouço constantemente uma afirmativa. Seja em palestras, seja em fóruns de discussão, seja em treinamentos, seja em consultoria ou projetos que participo, sempre ouço participantes dizendo “Tudo o que você falou que é errado é o que praticamos na nossa empresa.”

É triste mas é verdade. Existe um gap muito grande entre a teoria e a prática na nossa área de desenvolvimento de software. Por exemplo, neste ano de 2008 já tive contato com aproximadamente 200 profissionais em treinamentos. Numa pesquisa rápida, TODOS disseram praticar o processo de desenvolvimento em cascata (waterfall), mesmo que este modelo seja comprovadamente ineficiente e seja refutado por TODOS os autores que escrevem sobre desenvolvimento de software. Até mesmo o autor que cunhou o termo “Waterfall” já reconhecia que era um modelo que não deveria ser utilizado, que é um anti-pattern. Teve um aluno de uma turma de UML que ainda foi mais enfático “- É lógico que todo mundo aqui faz software em cascata!”.

Antes de continuar, para tentar explicar porque só agilidade funciona, vamos ver uma “ilusão” que o mercado tem chamado de “Modelo Tradicional” (ou agora também temos o “Modelo Controlado”, mais um devaneio inconsequente escrito por um “especialista” sem noção).

Modelo Tradicional x Modelo Ágil

A pergunta que me levou a escrever é: O que é o Modelo Tradicional? Durante aproximadamente uns 2 meses perguntei em praticamente todos os fóruns de discussão que participo (veja links do Blog) o que seria o modelo tradicional. Essa pergunta foi provocativa, mas ao mesmo tempo elucidadora para muitos. O fato é que NINGUÉM soube responder o que é o Modelo Tradicional. Ninguém soube explicar, ou citar, que autor escreveu ou defendeu algo chamado “Método Tradicional de Desenvolvimento de Software”. Nenhum modelo de processo é Tradicional. O Modelo Tradicional não existe.

Alguns citaram que o modelo tradicional é o Waterfall. Bem, como expliquei aqui, o Waterfall não é defendido em nenhuma literatura. Ok… ele pode ser tomado como tradicional pois é o modelo mais utilizado, porém, o modelo waterfall não tem sustentação teórica. Nenhum autor sério defende waterfall. Como pode pois a nossa indústria estar usando um modelo que desde o nascimento foi taxado como anti-pattern? Se o Waterfall é o modelo tradicional, seguimos uma tradição bem burra.

Outros citaram que o modelo tradicional é o RUP. Mais uma discordância aqui. O RUP é um “agile process framework”. Jacobson, Larman, Booch, Ambler são Rupeiros de plantão como eu e praticam agilidade. O problema com o RUP é que poucos compreendem o RUP. Já ví muitos “especialistas” em RUP falando muita besteira no mercado. Aqui no Brasil conheço 5 a 10 pessoas que realmente conhecem o RUP. O mercado tem um poder enorme de deturpar coisas que ele não compreende (quantas vezes você não ouviu sarcasticamente que XP “é aquela metodologia que são dois programadores por micro”?). O RUP verdadeiro, o que consta na literatura, é ágil. Se o RUP verdadeiro fosse o adotado nas empresas todas seriam ágeis e este artigo não precisaria existir.

Outros citaram o SWEBOK como sendo o Modelo Tradicional. Bem, o SWEBOK é um body-of-knowlegde jogado as moscas. Ninguém tá procurando hoje SWEBOK. SWEBOK surgiu recentemente, assim, não poderia ser tomado como Tradicional. O RUP é um body-of-knowledge mais maduro e mais experimentado que o SWEBOK.

Se você nunca parou para pensar pergunte a sí próprio: Quem falou que desenvolvimento de software é sequencial como Caso de Uso - UML - Codificação e Teste? Quem disse que Gantt Chart é bom para desenvolvimento de software? Que pesquisa revelou que especialização e divisão do trabalho é uma boa idéia para software? Por que eu tenho que levantar todos os requisitos antes? E a principal: Se waterfall funciona por que meus clientes estão insatisfeitos?

Essas práticas não tem o mínimo fundamento teórico, nenhuma literatura prega que desenvolvimento de software é assim. Sim, você que é universitário pode questionar seu “mestre”, pois muitos não tem a mínima noção ou experiência no que estão ensinando. Essas práticas erradas são “idéias” que gerentes burros adotaram simplesmente fazendo um comparativo com linhas de produção da indústria. Eles se encheram de práticas sequenciais e colocaram uma placa na frente da empresa: “Fábrica de Software”. Eles simplesmente viraram as costas para os avanços da tecnologia e desenvolvem software como se estivessem furando cartões em 1960.

Com isso colocado, não vejo o mínimo sentido as pessoas afirmarem que são “tradicionalistas” no desenvolvimento de software e por isso não são ágeis. Não faz sentido pessoas dizerem “Eu desenvolvo software no modelo tradicional e estou estudando modelos ágeis”. Se você parar para pensar, essa pessoa começou agora a estudar desenvolvimento de software. Não confunda tradicionalismo com burrice.

Agilidade não é falta de controle

Como o já citado “devaneio inconsequente“, o mito mais comum é que modelos ágeis são descontrolados e que não dão informações para o gerenciamento. Quando falamos sobre controle temos que ter em mente o que realmente queremos com o projeto.

Como podemos planejar e ter precisão nas nossas estimativas?

Como devemos capturar os reais desejos do cliente?

Como incorporar as constantes mudanças no projeto?

Como fazer com que as mudanças não impactem aquilo que funciona?

Qual arquitetura é a certa para meu projeto?

Como garantir a manutenção futura do sistema?

Como saber o real andamento do projeto de uma maneira livre de riscos?

Como ter certeza que estamos satisfazendo a real necessidade do cliente?

Como fazer a equipe não se dispersar?

Como manter a documentação atualizada?

Como manter prazo e planejamento num projeto em constante mutação?

Como me antecipar aos riscos?

Quais são as ferramentas certas?

Como evitar correrias, horas extras e a explosão de custo no final do projeto?

E a melhor de todas: Como fazer o projeto ser entregue muito antes do prazo?

Creio que estas e muitas outras perguntas são dúvidas muito frequentes para qualquer equipe que desenvolve software. O mais interessante é que a resposta está na frente deles e se chama AGILIDADE.

Os modelos ágeis são os modelos MAIS CONTROLADOS QUE EXISTEM. Se eu disser para você é possível fazer com que a equipe trabalhe motivada, focada em objetivos e que a assertividade das estimativas são muito próximas de 100% você acreditaria? Se eu disser para você que o simples fato de planejar baseado em objetivos e promover uma reunião diária de 15 minutos pode fazer com que a comunicação enriqueça e que o cliente sempre fique satisfeito mesmo com algumas falhas você acreditaria? As práticas do Scrum (que são baseadas no RUP) promovem esse tipo de controle.

Outros pontos. Se eu falar para você que com seu código coberto de testes automatizados você poderá incorporar mudanças com uma segurança total você acreditaria? Se eu falar pra você que esses mesmos testes automatizados podem servir como documentação dos requisitos e do design de maneira executável, e que através de um relatório de cobertura e muitas outras ferramentas deterministas é possível saber se a “documentação” está atualizada de fato, você acreditaria? Essas são práticas do XP e da TDD.

Se eu falar para você que aproximar o cliente da equipe de desenvolvedores, promover a colaboração e colocar “dois programadores para trabalhar numa mesma máquina” trocando pares é um excelente mecanismo para ganhar produtividade removendo atividades inúteis você acreditaria?

A melhor resposta para o controle são práticas ágeis. Até o momento nenhum outro modelo provou ser eficaz. Nem Gantt, nem PMBOK, nem CMMI, nem MPS.BR são modelos completos que garantem respostas para as perguntas acima. Muito menos um mito, um dogma, um devaneio inconsequente que se criou nas mãos de pessoas que não sabem desenvolver software e chamaram isso de “tradicionalismo”.

Práticas ágeis não competem com “alguma outra coisa” que funciona.

Conclusão: (pela milésima vez)
O modelo tradicional não existe.
Só Agilidade funciona.

Durante um único dia de trabalho de uma equipe ágil temos alguns instantes que fazemos a reunião em pé do XP ou o encontro diário do Scrum. Esta mini-reunião é um ponto de sincronização do status do projeto (é uma inspeção no ciclo da iteração). O Scrum sugere que essa reunião tome o tempo máximo de 15 minutos. Dentro de um dia de trabalho de uma equipe ágil, fora desses poucos minutos preocupados com o gerenciamento a equipe trabalha no sentido de fazer incrementos de software funcionar de maneira “atômica”, isto é, um pequeno requisito é capturado e rapidamente transformado em software funcionando. Isso é o ciclo ágil de um dia. Assunto que tratarei na próxima edição da MundoJava.

Uma caracterísca marcante do ciclo ágil de um dia é que ele é não precisa ser gerenciado no nível macro, isto é, ele não pode ser tomado como base para o andamento do projeto como um todo. Somente com software funcionando e usuários felizes é que você pode dizer que o projeto andou. Este ciclo ocorre de maneira muito rápida e quem gerencia é o próprio desenvolvedor. Essa responsabilidade é uma cultura auto-organizável que faz parte do cerne do gerenciamento ágil. Gerentes de Projeto e Coordenadores não devem interferir no trabalho que é responsabilidade técnica dos desenvolvedores.

Os pontos que defendo aqui são práticas ágeis essencialmente constantes na metodologia XP e no TDD. Infelizmente essas práticas não são adotadas na maioria das equipes que tive contato. Um padrão muito comum nas equipes são práticas fantasiadas de Unified Process (ou RUP) que seguem um formato “Casos de Uso - UML - Codificação - Teste”, seguindo basicamente um processo em cascata numa escala menor. Este modelo dá a entender que requisitos estão em Casos de Uso (geralmente em documentos Word), o projeto ou arquitetura está no modelo UML (uma abstração intermediária), o código simplemente é algo que o computador compreende e, ao final, testes baseados no Caso de Uso são aplicados.

Primeiramente, gostaria de deixar claro que esta pode ser uma maneira de você implementar uma funcionalidade específica de um usuário com certo sucesso, porém, esse tipo de desenvolvimento não deve ser sequêncial e nem mesmo ser um padrão para todas as funcionalidades e nem para todos os projetos. Se a funcionalidade é simples e a expectativa do usuário está clara, documentos de Casos de Uso e modelos UML podem ser descartados. Porém, existem outras maneiras de você alcançar este mesmo objetivo! O próprio RUP não prega este tipo de prática.

Este anti-pattern causa uma cegueira técnica. O fato de sempre ter Casos de Uso, UML, Código e Testes em cascata leva a equipe a acreditar que todos os requisitos estão em casos de uso, temos que modelar tudo e codificar é uma atividade pouco criativa, assim como os testes. Porém, se verificarmos que estatisticamente somente um terço dos requisitos estão em casos de uso [Cockburn], que modelamos somente o que precisa ser modelado [Yoshima] e que todo o processo de desenvolvimento de software é uma atividade criativa (inclusive os testes [Fowler]), vemos que este padrão é muito questionável e muito dispendioso.

Você pode utilizar Casos de Uso para capturar requisitos e utilizar UML para analisar um problema. A culpa não é dessas ferramentas! O maior problema desse padrão é não conversar mais com os usuários depois que o Caso de Uso está escrito, roubando sorrateiramente a comunicação entre a equipe técnica e o cliente durante o desenvolvimento. Refinamentos surgem o tempo todo! A equipe precisa durante o desenvolvimento ligar para o cliente e tirar dúvidas! É comum que durante a codificação novos requisitos não capturados emergam. Requisitos capturados, modelados, codificados e testados podem não ser o que o usuário queria de fato, pois artefatos como Casos de Uso e modelos UML são propensos a muitas imperfeições (são abstrações e não são naturalmente executáveis).

Vejo que o padrão “Caso de Uso - UML - Codificação - Teste” é uma má influência do processo Waterfall, que declaradamente é uma péssima prática para desenvolvimento de software. Esse pensamento seqüencial é ainda mais danoso quando tentamos encaixar este padrão dentro da divisão e especialização de trabalho do Taylorismo, comum em fábricas de software. Nesse cenário, um analista de negócios escreve Casos de Uso, um analista de sistemas desenha o modelo, um programador codifica e um testador testa. Essa equipe muitas vezes utiliza artefatos para se comunicar (e logicamente, cada passo geralmente é controlado por um Gantt Chart). Antes de prosseguir, veja a citação de Kent Beck a respeito do Taylorismo:

“Especialização e rigorosamente dividir e conquistar serviu para produzir mais carros de maneira mais barata. Na minha experiência esses princípios não fazem sentido como estratégia para desenvolvimento de software. Nem para o negócio e nem para o lado humano eles fazem sentido.” Kent Beck

A base da divisão do trabalho é que é possível quebrar um determinado processo em partes menores gerenciáveis, e se cada parte for otimizada, o processo como um todo é otimizado. A especialização diz que determinado recurso efetuando uma tarefa várias vezes torna-se ótimo para esta tarefa. A questão é que para desenvolvimento de software, nem sempre a soma “Casos de Uso + UML + Código + Testes” geram algo do agrado do usuário se ele não estiver envolvido em todo o ciclo. Isso nos mostra que esses passos não são mensuráveis. Além disso, um analista de negócio não se tornará um analista de negócio melhor se ele escrever muitos Casos de Uso, assim como acontece com um Analista de Sistemas ou Programador.

Desenvolvimento de software não é um processo mecânico. Todas as metodologias atuais pregam um trabalho coletivo, em constante comunicação, entrosamento e principalmente uma visão holística sobre o projeto (o todo, e não as partes). Se apegar a rígidos papéis e responsabilidades é péssimo sob qualquer aspecto para uma equipe que desenvolve software.

Feedback do Workshop Scrum ministrado na Sumus.

Este curso particularmente foi interessante pois toda a gerência (e até os donos da empresa) participaram. Eles procuram adotar uma estratégia “Enterprise Scrum”.

Não é só a imagem abaixo e a substituição do Gantt que foram empolgantes. A equipe demonstrou real entusiasmo com o planejamento e as práticas do Scrum!

Abraços a todos da equipe Summus.

———- Forwarded message ———-
From: Fernando
Date: 03/04/2008 12:19
To: Rodrigo Yoshima

Ae Rodrigo blz?

O pessoal curtiu muito o curso, todo mundo falou bem, e o impacto do curso ta na foto anexa no email, lembra aquele quadro do gantt chart? virou isso aí que voce tá vendo!

Abraços,
Fernando

No meu artigo “Entregue Software Funcionando! Gerenciamento de Projetos Ágil” (MundoJava #26) publiquei um manifesto contra o uso de Gantt Charts para projetos de software (ou qualquer outra atividade criativa e empírica). Segue o trecho!

Quase todas as organizações que tive contato tentam, e falham miseravelmente, aplicar Gantt Charts para controlar e reportar status do projeto. Vamos estudar um exemplo:

Clique para ver imagem completa…

PROBLEMA 1 – O processo é cíclico: É muito comum ver Gantt Charts de projetos de software com essa disposição, porém, uma das maiores razões do acompanhamento do projeto falhar com Gantt Charts é que o processo de desenvolvimento de software é cíclico e não linear da maneira Requisitos-Análise-Codificação-Teste. Além disso, os produtos dessas disciplinas são abstrações, assim, não podemos tomar um documento de requisitos e tratá-lo como “pronto” de maneira determinista.

O desenvolvimento de uma funcionalidade de software passa por VÁRIOS ciclos de Requisitos-Análise-Codificação-Teste. Essa é uma das razões que Gantt Charts sempre estão atrasados. Muitas vezes não é previsto pelo cronograma que durante os testes o processo pode voltar várias vezes para a codificação, para análise ou até para requisitos. Como esse tempo não está previsto, naturalmente o cronograma se torna impossível de se cumprir.

PROBLEMA 2 - Síndrome do Estudante: Um dos problemas comuns do foco em tarefas é um fenômeno chamado “Síndrome do Estudante” defendido por Eliyahu Goldratt na Teoria da Corrente Crítica. Esse fenômeno é simples de observar nos projetos. Alguma vez você viu um projeto de software controlado por Gantt Charts ser entregue antes do prazo? Creio que isso deve ser extremamente raro! Essa falha acontece porque um Gantt Chart funciona melhor para projetos com controle definido e não empírico. A Síndrome do Estudante é também chamada de Procrastinação. Procrastinar é adiar continuamente o início das tarefas simplesmente pelo fato do cronograma lhe dar “um prazo confortável”.

No cronograma acima podemos ver que foi dado 32 horas para o Júlio fazer a análise. Mesmo que ele consiga fazer esse trabalho em 8 horas, a tendência é que ele só diga que terminou após as 32 horas, ou talvez ele inicie a tarefa somente quando estiver lá pelas 24 horas do prazo. A síndrome do estudante é provada pelo fato que as pessoas realmente sabem o último minuto possível que elas têm para iniciar uma tarefa. Ela tem esse nome por conta do nosso comportamento quando temos uma prova marcada para daqui a um mês: só começamos a estudar um dia antes da prova!

PROBLEMA 3 – Essas dependências não existem! Muitas pessoas realmente acreditam que existe uma dependência Requisitos-Análise-Codificação-Teste. Essas pessoas estão em contato há muito tempo com Gantt Charts, organizações funcionais, divisão do trabalho e desenvolvimento em cascata, e essa exposição a práticas ruins gerou paradigmas na mente delas, porém, essas dependências não existem na prática! É possível que você faça Requisitos, Análise, Codificação e Teste tudo ao mesmo tempo, ou talvez, num prazo tão curto de tempo (em frações de minutos) de forma que não é interessante gerenciar essas dependências!

Uma das coisas que as pessoas não compreendem na metodologia XP (Extreme Programming) é a prática do TDD (Test-Driven Development). Nessa prática, testes são escritos antes que qualquer código da funcionalidade seja escrito. Dessa forma, não existe código não testado e os testes são feitos antes ou durante a codificação. A idéia é: codifica-se um pouco, testa-se um pouco, e esse ciclo ocorre centenas de vezes num único dia. Outro ponto: agilistas gostam de tomar os testes como sendo seus próprios requisitos, então, testes e requisitos tornam-se uma coisa só. Dessa forma, numa única semana, o ciclo requisitos-codificação-teste pode ocorrer MILHARES de vezes dentro de uma equipe!

O levantamento dos requisitos podem ser feitos a qualquer momento através da prática do “cliente presente”, ou através de uma ligação telefônica para o cliente. A análise pode ser feita de modo incremental assim que novos requisitos vão sendo adicionados no projeto (via refactoring). As disciplinas não são fases! Elas ocorrem ciclicamente e esse ciclo numa equipe ágil é tão rápido que o custo para gerenciar isso não vale a pena. Acredite! Antes das pessoas começarem a tentar aplicar idéias Tayloristas no desenvolvimento de software, essa atividade era bem simples, divertida e a última preocupação que existia era o cronograma.

PROBLEMA 4 – A Grande Mentira da Porcentagem Concluída Leia o restante deste artigo »

Na MundoJava número 26 publiquei o artigo: “Entregue Software
Funcionando! Gerenciamento de Projetos Ágeis”. Nesse artigo escreví
sobre práticas erradas utilizadas em gerenciamento de projetos de
software. Vou passar uma listinha de tópicos abordados.

1. Manifesto Ágil
2. Software não é prédio
3. “Requisitos Detalhados” não são escopo
4. Um estudo de caso (não podia faltar, né?)
5. Por que Gantt Charts não servem para projetos de Software?
6. Liderança Corajosa x Gestão Covarde
7. Não confunda Tradicionalismo com Burrice

Recomendo que comprem a revista para os “gerentes” de projeto que
vocês têm que lidar no dia a dia!!!