Metodologias Ágeis de Desenvolvimento (Locaweb)

O pessoal da ThoughtWorks fez um vídeo divertido sobre o mundo ágil, fazendo uma versão da canção “My Favourite Things” (via @paulocaroli):

Recentemente Dov Bigio, Gerente de Produtos de Telecom da Locaweb, postou em seu blog sobre “O triângulo dos projetos“, que explica que dadas as variáveis de um projeto (qualidade, custo e prazo) pode-se fixar no máximo duas delas, e a terceira irá variar. Ou seja, se fixarmos prazo e custo, a qualidade poderá ser menor do que a esperada. Ou se fixarmos a qualidade e o custo, o prazo poderá ser maior que o esperado. Nunca conseguiremos fixar as três variáveis de um projeto.

O pessoal da 37signals prefere manter a qualidade sempre fixa (num patamar alto) e substituiu a qualidade pelo escopo no triângulo dos projetos. Eles também recomendam que devemos sempre fixar prazo e custo de um projeto e sempre flexibilizar o escopo.

Vou explicar como isso faz sentido usando como exemplo um projeto recente que tivemos aqui na Locaweb, o projeto de reescrever o site.

site da Locaweb antes do projeto de reescrever o site

Em novembro de 2008 decidimos que já havia passado da hora de termos um novo site que estivesse mais em linha com tudo o que temos estudado sobre experiência do usuário, design centrado no usuário, arquitetura da informação, design de interação e conceitos de web 2.0 com maior participação do visitante do site. Decidimos também o prazo, na primeira quinzena de março de 2009 esse site deveria estar no ar. E o custo também estava fechado: não íamos contratar ou pegar empresatado de outra equipe ninguém a mais para tocar esse projeto.

Tomada a decisão, começamos a desenhar o escopo do projeto. Dentre os vários requisitos do projeto tivemos:

• navegação simples e intuitiva
• manter o código bem enxuto
• aplicar SEO em todo o site
• minimizar o uso de flash
• design visual leve, para dar importância à informação contida nas páginas
• rever a arquitetura de informação de todo o site, revendo todo o conteúdo

Fizemos o planejamento para 6 sprints de duas semanas cada. Numa determinada altura percebemos que não ia dar para fazer tudo para lançar na primeira quinzena de março. Ficamos então pensando se íamos aumentar o prazo ou se podíamos cortar algo do escopo desse projeto.

A entrega de uma projeto é muito importante, tanto para a equipe que trabalhou no projeto, que fica com a sensação de “dever cumprido”, quanto para o cliente do projeto, que irá usufruir dos benefícios de ter o projeto pronto. Com isso em mente, decidmos diminuir o escopo, descobrir alguma coisa que pudéssemos cortar do projeto a fim de entregá-lo no prazo. Dentre as opções de redução de escopo, escolhemos não rever a arquitetura de informação de todo o site, mas apenas das áreas mais importantes.

Com isso conseguimos entregar a tempo e os visitantes do site - principal “cliente” desse projeto - puderam usufruir de seu novo layout e de sua nova organização.

site da Locaweb depois do projeto de reescrever o site

De uma certa forma, redução de escopo e redução de qualidade são parecidos, mas têm uma diferença fundamental. Podemos reduzir qualidade de duas formas:

• fazer tudo o que foi planejado, só que fazer mal feito, ou;
• fazer menos do que foi planejado, só que bem feito.

Já quando falamos em redução de escopo, não damos margem para interpretação: é sempre fazer menos do que foi planejado, mantendo o trabalho bem feito. E muitas vezes quando fazemos e entregamos menos, percebemos que o menos que entregamos já é suficiente e que o produto final de nosso projeto ficou melhor com menos do que o que foi originalmente planejado.

Então da próxima vez que você pensar em reduzir a qualidade de seu projeto para poder entregá-lo no prazo e dentro do orçamento, pense se não seria melhor reduzir o escopo. Você e seu cliente poderão sair ganhando com a redução de escopo!

Há quase um ano atrás eu comentei sobre a mudança do papel do gerente em um time que resolveu adotar metodologias ágeis. Na London QCon 2009 foi apresentada a palestra Managers in Scrum de Roman Pichler, um consultor inglês especializado em gestão ágil de produtos.

A apresentação completa pode ser vista em:

http://www.infoq.com/presentations/managers-in-scrum

Quem quiser ver só os slides, pode baixá-los aqui.

Vou destacar 4 slides que resumem a apresentação. Primeiro um slide que mostra como funciona a gerência tradicional:

Em seguida um slide que ilustra como deve ser a gerência em um ambiente ágil:

Uma comparação entre o processo de padronização antes e depois do uso de metodologias ágeis e o papel do gerente nesse processo:

E, por último, um resumo:

Vale conferir essa apresentação.

Recentemente li dois posts sobre a questão da cultura ágil e como alguns times usam apenas os processos embutidos nas metodologias ágeis sem absorver a cultura da agilidade:

• Agile development is more culture than process
• Creating The Culture For An Agile Environment

Pesquisando na Wikipedia, encontrei as definições abaixo:

• Cultura é um padrão integrado de conhecimento, crença ou comportamento humano que depende da capacidade de pensamento simbólico e de aprendizado social de um determinado grupo de pessoas. É também um conjunto de atitudes, valores, objetivos e práticas compartilhadas que caracterizam esse grupo de pessoas.
• Processo é um cojunto de tarefas e atividades relacionadas que produzem um determinado produto ou serviço para um ou mais clientes de uma empresa. Pode ser visualizado com um fluxograma.

Ou seja, o processo é o “como” enquanto a cultura é o “porquê”.

Sem dúvida o que mais importa é a cultura, já que sem o “porquê” é muito mais difícil seguir e manter o respectivo “como”.

As metodologias ágeis, ou seja, os processos de desenvolvimento de software que as metodologias ágeis definem, são consequência da cultura ágil.

A cultura ágil consegue existir sem as metodologias ágeis. Se falarmos apenas no manifesto ágil e em seus princípios para alguém que nunca ouviu falar nas metodologias ágeis, é muito provável que essa pessoa acabe criando os processos necessários para viabilizar a cultura ágil.

Por outro lado, dado o processo ágil, por exemplo o Scrum, é difícil entender o “porquê” esse processo deve ser seguido. Dá até para perceber que esse processo melhora o dia-a-dia do desenvolvimento de software, mas sem saber o “porquê” de o seguir, as chances de que o processo se mantenha ou, mais importante, de que o processo melhore, são bem baixas.

Daí a importância de entender a cultura ágil antes de implementar as metodologias ágeis.

Só que mudar cultura é tarefa de longo prazo, gradual e de difícil mensuração. E como toda tarefa de longo prazo, gradual e de difícil mensuração, é pouco atraente. As pessoas querem os resultados da mudança de cultura, mas não querem gastar o que é necessário para se chegar ao resultado. Daí a busca por receitas de bolo.

Implementar metodologias e mudar processos são tarefas de curto prazo, de impacto e de fácil mensuração (gráficos, pontos, etc.). Daí a preferência natural que temos pelas metodologias, pelas “receitas de bolo”.

É fundamental orientar a implementação das metodologias e as mudanças de processo para garantir que elas não se transformem em atos mecânicos e para que sejam gradualmente absorvidos como cultura da organização.

E orientar a implementação das metodologias e as mudanças de processo não é conhecer muito sobre o tema e fornecer respostas para perguntas do tipo “o que eu faço com os pontos dessa história que não acabamos nesse sprint?” ou “devo pontuar as histórias com pontos ou com horas?” ou “será que devo usar kanbam, lean, XP, Scrum, …?” ou …

A orientação que deve ser dada está em ensinar a “pensar ágil”. As metodologias ágeis são um auxílio para nos ajudar a pensar ágil mas muitas vezes, ao invés de nos ajudar a pensar ágil, nos faz não pensar. :-/

Só se muda uma cultura pensando, discutindo, argumentando, ouvindo, experimentando.

Seguir “receitas de bolo” sem pensar, discutir, argumentar, ouvir e escutar é receita certa para uma implementação mecanizada das metodologias e consquente fracasso.

Como dito no Outliers e em um artigo bem bacana de Scientific American, para ser um especialista em algo, devemos praticar de forma consciente, ou seja, sempre questionando e entendendo o que estamos praticando e nunca executar a “prática cega”.

Por isso, em sua próxima reunião de revisão e planejamento de sprint, ou mesmo na sua reunião diária, lembre-se que antes da metodologia ágil deve vir a cultura ágil. Releia junto com o seu time o manifesto ágil e seus princípios e discutam:

• por que esses princípios são importantes para nosso time?
• o que tem sido feito para seguir esses princípios?
• onde não seguimos esses princípios e por que?

Agilidade é cultura, as metodologias ágeis são os processos que ajudam a sedimentar essa cultura.

Em um post antigo, de 2007, um dos pais das metodologias ágeis, o Alistair Cockburn, enumera 10 formas de saber se um time NÃO está sendo ágil.

Acho que vale refletir sobre essa lista. Por um lado, é provável que vários itens dessa lista seu time já tenha resolvido, mas pode ser que ainda falte um ou outro item:

In no particular order, you know you’re not doing agile if:

1. The team is co-located, but people are not sitting within the length of a school bus to each other.
2. They’re distributed, and there is an absence of microphones and webcams and one or two meetings a day.
3. They have not delivered anything to real users in the last three months. Some of my agile friends would say that’s much too long, but I’m being generous there.
4. If no user has seen real running software inside the last month.
5. They don’t have the output of last month’s reflection workshop or retrospective on the wall.
6. They don’t have fully automated unit tests, and a large number of acceptance tests aren’t automated.
7. They’re not having a build integration at least once day. Good groups do it every half hour; there are groups that get away with it every other day.
8. They write big requirements documents, and they don’t know how to split those up into smaller pieces so they could deliver a piece of software every month.
9. They have itty-bitty requirements on the order of “here’s what happens when you click here,” but they don’t have long-term vision for what they’re trying to accomplish.
10. People keep saying, “It’s not my job.” One of the things about proper agile development is that there is group accountability for results. Very specifically, if the requirements are not coming in fast enough, whoever has a bit of spare time (programmers, testers, etc.) drops what they’re doing and helps gather requirements; if tests aren’t getting done, people with some spare capacity help test and so on.

Apresentação interessante sobre métodologias ágeis. Pode ser útil quando você precisar apresentar o tema em algum lugar:

Texto muito interessante sobre “deploy contínuo”. Seria o próximo passo depois de se alcançar a “integração contínua”.

http://startuplessonslearned.blogspot.com/2009/02/continuous-deployment-and-continuous.html

A idéia é bem simples (o destaque é meu):

The high level of our process is dead simple: Continuously integrate (commit early and often). On commit automatically run all tests. If the tests pass deploy to the cluster. If the deploy succeeds, repeat.

Our tests suite takes nine minutes to run (distributed across 30-40 machines). Our code pushes take another six minutes. Since these two steps are pipelined that means at peak we’re pushing a new revision of the code to the website every nine minutes. That’s 6 deploys an hour. Even at that pace we’re often batching multiple commits into a single test/push cycle. On average we deploy new code fifty times a day.

We call this process continuous deployment because it seemed to us like a natural extension of the continuous integration we were already doing. Our eventual conclusion was that there was no reason to have code that had passed the integration step but was not yet deployed.

Recentemente li dois posts sobre como “encaixar” UX em times que estão usando metodologias ágeis. Um deles é o “Agile UX: Como trabalhar com os designers” do Guilherme Chapiewski que trabalha na Globo.com. O outro é o “Agile UX: como integrar UX e desenvolvimento” do Antonio Carlos Silveira do Yahoo! Brasil.

Como o próprio Antonio apontou bem, essa preocupação sobre como integrar UX em um time de desenvolvimento de software que segue alguma metodologia ágil existe desde o início das metodologias ágeis. Alguns posts sobre o tema:

• Agile Development Projects and Usability: Jakob Nielsen descreve maneiras de garantir que a qualidade da usabilidade não seja ameaçada pela adoção de metodologias ágeis.
• Agile / Scrum Product Development Process: Marty Cagan propõe uma forma de integrar UX e Scrum.
• Extreme Programming vs. Interaction Design: Entrevista com Kent Beck e Alan Cooper sobre design de interação e XP. Nessa entrevista, chamada por alguns de “duelo de titãs”, Beck defende o desenvolvimento do design de interação de forma incremental, enquanto Cooper defende que o desenvolvimento de software não deve começar antes de todo o trabalho de design de interação ser concluído.
• UX Agile: um blog totalmente dedicado à questão de integrar UX aos times de desenvolvimento que usam metodologias ágeis.

Aliás a busca por Agile UX no Google retorna muitas e muitas páginas dedicadas ao tema.

Um exemplo interessante é a apresentação abaixo, da Leisa Reichert que ela apresentou na Web 2.0 Expo Berlin:

Sem dúvida há várias maneiras de se integrar UX e metodologias ágeis e o correto é escolher a maneira que se adapta melhor à sua situação e disponibilidade de recursos (tempo, dinheiro e pessoas).

Contudo, queria adicionar meus 2 centavos a essa conversa. Apesar de ser importante termos especialistas em UX, pessoas que conheçam a fundo sobre arquitetura da informação, design de interação, design visual e todos os temas relacionados à experiência do usuário, acredito que UX deve ser uma preocupação de todas as pessoas do time. Não há razão alguma para o PO e os membros do time não se preocuparem com o tema e deixarem tudo nas mãos de um especialista. E se esse especialista um dia não estiver disponível? Se ele estiver ocupado cuidando de outras coisas? Ou mesmo se não tivermos um especialista em UX no time?

Não estou querendo dizer que UX não é um tema complexo, que requer muito estudo e prática, mas acredito que todos nós devemos conhecer os conceitos básicos de UX.

Vou citar duas situações exemplo que ilustram bem a importância de todo o time se preocupar com UX:

1. Feedback: imagine que você tem em sua aplicação uma determinada função que não é executada na hora e que pode levar até 2 horas para acontecer. Na interface você implementa o comendo que executa essa função só que não informa o prazo. O usuário certamente vai se perguntar o que aconteceu, se a função foi de fato executada. Um solução é avisá-lo desse prazo logo após o comando ser invocado. O ideal é avisar antes mesmo de ele invocar o comando que executa a função.
2. Opções: imagine que você está desenvolvendo um formulário de pagamento com opções de pagamento por cartão de crédito. Você recebe o protótipo com um select que permite escolher entre Amex, VISA e Mastercard. Você implementa esse protótipo. Na hora de colocar em produção você recebe a informação de que inicialmente o sistema só irá aceitar Mastercard. Você edita o select e remove as outras opções. A sua interface vai ficar com um select de uma opção só! O correto aqui seria remover o select enquanto houver uma opção só.

Ou seja, não é necessário ser um especialista em UX para ajudar no desenvolvimento e melhoria de UX dos sistemas que seu time cuida. Leia, estude, informe-se, afinal conhecimento nunca é em excesso!

A AG2 é uma agência digital com mais de 70 pessoas envolvidas em desenvolvimento. Recentemente ele resolveram adotar o Scrum e abaixo o Marcelo Bacchieri, responsável pela área de projetos da AG2, conta um pouco dessa experiência.

[LW] Você poderia nos contar o que é a AG2 e que tipo de desenvolvimento vocês fazem?
[AG2] A AG2 Agência de Inteligência Digital S.A. é uma agência digital de soluções completas para grandes corporações. Atuante em nível nacional, é líder de mercado na Região Sul e uma das 5 maiores do país. Suas linhas de serviços proporcionam um ciclo de atendimento completo, tendo capacidade de resposta às necessidades de toda a cadeia de valor do negócio. A AG2 suporta seus clientes na definição de opções estratégicas e tecnológicas, desenvolve sistemas web sob medida para as mais diversas aplicações, bem como ações de comunicação interativa, provendo ainda toda a gestão operacional da presença digital. Com mais de 150 colaboradores nas suas bases de São Paulo, Porto Alegre e Pelotas, a AG2 atende empresas como Embraer, Bradesco, General Motors, Grupo Silvio Santos, Bunge, C&A e Vulcabras.

[LW] Quantos desenvolvedores trabalham na AG2?
[AG2] A AG2 conta com aproximadamente 30 colaboradores envolvidos diretamente no desenvolvimento de sistemas, como codificadores HTML, analistas de sistemas, DBAs, desenvolvedores .Net e analistas de testes e 40 nas disciplinas relacionadas a arquitetura de informação e interface, como analistas e projetistas de interface, diretores de arte, web designers, programadores Flash, além de profissionais de análise de negócios, criação e gerenciamento de projetos.

[LW] Vocês decidiram usar Scrum recentemente. Quando foi isso e por que vocês decidiram seguir esse caminho?
[AG2] Começamos a estudar Scrum pelo fato de ser mais uma metodologia de desenvolvimento de projetos, inicialmente mais em tom investigativo e para conhecer os conceitos do que efetivamente objetivando alterar nossos métodos. Durante o estudo notamos que vários aspectos dela poderiam se encaixar muito bem no que fazemos, agregando muito com relação a agilidade e velocidade de desenvolvimento que ela proporciona. Devido principalmente aos prazos sempre apertados que temos para desenvolver e o teor de alguns projetos começamos a fazer alguns testes em alguns projetos.

[LW] Você utilizam só Scrum, ou usam outras metodologias também como o XP?
[AG2] Apenas Scrum.

[LW] Como foi a implementação do Scrum? Foi em toda a equipe de desenvolvimento ao mesmo tempo? E qual foi a receptividade? Todos gostaram ou houve alguma resistência?
[AG2] Começamos a implementar o Scrum de forma bem “comportada”. Inicialmente montamos alguns workshops para apresentar a metodologia para a equipe e discutimos bastante os benefícios e os possíveis problemas que poderíamos enfrentar com esse nova metodologia. Uma vez conversado entre o time de desenvolvimento, observamos a possibilidade de aplicarmos Scrum em um projeto especifico e assim o fizemos. Ou seja, não saímos alterando nossos métodos e processos do dia para a noite. Queríamos fazer nossos próprios testes e tirar as nossas conclusões. A receptividade dos envolvidos foi ótima! Tendo em vista que o Scrum prima pela multidisciplinaridade e o envolvimento completo do time do projeto, todos os integrantes envolvidos no piloto passaram a se sentir mais presentes e agregadores ao projeto. Não tivemos praticamente nenhuma resistência na implementação da metodologia.

[LW] Como foi feita a divisão dos times? Quantas pessoas por time? Como vocês fazem para integrar todos os times?
[AG2] Os times que montamos (e ainda estamos montando) tem em média 9 integrantes. Para cada time optamos por colocar diferentes disciplinas de desenvolvimento, de forma que um time tenha capacidade de desenvolver qualquer tipo de demanda e seja auto-gerenciável. Ou seja, temos Desenvolvedores .Net junto com Diretores de Arte, sentados lado a lado em locais físicos específicos para o time. Com relação a “sintonia fina” das equipes, outra coisa que fizemos na montagem dos times foi agrupá-los por cliente. Isso faz com que a cultura de cada um dos clientes seja absorvida de forma mais visceral pelo time, resultando em projetos bem mais aderentes aos objetivos de nossos contratantes.

[LW] Como responsável pela gestão de projetos, quais as vantagens que você vê em usar metodologias ágeis de desenvolvimento em comparação com modelos mais tradicionais de gestão de projetos?
[AG2] Creio que todos os modelos de gerenciamento de projetos tem as suas vantagens e estas são exponencializadas de acordo com os projetos propriamente ditos. Aqui na AG2 desenvolvemos alguns projetos usando modelos mais tradicionais em cascata e outros usando Scrum. Decidimos o modelo de gestão para um projeto específico baseado nas características de cada um deles. Se vislumbramos algo com escopo razoavelmente definido e altíssimo grau de complexidade talvez optemos por um modelo mais clássico de desenvolvimento, pois talvez um modelo ágil não seja o mais adequado para esta ocasião. Ao passo que, se nos deparamos com uma possibilidade de desenvolvimento onde temos uma variável de tempo muito curta e muitas indefinições, a metodologia ágil tende a aumentar muito as nossas chances de sucesso. Então, creio que quem dita as vantagens realmente são os projetos.

[LW] As metodologias ágeis prevêm a presença do cliente junto da equipe de desenvolvimento. Vocês conseguem ter o cliente por perto durante o desenvolvimento?
[AG2] A grande maioria de nossos clientes são extremamente participativos no decorrer de todo o desenvolvimento. Nestes casos envolvemos o cliente do inicio ao fim explicando os benefícios de seu envolvimento no processo de tomada de decisões e no processo produtivo como um todo. Isso sempre se mostra uma excelente forma de aumentar a possibilidade de sucesso do projeto. Reuniões de definições de prioridades para desenvolvimento e aprovações acontecem durante todo o projeto e as indesejáveis surpresas deixam de acontecer. Quando é mais difícil agregar o cliente ao processo elegemos alguém que represente o cliente em nossa estrutura, geralmente o profissional de Atendimento. Dessa forma tentamos aproximar ao máximo as percepções do cliente ao nosso dia a dia de trabalho.

[LW] Um grande questionamento que existe é sobre como encaixar o design visual no processo de desenvolvimento de sistemas usando metodologias ágeis. Como vocês conseguiram combinar o design visual com o desenvolvimento?
[AG2] A forma que estamos utilizando para desenvolver o design juntamente com a parte de programação inserido na metodologia ágil é tentar mantê-las independentes o máximo de tempo possível. No inicio do projeto tentamos definir o Backlog de cada Sprint de forma que os desenvolvedores de sistema possam programar as funcionalidades que são totalmente independentes da Interface, ao passo que o pessoal do design possa se preocupar com a arquitetura da informação, navegabilidade e estética do projeto. Em Sprints subseqüentes, devido ao aumento do conhecimento de toda a equipe assim como a melhoria da definição do projeto começamos a aproximar as áreas para que a integração entre elas ocorra sem problemas.

[LW] A adoção de metodologias ágeis é um processo de constante aprimoramento. Quais são os seu próximos objetivos?
[AG2] Estamos engatinhando ainda no que diz respeito a metodologias ágeis. Nossos próximos passos são realmente comprovar a eficácia com relação a rentabilidade e performance dos projetos e aumentar a cultura destes métodos na AG2. Treinamentos e workshops são as medidas imediatas para que todos sintam-se confortáveis e confiantes com o uso delas. A partir desse ponto veremos o que o futuro nos apresenta…

Se você também quer compartilhar a sua experiência, mande um email para joaquim ponto torres arroba locaweb ponto com ponto br.

Outro dia me deparei com um post no blog da 37signals sobre sistemas complexos que trazia uma citação de John Gall:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

Fuçando um pouco descobri que esse John Gall, um pediatra, escreveu em 1978 um livro chamado “Systemantics, How Systems Really Work and Especially How They Fail” com um conjunto de leis que regem quaisquer tipos de sistemas, que podem ser desde programas de computador até o corpo humano, o universo, uma cidade, uma empresa, etc.

O livro é uma espécie de paródia ou crítica à teoria de sistemas que foi criada por Ludwig von Bertalanffy, um biólogo austríaco, no início do século passado.

Systemantics teve uma segunda edição, “Systemantics: The Underground Text of Systems Lore”:

E na terceira edição foi rebatizado como “The Systems Bible: The Beginner’s Guide to Systems Large and Small”:

Apesar de ser uma paródia, no estilo das Leis de Murphy, ou mesmo por ser uma paródia, as leis de Systemantics fazem refletir, principalmente quando as lemos pensando em desenvolvimento de sistemas e produtos de internet.

Além da citação do início desse post, gosto particularmente das leis abaixo, que refletem muito a forma de pensar das metodologias ágeis:

• The Functional Indeterminacy Theorem (F.I.T.): In complex systems, malfunction and even total non-function may not be detectable for long periods, if ever.
• The mode of failure of a complex system cannot ordinarily be predicted from its structure.
• The larger the system, the greater the probability of unexpected failure.
• Colossal systems foster colossal errors.
• Choose your systems with care.

As 5 primeiras leis são bem interessantes também:

• The Primal Scenario or Basic Datum of Experience: Systems in general work poorly or not at all. (Complicated systems seldom exceed five percent efficiency.)
• The Fundamental Theorem: New systems generate new problems.
• The Law of Conservation of Anergy [sic]: The total amount of anergy in the universe is constant. (”Anergy” = ‘human energy’)
• Laws of Growth: Systems tend to grow, and as they grow, they encroach.
• The Generalized Uncertainty Principle: Systems display antics. (Complicated systems produce unexpected outcomes. The total behavior of large systems cannot be predicted.)

Uma lista mais completa das leis pode ser encontrada em:

http://en.wikipedia.org/wiki/Systemantics

E nos links abaixo há a lista de leis com alguns comentários:

http://www.laetusinpraesens.org/docs/systfail.php
http://www.draftymanor.com/bart/systems1.htm
http://www.ece.osu.edu/~fasiha/systemantics

Fecho esse post com uma lei específica sobre evolução que é bem apropriada aos sistemas desenvolvidos usando metodologias ágeis:

As evolution is the only system known to produce intelligent behaviour, it is to be preferred.