No método ágil vimos que não é correto trabalhar com "escopo fechado". Minha dúvida é: Como determinar os tempos para entrega? Outra dúvida: Como geralmente o cliente não sabe direito o que quer, será que nas reuniões "face to face" com frequência não tendem a tornar o projeto inexequível?
hoje, com a Alura e o Google Gemini
Olá Carlos,
nas próximas aulas do curso você verá algumas técnicas de como alguns processos ágeis estimam as entregas. Mas já dando uma adiantada, no Scrum, por exemplo, nós estabelecemos um tempo para as iterações/ciclos que ficam se repetindo, conhecidos como Sprints. Segundo o Scrum Guide, uma Sprint deveria ter uma duração menor ou igual a 1 mês. Então vamos supor que, por exemplo, nós escolhemos que cada iteração durará 2 semanas no nosso time. Então a cada duas semanas, no começo da Sprint nós escolhemos um conjunto de tarefas que acreditamos que cabem dentro destas 2 semanas. Ou seja, o Scrum faz meio que uma inversão no cálculo do tempo de entrega, de forma que ao invés do cliente passar um conjunto de tarefas e os desenvolvedores estimam quanto tempo levarão para terminá-las, o time determina um tempo e coloca a quantidade de tarefas que eles acreditam que cabem dentro deste tempo. E no final da Sprint apresentamos para o cliente o que ficou pronto . Assim na próxima Sprint conseguimos novamente escolher um novo conjunto de tarefas que serão feitas nas próximas duas semanas e assim seguem os clicos.
E se o cliente não sabe o que quer, ai sim eu defendo que o time deveria se encontrar com ele cara a cara com uma muito mais frequência para o projeto desenrolar. Se a própria regra de negócio não está clara nem para cliente ou para o time, você espaçar a frequência com a qual eles se encontram só aumenta a incerteza no projeto e dá margem para o que está sendo desenvolvido não ser algo que resolve o problema do cliente.
Em geral, o cliente vai ter uma ideia do que ele quer resolver ou fazer, só que por não ter conhecimento técnico ele não sabe como isso pode ser feito. Por exemplo, ele não sabe como pode ser a interface, quais as informações precisaremos salvar , etc. Então é trabalho do time entender a ideia do cliente ou o problema pelo qual ele está passando, criar soluções em cima disso e entregá-las frequentemente para o seu cliente. Só assim você consegue mostrar pro seu cliente o que é possível ser feito e coletar um feedback dele sobre o que achou do trabalho e o que ele gostaria de mudar. E mostrando a evolução do projeto você pode até dar uma visão melhor para o cliente sobre o que pode ser feito com software e dar ideias para ele das próximas funcionalidades, telas, etc. Com o tempo, tanto o cliente quanto os desenvolvedores ganham mais maturidade e se entendem mais.
Se não a gente cai no velho problema do Waterfall que você encontra o cliente só no começo do projeto, em que ele te apresenta uma ideia, mas sem que ele saiba direito como ele quer o sistema. E depois de vários meses/anos desenvolvendo quando você entrega o projeto no final, ele não resolve o problema do cliente que fica insatisfeito.