Qual a sua sequencia para desenvolver uma funcionalidade?

Você começa pela documentação? Pela análise? Faz diagramas? Parte direto pro código? Testa antes ou depois?

Eu propus uma sequência, seguindo o que o Thiago Arrais propôs também.

Gostaria de saber como vocês estão acostumados a fazer...

Bom, para começar, muito bom o comentário, artigo, seja lá o que for que o thiago escreveu, muito claro e com um ótimo senso de humor.

Na minha experiência, já fiz dos dois jeitos, hoje não sou adepto de um ou outro e por isso não arredo o pé para sempre fazer do mesmo jeito. Sigo os ensinamentos orientais que dizem que você tem que ser igual a água (uma parte dele apenas, pois tem mais do que isso), ou seja, tento ser flexivel, me adaptar a cada situação e escolher a melhor forma de trabalhar. Portanto hoje, digo que uso os dois modos, o "corporatives" e o TDD

vai da situação, do tempo, do que o cliente quer e bla bla bla

Eu bem que queria passar mais por TDD, mas como a empresa onde trabalho tem que entregar aos clientes uma série de documentos, temos que trabalhar à la RUP. rs

1 - Identifica necessidade
2 - Detalha requisitos
3 - Analisa Problema
4 - Projeta Solução
5 - Implementa
6 - Testa

E volta aos passos 3, 4 ou 5, a depender da necessidade observada no passo 6.

Até que é legal. E considerando que o cliente sempre pede alterações depois de algum tempo, (as vezes 6, 7 meses sem ninguém mexer no sistema) e que a equipe tem uma rotação razoável, é bom ter a documentação bem estruturada.

Aqui, nós prezamos pelo minimalismo. Detalhamos bem, mas apenas o que for necessário!

josenaldo wrote:...mas como a empresa onde trabalho tem que entregar aos clientes uma série de documentos, temos que trabalhar à la RUP. rs

1 - Identifica necessidade
2 - Detalha requisitos
3 - Analisa Problema
4 - Projeta Solução
5 - Implementa
6 - Testa

E volta aos passos 3, 4 ou 5, a depender da necessidade observada no passo 6.

i++

Minha empresa também trabalha seguindo um modelo derivado do RUP. O problema desse modelo, como já foi discutido aqui milhares de vezes, é a burocracia necessária para alterar alguma coisa. Fica muito engessado. Aí, quando o prazo da entrega aperta, esqueçam a documentação e modelagem e façam a implementação direto. Resultado? Milhões de documentos desafados e a empresa inteira mobilizada para sincronizar as informações. Uma gracinha.

MarcioTavares wrote:

josenaldo wrote:...mas como a empresa onde trabalho tem que entregar aos clientes uma série de documentos, temos que trabalhar à la RUP. rs

1 - Identifica necessidade
2 - Detalha requisitos
3 - Analisa Problema
4 - Projeta Solução
5 - Implementa
6 - Testa

E volta aos passos 3, 4 ou 5, a depender da necessidade observada no passo 6.

i++

Minha empresa também trabalha seguindo um modelo derivado do RUP. O problema desse modelo, como já foi discutido aqui milhares de vezes, é a burocracia necessária para alterar alguma coisa. Fica muito engessado. Aí, quando o prazo da entrega aperta, esqueçam a documentação e modelagem e façam a implementação direto. Resultado? Milhões de documentos desafados e a empresa inteira mobilizada para sincronizar as informações. Uma gracinha.

Nem fale. Aqui até que a gente consegue não atrasar, visto que o gerente tem experiência e mão forte na hora de dar os prazos. O cara não promete o que a equipe não pode fazer.

Mas que o custo da manutenção de documentação atualizada é alto, é, mas se paga. Principalmente quando você mexe no sistema depois de 6 meses. Mas atenção, pra isso valer a pena, A DOCUMENTAÇÃO TEM QUE ESTAR ATUALIZADA!

Além do mais, o RUP não é tão burocrático. É que algumas empresas teimam em entupir o projeto com todo tipo de documento, pra ficar com um projeto "completo". Ou pra justificar o que cobra!

Mas que precisa agilizar mais, precisa!

Será que alguém já encontrou um modelo híbrido de UP com métodos ágeis? Pelo menos algo que valha a pena?

Notícias, artigos e o maior fórum brasileiro sobre Java