[quote=scottys0]Minha opinião sincera ???
Se voce for o dono da empresa q ta contratando o servico .
Escolha RUP
Porque ???
No fim do desenvolvimento, voce vai ter MAIS documantação do teu programa do que codigo fonte pra analisar
// editado
Oque futuramente para manutenção pode ser bom que voce pode pesquisar por mão de obra mais barata :twisted:
[/quote]
é melhor pagar um monte de documentadores agora do que pagar um programador amanhã?
Olá,
Fora isso tudo é custo no projeto. Hoje em dia o cliente ja reclama do tempo gasto no desenvolvimento e sempre quer cortar horas, imagina entao para fazer a documentacao.
]['s
[quote=kvra][quote=scottys0]Minha opinião sincera ???
Se voce for o dono da empresa q ta contratando o servico .
Escolha RUP
Porque ???
No fim do desenvolvimento, voce vai ter MAIS documantação do teu programa do que codigo fonte pra analisar
// editado
Oque futuramente para manutenção pode ser bom que voce pode pesquisar por mão de obra mais barata :twisted:
[/quote]
é melhor pagar um monte de documentadores agora do que pagar um programador amanhã?[/quote]
se um programador booom hoje custa R$ 30,00 hora teu projeto requer uns 5 programadores pra ficar dentro do prazo. contrate + 3 documentadores a 10 ou 15 reais a hora …
…
Passado um ano … voce precisa implementar ou fazer alguma modificação.
o cara que voce contratou por 30 reais ano passado vai te cobrar 50
o documentador que agora com a experiencia pode te cobrar 30
um programador que voce contrate como consultor vendo que seu sistema esta bem desenvolvido e bem documentado e não vai dar tanta dor de cabeça … pode te cobrar bem menos do que o cara q desenvolveu na primeira instancia 
então … fica ai minha numerologia e “adivinhamento” …
[quote=scottys0]se um programador booom hoje custa R$ 30,00 hora teu projeto requer uns 5 programadores pra ficar dentro do prazo. contrate + 3 documentadores a 10 ou 15 reais a hora …
…
Passado um ano … voce precisa implementar ou fazer alguma modificação.
o cara que voce contratou por 30 reais ano passado vai te cobrar 50
o documentador que agora com a experiencia pode te cobrar 30
um programador que voce contrate como consultor vendo que seu sistema esta bem desenvolvido e bem documentado e não vai dar tanta dor de cabeça … pode te cobrar bem menos do que o cara q desenvolveu na primeira instancia
então … fica ai minha numerologia e “adivinhamento” …
[/quote]
Cara nao me leve a mal, mas tu ta falando isso por experiencia ja ou por suposicao?
]['s
Documentadores vs Implementadores?
Zahl nos mantenha ágeis,
nos mostre a verdade dos testes unitários,
nos ensine o UML as sketch
nos mostre que não importa quanto papel você tem, o improtante é como você construiu seu sistema
e nos livre do waterfall,
amem
É muito legal ter documentação sorbe tudo tudo do sistema, pena que não existe budget pra escrever um sistema do zero baseado nela. E nunca terá.
A questão não é não documentar a questão é mduar a ênfase que é dada em documentação. Um engenheiro constrói um modelo minucioso num papel porque ele não pode fazer testes unitários nem refatorar o prédio.
mais improtante que um quilo de Word é um código que seus programadores consigam manter e entender.
[quote=fabgp2001][quote=scottys0]se um programador booom hoje custa R$ 30,00 hora teu projeto requer uns 5 programadores pra ficar dentro do prazo. contrate + 3 documentadores a 10 ou 15 reais a hora …
…
Passado um ano … voce precisa implementar ou fazer alguma modificação.
o cara que voce contratou por 30 reais ano passado vai te cobrar 50
o documentador que agora com a experiencia pode te cobrar 30
um programador que voce contrate como consultor vendo que seu sistema esta bem desenvolvido e bem documentado e não vai dar tanta dor de cabeça … pode te cobrar bem menos do que o cara q desenvolveu na primeira instancia
então … fica ai minha numerologia e “adivinhamento” …
[/quote]
Cara nao me leve a mal, mas tu ta falando isso por experiencia ja ou por suposicao?
]['s[/quote]
Experiencia … sistema bem documentado … eu não fui recontratado :? depois que dei meu preço … hehehehehe
[quote=pcalcado]Documentadores vs Implementadores?
Zahl nos mantenha ágeis,
nos mostre a verdade dos testes unitários,
nos ensine o UML as sketch
nos mostre que não importa quanto papel você tem, o improtante é como você construiu seu sistema
e nos livre do waterfall,
amem
É muito legal ter documentação sorbe tudo tudo do sistema, pena que não existe budget pra escrever um sistema do zero baseado nela. E nunca terá.
A questão não é não documentar a questão é mduar a ênfase que é dada em documentação. Um engenheiro constrói um modelo minucioso num papel porque ele não pode fazer testes unitários nem refatorar o prédio.
mais improtante que um quilo de Word é um código que seus programadores consigam manter e entender.[/quote]
Eu sou totalmente a favor… só estou querendo colocar uma visão comercial na “coisa”
Sabe o que acontece comercialmente? A profissão muda, as pessoas não.
Olhe quantos posts aqui no GUJ d egente programando em java como faz há cinco anos com ASP, ou mais anos aidna com COBOL. Essa é a única maneira? É a melhor? Não. Eles sabem disso?
1 - Não sabem
2 - Não querem saber
3 - Têm raiva de quem sabe
Simples assim. Seu gerente “escreva quatro docuemntos antes de um teste” é como o amigo “eu fiz um javabean que abre uma conexão com o banco e retorna um resultset rpa minha jsp”.
Gerentes espertos conseguem enxergar muito mais que isso, mas aprece que (assim como para consultor) para ser gerente é pré-requisito ser tapado na maioria das empresas. Assim como o amiguinho JSP+JavaBean quer é ver algo funcionando sem se mexer, o gerente quer é documentação para poder mostrar como o projeto é bonitinho, comoe stá andando rápido… mesmo que ao finald e 70% do seu prazo você tenha um bando de .doc e nada mais do seu sistema.
Assim como eu trabalho com EJBs até para fazer log porque exigem, eut rabalho com quilos de documentação inútil porque exigem. Eu quero continuar fazendo isso? Não! Então eu divulgo quando posso técnicas que eu acredito. Se algum dia eu vier a gerenciar alguma coisa, que Zahl tenha piedade e me deixe ter a mesma cabeça que eu tenho quando procuro o melhor meio de fazer um programa, fugindo do padrão de mercado quando necessário e possível, quando for gerenciar pessoas.
Documentação boa e devidamente sincronizada com o projeto costuma acarretar em um custo enorme de desenvolvimento e sempre acaba sacrificando a qualidade do software. Refatorar código é facil, documentação é um inferno.
Não que toda e qualquer documentação seja inutil, mas aquela que diz respeito aos alvos moveis do produto é.
Olá
Assim como o Fábio e o louds, eu não conheço casos de sistemas bem documentados que não tenham sofrido horrores para chegar a este ponto. Sei de um caso em que uma empresa que foi contratada a peso de ouro para documentar um sistema já pronto feito por outra.
Entregar sistemas nos prazos de hoje e ainda documentar corretamente só com boas práticas no código e meia dúzia de diagramas de visão geral. O resto fica tudo defasado e esta foi uma das grandes sacadas do Kent Beck.
Última coisa: tem muito sistema por aí que nem com toneladas de documentos quem vem de fora consegue saber para o que serve. Já vivi isto na pele.
[]s
Luca
Uma coisa que ando muito curioso é como possivelmente contratar um fábrica pode ser um bom negócio. O custo para fazer a documentação para a criação do software costuma ser exorbitante.
Mas parece que enfiar dinheiro latrina a baixo não é problema para grandes empresas, eu, por exemplo, acabei de sair de uma reunião com 8 pessoas que durou 3 horas e ficou NADA decidido… Viva viva a metodologias waterfall.
Hmm, bom, deixa eu chutar uns argumentos meia-boca da pagina anterior antes que a gente de a conversa por encerrada:
XP eh bom em equipes pequenas da mesma forma que o desenvolvimento de software em geral eh feito melhor em equipes pequenas, ja que o custo da comunicacao aumenta exponencialmente (e quem disse isso foi Fred Brooks, nao eu. Reclamem com ele ;)). A menos que a sua equipe tenha menos de 3 pessoas envolvidas no dia-a-dia, diminuir o tamanho dela enquanto mantendo a base de conhecimento a torna mais agil.
XP nao diz nada sobre documentacao. O que eh dito eh que o cliente dita as prioridades. Se o cliente acha que documentacao deve ser feita ao longo do projeto, pq acredita que isso agrega valor ao sistema e nao se convence do contrario - ou, talvez ele tenha mesmo uma razao pra tal, que assim seja. No caso de praticamente todas as metodologias ageis, eh mais importante entregar ao cliente as coisas que valem mais: se uma nova feature vale mais do que um diagrama da arquitetura atual, entao implementa-se a feature primeiro. Quando a maior prioridade for a da documentacao, ok, faz-se somente o necessario pra dar a tarefa como concluida (assim como com todas as outras tarefas), e bola pra frente.
Bem mas quando se trata de papel o RUP não brinca em serviço …
Esses são os artefatos gerados para cada fase do desenvolvimento, lembrando que cada fase pode ter n iterações ;;; é muito documento …
Modelagem de Negócios
Avaliação da Organização-Alvo
Documento de Arquitetura de Negócios
Glossário de Negócios
Regras de Negócios
Visão do Negócio
Caso de Uso de Negócios
Realização de Casos de Uso de Negócios
Especificação Suplementar de Negócios
Requisitos
Glossário
Plano de Gerenciamento de Requisitos
Visão
Especificação Suplementar
Solicitações dos Principais Envolvidos
Caso de Uso
Especificação de Requisitos de Software
Análise e Design
Documento de Arquitetura de Software
Realização de Casos de Uso
Teste
Plano de Teste
Sumário de Avaliação de Testes
Gerenciamento
Caso de Negócio
Plano de Iteração
Avaliação de Iteração
Plano de Métricas
Plano de Aceitação do Produto
Plano de Resolução de Problemas
Plano de Garantia de Qualidade
Lista de Riscos
Plano de Gerenciamento de Riscos
Plano de Desenvolvimento de Software
Avaliação de Status
Gerenciamento de Configuração e Mudança
Plano de Gerenciamento de Configuração
Implantação
Lista de Materiais
Plano de Implantação
Notas de Release
Implementação
Plano de Integração do Build
Ambiente
Guia de Modelagem de Negócios
Guia de Design
Caso de Desenvolvimento
Avaliação da Organização de Desenvolvimento
Guia de Programação
Guia de Teste
Guia de Modelagem de Casos de Uso
Esse esqueminha ainda ajuda um pouco (ANTES QUE O CV ME TRUCIDE )NÂO TODO ELE … até mesmo no XP …
É, esta é uma grande nuvem de negra sobre XP. “Se seu projeto tiver equipes grandes, XP não vai funcionar”. Mas, defina para mim o que é uma equipe grande? 20 pessoas? 50 pessoas? 100 pessoas?
Não! O problema da XP não é a quantidade de pessoas numa equipe, mas a capacidade da informação se disseminar através desta equipe de maneira eficiente. Você pode ter uma equipe de 10 autistas e XP vai fazer seu projeto naufragar como o Titanic. Mas você pode ter uma equipe de 50 pessoas em que a informação flui de uma maneira muito fácil, então, talvez, XP dê certo. O que é preciso entender sobre XP é que ela é baseada em 4 valores e, o primeiro deles, é a comunicação (os demais são simplicidade, feedback e coragem). Logo, se sua equipe não se comunicar bem, se as informações não fluem adequadamente entre o time, não adianta, XP não vai dar certo.
Leitura obrigatória para quem quiser saber sobre XP (e evitar de ficar falando asneiras sobre “ouvi dizer que…”): Extreme Programming: Explained.
[quote=scottys0]Bem mas quando se trata de papel o RUP não brinca em serviço …
Esses são os artefatos gerados para cada fase do desenvolvimento, lembrando que cada fase pode ter n iterações ;;; é muito documento …
[/quote]
E no final do terceiro mês de projeto, você ainda não tem nenhuma linha de código ou módulo funcional do sistema…
[quote=Daniel Quirino Oliveira][quote=scottys0]Bem mas quando se trata de papel o RUP não brinca em serviço …
Esses são os artefatos gerados para cada fase do desenvolvimento, lembrando que cada fase pode ter n iterações ;;; é muito documento …
[/quote]
E no final do terceiro mês de projeto, você ainda não tem nenhuma linha de código ou módulo funcional do sistema…
:P[/quote]
concordo …
Mas fica aqui … minha opinião sobre o post …
A direita os Defensores de XP … a Esquerda os defensores de RUP
É impressão minha, ou parece que gente velha gosta mais de RUP e a molecada mais de XP ?
Alguém já viu uma aplicação feita em RUP dar certo, sem dar dor de cabeça pra ninguém?
Afinal, na maioria das empresas que se vê por ai eles tem a mesma idéia burocrática do RUP. Não criam todos os artefatos que o RUP exige, mas ainda sim atrasam pacas.
Não é por nada não, mas até concordo que RUP as vezes é necessário. Mas pra quê. Aparece uma mudança, e dale mudança em um mundo de documentos! Por isso dificilmente usam o RUP na prática!
Muitos dos desenvolvedores hoje em dia se limitaram a aprender apenas o que viram na faculdade. Está aí a facinação deles por RUP, e essa metodologia de desenvolvimento que vai de fase em fase gerando um mundo de documentação!
Mas, até aqui, eu não vi esta forma de desenvolvimento dar certo ou dor de cabeça. Mas eu também estou percebendo que há coordenadores de projeto, indivíduos e outros que estão começando a questionar a metodologia tradicional, dizendo que para o sucesso de uma aplicação a comunicação é uma peça fundamental. Alguns coordenadores tomam até a iniciativa de mudar a estrutura organizacional de sua equipe.
Ao invés de ficar aquela estrutura hierárquica, fica todo mundo num círculo, onde todos tem acesso a tudo e a todos. Para ser sincero, as esquipes que sabem trabalhar melhor em grupo, são as equipes que mais se destacam.
As coisas caminham para um lado onde valorizam trabalho em equipe e comunicação. E XP é uma metodologia que visa este lado. Eu aposto no XP! Vamos esperar para ver no que vai dar!
Abraços!
Thiago
Hummm… não. Eu diria que as pessoas mais flexíveis à mudanças preferem XP!
Segue link de um livro… eu recomendo:
http://www.temporeal.com.br/produtos.php?id=168198