Este artigo foi traduzido por máquina.

ALM Rangers

Uma caça ao tesouro de preparação para o ALM

ALM Rangers

Baixar o código de exemplo

Neste artigo, apresentamos o exemplo Windows Store app, ALM mapa do tesouro de prontidão e compartilhar o projeto, codificação e teste de experiências do Visual Studio ALM Rangers na construção do aplicativo. Ele foi projetado para fornecer um catálogo mestre do conteúdo disponível para ajudar os desenvolvedores a se tornar proficientes em práticas de Application Lifecycle Management (ALM). Os ALM Rangers são um grupo de especialistas que promovem a colaboração entre o grupo de produtos da Visual Studio , Microsoft Services e a comunidade Microsoft MVP por endereçamento funcionalidade ausente, removendo bloqueadores de aprovação e publicação, melhores práticas e diretrizes com base nas experiências do mundo real.

O que podemos fazer e por quê?

Nós temos uma confissão a fazer: Nós amamos Visual Studio e Visual Studio Team Foundation Server (TFS). Microsoft produz algumas das melhores ferramentas de desenvolvimento de software disponíveis. Nós não apenas está dizendo que, porque trabalhamos para Microsoft — sentimos esta maneira muito antes de entrar para a empresa. Estas suites oferecem um número incrível de recursos, mas podem provar difícil para novos usuários. Como os desenvolvedores começar a aprender a usar essas ferramentas? Esta questão apresentou-se a nós em uma forma ligeiramente diferente.

ALM Rangers presentes nas conferências de TechReady que normalmente têm um número de sessões que descreve como melhorar o conhecimento das ferramentas de desenvolvimento Microsoft. As conferências até mesmo realizar sessões interativas onde os participantes podem fornecer feedback para os grupos internos, estes produtos de construção. Encontramos estas ser excitantes oportunidades para desenvolvedores e consultores. Depois de entrar para a equipe de ALM Rangers , começamos a explorar as orientações publicadas e rapidamente percebeu que havia uma quantidade significativa de conteúdo para digerir; ficamos sem saber onde começar a estudar.

O que realmente queríamos era um recurso para nos ajudar a se tornar proficientes em práticas ALM. Começamos a ALM prontidão tesouro mapa Windows loja app para levar os usuários através dos materiais em sua jornada para se tornar especialistas de construção. Figura 1 mostra-lhe os resultados do nosso trabalho. Ele contém cinco categorias, cada uma com vários tópicos de estudo:

1. Preparar
2. Introdução rápida
3. Diretrizes
4. Trabalho feito com ferramentas
5. Oficinas

Figura 1 o tesouro mapa Windows Store App

Estas áreas contêm guias, laboratórios práticos e vídeos para torná-lo tão fácil quanto possível para os usuários para pegar as habilidades que eles precisam de forma rápida e eficaz. Navegando os materiais funciona particularmente bem em novos dispositivos de ecrã táctil, como o Microsoft Surface.

Para proporcionar a experiência ideal, nós contou com a ajuda de um especialista UX designer e desenvolvedores sênior para construir o aplicativo.

A solução de mapa de tesouro de prontidão ALM: UX Design Nuggets

Fazer uma boa primeira impressão a telha de mapa do Tesouro (ver Figura 2) é atraente e brilhante, com um fundo laranja, usado para simbolizar a areia. Imediatamente, o usuário vê o tema do app — isso é evidente por causa da palmeira e o caminho para onde "X" marca o local do Tesouro. O título do app é claramente visível na telha. Certificar-se de que a telha retrata o que o app é realmente sobre cria uma boa primeira impressão. A última coisa que você quer é para que os usuários abrir o app e confundir-se sobre por que eles estão usando ele e como ele pode ajudá-los.

Figura 2 o tesouro mapa Windows Store App telha

Nós já alavancou a tela inicial (consulte Figura 3) para mostrar um pouco mais da personalidade do aplicativo e para ajudar a garantir uma experiência de bom lançamento. Tela de abertura do mapa do Tesouro processa um caminho longo para o tesouro, que é uma experiência de carregamento liso, polido. É organizada e direta pelo projeto, refletindo como o UX será. Além disso, uma única tela pode ajudar a reforçar a marca.

Figura 3 tela inicial de App Store de janelas de mapa de tesouro

Página inicial — o mapa do Tesouro — aparece quando o aplicativo foi carregado. Mais uma vez, nosso projeto claro, centrados em conteúdo imediatamente confirma a finalidade do app. Queríamos fazer esta página fantástica para que o usuário que quer explorar o resto do aplicativo. A homepage é onde a viagem começa e, num ápice, o usuário sabe que isso vai ser uma viagem. Os títulos são a fonte para a navegação, e por causa de nosso projeto "conteúdo sobre cromo", eles se destacam. O conteúdo do aplicativo é enfatizado através da remoção de quaisquer elementos não-funcionais. Alguém olhando para encontrar informação rapidamente pode encontrar todos os links na tela sem ter que navegar através da app, que proporciona uma grande experiência para todos os tipos de usuários.

Às vezes negligenciado, mas Crucial o Windows 8 UI usa o princípio de um sistema de grade em todos os seus apps. Este princípio promove um design limpo e organizado.

O mapa do Tesouro app emprega o sistema de grade em todos os lugares, exceto na página inicial e o resultado é que o conteúdo é altamente visível — mais conteúdo, menos cromo. Este conteúdo sobre princípio de cromo é um dos princípios mais originais do estilo app Store do Windows, onde a unidade visual contribui para um UX grande. A homepage é a única página que é uma exceção a essa regra. Nós estamos retratando uma viagem e um tema do pirata que não fomos capazes de alcançar sem representações visuais.

Tipografia é por vezes esquecida e muitas pessoas não percebem o quanto ele pode fortalecer a marca do app. Usando fontes corretamente e consistentemente ajuda a alcançar clareza e dá uma aparência simples e minimalista, que faz com que o aplicativo mais fácil de ler e, portanto, usar. As fontes recomendadas são Segoe UI (usado principalmente para elementos de interface do usuário, como botões), Calibri (usada para leitura e escrita, como em e-mails) e Cambria (para blocos maiores do texto). Usamos Segoe UI para todo o texto que não sejam os cabeçalhos. Para aqueles, costumávamos Blackadder ITC para estabelecer um tema mais forte (ver Figura 4). Vamos quebrar a regra de fonte aqui, porque queríamos a aparência do aplicativo, para coadunar-se com um mapa em papel, como isso ajuda a reforçar o tema pirata. Então, nesse caso, ele funciona bem.

Figura 4 a tipografia que usamos no App Store de janelas de mapa de tesouro

Navegação perfeita e fluida é crucial para fornecer essa facilidade de uso e grande UX. Duas formas de navegação padrões são recomendadas: o sistema hierárquico e o sistema plano (ver Figura 5). O sistema hierárquico é o que a maioria dos aplicativos usam. Ele é o mais comum e vai ser o tipo mais familiar de navegação para muitos usuários. É também o melhor sistema para criar essa sensação de fluido ainda ser ainda fácil de usar. O sistema plano é usado principalmente em jogos, navegadores ou aplicações de criação de documentos, onde o usuário pode apenas ir para trás e para a frente no mesmo nível hierárquico. O mapa do Tesouro app usa o sistema hierárquico, e acreditamos que ele usa-lo bem. Página inicial poderia ser classificada como o hub e cada seção cria o primeiro ramo hierárquico, onde cada seção, em seguida, cria outro ramo hierárquico. Por exemplo, partir da homepage, o usuário pode navegar para a seção de preparação, onde o usuário pode explorar outras subseções de preparar.

Figura 5 padrões de navegação de recomendado

Usabilidade é importante avaliar o UX do app para melhorar o design para que o app é:

• Fácil de usar
• Mais valioso para os usuários — por exemplo, as características que ele pode oferecer
• Mais desejável para usar

Avaliar seu projeto dá-lhe a confiança que a app tem um excelente UX e que os usuários vão achar útil, útil e desejável.

Assim como avaliamos o UX do app? Há muitas maneiras de fazer isso, mas dois comuns são auto-avaliações e orientações cognitivas, como mostrado na Figura 6.

Figura 6 avaliando o UX do App

Existem quatro métricas de sucesso que vão ajudar tanto a auto-avaliação do app como o passo a passo cognitiva do app. Eles são:

• Grande em: Qual é o app grande em? Quais são os pontos focais dos elementos visuais?
• Utilizável: O que usuários seja capazes de compreender, saber ou fazer mais sucesso por causa de app?
• Útil: O que você deseja que os usuários os valor?
• Desejável: Quais partes do aplicativo você deseja encantar os usuários ou eles fazem amor?

Usamos auto-avaliações e orientações cognitivas. As auto-avaliações foram realizadas através de cada sprint e revistas no nossos stand-ups semanais. As orientações cognitivas foram realizadas durante o processo de projeto e através de cada sprint. Avaliar o UX do nosso app nos ajudou a entender o desejo e a conexão emocional para as experiências que um usuário pode reconhecer.

Para resumir o UX design:

• Certifique-se de que a peça retrata o seu app é sobre.
• Crie uma tela de abertura exclusivo para reforçar sua marca.
• Escreva o conteúdo com um foco claro.
• Use o layout de grade recomendada para criar um projeto simples e limpo.
• Don' t esquecer sobre tipografia. Use fonte recomendada sempre que possível, como Segoe UI, Calibri ou Cambria.
• Ter um padrão de navegação clara. Escolha o sistema hierárquico ou o sistema flat.
• Avalie a usabilidade de seu aplicativo em todo o ciclo de desenvolvimento.

As jóias de codificação

Antes de codificação começou, estamos estabelecidos uma série de objetivos para este projeto de codificação. Essas metas tornou-se o mantra para como concebido e desenvolvido a base de código.

• Adaptabilidade: Requisitos podem alterar características podem ser adicionadas ou corte e projetos podem ser jogados fora em favor de algo completamente diferente. Adaptabilidade é o nome do jogo!
• Simplicidade: Simplicidade é essencial para muitas vantagens no design de software, em especial para a facilidade de manutenção e fixability.
• Capacidade de teste: Garantia de qualidade deve ser uma prioridade para cada projeto, e a base de código deve permitir testes abrangentes e "simples".
• Desempenho e fluidez: UX do aplicativo deve ser positivo desde o início. A app deve exibir informações em tempo hábil, deve sempre estar respondendo à entrada do usuário e não deve ficar.
• Ambientes de equipe: Raramente é um aplicativo construído por um contribuinte individual ou até mesmo uma equipe individuais. Temos a certo que o app foi construído de forma que poderia ser escalada para muitos membros da equipe mais.

Assim agora que nós tivemos nossos objetivos definidos, como no mundo nós conseguir escrever um app em tão pouco tempo — trabalhando tempo parcial — cumprindo não apenas os requisitos funcionais, mas também nossos requisitos não-funcionais também? Felizmente para nós, esta roda foi construída antes, e a construção do nosso app era uma questão de aplicação comprovadas de padrões e práticas para nosso aplicativo:

• C# e XAML: Decidimos usar c# e XAML, principalmente porque a maioria dos contribuintes neste projeto está familiarizada com esta abordagem. Isso inclui os idiomas próprios, bem como o ferramental e suporte para eles.
• Model-View-ViewModel (MVVM): Este é um padrão para a separação de sua camada de apresentação de sua lógica de negócios de seus objetos. Nós escolhemos esse padrão particular porque o c# XAML tecnologias e se prestam muito bem a ele. Mas, mais importante, com um padrão único, fomos capazes de começar a escarificação afastado em nossos requisitos não-funcionais. Os objetivos que MVVM mais positivamente afetado foram adaptabilidade, testabilidade, ambientes de equipe e simplicidade. Adaptabilidade é melhor que você pode trocar qualquer das peças funcionais de sua aplicação. Talvez uma nova apresentação de um modelo de vista particular foi terminada, e você imediatamente pode substituí-lo sem alterar qualquer outro código. Capacidade de teste é melhor porque cada parte funcional do núcleo do código é separado em suas responsabilidades individuais, quais testes de meios podem ser escritos contra aqueles diretamente e automatizados. Ambientes de equipe são melhores porque você tem um conjunto definido de contratos entre partes móveis do aplicativo, permitindo que equipes trabalhem em paralelo um com o outro. Simplicidade é melhor em que cada parte móvel é a sua própria parte de movimento definida e interage de forma específica. Para obter mais informações, consulte "O que há de novo no Microsoft Test Manager 2012" em msdn.microsoft.com/magazine/jj618301.
• Resources: Seguindo o espírito do MVVM e separação de funções e partes substituíveis, decidimos adicionar recursos para a definição de nossas fontes, botões e outros elementos de design semelhante. Isso ajudou a adaptabilidade, simplicidade e melhorar ambientes de equipe.
• Mas o que podemos fazer sobre o desempenho e fluidez? Seguimos o padrão assíncrono/aguardam para processos de longa duração. Esta é uma das áreas onde os desenvolvedores podem lutar na criação de aplicativos Windows Store, mas ele não tem que ser. Felizmente, apps da loja do Windows usando c# e XAML são alimentados pelo Microsoft .NET Framework 4.5, que permite que você facilmente incluir cargas de trabalho assíncronas em seu aplicativo através deste padrão. Se ele é feito tão facilmente, por que gente lutar com ele? A resposta a esta pergunta geralmente resume-se a usar a lógica que é longa e não é fornecida fora da caixa pelo .NET Framework. Um exemplo disso poderia ser lógica para calcular pontos de trama para um gráfico com base em matemática complexa. A completa compreensão do async e aguardam é crucial para fornecer um app de fluido, de alto desempenho. Para obter mais informações, consulte "desempenho de Async: Entendendo os custos de Async e Await"em msdn.microsoft.com/magazine/hh456402.

Outras considerações incluídas:

• Linguagem do toque: De uma perspectiva de desenvolvimento, isso não poderia ser mais fácil. Quase todos os controles fora-de-caixa suporta o toque em todas as maneiras que você espera. De uma perspectiva de codificação, esta foi a parte mais fácil do app para construir.
• Amuletos: Interagindo com os encantos era simples assim. Registrar estas em seu appxmanifest e adicionar no evento manipuladores para cada página para os encantos específicos para registrar, como Pesquisar ou compartilhamento. Nós não tinha problemas lidando com encantos. Bem, em que trabalhou como um encanto deve funcionar.
• Telhas, telas de splash e orientações: Todos estes foram tratados no appxmanifest e, em seguida, através de ganchos de evento no app no nível do aplicativo. Era simples, e tudo é detalhado no código de exemplo.

Como tudo realmente funcionava aqui é como as coisas funcionavam na prática:

• Comandos do MVVM: MVVM foi fantástico na teoria. No entanto, na realidade, mostrou um pouco diferente do usual Windows Presentation Foundation (WPF) e desenvolvimento de Silverlight, particularmente para a execução de comandos, porque nossas amostras antigas não funcionam. Felizmente, de comando <T> foi bastante fácil de implementar no novo quadro e pode ser visto em nosso aplicativo de exemplo. Mas nossos problemas não terminam com comandos, porque ListViewBase itens não tem uma propriedade anexada comando! Estamos decididos a resolver este problema para demonstração de duas maneiras:

Em primeiro lugar, estamos decididos a resolver este problema usando uma propriedade não utilizada:

<ListView Grid.Column="2"
          SelectedItem="{Binding Selected,Mode=TwoWay}"

A propriedade a que está vinculado retorna "nulo" e não jogue todas as exceções (mesmo se você ligar todas as exceções), que é bom, mas a chave está no conjunto. No conjunto, em vez de definir qualquer coisa, nós fazemos uma navegação chamada e passar como parâmetro o índice do item selecionado.

Em segundo lugar, nós decidimos criar uma propriedade de dependência anexada do tipo ICommand. O exemplo de implementação é a classe "ItemClickCommand" dentro da pasta "MVVMSupport."

• Vários Estados de exibição conduzem a enormes arquivos: Nossos arquivos de vista tornou-se extremamente grandes e mais difíceis de gerir, principalmente devido aos vários Estados de exibição. Um layout diferente por estado de exibição é geralmente necessário, e você mesmo poderia ter diferentes pontos de vista para exibir diferentes dimensões ou dimensões de mudanças e assim por diante. Nossa abordagem foi dividi-los em vários arquivos. XAML, usando um arquivo. XAML per view por Estado. Por exemplo, se tivéssemos uma exibição chamada "HomePageView", teríamos "HomePageView.xaml" dentro de uma pasta completa, bati e cheia, cada um na pasta de seu estado.
• Adaptando-se no mundo real: Esta foi uma boa história. Depois que tinha desenvolvido grande parte de nosso aplicativo — UIs de comutação e comutação provedores de dados, adicionando novos charm interações de todos os lugares adequados — adaptando-às novas exigências tornou-se um pedaço de bolo. Questões eram fáceis de rastrear, e grande parte do planejamento valeu a pena porque os designers poderiam trabalhar em paralelo com os colaboradores e patrocinadores.

Resumindo nesta seção, de um ponto de vista da codificação, Windows Store apps são simples de desenvolver adequadamente. Seguir algumas regras predefinidas, mentalidades e padrões permite criar um app bom rapidamente. As principais preocupações são o estado de exibição do aplicativo, estado de ciclo de vida do aplicativo, interação de encanto, fluidez e garantindo que você o código de uma forma que permite que sua equipe de design iterar projetos no será. Para obter mais informações, consulte dev.windows.com.

Testar e verificar a qualidade da solução

Dentre os requisitos de aceitação do núcleo que definimos desde o início foi para elevar a qualidade de código de amostra e fazer parte do nosso programa de cão-fooding qualidade global (ver aka.ms/df_tooling). Portões de qualidade rigorosos para geopolítica, namespace, análise de código e StyleCop (consulte stylecop.codeplex.com) conformidade ajudou-nos produzir uma solução melhor, ainda que apenas uma amostra.

Teste não deve ser uma reflexão tardia e é tão importante com amostras como é com soluções de missão críticas. É mais fácil para fazer valer a qualidade do código e gerenciar requisitos e expectativas do usuário, desde o início, ao invés de confrontar-se com centenas de bugs de conformidade e testadores irados e tem que lidar com a rotatividade de recurso e código durante um ciclo de melhoria da qualidade tardio.

Porque a intenção era uma solução rápida, principalmente adotou uma "caixa preta", testando a estratégia com foco em comportamento como parte do sistema e o usuário (UAT) de testes de aceitação. O anterior foi realizado manualmente pela equipe, com foco em características esperadas e requisitos não-funcionais e explorando casos borda onde os internos foram compreendidos. A Comunidade foi convidada para auxiliar com a validação de UAT, realizando teste exploratório com base em cenários reais e expectativas e unearthing bugs e funcionalidades ausentes, impraticáveis e claras.

Conforme Figura 7 (com os numerais correspondentes aqui os números de um círculo vermelho na figura), normalmente usamos o recurso de teste exploratório Microsoft Test Manager (1) e o simulador (2) para avaliar a solução de exemplo em um dispositivo do tipo de superfície, capturado detalhada comentários (3) e gravou a sessão de testes (4) para referência futura.

Figura 7 teste exploratório

No futuro, vamos seriamente considerar a definição de casos de teste mais estruturados e o uso de Microsoft Fakes para nos ajudar a implementar a unidade e testes de fumaça. Isso nos permitirá automaticamente e continuamente validar alterações de recurso e associada a alterações de código.

O que vem a seguir?

Nós irá evoluir o app de mapas de tesouro de prontidão ALM, e estamos considerando uma característica de atualização on-line para os ativos de referência de prontidão. Para obter mais informações, consulte "sob­o Visual StudioALM Rangersde pé" em aka.ms/vsarunderstand; Visual Studio ALM Ranger soluções"em aka.ms/vsarsolutions; o código de exemplo de mapa de tesouro de prontidão ALM em aka.ms/almtreasure; e o próprio aplicativo na loja do Windows em aka.ms/vsartmapapp. Congratulamo-nos seu feedback sincero e idéias!

Anisha Pindoria é um consultor desenvolvedor UX Microsoft Consulting Services no Reino Unido.

Dave Crook é consultor desenvolvedor Microsoft Consulting Services região leste, onde seu foco é Visual Studio e Team Foundation .

Robert Bernstein é um desenvolvedor sênior com a equipe da Microsoft Consulting Services em todo o mundo Sector Público Cyber segurança.

Robert MacLean é um desenvolvedor de software aninhado em um escritório de desenvolvimento de plano aberto típico no BBD (bbd.co.za).

Willy-Peter Schaub é gerente de programa sênior com o Visual Studio ALM Rangers o Canadá Microsoft Development Center.

Agradecemos ao seguinte especialista técnico pela revisão deste artigo: Patricia Wagner (Microsoft)