Requisitos x Análise e Projeto x Tempo

JavaChild Membro desde: 01/06/2006 12:38:40 Mensagens: 121 Offline

Olá pessoal,

Na empresa que trabalho, o que eu acredito que não seja diferente para 90% dos participantes deste fórum, , sofremos bastante com a variável Tempo.

O projeto já começa atrasado, os especificadores demoram bastante para entender o projeto e consequentemente entregam os UC's fora do prazo estipulado pelo gerente do projeto (cronograma).

Quando chega a parte de implementação, 4 especificadores tem 6meses para entregarem um projeto com 800PF.

Da fase de requisitos, o gerente já pede para o codificador implementar o UC para ontem. E com isso, não é executada a disciplina de análise e projeto. Parte da análise (MER) é feito quando o UC já está validado pelo cliente, e o codificador pega para codificar.

O problema, como já era de se esperar, é que o codificador não entende NADA do negócio, e tem que codificar um UC com os seguintes artefatos: UC, Regras de negócio e MER.

O que vocês acham que poderia ser feito para que o GAP entre os codificadores e os especificadores fosse diminuído?

Eu pensei em fazer com que antes de do codificador pegar o UC para implementar, ele poderia fazer o Projeto do UC, e depois utilizando MDA, minizar a "perda de tempo" na geração de documentação. Em contra-partida, ele já estaria entendendo perfeitamente o UC na hora de implementar.

Olá

Meu pitaco de solução:

Abandonar TODAS as práticas que citou, comprar livros e ler tudo sobre SCRUM, desenvolvimento ágil, XP, lean e fracassos de projetos desenvolvidos em cascata.

Se isto não der certo, pule fora do barco pois seguindo tal como está será mais um projeto naufragado e a culpa ainda recairá no lado mais fraco.

[]s
Luca

+1 pra muda tudo ou pula fora.

+1 pros posts anteriores, mas...

wood wrote:Eu pensei em fazer com que antes de do codificador pegar o UC para implementar, ele poderia fazer o Projeto do UC, e depois utilizando MDA, minizar a "perda de tempo" na geração de documentação. Em contra-partida, ele já estaria entendendo perfeitamente o UC na hora de implementar.

MDA nao vai te ajudar aqui. Isso nao eh um problema onde jogar mais ferramentas na brincadeira vai adiantar alguma coisa. O problema eh de comunicacao, e pelo jeito vc tem uma barreira enorme entre gerente de projeto, analistas e desenvolvedores (codificador!? que eh isso? um digitador de luxo?) onde ninguem conversa direito a nao ser atraves de diagramas, e todo mundo tenta seguir um plano mesmo que ele seja impossivel ou nao entregue o valor de negocio desejado pelo cliente/sponsor no final.

Isso é um problema quando acontece do cliente e fornecedor querendo a burucracia. E quando o cliente força vocês a usar essa documentação toda, nao tem jeito. É aceitar ou pular fora do contrato... Eu sei porque trabalho com clientes assim e tento mudar a mentalidade da empresa para que as pessoas ao menos melhorem as praticas de programação.

wood, no seu caso acho que a melhor coisa é utilizar uma ferramenta informal para comunicação entre os analistas e os programadores. Tente criar um wiki ou um forum na empresa onde essas pessoas podem trocar idéias sobre o projeto e, consequentemente, melhorar a documentação criada pelo analista.

É claro que a melhor é a conversa olho no olho, mas com isso fica difícil rastrear alguns itens de escopo que não foram identificados e o analista não percebeu que deveria documentar nos UCs a serem entregues ao cliente.

Vamos lá.

Esse Projeto deveria beneficiar um cliente. Logo a sua equipe deveria trabalhar para atender da melhor forma possivel o cliente, e não criar barreiras pra dizer "a culpa foi do codificador que não implementou o meu precioso UML da forma como deveria ser".

A mudança que pode ser feita com Scrum é radical SE vc pode tomar essa decisão. Geralmente o projeto foi acordado com diversas pessoas que seria daquele jeito, que tem data pra acabar e se vc chegar com esse papo vão achar que vc é um Hippie ou algo assim. Vc tem que entender o motivo de algumas mudanças.

Vc pode começando a ler por aqui:
http://blog.fragmental.com.br/2007/07/24/contratando-agilistas-retardatarios/
http://blog.fragmental.com.br/2007/08/15/introduzindo-agilidade-num-ambiente/

Boa sorte.

Uma das características do processo cascata são os 30 analistas que trabalham antes da codificação geralmente não trabalham... enrolam... ficam fingindo que estão fazendo alguma coisa, dizem que estão escrevendo casos de uso. Analisando... um falácia sem fim e sem propósito.

Eles ENROLAM MESMO. Acredite. ENROLAM tanto que quando implantamos um processo iterativo eles dizem que não se adaptam a isso e mudam de emprego. Já ví isso acontecer mais de uma vez.

Outra coisa comum é a empresa "desenvolver de qq jeito", afinal tem q atingir o prazo e pegar a grana.

Quando se vê a qualidade do sistema ai rola uns acordos de bastidores, uns contratos de suporte, uma noitada numa casa de deboche... com alguns desenvolvedores trabalhando como loucos num horario apertado, dentro do cliente, pra corrigir a coisa toda.

Thread.start() Membro desde: 03/10/2007 18:41:36 Mensagens: 26 Offline

a maioria das fábricas de software trabalham dessa forma mesmo...
implantam um RUP waterfall, incham as equipes com "analistas"
e "arquitetos" gerando um monte de papelada inútil que nem eles
próprios sabem para que serve...
dizem que programador não deve conversar com o analista...
compram uma mesa maior pro cara que vai passar o dia operando o PMO (áfff...)
e espalham aos 4 ventos que seus processos bem definidos garantem a qualidade
do serviço...

e o resultado disso tudo aí já está bem documentado pelo Standish Group...

Mr. wood,

Se vc for "apenas" o desenvolvedor e está em uma posição em que não decide nada, ou seja, não é gerente, nem diretor, nem amigo do dono, e principalmente dono da empresa mas gosta de ver as coisas acontecerem de uma melhor forma (na sua opinião) aconcelho vc a procurar um outro lugar pra trabalhar onde existam pessoas com a mesma ideologia que a sua.

Você citou varios indicadores de problemas enormes, ex. comunicação, processo que não favorece a qualidade e nem a agilidade, comprometimento e etc...
Na maioria das vezes apenas vontade não muda certas coisas, é necessario também um pouco de poder (infelizmente).

Geralmente nesse contexto os líderes costumama acusar os desenvolvedores de falta de comprometimento insinuando que deveriam atravessar noites e finais de semana trabalhando para compensar os erros gigantes que ocorreram na interface cliente (compra o projeto) / fornecedor (desenvolve o projeto).

Porisso gostaria de adicionar que, atravessar noites e finais de semana trabalhando não é sinal de comprometimento e sim de INCOMPETENCIA que pode estar presente em todos os níveis, o desenvolvedor não está isento disto neste momento.

[]'s

This message was edited 1 time. Last update was at 28/07/2008 14:12:45

rodrigoy wrote:Uma das características do processo cascata são os 30 analistas que trabalham antes da codificação geralmente não trabalham... enrolam... ficam fingindo que estão fazendo alguma coisa, dizem que estão escrevendo casos de uso. Analisando... um falácia sem fim e sem propósito.

Eles ENROLAM MESMO. Acredite. ENROLAM tanto que quando implantamos um processo iterativo eles dizem que não se adaptam a isso e mudam de emprego. Já ví isso acontecer mais de uma vez.

Infelizmente essas pessoas fazem isso e mudam de emprego porque o defict de profissionais da nossa área permite esse tipo de coisa. Eu mesmo já trabalhei com um montão de gente assim.

This message was edited 1 time. Last update was at 28/07/2008 16:12:41

A formação das pessoas deve se verificada. Só processo ou práticas, mesmo ágeis, não resolve se sua empresa contrata mão-de-obra barata e usa processos para compensar a falta de formação da equipe. A burocracia gerada vai inviabilizar qualquer prazo razoável.

É provável que seja um projeto virtualmente impossível.

Luca wrote:Olá

Meu pitaco de solução:

Abandonar TODAS as práticas que citou, comprar livros e ler tudo sobre SCRUM, desenvolvimento ágil, XP, lean e fracassos de projetos desenvolvidos em cascata.

Se isto não der certo, pule fora do barco pois seguindo tal como está será mais um projeto naufragado e a culpa ainda recairá no lado mais fraco.

[]s
Luca

Infelizmente na maioria das vezes é impossível mudar a ambiente.

Rubem Azenha wrote:
Infelizmente na maioria das vezes é impossível mudar a ambiente.

E felizmente emprego na nossa área é o que não falta hoje em dia.

E se o cara for um pouquinho competente dá até pra escolher exatamente o ambiente onde ele quer trabalhar.

Rubem Azenha wrote:

Luca wrote:Olá

Meu pitaco de solução:

Abandonar TODAS as práticas que citou, comprar livros e ler tudo sobre SCRUM, desenvolvimento ágil, XP, lean e fracassos de projetos desenvolvidos em cascata.

Se isto não der certo, pule fora do barco pois seguindo tal como está será mais um projeto naufragado e a culpa ainda recairá no lado mais fraco.

[]s
Luca

Infelizmente na maioria das vezes é impossível mudar a ambiente.

E em outras tantas vezes, não é lucrativo mudar esse ambiente.

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