Concepteurs et développeurs travaillant ensemble [fermé]

Question

Les riches capacités de présentation de WPF et Silverlight signifient que les développeurs comme moi travailleront plus souvent en étroite collaboration avec des graphistes ces jours-ci, comme c'est le cas dans mon prochain projet.

Quelqu'un a-t-il des conseils et une expérience (des deux points de vue) pour que cela se déroule plus facilement ?

Par exemple, lorsque j'ai récemment mentionné le contrôle de source à un concepteur, on m'a rapidement dit que vous ne pouviez pas contrôler de source les graphiques, les images, etc., c'était donc une perte de temps.J'ai donc répondu :ok mais qu'en est-il des fichiers XAML dans WPF/Silverlight ?

Scott Hanselman a parlé de ce sujet dans un podcast, mais il s'est davantage concentré sur les outils, alors que je m'intéresse davantage aux enjeux/aspects de la communication.

Answer 1

J'ai passé 4 mois sur un projet en travaillant en étroite collaboration avec un concepteur et il n'a toujours pas compris l'idée de base de CVS (qui n'est pas mon choix de système de contrôle de code source).Je parle ici de fichiers modèles, JavaScript et CSS.Il n'est pas stupide, c'est juste une de ces choses qui rend son travail plus difficile, alors il résiste à s'y engager pleinement.

Dans mon cas, j'ai dû vraiment insister sur le fait que presque tout mon JavaScript dépendait du balisage et quand il a changé sa mise en page pure CSS, basée sur DIV en une mise en page basée sur un tableau sans me le dire, alors tout mon JS va casser.

Souvent, au cours du projet, moi-même et le designer, avec qui je m'entends plutôt bien et avec qui je joue au football en dehors du travail, avons eu des échanges très animés sur nos responsabilités respectives.Si je ne le connaissais pas suffisamment pour dépasser ces échanges, je pense que cela aurait créé un environnement de travail insupportable.Je pense donc qu'il est important que vous établissiez entre vous deux et avec une sorte de manager ou de superviseur de projet exactement ce que l'on attend des deux parties pendant le projet.

Dans mon cas, il y a eu très peu de problèmes ces derniers temps, car la situation avec CVS ​​a été réglée ainsi que l'idée qu'il ne peut pas simplement modifier le balisage quand il en a envie.Plutôt que d'essayer de créer des fichiers modèles et de travailler dessus directement, le concepteur ne travaille que sur des fichiers statiques et il est de ma responsabilité de les connecter à mes fichiers modèles.

Tout est question de communication et d'un peu de compromis des deux côtés.

Answer 2

L'une des choses que j'ai découvertes est que la façon dont vous, en tant que développeur, concevez votre code affecte grandement ce que le concepteur peut en faire.Souvent, vous téléchargez un exemple d'application Silverlight ou WPF à partir du Web et l'ouvrez dans Blend, juste pour que Blend plante sur vous car le code ne fonctionne pas bien dans le concepteur.S'il ne plante pas, il ressemble rarement à l'application en cours d'exécution.

J'ai récemment donné une conférence à Tech Ed Australia et en Nouvelle-Zélande sur les techniques que vous pouvez appliquer à la « conception pour la conception ».Une courte liste bullée est incluse :

1. Écrivez du code qui peut tirer parti de la liaison de données.Le Model-View-ViewModel ou le modèle de présentation convient parfaitement à cela.

2. Fournissez des talons « heure de conception » pour vos dépendances de service.Si la classe avec laquelle vous effectuez une liaison effectue des appels de service Web, assurez-vous de remplacer le client du service Web par une classe stub qui renvoie des « données factices » que le concepteur consomme dans Blend.Cela peut facilement être fait via IoC et Dependency Injection, en injectant une implémentation si HtmlPage.IsEnabled == false.

3. En utilisant la liaison de données, vous pouvez limiter le nombre d'« éléments nommés » que vous avez dans votre fichier XAML.Si vous écrivez beaucoup de code derrière, vous finissez par coupler votre code C# avec des éléments nommés tels que txtName ou txtAddress, ce qui permet au concepteur de "bousiller" facilement.

4. Utilisez un modèle de commande au lieu du code derrière les gestionnaires d'événements de clic.En couplant vaguement l'invocateur d'un événement à partir du gestionnaire, vous pouvez avoir moins d'éléments nommés et vous donnez au concepteur la liberté de choisir entre un bouton ou un élément de menu pour appeler une commande spécifique.

5. Testez votre code dans Blend !Même si vous vous considérez comme un pur développeur, vous devez vérifier que votre code est consommable par un outil et vous efforcer d'obtenir la meilleure expérience possible au moment de la conception.Certains diront qu'un outil ne devrait pas affecter la conception de votre logiciel, tout comme certains se plaignent de la "conception pour la testabilité" et de la prise de décisions de conception de logiciel uniquement pour rendre le code plus testable.Je pense que c'est une chose intelligente à faire, et c'est la seule façon de lancer un véritable flux de travail concepteur-développeur.

D’autres conseils seraient de commencer petit.Si votre concepteur est nouveau dans XAML, WPF et Silverlight, commencez par le présenter à l'équipe du projet et demandez-lui de réaliser quelques conceptions de base avec les outils qu'il connaît.Laissez-les créer des boutons et des illustrations dans Adobe Illustrator, exportez-les vers XAML et montrez-leur comment vous pouvez exploiter directement leurs ressources de conception.Continuez en en introduisant de plus en plus, et j'espère qu'ils seront intéressés et voudront passer à Blend.C'est toute une courbe d'apprentissage, mais cela en vaut vraiment la peine !

Bonne chance!

PS :J'ai beaucoup écrit sur les modèles et la création de code convivial pour les concepteurs sur mon blog à l'adresse http://jonas.follesoe.no.Vous pouvez également trouver des liens vers un enregistrement vidéo de ma conférence Tech Ed, ainsi que de nombreux liens vers des lectures plus approfondies sur le sujet.

Answer 3

C'est peut-être un peu hors sujet (je réponds spécifiquement à votre question sur le contrôle de source et les graphiques), mais vous peut mettre des données binaires (images, etc.) dans le contrôle de source (et à mon avis, dans de nombreux cas, cela devrait) - elles occupent simplement plus d'espace disque et vous ne pouvez pas utiliser une vue différentielle pour analyser ce qui a changé de manière significative , mais ce que vous obtenez, c'est un historique des messages de validation documentant chaque révision, la possibilité de restauration et la possibilité d'archiver facilement (marquer une révision en termes SVN), tous les fichiers (qu'il s'agisse d'actifs visuels, de documentation, de code source, etc.) appartenant ensemble à une version/version spécifique.Il est également plus facile pour votre système de build de récupérer tout ce qui est nécessaire à la création d'une version spécifique de votre logiciel à partir du contrôle de code source.

Answer 4

Impliquer le graphiste dans les premières séances de conception et d’architecture.

Vous souhaitez les impliquer pour révéler des hypothèses mal alignées et établir un modèle de collaboration plutôt que de jeter des choses par-dessus le mur.

Answer 5

À l'origine, il était envisagé que les concepteurs professionnels travailleraient dans Expression Blend et que les développeurs travailleraient dans Visual Studio, apportant des modifications à un seul ensemble partagé de fichiers sources.Bien qu'il soit certainement possible de le faire (à condition que vous veilliez à vérifier régulièrement que vous n'avez pas cassé quelque chose attendu par l'autre développeur.ou outil de conception), de nombreux membres de la communauté des développeurs, y compris certains au sein de Microsoft, ont découvert les avantages de garder l'activité des projets Blend et Visual Studio SÉPARÉES - au point même de couper et coller manuellement des versions soigneusement refactorisées de Xaml généré par Blend dans la source "officielle" du projet VStudio, plutôt que de permettre aux concepteurs et aux développeurs d'opérer directement sur une seule base de code partagée.L'équipe d'expérience utilisateur de Microsoft au Royaume-Uni a publié une vidéo décrivant les problèmes rencontrés en essayant de coordonner les efforts des concepteurs et des développeurs sur des projets réels.

Real_World_WPF_DesignersAndDevelopersWorkingTogether

L'une des principales leçons apprises est que vous ne pouvez pas confier un projet à des concepteurs et des développeurs qui ignorent complètement les domaines de chacun.Les développeurs doivent être suffisamment familiers avec Blend pour pouvoir fournir aux concepteurs des shells d'interface utilisateur utiles que le concepteur peut décorer, ainsi que des « stubs » de données utiles sur lesquels le concepteur peut concevoir l'interactivité, et le concepteur doit avoir une compréhension suffisante des problèmes de développement qu'ils ne connaissent pas. Je ne fais pas des choses comme supprimer des contrôles et les remplacer par des éléments visuels personnalisés - sans me rendre compte qu'ils ont cassé toutes les fonctionnalités liées au contrôle d'origine.

Answer 6

La vision de Microsoft du mariage du workflow concepteur/développeur semble définitivement s'effondrer dans la vraie vie.J'ai de l'expérience de travail sur un projet WPF à assez grande échelle qui impliquait 2 ressources de conception dédiées pendant environ 4 mois.Voici quelques faits que Microsoft semble souvent oublier.

• Les designers préfèrent souvent utiliser des Mac (les designers de mon entreprise sont 100 % Mac - 0 % Windows)
• Blend ne fonctionne pas sur Mac (en ce qui concerne les solutions VM - les concepteurs n'aiment généralement pas les solutions geek comme exécuter des applications étranges dans un système d'exploitation étranger).
• Les designers utilisent leurs outils professionnels - Photoshop et Illustrator.Période.
• L'agressivité des horaires actuels ne laisse généralement pas suffisamment de temps aux concepteurs pour apprendre un tout nouvel environnement d'application/de conception (comme Blend).

Compte tenu de ce qui précède, ce que j'ai remarqué, c'est que cela crée un nouveau type de travail : soit un concepteur très technique, soit un programmeur graphiquement éclairé.Fondamentalement, quelqu'un qui peut prendre les éléments de conception sous forme brute - généralement au format .psd ou illustrateur et les appliquer selon les besoins au processus de candidature.

Je me suis avéré être ce type (programmeur graphiquement éclairé).J'ai passé beaucoup de temps à exporter du XAML à partir de fichiers Illustrator, à les nettoyer à la main si nécessaire et à rendre ces actifs facilement utilisables comme objets d'affichage dans Blend ou VS.Il y avait aussi des moments où je prenais un élément de conception et le redessinais en utilisant Blend (généralement lorsque l'élément d'origine était basé sur un bitmap et qu'il était plus logique de le convertir en vecteur).

Mon application n'était peut-être pas typique - car elle était extrêmement riche graphiquement et l'indépendance de la résolution était l'un des principaux objectifs car elle devait avoir une belle apparence sur plusieurs résolutions et formats d'image (pensez aux difficultés de conception pour la télévision dans le paysage actuel - les choses ont pour avoir une belle apparence à la fois en SD basse résolution et bien évoluer en HD haute résolution).

En résumé, je pense que WPF est une technologie géniale et constitue absolument un pas dans la bonne direction pour Microsoft.Ce n'est cependant pas la solution ultime pour intégrer le concepteur dans le processus de développement - à moins de redéfinir le rôle du concepteur.

Answer 7

Je m'appelle Felix Corke, le concepteur du podcast Hanselman que vous avez mentionné. Voici donc quelques points d'un véritable créatif plutôt que d'un développeur.

Il a fallu beaucoup de temps pour s'habituer aux outils de développement - je n'avais jamais entendu parler de Visual Studio, de C# ou de tout autre type de contrôle de source lorsque j'ai commencé à travailler sur Xaml il y a quelques années.Ils m’étaient aussi étrangers qu’Illustrator ou 3DsMax le seraient peut-être pour vous.

Mon point le plus important est que l'on ne peut pas s'attendre à ce que le concepteur connaisse les pratiques des développeurs - soyez prêt à faire beaucoup de travail de main.Vous n'aurez rien à apprendre de nouveau tandis que le concepteur sera lancé dans un tout nouveau côté effrayant du développement d'applications.J'ai fait un vrai gâchis avec quelques solutions et enregistrements (et je le fais toujours).

Heureusement, j'ai appris à devenir davantage un intégrateur axé sur le design qu'un simple créatif, et c'est peut-être un rôle que vous devez inclure dans votre projet.C'est l'illustration que j'ai réalisée pour notre session beauté et geek - designer/développeur chez Mix - si l'un de vous est trop loin à l'une ou l'autre extrémité du spectre, il peut être difficile de comprendre comment l'autre fonctionne et quel devrait être son rôle.

Heureux de répondre à toutes vos questions spécifiques !

ps, vous ne voulez PAS de fichiers .psd de plus de 100 Mo dans le contrôle de source ;)

Answer 8

Je crois fermement à l'approche intégrateur, qui est vraiment le rôle que j'ai dû jouer pour que nos efforts WPF soient couronnés de succès.

Laurent Bugnion a un poste sur ceci qui décrit de quoi je parle. Robby Ingebretsen est également un grand partisan de cette approche.

Mais fondamentalement, quelqu'un doit combler le « fossé » qui existe entre le monde des développeurs et celui des concepteurs.Ce qui arrive généralement, c'est que cette personne vient soit du monde des développeurs, soit du monde des designers.S'ils viennent du monde des développeurs, il s'agit probablement d'un développeur avec des tendances designer (ils sont responsables de l'apparence, des visuels de l'application, de la disposition des écrans, etc.).S'ils viennent du monde du design, alors ils n'ont pas peur du code et aiment se plonger de temps en temps dans le code pour obtenir cette animation ou autre chose scintillante.

Cependant, quel que soit le monde d’où ils viennent, ils doivent généralement acquérir des compétences qu’ils n’avaient jamais acquises auparavant.Dans mon cas, je suis un développeur qui aime la couche d'interface utilisateur et je dirais donc que je suis un développeur avec des tendances de concepteur.Afin de combler cette lacune et d'avoir des conversations productives avec notre graphiste, j'ai dû acquérir tout un tas de compétences de type designer telles que :apprendre à utiliser Expression Design, XAM 3D, etc.

Shannon Braun a récemment fait une présentation lors d'une conférence locale des développeurs sur la relation développeur/concepteur et les flux de travail qui, selon la communauté, fonctionnent pour eux.Je n'ai pas assisté à la conférence, mais je pensais que son diapositives ont eu une grande discussion sur le sujet.

Answer 9

La mesure dans laquelle les concepteurs se sentent en droit d'être éloignés de l'ensemble du travail impliqué dans la construction d'un produit logiciel est un problème bien plus important qui doit être résolu.Ne vous contentez pas du droit exprimé d'un designer de ne pas avoir à savoir comment son travail s'intègre dans l'ensemble.

Le type de spécialisation poussée qui s'est développée au sein de la communauté des concepteurs constitue l'un des plus gros problèmes de maturité industrielle auquel est confronté le secteur du développement de logiciels.Il s'agit d'un degré de spécialisation qui entraîne, comme on pouvait s'y attendre, davantage de retouches et des temps de cycle plus longs.

Cela est également vrai du sentiment de droit des développeurs d'ignorer complètement la conception et la mise en œuvre des interactions.

Une spécialisation extrême est toujours un multiplicateur exponentiel des problèmes de productivité.Résolvez-le sur le plan organisationnel en adoptant des processus qui favorisent les cultures d’apprentissage.C’est le niveau de maturité que la plupart des autres industries de production ont déjà atteint, et que les logiciels traînent terriblement derrière.

À chaque endroit d'un flux de travail de développement où des transferts se produisent entre la surspécialisation, des files d'attente de travail et des tampons se forment.Le logiciel reste l'une des rares industries à ne pas reconnaître qu'il s'agit de l'un des plus gros problèmes auxquels nous sommes confrontés.Ceci est encore plus exacerbé dans la communauté Microsoft, car la surspécialisation semble de plus en plus normale en raison de la perpétuation par Microsoft de cette surspécialisation à travers ses outils et ses conseils.À moins que vous ne puissiez vous permettre de gaspiller autant d’argent que Microsoft dans les efforts de développement, vous devriez vous tourner vers des méthodologies bien mieux informées sur les questions de flux et de productivité.

Par conséquent, le développeur qui ne sait pas tester et le testeur qui ne sait pas coder sont le symptôme de la même immaturité industrielle.

Vous n'apprendrez rien de tout cela à partir du modèle Scrum pour TFS.Microsoft a pris des années de retard pour mettre en œuvre la pensée agile, même dans ses formes les plus rudimentaires, et maintenant que nous progressons vers la pensée Lean, Microsoft aura encore trois à cinq ans avant d'essayer d'incorporer la pensée Lean dans ses gammes de produits. .N'attendez pas que Microsoft vous explique comment constituer une équipe et un flux de travail.Vous pouvez apprendre dès maintenant des personnes auxquelles Microsoft prêtera finalement attention dans quelques années.

Answer 10

D'après mon expérience, le rôle d'intégrateur ou de « développeur » doit vraiment être impliqué dans ce processus, à moins que tous les membres de la (petite) équipe soient capables de jouer ce rôle.Il s'agit d'une circonstance très rare.Habituellement, vous constaterez que les développeurs sont très bons en développement mais ne sont pas aussi bons en conception/utilisabilité et que les concepteurs sont excellents en esthétique/utilisabilité mais ne veulent pas ou ne sont pas suffisamment formés pour coder.Avoir quelqu'un qui peut traverser les deux mondes et « parler la langue » est très important.

L'intégrateur doit coordonner les contrôles en cours de développement avec les ressources de conception créées par les concepteurs.Dans notre projet actuel, nous avons 6 développeurs actifs et 2 designers issus d'un atelier extérieur.Je suis l'intégrateur de ce projet et je passe la majeure partie de ma journée dans Expression Blend.Les développeurs travaillent principalement dans VS en créant des contrôles qui répondent à nos spécifications de produit et l'atelier de conception conçoit à quoi ressemblera le produit final.Les designers travaillent dans Illustrator.Mon travail consiste à prendre les fichiers Illustrator et à créer des styles de contrôle à partir d'eux, puis à les appliquer aux contrôles développés par notre équipe de développement.À mesure que nous évoluons vers Blend 3 avec prise en charge native des fichiers PSD et AI, cette tâche devient beaucoup plus facile.

Il est très utile de créer le « look » de votre application dans une solution distincte du tronc principal de l'application, puis de fusionner ultérieurement vos ResourceDictionaries dans l'application principale.Vous pouvez obtenir une apparence et une sensation correctes sans trop vous laisser prendre par des contrôles qui pourraient encore être incomplets.

Answer 11

Je vais supposer que vous faites référence aux projets RIA depuis votre mention de SL.

J'ai travaillé sur plusieurs projets RIA avec Adobe en concevant et en développant des applications et des services.

Le meilleur conseil que je puisse vous donner est basé sur mes 14 années d'expérience en tant que concepteur UX et visuel avec une certaine expérience en programmation bien que pathétique par rapport à vous.

Acceptez le fait que vous ne vous comprendrez pas.

Le programmeur réfléchit quoi la fonctionnalité doit être réalisée, le concepteur réfléchit comment la fonctionnalité doit se comporter.

Pour le développeur, un bouton est généralement générique, pour le concepteur, ce n'est pas le cas.Les designers pensent en composition, les développeurs pensent en frameworks.

Apprenez donc à comprendre que votre responsabilité est différente.

En tant que développeur, vous devez réfléchir au caractère générique de votre code et vous ne pouvez pas vous permettre de tout traiter comme étant unique et une composition codée en dur.Sauf si vous pouvez automatiser ce caractère unique d’une manière ou d’une autre.

Le concepteur DOIT considérer l’application ou le service comme étant unique en quelque sorte.Cela pourrait vouloir dire qu’un bouton n’est pas un bouton.Il peut y avoir différentes tailles, couleurs ou autres désagréments.

Assurez-vous donc de développer une bonne relation avec le designer en reconnaissant que vous comprenez la responsabilité du concepteur et assurez-vous qu'il comprend la vôtre.

Ce n’est pas que vous ne souhaitiez pas créer la meilleure application au monde.C'est juste que certaines de ces décisions de conception prennent beaucoup de temps.

Assurez-vous d'être très clair sur la manière dont le concepteur doit vous livrer afin de ne pas perdre son temps.Quel format, des atouts ?Appellation?

Tout ce qui est impliqué dans la transmission d'un paradigme à un autre.

Et surtout, communiquez et respectez le fait qu'ils ne savent pas comment utiliser JavaScript ou comprendre les idées de base de CVS.

La plupart des développeurs ne sauraient pas comment créer un crénage pour sauver leur vie, ce qu'est une veuve, comment superposer FireWorks ou créer une icône photo-réaliste, trouver un bon slogan ou faire quelque chose de compréhensible pour Joe moyen en 4 mots.Vous ne savez pas ce qu'est une grille ou un alignement et vous avez tendance à rendre les choses vertes et violettes sur du noir.

Et le concepteur doit comprendre que ce n'est pas parce qu'il s'occupe de programmation qu'il est un robot, qu'il ne peut pas avoir d'idées et de solutions créatives.Il devrait également essayer d'apprendre à programmer au moins un pseudo-programme afin de comprendre ce qu'implique la réalisation de votre projet.

Et, surtout.Ne commencez pas à débattre de Mac contre.PC :) Des projets ont été annulés à cause de cela.

Answer 12

Franchement, vous devriez dire au concepteur que les images peuvent, devraient et "seront placées dans le contrôle source Mister!" :)

Cela peut être légèrement non conventionnel et vous ne pourrez pas faire de fusion ou quoi que ce soit de ce genre, mais il y aura des révisions et un historique, etc.Les images peuvent également être intégrées dans un fichier de ressources qui entre également dans le contrôle de code source.

XAML peut (et doit) être placé dans le contrôle de code source et, en tant que fichier de balisage, il bénéficiera de toutes les fonctionnalités.

En ce qui concerne les conseils pour travailler avec un designer, celui avec lequel vous travaillez me fait vraiment peur rien que par ce seul commentaire, donc tout peut se résumer à QUI vous travaillez.J'expliquerais les meilleures pratiques de base de manière agréable et je procéderais à partir de là.