Este artículo proviene de un motor de traducción automática.

ALM Rangers

En busca del tesoro de los conocimientos de ALM

ALM Rangers

Descargar el ejemplo de código

En este artículo, introducimos la aplicación Windows Store de muestra, preparación ALM mapa del Tesoro y comparten el diseño, codificación y pruebas de experiencias de los Visual Studio ALM Rangers en la construcción de la aplicación. Se ha diseñado para proporcionar un catálogo maestro de los contenidos disponibles para ayudar a los desarrolladores sean proficientes en las prácticas de gestión de ciclo de vida de aplicaciones (ALM). Los ALM Rangers son un grupo de expertos que promueven la colaboración entre el grupo de producto de Visual Studio , Microsoft Services y la comunidad de Microsoft MVP por funcionalidad falta abordar, quitar los moldes de la adopción y publicación de mejores prácticas y orientación basada en experiencias reales.

¿Qué hicimos y por qué?

Tenemos que hacer una confesión: Nos encanta Visual Studio y Visual Studio Team Foundation Server (TFS). Microsoft produce algunas de las mejores herramientas de desarrollo de software disponibles. No sólo estamos diciendo que porque trabajamos para Microsoft — nos sentimos este camino mucho antes de unirse a la compañía. Estas suites proporcionan un número increíble de características pero pueden ser intimidante para los nuevos usuarios. ¿Cómo los desarrolladores empezar a aprender a usar estas herramientas? Esta pregunta se presentó a nosotros de una manera ligeramente diferente.

ALM Rangers presente en las conferencias de TechReady que suelen tienen un número de sesiones que describe cómo mejorar el conocimiento de herramientas de desarrollo de Microsoft. Las conferencias incluso sostener sesiones interactivas donde los participantes pueden retroalimentar a los grupos internos de estos productos para la construcción. Encontramos a ser interesantes oportunidades para los desarrolladores y consultores. Después de unirse al equipo de ALM Rangers , comenzamos a explorar la orientación publicada y rápidamente di cuenta que había una gran cantidad de contenido para digerir; estábamos seguros de dónde comenzar a estudiar.

Lo que realmente queríamos era un recurso que nos ayude a ser competentes en ALM prácticas. Comenzó a construir la aplicación de ALM preparación tesoro mapa Windows Store para llevar a los usuarios a través de los materiales en su viaje para convertirse en expertos. Figura 1 muestra los resultados de nuestro trabajo. Contiene cinco categorías, cada una con múltiples temas de estudio:

1. Preparar
2. Rápida introducción
3. Dirección
4. Herramientas
5. Talleres

Figura 1 la aplicación del mapa de tesoro Windows Store

Estas áreas contienen guías, prácticas de laboratorio y vídeos para que sea más fácil posible para los usuarios para recoger las habilidades que necesitan rápidamente y con eficacia. Navegando por los materiales funciona especialmente bien en nuevos dispositivos táctil, como el Microsoft Surface.

Para ofrecer la experiencia óptima, recurrió a la ayuda de un experto diseñador UX y desarrolladores senior para construir la aplicación.

La solución ALM preparación tesoro mapa: UX diseño Nuggets

Hacer una buena primera impresión el azulejo de mapa del tesoro (ver figura 2) es llamativo y brillante, con un fondo naranja usado para simbolizar la arena. Inmediatamente, el usuario ve el tema de la aplicación, esto está claro debido a la palmera y el camino que lleva a donde "X" marca el lugar del tesoro. El título de la aplicación es claramente visible en la baldosa. Asegurándose de que el azulejo representa lo que su aplicación es realmente acerca de crea una buena primera impresión. Lo último que desea es para que los usuarios abrir su aplicación y ser confundido sobre por qué está usando y cómo les puede ayudar.

Figura 2 el azulejo de App Store de Windows de mapa de tesoro

Hemos aprovechamos la pantalla de bienvenida (ver figura 3) para mostrar un poco más de la personalidad de la aplicación y para ayudar a asegurar una experiencia buena presentación. Pantalla de bienvenida del mapa del tesoro representa un prolongado camino al tesoro, que es una experiencia de carga suave y pulido. Es ordenada y sencilla por diseño, reflejando cómo será el UX. Además, una única pantalla puede ayudar a reforzar la marca.

Figura 3 la pantalla de bienvenida de la App de tesoro mapa Windows Store

La Página principal — el mapa del tesoro, aparece una vez que ha cargado la aplicación. Una vez más, nuestro diseño claro, centrados en el contenido inmediatamente confirma el propósito de la aplicación. Hemos querido hacer esta página fantástica para que el usuario desea explorar el resto de la aplicación. La página es donde empieza el viaje y, en Resumen, el usuario sabe que esto va a ser un viaje. Los títulos son la fuente para la navegación, y debido a nuestro diseño "contenido en cromo", destacan. Contenido de la aplicación se acentúa mediante la eliminación de elementos no funcionales. Cualquiera que quiera para encontrar la información rápidamente puede encontrar todos los enlaces en la pantalla sin tener que navegar a través de la aplicación, que proporciona una gran experiencia para todo tipo de usuarios.

A veces se pasa por alto, pero Crucial la UI de Windows 8 utiliza el principio de un sistema de red a través de todas sus aplicaciones. Este principio promueve un diseño limpio y ordenado.

La aplicación del mapa del tesoro utiliza el sistema de rejilla en todas partes excepto en la Página principal y el resultado es que el contenido es altamente visible, más contenido, menos cromo. Este contenido sobre principio de cromo es uno de los principios más singulares del estilo app Store de Windows, donde la unidad visual contribuye a una gran UX. La página es la única página que es una excepción a esta regla. Nos estamos mostrando a un viaje y un tema de piratas que no habría podido alcanzar sin representaciones visuales.

A veces se olvida la tipografía y muchas personas no saben cuánto puede fortalecer la marca de la aplicación. Usando fuentes correctamente y constantemente ayuda a lograr claridad y da un aspecto limpio y ordenado que hace más fácil leer y por lo tanto, usar la aplicación. Las fuentes recomendadas son Segoe UI (principalmente usado para elementos de la interfaz de usuario como los botones), Calibri (utilizado para la lectura y la escritura, tales como en correos electrónicos) y Cambria (para grandes bloques de texto). Utilizamos Segoe UI para todo el texto que no sea de las cabeceras. Para aquellos, utilizamos Blackadder ITC para establecer un tema más fuerte (ver figura 4). Rompemos la regla de la fuente, porque queríamos aspecto de la aplicación para ser consistentes con un mapa en papel, como esto ayuda a reforzar el tema de piratas. Por lo tanto, en este caso, funciona bien.

Figura 4 la tipografía que usamos en la App Store de Windows de mapa de tesoro

Transparente y fluida navegación es crucial para proporcionar esa facilidad de uso y gran UX. Se recomiendan dos tipos de patrones de navegación: el sistema jerárquico y el plano (ver figura 5). El sistema jerárquico es el que usan la mayoría de aplicaciones. Es el más común y será el tipo más familiar de navegación para muchos usuarios. También es el mejor sistema para crear esa sensación fluida aún siendo fácil de usar. El sistema de plano se utiliza principalmente en juegos, navegadores o aplicaciones de creación de documentos, donde el usuario sólo puede ir hacia atrás y adelante en el mismo nivel jerárquico. La aplicación del mapa del tesoro utiliza el sistema jerárquico, y creemos que utiliza bien. La página se clasificarían como centro, y cada sección crea la primera rama jerárquica, desde donde cada sección entonces crea otra rama jerárquica. Por ejemplo, desde nuestra página web, el usuario puede navegar a la sección de preparación, donde el usuario puede explorar otras subdivisiones de la preparación.

Figura 5 patrones de navegación se recomienda

Usabilidad es importante evaluar la UX de la aplicación para mejorar el diseño para que la aplicación es:

• Fácil de usar
• Más valioso para los usuarios, por ejemplo, en las características puede ofrecer
• Más recomendable el uso

Evaluar su diseño le da confianza en que la aplicación tiene una excepcional UX y que los usuarios le resultará útil, utilizable y deseable.

Entonces, ¿cómo evaluamos la UX de la aplicación? Hay muchas maneras de hacer esto, pero dos más comunes son autoevaluaciones y tutoriales cognitiva, como se muestra en figura 6.

Figura 6 evaluar la UX de la aplicación

	Autoevaluación	Tutorial cognitivo
¿Por qué	Esto se basa en los objetivos que desea alcanzar o encontrar el usuario. Se asegura que el diseño está en camino con sus principales intenciones.	Esto es un poco más estructurado alrededor de las tareas específicas que un usuario podría desear cumplir, por ejemplo, para obtener más información sobre "herramientas de la fábrica VM y orientación".
Cuando	Es una buena idea hacer autoevaluaciones cada sprint, o cuando se ha logrado cada meta; duran hasta 30 minutos.	Durante el proceso de diseño y a través de cada sprint.

Hay cuatro indicadores de éxito que ayudarán en ambos la autoevaluación de la aplicación, así como el tutorial cognitivo de la aplicación. Estos son:

• Gran en: ¿Qué es la aplicación muy bueno? ¿Cuáles son los puntos focales de los efectos visuales?
• Usable: ¿Qué deberían los usuarios poder entender, saber o hacer más con éxito debido a la aplicación?
• Útil: ¿Qué quieren los usuarios al valor?
• Deseable: ¿Qué partes de la aplicación ¿desea las delicias de los usuarios o hacer el amor?

Utilizamos tanto las autoevaluaciones y tutoriales cognitivo. Las autoevaluaciones se llevó a cabo a través de cada sprint y revisadas en nuestros stand-ups semanales. Los tutoriales cognitivos se llevaron a cabo durante el proceso de diseño y a través de cada sprint. Evaluar la UX de nuestra aplicación nos ayudó a entender el deseo y la conexión emocional a experiencias que un usuario puede reconocer.

Resumiendo diseño UX:

• Asegúrese de que el azulejo representa lo que se trata su aplicación.
• Crear una pantalla de presentación única para reforzar su marca.
• Escriba el contenido con un claro enfoque.
• Utiliza la distribución de la red recomendados para crear un diseño simple y limpio.
• Don' t forget about tipografía. Utilice las fuentes recomendadas donde sea posible, como Segoe UI, Calibri o Cambria.
• Tienen un patrón de navegación clara. Elija entre el sistema jerárquico o el sistema plano.
• Evaluar la usabilidad de su aplicación durante todo el ciclo de desarrollo.

Las joyas de codificación

Antes de la codificación, establece una serie de metas para este proyecto de codificación. Estos objetivos se convirtió en la muletilla cómo diseñado y había desarrollado el código base.

• Adaptabilidad: Pueden cambiar los requisitos, características pueden ser añadidos o corte y diseños pueden desecharse a favor de algo completamente diferente. La adaptabilidad es el nombre del juego!
• Simplicidad: Simplicidad es esencial para muchas ventajas en el diseño de software, en particular para el mantenimiento y los íconos.
• Capacidad de prueba: Aseguramiento de la calidad debe ser una prioridad para cada proyecto, y debe permitir el código para la prueba integral y "simple".
• Rendimiento y fluidez: UX de la aplicación debe ser positiva desde el principio. La aplicación debe mostrar la información de manera oportuna, siempre se debe responder a la entrada del usuario y no debe retrasarse.
• Entornos de equipo: Raramente se construye una aplicación por un contribuyente individual o incluso un equipo individual. Nos aseguramos de que la aplicación fue construida de una manera que podría reducirse a muchos más miembros del equipo.

¿Así que ahora que hemos tenido nuestras metas definidas, cómo en el mundo logró escribir una aplicación en tan poco tiempo — trabajando tiempo parcial — no sólo satisfacer los requisitos funcionales, pero también nuestros requisitos no funcionales así? Por suerte para nosotros, esta rueda ha sido construida antes y la construcción de nuestra aplicación era una cuestión de aplicar patrones probados y prácticas a nuestra aplicación:

• C# y XAML: Decidimos utilizar C# y XAML, principalmente porque la mayoría de los contribuyentes en este proyecto está familiarizada con este enfoque. Esto incluye las lenguas propias así como las herramientas y apoyo para ellos.
• Modelo-View-ViewModel (MVVM): Este es un patrón para la separación de la capa de presentación de su lógica de negocio de los objetos. Elegimos este patrón particular porque el C# y tecnologías XAML se prestan muy bien a él. Pero más importante, con un solo patrón, pudimos comenzar a cincelar en nuestros requisitos no funcionales. Los objetivos que MVVM más positivamente afectado fueron testability, entornos de equipo, adaptabilidad y simplicidad. Adaptabilidad es mejor que usted puede intercambiar cualquiera de las piezas funcionales de su aplicación. Quizás haya finalizado una nueva presentación para un modelo particular de la vista, y al instante puede sustituirla sin cambiar cualquier otro código. Capacidad de prueba se mejora porque cada pieza funcional de la base del código se separa en sus responsabilidades individuales, los ensayos de medios puede ser escritos contra los directamente y automatizados. Entornos de equipo se mejoran porque tienes un conjunto definido de contratos entre las partes móviles de la aplicación, permitiendo que los equipos trabajen en paralelo uno con el otro. Simplicidad es mejorado en que cada parte móvil es su propia pieza móvil definida e interactúa en forma específica. Para obtener más información, consulte "' s New en Microsoft Test Manager 2012" en msdn.microsoft.com/magazine/jj618301.
• Recursos: Siguiendo el espíritu de MVVM y separación de funciones y piezas de repuesto, decidimos añadir recursos para la definición de nuestras fuentes, botones y otros elementos de diseño similar. Esto ayudó a mejorar ambientes de equipo, la sencillez y la adaptabilidad.
• Pero ¿qué hicimos sobre rendimiento y fluidez? Seguimos el patrón asincrónico/esperan para procesos de larga duración. Se trata de una de las zonas donde los desarrolladores podrían luchar en la construcción de aplicaciones Windows Store, pero no tiene que ser. Por suerte, aplicaciones de Windows Store usando C# y XAML son impulsados por Microsoft .NET Framework 4.5, que le permite incluir fácilmente las cargas de trabajo asincrónicos en su aplicación a través de este patrón. Si se hace tan fácilmente, ¿por qué amigos luchan con él? La respuesta a esta pregunta generalmente se reduce a utilizando la lógica que es larga y no siempre fuera de la caja por el .NET Framework. Un ejemplo de ello podría ser la lógica para calcular los puntos de trama para un gráfico basado en matemáticas complejas. A completo entendimiento de async y esperan es crucial para proporcionar una aplicación de fluidos y de alto rendimiento. Para obtener más información, consulte "Async Performance: Comprender los costos de Async y aguarda"en msdn.microsoft.com/magazine/hh456402.

Otras consideraciones incluidas:

• Lenguaje táctil: Desde una perspectiva de desarrollo, esto no podría ser más fácil. Casi cada control out-of-the-box soporta touch en todas las formas que usted espera. Desde una perspectiva de la codificación, esto era la parte más fácil de la aplicación para construir.
• Encantos: Interactuando con los encantos era simple así. Registrar en su appxmanifest y en el evento agregar controladores a cada página para los encantos específicos que desea registrar, como buscar o compartir. Hemos no tenido ningún problema con encantos. Trabajaron bien, como debe trabajar un encanto.
• Azulejos, salpicadura pantallas y orientaciones: Todos estos se manejaron en el appxmanifest y luego a través de ganchos del evento en la aplicación en el nivel de aplicación. Era sencillo, y todo se detalla en el código de ejemplo.

¿Cómo funcionó realmente aquí es cómo las cosas se elaboraron en la práctica:

• Comandos MVVM: MVVM fue fantástico en teoría. Sin embargo, en realidad, resultó un poco diferente de la habitual Windows Presentation Foundation (WPF) y el desarrollo de Silverlight, particularmente para la ejecución de comandos, porque nuestras muestras antiguas no funcionaba. Por suerte, comando <T> era bastante fácil de implementar en el nuevo marco y puede verse en nuestra aplicación de ejemplo. Pero las dificultades no terminan con los comandos, ya ListViewBase artículos no tienen una propiedad adjunta comando! Hemos decidido solucionar esto para demonstración de dos maneras:

En primer lugar, hemos decidido resolver este problema usando una propiedad no utilizada:

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

La propiedad que está encuadernado devuelve "null" y no lanzar excepciones (incluso si enciende todas las excepciones), por que es bonita, pero la clave está en el conjunto. En el conjunto, en lugar de establecer nada, hacemos una navegación llamar y pasar como parámetro el índice del elemento seleccionado.

En segundo lugar, hemos decidido crear una propiedad de dependencia adjunta de tipo ICommand. La aplicación de la muestra está en la clase "ItemClickCommand" dentro de la carpeta "MVVMSupport".

• Varios Estados de vista llevan a los archivos de vista masiva: Nuestros archivos de vista se convirtió en extremadamente grande y más difícil de manejar, principalmente debido a los múltiples Estados de vista. Un diseño diferente por el estado de vista generalmente se requiere, y aún podría tener diferentes puntos de vista para mostrar diferentes dimensiones o dimensiones cambiantes y así sucesivamente. Nuestro enfoque fue a separar para arriba en varios archivos .xaml, utilizando un archivo .xaml per view por estado. Por ejemplo, si tuviéramos una vista denominada "HomePageView", tendríamos "HomePageView.xaml" dentro de una carpeta completa, rotos y obturada, cada uno en la carpeta para su estado.
• Adaptación en el mundo real: Se trataba de una buena historia. Después de que habíamos desarrollado las grandes partes de nuestra aplicación — conmutación proveedores de datos, cambio de UIs y agregar nuevo encanto interacciones a todos los lugares apropiados, adaptándolo a las nuevas necesidades se convirtió en un pedazo de pastel. Temas eran fáciles de localizar, y gran parte de la planificación dado porque los diseñadores pueden trabajar en paralelo con los desarrolladores y los patrocinadores.

Resumiendo esta sección, desde un punto de vista de codificación, aplicaciones Windows Store son sencillos desarrollar adecuadamente. Siguiendo unas reglas predefinidas, mentalidades y patrones le permite crear rápidamente una buena aplicación. Las principales preocupaciones son el estado de vista de aplicación, estado del ciclo de vida de la aplicación, interacción de encanto, fluidez y asegurando que será usted el código de una manera que permite a su equipo de diseño iterar diseños en. Para obtener más información, consulte dev.windows.com.

Prueba y verificación de calidad de la solución

Uno de los requisitos de aceptación de base que definido desde el principio fue elevar la calidad de código de muestra y ser parte de nuestro programa de perro-fooding calidad general (ver aka.ms/df_tooling). Puertas de calidad para la geopolítica, espacio de nombres, análisis de código y StyleCop (ver stylecop.codeplex.com) cumplimiento nos ayudó a obtener una mejor solución, aunque sólo una muestra.

La prueba no debe ser una ocurrencia tardía y es tan importante con muestras como en soluciones de misión crítica. Es más fácil hacer cumplir la calidad del código y a administrar los requerimientos y las expectativas del usuario desde el principio, en lugar de enfrentarnos con cientos de errores de cumplimiento y probadores airadas y tienen que lidiar con característica y código mantequera durante un ciclo de mejoramiento de la calidad tardío.

Porque la intención era una solución de muestra rápida, adoptamos principalmente una "caja negra" que prueba la estrategia se centra en el comportamiento como parte de la aceptación de sistema y de usuario prueba (UAT). El primero fue realizado manualmente por el equipo, centrándose en las características esperadas y requisitos no funcionales y explorar el borde-casos donde los componentes internos eran entendidos. La comunidad fue invitada para asistir con la validación de la UAT, realizando pruebas exploratorias basan en escenarios reales y expectativas y errores de desenterrar y características faltantes, prácticas y claras.

Como se muestra en figura 7 (con los números aquí corresponden a los números en un círculo rojo en la figura), normalmente usamos la función prueba exploratoria de Microsoft Test Manager (1) y el simulador (2) para evaluar la solución de la muestra en un dispositivo de tipo superficie, capturado comentarios detallados (3) y grabó la sesión de prueba (4) para referencia futura.

Figura 7 pruebas exploratorias

En el futuro, a considerar seriamente la definición de casos de prueba más estructurado y el uso de Microsoft Fakes para ayudarnos a implementar la unidad y el humo de la prueba. Esto permitirá automáticamente y continuamente cambios de función de validar y asociados a cambios en el código.

¿Qué sigue?

Evolucionará la aplicación del mapa del Tesoro de preparación ALM, y estamos considerando una función de actualización en línea para los activos de referencia de la preparación. Para obtener más información, consulte "bajo­el Visual StudioALM Rangersde pie" en aka.ms/vsarunderstand; Visual Studio ALM Ranger Solutions"en aka.ms/vsarsolutions; el código de ejemplo de mapa del tesoro ALM preparación en aka.ms/almtreasure; y la aplicación en la tienda de Windows en aka.ms/vsartmapapp. Acogemos con satisfacción su sincero e ideas!

Anisha Pindoria es Consultor Desarrollador UX de Microsoft Consulting Services en el Reino Unido.

Dave Crook es consultor desarrollador de Microsoft Consulting Services región Oriente, donde su enfoque es el Visual Studio y Team Foundation Server.

Robert Bernstein es un programador senior con el Microsoft Consulting Services en todo el mundo Sector público Cyber Seguridad equipo.

Robert MacLean es un desarrollador de software ubicado en una oficina de desarrollo típico de planta abierta en BBD (bbd.co.za).

Willy -Peter Schaub es un gestor senior del programa con los Visual Studio ALM Rangers en el Canadá Development Center de Microsoft.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Patricia Wagner (Microsoft)