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…
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.
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
[quote=rodrigoy]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.[/quote]
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.
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.
[quote=Luca]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[/quote]
Infelizmente na maioria das vezes é impossível mudar a ambiente.
[quote=Rubem Azenha]
Infelizmente na maioria das vezes é impossível mudar a ambiente.[/quote]
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.
[quote=Rubem Azenha][quote=Luca]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[/quote]
Infelizmente na maioria das vezes é impossível mudar a ambiente.[/quote]
E em outras tantas vezes, não é lucrativo mudar esse ambiente.
Olá
Observação perfeita.
Me lembrei do papo de sábado no TDC onde se não me engano, o Juan Bernabó me disse que as empresas que usam fábricas de software tem fortes interesses no desenvolvimento deste jeito altamente burocratizado e com mais chances de dar errado porque cobram por homens/hora.
[]s
Luca