[MÚSICA] Olá, bem-vindo ao curso Princípios de Desenvolvimento Ágil de Software, eu sou Clóvis Fernandes E hoje iremos apresentar o que é a Visão da Aplicação, a visão do produto, no contexto nosso do Scrum&XP s os user stories. Bom, nós havíamos definido que a Visão da Aplicação tem dois lados: a Visão ou Valor de negócios e que vão realmente direcionar as necessidades dos clientes ou dos tipos de usuários que a gente vai usar, tá certo? O que vai nos interessar é isso aqui, né, tá certo? Essa parte aqui da necessidade dos clientes é que vai nos interessar, tá certo? Nós queremos é ver isso, embora por causa do PO, o product owner nós teremos sempre representante que vai estar sempre olhando o que nós estamos como equipe desenvolvendo como Visão ou Valor de Negócio, agora quando eu estou escrevendo a Visão da Aplicação o que mais nos interessa é isso aqui: as necessidades dos clientes, de qualquer forma vai ser a equipe como todo que vai trabalhar nisso, né? Inicialmente, nós identificamos os tipos de usuários ou User Roles, tá certo? Nós vamos identificar o "Who" e nós vamos identificar as necessidades de cada dos tipos de usuários que nós identificarmos, então é isso que nós vamos fazer, quer dizer, basicamente iremos identificar esses papéis, as necessidades e com base nessas necessidades nós vamos então desenvolver os requisitos, a segunda parte então é essa: é identificar os atributos do produto O que são os atributos dos produtos? São os Requisitos Funcionais e os Requisitos Não Funcionais, ou seja, então além da identificação dos tipos de usuários e das necessidades dos tipos de usuários, nós vamos delinear melhor essas necessidades dos usuários de uma forma pouquinho mais interessante que é na forma de requisitos Funcionais e Não Funcionais, exemplos de Requisitos Funcionais: por exemplo, no aplicativo que você tem do WhatsApp, fazer uma chamada telefônica, isso é requisito funcional, mandar uma mensagem, post para uma outra pessoa também é requisito funcional, enviar e-mail no seu software de e-mail, isso é requisito funcional, tá certo? Ou seja, o software foi feito para atender essas necessidades que são específicas dos tipos de usuários envolvidos. Já os Requisitos Não Funcionais, eles vão ter impacto obviamente nos Requisitos Funcionais mas eles olham a coisa de uma maneira mais global e eles são bastante influenciados pelo Valor de Negócio, pela Visão de Negócio, eu tenho aqui requisito de performance, que é o desempenho, tá certo? Porque se é website, por exemplo, eu não quero que o serviço que o site está me oferecendo demore muito, tá certo? Quer dizer, além da demora que eventualmente tem pelo tráfego na internet normal o site vai demorar muito? Não, então não deve demorar muito. Questão da robustez: ou seja, não é porque ocorre algum pequeno problema no meu sistema que tudo tem que parar, tá certo? Pode parar exatamente uma determinada coisa que deu o problema, mas não o resto e isso significa ter robustez e é o que eu quero, se eu estou fazendo software pela internet ou aplicativo de tablet ou de celular, eu quero que ele tenha bastante robustez. E a outra coisa que eu quero também, é a usabilidade, então ele tem que ser fácil de usar, eu não posso ter muita dificuldade, eu não posso cometer erros porque a disposição da interface está me causando dificuldade de entendimento. Obviamente, nós temos outros tipos de Requisitos Não Funcionais, como, por exemplo, seria o da disponibilidade, o sistema tem que estar funcionando 24 horas, todo dia, 7 dias por semana, por exemplo, é outro tipo, tá certo? E existem vários outros mais que não iremos tratar aqui. Na Visão, quais são os cuidados que nós devemos tomar ao desenvolver a Visão da Aplicação? Grande problema é o que a gente chama de subespecificação, aqui "subespecificação" não está escrito errado, você escreve sem hífen e fala como se tivesse hífen: "subespecificação", é você especificar muito rapidamente, com poucos elementos e o que vai acontecer? O "desenhinho" aqui tá deixando isso bem claro aqui: a sua estrada à frente não está clara, não está muito clara, ou seja, é problema de subespecificação, você não tá conseguindo ver o suficiente, pra poder prosseguir com segurança, com segurança de que você vai desenvolver bom produto dentro do tempo no custo determinado. O outro é a superespecificação, o mesmo problema: a gente lê "superespecificação" como se tivesse hífen, mas não tem hífen, tá certo? Não tem hífen aqui. O que que acontece com a superespecificação? Eu não quero cair naquele problema do BDUF- Big Design Up Front, ou seja, eu não quero perder muito tempo e fazer uma especificação detalhada e aquilo depois não é o que o cliente final realmente quer, então eu perdi muito tempo, muito dinheiro e não fiz o que devia, tá certo? O que realmente nós queremos é a especificação suficiente, o que eu chamo, atenção, é só eu que chamo isso, tá certo? Vocês não vão encontrar esse tipo de coisa outro lugar, é o EDUF, a especificação suficiente, então a minha Visão da Aplicação deve ter apenas o suficiente para que eu consiga ver a estrada à frente pouco. E não parar porque não consegui vislumbrar coisas óbvias que deveria vislumbrar e problemas e não consegui identificar, então a especificação suficiente é o que é o importante nessa Visão da Aplicação, principalmente porque nós vamos fazer isso sempre dia, não é muito comum fazer dia, mas uma semana é o bastante comum, tá certo? E duas semanas quando o custo da aplicação é muito grande, tá certo? Com isso, nós mostramos pra você o que é a Visão da Aplicação no contexto nosso do Scrum&XP. Obrigado! [MÚSICA]