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…
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!
[quote=josenaldo]…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.[/quote]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.
[quote=MarcioTavares][quote=josenaldo]…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.[/quote]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.
[/quote]
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?