Semicondutores: Toshiba vai projetar chips no Brasil em 2011

"Pecado: O culpado da persistência do modelo Waterfall no desenvolvimento de Software?"

Pecado: O culpado da persistência do modelo Waterfall no desenvolvimento de Software?: "Quer entender melhor por que o manifesto Ágil fala em valorizar mais a colaboração com os clientes que a negociação de contratos? Um novo livro de um autor clássico dentro de nossa área de Engenharia de Software pode nos ajudar.

Estou lendo o novo e fantástico livro novo do Frederick Brooks, de título The Design of Design. Para aqueles da nossa área que ainda não o conhecem, Brooks é o autor do clássico livro de engenharia de software The Mythical Man-Month (que considero leitura obrigatória para executivos da área de TI).

Os primeiros capítulos do novo livro de Brooks são os mais interessantes, pois evidenciam claramente os problemas de se tentar realizar o design e construção de um produto seguindo um modelo cascata ( Waterfall ).

O capítulo 3 se chama 'What's wrong with this model?' e é focado em explicar porque, nas palavras de Brooks: 'o modelo cascata é errado e perigoso; precisamos superá-lo'. Ele inclusive mostra como o próprio Winston Royce (suposto inventor do modelo cascata) critica fortemente o modelo cascata no mesmo artigo em que o descreve (Royce apenas o usou como uma referência do que NÃO funciona).

O resultado de um processo de produto Waterfall (onde os requisitos são completamente definidos antes do design e implementação começarem) é um conjunto de requisitos enorme e gigantesco, a união de muitas listas de desejos, levantada sem nenhum tipo de restrição. E, para piorar, a lista não é priorizada ou medida em termos de custo versus benefício. As forças sociais envolvidas acabam proibindo o conflitos dolorosos ocasionais gerados pela priorização.

Nas palavras de Brooks: 'a proliferação de requisitos deve ser combatida, através de controle de natalidade e infanticídio destes requisitos'. Ele inclusive dá um excelente exemplo de uma pesquisa realizada por um comitê nacional americano em projetos militares dos EUA: 'Os projetos extremamente bem sucedidos tem um ou muito poucos objetivos e urgência de cronograma. Esses projetos começam com poucos requisitos de alto nível. Enquanto o desenvolvimento procedia, estes eram quebrados em requisitos mais específicos. Estes requisitos eram controlados e priorizados fortemente por gerentes capazes que continuamente balanceavam funcionalidade em relação a custo e prazo'.

Aí vem a grande pergunta de Brooks no capítulo 4, de título 'Requirements, Sin and Contracts': como podemos explicar a persistência de um modelo perigoso como o Cascata, quando já sabemos através de evidências maciças levantadas durante quase um quarto de século de que o modelo espiral/iterativo produz melhores resultados?

Antes da resposta, vamos supor o seguinte:

- O cliente ficará feliz em pagar para o seu fornecedor um preço justo pela sua experiência e trabalho.

- Ele conseguiu um fornecedor que age e usa suas habilidades para servir aos interesses reais dos clientes. Este fornecedor também realiza seu trabalho sempre almejando construir produtos com alta qualidade na melhor proporção de custo-benefício, dentro do prazo e orçamento.

- Todos são honestos, verdadeiros e a comunicação entre eles é excelente.

Tendo isso em vista, Brooks nos mostra que:

- Um contrato que pague o custo do fornecedor mais um bônus por metas irá dar ao cliente e ao fornecedor o melhor valor por dólar investido.

- Um modelo de processo espiral e iterativo vai gerar o produto mais apropriado para as necessidades principais do cliente.

Como podemos então explicar a existência de tantos projetos ainda seguindo um processo cascata? A resposta: Pecados... Especialmente Orgulho, Ganância e Preguiça.

Muitos olham as suposições acima e falam: 'Essas suposições nunca ocorrem! Os humanos são pecadores e não podemos confiar na motivação do outro. Como os humanos são pecadores, não podemos nos comunicar perfeitamente'. Por essa razão que entram contratos escritos. Precisamos de contratos para a proteção de faltas dos outros e para evitar nossa própria tentação de cometer transgressões.

E então, chegamos no ponto de Brooks: 'Claramente, é a necessidade por contratos dentro de uma mesma organização ou entre organizações que força a descrição muito precoce de objetivos, requisitos e restrições detalhados'. Portanto, segundo Brooks (e concordo com ele!), a necessidade por contratos detalhados melhor explica a persistência de um modelo errado como o cascata para projetar e construir sistemas complexos.

Quer saber mais sobre soluções interessantes para contratos de desenvolvimento de sistemas (ou implantação de ERPs e outros sistemas prontos que necessitam de customização) ? Vide meu artigo e apresentação sobre contratos com o título Contratos e Scrum: The Good, The Bad and the Ugly e também a palestra em vídeo que ministrei sobre contratos no Falando em Agile .

Não vou me atrever a opinar por este meio entre estes senhores tão eloquentes. É praticamente utópico no modelo atual de negócios da maioria do mercado de TI no Brasil, mas eu disse praticamente, não totalmente. Como já dizia uma candidato a presidente: "Yes, We Can".

Fase 3106 do plano do Google de conquistar o mundo.

"No modo atual do Gmail, o usuário é responsável por verificar quais mensagens são importantes, quais devem ser respondidas e quais podem ser ignoradas. E o serviço de emails do Google já oferece características o bastante para isso: é possível marcar um item com uma estrela, criar filtros para certos remetentes ou assuntos e até criar uma resposta automática. Mas o Google pretende automatizar esse processo de separação.

Para isso, os engenheiros do Gmail criaram algo chamado Priority Inbox (ou caixa de entrada prioritária, em tradução livre). Com ela, o próprio Gmail separa o que é importante do que não é. Isso é feito através da mesma mecânica na qual o filtro de spam do Gmail é baseado.

Ele também detecta quais mensagens de quais remetentes que você mais responde e vai aperfeiçoando o filtro. Assim como o filtro de spam, o filtro de separação de importância vai ficando cada vez mais inteligente com o passar do tempo. Também é possível alterar o nível de importância de uma mensagem para mais alto ou mais baixo, caso esse algoritmo de seleção erre.

O novo recurso será ativado para os milhões de usuários do Gmail e Google Apps a partir da semana que vem. Para saber mais, assista ao vídeo informativo sobre a Priority Inbox nesse link (apenas em inglês).

Tenham medo! Mas morram felizes! Aproveitem. Eu já adicionei o recurso na minha caixa e comecei a usar. 

Space Savers ou como revolucionar o m² do seu apartamento

Brutalmente simples e incrivelmente genial. Para quem não tem, sabe que nunca vai ter ou que só acha que pode ter daqui a uns 50 anos: CHOREM. Eu já estou no terceiro lenço. :'(

Ah, não deixem de acessar o site dos caras. Tem muito coisa bacana lá (e de outro mundo também.)