Feedback de uma análise parcial

Olá, Miguel, tudo bem?

De fato, caso o cliente tente solucionar esta questão do calor colocando um ar condicionado, isso acarretará em prejuízos para ele, uma vez que o quarto já está feito e terão todos os inconvenientes que você bem descreveu. Acontece que, quando o time se dispõe a fazer um software, inicialmente o Product Owner passa por uma etapa de descobrimento do produto, na qual busca conhecer a fundo qual o melhor tipo de produto a ser criado para satisfazer o cliente. Durante essa etapa, tanto o PO como o cliente contribuem para a criação de um produto que gere valor para o cliente. Nela, são pensadas ideias e pode ser feito inclusive uma prototipação daquilo que está sendo idealizado pelo time. Após esse período de análise, o PO começa a criar as histórias de usuário, ou seja, adiciona ao backlog as funcionalidades necessárias para que aquele produto seja executado. Dessa maneira, quando o time de desenvolvimento começar a executar o projeto, já terá uma ideia da dimensão daquele sistema, tomando os devidos cuidados para atender àquilo que foi solicitado pelo PO, que, por já ter uma visão de negócios ampla, tentará colocar aquela história de usuário no backlog de modo que os prejuízos sejam os menores possíveis. É pensado na ideia de "mínimo produto viável (MVP)", ou seja, um produto em sua forma mais básica que gere valor para o cliente e que, ao longo do processo, possa sofrer incrementos de melhoria.

Também é importante pensar que, ao entregar um MVP, aquele produto será consumido por um usuário e, quando isso acontecer, ele começará a dar algum retorno financeiro para a pessoa que investiu na construção do produto. Muitas vezes, vale a pena lançar o produto em sua forma mais "simples" e fazer com que ele comece a gerar lucros para a empresa e, aos poucos, ir ajustando e aumentando suas funcionalidades. Essa é também uma diferença entre o exemplo dado na aula e o setor de tecnologia, uma vez que a construção de uma casa é feita de maneira linear e muito dificilmente são pensadas entregas parciais, uma vez que seu lucro máximo será obtido quando a casa for finalizada e, finalmente, vendida.

Espero ter ajudado, qualquer dúvida, sigo à disposição.

Abraços e bons estudos!

Compartilho dos mesmos questionamentos do Miguel, e acredito que o grande problema é a analogia de um software/aplicação com uma edificação, coisas que tem funcionamentos muito distintos. No vídeo "Porque surgiu o método agile", o próprio instrutor informou que inicialmente a engenharia de software se baseou no método waterfall porque funcionava para outras engenharias, incluindo a construção, mas que ai viram que esse método não era tão eficiente para software e foi por isso que o método agile surgiu. Por isso não faz sentido usar como exemplo a construção civil onde o método agile não é eficiente da mesma forma que em softwares.

O sentido do MVP faz muito sentido em softwares, mas não em construção civil, pois trabalha com coisas concretas, se um quarto for construído num local inadequado ou não se pensar como cada cômodo se encaixará no projeto final, é possível ter que derrubar tudo para reconstruir novamente. Em software é possível transferir blocos de código e adaptá-los com maior facilidade. Existe maior flexibilidade e isso reflete na possibilidade de trabalhar de forma mais ágil e flexível. Depois que sobe uma parede numa casa não tem como transferi-la, é necessário derrubá-la por completo e refazer do zero.

Talvez fizesse mais sentido se no exemplo já tivéssemos a estrutura final da casa toda pronta, e os fluxos/feedbacks fossem feitos através das prioridades do cliente: o cliente tem urgência, portanto prioriza fazer o acabamento/mobiliar/decorar quarto e banheiro, entregar, ter feedback, enquanto outras partes estão ainda apenas no esqueleto. Mesmo assim, não é o melhor exemplo para entender o conceito de agilidade em relação a softwares.