Processos de software...é uma longa história!

Era uma vez...brincadeira!

Antes que você fique decepcionado vou adiantar, esse post não é um tutorial sobre quais os processos de software existentes, qual o melhor deles, diferenças, ou o que fazer com eles. Na verdade é um comentário em cima de outro post. Espero que a reflexão e a discussão sejam produtivas e construtivas para todos nós. Aproveitem!

Para entender melhor sobre o que eu estou falando, leiam o post do link abaixo, muito legal e vale a pena:

http://www.linhadecodigo.com.br/artigos.asp?id_ac=1262&pag=1

Nesse caso de sucesso, considerando uma equipe fixa, praticamente nivelada em conhecimento, e todos acompanhando o projeto do início ao fim, como ele menciona em alguns trechos (claro que podem ter ocorrido alguns problemas, mas vamos considerar o cenário dessa forma).

Assim é muito bom empregar uma metodologia mais alternativa, como descrito no caso, onde o grupo tem rotatividade, todos conhecem todo o código do projeto, e por isso o "pirata" pode ser uma pessoa dedicada a problemas críticos do projeto, além de dar uma dinâmica, flexibilidade e motivação para o grupo confrontando-se sempre com novos desafios e trabalhando sempre em equipe (um fator importante, se tratando de um ambiente de programação, onde o ego é algo difícil de lidar, dependendo das pessoas é claro, sempre depende delas...hehehehehe).

Mas ainda tem outro quesito importante, a eficiência do gerente. Não é fácil definir tarefas e o tempo que elas irão levar, pois sempre tem imprevistos. Para isso é necessário políticas.

"...até mesmo em um ambiente caótico (ou aparentemente) existe ordem. (Teoria do Caos)".

Essa abordagem descrita é a metodologia XP - eXtreme Programming (ou pelo menos me lembra muito) e ele defende muito bem no post, mas na questão de documentação, XP peca em muitos casos, claro que depende da abordagem, XP é bem flexível (quem disse que os cartõezinhos na janela não servem de documentação para o projeto), mas o pecar, ao qual me refiro, é na documentação do código, que geralmente não existe.

Discordo quando ele diz que não tem necessidade de documentação, apesar de ser muito chato documentar, é de suma importância e auxilia muito os programadores novos no grupo, principalmente em equipes que não são fixas e mudam muito durante o projeto.

A documentação ajuda no entendimento do projeto, que na metodologia XP fica toda na cabeça dos integrantes da equipe (caso um avião com todos eles caia, o projeto cai junto!).

XP é muito bom, e pessoalmente prefiro trabalhar dessa forma, acho muito produtivo, e além de algumas vantagens que eu citei, existem outras muito legais: como o desenvolvimento em pares, maior concentração na codificação, maior poder para solucionar o problema (duas cabeças pensam melhor que uma), diminui o número de erros, entre outras vantagens, porém é necessário um mínimo de burocracia, controle e documentação....ajuda na hora dos imprevistos. ;)

Uma solução legal seria uma abordagem mista, quem sabe?

E concordo que nem sempre o senso comum é o melhor!

Inovar pode ser uma boa alternativa, mas tenha sempre muito cuidado!

Muito legal a historinha, fiquei imaginando o cara com o chapéu de pirata! Deve ser um castigo pra quem é sorteado: - "E o sorteado da semana para resolver os pipinos é...hehehehehehehe :)

É isso...

Não esqueça de deixar seu comentário e verificar os anúncios.

Gostaria de agradecer ao Jack que me ajudou com as figuras e ao Caike pela dica de leitura do post. Valeu!

Abraço!