Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Impactos no design devido a falta de visão do todo

Caros amigos, eu semprei achei os métodos ágeis uma filosofia bastante desafiadora. Sempre trabralhei com outros métodos tradicionais e sempre tive um bom percentual de sucesso e, depois, descobri que já utilizava alguns preceitos ágeis e não tinha percebido. A minha dúvida se refere à arquitetura da solução. Como a ideia é não fazer um levantamento muito abrangente da solução, não existe um risco alto da equipe definir uma solução arquitetural e depois, talvez no meio do SPRINT, decobrir que fez uma escolha errada quando precisou detalhar mais um requisito? Uma alusão seria: estava construindo um prédio de 3 andares e, quando fui detalhar um requisito do meu SPRINT a equipe descobriu que vai precisar de 4 ou 5 andares. O que fazer se não posso renegociar com o cliente já que o erro foi da equipe e este detalhe não apareceu como impedimento antes e a minha "construção" não tem fundação para mais 2 andares?

4 respostas

Boa noite!

O Agile não é uma bíblia para ser seguida a risca. Se for um projeto de construção civil, algo relacionado a área da saúde ou algo que tenha um risco de dar errado por planejamento insuficiente tem que detalhar os requisitos ao máximo devido.

Com software se o cliente não gostou a gente reprograma. Agora não dá para levantar mais andares do que o previsto em um prédio porque não tem fundação suficiente para aguentar a estrutura.

Além de toda estrutura legal de um projeto de construção civil que diz que o projeto tem que ser bem definido antes da construção e o mesmo vale para outras áreas críticas.

Cada caso tem que ser tratado diferentemente, de acordo com a legislação vigente e sempre usar o bom senso.

O que fazer se não pode renegociar com o cliente? Sobra pedir desculpas e tentar reparar do bolso ou pagar uma multa dependendo da situação.

Espero ter respondido a sua pergunta!!!

Entendi o seu ponto, mas gostaria de ir além. Eu imagino que seria importante ter uma equipe madura para tentar reduzir este tipo de risco. Sempre aparecem métodos que muitos utilizam como a solução de todos os problemas e eu sei que isso é um exagero. Muito se falou mal do RUP e até mesmo do PMI e eu vejo, na minha experiência, que muitos utilizaram estas abordagens de forma errada. Porém, nem tudo estava errado. Vejo o mesmo acontecer com as abordagens ágeis. Em resumo, como você mesmo colocou, deve-se ter bom senso. Eu acredito que é importante uma equipe madura que tenha alguma experiência para evitar erros grotescos que seria inviável (em termos de custo) uma refatoração. Um modelo de dados inapropriado pode gerar um grande retrabalho. Embora todos os requisitos não tenham que ser inicialmente muito bem definidos, eu acredito que um básico que consiga dar uma ideia do design tecnológico deva ser levantado. Novamente, estamos no meio do bom senso, que sempre será perigoso.

solução!

Acredito que dentre as formas atuais de desenvolvimento, não temos uma bala de prata pois em alguns cenários podemos mesclar a ideia do RUP para partes críticas (requisitos do Core da aplicação) e para novas necessidades a abordagem ágil se mostra mais adequada. No seu exemplo, diria que para saber se um prédio devia ter 3 ou 5 andares deve usar algo mais maduro e tradicional na fase inicial do projeto. e Ao longo do tempo podemos mudar os andares aí sim com características ágeis.

Fernanda, eu concordo com você. O que eu quis alertar aqui é que, como não existe a "bala de prata" a experiência ainda fala mais alto. Se você pegar apenas uma equipe com experiência em SCRUM, dificilmente perceberá isso. Nem o SCRUM Master tradicional perceberá já que a função dele é manter o processo funcionando e ser o facilitador. É muito importante ter na equipe um "arquiteto experiente". Claro, que uma equipe madura ajuda muito. Já vi projetos entregues utilizando metodologias ágeis com grandes problemas de manutenção ou performance. Como o cliente final não entende destes aspectos, não consegue interceder. Obviamente, em alguns testes, também não se consegue identificar tais gargalos. Só depois que o projeto está em produção com muitos acessos e com uma boa base de informações, os problemas começam a aparecer.