1. Estórias
1.1. COMO DEVE SER UMA HISTÓRIA?
1.1.1. Independente
1.1.1.1. O ideal é que possamos trabalhar em uma história independente das demais. Assim, podemos trabalhar nela a qualquer momento, sem depender de outras. Nem sempre isso é possível, mas deve ser buscado. Ou seja, procuramos minimizar as dependências.
1.1.2. Negociável
1.1.2.1. Uma história deve poder ser trabalhada em conjunto, pelo cliente e pela equipe. Assim, o conceito deve ser bem definido e os detalhes são resolvidos posteriormente em conjunto. A essência deve ser capturada, deixando os detalhes como parte da implementação
1.1.3. Valiosa
1.1.3.1. Uma história tem que prover valor para o cliente. Ao dividir histórias devemos nos preocupar em manter a visão total de sua implementação, de forma que o cliente perceba o seu valor e suporte o desenvolvimento da história. Temos histórias chamadas “técnicas” aonde o cliente tem muitas vezes dificuldade para enxergar valor, mas falaremos sobre isso em outra oportunidade. De uma forma geral, devemos evitá-las, procurando inseri-las como partes de outras histórias onde o cliente perceba valor. Nem sempre isso é possível.
1.1.4. Estimável
1.1.4.1. Para que o time possa programar o seu trabalho e o cliente possa priorizar a realização das histórias, elas precisam ser estimadas. Quanto maior a história mais impreciso e difícil é estimar.
1.1.5. Pequena
1.1.5.1. Histórias devem ser pequenas. Devem poder ser feitas com poucos homem-hora, alguns dias de trabalho somente. Adicionalmente, pequenas são estimadas mais facilmente e com maior precisão.
1.1.6. Testáveis
1.1.6.1. Tudo o que é feito pelo time deve poder ser verificado e validado. Um bom exercício é definir o teste antes de trabalhar na história. Se há dificuldade em definir testes, a história pode não ter sido bem entendida ou estar no nível de abstração incorreto. É fundamental para todos da equipe Scrum entender que o trabalho é realizado por histórias e, portanto, a qualidade das mesmas definirá a eficácia e a eficiência da equipe. Ainda, o trabalho na definição das histórias, as necessárias discussões e levantamentos, e outras atividades correlatas, servem para a aquisição de conhecimento pelo time, e até pelo próprio cliente. Voltando ao nosso simples exemplo inicial, poderíamos substituir nosso épico O Diretor quer controlar o estoque para otimizar o uso dos recursos financeiros por: Diretor deseja registrar a entrada de mercadorias para permitir as vendas e limitar o uso do almoxarifado Vendedor precisa registrar a saída de mercadorias para permitir a reposição do estoque Controlador deseja verificar e ajustar a quantidade de mercadoria existente para efetuar o balanço de material
1.2. User Stories
1.2.1. Uma História pode ser escrita da seguinte forma (Cohn, 2004): Um Ator quer Algo por um Motivo
1.2.1.1. ATOR
1.2.1.1.1. Ator - O Ator é a representação de um papel de usuário, ou seja, de um tipo de usuário, como Secretária, Atleta, Cliente, Associado, Diretor, etc.
1.2.1.2. AÇÃO
1.2.1.2.1. Quer algo - O Algo é a meta do usuário ao utilizar o produto sendo criado. Deixa claro o que o usuário espera ao utilizar o produto. Algo como “emitir um relatório de vendas” ou “verificar os batimentos cardíacos”.
1.2.1.3. FUNCIOLALIDADE
1.2.1.3.1. Por algum motivo - O Motivo funciona como uma justificativa e ajuda o Time Scrum a entender a História e a necessidade do Ator. “Para premiar o melhor vendedor” e “para ajustar a intensidade do exercício” são exemplos de motivos.
2. AOO
2.1. Definição Básica
2.1.1. [Todos os métodos orientados a objetos são] baseados nos conceitos que aprendemos no jardim de infância: objetos e atributos, totalidades e partes, classes e membros.
2.2. Modelagem
2.2.1. Classes
2.2.1.1. Conjunto de objetos que o sistema vai manipular
2.2.1.2. As classes se manifestam conforme as manairas a seguir
2.2.1.2.1. ENTIDADES EXTERNAS - (por exemplo, outros sistemas, dispositivos, pessoas) que produzem ou consomem informações a ser usadas por um sistema baseado em computadores.
2.2.1.2.2. COISAS - (por exemplo, relatórios, exibições, letras, sinais) que fazem parte do domínio de informações para o problema.
2.2.1.2.3. OCORRÊNCIAS OU EVENTOS - (por exemplo, uma transferência de propriedades ou a finalização de uma série de movimentos de robô) que ocorrem no contexto da operação do sistema.
2.2.1.2.4. PAPÉIS - (por exemplo, gerente, engenheiro, vendedor) desempenhados pelas pessoas que interagem com o sistema.
2.2.1.2.5. UNIDADES ORGANIZACIONAIS - (por exemplo, divisão, grupo, equipe) relevantes para uma aplicação.
2.2.1.2.6. LOCAIS - (por exemplo, chão de fábrica ou área de carga) que estabelecem o contexto do problema e a função global do sistema.
2.2.1.2.7. ESTRUTURAS - (por exemplo, sensores, veículos de quatro rodas ou computadores) que definem uma classe de objetos ou classes de objetos relacionadas.
2.2.1.3. Características de seleção das Classes de ANÁLISE
2.2.1.3.1. INFORMAÇÕE RETIDAS - A classe em potencial será útil durante a análise apenas se as informações sobre ela tiverem de ser relembradas para que o sistema possa funcionar.
2.2.1.3.2. SERVIÇOS NECESSÁRIOS. A classe em potencial deve ter um conjunto de operações identificáveis capazes de modificar, de alguma forma, o valor de seus atributos.
2.2.1.3.3. ATRIBUTOS MÚLTIPLOS - Durante a análise de requisitos, o foco deve ser nas informações “importantes”; uma classe com um único atributo poderia, na verdade, ser útil durante o projeto; porém, provavelmente seria mais bem representada na forma de atributo de outra classe durante a atividade de análise.
2.2.1.3.4. ATRIBUTOS COMUNS - Um conjunto de atributos pode ser definido para a classe em potencial e esses atributos se aplicam a todas as instâncias da classe.
2.2.1.3.5. OPERAÇÕES COMUNS - Um conjunto de operações pode ser definido para a classe em potencial e tais operações se aplicam a todas as instâncias da classe.
2.2.1.3.6. REQUISITOS ESSENCIAIS - Entidades externas que aparecem no espaço do problema e produzem ou consomem informações essenciais à operação de qualquer solução para o sistema, quase sempre serão definidas como classes no modelo de requisitos.
2.2.2. Objetos
2.2.3. Atributos
2.2.3.1. as operações (também chamadas de métodos ou serviços) que vão ser aplicadas aos objetos para efetuar a manipulação;
2.2.3.2. EM ESSÊNCIA SÃO OS ATRIBUTOS QUE DEFINEM UMA CLASSE - Atributos representam o conjunto de objetos de dados que definem completamente a classe no contexto do problema -
2.2.3.2.1. Exemplos
2.2.4. Relações
3. CASOS DE USO
3.1. Definição
3.1.1. Basicamente, um caso de uso conta uma jornada estilizada sobre como um usuário (desempenhando um de uma série de papéis possíveis) interage com o sistema sob um conjunto de circunstâncias específicas.
3.1.2. Independentemente de sua forma, um caso de uso representa o software ou o sistema do ponto de vista do usuário.
3.2. Atores
3.2.1. Definição
3.2.1.1. O que é um ator
3.2.1.1.1. Ator é um papel que as pessoas (usuários) ou dispositivos desempenham ao interagir com o software.
3.2.1.2. Ator primário
3.2.1.2.1. Os atores primários interagem para atingir a função necessária e obter o benefício desejado do sistema.
3.2.1.3. Atores secundários
3.2.1.3.1. Os atores secundários dão suporte ao sistema para que os primários possam realizar seu trabalho.
3.2.2. Nem todos os atores serão levantados na primeira iteração
3.3. Modelo de Caso de Uso
3.3.1. Perguntas chave para levantamento de Casos de Uso
3.3.1.1. • Quem é o ator primário e quem é (são) o(s) ator(es) secundário(s)?
3.3.1.2. • Quais são as metas do ator?
3.3.1.3. • Que precondições devem existir antes de uma jornada começar?
3.3.1.4. • Que tarefas ou funções principais são realizadas pelo ator?
3.3.1.5. • Que exceções poderiam ser consideradas à medida que uma jornada é descrita?
3.3.1.6. • Quais são as variações possíveis na interação do ator?
3.3.1.7. • Que informações de sistema o ator adquire, produz ou modifica?
3.3.1.8. • O ator terá de informar o sistema sobre mudanças no ambiente externo?
3.3.1.9. • Que informações o ator deseja do sistema?
3.3.1.10. • O ator gostaria de ser informado sobre mudanças inesperadas?
3.3.2. Caso de Uso Prático
3.3.3. Modelo Caso de Uso Força Tarefa
3.4. Diagrama de Caso de Uso
3.4.1. Exemplo
3.4.1.1. Diagrama de Caso de Uso.png