Ciclo de Design

Overview

É o processo de concretização de uma ideia em forma de projetos, modelos ou especificações, para a criação de produtos ou serviços (LÖBACH, 2001). Trata-se de desenhar soluções para atender a uma necessidade, resolver ou mitigar um problema específico.

No Mi9, o Ciclo de Design é composto por quatro atividades:

Analisar a Viabilidade Prática
Realizar a Prova de Conceito
Decompor a Solução
Especificar Artefatos

No Quadro de Design além das listas de atividades, há a lista de Ajuda, que contém materiais de apoio sobre o Mi9; e, a lista de Backlog, uma "lista de coisas a fazer", um repositório temporário das ideias formadas no Ciclo de Ideação ou ideias maturadas que não passaram pelo Ciclo de Ideação necessariamente.

E na prática, o Mi9 instanciado em uma ferramenta de gestão apresenta o ciclo de Design em forma de Quadro composto por listas de cartões, e cada lista representa uma de suas atividades, que são detalhadas a seguir.

Fig. 1.1 - Fluxo do Processo de Design

Analisar a Viabilidade Prática (Practical Viability Assessment)

Nesta atividade o time analisa cada uma das ideias que emergiram na etapa anterior e as classifica em viáveis ou não viáveis utilizando critérios objetivos.

Analisar a viabilidade prática de uma ideia é uma responsabilidade do time para evitar que sejam selecionadas ideias não eficientes para revolver o problema ou superar o desafio proposto ou ideias que se restrinjam a um baixo tempo de materialização. Ou seja, esta atividade permite ao time refletir o quão viável uma ideia pode ser materializada a ponto de evitar retrabalhados, perda de tempo, entre outros prejuízos.

Entradas

As ideias não viáveis são arquivadas, e podem ser reaproveitadas ou revistas quando necessário. Uma ideia não viável em um determinado contexto, ou momento, pode se tornar viável em outro. Por exemplo, isso pode acontecer pelo fato de uma determinada tecnologia estar indisponível, no presente para viabilizar a materialização de uma ideia em função do seu custo, mas se tornar acessível num futuro próximo.

Ferramentas e Técnicas

Nesse estágio do ciclo, cada ideia é avaliada com base em critérios de viabilidade, que podem variar de acordo com o produto, projeto ou o contexto organizacional onde o produto está sendo desenvolvido. Para exemplificação da técnica adotaremos os seguintes critérios de análise de viabilidade:

- Técnica: procura responder a pergunta "a ideia é tecnicamente viável?". Esta pergunta ajudará a determinar se a organização possui ou não os recursos técnicos para desenvolver o produto com sucesso. A ideia pode ser materializada de forma confiável, sustentável e acessível? É possível garantir a qualidade necessária com os recursos disponíveis? Isso inclui avaliar todo os recursos (hardware, software e outros ativos) técnicos que você tem à sua disposição e se eles atendem ou não aos requisitos para o design de seu novo produto.
- Legal & Ética: procura responder a pergunta "a ideia é legal e eticamente viável?". A ideia está em conformidade com todos os requisitos, leis e regulamentos vigentes? É importante verificar se a ideia atende aos limites éticos e legais para sua implementação, que inclui desde leis de proteção de dados a requisitos de construção e cultura organizacional. Caso contrário, você poderá avançar antes de perceber que sua equipe não está cumprindo algum regulamento esquecido que desperdiçará mais tempo e recursos para retificar mais tarde.
- Econômica & Temporal: procura responder à pergunta "a ideia é economicamente viável e pode ser implementada no tempo disponível?". Estas são duas das questões mais importantes: (1) a implementação da ideia cabe no orçamento disponível? e, (2) o time tem tempo para implementá-la adequadamente? É importante que você avalie o cronograma realista e considere o tempo disponível para a conclusão do produto, caso contrário, você se verá perdendo os prazos e a qualidade de seus resultados. Neste critério você também avaliará se a ideia, uma vez implementada, fornecerá ou não o suposto valor necessário para justificar seu custo.

Algumas equipes podem se sentir mais à vontade desmembrando algum dos critérios acima em mais de um, ou adicionando seus próprios critérios. Para cada critério poderia ser estabelecida uma Escala de 3 pontos (1. Baixo, 2. Médio e 3. Alto), onde a maior pontuação estaria associada a superlatividade de cada critério. Como por exemplo na figura a seguir.

Fig. 1.2 - Escala de pesos para a Matriz TLE

Saídas

O principal produto deste estágio é a compreensão das ideias viáveis, a partir dos critérios de análise, para resolver o problema ou superar o desafio proposto. Nesta atividade o time aprende a analisar a viabilidade das ideias, que poderão ser reaproveitadas ou revistas.

Templates

Veja aqui o(s) template(s) recomendável(is) para esta atividade. Para aquele(s) que não possue(m) link de acesso, você pode buscar alternativas na internet. Posteriormente, poderemos incluí-lo(s) na seção.

Banco de Ideias - Matriz TLE

Síntese

Entradas

Ideias

Ferramentas e Técnicas

Priorização
Análise de Viabilidade
Matriz TLE
Banco de Ideias

Saídas

Ideias viáveis
Ideias não viáveis

Realizar a Prova de Conceito (Proof of Concept)

Prova de conceito (Proof of Concept - PoC) é uma demonstração de que uma ideia funciona de fato. Geralmente é implementada por meio de um 'modelo prático' que tenta provar que um 'conceito teórico' funciona na prática. Em alguns casos é uma implementação, em geral resumida ou incompleta, de uma ideia, realizado com o propósito de verificar se o conceito/teoria em questão é suscetível de ser explorado de uma maneira útil. A PoC é um passo importante no processo de criação de um protótipo realmente operativo da solução, ou de parte dela.

Contudo, a PoC é uma atividade opcional. O time deve realizá-la quando compreende que uma ideia é muito complexa (envolve muitas variáveis, precisa ser testada em suas partes e/ou na combinação destas partes), original (funciona em teoria, mas nunca foi testada na prática), ou possui potencial (funciona em outro contexto, mas nunca foi demonstrada no contexto vivenciado, ou há poucas referências a respeito).

Neste sentido, no Ciclo de Design, preconiza os seguintes possíveis fluxos de atividade (Figura 1.2):

Fluxo Principal: O time realiza a análise de viabilidade prática da ideia, e se satisfeito com a apreciação teórica da ideia, caracteriza-a como viável, e passa à atividade seguinte do ciclo de design: a decomposição da solução em seus componentes e especificações.
Fluxo Alternativo (ou de exceção): Caso o time não se sinta seguro se a ideia funciona na prática, realiza a PoC, procedendo uma apreciação prática da ideia, por meio de uma demonstração simplificada de sua viabilidade. As ideias fundamentamente viáveis são, então, decompostas em seus componentes e especificações, na atividade seguinte do ciclo de design.

Fig. 1.3 - Fluxo principal e fluxo alternativo do Ciclo de Design.

Entradas

As entradas desta atividade são as ideias que o time não se sente seguro quanto a sua viabilidade prática, pelos motivos já mencionados anteriormente.

Ferramentas e Técnicas

Diversas ferramentas e técnicas podem ser utilizadas numa PoC a depender da característica da ideia que precisa ter sua viabilidade verificada. Usualmente, a PoC é registrada em um documento para que possa servir de referência em situações semelhantes. Esse documento possui detalhes de planejamento, definição dos critérios de aceitação da PoC, implementação, avaliação dos resultados obtidos, e conclusão. A conclusão deve indicar claramente em que circunstâncias (ou cenários) a ideia avaliada é viável ou não, e se ela pode ser considerada como uma solução factível e razoável para o problema ou desafio posto.

Uma ideia 'teoricamente robusta' pode não ser viável num primeiro momento, por alguma insuficiência de recursos, contexto vivenciado pela organização onde ela seria aplicada, ou alguma limitação tecnológica. Contudo, esses entraves podem ser transitórios e essa mesma ideia pode demonstrar ser viável num momento futuro.

Saídas

O principal produto deste estágio é a confirmação ou não da exequibilidade das ideias que o time não se sentia seguro quanto a sua viabilidade prática, na etapa anterior do ciclo de design.

Templates

Documento de Prova de Conceito

Síntese

Entradas

Ideias

Ferramentas e Técnicas

Planejamento
Definição dos critérios de aceitação
Implementação da PoC
Avaliação dos resultados

Saídas

Ideias viáveis, aprovadas na prova de conceito
Ideias não viáveis, rejeitadas na prova de conceito

Decompor a Solução (Breakdown)

As ideias podem ser combinadas ou não (uma solução pode ser originada de uma única ideia), na concepção de uma solução para o problema ou o desafio posto.

Nesta atividade as soluções são decompostas em partes menores denominadas artefatos, para simplificar o processo de construção e teste. Artefato é um termo genérico utilizado para caracterizar produtos desenvolvidos a partir de um trabalho, para um propósito específico. Assim, as partes podem ser caracterizadas como o artefato que será produzido.

Os artefatos podem ser decompostos em partes menores, e estas caracterizadas como requisitos. Requisito é uma condição (ou regra) do negócio com a qual a solução (ou suas partes) deve estar em conformidade. Os requisitos podem ser funcionais ou não funcionais. Considerando o exemplo de um veículo, essas características podem ser 'concretas' (funcionais: rodas, volante...) ou 'abstratas' (não funcionais: seguro, rápido, leve...).

Os requisitos funcionais especificam ações que um artefato deve ser capaz de realizar, em termos de funcionalidade e utilidade.

Já os requisitos não funcionais estão relacionados ao uso de um artefato em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas; diz respeito a como as funcionalidades serão entregues ao consumidor da solução.

Entradas

Os insumos para realizar esta atividade podem ser derivados de duas formas:

O resultado da Análise da Viabilidade Prática: são as ideias viáveis, quando não houver necessidade de realizar a Prova de Conceito.
O resultado da Prova de Conceito: são as ideias viáveis aprovadas na Prova de Conceito.

Neste estágio, cada ideia, referida como solução ao problema ou desafio posto, é decomposta em partes menores (artefatos) para simplificar o processo de construção e teste, a partir da classificação dos requisitos atribuídos a cada um dos artefatos.

Ferramentas e Técnicas

A técnica de decomposição de requisitos prevê que a depender de sua complexidade e tamanho, os requisitos podem ser classificados em Épico, Tema e Estória, geralmente representados por cartões em quadros que servem para sinalizar o andamento das atividades por meio de um fluxo de trabalho (Kanban).

Épico - É uma estória (de usuário) que ainda não foi detalhada, é muito grande ou ainda possui muita incerteza, portanto não pode ser transformada em incremento do produto. O épico deve ser decomposto em estórias menores.
- - Um exemplo de épico poderia ser: “Eu, enquanto deficiente visual, desejo que meu ambiente de trabalho seja mais sinalizado para que eu não dependa tanto de outras pessoas.”

Tema - É uma coleção de estórias que compartilham características em comum.
Estória (de usuário) - É um formato sucinto para escrita dos requisitos necessários para a construção de um artefato.
- - Um exemplo de estória poderia ser: “Eu, enquanto pessoa com deficiência visual, desejo que os locais onde frequento sejam sinalizados para não ter que passar pelo constrangimento de precisar pedir orientação às pessoas”.

Uma ilustração dos tipos de requisitos que compõem um artefato é apresentada na Figura 1.3 a seguir:

Fig. 1.4 - Tipos de requisitos.

A técnica de especificação de requisitos pode ser aplicada em cartões de estórias, que são utilizados com o objetivo de capturar requisitos, eles concentram-se em "quem", no "que" e no porquê de um recurso", não no "como". Os cartões não devem possuir informações de "como o artefato será construído", ou qualquer outro tópico que não seja informações de negócio. E, os cartões devem ser escritos a partir de uma perspectiva do negócio sob a visão do MAnGveStaff, ou seja, das pessoas de negócio da organização. Assim, os cartões devem evitar jargões técnicos, e se existirem, deverão ser explicados e constar no Glossário.

No MAnGve, um framework ágil para implantação e melhoria dos processos de governança e serviços de TIC, do qual o MAnGve-i9 aproveita muitos conteúdos em seus ciclos, os cartões de estória são utilizados para capturar as entregas esperadas de requisitos de negócio (Business Requirements ou BR), baseados em iniciativas de TIC que possam colaborar na consecução do negócio da organização. E de cada BR são elicitadas as estórias de negócio (Business Stories ou BSs) que precisam ser entregues para agregação de valor ao negócio.

A figura 1.4 a seguir representa um exemplo de cartão de estória com base no contexto supracitado, utilizado no MAnGve:

Fig. 1.5 - Exemplo de cartão de estória. Fonte: Luna (2011).

Um cartão de estória deve possuir ao menos três grupos de itens: informações do cartão; dados de conversa com o usuário/cliente; e, testes de validação de cartão.

Informações do cartão: i) número (ID ou código) e rastreabilidade (iniciativa e requisito de negócio associados a uma determinada estória); ii) nome ou título; iii) descrição da estória; iv) estimativa de complexidade (story points ou SP); v) valor de negócio (Business Value ou BV); vi) ROI (Retorno sobre o Investimento); vii) Proprietário: geralmente o MAnGveBiz, ou um membro do MAnGveStaff, irá definir o que será entre na estória e será chamado pelo time para esclarecer dúvidas quando necessário etc.
Conversas: são anotações (lembretes) gerais que possam agregar mais detalhes à estória.
Confirmação (ou testes de aceitação): são os requisitos que deverão ser atendidos para que a estória seja aprovada (ou aceita) nos testes. Os testes possibilitam o entendimento melhor do cartão e ajudam na busca de cenários que o MAnGveStaff e o MAnGveTeam podem não ter pensado. São esses critérios que podem ajudar o MAnGveTeam a comprovar para o MAnGveBiz que a estória foi entregue e colaborou no atendimento do requisito de negócio e está entregando o valor planejado ao negócio.

Saídas

O principal produto deste estágio são os cartões de requisitos a partir da classificação de requisitos de cada artefato conforme complexidade e tamanho, necessários para a construção e teste de um artefato. A partir dos cartões o time se prepara para especificar os cartões de estórias, que definirão as diretrizes de cada artefato que será construído no ciclo seguinte.

Templates

Cartões de requisitos

Síntese

Entradas

Ideias viáveis a partir da Análise da Viabilidade Prática
Ideias viáveis aprovadas na Prova de Conceito

Ferramentas e Técnicas

Técnica de Especificação
Técnica de Decomposição

Saídas

Cartões de Requisitos do tipo Estória

Especificar Artefatos (Especify Artifacts)

Neste estágio, para cada artefato identificado deve ser realizado o desenho e a especificação detalhada da arquitetura e design para facilitar o desenvolvimento. O time precisa de uma "lista de especificações" para iniciar o ciclo de desenvolvimento, porque além da construção, prevê o teste de conformidade em resposta a questões como "o artefato atende a todos os requisitos especificados?", "são necessários ajustes nos requisitos para que o artefato seja homologado?". Neste caso, se o time identificar no teste a necessidade de ajustar os requisitos como sinal de impacto no desenvolvimento do artefato proposto, o time volta a este estágio, complementa ou corrige a lista de especificações e retorna ao ciclo de desenvolvimento. Portanto, para evitar retrabalho, faz-necessária a máxima atenção no produto deste estágio.

Entradas

As Estórias que surgiram na etapa anterior são especificadas, i.e., descritas em pormenores e representadas visualmente sempre que possível (por meio de diagramas e/ou desenhos esquemáticos), buscando produzir insumos suficientes para o pleno desenvolvimento e testes do artefato em questão. Uma vez especificadas as partes que compõem o artefato (seus requisitos) é possível iniciar o Ciclo de Desenvolvimento.

Ferramentas e Técnicas

Embora o time conheça os tipos de requisitos que podem compor um artefato (funcionais e não funcionais) no estágio anterior, nesta atividade cada requisito é especificado e documentado. Na área de Requisitos de Software existem modelos de documentação popularmente aceitos, e podem ser adaptados e aplicados no contexto do Mi9.

Primeiramente os membros do time responsáveis pela técnica de especificação dos requisitos poderão aplicar a técnica de benchmarking (reveja detalhes desta técnica no Ciclo de Ideação, na atividade de Desenvolver Empatia) para pesquisar e selecionar especificações de requisitos do artefato que será produzido, com base em outros contextos.

Complementarmente o Modelo de Casos de Uso é utilizado como base para captar e qualificar requisitos funcionais ao artefato a que se propõe construir. O modelo de Casos de Uso descreve como diferentes atores interagem para resolver um determinado problema ou simplesmente executar uma determinada atividade. É comumente utilizado para descrever interações entre usuários e um sistema.

O modelo de Casos de Uso permite que uma visão global de todos os atores que estão envolvidos em um determinado problema ou desafio e quais interações são possíveis considerando o artefato a ser construído.

Neste sentido, o Diagrama de Casos de Uso é a representação do modelo de Casos de Uso e se constitui em uma ferramenta que agrega valor à especificação dos requisitos funcionais. O Diagrama utiliza a linguagem UML (Unified Modeling Language ou Linguagem Unificada de Modelagem), uma notação presente dominante em modelagens e documentações de projetos que percorrer por diversas atividades de desenvolvimento de um artefato e facilita a comunicação entre o time ao longo do processo.

No diagrama, para cada caso de uso, constata-se uma função (representada por uma elipse), e, para cada função o time deve associar a um requisito funcional, que deverá constar no cartão de estória.

Figura 1.6 - Diagrama de Casos de Uso

E, para estruturar as especificações em um documento, faz-se necessário documentar desde uma breve descrição do objetivo do documento até as especificações propriamente ditas. Um exemplo da estrutura deste tipo de documento é representado a seguir:

Introdução

1.1 Objetivo

1.2 Escopo

1.3 Definições, Acrônimos e Abreviações

1.4 Referências

1.5 Visão Geral

Descrição Geral

2.1 Relatório Sintético de Modelo de Casos de Uso

2.2 Premissas e Dependências

Requisitos Específicos

3.1 Relatórios de Caso de Uso

3.2 Requisitos Suplementares

Informações de Suporte

Saídas

O principal produto deste estágio é a especificação de artefatos a serem construídos. As estórias serão transferidas para o backlog do próximo ciclo e servirão de insumos, subsequentemente, para a atividade de Planejamento de cada Iteração, onde serão identificados os grupos de tarefas relacionadas que precisarão ser realizadas para entregar cada Estória.

Templates

Cartões de estória
Documento de Especificação de Requisitos
Diagrama de Casos de Uso

Síntese

Entradas

Cartões de Requisitos do tipo Estória

Ferramentas e Técnicas

Benchmarking
Técnica de Especificação

Saídas

Artefatos Especificados (Estórias)

Ficou com alguma dúvida?

Navegue pelas Perguntas Frequentes ou Envie-nos sua mensagem no Formulário de Contato.

Page updated

Report abuse