Ingénierie d'espace de travail
Considérez l'espace de travail comme un produit destiné à la personne qui l'utilise. Concevez le processus qui rend le travail utile reproductible, pas seulement l'invite qui donne un bon résultat.
La question centrale : Qu'est-ce que cette personne doit encore mémoriser, réparer ou expliquer que l'espace de travail devrait gérer ?
Le cas d'usage principal est l'écriture de code avec des agents. Proposez activement un processus de développement, y compris ce qui manque dans l'espace de travail actuel ; ne vous arrêtez pas à décrire les instructions existantes. Pour les rôles non techniques, adaptez les mêmes principes de feedback et d'acceptation à leurs livrables.
1. Établir la tâche
Déduisez le mode demandé à partir des mots de l'utilisateur :
- Revue : inspectez le processus actuel, expliquez les lacunes et recommandez des améliorations. Laissez l'implémentation inchangée.
- Construire ou améliorer : implémentez le périmètre demandé, y compris la validation et une remise en état utilisable. Une demande de construction autorise déjà l'implémentation réversible ordinaire ; n'ajoutez pas de cérémonie d'approbation de plan.
Commencez par la preuve qui existe : dépôt, document de processus ou récit de l'utilisateur. Un dépôt n'est pas nécessaire pour la découverte du processus. Lisez les instructions applicables du dépôt avant d'inspecter l'implémentation ou d'exécuter des commandes. Inspectez les scripts de configuration avant de les exécuter. Préservez le travail existant et suivez la disposition canonique des compétences/instructions de la cible.
Identifiez le rôle principal, la tâche récurrente, le résultat acceptable, la douleur actuelle et les décisions humaines. Utilisez discovery pour les entretiens, les documents de processus ou les responsabilités floues. Lisez d'abord le matériel disponible, puis posez uniquement les questions dont les réponses modifient la conception. Continuez le travail indépendant en attendant ; n'inventez pas une réponse manquante.
2. Tracer une tâche complète
Choisissez une demande représentative et suivez-la de la réception à l'exécution, la validation, la remise et la récupération. Incluez un échec ou une correction si des preuves existent. Pour les revues larges, échantillonnez chaque workflow sensiblement différent plutôt que de prétendre qu'un seul échantillon couvre tout.
Enregistrez ce que l'utilisateur fait, ce que l'agent fait, quels outils agissent, quel état est sauvegardé et ce qui prouve l'achèvement. Comparez la pratique prévue avec l'implémentation et le comportement observé. Gardez ces étiquettes de preuve distinctes :
- Documenté : une règle ou un processus dit que cela devrait se produire.
- Implémenté : un mécanisme concret existe et est intégré au chemin.
- Observé : une exécution démontre le comportement pour une révision ou un artefact nommé.
- Inconnu : la preuve ou l'accès manque. Ce n'est pas une preuve d'absence.
Utilisez review pour examiner le chemin et prioriser les résultats. Un test vert est une preuve de ce qu'il a affirmé, pas de chaque affirmation qui lui est attachée.
3. Concevoir l'amélioration
Lisez le processus de base en mode revue et construction. Utilisez ses valeurs par défaut de développement logiciel, sauf si la tâche est non technique, auquel cas utilisez ses directives d'adaptation. Pour les espaces de travail mixtes, appliquez la base de codage au code et aux aides même si l'utilisateur final est non technique.
Rendez le processus proposé concret : déclencheur, étapes, commandes ou outils, critères de succès/échec, réponse en cas d'échec, propriétaire et preuve d'achèvement. Mappez chaque élément applicable de la base à un mécanisme existant, un changement recommandé, une exception explicite ou un inconnu. Expliquez les écarts matériels ; n'omettez pas silencieusement une pratique manquante parce que le dépôt ne l'a jamais eue. Préservez les exigences existantes plus strictes.
Regroupez les symptômes par leur cause sous-jacente. Préférez un utilitaire partagé, une meilleure entrée, un contrat d'outil plus clair ou une procédure plus courte à l'ajout d'un autre avertissement que l'agent doit mémoriser. Supprimez les instructions et vérifications redondantes uniquement lorsque leur objectif est préservé ailleurs.
Pour chaque changement proposé, précisez :
| Champ | Réponse |
|---|---|
| Problème utilisateur | Qu'est-ce qui ralentit, échoue ou nécessite une explication répétée ? |
| Preuve | Quel fichier, étape de processus, incident ou exécution soutient la conclusion ? |
| Changement | Que fera l'espace de travail différemment ? |
| Placement | Connaissance, compétence, règle, outil, vérification locale, passerelle distante ou décision humaine ? |
| Preuve de réussite | Comment saurons-nous que le changement fonctionne, y compris un cas d'échec pertinent ? |
| Compromis et propriétaire | Qu'est-ce que cela coûte à exécuter ou à maintenir, et qui peut modifier la politique ? |
Priorisez par impact utilisateur, récurrence, confiance, effort et délai de feedback. Commencez par les quelques changements qui valent la peine d'être faits en premier, pas par un score ou une pile de modèles. Utilisez patterns lorsqu'un exemple concret ou une disposition d'espace de travail serait utile.
4. Revoir ou implémenter
Pour une revue, livrez le processus actuel en bref, le processus de travail proposé, les résultats priorisés avec preuves et la prochaine étape utile. Préservez les mécanismes existants solides et indiquez ce qui n'a pas pu être vérifié. Une revue uniquement documentaire du processus doit distinguer les contrôles proposés des contrôles connus pour exister.
Pour une construction ou amélioration, utilisez build. Implémentez le périmètre autorisé de bout en bout. Si l'utilisateur souhaite un nouvel espace de travail mais que le rôle ou le livrable est encore inconnu, résolvez cela avant de choisir la pile. Ne transformez pas chaque problème de processus en un projet logiciel.
5. Boucler la boucle
Rapportez ce qui a changé ou a été recommandé, en quoi cela aide le rôle, ce qui a été effectivement vérifié et ce qui reste dépendant de l'accès ou du jugement humain. Pour l'implémentation, laissez une façon claire de démarrer le workflow et une façon d'exécuter ses vérifications.
Gardez les limites opérationnelles explicites :
- Ne faites jamais passer un contrôle échoué en affaiblissant le critère, en contournant le crochet ou en acceptant des preuves manquantes. Un changement de politique légitime doit être identifié séparément et autorisé par son propriétaire.
- Préservez l'autorisation déjà donnée ; distinguez une construction locale de la dépense de crédits, de la publication ou de la modification de systèmes en production. Résolvez l'autorisation uniquement pour une action qui en a réellement besoin.
- Ne prescrivez pas la fusion automatique, l'absence de revue de code, un pourcentage de couverture fixe, le développement piloté par les tests ou un système CI particulier comme définition d'un espace de travail.
- Gardez les secrets et les détails de source privée hors des instructions réutilisables. Lorsque le matériel source est privé, extrayez le modèle avec des exemples neutres.