-
Notifications
You must be signed in to change notification settings - Fork 2
Estado Desejado
O modelo utilizado como base para o projeto será o Scrum que é um framework para metodologias ágeis, com alguns aspectos do Kanban e do eXtreme Programming(XP). A escolha do Scrum como base foi feita pelo motivo de que boa parte dos integrantes do projeto já estão familiarizados com ele, facilitando a execução do processo da empresa Go-Horse+.
Scrum é um framework para desenvolver, entregar e manter produtos complexos. Este guia contém a definição do Scrum. Esta definição consiste em papéis, eventos, artefatos e as regras do Scrum que unem os demais e os mantém integrados. Ken Schwaber e Jeff Sutherland desenvolveram o Scrum.
O XP é um método de desenvolvimento de software criado em 1997 considerado leve, não prescritivo, e que procura fundamentar as suas práticas por um conjunto de valores. Para o trabalho vamos trazer algumas dessas práticas:
O Kanban é uma estrutura popular usada para implementar o desenvolvimento ágil de software. Ele requer uma capacidade de comunicação em tempo real e transparência total de trabalho. Os itens de trabalho são representados visualmente em um quadro do kanban, permitindo que os membros da equipe vejam o estado de cada parte do trabalho a qualquer momento. Dessa forma, além de trazer grande visibilidade do fluxo de desenvolvimento para a equipe, é um ótimo complemento para o Scrum, que também foi eleito como modelo para o processo desejado, auxiliando em tarefas relacionadas a planejamento, monitoramento e controle.
As atividades do processo devem ser baseadas no Scrum. Portanto, é necessário que existam sprints, que a entrega seja incremental feitas em espaços de tempo definidos (time-boxed) que tenham os eventos de planejamento de sprint, reunião diária, revisão e retrospectiva mapeadas para as atividades do processo da empresa Go-Horse+. Os eventos do Scrum são definidos abaixo:
Planejamento da Sprint: (Planejamento) O Time de Desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidasdurante a Sprint. O Product Owner debate o objetivo que a Sprint deve realizar e os itens de Backlog do Produto que, se completados na Sprint, atingirão o objetivo da Sprint. Todo o Time Scrum colabora com o entendimento do trabalho da Sprint. O planejamento é time-boxed - máximo 8 horas para uma sprint com duração de um mês. Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o Time de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”. Os itens de Backlog do Produto selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de Backlog da Sprint. Durante o planejamento da Sprint é definido a meta da sprint que fornece uma direção para o Time de Desenvolvimento sobre o porquê de estar construindo o incremento.
Reunião diária: (Monitoramento e Controle) É um evento time-boxed de 15 minutos no máximo com foco no time de desenvolvimento. Ela é mantida todo dia no mesmo horário e local para reduzir complexidade. Ela é utilizada para inspecionar o progresso em direção ao objetivo da Sprint e para inspecionar se o progresso tende na direção de completar o trabalho do Backlog da Sprint. O Scrum Master assegura que o Time de Desenvolvimento tenha a reunião, mas o Time de Desenvolvimento é responsável por conduzir a Reunião Diária. O Scrum Master ensina o Time de Desenvolvimento a manter a Reunião Diária dentro do time-box de 15 minutos. No entanto com base no contexto do projeto deve ser feita uma adaptação, com a execução das "reuniões diárias" nos dias das aulas, com base das especificações acima, excetuando a periodicidade da realização do ritual.
Revisão da Sprint: (Monitoramento e Controle) A Revisão da Sprint é realizada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que podem ser feitas para otimizar valor. Esta é uma reunião informal, não uma reunião de status, e a apresentação do incremento destina-se a motivar e obter feedback e promover a colaboração. É um evento time-boxed de 4 horas para sprints com duração de um mês. O resultado da Revisão da Sprint é um Backlog do Produto revisado que define os prováveis Itens de Backlog do Produto para a próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades. O objetivo principal desse evento é demonstrar o que foi feito para as partes envolvidas no projeto.
Retrospectiva da Sprint: (Monitoramento e Controle) A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint. Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a si próprio. Apesar de que melhorias podem ser implementadas a qualquer momento, a Retrospectiva da Sprint fornece uma oportunidade formal focada em inspeção e adaptação. É um evento time-boxed de 3 horas para sprints com duração de um mês. Portanto, o objetivo desse evento é demonstrar os pontos positvos, os negativos e propor melhorias para os pontos negativos encontrados.
A utilização do KanBan pode estar explícita no processo desejado, mais especificamente, em atividades relacionadas aos seguintes eventos do Scrum: Planejamento da Sprint, Reunião Diária e na Própria Sprint (Time-Box de Desenvolvimento). Uma forma de mapear o uso desse modelo no processo, é a menção deste nas descrição das atividades, exigindo a utilização dos quadros e movimentação dos cartões caso seja necessário na atividade da qual a descrição diz respeito.
Assim como nas atividades, os papeis devem ter como base o framework scrum e devem estar explícitos no processo. Os papéis do Scrum são product owner, time de desenvolvimento e scrum master. As responsábilidades de cada um dos papeis se encontram abaixo.
Product Owner: O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto resultado do trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos.O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto.
Time de Desenvolvimento: O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento potencialmente liberável do produto “Pronto” ao final de cada Sprint. Um incremento “Pronto” é requerido na Revisão da Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos.
Características dos times de desenvolvimeto:
- Auto-organizados;
- Times de Desenvolvimento são multifuncionais;
- O Scrum não reconhece títulos para os integrantes do Time;
- O Scrum não reconhece sub-times no Time de Desenvolvimento;
- Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo
Scrum Master: O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia Scrum. O Scrum Master faz isso ajudando todos a entenderem a teoria, as práticas, as regras e os valores do Scrum. O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum.
As boas práticas devem ser definidas com base na metodologia de desenvolvimento eXtreme Programming(XP) e devem estar explícitas no processo de desenvolvimento (descrição das atividades) e/ou nas políticas adotadas pela empresa Go-Horse+. As boas práticas que devem ser seguidas são a programação pareada, execução de testes, integração contínuas e padronização do código. O Scrum não explicita como deve ser o desenvolvimento, por este motivo foi necessário o apoio do XP, portanto, é ideal que as boas práticas estejam inclusas na execução da sprint, seja como políticas ou como descrição da atividade de desenvolvolvimento. As práticas adotadas são descritas abaixo:
Trata-se de duas pessoas trabalhando com UMA máquina onde um codifica, e o outro critica ou dá sugestões. Os pares trocam de lugar periodicamente. Essa prática é excelente e favorece comunicação e aprendizado. Com essa troca constante de ideias temos como resultado um Projeto de maior qualidade e como estudos comprovam temos maior produtividade e maior qualidade (com padrão de codificação e entendimento do código e partes do código que não eram entendidos). Essa prática também facilita aprendizado dos novos integrantes.
Evidente que essa prática requer ambiente de trabalho apropriado como, por exemplo, um ambiente que provê mobilidade, e pessoas que devem concordar com o barulho que será causado.
A prática de teste no XP é bastante técnica, e envolve a presença do cliente no desenvolvimento e na validação de testes. O cliente compartilha com o desenvolvedor sobre o funcionamento do sistema. Os testes também se tornam as especificações da programação, visto que o teste diz o que deve estar de acordo e o que não deve estar de acordo, é como uma especificação.Os testes são escritos antes da funcionalidade, o que também é conhecido como TDD (Test-Driven Design) onde intercala-se a função de testar um pouco e codificar um pouco. Além disso, o TDD impõe o programador à saber o que deve ser verdadeiro no programa e o que não deve ser para que ele funcione corretamente, portanto, pensa-se primeiramente no problema e depois na solução. Dessa forma, os testes são automatizados, diferente de anteriormente onde o desenvolvedor fazia a implementação e entregava para alguém testar. Com os testes automatizados podemos executá-los a qualquer momento, e dessa forma, novas funcionalidade ou alterações podem ser imediatamente testadas para ver se essas mexidas não acarretaram outros problemas. Dessa forma, o teste impõem também confiança ao sistema e dão coragem para altera-lo, pois podemos saber imediatamente se algo introduziu um bug no sistema.
Entre os tipos de testes temos o Teste Unitário que automatiza o teste da funcionalidade e tipicamente testa uma classe, ou pequeno grupo de classes. Se um bug é descoberto, acrescenta-se imediatamente um caso de teste para ele. Assim garantimos que ele não se repetirá. Outro tipo de teste é o Teste de Aceitação (Teste funcional) que é especificado pelo cliente para testar que o sistema funciona conforme especificado por ele. Quando todos os seus testes de aceitação passam, a história é considerada completa.
Teste automatizado é a prática que sustenta e viabiliza muitas outras práticas como Integração contínua, Projeto Simples, Versão Pequena, Refatoração, e Propriedade Coletiva.
Para o contexto da matéria, não será feito o TDD tendo assim a adoção apenas dos testes automatizados.
Todo código deve ser integrado diariamente e todos testes devem passar antes e depois da integração. Se algum problema é encontra do ele deve ser corrigido imediatamente.
Todos mexem em todos os códigos, todos refatoram e todos trabalham em pares. Assim é interessante mantermos um padrão para termos algo solidificado. Por isso a melhor forma é a equipe definir um padrão de codificação sempre no inicio dos projetos.
Os artefatos do processo desejado devem ser, também, baseados no Scrum e devem estar explicitos no processo utilizado. O backloog do produto, backlog da sprint e o incremento são elementos fundamentais do Scrum e estes são descritos abaixo.
O Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no produto. É a única origem dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação.
O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint. O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento “Pronto”.
O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar na condição de ser utilizado e atender a definição de “Pronto” do Time Scrum. Um incremento é uma parte principal inspecionável de trabalho pronto que suporta empirismo no final da sprint. O incremento é um passo na direção de uma visão ou de um objetivo. O incremento deve estar na condição de ser utilizado independente do Product Owner decidir por liberá-lo ou não.
SCHWABER, Ken. SUTHERLAND, Jeff. The Scrum Guide The Definitive Guide to Scrum: The Rules of the Game. 2017 < https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf >
Como a metodologia Kanban é aplicada ao desenvolvimento de software https://br.atlassian.com/agile/kanban
Em geral, "medição" é o processo pelo qual números ou símbolos são atribuídos a atributos de entidades no mundo real, de modo a descrevê-los de acordo com regras claramente definidas (Fenton e Pfleeger, 1996). O resultado numérico é chamado de "medição". Isso pode ser aplicado a um processo de desenvolvimento de software e a um produto de software.
Medição de software é o processo contínuo de definir, coletar e analisar dados sobre o processo de desenvolvimento de software e seus produtos, a fim de compreender e controlar o processo e seus produtos, e fornecer informações significativas para melhorar esse processo e seus produtos.Sendo assim, é necessário que o processo da organização contenha em seu entendimento um momento para a realização dessa atividade de suma importância.
A medição de software deve ser realizada apenas para um propósito explicitamente declarado. Assim,para definir esse propósito, a organização utilizará o GQM (goal-oriented measurement) que é um modelo utilizado usado especialmente para programas de melhoria baseados na medição.Fazendo com que a organização respeite e realize todas as atividades e artefatos descritos como necessários por este modelo.
O GQM representa uma abordagem sistemática para adaptar e integrar metas a modelos de processos de software, produtos e perspectivas de qualidade de interesse, com base nas necessidades do projeto e da organização (Basili et al, 1994a). O resultado da aplicação do método GQM é a especificação de um programa de medição visando um determinado conjunto de questões e um conjunto de regras para a interpretação dos dados de medição.
O método GQM contém quatro fases:
- A fase de planejamento, durante a qual um projeto para aplicação de medição é selecionado, definidos, caracterizados e planejados, resultando em um plano de projeto.
- A fase de definição, durante a qual o programa de medição é definido (objetivo, perguntas, métricas e hipóteses são definidas) e documentadas.
- A fase de Coleta de Dados, durante a qual a coleta de dados real ocorre, resultando em Dados coletados.
- A fase de Interpretação, durante a qual os dados coletados são processados em relação ao métricas definidas nos resultados das medições, que fornecem respostas para as perguntas, após as quais a obtenção de metas pode ser avaliada.
A fase de planejamento é realizada para cumprir todos os requisitos básicos para tornar um programa de medição GQM um sucesso, incluindo treinamento, envolvimento de gerenciamento e planejamento de projetos. Durante a fase de definição, todas as entregas GQM são desenvolvidas, principalmente com base em entrevistas estruturadas ou outras técnicas de aquisição de conhecimento. A fase de definição identifica um objetivo, todas as questões, métricas e expectativas relacionadas (hipóteses) das medições. Quando todas as atividades de definição estão concluídas, a medição real pode começar. Durante esta fase de coleta de dados, os formulários de coleta de dados são definidos, preenchidos e armazenados em um banco de dados de medição.
Então, o "trabalho real" pode começar usando os dados de medição. Durante a fase de interpretação, as medições são usadas para responder às perguntas declaradas, e essas respostas são novamente usadas para ver se os objetivos declarados foram atingidos
Ao longo dos anos, o GQM evoluiu para incluir modelos de processos e produtos de software,resultando em uma abordagem GQM baseada em modelo (Solingen et al, 1995), que define métricas duas perspectivas diferentes.Sendo:
• Definição de métricas por membros da equipe do projeto, usando técnicas de GQM. • Definição de métricas com base em modelos de processos e produtos de software.
A modelagem GQM pode ser verificada quanto à consistência e completude com base em processos de software e modelos de produtos. As seguintes atividades são requeridas:
- Verifique a presença de todas as métricas diretas baseadas em GQM no desenvolvimento do modelo de processo de desenvolvimento de software.
- Ajuste o modelo de processo de desenvolvimento de software, adicionando as métricas diretas ausentes.
- Verifique a definição do GQM sobre métricas ausentes definidas no modelo de processo de desenvolvimento de software e identifique sua relevância.
- Ajuste a definição do GQM, adicionando as métricas diretas (ou indiretas) ausentes.
- Decida aceitar o conjunto de métricas diretas.
A verificação de consistência e integralidade entre os modelos de processo de desenvolvimento de software e o GQM significa que todas as métricas definidas em um programa de medição também precisam ser definidas no modelo de processo de desenvolvimento de software. No entanto, se uma determinada métrica direta não estiver definida no modelo de processo de desenvolvimento de software, conforme necessário no modelo GQM, o modelo de processo de desenvolvimento de software deverá ser aprimorado, adicionando a métrica específica. Desta forma, o GQM também suporta a melhoria de seus modelos de processo de desenvolvimento de software.
Um plano GQM consiste em um único objetivo mais os conjuntos de perguntas e métricas necessárias para fornecer uma definição operacional desse objetivo. Três técnicas são introduzidas para o desenvolvimento de planos GQM. Primeiro, são mostrados modelos de metas que auxiliam na geração de uma meta do GQM. Em segundo lugar, as folhas de abstração (um tipo de formulário) são definidas para auxiliar na coleta das informações necessárias para construir um plano detalhado do GQM. Em terceiro e último lugar, são fornecidas duas estruturas que documentam informações relacionadas a produtos e processos nos planos GQM. Um produto que está intimamente relacionado a um plano GQM é um plano de medição. A estrutura do GQM consiste em:
O modelo identifica cinco aspectos principais: o objeto, finalidade, foco de qualidade, ponto de vista e ambiente de um programa de medição. Primeiro, o aspecto do objeto expressa o alvo primário do estudo; isto é, o processo ou produto que será analisado. Segundo, o aspecto objetivo expressa como o objeto será analisado; isto é, será analisado para fins de compreensão e caracterização, será comparado com algum outro objeto, etc. Terceiro, o aspecto do foco de qualidade expressa a propriedade particular do objeto que será analisado no decorrer do estudo, como custo, confiabilidade, etc. Em quarto lugar, o aspecto do ponto de vista expressa informações sobre o grupo de pessoas que verá e interpretará os dados.Finalmente, o aspecto do ambiente expressa o contexto no qual o estudo será realizado e é usado para fazer fatores de influência explícito.
Um exemplo de meta de produto construída usando esse modelo pode ser:
- Analise o produto final (objeto)
- para fins de caracterização (finalidade)
- com relação à confiabilidade (foco na qualidade)
- do ponto de vista do testador (ponto de vista)
- no contexto do Projeto X (ambiente).
Um exemplo de objetivo de processo construído usando esse modelo pode ser:
- Analise o processo de teste (objeto)
- com a finalidade de melhoria (propósito)
- com relação à confiabilidade (foco na qualidade)
- do ponto de vista do desenvolvedor (ponto de vista)
- no contexto do Projeto Y (meio ambiente).
Uma folha de abstração GQM é um documento, geralmente uma única folha de papel, que ajuda a elicitar e estruturar informações durante uma entrevista e auxilia na construção, refinamento e revisão de um único plano de GQM. O design da folha de abstração reflete a questão que as pessoas podem pular de um problema para outro durante uma entrevista. Uma folha de abstração ajuda a lidar com esse problema e fornece um lembrete sobre quais questões de categorias genéricas devem ser abordadas. Uma folha de abstração também pode ser usada como uma visão abstrata de um plano GQM que ajuda a revelar as dependências entre as questões desse plano GQM.
Uma folha de abstração consiste em quatro quadrantes mais uma seção intitulada "Feedback" .Os quadrantes são: foco na qualidade, fatores de variação, hipótese da linha de base, impacto na hipótese da linha de base
Um plano GQM documenta o refinamento operacional de uma tarefa de análise. A tarefa é especificada com precisão como uma meta de medição que é refinada por meio de perguntas em métricas. As três camadas de um plano correspondem aos três seguintes níveis[2]:
-
Nível conceitual (meta)
- Um objetivo é definido para um objeto, por uma variedade de razões, com relação a vários modelos de qualidade, de vários pontos de vista e relativos a um ambiente particular.
-
Nível operacional (pergunta)
- Um conjunto de perguntas é usado para definir modelos do objeto de estudo e, em seguida, enfoca esse objeto para caracterizar a avaliação ou a realização de um objetivo específico.
-
Nível quantitativo (métrico)
- Um conjunto de métricas, baseado nos modelos, está associado a todas as perguntas para respondê-las de maneira mensurável.
Três grandes categorias de questões precisam ser abordadas para cada produto em estudo, ou seja, a definição do produto, a definição do foco da qualidade e o feedback relacionado ao foco da qualidade.
-
Definição do produto: Esta primeira categoria de perguntas inclui questões relacionadas a atributos lógicos e físicos, custo de desenvolvimento, mudanças durante o desenvolvimento, contexto operacional e outros aspectos que ajudam a caracterizar o produto.
-
Definição do foco de qualidade: Esta segunda categoria inclui questões relacionadas ao modelo principal do foco de qualidade que é usado, a validade do modelo para o ambiente específico, a validade dos dados coletados e também pode incluir uma fundamentação do modelo. Por exemplo, um modelo de “confiabilidade” de foco de qualidade pode ser simplesmente o número de falhas operacionais críticas e não críticas que foram relatadas durante a fase de teste de aceitação.
-
Feedback relacionado ao foco da qualidade: Essa terceira categoria inclui perguntas, relativas ao foco da qualidade, que pedem as informações necessárias ao tentar melhorar o produto.
Três grandes categorias de questões precisam ser abordadas para cada processo em estudo, ou seja, a definição do processo, a definição do foco da qualidade e o feedback relativo ao foco da qualidade do uso desse processo. Um plano GQM orientado ao processo é o mesmo que um plano GQM orientado para o produto em relação às duas últimas categorias de questões.
-
Definição do processo: A primeira categoria inclui questões relacionadas à conformidade do processo e à conformidade do domínio. Conformidade do processo inclui tanto uma caracterização do processo e uma avaliação de quão bem o processo foi seguido. Conformidade de domínio inclui uma caracterização do objeto ao qual o processo é aplicado e uma análise do conhecimento do executor do processo referente ao objeto.
-
Definição do foco e feedback da qualidade: Os propósitos e estruturas da segunda e terceira categorias de perguntas para um plano orientado para o processo são essencialmente idênticos aos seus correspondentes no plano orientado para o produto; seus conteúdos são naturalmente muito diferentes
Um plano de medição descreve quando, como e por quem os dados exigidos pelas métricas no plano GQM são coletados. Essencialmente, o plano de medição deve determinar o procedimento de coleta (quem, como e quando) para cada métrica no plano GQM. Se formulários ou ferramentas forem usados para coletar dados, eles devem ser incluídos (formulários) ou descritos em detalhes (ferramentas) no plano de medição.
Segundo Sollingen [1], temos as seguintes informações em relação aos papéis necessários durante a utilização do GQM.
Um requisito importante para o sucesso de um programa de medição é o nível de confiança mútua e cooperação entre a equipe do GQM e a equipe do projeto [4]. Portanto, é importante que a equipe do GQM não tenha interesse nos dados que a equipe de projeto se reúne. Para poder orientar e apoiar um programa de medição, a equipe GQM precisa ter um certo nível de conhecimento a fundo sobre o processos de desenvolvimento e produtos nos quais o programa de medição se concentra. Isto é um pré-requisito importante, pois a equipe do GQM deve ser capaz de discutir as interpretações com o equipe de projeto.
Além disso, a equipe do GQM deve considerar-se um facilitador da aprendizagem [4] e têm uma mente orientada para a melhoria. A equipe do GQM deve mostrar respeito à equipe do projeto em relação à execução das tarefas de desenvolvimento, como nem sempre predefinidas os procedimentos serão ou poderão ser seguidos. A equipe do GQM deve ter uma mente aberta para tais questões, como no final, os desenvolvedores têm todo o conhecimento sobre os processos e produtos e são responsáveis pelo seu projeto e suas medições.
Os papéis da equipe GQM são "gerente" (responsável pela continuação do programa de medição), 'coach' (especialista em GQM) e 'engenheiro de suporte' (para atividades de medição). As principais atividades da equipe do GQM são:
- Planejar programas de medição dentro de projetos de desenvolvimento.
- Realize atividades de definição de medição e desenvolva as entregas do GQM.
- Verifique a coleta de dados pela equipe do projeto e processe os dados disponíveis.
- Prepare a interpretação dos dados de medição, organizando sessões de feedback.
- Moderar as sessões de feedback.
- Relate o progresso para a equipe e a gerência do projeto, e divulgue e empacote os resultados.
Habilidades pessoais dos membros da equipe GQM desempenham um papel crucial no sucesso de um programa de medição, particularmente em sua capacidade de motivar os outros. Quando uma equipe do GQM não tem capacidade, todo o programa de medição tem pouco sucesso. Uma equipe GQM deve portanto, incluir funcionários respeitáveis.
No caso da organização, esses papéis devem estar claramente definidos e as informações divulgadas a todos os membros do projeto.
[1] Solingen, Rini & Berghout, Egon. (1999). The Goal/Question/Metric Method: A Practical Guide for Quality Improvement of Software Development.
[2] Basili, V.R., D.M. Weiss, ‘A methodology for collecting valid software engineering data’, IEEE Transactions on Software Engineering, Vol. SE-10, No. 6, 1984
[3] C. Differding, B. Hoisl, C. M. Lott. Technology Package f or the Goal Question Metric Paradigm. 281/96
[4] Solingen, R. van, E.W. Berghout, E. Kooiman, ‘Assessing feedback of measurement data: Schlumberger practices with reflection to theory’, Proceedings of the 4th International Symposium on Software Metrics (Metrics’97), Albuquerque, New Mexico, USA, IEEE Computer Society Press, pp 152-164, November, 1997.
Os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços que oferece e as restrições a seu funcionamento. Esses requisitos refletem as necessidades dos clientes para um sistema que serve a uma finalidade determinada, como controlar um dispositivo, colocar um pedido ou encontrar informações. O processo de descobrir, analisar, documentar e verificar esses serviços e restrições é chamado engenharia de requisitos [1].
Os requisitos de software são frequentemente classificados como requisitos funcionais e requisitos não funcionais:
Requisitos funcionais: São declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais também podem explicitar o que o sistema não deve fazer.
Requisitos não funcionais: São restrições aos serviços ou funções oferecidos pelo sistema. Incluem restrições de timing, restrições no processo de desenvolvimento e restrições impostas pelas normas. Ao contrário das características individuais ou serviços do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo[1].
O modelo utilizado como base para o projeto será uma adaptação do SAFe, Scaled Agile Framework, é um framework projetado por Dean Leffingwell para expandir o desenvolvimento ágil a nível corporativo, permitindo que o Scrum e o XP, sejam aplicados a grandes organizações, facilitando o gerenciamento de tarefas em empresas com vários desenvolvedores integrados[3].
O SAFe descreve uma hierarquia de artefatos que descrevem o comportamento funcional do sistema, sendo eles: Epic> Features> Stories. Porém para neste projeto será utilizado apenas as Features e Stories.
- Feature é um serviço que atende às necessidades de uma parte interessada. Cada Feature inclui uma hipótese de benefício e critérios de aceitação, e é dimensionado ou dividido conforme necessário para ser entregue por um único Agile Release Train (ART - é uma equipe de equipes Agile) em um Incremento de Programa (PI) - é um timebox durante o qual um (ART) fornece um valor incremental na forma de software e sistemas testados e em funcionamento[3].
Os Gerentes de Produto, em colaboração com os Product Owners e outras partes interessadas importantes, definem Features no contexto local de um ART.
A priorização das features deve ser feita com base no scrum que diz que o product owner ou cliente que deve escolher a preferência do que deve ser desenvolvido anteposto as demais features.
- Histórias (Stories) são descrições curtas de uma pequena parte da funcionalidade desejada, escrita no idioma do usuário. As equipes ágeis implementam pequenas fatias verticais de funcionalidade do sistema e são dimensionadas para que possam ser concluídas em uma única iteração. As histórias são o artefato principal usado para definir o comportamento do sistema no Agile. Eles não são requisitos. Em vez disso, são descrições simples e curtas de funcionalidade, geralmente contadas da perspectiva do usuário e escritas em seu idioma. Cada um deles destina-se a permitir a implementação de uma pequena fatia vertical de comportamento do sistema que suporte o desenvolvimento incremental[3].
Equipes ágeis usam pontos de história para valorizar seu trabalho. Um ponto de história é um número singular que representa uma combinação de qualidades:
- Volume - Quanto custa?
- Complexidade - quão difícil é isso?
- Conhecimento - O que é conhecido?
- Incerteza - O que é desconhecido?
Os pontos da história são relativos, sem conexão com nenhuma unidade de medida específica. O tamanho (esforço) de cada história é estimado em relação à menor história, à qual é atribuído um tamanho de 'um'. Uma seqüência de Fibonacci modificada (1, 2, 3, 5, 8, 13, 20, 40, 100) é aplicada, refletindo a incerteza inerente na estimativa, especialmente números grandes (por exemplo, 20, 40, 100) [1][3].
Além disso, o *SAFe é divido organizacionalmente em três níveis: nível Portfólio, nível do programa (Program) e nível de Equipe (Team). Porém, o modelo adotado para o projeto utilizará apenas o nível de time que fornece um modelo de processo para equipes ágeis baseadas em Scrum e práticas do XP.
O nível de equipe contém as funções, atividades, eventos e processos que os Agile Teams criam e fornecem valor no contexto do Agile Release Train (ART) .
Cada equipe ágil é responsável por definir, construir e testar as histórias de seu Backlog de equipe. Usando cadência e sincronização de Iteração comuns , as equipes se alinham a uma série de Iterações de comprimento fixo para garantir que todo o sistema esteja interagindo. As equipes usam ScrumXP ou Kanban para fornecer sistemas de alta qualidade, produzindo uma demonstração do sistema a cada período de tempo fixo pré-determinado. Isso garante que todas as equipes do ART criem um sistema integrado e testado que as partes interessadas possam avaliar e responder com feedback rápido[1][3].
São aplicados o ScrumXP ou o Team Kanban, juntamente com as práticas internas de qualidade que garantem um produto de qualidade. Cada equipe tem cinco a nove membros e inclui todas as funções necessárias para criar um incremento de valor de qualidade em cada iteração . As funções do ScrumXP incluem o Scrum Master , o Product Owner (PO), colaboradores individuais dedicados e quaisquer especialistas no assunto que a equipe precisa para agregar valor.
O modelo do projeto será baseado no SAFe (Scaled Agile Framework). Onde o serão definidos na escala negocial os épicos, que são divididos em funcionalidades como features, que por fim são destrinchados em histórias de usuários. Mantendo assim uma rastreabilidade[1][3].
Do SAFe só serão utilizados os épicos, as features e as histórias. E quanto a questão de nível, só será utilizada o nível de time.
A elicitação de requisitos compreende um conjunto de atividades em que os desenvolvedores utilizam para descobrir as necessidades dos stakeholders, buscando aplicar da melhor maneira os requisitos essenciais do sistema a ser desenvolvido. As necessidades, expectativas e recursos esperados do sistema serão levados em consideração de cada stakeholder. O intuito é prover de forma correta e completa entendimento do sistema.
Podem ser utilizadas inúmeras técnicas para elicitação de requisitos com o objetivo de colher informações como:
-
Entrevistas: Questionar os stakeholders sobre o sistema (ou processo) atual e sobre o sistema que será desenvolvido entrevistas, observação, cenários e leitura de documentos.
- Tipos de entrevistas
- Entrevistas fechadas: conjunto pré-definido de perguntas
- Entrevistas abertas: sem agenda pré-definida; se adapta para explorar o conhecimento do stakeholder
- Tipos de entrevistas
-
Prototipagem: Protótipo tem por objetivo explorar aspectos críticos dos requisitos de um produto, implementando de forma rápida um pequeno subconjunto de funcionalidades deste produto. O protótipo é indicado para estudar as alternativas de interface do usuário; problemas de comunicação com outros produtos; e a viabilidade de atendimento dos requisitos de desempenho.
-
Questionários: Existem vários tipos de questionários que podem ser utilizados. Entre estes podemos listar: múltipla escolha, lista de verificação e questões com espaços em branco. O questionário deve ser desenvolvido de forma a minimizar o tempo gasto em sua resposta
-
Brainstorming: é uma técnica para geração de idéias. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem idéias.
-
Técnica de Cenários: Descreve uma situação de uso do sistema, que inclui informações como:
- Nome do Cenário
- Ator(es)
- Pré-condição
- Fluxo normal
- Fluxos alternativos
- Pós-condição
Artefatos que devem ser documentados:
- Features
- Backlog da release (Histórias de usuário)
As Features são definidos usando uma Matriz de Recursos e Benefícios (FAB):
- Features - Uma frase curta que dá nome e contexto
- Hipótese de benefício - O benefício mensurável proposto para o usuário final ou empresa
| Feature | Hipótese de Benefício (Descrição) |
|---|---|
| FExx[Nome Significativo] | [Benefício mensurável proposto para o usuário final ou empresa] |
As histórias são descrições curtas de uma pequena peça de funcionalidade desejada, escrita na linguagem do usuário. As histórias implementam pequenas fatias de funcionalidades do sistema dimensionadas para que possam ser completadas pela equipe ágil em uma única iteração[3][1].
O SAFe recomenda a utilização da Voz de Usuário para a escrita das histórias, já que estas são voltadas para o próprio usuário e não ao sistema em si. Dessa forma, as histórias de usuário e as histórias técnicas serão descritas da seguinte forma:
| Nome da História | Eu, como... | desejo... | para... |
|---|---|---|---|
| USxx[Atividade] | [Papel] | [Atividade] | [Valor de Negócio] |
[1] Leffingwell, Dean. Requisitos ágeis de software: Práticas de requisitos enxutos para equipes, programas e a empresa . Addison-Wesley, 2011.
[2] SOMMERVILLE. Software Engineering, 9th edition, publicada pela Pearson Education, Inc
- Template do Plano de Medição
- Template para Resultado de Métricas Coletadas por Sprint
- Diretrizes e template para Objetivos GQM