From 6c1b35062f6fed84284f18eed968bf0b1812b3b2 Mon Sep 17 00:00:00 2001 From: Jayson McIntosh Date: Tue, 3 Aug 2021 15:09:47 -0400 Subject: [PATCH 01/21] Typo (alongide -> alongside) --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f9fa8a2..7d6e339 100644 --- a/README.md +++ b/README.md @@ -102,7 +102,7 @@ Many organisations find that running team assessments **every 3 months** provide * [Testing and Testability - assessment sheet](print/print-testability.md) * [Reliability and SRE - assessment sheet](print/print-reliability.md) * [On-call - assessment sheet](print/print-on-call.md) -4. For **online sessions**, show the _Tired_ and _Inspired_ criteria on the screen alongide the question. For **in-person sessions**, either print the details pages as a guide or have the pages open on-screen to understand the context and details of each of the assessment criteria: +4. For **online sessions**, show the _Tired_ and _Inspired_ criteria on the screen alongside the question. For **in-person sessions**, either print the details pages as a guide or have the pages open on-screen to understand the context and details of each of the assessment criteria: 1. [Team Health](team-health.md) 2. [Deployment](deployment.md) 3. [Flow](flow.md) From 931efcac97154cc986563e4a6917dd12bc7a9364 Mon Sep 17 00:00:00 2001 From: Jayson McIntosh Date: Tue, 3 Aug 2021 15:14:34 -0400 Subject: [PATCH 02/21] Typo (healthcheck -> health check) I think the intent was health check (as in, "health checkup") rather than healthcheck (or HealthCheck), which seems to be the name of a few products. --- operability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/operability.md b/operability.md index 1ebc002..cc4fcc4 100644 --- a/operability.md +++ b/operability.md @@ -20,7 +20,7 @@ Method: Use the [*Spotify Squad Health Check*](https://labs.spotify.com/2014/0 | 2\. **Spend on operability** - What proportion of product budget and team effort is spent addressing operational aspects? How do you track this? \[Ignore infrastructure costs and focus on team effort\] | We try to spend as little time and effort as possible on operational aspects / We do not track the spend on operational aspects at all | We spend around 30% of our time and budget addressing operational aspects and raise an alert if focus on operational aspects drops | | 3\. **Feature Toggles** - How do we know which feature toggles (feature switches) are active for this subsystem? | We need to run diffs against config files to determine which feature toggles are active | We have a simple UI or API to report the active/inactive feature flags in an environment | | 4\. **Config deployment** - How do we deploy a configuration change without redeploying the software? | We cannot deploy a configuration change without deploying the software or causing an outage | We simply run a config deployment separately from the software / We deploy config together with the software without an outage | -| 5\. **System health** - How do we know that the system is healthy (or unhealthy)? | We wait for checks made manually by another team to tell us if our software is healthy | We query the software using a standard HTTP healthcheck URL, returning HTTP 200/500, etc. based on logic that we write in the code, and with synthetic transaction monitoring for key scenarios | +| 5\. **System health** - How do we know that the system is healthy (or unhealthy)? | We wait for checks made manually by another team to tell us if our software is healthy | We query the software using a standard HTTP health check URL, returning HTTP 200/500, etc. based on logic that we write in the code, and with synthetic transaction monitoring for key scenarios | | 6\. **Service KPIs** - How do we track the main service/system Key Performance Indicators (KPIs)? What are the KPIs? | We do not have service KPIs defined | We use logging and/or time series metrics to emit service KPIs that are picked up by a dashboard | | 7\. **Logging working** - How do we know that logging is working correctly? | We do not test if logging is working | We test that logging is working using BDD feature tests that search for specific log message strings after a particular application behaviour is executed and we can see logs appear correctly in the central log aggregation/search system | | 8\. **Testability** - How do we show that the software system is easy to test? What do we provide and to whom? | We do not explicitly aim to make our software easily testable | We run clients and external test packs against all parts of our software within our deployment pipeline | From effe127056c433a5d3e0d1185f5de6732b73bfca Mon Sep 17 00:00:00 2001 From: Jayson McIntosh Date: Tue, 3 Aug 2021 15:16:36 -0400 Subject: [PATCH 03/21] Typo (availabillity ==> availability) --- reliability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/reliability.md b/reliability.md index 59242d2..68772c2 100644 --- a/reliability.md +++ b/reliability.md @@ -25,8 +25,8 @@ Method: Use the [*Spotify Squad Health Check*](https://labs.spotify.com/2014/0 | 2\. **User Goals and SLIs** - What should your service/application do from the viewpoint of the user? | We do not have a clear definition of what our application or service does from the user perspective. | We have clear, user-centric definitions of the application/service capabilities and outcomes from a user perspective. | | 3\. **Understanding users and behavior** - Who are the users of the software and how do they interact with the software? How do you know? | We don't really know how our users interact with our application/service --OR-- We don't really know who our users are. | We have **user personas** validated through user research and we measure and track usage of the applications/services using digital **telemetry**. | | 4\. **SLIs/SLOs** - How do you **know when users have experienced an outage** or unexpected behaviour in the software? | We know there is an outage or problem when users complain via chat or the help desk. | We proactively monitor the user experience using synthetic transactions across the key user journeys. | -| 5\. **Service Health** - What is the single most important **indicator or metric** you use to determine the **health and availability of your software** in production/live? | We don't have a single key metric for the health and availabillity of the application/service. | We have a clear, agreed key metric for each application/service and we display this figure on a team-visible dashboard. The dashboard data is updated at least every 10 minutes. | -| 6\. **SLIs** - What combination of three or four **indicators or metrics** do you use (or could/would you use) to provide a **comprehensive picture of the health and availability** of your software in production/live? | We don't have a set of key metrics for the health and availabillity of the application/service. | We have a clear, agreed set of key metrics for each application/service and we display this figure on a team-visible dashboard. The dashboard data is updated at least every 10 minutes. | +| 5\. **Service Health** - What is the single most important **indicator or metric** you use to determine the **health and availability of your software** in production/live? | We don't have a single key metric for the health and availability of the application/service. | We have a clear, agreed key metric for each application/service and we display this figure on a team-visible dashboard. The dashboard data is updated at least every 10 minutes. | +| 6\. **SLIs** - What combination of three or four **indicators or metrics** do you use (or could/would you use) to provide a **comprehensive picture of the health and availability** of your software in production/live? | We don't have a set of key metrics for the health and availability of the application/service. | We have a clear, agreed set of key metrics for each application/service and we display this figure on a team-visible dashboard. The dashboard data is updated at least every 10 minutes. | | 7\. **Error Budget and similar mechanisms** - How does the team know when to **spend time on operational aspects** of the software (logging, metrics, performance, reliability, security, etc.)? Does that time actually get spent? | We spend time on operational aspects only when there is a problem that needs fixing. | We allocate between 20% and 30% of our time for working on operational aspects and we check this each week. We alert if we have not spent time on operational aspects --OR-- We use SRE Error Budgets to plan our time spent on operational aspects. | | 8\. **Alerting** - What proportion (approximately) of your time and effort as a team do you spend on **making alerts and operational messages more reliable and more relevant**? | We spend as little time as possible on alerts and operational messages - we need to focus on user-visible features. | We regularly spend time reviewing and improving alerts and operational messages. | | 9\. **Toil and fixing problems** - What proportion (approx) of your time gets taken up with incidents from live systems and how predictable is the time needed to fix problems? | We do not deal with issues from live systems at all - we focus on new features --OR-- live issues can really affect our delivery cadence and are very disruptive. | We allocate a consistent amount of time for dealing with live issues --OR-- one team member is responsible for triage of live issues each week OR we rarely have problems with live issues because the software works well. | From d3928966b5b7c88391074ed76a7609d46771e9d4 Mon Sep 17 00:00:00 2001 From: Jayson McIntosh Date: Tue, 3 Aug 2021 15:17:57 -0400 Subject: [PATCH 04/21] Typo (team work ==> teamwork) --- team-health.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/team-health.md b/team-health.md index 87789a8..a5a6f08 100644 --- a/team-health.md +++ b/team-health.md @@ -22,7 +22,7 @@ Method: Use the [Spotify Squad Health Check](https://labs.spotify.com/2014/09/16 | 4\. **Value** - do you work on valuable things as a team? | We are disconnected from customer or user value | We live and breathe a value-driven team approach | | 5\. **Speed** - how rapidly do you work as a team? | We seem to take a long time to get things done | We deliver work rapidly together | | 6\. **Mission** - how well do you know why you are working on things? | It is rarely clear what our mission is | We have a clear mission that we share with all stakeholders | -| 7\. **Fun** - how fun is it to work in your team? How much *camaraderie* and sense of teamwork? | Fun is rarely an aspect of our team work | The team is a fun place to be every day | +| 7\. **Fun** - how fun is it to work in your team? How much *camaraderie* and sense of teamwork? | Fun is rarely an aspect of our teamwork | The team is a fun place to be every day | | 8\. **Learning** - how much do you learn as a team? | We rarely learn anything new | We learn something every day | | 9\. **Support** - how much support do you get as a team? | We get very little support as a team | We are well-supported as a team | | 10\. **Pawns or players** - how much control do you have over what you work on and how? | We have very little say in what we work on | We have strong influence over what we work on | From 388f266c20666cf496d53f3e12eaf91b4f162b29 Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Thu, 19 Aug 2021 16:00:38 -0400 Subject: [PATCH 05/21] adding translations for continuous delivery --- translations/fr/continuous-delivery.fr.md | 37 +++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 translations/fr/continuous-delivery.fr.md diff --git a/translations/fr/continuous-delivery.fr.md b/translations/fr/continuous-delivery.fr.md new file mode 100644 index 0000000..096d89c --- /dev/null +++ b/translations/fr/continuous-delivery.fr.md @@ -0,0 +1,37 @@ +# Continuous Delivery check + +> **Part of the Multi-team Software Delivery Assessment** ([README](README.md)) +> +> Copyright © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) +> +> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> +> _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ + +Basé sur : + +* les pratiques clés dans le livre [Continuous Delivery](http://continuousdelivery.com/) de Jez Humble et Dave Farley; +* le livre [Continuous Delivery with Windows and .NET](http://cdwithwindows.net/) de Matthew Skelton et Chris O’Dell; +* le résumé des pratiques de livraison continue sur [CDchecklist.info](http://cdchecklist.info/). + +But : *Évaluer la sensibilisation et le rendement de l’équipe à l’égard des pratiques clés de livraison continue.* + +Méthode : Utilisez l’approche [*Spotify Squad Health Check*](https://labs.spotify.com/2014/09/16/squad-health-check-model/) pour évaluer les réponses de l’équipe aux questions suivantes, et consignez les réponses : + +| **Question** | **Fatigué (1)** | **Inspiré (5)** | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 1\. **Candidat au lancement** - Chaque enregistrement conduit au lancement possible (chapitre 1). | Nous avons des versions spéciales « Candidat au lancement » occasionnellement. | N’importe quel enregistrement peut générer une version qui peut aller en Production sans une autre version. | +| 2\. **Effectué** - Signifie « lancé » \[c’est-à-dire, mis en production et ne causant pas de problèmes\] (Chapitre 1). | Notre définition de Terminé « Effectué » signifie que « les essais de fonctionnalité ont réussi ». | Notre définition de « Effectué » signifie que les changements sont déployés à la Production avec une surveillance pour garantir que rien n’est rompu. | +| 3\. **Configuration automatisée** - La configuration doit toujours être effectuée par des processus automatisés à l’aide de valeurs tirées de votre référentiel de configuration (Chapitre 2). | Beaucoup de nos applications et essais sont configurés manuellement à chaque | Toutes les configurations sont effectuées à l’aide de scripts. | +| 4\. **Options de configuration** - Il devrait être facile pour quiconque de voir les options de configuration qui sont disponibles pour une version particulière d’une application dans tous les environnements où elle sera déployée. (Chapitre 2). | Nous devons exécuter des différences sur divers fichiers, certains dans le contrôle de version, d’autres tirés des serveurs en direct. | Nous disposons d’une API ou d’une interface utilisateur pour afficher les options de configuration déployées dans n’importe quel environnement. | +| 5\. **Versions rompues** - N’enregistrez pas sur une version rompue (Chapitre 3) \[sauf pour réparer la version rompue\!\]. | Nous ne pouvons pas facilement savoir quand notre équipe a rompu une version. | Nous gardons la version avec soin et n’enregistrons jamais sur une version rompue. | +| 6\. **Essais de non-conformité** - Ne commentez pas les essais de non-conformité (chapitre 3). | Nous désactivons les essais de non-conformité pour que la version ou le pipeline fonctionne. | Nous faisons confiance à nos essais; si les essais échouent, alors quelque chose ne fonctionne pas et nous allons le réparer. | +| 7\. **Binaires** - Ne compilez vos binaires qu’une seule fois [aucune version spéciale de « candidat de lancement »] (Chapitre 5). | Nous avons plusieurs versions différentes, puis les fusionnons pour créer le candidat de lancement définitif. | Nous n’avons qu’une seule version pour produire un artefact binaire qui est ensuite promu dans tous les environnements sans fusion ou version supplémentaire nécessaire. | +| 8\. **Arrêt** - Si une partie du pipeline échoue, arrêtez \[tout le monde arrête le travail lié aux fonctionnalités et corrige le problème\] (Chapitre 5). | Le pipeline échoue si souvent qu’il est difficile de savoir quelle équipe a rompu la version. | Si le pipeline échoue, on connaît clairement l’équipe qui est responsable et nous arrêtons donc immédiatement notre travail pour résoudre le problème. | +| 9\. **Déploiement idempotent** - Assurez-vous que le processus de déploiement est idempotent \[nous pouvons déployer la même version plusieurs fois avec le même résultat\] (Chapitre 6). | Il est difficile d’obtenir des déploiements répétables. | Nous pouvons redéployer la même version plusieurs fois avec le même résultat. | +| 10\. **Modules de remplacement** - Utilisez des modules de remplacement pour simuler des systèmes externes \[traitez presque tous les autres systèmes comme « externes »\!\] (Chapitre 8). | Il y a peu de modules de remplacement disponibles et nous n’avons pas assez de temps pour rédiger les modules de remplacement nous-mêmes. | Les modules de remplacement que nous consommons et écrivons sont de bonne qualité et nous donnent un niveau élevé de confiance que nos essais fonctionnent bien. | +| 11\. **Réexécution de l’API** - Consignez les interactions sur un service ou une API publique (Chapitre 9). | Nous n’avons aucun moyen de consigner les demandes ou réponses d’une API distante. | Nous consignons les demandes ou réponses clés des API distantes que nous utilisons pour élaborer des essais d’intégration à haute fidélité. | +| 12\. **Bleu vert** - Utilisez les déploiements bleu vert [à un niveau granulaire] (Chapitre 10) – c’est tout mécanisme qui vous permet de mettre à l’essai une nouvelle version à côté d’une version existante et de revenir à l’ancienne version, au besoin. | Nous n’utilisons aucune technique de déploiement bleu vert. | Nous utilisons des techniques de déploiement bleu vert à grain fin – au niveau des services individuels. | +| 13\. **Historique de l’environnement** - l devrait être possible de voir un historique des changements apportés à chaque environnement, y compris les déploiements. (Chapitre 11). | Il est difficile de voir l’historique des changements dans un environnement. | Nous avons un tableau de bord ou un journal des changements dans chaque environnement. | +| 14\. **Modifications de base de données** - Découplez le déploiement d’applications à partir de la migration des bases de données \[et d’autres services riches en données\] (chapitre 12) – il s’agit de bases de données partagées. | Nous devons déployer notre application ou service avec la base de données ou la couche de données. | Notre application ou service est complètement découplé de la base de données ou de la couche de données sous-jacente. | + From 0db9b809c21d48e437cd96a730e7f9ea9d539d0f Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Thu, 19 Aug 2021 16:02:21 -0400 Subject: [PATCH 06/21] missing line that was not translated --- translations/fr/continuous-delivery.fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translations/fr/continuous-delivery.fr.md b/translations/fr/continuous-delivery.fr.md index 096d89c..b604499 100644 --- a/translations/fr/continuous-delivery.fr.md +++ b/translations/fr/continuous-delivery.fr.md @@ -1,6 +1,6 @@ # Continuous Delivery check -> **Part of the Multi-team Software Delivery Assessment** ([README](README.md)) +> **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) > > Copyright © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) > From ac83f1b6f9a42dea13b9af0db4be4a5526c0e51f Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Thu, 19 Aug 2021 16:03:04 -0400 Subject: [PATCH 07/21] missing translations --- translations/fr/continuous-delivery.fr.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/translations/fr/continuous-delivery.fr.md b/translations/fr/continuous-delivery.fr.md index b604499..4e6c50f 100644 --- a/translations/fr/continuous-delivery.fr.md +++ b/translations/fr/continuous-delivery.fr.md @@ -2,9 +2,9 @@ > **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) > -> Copyright © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) +> Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) > -> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> Sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) > > _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ From 968452cd5a215b9297994a1d3f396b2432e3ed50 Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Thu, 19 Aug 2021 16:06:34 -0400 Subject: [PATCH 08/21] adding french translations for deployment --- translations/fr/deployment.fr.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 translations/fr/deployment.fr.md diff --git a/translations/fr/deployment.fr.md b/translations/fr/deployment.fr.md new file mode 100644 index 0000000..aa82d39 --- /dev/null +++ b/translations/fr/deployment.fr.md @@ -0,0 +1,23 @@ +# Deployment check + +> **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) +> +> Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) +> +> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> +> _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ + +Basé sur les questions de maturité de Mirco Hering, auteur de [*DevOps for the Modern Enterprise*](https://notafactoryanymore.com/2018/03/01/mircos-self-assessment-questions-of-devops-maturity/) + +But : *Évaluer la confiance de l’équipe dans les pratiques de déploiement de ses logiciels* + +Méthode : Utilisez l’approche [*Spotify Squad Health Check*](https://labs.spotify.com/2014/09/16/squad-health-check-model/) pour évaluer les réponses de l’équipe aux questions suivantes : + +| **Question** | **Inspiré (1)** | **Fatigué (5)** | +| -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------ | +| 1\. **Reconstruction d’environnement** - Que se passerait-il si nous décidions de : **vider l’environnement et le reconstruire à partir de notre configuration stockée.** | Nous ne savons pas ce qui se passerait – les environnements sont instables. | Pas de problème – nous mettons cela à l’essai dans le pipeline de déploiement d’abord. | +| 2\. **Nouvelle configuration** - Que se passerait-il si nous décidions de : **supprimer la configuration de l’application et la redéployer.** | Nous ne savons pas ce qui se passerait – le processus de configuration est instable. | Pas de problème – nous mettons cela à l’essai dans le pipeline de déploiement d’abord. | +| 3\. **Redéployer l’application** - Que se passerait-il si nous décidions de : **redéployer l’application même si rien n’a changé.** | Nous ne savons pas ce qui se passerait – les déploiements sont instables. | Pas de problème – nous mettons cela à l’essai dans le pipeline de déploiement d’abord. | +| 4\. **Réexécution des essais** - Que se passerait-il si nous décidions de : **réexécuter la suite des essais, et ainsi de suite.** | Nous ne savons pas ce qui se passerait – la suite d’essais est vraiment instable. | Pas de problème – nous mettons cela à l’essai dans le pipeline de | + From 93f69f87adb127d3a786dfaca70c00fb47d597fa Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 20 Aug 2021 10:02:22 -0400 Subject: [PATCH 09/21] adding flow and fixing small typos --- translations/fr/README.fr.md | 166 ++++++++++++++++++++++ translations/fr/continuous-delivery.fr.md | 4 +- translations/fr/deployment.fr.md | 2 +- translations/fr/flow.fr.md | 31 ++++ translations/fr/operability.fr.md | 33 +++++ translations/fr/team-health.fr.md | 32 +++++ translations/fr/testability.fr.md | 28 ++++ 7 files changed, 293 insertions(+), 3 deletions(-) create mode 100644 translations/fr/README.fr.md create mode 100644 translations/fr/flow.fr.md create mode 100644 translations/fr/operability.fr.md create mode 100644 translations/fr/team-health.fr.md create mode 100644 translations/fr/testability.fr.md diff --git a/translations/fr/README.fr.md b/translations/fr/README.fr.md new file mode 100644 index 0000000..e116759 --- /dev/null +++ b/translations/fr/README.fr.md @@ -0,0 +1,166 @@ +# Multi-team Software Delivery Assessment + +Multi-team Software Delivery Assessmentは、組織内のさまざまなチームのソフトウェア・デリバリーを評価するためのシンプルで実行しやすい手法です。 　　　　 + +この評価手法は、よく知られ実績のある[Spotify Squad Health Check model](https://labs.spotify.com/2014/09/16/squad-health-check-model/)を基にしており、以下合計6つの観点をカバーしています。 + +1. [Team Health](team-health.ja.md) +2. [Deployment](deployment.ja.md) +3. [Flow](flow.ja.md) +4. [Continuous Delivery](continuous-delivery.ja.md) +5. [Operability](operability.ja.md) +6. [Testing and Testability](testability.ja.md) + +これら6つの観点は、最新のソフトウェア・デリバリーのすべての重要事項を網羅していて、チームがそれぞれの長所とプラクティスを自己評価できます。 + +**🚀 概要**: [Continuous Delivery at scale](https://www.slideshare.net/matthewskelton/continuous-delivery-at-scale-matthew-skelton-nhs-digital-agile-cop-march-2019)のスライド32〜38を参照してください。 + +> Copyright © 2018-2019 [Conflux Digital Ltd](https://confluxdigital.net/) +> +> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> +> _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ + +## 評価の目的 + +ソフトウェアシステムを構築および実行するためのポジティブな作業環境の促進、および維持することが評価の目的です。 +ポジティブな作業環境では、以下の状況が発生します。 + + - ソフトウェアの変更は、継続的デリバリーの手法を使用して、**迅速かつ安全に**ビルドされ、テストされ、プロダクション環境にリリースされる。 + - プロセスとプラクティスは、**リリースに向けたソフトウェアの変更フロー**に最適化される。 + - ソフトウェアは、1つ１つ分断されたシステムに対して**独立、分離したリリース**ができるように設計および構築される。 + - ソフトウェアは、**運用性**、**テスト容易性**、および**リリース容易性**を考慮して設計および構築される。 + - ソフトウェアプロダクト、ソフトウェア生産過程での問題が、顧客やユーザーが気付く前に常に**チームによって検出される**。 + - 開発者がソフトウェアの変更に対する責任と**説明責任**を持ち、開発者のエンパワーメントとオーナーシップに繋がる。 + - ソフトウェア開発が、**やりがいのあり**、楽しいものになる。 + - **悪い慣習と悪いアプローチに挑み、変えること** に自信が持てるようになる。 + +基本的にMulti-team Software Delivery Assessmentは**チームを解放して活性化**し、チームが成功するのに役立ちます。この評価手法は、様々な改善点を特定することにより、**チームがソフトウェアシステムの構築、テスト、およびリリースを改善する**のを手助けします。 +改善点には、以下があります。 + +1.チーム中心の改善点 +2.製品中心およびサービス中心の改善点 +3.組織全体の改善点 + +この評価手法は、チームにペナルティを科すために使用するべきではなく、プラクティスと品質の改善に向けて、共有される意欲を提供するために使用するべきです。 + +## 評価対象のチーム + +アプリケーションソフトウェアまたはインフラストラクチャのコード、スクリプトの作成、またはそれらの設定を行うすべてのチームが評価対象となり、評価することでメリットがあります。 +評価対象のチームは以下になります。 + + - **ユーザー向け-のWebサイトとサービス**、**顧客向けのWebサイトとサービス**を構築するチーム + - **内部サービス**を構築するチーム + - 他のシステムをサポートする**インフラストラクチャ**を構築するチーム（プラットフォームチームを含む） + - **ビルド とデプロイメント**ツール、スクリプトを構築するチーム + - ソフトウェアおよびインフラストラクチャの一部としてCOTS製品を構成およびテストするチーム + - その他、**ソフトウェアおよびインフラストラクチャの構築、構成、およびテスト** に主眼をおくチーム + +"チーム"とは、人材連携の度合いの大きい6-10人のグループを意味します。通常、**Squad**、**Scrumチーム**、**Productチーム**、または **Stream-alignedチーム**と呼ばれます。 + +## 評価基準 + +各観点の評価基準は、既存の出版された書籍、およびオンラインソースから取得しています。 + +* **Team Health** - [_Spotify Squad Health Check_](https://labs.spotify.com/2014/09/16/squad-health-check-model/) の評価基準に基づき作成し、いくつかのチェック項目を追加しました。。 +* **Deployment** - Mirco Hering氏のブログ投稿[_DevOps for the Modern Enterprise_](https://itrevolution.com/book/devops_modern_enterprise/) で説明されている書籍[_DevOps for the Modern Enterprise_](https://itrevolution.com/book/devops_modern_enterprise/) の主要な質問に基づいて作成しました。 +* **Flow** - Nicole Forsgren氏、Jez Humble氏、Gene Kim氏の書籍 [_Accelerate_](https://itrevolution.com/book/accelerate/) の評価基準に基づき作成し、Don Reinertsen 氏の書籍 [_The Principles of Product Development Flow_](https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009) から、いくつかチェック項目を追加しました。 +* **Contous Delivery** - Jez Humble氏とDave Farley氏による書籍 [_Continuous Delivery_](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912) と [CDchecklist.info](http://CDchecklist.info/) にある書籍の要約に基づいて作成しました。 +* **Operability** - [OperabilityQuestions.com](http://OperabilityQuestions.com/)からの質問と、Matthew Skelton氏、Alex Moore氏、およびRob Thatcher氏による書籍[_Team Guide to Software Operability_](http://operabilitybook.com/) から選択した評価基準に基づいて作成しました。 +* **Testing and Testability** - Lisa Crispin氏 と Janet Gregory氏による書籍 [_Agile Testing_](https://wordery.com/agile-testing-lisa-crispin-9780321534460) , Jez Humble氏とDave Farley氏による書籍 [_Continuous Delivery_](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912) , Steve Freeman 氏 と Nat Price 氏 による書籍[_Growing Object-Oriented Software_](https://wordery.com/growing-object-oriented-software-guided-by-tests-steve-freeman-9780321503626) , Michael Feathers氏による書籍 [_Working Effectively with Legacy Code_](https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052), Ash Winter氏と Rob Meaney氏による書籍 [_Team Guide to Software Testability_](http://testabilitybook.com/) と Webサイト [TestabilityQuestions.com](http://TestabilityQuestions.com/) に基づいて評価基準を作成しました。 + +## 評価の実行方法 + +評価セッション自体は、チームのふりかえりのように実施する必要があります。通常のふりかえりとの主な違いは、評価セッションではファシリテーターが議論をよりしっかりと導くことです。議論する多くの質問があり、チームが利用可能な時間内にすべての評価基準を議論することが重要です。 + +評価セッションの終わりには、チームは議論に基づいて、プロセスとプラクティスを改善するためにどのようなアクションを実行するかの決定を促され、エンパワーメントされたと感じる必要があります。 + +### 評価の実行頻度 + +多くの組織では、評価セッションを**3か月ごとに** 実行すると、良い結果が得られることがわかっています。 + +### 評価のための準備 + +1. 評価セッションのファシリテーターを見つけます。これは、チームのふりかえりに精通しているチーム外の人でなければなりません。 +2. 時間を2時間、チームに対して大きめのミーティングルームを確保します。 +3. [既製のA1 PDF（リリースを参照）](https://github.com/ConfluxDigital/software-delivery-assessment/releases)を使用するか、可能であればA1サイズで、以下の個々の評価ページ（小さなマージンを使用）を使用して、各観点の評価シートを印刷します。 + * [Team Health - 評価シート](print/print-team-health.ja.md) + * [Deployment - 評価シート](print/print-deployment.ja.md) + * [Flow - 評価シート](print/print-flow.ja.md) + * [Continuous Delivery - 評価シート](print/print-continuous-delivery.ja.md) + * [Operability - 評価シート](print/print-operability.ja.md) + * [Testing and Testability - 評価シート](print/print-testability.ja.md) +4. 詳細ページをガイドとして印刷（またはページを画面上で開く）して、各評価基準のコンテキストと詳細を理解します。 + 1. [Team Health](team-health.ja.md) + 2. [Deployment](deployment.ja.md) + 3. [Flow](flow.ja.md) + 4. [Continuous Delivery](continuous-delivery.ja.md) + 5. [Operability](operability.ja.md) + 6. [Testing and Testability](testability.ja.md) +5. マーカーまたはホワイトボードマーカーをたくさん用意してください。赤、青、緑が最適です。 +6. セッションに**ふりかえりのファシリテーションに精通している人**（おそらくスクラムマスター）を含めます。 チームのファシリテーター以外の人は、セッション中にファシリテーターから学習し、後に他の評価セッションでファシリテートできるようになります。 + +> **ファシリテーター** +> +> ファシリテーターは、セッションを実行する前に[Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/)のアプローチに慣れる必要があります。優れたレポートとして、[How I Used the Spotify Squad Health Check Model](http://www.barryovereem.com/how-i-used-the-spotify-squad-health-check-model/)、SkyBet [Squad Health Checks](https://engineering.skybettingandgaming.com/2017/02/01/squad-health-checks/)で公開されており、また、SpotifyからSquad Health Checkの説明文書([PDF](https://spotifylabscom.files.wordpress.com/2014/09/squad-health-check-model2.pdf)) がダウンロードできます。 +> +> 評価セッション中に実施すること: +> +> * いくつか議題が長引く場合は、セッションの外でディスカッションを行うように依頼して、セッションがスケジュール通り進むようにします。 +> * 印刷された評価シートにチームのスコアとメモを書き留めます。 +> * 完成した評価シートの写真を撮ります。 +> * エンジニアリング評価の意義と実施結果についてチームからフィードバックを受け取ります。 - 笑顔で十分です。 +> + +### 時間調整 + +チーム評価セッションは2時間で実行され、ファシリテーターは6つの観点の質問を通して、セッションをファシリテートします。 + +1. Team health check - **35分** +2. Deployment health check - **10分** +3. Flow check - **10分** +4. Continuous Delivery check - **20分** +5. Operability check - **20分** +6. Test coverage check - **20分** + +これら6つの評価の間に**5分の休憩**を挟みます。 + +### 評価セッションの実行 + +各セクションにはいくつかのルールがあります。各質問には以下の記載事項を意識して回答する必要があります。 + + - チームは、個人またはチームとして、***Tired* and *Inspired*** ガイドラインに基づいて、SAD（1 OR 2）/MEH（3）/ YAY（4 OR 5） を使用して各評価基準を評価します。 + + - *Tired (しんどい)* は評価が低く (1), *Inspired (すばらしい)* は評価が高い (5) です。　　　　 + + - 個人ごとに評価した場合は、評価を集計し、1-5の単一のチームスコアを決定します。印刷されたシートに異なる色のペンを使用して、異なる評価を視覚的に示すと便利です。 + + - 過去に評価を実施している場合は、前回のスコアに対する**トレンド** を決定します。(上がった, 変わらない, 下がった) + + - 今後数カ月にわたり、評価基準のスコア改善することに**同意します**。 + + - **メモ**欄を使用して、評価のまとめ役が知る必要があると思われる詳細情報を示します。 + + - 各シートの下部にある **日付/名前/ファシリテーター** 欄に必ず情報を記入します。 + + - 記入済みの各シートの写真を撮り、評価のまとめ役に送信します。 + + - チームメンバーに次の観点から評価セッション自体を評価してもらいます： **価値**、**実行** （悪い、まあまあ、良い） + +### ファシリテーションを促進する + +各チームの評価セッションには、ファシリテーターから学習している人物が参加しているため、今後のセッションをファシリテートすることができます。新しいファシリテーターはそれぞれ、少なくとも2つの他のチームとのセッションをファシリテーションする必要があります。このようにして、ファシリテーターの数は急速に拡大し、最初のファシリテーターの負担を最小限に抑えることができます。 + +## 結果の調整と解釈 + +各チームが評価セッションを実行して結果を送信した後、評価のまとめ役は異なるチームの結果を照合し、組織全体で改善が必要な領域を特定する必要があります。 +改善が必要な領域を特定するには、次のような質問をします。 + +* チームABCがテストカバレッジについて1と評価するのは何故ですか？ スコアの上昇を妨げているものは何ですか？ + +* より多くのチームのリリースを支援するために、組織として何ができますか？ + +* チームがよりよく、効率良く作業できるようにプラットフォーム側が改善するべき点はありますか？ + +チームを直接ランク付けまたは比較しようとしないでください。代わりに、チームからのシグナルを使用して組織のダイナミクスをより理解し、組織全体の改善に優先順位を付けます。 + diff --git a/translations/fr/continuous-delivery.fr.md b/translations/fr/continuous-delivery.fr.md index 4e6c50f..06f01d3 100644 --- a/translations/fr/continuous-delivery.fr.md +++ b/translations/fr/continuous-delivery.fr.md @@ -10,8 +10,8 @@ Basé sur : -* les pratiques clés dans le livre [Continuous Delivery](http://continuousdelivery.com/) de Jez Humble et Dave Farley; -* le livre [Continuous Delivery with Windows and .NET](http://cdwithwindows.net/) de Matthew Skelton et Chris O’Dell; +* les pratiques clés dans le livre [Continuous Delivery](http://continuousdelivery.com/) de Jez Humble et Dave Farley. +* le livre [Continuous Delivery with Windows and .NET](http://cdwithwindows.net/) de Matthew Skelton et Chris O’Dell. * le résumé des pratiques de livraison continue sur [CDchecklist.info](http://cdchecklist.info/). But : *Évaluer la sensibilisation et le rendement de l’équipe à l’égard des pratiques clés de livraison continue.* diff --git a/translations/fr/deployment.fr.md b/translations/fr/deployment.fr.md index aa82d39..dd85af7 100644 --- a/translations/fr/deployment.fr.md +++ b/translations/fr/deployment.fr.md @@ -4,7 +4,7 @@ > > Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) > -> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> Sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) > > _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ diff --git a/translations/fr/flow.fr.md b/translations/fr/flow.fr.md new file mode 100644 index 0000000..ab62f10 --- /dev/null +++ b/translations/fr/flow.fr.md @@ -0,0 +1,31 @@ +# Flow check + +> **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) +> +> Droit d’auteur [Conflux Digital Ltd](https://confluxdigital.net/) +> +> Sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> +> _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ + +D’après les principaux critères d’évaluation tirés des suivants: + +* [*Accelerate*](https://wordery.com/accelerate-nicole-forsgren-phd-9781942788331) de Nicole Forsgren, Jez Humble et Gene Kim. +* [*Principles of Product Development Flow*](https://wordery.com/the-principles-of-product-development-flow-donald-g-reinertsen-9781935401001) de Don Reinertsen. +* [*Team Guide to Metrics for Business Decisions*](http://bizmetricsbook.com/) de Mattia Battiston et Chris Young. + +But : *Évaluer la sensibilisation et le rendement de l’équipe en ce qui concerne les mesures de livraison de bout en bout.* + +Méthode : Utilisez l’approche [*Spotify Squad Health Check*](https://labs.spotify.com/2014/09/16/squad-health-check-model/) pour évaluer les réponses de l’équipe aux questions suivantes, et consignez les réponses : + +| **Question** | **Fatigué (1)** | **Inspiré (5)** | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | +| 1\. **Durée du cycle** - Combien de temps faut-il pour qu’un changement de code passe du contrôle de version à l’exécution en Production? (Minimum, standard). | 2 semaines ou plus. | 1 heure ou moins. | +| 2\. **Fréquence de déploiement** - À quelle fréquence votre équipe se déploie-t-elle en production? | Toutes les 2 semaines ou plus dans la pratique. | Tous les 2 jours ou moins. | +| 3\. **Temps moyen de résolution (TMR)** - Combien de temps faut-il pour restaurer votre application ou service après un incident? | Nous n’en avons aucune idée – nous ne fais pas ce suivi. | Nous faisons le suivi du TMR et nous restaurons le service en 10 minutes automatiquement et nous le testons dans le pipeline de déploiement. | +| 4\. **Modifications ayant échoué** - Quelle proportion de modifications apportées à votre application ou service dans en production a échoué ou exigent une correction? (Il s’agit généralement du nombre de déploiements ayant échoué.) | Plus de 20 % de nos changements ou déploiements échouent en production. | Moins de 5 % de nos changements ou déploiements échouent dans la production. | +| 5\. **Travaux en cours** - Sur combien de choses votre équipe travaille-t-elle en même temps? (Minimum, standard.) | Nous avons beaucoup plus d’éléments Travail en cours (TEC) que de membres d’équipe. | Nous avons explicitement limité nos TEC en nous fondant sur la théorie des files d’attente (ou coût du retard), et le nombre de TEC est inférieur ou égal au nombre de personnes dans notre équipe. | +| 6\. **Innovation** - Dans quelle mesure êtes-vous capable d’innover en matière d’approches de livraison? | Nous n’avons pas le temps d’innover. | Nous consacrons du temps à l’innovation chaque semaine et suivons les progrès dans le cadre des mesures de notre équipe. | +| 7\. **Intégration** - Quelle est l’efficacité du processus d’intégration pour les nouvelles équipes et le nouveau personnel? | Le processus d’intégration est incroyablement difficile et freine vraiment le progrès. | Le processus d’intégration est très simple, facile et clair. | +| 8\. **Âge des branches** - Combien de temps durent vos branches? (Autre que la branche maître.) | Nos branches de fonctionnalités durent pour plusieurs sprints. | Nous nous développons directement sur la branche maître ou le tronc et toutes les branches de fonctionnalités ne durent pas plus de deux jours. | +| 9\. **Rétrospectives** - Quelle est l’efficacité des rétrospectives de votre équipe? | Nous n’avons pas de rétrospectives périodiques. | Nos rétrospectives sont vraiment énergivores/précieuses/efficaces pour l’équipe et nous les attendons avec impatience. | \ No newline at end of file diff --git a/translations/fr/operability.fr.md b/translations/fr/operability.fr.md new file mode 100644 index 0000000..a1c00b4 --- /dev/null +++ b/translations/fr/operability.fr.md @@ -0,0 +1,33 @@ +# Operability check + +> **Part of the Multi-team Software Delivery Assessment** ([README](README.md)) +> +> Copyright © 2018-2019 [Conflux Digital Ltd](https://confluxdigital.net/) +> +> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> +> _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ + +[OperabilityQuestions.com](http://OperabilityQuestions.com/)からの質問と、Matthew Skelton氏、Alex Moore氏、およびRob Thatcher氏による書籍[_Team Guide to Software Operability_](http://operabilitybook.com/) から選択した評価基準に基づいて作成しました。 + +目的：*ソフトウェアの操作性-実稼働の準備 に関するチームの認識と実践を評価すること* + +方法：[Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/) のアプローチを使用して、次の質問に対するチームの回答を評価する: + +| **質問** | **しんどい (1)** | **すばらしい (5)** | +| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 1\. **コラボレーション** - 運用機能（ログ、監視、アラートなど）や非機能要件など、システムの運用面で他のチームとどのくらいの頻度で、どのように協力していますか? | リリース後に、サービスチームの要求により必要に応じて対応する | 仕事やプロジェクトの最初の週から運用面で協力する | +| 2\. **運用コスト** - 製品の予算とチームの努力のどの部分が運用面の対処に費やされていますか？ これをどのように計測しますか？ \[インフラコストを無視し、チームの努力に集中する\] | 運用面での時間と労力をできる限り少なくしようとしている/運用面での支出を計測していない| 時間と予算の約30％を運用面に費やしている | +| 3\. **機能の切り替え** - システムでどの機能（機能スイッチ）がアクティブであるかをどのように知ることができますか? | どの機能がアクティブかを判断するために、設定ファイルの差分を比較する必要がある | 環境内の機能のアクティブ/非アクティブを確認するシンプルなUIまたはAPIがある | +| 4\. **設定のデプロイ** - ソフトウェアを再デプロイせずに構成変更を反映するにはどうすればよいですか? | ソフトウェアをデプロイするか、停止せずに設定変更を反映できない | ソフトウェアとは別に設定変更作業を実施する/ソフトウェアを停止することなく、設定変更を実施できる | +| 5\. **システムの健全性** - システムが健全（または不健全）であることをどのようにして知ることができますか? | ソフトウェアが正常かどうかを確認するために、別のチームに手動チェック実施してもらう | 標準のHTTPヘルスチェックURLを使用してソフトウェアに問い合わせし、コードに記述したロジックに基づいてHTTP 200/500を返します。また、主要なシナリオの合成トランザクションモニタリングを使用する | +| 6\. **サービスKPI** - メインサービス/システムの主要業績評価指標（KPI）を追跡するにはどうすればよいですか? 何をKPIに設定していますか? | サービスKPIが定義されていない | ロギングおよび/または時系列メトリックを使用して、ダッシュボードで取得できるサービスKPIを定義している | +| 7\. **ロギング動作** - ロギングが正しく機能していることをどのようにして知ることができますか? | ロギングが機能しているかどうかはテストしていない |特定のアプリケーションの動作が実行された後に、特定のログメッセージ文字列を検索するBDD機能テストを実行、ロギングが機能していることをテストし、中央ログ集約/検索システムでログが正しく表示されることを確認できる | +| 8\. **テスト容易性** - ソフトウェアシステムのテストが簡単であると言えますか? 何を誰に提供しますか? | ソフトウェアを簡単にテストできるようにすることを明確に目指していない |デプロイメント・パイプライン内のソフトウェアのすべての部分に対してクライアントと外部テストパックを実行する | +| 9\. **TLS証明書** - SSL / TLS証明書の有効期限が近づいたことをどのようにして知ることができますか? | 証明書の有効期限がいつなのかわからない| 証明書の自動更新と証明書監視/アラートツールを組み合わせて使用​​し、証明書の有効期限が切れるときにライブチェックを行い、事前に是正措置ができる | +| 10\. **機密データ** - ログ内の機密データをマスクまたは非表示にするにはどうすればよいですか? | ログ内の機密データのテストはしていない | 特定のアプリケーションの動作した後に、特定のログメッセージ文字列を検索するBDD機能テストを使用して、データマスキングが発生していることをテストする | +| 11\. **パフォーマンス** - システム/サービスのパフォーマンスが許容範囲内で機能することをどのようにして知ることができますか? | サービスまたはアプリケーションのパフォーマンスの検証は、パフォーマンスチームのみに依存している | バージョン管理へのすべてのチェックインで実行されるデプロイメント・パイプライン内で一連のパフォーマンステストを実行する | +| 12\. **故障モード** - システムのさまざまな既知の故障モード（故障シナリオ）をどのように確認して共有しますか? | システムがどのように故障するかを本当に知らない | エラー識別子のセットを使用して、ソフトウェアの故障モードを定義し、これらの識別子をログメッセージで使用する | +| 13\. **呼び出しトレース** - システムでE2Eでコール/リクエストをトレースするにはどうすればよいですか? | システムで呼び出しをトレースできない | OpenTracingなどの標準トレースライブラリを使用して、システム全体の呼び出しをトレースする。 他のチームと協力して、コンポーネントの境界を越えて正しいトレースフィールドが維持されるようにする | +| 14\. **サービスの状況** - 現在のサービス/システムステータスを運用担当チームにどのように表示していますか? | 運用チームが、サービスの監視項目を発見する傾向がある | 運用チームと協力してダッシュボードを構築し、UXを重要な考慮事項としてユーザーフレンドリーな方法で必要なすべての詳細情報が得られるようにしている | + diff --git a/translations/fr/team-health.fr.md b/translations/fr/team-health.fr.md new file mode 100644 index 0000000..fb5b53b --- /dev/null +++ b/translations/fr/team-health.fr.md @@ -0,0 +1,32 @@ +# Team Health check + +> **Part of the Multi-team Software Delivery Assessment** ([README](README.md)) +> +> Copyright © 2018-2019 [Conflux Digital Ltd](https://confluxdigital.net/) +> +> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> +> _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ + +[Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/)とGoogleの[Project Aristotle](https://rework.withgoogle.com/print/guides/5721312655835136/)からの洞察に基づいて作成しました。 + +目的： *ソフトウェア・デリバリー単位ごとのチームの健康と自信を評価すること* + +方法：[Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/) のアプローチを使用して、次の質問に対するチームの回答を評価する: + +| **質問** | **しんどい (1)** | **すばらしい (5)** | +| ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | +| 1\. **リリースが容易** - 作業中のソフトウェア変更をリリースするのは簡単ですか？ | リリースするのは難しい |リリースするのは簡単で分かりやすい | +| 2\. **適切なプロセス** - ソフトウェアの開発とリリースのプロセスは適切ですか？ | プロセスは面倒で役に立たない | プロセスはほとんどが隠されていて、ほとんど意識することがない | +| 3\. **技術品質** (コードベースの健全性) - コードベースはどれくらい健全ですか？ | コードには、回避策と危険領域が山積みされている | コードはクリーンで安全に使用でき、十分にテストされている| +| 4\. **顧客またはユーザーの価値** - チームはビジネスとして価値あることに取り組んでいますか？ | 顧客またはユーザーの価値から切り離されている| 顧客またはユーザーの価値重視のチームアプローチを採用し、実践している | +| 5\. **スピード** - チームとしてどれくらい迅速に仕事をしていますか？ | 物事を成し遂げるために長い時間がかかる| 共々に迅速な仕事を提供している| +| 6\. **ミッション** - ミッションに取り組んでいる理由をどれだけ知っていますか？ | ミッションは明確ではない | すべての利害関係者と共有する明確なミッションがある| +| 7\. **楽しさ** - チームで働くのはどれほど楽しいですか？ *仲間意識*とチームワークの意識はどのくらいですか？ | チームに楽しさはない | チームの毎日は楽しい| +| 8\. **学び** - チームとしてどれくらい学びがありますか？ | 新しいことはほとんど学ばない | 毎日何かを学ぶ | +| 9\. **サポート** - チームとしてどれくらいのサポートが得られますか？ | チームとしてのサポートはほとんどない | チームとして十分にサポートされている | +| 10\. **ポーンか？プレイヤーか？** - 作業内容とその手段をどの程度管理していますか？ | 自分たちが取り組んでいることについて、チェスのポーンのようにプロセス、作業そのものを変更することはできない。 | 自分たちが取り組んでいることについて、チェスのプレイヤーのようにプロセス、作業そのものを変更でき、強い影響を与えることができる| +| 11\. **心理的安全性** - 懸念を提起することに対する安全性はどの程度ですか？ | 懸念を提起した場合、自分たちの叫びは無視される | 懸念は評価され、チームと組織の改善に役立てられる | +| 12\. **周りのチーム** - あなたの周りのチームはあなたとあなたのチームとどれくらいうまく働いていますか？ | 周りのチームは役に立たずで、失礼な振る舞いをする | 周りのチームはとてもフレンドリーで親切で、他のチームと仕事をすることに喜びを感じる| +| 13\. **ソフトウェア・デリバリープラットフォーム** - チームのソフトウェア・デリバリーを支えるソフトウェア・デリバリープラットフォームはどれほど効果的で使いやすいですか？ | ソフトウェア・デリバリープラットフォームは自分たちの作業を妨害しているようで、使用が難しい | このプラットフォームは自分たちの開発を加速させるもので、迅速かつ安全にソフトウェア・デリバリーするのに役立っている。 ソフトウェア・デリバリープラットフォームが好きだ。| +| 14\. **経営スタイル** - 経営陣やその他の上級管理者によるアプローチは、どの程度効果的かつ適切ですか？ | 管理アプローチは本当に自分たちの努力を妨げている | 管理アプローチは、迅速かつ安全にソフトウエアをリリースする助けとなる| diff --git a/translations/fr/testability.fr.md b/translations/fr/testability.fr.md new file mode 100644 index 0000000..6d570fa --- /dev/null +++ b/translations/fr/testability.fr.md @@ -0,0 +1,28 @@ +# Testability check + +> **Part of the Multi-team Software Delivery Assessment** ([README](README.md)) +> +> Copyright © 2018-2019 [Conflux Digital Ltd](https://confluxdigital.net/) +> +> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> +> _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ + +Lisa Crispin氏 と Janet Gregory氏による書籍 [_Agile Testing_](https://wordery.com/agile-testing-lisa-crispin-9780321534460) , Jez Humble氏とDave Farley氏による書籍 [_Continuous Delivery_](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912) , Steve Freeman 氏 と Nat Price 氏 による書籍[_Growing Object-Oriented Software_](https://wordery.com/growing-object-oriented-software-guided-by-tests-steve-freeman-9780321503626) , Michael Feathers氏による書籍 [_Working Effectively with Legacy Code_](https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052), Ash Winter氏と Rob Meaney氏による書籍 [_Team Guide to Software Testability_](http://testabilitybook.com/) と Webサイト [TestabilityQuestions.com](http://TestabilityQuestions.com/) に基づいて評価基準を作成しています。 + +目的：*ソフトウェアシステム内のテストおよびテスト容易性へのアプローチを評価* + +方法：[Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/) のアプローチを使用して、次の質問に対するチームの回答を評価する: + +| **質問** | **うんざり (1)** | **すばらしい (5)** | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 1\. **テストファースト（クラス）** - **メソッドとクラスのテストをテストファーストで書く**時間の割合はどれくらいですか？ | 多くの場合、テストファーストのアプローチを使用する時間がない。 | 常にテストファーストのアプローチを使用している-それが良いソフトウェアを入手する唯一の方法だ！ | +| 2\. **テストファースト（機能）** - どのくらいの割合で、**機能と動作のテストをテストファーストで書き**ますか？ | 多くの場合、テストファーストのアプローチを使用する時間がない | 常にテストファーストのアプローチを使用している-それが良いソフトウェアを入手する唯一の方法だ！ | +| 3\. **ユニットテスト %** - どのくらいのコードカバレッジレベルで、**ユニットテスト**が成功したとみなしますか？ | ユニットテストは10％のカバレッジで成功とみなす。 | ユニットテストは80％以上のカバレッジで成功とみなす。 | +| 4\. **機能テスト %** - どのくらいの機能カバレッジレベルで、**機能テスト**（またはビヘイビアテスト）が成功したとみなしますか？ | 機能テストは10％のカバレッジで成功とみなす。 | 機能テストは100％以上のカバレッジで成功とみなす。 | +| 5\. **機能カバレッジ** - **機能テスト（またはビヘイビアテスト）でカバーされるコード内の機能の割合**はどのくらいですか？ | 機能の50％未満に対応する機能テストがある | すべての機能に、対応する機能テストが少なくとも1つある | +| 6\. **テストデータ** - **スクリプトから生成され**、データストアに自動的に挿入されるテストデータの割合はどのくらいですか？ | テストデータを設定するための手動プロセスがある | すべてのテストデータはスクリプトから生成され、自動テストの一部としてデータストアに挿入される | +| 7\. **デプロイメント** - デプロイメントパイプラインコードのどの部分に、**ビルドとデプロイの動作をカバーするテスト**がありますか? | ビルドおよびデプロイスクリプトをテストしない | ビルドおよびデプロイスクリプトの主要部分のテスト（デプロイ検証テストなど）があり、コードはモジュール式で適切に構造化されている | +| 8\. **テスト容易性** - **ソフトウェアをテストを可能にするために**あなたの時間のどの割合が費やされていますか？ | ソフトウェアをテスト可能にするための時間を費やしいない | ソフトウェアをよりテストしやすいものにするために、定期的にリファクタリングする-スプリントまたは週ごと | +| 9\. **CDCs/Pact/SemVer** - コンシューマ駆動契約（CDC）/ Pact / Semantic Versioningなど、**inter-team testing approaches**をどの程度使用していますか？ | 各コンポーネントまたはパッケージの最新バージョンを使用している | コンシューマ駆動契約（CDC） / Pactを使用して、インターフェイスの変更をテストする。 セマンティックバージョニングを使用して、重大な変更を含む変更の意味を伝える。Tolerant Readerパターンを使用して、重大な変更を一切行わないよう努めている。| +| 10\. **その他のコード** - **ポートフォリオ内の他のチームからのコード**について、あなたがうまく使える（ただし、実装はしない）自信はどれくらいありますか？ | 他のチームのコードは非常に不安定で予測ができない。 | 包括的な自動テストスイートにより、他のチームのコードは安心して使える。 | From 241d3776ba789d5f65582b7d1411aca2dc8fbfcd Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 20 Aug 2021 10:43:18 -0400 Subject: [PATCH 10/21] adding translations for operability --- translations/fr/operability.fr.md | 43 +++++++++++++++---------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/translations/fr/operability.fr.md b/translations/fr/operability.fr.md index a1c00b4..6edef1b 100644 --- a/translations/fr/operability.fr.md +++ b/translations/fr/operability.fr.md @@ -1,33 +1,32 @@ # Operability check -> **Part of the Multi-team Software Delivery Assessment** ([README](README.md)) +> **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) > -> Copyright © 2018-2019 [Conflux Digital Ltd](https://confluxdigital.net/) +> Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) > -> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> Sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) > > _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ -[OperabilityQuestions.com](http://OperabilityQuestions.com/)からの質問と、Matthew Skelton氏、Alex Moore氏、およびRob Thatcher氏による書籍[_Team Guide to Software Operability_](http://operabilitybook.com/) から選択した評価基準に基づいて作成しました。 +Basé sur les questions d’évaluation d’exploitabilité [Team Guide to Software Operability](http://operabilitybook.com/) de Matthew Skelton, Alex Moore et Rob Thatcher à [OperabilityQuestions.com](http://operabilityquestions.com/) -目的：*ソフトウェアの操作性-実稼働の準備 に関するチームの認識と実践を評価すること* +But : *Évaluer la connaissance et les pratiques de l’équipe par rapport à l’exploitabilité logicielle — préparation à la production.* -方法：[Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/) のアプローチを使用して、次の質問に対するチームの回答を評価する: +Méthode : Utilisez l’approche [*Spotify Squad Health Check*](https://labs.spotify.com/2014/09/16/squad-health-check-model/) pour évaluer les réponses de l’équipe aux questions suivantes, et consignez les réponses : -| **質問** | **しんどい (1)** | **すばらしい (5)** | +| **Question** | **Fatigué (1)** | **Inspiré (5)** | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1\. **コラボレーション** - 運用機能（ログ、監視、アラートなど）や非機能要件など、システムの運用面で他のチームとどのくらいの頻度で、どのように協力していますか? | リリース後に、サービスチームの要求により必要に応じて対応する | 仕事やプロジェクトの最初の週から運用面で協力する | -| 2\. **運用コスト** - 製品の予算とチームの努力のどの部分が運用面の対処に費やされていますか？ これをどのように計測しますか？ \[インフラコストを無視し、チームの努力に集中する\] | 運用面での時間と労力をできる限り少なくしようとしている/運用面での支出を計測していない| 時間と予算の約30％を運用面に費やしている | -| 3\. **機能の切り替え** - システムでどの機能（機能スイッチ）がアクティブであるかをどのように知ることができますか? | どの機能がアクティブかを判断するために、設定ファイルの差分を比較する必要がある | 環境内の機能のアクティブ/非アクティブを確認するシンプルなUIまたはAPIがある | -| 4\. **設定のデプロイ** - ソフトウェアを再デプロイせずに構成変更を反映するにはどうすればよいですか? | ソフトウェアをデプロイするか、停止せずに設定変更を反映できない | ソフトウェアとは別に設定変更作業を実施する/ソフトウェアを停止することなく、設定変更を実施できる | -| 5\. **システムの健全性** - システムが健全（または不健全）であることをどのようにして知ることができますか? | ソフトウェアが正常かどうかを確認するために、別のチームに手動チェック実施してもらう | 標準のHTTPヘルスチェックURLを使用してソフトウェアに問い合わせし、コードに記述したロジックに基づいてHTTP 200/500を返します。また、主要なシナリオの合成トランザクションモニタリングを使用する | -| 6\. **サービスKPI** - メインサービス/システムの主要業績評価指標（KPI）を追跡するにはどうすればよいですか? 何をKPIに設定していますか? | サービスKPIが定義されていない | ロギングおよび/または時系列メトリックを使用して、ダッシュボードで取得できるサービスKPIを定義している | -| 7\. **ロギング動作** - ロギングが正しく機能していることをどのようにして知ることができますか? | ロギングが機能しているかどうかはテストしていない |特定のアプリケーションの動作が実行された後に、特定のログメッセージ文字列を検索するBDD機能テストを実行、ロギングが機能していることをテストし、中央ログ集約/検索システムでログが正しく表示されることを確認できる | -| 8\. **テスト容易性** - ソフトウェアシステムのテストが簡単であると言えますか? 何を誰に提供しますか? | ソフトウェアを簡単にテストできるようにすることを明確に目指していない |デプロイメント・パイプライン内のソフトウェアのすべての部分に対してクライアントと外部テストパックを実行する | -| 9\. **TLS証明書** - SSL / TLS証明書の有効期限が近づいたことをどのようにして知ることができますか? | 証明書の有効期限がいつなのかわからない| 証明書の自動更新と証明書監視/アラートツールを組み合わせて使用​​し、証明書の有効期限が切れるときにライブチェックを行い、事前に是正措置ができる | -| 10\. **機密データ** - ログ内の機密データをマスクまたは非表示にするにはどうすればよいですか? | ログ内の機密データのテストはしていない | 特定のアプリケーションの動作した後に、特定のログメッセージ文字列を検索するBDD機能テストを使用して、データマスキングが発生していることをテストする | -| 11\. **パフォーマンス** - システム/サービスのパフォーマンスが許容範囲内で機能することをどのようにして知ることができますか? | サービスまたはアプリケーションのパフォーマンスの検証は、パフォーマンスチームのみに依存している | バージョン管理へのすべてのチェックインで実行されるデプロイメント・パイプライン内で一連のパフォーマンステストを実行する | -| 12\. **故障モード** - システムのさまざまな既知の故障モード（故障シナリオ）をどのように確認して共有しますか? | システムがどのように故障するかを本当に知らない | エラー識別子のセットを使用して、ソフトウェアの故障モードを定義し、これらの識別子をログメッセージで使用する | -| 13\. **呼び出しトレース** - システムでE2Eでコール/リクエストをトレースするにはどうすればよいですか? | システムで呼び出しをトレースできない | OpenTracingなどの標準トレースライブラリを使用して、システム全体の呼び出しをトレースする。 他のチームと協力して、コンポーネントの境界を越えて正しいトレースフィールドが維持されるようにする | -| 14\. **サービスの状況** - 現在のサービス/システムステータスを運用担当チームにどのように表示していますか? | 運用チームが、サービスの監視項目を発見する傾向がある | 運用チームと協力してダッシュボードを構築し、UXを重要な考慮事項としてユーザーフレンドリーな方法で必要なすべての詳細情報が得られるようにしている | - +| 1\. **Collaboration** - À quelle fréquence et de quelle façon collaborons-nous avec d’autres équipes sur les aspects opérationnels du système comme les fonctionnalités opérationnelles (journalisation, surveillance, alerte, etc.) et les exigences non fonctionnelles (ENF)? | Nous répondons à la nécessité d’aspects opérationnels après le lancement lorsque les équipes de service en direct émettent des billets. | Nous collaborons sur les aspects opérationnels dès la première semaine de la mobilisation ou du projet. | +| 2\. **Dépense pour l’exploitabilité** - Quelle proportion du budget du produit et de l’effort d’équipe est dépensée pour les aspects opérationnels? Comment en fait-on le suivi? \[Ignorez les coûts d’infrastructure et mettez l’accent sur l’effort d’équipe\]. | Nous essayons de consacrer le moins de temps et d’efforts possible aux aspects opérationnels/Nous ne suivons pas du tout les dépenses consacrées aux aspects opérationnels. | WNous consacrons environ 30 % de notre temps et de notre budget aux aspects opérationnels, et nous signalons si l’accent mis sur les aspects opérationnels diminue. | +| 3\. **Bascules de fonctionnalités** - Comment savons-nous quelles bascules de fonctionnalités (commutateurs de fonctionnalités) sont actives pour ce sous-système? | Nous devons exécuter les différences sur des fichiers de configuration pour déterminer les bascules de fonctionnalités qui sont actives. | Nous avons une interface utilisateur ou une API simple pour signaler les indicateurs de fonctionnalité active/inactive dans un environnement. | +| 4\. **Déploiement de configuration** - Comment déployer une modification de configuration sans redéployer le logiciel? | Nous ne pouvons pas déployer une modification de configuration sans déployer le logiciel ou provoquer une interruption. | Nous exécutons simplement un déploiement de configuration séparément du logiciel/Nous déployons la configuration avec le logiciel sans interruption. | +| 5\. **Santé du système** - Comment savons-nous que le système est sain (ou malsain)? | Nous attendons les vérifications faites manuellement par une autre équipe pour nous dire si notre logiciel est sain. | Nous recherchons le logiciel à l’aide d’une adresse URL de vérification de santé HTTP standard, retournant HTTP 200/500, etc. en fonction de la logique que nous écrivons dans le code, et avec la surveillance synthétique des transactions pour les scénarios clés. | +| 6\. **IRC du service** - Comment suivre les principaux indicateurs de rendement clés (IRC) du service/système? Quels sont les IRC? | Nous n’avons pas d’IRC de service définis. | Nous utilisons des mesures de journalisation ou de séries chronologiques pour émettre des IRC de service récupérés par un tableau de bord. | +| 7\. **Fonctionnement de la journalisation** - Comment savons-nous que la journalisation fonctionne correctement? | Nous ne vérifions pas si la journalisation fonctionne. | Nous testons que la journalisation fonctionne à l’aide de tests de fonctionnalité BDD qui recherchent des chaînes de messages de journal précises après l’exécution d’un comportement d’application particulier, et nous pouvons voir que les journaux apparaissent correctement dans le système central d’agrégation ou de recherche de journaux. | +| 8\. **Testabilité** - Comment montrer que le système logiciel est facile à tester? Que fournissons-nous et à qui? | Nous ne visons pas explicitement à rendre nos logiciels facilement testables. | Nous exécutons des clients et des paquets de tests externes sur toutes les parties de notre logiciel dans notre pipeline de déploiement. | +| 9\. **Certificats TLS** - Comment savons-nous quand un certificat SSL/TLS est sur le point d’expirer? | Nous ne savons pas quand nos certificats expireront. | Nous utilisons le renouvellement automatique des certificats combiné à des outils de surveillance ou d’alerte des certificats pour vérifier en temps réel quand les certificats expireront, afin de pouvoir prendre des mesures correctives à l’avance. | +| 10\. **Données sensibles** - Comment veiller à ce que les données sensibles dans les journaux soient masquées ou cachées? | Nous ne testons pas les données sensibles dans les journaux. | Nous vérifions que le masquage des données se produit en utilisant des tests de fonctionnalité BDD qui recherchent des chaînes de messages de journal précises après l’exécution d’un comportement d’application particulier. | +| 11\. **Rendement** - Comment savons-nous que le système ou service fonctionne dans des plages acceptables? | Nous comptons uniquement sur l’équipe chargée du rendement pour valider le rendement de notre service ou application. | Nous exécutons un ensemble de tests de rendement indicatifs dans notre pipeline de déploiement qui sont exécutés à chaque enregistrement pour le contrôle de version. | +| 12\. **Modes d’échec** - Comment pouvons-nous voir et partager les différents modes d’échec connus (scénarios d’échec) du système? | Nous ne savons pas vraiment comment le système pourrait échouer. | Nous utilisons un ensemble d’identificateurs d’erreurs pour définir les modes d’échec dans notre logiciel et nous utilisons ces identificateurs dans nos messages de journal. | +| 13\. **Suivi des appels** - Comment suivre un appel ou une demande de bout en bout dans tout le système? | Nous ne suivons pas les appels dans tout le système. | Nous utilisons une bibliothèque de suivi standard comme OpenTracing pour suivre les appels dans tout le système. Nous collaborons avec d’autres équipes afin de veiller à ce que les bons champs de suivi soient maintenus au-delà des limites des composants. | +| 14\. **État du service** - Comment afficher l’état actuel du service ou système aux équipes des opérations? | Les équipes des opérations ont tendance à découvrir elles-mêmes les indicateurs de statut. | Nous élaborons un tableau de bord en collaboration avec les équipes des opérations afin qu’elles aient tous les détails dont elles ont besoin de manière conviviale avec UX une considération clé. | From 15f2c22820e97c3b1a648458ec79fe8a5de6bae9 Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 20 Aug 2021 13:47:11 -0400 Subject: [PATCH 11/21] adding translations for README --- translations/fr/README.fr.md | 278 ++++++++++++++++++----------------- 1 file changed, 146 insertions(+), 132 deletions(-) diff --git a/translations/fr/README.fr.md b/translations/fr/README.fr.md index e116759..196177f 100644 --- a/translations/fr/README.fr.md +++ b/translations/fr/README.fr.md @@ -1,166 +1,180 @@ # Multi-team Software Delivery Assessment -Multi-team Software Delivery Assessmentは、組織内のさまざまなチームのソフトウェア・デリバリーを評価するためのシンプルで実行しやすい手法です。 　　　　 +L’évaluation de la livraison de logiciels à plusieurs équipes est une approche simple et facile à exécuter pour évaluer la livraison de logiciels dans de nombreuses équipes différentes dans une organisation. Conçue par [Matthew Skelton](https://github.com/matthewskelton) de [Conflux](https://confluxdigital.net/), elle est utilisée comme élément clé de Software Delivery Assessment à Conflux, mais peut être utilisé librement par n’importe qui (sous réserve de la licence CC BY-SA ci-dessous). -この評価手法は、よく知られ実績のある[Spotify Squad Health Check model](https://labs.spotify.com/2014/09/16/squad-health-check-model/)を基にしており、以下合計6つの観点をカバーしています。 +L’évaluation utilise et met à profit le modèle bien connu et éprouvé de [Spotify Squad Health Check model](https://labs.spotify.com/2014/09/16/squad-health-check-model/). -1. [Team Health](team-health.ja.md) -2. [Deployment](deployment.ja.md) -3. [Flow](flow.ja.md) -4. [Continuous Delivery](continuous-delivery.ja.md) -5. [Operability](operability.ja.md) -6. [Testing and Testability](testability.ja.md) +> Traductions: [Japanese (ja 🇯🇵)](translations/ja/README.ja.md), [English (en)](translations/en/README.en.md) -これら6つの観点は、最新のソフトウェア・デリバリーのすべての重要事項を網羅していて、チームがそれぞれの長所とプラクティスを自己評価できます。 +L’évaluation porte sur huit dimensions au total : -**🚀 概要**: [Continuous Delivery at scale](https://www.slideshare.net/matthewskelton/continuous-delivery-at-scale-matthew-skelton-nhs-digital-agile-cop-march-2019)のスライド32〜38を参照してください。 +1. [Santé de l’équipe](team-health.md) +2. [Déploiement](deployment.md) +3. [Flux](flow.md) +4. [Livraison continue](continuous-delivery.md) +5. [Exploitabilité](operability.md) +6. [Essais et testabilité](testability.md) +7. [Fiabilité et IFS](reliability.md) +8. [Sur appel](on-call.md) -> Copyright © 2018-2019 [Conflux Digital Ltd](https://confluxdigital.net/) +Ces huit dimensions couvrent les aspects clés de la livraison de logiciels modernes sous une forme qui permet aux équipes d’évaluer eux-mêmes leurs forces et leurs pratiques. + +**🚀 Aperçu**: voir Diapositives 32-38 dans [Continuous Delivery at scale](https://www.slideshare.net/matthewskelton/continuous-delivery-at-scale-matthew-skelton-nhs-digital-agile-cop-march-2019) + +**🃏 Jeu de cartes**: Rendre l’évaluation amusante et interactive à l’aide de [the 66-card Software Delivery Assessment printed card deck from Agile Stationery](https://agilestationery.co.uk/pages/software-delivery-assessment). Élaboré en collaboration avec Conflux, le jeu de cartes comporte des indicateurs Fatigué et Inspiré pour chacun des critères d’évaluation, ainsi que des cartes émoticônes pour le vote rapide des membres de l’équipe. Le jeu de cartes fonctionne aussi pour les évaluations à distance! + +Assessment cards from Agile Stationery Five emoji voting cards + +> Droit d’auteur © 2018-2021 © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) > -> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> Sous-licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) > > _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ -## 評価の目的 - -ソフトウェアシステムを構築および実行するためのポジティブな作業環境の促進、および維持することが評価の目的です。 -ポジティブな作業環境では、以下の状況が発生します。 - - - ソフトウェアの変更は、継続的デリバリーの手法を使用して、**迅速かつ安全に**ビルドされ、テストされ、プロダクション環境にリリースされる。 - - プロセスとプラクティスは、**リリースに向けたソフトウェアの変更フロー**に最適化される。 - - ソフトウェアは、1つ１つ分断されたシステムに対して**独立、分離したリリース**ができるように設計および構築される。 - - ソフトウェアは、**運用性**、**テスト容易性**、および**リリース容易性**を考慮して設計および構築される。 - - ソフトウェアプロダクト、ソフトウェア生産過程での問題が、顧客やユーザーが気付く前に常に**チームによって検出される**。 - - 開発者がソフトウェアの変更に対する責任と**説明責任**を持ち、開発者のエンパワーメントとオーナーシップに繋がる。 - - ソフトウェア開発が、**やりがいのあり**、楽しいものになる。 - - **悪い慣習と悪いアプローチに挑み、変えること** に自信が持てるようになる。 - -基本的にMulti-team Software Delivery Assessmentは**チームを解放して活性化**し、チームが成功するのに役立ちます。この評価手法は、様々な改善点を特定することにより、**チームがソフトウェアシステムの構築、テスト、およびリリースを改善する**のを手助けします。 -改善点には、以下があります。 - -1.チーム中心の改善点 -2.製品中心およびサービス中心の改善点 -3.組織全体の改善点 - -この評価手法は、チームにペナルティを科すために使用するべきではなく、プラクティスと品質の改善に向けて、共有される意欲を提供するために使用するべきです。 - -## 評価対象のチーム - -アプリケーションソフトウェアまたはインフラストラクチャのコード、スクリプトの作成、またはそれらの設定を行うすべてのチームが評価対象となり、評価することでメリットがあります。 -評価対象のチームは以下になります。 - - - **ユーザー向け-のWebサイトとサービス**、**顧客向けのWebサイトとサービス**を構築するチーム - - **内部サービス**を構築するチーム - - 他のシステムをサポートする**インフラストラクチャ**を構築するチーム（プラットフォームチームを含む） - - **ビルド とデプロイメント**ツール、スクリプトを構築するチーム - - ソフトウェアおよびインフラストラクチャの一部としてCOTS製品を構成およびテストするチーム - - その他、**ソフトウェアおよびインフラストラクチャの構築、構成、およびテスト** に主眼をおくチーム - -"チーム"とは、人材連携の度合いの大きい6-10人のグループを意味します。通常、**Squad**、**Scrumチーム**、**Productチーム**、または **Stream-alignedチーム**と呼ばれます。 - -## 評価基準 - -各観点の評価基準は、既存の出版された書籍、およびオンラインソースから取得しています。 - -* **Team Health** - [_Spotify Squad Health Check_](https://labs.spotify.com/2014/09/16/squad-health-check-model/) の評価基準に基づき作成し、いくつかのチェック項目を追加しました。。 -* **Deployment** - Mirco Hering氏のブログ投稿[_DevOps for the Modern Enterprise_](https://itrevolution.com/book/devops_modern_enterprise/) で説明されている書籍[_DevOps for the Modern Enterprise_](https://itrevolution.com/book/devops_modern_enterprise/) の主要な質問に基づいて作成しました。 -* **Flow** - Nicole Forsgren氏、Jez Humble氏、Gene Kim氏の書籍 [_Accelerate_](https://itrevolution.com/book/accelerate/) の評価基準に基づき作成し、Don Reinertsen 氏の書籍 [_The Principles of Product Development Flow_](https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009) から、いくつかチェック項目を追加しました。 -* **Contous Delivery** - Jez Humble氏とDave Farley氏による書籍 [_Continuous Delivery_](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912) と [CDchecklist.info](http://CDchecklist.info/) にある書籍の要約に基づいて作成しました。 -* **Operability** - [OperabilityQuestions.com](http://OperabilityQuestions.com/)からの質問と、Matthew Skelton氏、Alex Moore氏、およびRob Thatcher氏による書籍[_Team Guide to Software Operability_](http://operabilitybook.com/) から選択した評価基準に基づいて作成しました。 -* **Testing and Testability** - Lisa Crispin氏 と Janet Gregory氏による書籍 [_Agile Testing_](https://wordery.com/agile-testing-lisa-crispin-9780321534460) , Jez Humble氏とDave Farley氏による書籍 [_Continuous Delivery_](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912) , Steve Freeman 氏 と Nat Price 氏 による書籍[_Growing Object-Oriented Software_](https://wordery.com/growing-object-oriented-software-guided-by-tests-steve-freeman-9780321503626) , Michael Feathers氏による書籍 [_Working Effectively with Legacy Code_](https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052), Ash Winter氏と Rob Meaney氏による書籍 [_Team Guide to Software Testability_](http://testabilitybook.com/) と Webサイト [TestabilityQuestions.com](http://TestabilityQuestions.com/) に基づいて評価基準を作成しました。 - -## 評価の実行方法 - -評価セッション自体は、チームのふりかえりのように実施する必要があります。通常のふりかえりとの主な違いは、評価セッションではファシリテーターが議論をよりしっかりと導くことです。議論する多くの質問があり、チームが利用可能な時間内にすべての評価基準を議論することが重要です。 - -評価セッションの終わりには、チームは議論に基づいて、プロセスとプラクティスを改善するためにどのようなアクションを実行するかの決定を促され、エンパワーメントされたと感じる必要があります。 - -### 評価の実行頻度 - -多くの組織では、評価セッションを**3か月ごとに** 実行すると、良い結果が得られることがわかっています。 - -### 評価のための準備 - -1. 評価セッションのファシリテーターを見つけます。これは、チームのふりかえりに精通しているチーム外の人でなければなりません。 -2. 時間を2時間、チームに対して大きめのミーティングルームを確保します。 -3. [既製のA1 PDF（リリースを参照）](https://github.com/ConfluxDigital/software-delivery-assessment/releases)を使用するか、可能であればA1サイズで、以下の個々の評価ページ（小さなマージンを使用）を使用して、各観点の評価シートを印刷します。 - * [Team Health - 評価シート](print/print-team-health.ja.md) - * [Deployment - 評価シート](print/print-deployment.ja.md) - * [Flow - 評価シート](print/print-flow.ja.md) - * [Continuous Delivery - 評価シート](print/print-continuous-delivery.ja.md) - * [Operability - 評価シート](print/print-operability.ja.md) - * [Testing and Testability - 評価シート](print/print-testability.ja.md) -4. 詳細ページをガイドとして印刷（またはページを画面上で開く）して、各評価基準のコンテキストと詳細を理解します。 - 1. [Team Health](team-health.ja.md) - 2. [Deployment](deployment.ja.md) - 3. [Flow](flow.ja.md) - 4. [Continuous Delivery](continuous-delivery.ja.md) - 5. [Operability](operability.ja.md) - 6. [Testing and Testability](testability.ja.md) -5. マーカーまたはホワイトボードマーカーをたくさん用意してください。赤、青、緑が最適です。 -6. セッションに**ふりかえりのファシリテーションに精通している人**（おそらくスクラムマスター）を含めます。 チームのファシリテーター以外の人は、セッション中にファシリテーターから学習し、後に他の評価セッションでファシリテートできるようになります。 - -> **ファシリテーター** +## But des évaluations + +L’objectif des évaluations est de promouvoir et de maintenir un environnement de travail positif pour le développement et la gestion de systèmes logiciels où : + + - les modifications apportées aux logiciels sont élaborées, testées et déployées en production **rapidement et en toute sécurité** grâce aux pratiques de livraison continue; + - les processus et les pratiques sont **optimisés pour le flux de changement** vers la production; + - le logiciel est conçu et développé pour permettre des **déploiements indépendants et découplés** pour des familles séparées de systèmes; + - le logiciel est conçu et développé de manière à répondre aux exigences **d’exploitabilité**, **de testabilité**, **de capacité de libération** et **de fiabilité**; + - les problèmes de production sont toujours **détectés par les équipes** avant que les clients et les utilisateurs ne s’en rendent compte; + - la responsabilité et **l’obligation de rendre compte** des changements logiciels mènent à l’autonomisation et à la propriété; + - travailler avec un logiciel est **gratifiant** et intéressant; + - être sur appel et appuyer le logiciel sont **durables et précieux**; + - les gens se sentent **confiants de contester les mauvaises pratiques** et approches. + +Fondamentalement, les évaluations devraient aider à **débloquer et à permettre aux équipes** de réussir. Les évaluations doivent **aider les équipes à améliorer la façon dont elles développent, testent et déploient des systèmes logiciels** en identifiant différents types d’améliorations : + +1. Améliorations axées sur l’équipe. +2. Améliorations axées sur le produit et sur le service. +3. Améliorations à l’échelle de l’organisation. + +Les évaluations NE doivent PAS être utilisées pour pénaliser les équipes, mais pour fournir une volonté commune d’améliorer les pratiques et la qualité. + +## Équipes incluses dans les évaluations + +Chaque équipe qui écrit du code, des scripts ou une configuration pour les logiciels d’application ou l’infrastructure bénéficiera de l’inclusion dans les évaluations : + + - Équipes élaborant des **sites Web et des services destinés aux utilisateurs et aux clients**. + - Équipes élaborant des **services internes.** + - Équipes élaborant l’**infrastructure** pour appuyer d’autres systèmes (y compris les équipes de plateforme). + - Équipes élaborant des outils et des scripts de **développement et de déploiement**. + - Équipes **configurant et testant les produits LCPE** dans le cadre du domaine logiciel et d’infrastructure. + - Toute autre équipe qui mise principalement sur **l’élaboration, la configuration et la mise à l’essai des logiciels et de l’infrastructure**. + +Par « équipe », on entend un groupe de 6 à 10 personnes qui travaille en étroite collaboration, généralement appelé Équipe, Équipe du Scrum, Équipe de produit ou Équipe harmonisée par flux. + +## Critères d’évaluation + +Les critères de chaque dimension sont tirés des ouvrages et des sources en ligne existants : + +* **Santé de l’équipe** - Fondée sur les critères de [_Spotify Squad Health Check_](https://labs.spotify.com/2014/09/16/squad-health-check-model/) avec quelques ajouts. +* **Déploiement** - Fondé sur les questions clés du livre [_DevOps for the Modern Enterprise_](https://itrevolution.com/book/devops_modern_enterprise/) de Mirco Hering comme abordé dans l’article [Mirco’s self assessment questions of DevOps Maturity](https://notafactoryanymore.com/2018/03/01/mircos-self-assessment-questions-of-devops-maturity/) du blogue de Mirco. +* **Flux** - Fondé sur les critères du livre [_Accelerate_](https://itrevolution.com/book/accelerate/) de Nicole Forsgren, Jez Humble, et Gene Kim, en plus de certains détails de [_The Principles of Product Development Flow_](https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009) de Don Reinertsen. +* **Livraison continue** - onction sur des critères sélectionnés du livre [_Continuous Delivery_](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912) de Jez Humble et Dave Farley et le résumé du livre à [CDchecklist.info](http://CDchecklist.info/) +* **Exploitabilité** - Fondée sur des critères sélectionnés dans le livre [_Team Guide to Software Operability_](http://operabilitybook.com/) de Matthew Skelton, Alex Moore, et Rob Thatcher, ainsi que quelques questions de [OperabilityQuestions.com](http://OperabilityQuestions.com/) +* **Essais et testabilité** - Selon les critères sélectionnés dans les livres [_Agile Testing_](https://wordery.com/agile-testing-lisa-crispin-9780321534460) de Lisa Crispin et Janet Gregory, [_Continuous Delivery_](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912) de Jez Humble and Dave Farley, [_Growing Object-Oriented Software_](https://wordery.com/growing-object-oriented-software-guided-by-tests-steve-freeman-9780321503626) de Steve Freeman et Nat Price, [_Working Effectively with Legacy Code_](https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052) de Michael Feathers, [_Team Guide to Software Testability_](http://testabilitybook.com/) de Ash Winter et Rob Meaney, et [TestabilityQuestions.com](http://TestabilityQuestions.com/). +* **Fiabilité et IFS** - Selon les critères sélectionnés dans les livres [_Site Reliability Engineering_](https://sre.google/sre-book/table-of-contents/) de Betsy Beyer, Chris Jones, Jennifer Petoff, et Niall Murphy, [_The Site Reliability Workbook_](https://sre.google/workbook/table-of-contents/) édité par Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, et Stephen Thorne, [_Seeking SRE_](https://www.oreilly.com/library/view/seeking-sre/9781491978856/) édité par David N. Blank-Edelman, [_Team Guide to Software Operability_](http://operabilitybook.com/) de Matthew Skelton, Alex Moore, et Rob Thatcher. +* **Sur appel** - Selon les critères sélectionnés des livres [_Site Reliability Engineering_](https://sre.google/sre-book/table-of-contents/) de Betsy Beyer, Chris Jones, Jennifer Petoff, et Niall Murphy, [_The Site Reliability Workbook_](https://sre.google/workbook/table-of-contents/) édité par Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, et Stephen Thorne, [_Team Guide to Software Operability_](http://operabilitybook.com/) de Matthew Skelton, Alex Moore, et Rob Thatcher. + +## Comment exécuter les évaluations + +La séance d’évaluation elle-même devrait ressembler à une séance rétrospective d’équipe. La principale différence par rapport à une séance rétrospective normale est que, lors de la séance d’évaluation de l’équipe, l’animateur oriente plus fermement la discussion. Il y a beaucoup de questions à aborder, et il est important que l’équipe discute de tous les critères dans le temps disponible. + +À la fin de la séance d’évaluation, l’équipe devrait se sentir encouragée et habilitée à décider des mesures qu’elle souhaite prendre pour améliorer ses processus et ses pratiques en se fondant sur les discussions. + +### Fréquence + +De nombreuses organisations jugent que l’évaluation des équipes **tous les trois mois** donne de bons résultats. + +### Préparation + +1. Trouvez quelqu’un pour faciliter l’évaluation. Il devrait s’agir de quelqu’un de l’extérieur de l’équipe, qui connaît bien les rétrospectives de l’équipe d’exécution.   +2. Réservez un créneau horaire de deux ou trois heures : pour les séances en ligne, vous pouvez les répartir sur deux séances d’appel vidéo ou plus, et pour les séances en personne, réservez une salle assez grande pour l’équipe. +3. Pour les séances en ligne, utilisez le jeu de cartes de Agile Stationery et la capture d’écran ou notez les résultats dans une feuille de calcul, ou utilisez un outil de sondage en ligne pour consigner les réponses des personnes à la séance. Pour les **séances en personne**, utilisez le jeu de cartes de Agile Stationery, ou imprimez les feuilles d’évaluation pour chaque ensemble de critères, soit en utilisant le PDF A1 prêt à l’emploi (voir Versions), soit les pages d’évaluation individuelles de taille A1 si possible (utilisez de petites marges) : + * [Santé de l’équipe – fiche d’évaluation](print/print-team-health.md) + * [Déploiement – fiche d’évaluation](print/print-deployment.md) + * [Flux – fiche d’évaluation](print/print-flow.md) + * [Livraison continue – fiche d’évaluation](print/print-continuous-delivery.md) + * [Exploitabilité – fiche d’évaluation](print/print-operability.md) + * [Essais et testabilité – fiche d’évaluation](print/print-testability.md) + * [Fiabilité et IFS – fiche d’évaluation](print/print-reliability.md) + * [Sur appel – fiche d’évaluation](print/print-on-call.md) +4. Pour **les séances en ligne**, affichez les critères Fatigué et Inspiré à l’écran en même temps que la question. Pour **les séances en personne**, imprimez les pages de détails comme guide ou ouvrez-les à l’écran pour comprendre le contexte et les détails de chacun des critères d’évaluation : + 1. [Santé de l’équipe](team-health.md) + 2. [Déploiement](deployment.md) + 3. [Flux](flow.md) + 4. [Livraison continue](continuous-delivery.md) + 5. [Exploitabilité](operability.md) + 6. [Essais et testabilité](testability.md) + 7. [Fiabilité et IFS](reliability.md) + 8. [Sur appel](on-call.md) +5. Il est utile de saisir les détails et les nuances des discussions entourant chaque question. Pour **les séances en ligne**, demandez à quelqu’un de prendre des notes dans un document ou un tableau blanc partagé. Pour **les séances en personne**, apportez beaucoup de stylos marqueurs ou de marqueurs de tableau blanc : le rouge, le bleu et le vert sont les meilleures couleurs. +6. Incluez dans la séance une **personne qui sait animer des rétrospectives** (peut-être un maître du scrum). Ils suivront l’animateur pendant la séance afin que la personne de votre équipe puisse animer d’autres séances d’évaluation plus tard. + +Assurez-vous que l’animateur comprend le but de la séance et qu’il connaît bien les pages et les questions de l’évaluation. + +> **Animateurs** > -> ファシリテーターは、セッションを実行する前に[Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/)のアプローチに慣れる必要があります。優れたレポートとして、[How I Used the Spotify Squad Health Check Model](http://www.barryovereem.com/how-i-used-the-spotify-squad-health-check-model/)、SkyBet [Squad Health Checks](https://engineering.skybettingandgaming.com/2017/02/01/squad-health-checks/)で公開されており、また、SpotifyからSquad Health Checkの説明文書([PDF](https://spotifylabscom.files.wordpress.com/2014/09/squad-health-check-model2.pdf)) がダウンロードできます。 +> L’animateur doit se familiariser avec l’approche [Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/) avant d’exécuter la séance. Voir [How I Used the Spotify Squad Health Check Model](http://www.barryovereem.com/how-i-used-the-spotify-squad-health-check-model/) our un bon rapport sur l’expérience, [Squad Health Checks](https://engineering.skybettingandgaming.com/2017/02/01/squad-health-checks/) de SkyBet, et téléchargez les instructions de Spotify ([PDF](https://spotifylabscom.files.wordpress.com/2014/09/squad-health-check-model2.pdf)). > -> 評価セッション中に実施すること: +> Au cours de l’évaluation : > -> * いくつか議題が長引く場合は、セッションの外でディスカッションを行うように依頼して、セッションがスケジュール通り進むようにします。 -> * 印刷された評価シートにチームのスコアとメモを書き留めます。 -> * 完成した評価シートの写真を撮ります。 -> * エンジニアリング評価の意義と実施結果についてチームからフィードバックを受け取ります。 - 笑顔で十分です。 +> * tenez l’équipe à l’heure prévue en demandant que certaines discussions se tiennent en dehors de la séance; +> * rédigez les notes et les commentaires de l’équipe sur les fiches d’évaluation imprimées ou assurez-vous que les notes et les commentaires sont saisis dans un outil numérique; +> * prenez des photographies des fiches d’évaluation remplies pour **les séances en personne**; +> * obtenez la rétroaction de l’équipe sur la VALEUR et l’EXÉCUTION de l’évaluation technique – les émoticônes souriants sont assez! > -### 時間調整 - -チーム評価セッションは2時間で実行され、ファシリテーターは6つの観点の質問を通して、セッションをファシリテートします。 +### Horaire -1. Team health check - **35分** -2. Deployment health check - **10分** -3. Flow check - **10分** -4. Continuous Delivery check - **20分** -5. Operability check - **20分** -6. Test coverage check - **20分** +Chaque évaluation de l’équipe dure deux à trois heures, et l’animateur dirigera l’équipe au moyen de huit séries de questions : -これら6つの評価の間に**5分の休憩**を挟みます。 +1. Vérification de la santé de l’équipe - **35 mins** +2. Vérification de l’état du déploiement - **10 mins** +3. Vérification du flux - **10 mins** +4. Vérification de livraison continue - **20 mins** +5. Vérification de l’exploitabilité - **20 mins** +6. Vérification de la couverture des essais - **20 mins** +7. Fiabilité et IFS - **30 mins** +8. Sur appel - **15 mins** -### 評価セッションの実行 +Cet horaire laisse place à une **pause de 10 minutes** pendant l’évaluation. -各セクションにはいくつかのルールがあります。各質問には以下の記載事項を意識して回答する必要があります。 +### Exécution de la séance d’évaluation - - チームは、個人またはチームとして、***Tired* and *Inspired*** ガイドラインに基づいて、SAD（1 OR 2）/MEH（3）/ YAY（4 OR 5） を使用して各評価基準を評価します。 +Chaque section comporte plusieurs questions. On doit répondre à chaque question comme suit : - - *Tired (しんどい)* は評価が低く (1), *Inspired (すばらしい)* は評価が高い (5) です。　　　　 + - L’équipe (soit à titre individuel, soit à titre d’équipe) évalue chacun des critères à l’aide de TRISTE (1 OU 2)/PFFF (3)/OUAIS (4 OU 5) selon les directives ***Fatigué* et *Inspiré***. - - 個人ごとに評価した場合は、評価を集計し、1-5の単一のチームスコアを決定します。印刷されたシートに異なる色のペンを使用して、異なる評価を視覚的に示すと便利です。 - - - 過去に評価を実施している場合は、前回のスコアに対する**トレンド** を決定します。(上がった, 変わらない, 下がった) - - - 今後数カ月にわたり、評価基準のスコア改善することに**同意します**。 + - *Fatigué* correspond à une faible cote (1), et *Inspiré* correspond à une cote élevée (5). - - **メモ**欄を使用して、評価のまとめ役が知る必要があると思われる詳細情報を示します。 + - Si vous avez utilisé des évaluations individuelles, regroupez les évaluations ou décidez d’une note d’équipe unique entre 1 et 5. Vous pouvez trouver utile d’utiliser différents stylos colorés sur la fiche imprimée pour indiquer visuellement les différentes évaluations. + + - La **tendance** depuis la période précédente est indiquée (en hausse, en demeurant à peu près la même, en baisse), le cas échéant. + + - Une **mesure** convenue pour améliorer la note à cette question au cours des prochains mois. - - 各シートの下部にある **日付/名前/ファシリテーター** 欄に必ず情報を記入します。 - - - 記入済みの各シートの写真を撮り、評価のまとめ役に送信します。 - - - チームメンバーに次の観点から評価セッション自体を評価してもらいます： **価値**、**実行** （悪い、まあまあ、良い） + - Utilisez la colonne **Notes** pour indiquer d’autres renseignements que vous pensez utiles pour l’équipe de coordination. -### ファシリテーションを促進する + - Assurez-vous de remplir les détails **Date/Nom/Animateur**. -各チームの評価セッションには、ファシリテーターから学習している人物が参加しているため、今後のセッションをファシリテートすることができます。新しいファシリテーターはそれぞれ、少なくとも2つの他のチームとのセッションをファシリテーションする必要があります。このようにして、ファシリテーターの数は急速に拡大し、最初のファシリテーターの負担を最小限に抑えることができます。 + - Pour les séances en personne, prenez une photo de chaque fiche remplie et envoyez-la à la personne qui coordonne les évaluations. -## 結果の調整と解釈 + -  Demandez aux membres de l’équipe d’évaluer la séance d’évaluation elle-même en fonction des éléments suivants : **Valeur**, **Exécution** (visages triste, agacé, heureux). -各チームが評価セッションを実行して結果を送信した後、評価のまとめ役は異なるチームの結果を照合し、組織全体で改善が必要な領域を特定する必要があります。 -改善が必要な領域を特定するには、次のような質問をします。 +### Animation virale -* チームABCがテストカバレッジについて1と評価するのは何故ですか？ スコアの上昇を妨げているものは何ですか？ +Chaque séance d’évaluation de l’équipe présente une personne qui suit l’animateur afin qu’elle puisse faciliter elle-même les séances futures. Chaque nouvel animateur devrait animer au moins deux séances avec d’autres équipes. De cette façon, le nombre d’animateurs augmente rapidement, ce qui permet un fardeau minimal pour les animateurs initiaux. -* より多くのチームのリリースを支援するために、組織として何ができますか？ +## Coordination et interprétation des résultats -* チームがよりよく、効率良く作業できるようにプラットフォーム側が改善するべき点はありますか？ +Une fois que les équipes ont organisé une séance d’évaluation et envoyé leurs résultats, le groupe de coordination doit recueillir les résultats des différentes équipes afin d’identifier les domaines qui doivent être améliorés dans l’ensemble de l’organisation. Posez des questions comme les suivantes : -チームを直接ランク付けまたは比較しようとしないでください。代わりに、チームからのシグナルを使用して組織のダイナミクスをより理解し、組織全体の改善に優先順位を付けます。 +* Pourquoi l’équipe ABC se note-t-elle à 1 pour la couverture des essais? Qu’est-ce qui les gêne? +* Que pouvons-nous faire en tant qu’organisation pour aider plus d’équipes à effectuer des déploiements? +* Y a-t-il un aspect de la Plateforme qui doit être amélioré pour que les équipes puissent aller plus vite? +N’essayez pas de classer ou de comparer directement les équipes. Au lieu de cela, utilisez les signaux des équipes pour mieux comprendre la dynamique organisationnelle, puis prioriser les améliorations à l’échelle de l’organisation. \ No newline at end of file From bf6097c54c48141761d64f9c1d9d953eab041ae5 Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 20 Aug 2021 13:55:17 -0400 Subject: [PATCH 12/21] adding translations for team-health --- translations/fr/team-health.fr.md | 42 +++++++++++++++---------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/translations/fr/team-health.fr.md b/translations/fr/team-health.fr.md index fb5b53b..94345dd 100644 --- a/translations/fr/team-health.fr.md +++ b/translations/fr/team-health.fr.md @@ -1,32 +1,32 @@ # Team Health check -> **Part of the Multi-team Software Delivery Assessment** ([README](README.md)) +> **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) > -> Copyright © 2018-2019 [Conflux Digital Ltd](https://confluxdigital.net/) +> Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) > -> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> Sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) > > _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ -[Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/)とGoogleの[Project Aristotle](https://rework.withgoogle.com/print/guides/5721312655835136/)からの洞察に基づいて作成しました。 +Basé sur le [Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/) combiné avec les idées du [Project Aristotle](https://rework.withgoogle.com/print/guides/5721312655835136/) de Google. -目的： *ソフトウェア・デリバリー単位ごとのチームの健康と自信を評価すること* +But :  *Évaluer la santé et la confiance de l’équipe en tant qu’unité de prestation.* -方法：[Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/) のアプローチを使用して、次の質問に対するチームの回答を評価する: +Méthode : Utilisez l’approche [Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/) pour évaluer les réponses de l’équipe aux questions suivantes : -| **質問** | **しんどい (1)** | **すばらしい (5)** | +| **Question** | **Inspiré (1)** | **Fatigué (5)** | | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | -| 1\. **リリースが容易** - 作業中のソフトウェア変更をリリースするのは簡単ですか？ | リリースするのは難しい |リリースするのは簡単で分かりやすい | -| 2\. **適切なプロセス** - ソフトウェアの開発とリリースのプロセスは適切ですか？ | プロセスは面倒で役に立たない | プロセスはほとんどが隠されていて、ほとんど意識することがない | -| 3\. **技術品質** (コードベースの健全性) - コードベースはどれくらい健全ですか？ | コードには、回避策と危険領域が山積みされている | コードはクリーンで安全に使用でき、十分にテストされている| -| 4\. **顧客またはユーザーの価値** - チームはビジネスとして価値あることに取り組んでいますか？ | 顧客またはユーザーの価値から切り離されている| 顧客またはユーザーの価値重視のチームアプローチを採用し、実践している | -| 5\. **スピード** - チームとしてどれくらい迅速に仕事をしていますか？ | 物事を成し遂げるために長い時間がかかる| 共々に迅速な仕事を提供している| -| 6\. **ミッション** - ミッションに取り組んでいる理由をどれだけ知っていますか？ | ミッションは明確ではない | すべての利害関係者と共有する明確なミッションがある| -| 7\. **楽しさ** - チームで働くのはどれほど楽しいですか？ *仲間意識*とチームワークの意識はどのくらいですか？ | チームに楽しさはない | チームの毎日は楽しい| -| 8\. **学び** - チームとしてどれくらい学びがありますか？ | 新しいことはほとんど学ばない | 毎日何かを学ぶ | -| 9\. **サポート** - チームとしてどれくらいのサポートが得られますか？ | チームとしてのサポートはほとんどない | チームとして十分にサポートされている | -| 10\. **ポーンか？プレイヤーか？** - 作業内容とその手段をどの程度管理していますか？ | 自分たちが取り組んでいることについて、チェスのポーンのようにプロセス、作業そのものを変更することはできない。 | 自分たちが取り組んでいることについて、チェスのプレイヤーのようにプロセス、作業そのものを変更でき、強い影響を与えることができる| -| 11\. **心理的安全性** - 懸念を提起することに対する安全性はどの程度ですか？ | 懸念を提起した場合、自分たちの叫びは無視される | 懸念は評価され、チームと組織の改善に役立てられる | -| 12\. **周りのチーム** - あなたの周りのチームはあなたとあなたのチームとどれくらいうまく働いていますか？ | 周りのチームは役に立たずで、失礼な振る舞いをする | 周りのチームはとてもフレンドリーで親切で、他のチームと仕事をすることに喜びを感じる| -| 13\. **ソフトウェア・デリバリープラットフォーム** - チームのソフトウェア・デリバリーを支えるソフトウェア・デリバリープラットフォームはどれほど効果的で使いやすいですか？ | ソフトウェア・デリバリープラットフォームは自分たちの作業を妨害しているようで、使用が難しい | このプラットフォームは自分たちの開発を加速させるもので、迅速かつ安全にソフトウェア・デリバリーするのに役立っている。 ソフトウェア・デリバリープラットフォームが好きだ。| -| 14\. **経営スタイル** - 経営陣やその他の上級管理者によるアプローチは、どの程度効果的かつ適切ですか？ | 管理アプローチは本当に自分たちの努力を妨げている | 管理アプローチは、迅速かつ安全にソフトウエアをリリースする助けとなる| +| 1\. **Diffusion facile** - À quel point est-il facile de diffuser un changement au logiciel sur lequel vous travaillez? | Il est difficile de diffuser un changement. | Il est facile et simple de diffuser un changement. | +| 2\. **Processus approprié** - Quel est le processus approprié pour le développement et la livraison de logiciels? | Le processus est lourd et peu utile. | Le processus est essentiellement caché et nous le sentons à peine. | +| 3\. **Qualité technique** (santé de base de codes) – Quel est l’état de santé de la base de codes? | Notre base de codes est remplie de solutions de rechange et des zones dangereuses. | Notre base de codes est propre, sécuritaire et bien testée. | +| 4\. **Valeur** - Travaillez-vous sur des choses précieuses en équipe? | Nous sommes déconnectés de la valeur client ou utilisateur. | Nous vivons et respirons une approche d’équipe axée sur la valeur. | +| 5\. **Vitesse** - À quelle vitesse travaillez-vous en équipe? | Il semble que nous prenions du temps pour faire avancer les choses. | Nous travaillons rapidement ensemble. | +| 6\. **Mission** - Savez-vous pourquoi vous travaillez sur des choses? | Il est rare de savoir clairement quelle est notre mission. | Nous avons une mission claire que nous partageons avec tous les intervenants. | +| 7\. **Plaisir** - Est-ce plaisant de travailler dans votre équipe? Quel niveau de camaraderie et quel sens du travail d’équipe? | Le plaisir est rarement un aspect de notre travail d’équipe. | L’équipe est un endroit plaisant tous les jours. | +| 8\. **Apprentissage** - Combien apprenez-vous en équipe? | Nous apprenons rarement quelque chose de nouveau. | Nous apprenons quelque chose chaque jour. | +| 9\. **Soutien** - Quel soutien obtenez-vous en tant qu’équipe? | Nous obtenons très peu de soutien en tant qu’équipe. | Nous sommes bien appuyés en tant qu’équipe. | +| 10\. **Pions ou joueurs** - Quel contrôle avez-vous sur ce sur quoi vous travaillez et comment? | Nous n’avons pas vraiment de mot à dire sur ce sur quoi nous travaillons. | Nous avons une forte influence sur ce sur quoi nous travaillons. | +| 11\. **Sécurité psychologique** - À quel point vous sentez-vous en sécurité pour soulever des préoccupations? | Si nous soulevons des préoccupations, on nous crie dessus et on nous ignore. | Nos préoccupations sont appréciées et utilisées pour aider à améliorer l’équipe et l’organisation. | +| 12\. **Équipes autour de nous** - Dans quelle mesure les équipes autour de vous travaillent-elles avec vous et votre équipe? | Les équipes autour de nous sont peu serviables et désagréables. | Les équipes autour de nous sont très amicales et serviables – c’est un plaisir de travailler avec les autres équipes. | +| 13\. **Plateforme de livraison** - À quel point la plateforme de livraison est-elle efficace et conviviale pour appuyer la livraison de votre équipe? | La plateforme semble nous obstruer et est difficile à utiliser. | La plateforme est un multiplicateur de force pour nous et nous aide à livrer rapidement et en toute sécurité. Nous aimons la plateforme. | +| 14\. **Style de gestion** - Quelles sont l’efficacité et la pertinence des approches de la direction et des autres intervenants supérieurs? | Les approches de gestion entravent vraiment nos efforts. | Les approches de gestion nous aident à livrer rapidement et en toute sécurité. | From a288f0f7a5e7cbf5e7f4e9d40aaeaea95656c711 Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 20 Aug 2021 14:04:40 -0400 Subject: [PATCH 13/21] adding translations for testability --- translations/fr/testability.fr.md | 40 ++++++++++++++++++------------- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/translations/fr/testability.fr.md b/translations/fr/testability.fr.md index 6d570fa..832538c 100644 --- a/translations/fr/testability.fr.md +++ b/translations/fr/testability.fr.md @@ -1,28 +1,34 @@ # Testability check -> **Part of the Multi-team Software Delivery Assessment** ([README](README.md)) +> **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) > -> Copyright © 2018-2019 [Conflux Digital Ltd](https://confluxdigital.net/) +> Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) > -> Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) +> Sous-licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png) > > _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ -Lisa Crispin氏 と Janet Gregory氏による書籍 [_Agile Testing_](https://wordery.com/agile-testing-lisa-crispin-9780321534460) , Jez Humble氏とDave Farley氏による書籍 [_Continuous Delivery_](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912) , Steve Freeman 氏 と Nat Price 氏 による書籍[_Growing Object-Oriented Software_](https://wordery.com/growing-object-oriented-software-guided-by-tests-steve-freeman-9780321503626) , Michael Feathers氏による書籍 [_Working Effectively with Legacy Code_](https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052), Ash Winter氏と Rob Meaney氏による書籍 [_Team Guide to Software Testability_](http://testabilitybook.com/) と Webサイト [TestabilityQuestions.com](http://TestabilityQuestions.com/) に基づいて評価基準を作成しています。 +Fondé sur le contenu des livres suivants : -目的：*ソフトウェアシステム内のテストおよびテスト容易性へのアプローチを評価* +* [_Agile Testing_](https://wordery.com/agile-testing-lisa-crispin-9780321534460) de Lisa Crispin et Janet Gregory. +* [_Continuous Delivery_](https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912) de Jez Humble et Dave Farley. +* [_Growing Object-Oriented Software_](https://wordery.com/growing-object-oriented-software-guided-by-tests-steve-freeman-9780321503626) de Steve Freeman et Nat Price. +* [_Working Effectively with Legacy Code_](https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052) de Michael Feathers. +* [_Team Guide to Software Testability_](http://testabilitybook.com/) de Ash Winter et Rob Meaney et le site Web accompagnateur [TestabilityQuestions.com](http://TestabilityQuestions.com/) -方法：[Spotify Squad Health Check](https://labs.spotify.com/2014/09/16/squad-health-check-model/) のアプローチを使用して、次の質問に対するチームの回答を評価する: +But : *Évaluer l’approche de mise à l’essai et de testabilité dans le système logiciel.*  -| **質問** | **うんざり (1)** | **すばらしい (5)** | +Méthode : Utilisez l’approche [*Spotify Squad Health Check*](https://labs.spotify.com/2014/09/16/squad-health-check-model/) pour évaluer les réponses de l’équipe aux questions suivantes, et consignez les réponses : + +| **Question** | **Fatigué (1)** | **Inspiré (5)** | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| 1\. **テストファースト（クラス）** - **メソッドとクラスのテストをテストファーストで書く**時間の割合はどれくらいですか？ | 多くの場合、テストファーストのアプローチを使用する時間がない。 | 常にテストファーストのアプローチを使用している-それが良いソフトウェアを入手する唯一の方法だ！ | -| 2\. **テストファースト（機能）** - どのくらいの割合で、**機能と動作のテストをテストファーストで書き**ますか？ | 多くの場合、テストファーストのアプローチを使用する時間がない | 常にテストファーストのアプローチを使用している-それが良いソフトウェアを入手する唯一の方法だ！ | -| 3\. **ユニットテスト %** - どのくらいのコードカバレッジレベルで、**ユニットテスト**が成功したとみなしますか？ | ユニットテストは10％のカバレッジで成功とみなす。 | ユニットテストは80％以上のカバレッジで成功とみなす。 | -| 4\. **機能テスト %** - どのくらいの機能カバレッジレベルで、**機能テスト**（またはビヘイビアテスト）が成功したとみなしますか？ | 機能テストは10％のカバレッジで成功とみなす。 | 機能テストは100％以上のカバレッジで成功とみなす。 | -| 5\. **機能カバレッジ** - **機能テスト（またはビヘイビアテスト）でカバーされるコード内の機能の割合**はどのくらいですか？ | 機能の50％未満に対応する機能テストがある | すべての機能に、対応する機能テストが少なくとも1つある | -| 6\. **テストデータ** - **スクリプトから生成され**、データストアに自動的に挿入されるテストデータの割合はどのくらいですか？ | テストデータを設定するための手動プロセスがある | すべてのテストデータはスクリプトから生成され、自動テストの一部としてデータストアに挿入される | -| 7\. **デプロイメント** - デプロイメントパイプラインコードのどの部分に、**ビルドとデプロイの動作をカバーするテスト**がありますか? | ビルドおよびデプロイスクリプトをテストしない | ビルドおよびデプロイスクリプトの主要部分のテスト（デプロイ検証テストなど）があり、コードはモジュール式で適切に構造化されている | -| 8\. **テスト容易性** - **ソフトウェアをテストを可能にするために**あなたの時間のどの割合が費やされていますか？ | ソフトウェアをテスト可能にするための時間を費やしいない | ソフトウェアをよりテストしやすいものにするために、定期的にリファクタリングする-スプリントまたは週ごと | -| 9\. **CDCs/Pact/SemVer** - コンシューマ駆動契約（CDC）/ Pact / Semantic Versioningなど、**inter-team testing approaches**をどの程度使用していますか？ | 各コンポーネントまたはパッケージの最新バージョンを使用している | コンシューマ駆動契約（CDC） / Pactを使用して、インターフェイスの変更をテストする。 セマンティックバージョニングを使用して、重大な変更を含む変更の意味を伝える。Tolerant Readerパターンを使用して、重大な変更を一切行わないよう努めている。| -| 10\. **その他のコード** - **ポートフォリオ内の他のチームからのコード**について、あなたがうまく使える（ただし、実装はしない）自信はどれくらいありますか？ | 他のチームのコードは非常に不安定で予測ができない。 | 包括的な自動テストスイートにより、他のチームのコードは安心して使える。 | +| 1\. **Essai d’abord (classes)** - Quelle proportion du temps rédigez-vous **l’essai en premier pour les méthodes et les classes**? | Souvent, nous n’avons pas le temps d’utiliser une approche d’essai d’abord. | Nous utilisons une approche d’essai d’abord tout le temps – c’est la seule façon d’obtenir un bon logiciel\! | +| 2\. **Essai d’abord (fonctionnalités)** - Quelle proportion du temps rédigez-vous **l’essai d’abord pour les fonctionnalités et le comportement**? | Souvent, nous n’avons pas le temps d’utiliser une approche d’essai d’abord. | Nous utilisons une approche d’essai d’abord tout le temps – c’est la seule façon d’obtenir un bon logiciel\! | +| 3\. **Pourcentage d’essai unitaire %** - Selon vous, quel est le niveau de réussite de la couverture des codes pour vos **essais unitaires**? | Nos essais unitaires réussissent avec une couverture de 10 %. | Nos essais unitaires réussissent avec une couverture de 80 % ou plus. | +| 4\. **Pourcentage des essais de fonctionnalités %** - Selon vous, quel est le niveau de réussite de la couverture des fonctionnalités pour vos **essais de fonctionnalités** (ou essais de comportement)? | Nos essais de fonctionnalités réussissent avec une couverture de 10 %. | Nos essais de fonctionnalités réussissent avec une couverture de 100 %. | +| 5\. **Couverture des fonctionnalités** - Quelle **proportion des fonctionnalités de votre code est couverte par un essai de fonctionnalités** (ou un essai de comportement)? | Moins de 50 % de nos fonctionnalités ont des essais de fonctionnalités correspondants. | Chacune de nos fonctionnalités a au moins un essai de fonctionnalité correspondant. | +| 6\. **Données d’essai** - Quelle proportion de vos **données d’essai est générée à partir de scripts** et injectée automatiquement dans les magasins de données? | Nous avons des processus manuels pour configurer les données d’essai. | Toutes nos données d’essai sont générées à partir de scripts et injectées dans les magasins de données dans le cadre des essais automatisés. | +| 7\. **Déploiement** - Quelle proportion de votre code de pipeline de déploiement a des **essais couvrant le comportement du développement et le déploiement**? | Nous ne mettons pas à l’essai notre code de développement et de déploiement. | Nous avons des essais (comme les essais de vérification de déploiement) pour les parties clés de nos scripts de développement et de déploiement et le code est modulaire et bien structuré. | +| 8\. **Testabilité** - Quelle proportion de votre temps est consacrée à **rendre le logiciel testable**? | Nous ne consacrons pas de temps à rendre nos logiciels testables. | Nous restructurons régulièrement pour rendre notre logiciel plus testable – chaque sprint ou chaque semaine. | +| 9\. **CDC/Pacte/SemVer** - Combien utilisez-vous des méthodes d’essai interéquipes comme les contrats dirigés par les consommateurs (CDC)/le pacte/la version sémantique? | Nous utilisons les dernières versions de chaque composant ou paquet. | Nous utilisons les CDC ou le Pacte pour faciliter l’essai des changements d’interface. Nous utilisons la version sémantique pour communiquer le sens des changements, y compris les changements inédits. Nous nous efforçons de ne pas faire de changements inédits du tout en utilisant le modèle Tolerant Reader. | +| 10\. **Autre code** - Dans quelle mesure êtes-vous confiant dans le **code d’autres équipes de l’organisation** avec laquelle vous travaillez ou que vous consommez (mais n’êtes pas l’autre)? | Le code des autres équipes est vraiment instable et imprévisible. | Nous sommes confiants dans l’utilisation du code d’autres équipes grâce à nos suites complètes d’essais automatisés. | From 15a7d0e7b7239e1576c7d2804c2d303671278ba6 Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Mon, 13 Sep 2021 15:02:16 -0400 Subject: [PATCH 14/21] adding french translations to print assessment content (missing continuous delivery) --- .../fr/print/print-continuous-delivery.fr.md | 22 +++++++++++++++++++ translations/fr/print/print-deployment.fr.md | 22 +++++++++++++++++++ translations/fr/print/print-flow.fr.md | 22 +++++++++++++++++++ translations/fr/print/print-on-call.fr.md | 21 ++++++++++++++++++ translations/fr/print/print-operability.fr.md | 22 +++++++++++++++++++ translations/fr/print/print-reliability.fr.md | 21 ++++++++++++++++++ translations/fr/print/print-team-health.fr.md | 22 +++++++++++++++++++ translations/fr/print/print-testability.fr.md | 22 +++++++++++++++++++ 8 files changed, 174 insertions(+) create mode 100644 translations/fr/print/print-continuous-delivery.fr.md create mode 100644 translations/fr/print/print-deployment.fr.md create mode 100644 translations/fr/print/print-flow.fr.md create mode 100644 translations/fr/print/print-on-call.fr.md create mode 100644 translations/fr/print/print-operability.fr.md create mode 100644 translations/fr/print/print-reliability.fr.md create mode 100644 translations/fr/print/print-team-health.fr.md create mode 100644 translations/fr/print/print-testability.fr.md diff --git a/translations/fr/print/print-continuous-delivery.fr.md b/translations/fr/print/print-continuous-delivery.fr.md new file mode 100644 index 0000000..1efd1d9 --- /dev/null +++ b/translations/fr/print/print-continuous-delivery.fr.md @@ -0,0 +1,22 @@ +# Multi-team Software Delivery Assessment: Continuous Delivery (4) + +| **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | +| ------------------------- | ---------------------------- | ----------------- | ---------- | --------- | +| 1\. Release Candidate | | | | | +| 2\. Done | | | | | +| 3\. Automated Config | | | | | +| 4\. Config Options | | | | | +| 5\. Broken Builds | | | | | +| 6\. Failing Tests | | | | | +| 7\. Binaries | | | | | +| 8\. Stop The Line | | | | | +| 9\. Idempotent Deployment | | | | | +| 10\. Stubs | | | | | +| 11\. API Replay | | | | | +| 12\. Blue-Green | | | | | +| 13\. Environment History | | | | | +| 14\. DB Changes | | | | | + +Date : ............... Nom et région de l’équipe : .................... Initiales de l’animateur : .......... (Version 2019-03-28) + +Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) | Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![](https://licensebuttons.net/l/by-sa/3.0/88x31.png) | [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/) \ No newline at end of file diff --git a/translations/fr/print/print-deployment.fr.md b/translations/fr/print/print-deployment.fr.md new file mode 100644 index 0000000..8e5e064 --- /dev/null +++ b/translations/fr/print/print-deployment.fr.md @@ -0,0 +1,22 @@ +# Évaluation de la livraison des logiciels effectuée par des équipes multiples : Déploiement (2) + +| **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | +| ----------------------- | ---------------------------- | ----------------- | ---------- | --------- | +| 1\. Reconstruction de l’environnement | | | | | +| 2\. Nouvelle configuration | | | | | +| 3\. Redéploiement de l’application | | | | | +| 4\. Nouvelle exécution des mises à l’essai | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | + +Date : ............... Nom et région de l’équipe : .................... Initiales de l’animateur : .......... (Version 2019-03-28) + +Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) | Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![](https://licensebuttons.net/l/by-sa/3.0/88x31.png) | [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/) diff --git a/translations/fr/print/print-flow.fr.md b/translations/fr/print/print-flow.fr.md new file mode 100644 index 0000000..d2572a4 --- /dev/null +++ b/translations/fr/print/print-flow.fr.md @@ -0,0 +1,22 @@ +# Multi-team Software Delivery Assessment: Flow (3) + +| **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | +| ------------------------ | ---------------------------- | ----------------- | ---------- | --------- | +| 1\. Durée du cycle | | | | | +| 2\. Fréquence de déploiement | | | | | +| 3\. TMR | | | | | +| 4\. Changements qui ont échoué | | | | | +| 5\. Longueur de la file d’attente | | | | | +| 6\. Innovation | | | | | +| 7\. Intégration | | | | | +| 8\. Âge de la direction générale | | | | | +| 9\. Rétrospectives | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | + +Date : ............... Nom et région de l’équipe : .................... Initiales de l’animateur : .......... (Version 2019-03-28) + +Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) | Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![](https://licensebuttons.net/l/by-sa/3.0/88x31.png) | [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/) diff --git a/translations/fr/print/print-on-call.fr.md b/translations/fr/print/print-on-call.fr.md new file mode 100644 index 0000000..8f4816c --- /dev/null +++ b/translations/fr/print/print-on-call.fr.md @@ -0,0 +1,21 @@ +# Multi-team Software Delivery Assessment: On-call (8) + +| **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | +| ------------------------- | ---------------------------- | ----------------- | ---------- | --------- | +| 1\. Raison d’être d’une équipe sur appel | | | | | +| 2\. Avantages d’une équipe sur appel | | | | | +| 3\. Récompenses | | | | | +| 4\. Expérience de l’utilisateur (EU) liée aux équipes sur appel | | | | | +| 5\. Apprentissage lié aux équipes sur appel | | | | | +| 6\. Attitude par rapport aux équipes sur appel | | | | | +| 7\. Futur des équipes sur appel | | | | | +| 8\. Outillage des équipes sur appel | | | | | +| 9\. Amélioration des équipes sur appel | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | + +Date : ............... Nom et région de l’équipe : .................... Initiales de l’animateur : .......... (Version 2019-03-28) + +Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) | Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![](https://licensebuttons.net/l/by-sa/3.0/88x31.png) | [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/) \ No newline at end of file diff --git a/translations/fr/print/print-operability.fr.md b/translations/fr/print/print-operability.fr.md new file mode 100644 index 0000000..47af115 --- /dev/null +++ b/translations/fr/print/print-operability.fr.md @@ -0,0 +1,22 @@ +# Multi-team Software Delivery Assessment: Operability (5) + +| **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | +| ------------------------ | ---------------------------- | ----------------- | ---------- | --------- | +| 1\. Collaboration | | | | | +| 2\. Dépenses en matière d’exploitabilité | | | | | +| 3\. Bascules de la fonction | | | | | +| 4\. Mise en place de la configuration | | | | | +| 5\. Santé du système | | | | | +| 6\. Indicateurs de rendement clés du service | | | | | +| 7\. Fonctionnalité de la connexion | | | | | +| 8\. Testabilité | | | | | +| 9\. Certificats de protocole TLS | | | | | +| 10\. Données de nature sensible | | | | | +| 11\. Rendement | | | | | +| 12\. Modes de défaillance | | | | | +| 13\. Dépistage d’appel | | | | | +| 14\. État du service | | | | | + +Date : ............... Nom et région de l’équipe : .................... Initiales de l’animateur : .......... (Version 2019-03-28) + +Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) | Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![](https://licensebuttons.net/l/by-sa/3.0/88x31.png) | [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/) \ No newline at end of file diff --git a/translations/fr/print/print-reliability.fr.md b/translations/fr/print/print-reliability.fr.md new file mode 100644 index 0000000..a5e0432 --- /dev/null +++ b/translations/fr/print/print-reliability.fr.md @@ -0,0 +1,21 @@ +# Multi-team Software Delivery Assessment: Reliability and SRE (7) + +| **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | +| ------------------------- | ---------------------------- | ----------------- | ---------- | --------- | +| 1\. Disponibilité du service | | | | | +| 2\. Objectifs des utilisateurs et INS | | | | | +| 3\. Compréhension des utilisateurs et des comportements | | | | | +| 4\. INS/ONS | | | | | +| 5\. Santé du service | | | | | +| 6\. INS | | | | | +| 7\. Bilan des erreurs et mécanismes semblables | | | | | +| 8\. Messages d’alerte | | | | | +| 9\. Tâches « toil » et résolution de problèmes | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | + +Date : ............... Nom et région de l’équipe : .................... Initiales de l’animateur : .......... (Version 2019-03-28) + +Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) | Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![](https://licensebuttons.net/l/by-sa/3.0/88x31.png) | [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/) \ No newline at end of file diff --git a/translations/fr/print/print-team-health.fr.md b/translations/fr/print/print-team-health.fr.md new file mode 100644 index 0000000..17a433d --- /dev/null +++ b/translations/fr/print/print-team-health.fr.md @@ -0,0 +1,22 @@ +# Multi-team Software Delivery Assessment: Team Health (1) + +| **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | +| ------------------------- | ---------------------------- | ----------------- | ---------- | --------- | +| 1\. Facilité de lancement | | | | | +| 2\. Processus adéquat | | | | | +| 3\. Qualité technique | | | | | +| 4\. Valeur | | | | | +| 5\. Vitesse | | | | | +| 6\. Mission | | | | | +| 7\. La joi | | | | | +| 8\. Apprentissage | | | | | +| 9\. Soutien | | | | | +| 10\. Pions ou joueurs | | | | | +| 11\. Sécurité psychologique | | | | | +| 12\. Équipes à proximité | | | | | +| 13\. Plateforme de déploiement | | | | | +| 14\. Style de gestion | | | | | + +Date : ............... Nom et région de l’équipe : .................... Initiales de l’animateur : .......... (Version 2019-03-28) + +Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) | Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![](https://licensebuttons.net/l/by-sa/3.0/88x31.png) | [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/) \ No newline at end of file diff --git a/translations/fr/print/print-testability.fr.md b/translations/fr/print/print-testability.fr.md new file mode 100644 index 0000000..46b5614 --- /dev/null +++ b/translations/fr/print/print-testability.fr.md @@ -0,0 +1,22 @@ +# Multi-team Software Delivery Assessment: Testing and Testability (6) + +| **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | +| ------------------------- | ---------------------------- | ----------------- | ---------- | --------- | +| 1\. Premières mises à l’essai (classes) | | | | | +| 2\. Premières mises à l’essai (fonctions) | | | | | +| 3\. Pourcentage des mises à l’essai d’unité | | | | | +| 4\. Pourcentage des mises à l’essai de fonction | | | | | +| 5\. Portée des fonctions | | | | | +| 6\. Données des mises à l’essai | | | | | +| 7\. Déploiement | | | | | +| 8\. Testabilité | | | | | +| 9\. CNC/outil Pact/SemVer | | | | | +| 10\. Autre code | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | + +Date : ............... Nom et région de l’équipe : .................... Initiales de l’animateur : .......... (Version 2019-03-28) + +Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) | Licenced under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![](https://licensebuttons.net/l/by-sa/3.0/88x31.png) | [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/) \ No newline at end of file From 11f44a0919b3093f8cf70d0cb5eb145b93a80a79 Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 17 Sep 2021 16:01:49 -0400 Subject: [PATCH 15/21] adding in french translations --- .../fr/print/print-continuous-delivery.fr.md | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/translations/fr/print/print-continuous-delivery.fr.md b/translations/fr/print/print-continuous-delivery.fr.md index 1efd1d9..f9dabb9 100644 --- a/translations/fr/print/print-continuous-delivery.fr.md +++ b/translations/fr/print/print-continuous-delivery.fr.md @@ -1,21 +1,21 @@ -# Multi-team Software Delivery Assessment: Continuous Delivery (4) +# Évaluation de la prestation de logiciels par diverses équipes : Prestation continue (4) | **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | | ------------------------- | ---------------------------- | ----------------- | ---------- | --------- | -| 1\. Release Candidate | | | | | -| 2\. Done | | | | | -| 3\. Automated Config | | | | | -| 4\. Config Options | | | | | -| 5\. Broken Builds | | | | | -| 6\. Failing Tests | | | | | -| 7\. Binaries | | | | | -| 8\. Stop The Line | | | | | -| 9\. Idempotent Deployment | | | | | -| 10\. Stubs | | | | | -| 11\. API Replay | | | | | -| 12\. Blue-Green | | | | | -| 13\. Environment History | | | | | -| 14\. DB Changes | | | | | +| 1\. Version d’évaluation | | | | | +| 2\. Achèvement | | | | | +| 3\. Configuration automatisée | | | | | +| 4\. Options de configuration | | | | | +| 5\. Versions défectueuses | | | | | +| 6\. Échec des tests | | | | | +| 7\. Binaires | | | | | +| 8\. Cesser la ligne | | | | | +| 9\. Déploiement idempotent | | | | | +| 10\. Modules de remplacement | | | | | +| 11\. Réexécuter l’API | | | | | +| 12\. Déploiement bleu-vert | | | | | +| 13\. Historique de l’environnement | | | | | +| 14\. Changements apportés à la base de données | | | | | Date : ............... Nom et région de l’équipe : .................... Initiales de l’animateur : .......... (Version 2019-03-28) From 5a8a3705ecb92f8aaa203139dc2a08bccc5bbdb7 Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 17 Sep 2021 16:05:13 -0400 Subject: [PATCH 16/21] updating incorrect link to english README --- translations/fr/README.fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translations/fr/README.fr.md b/translations/fr/README.fr.md index 196177f..59e7484 100644 --- a/translations/fr/README.fr.md +++ b/translations/fr/README.fr.md @@ -4,7 +4,7 @@ L’évaluation de la livraison de logiciels à plusieurs équipes est une appro L’évaluation utilise et met à profit le modèle bien connu et éprouvé de [Spotify Squad Health Check model](https://labs.spotify.com/2014/09/16/squad-health-check-model/). -> Traductions: [Japanese (ja 🇯🇵)](translations/ja/README.ja.md), [English (en)](translations/en/README.en.md) +> Traductions: [Japanese (ja 🇯🇵)](translations/ja/README.ja.md), [English (en)](README.md) L’évaluation porte sur huit dimensions au total : From f91fe12ad8a8784b6c35923f3a2aee41428574dd Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 17 Sep 2021 16:06:12 -0400 Subject: [PATCH 17/21] updating incorrect link to english README --- translations/fr/README.fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translations/fr/README.fr.md b/translations/fr/README.fr.md index 59e7484..0346682 100644 --- a/translations/fr/README.fr.md +++ b/translations/fr/README.fr.md @@ -4,7 +4,7 @@ L’évaluation de la livraison de logiciels à plusieurs équipes est une appro L’évaluation utilise et met à profit le modèle bien connu et éprouvé de [Spotify Squad Health Check model](https://labs.spotify.com/2014/09/16/squad-health-check-model/). -> Traductions: [Japanese (ja 🇯🇵)](translations/ja/README.ja.md), [English (en)](README.md) +> Traductions: [Japanese (ja 🇯🇵)](../translations/ja/README.ja.md), [English (en)](/README.md) L’évaluation porte sur huit dimensions au total : From 8600bfcfeaa73ad3763ce1148d36630cd2acc4de Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 17 Sep 2021 16:06:43 -0400 Subject: [PATCH 18/21] updating incorrect link to english README --- translations/fr/README.fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translations/fr/README.fr.md b/translations/fr/README.fr.md index 0346682..cf87c76 100644 --- a/translations/fr/README.fr.md +++ b/translations/fr/README.fr.md @@ -4,7 +4,7 @@ L’évaluation de la livraison de logiciels à plusieurs équipes est une appro L’évaluation utilise et met à profit le modèle bien connu et éprouvé de [Spotify Squad Health Check model](https://labs.spotify.com/2014/09/16/squad-health-check-model/). -> Traductions: [Japanese (ja 🇯🇵)](../translations/ja/README.ja.md), [English (en)](/README.md) +> Traductions: [Japanese (ja 🇯🇵)](../ja/README.ja.md), [English (en)](/README.md) L’évaluation porte sur huit dimensions au total : From c0055d67a4fb1e9b9dd580eac2ba0ac7ce0f157b Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 17 Sep 2021 16:08:19 -0400 Subject: [PATCH 19/21] updating link and translation to assessment cards --- translations/fr/README.fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translations/fr/README.fr.md b/translations/fr/README.fr.md index cf87c76..6e0631d 100644 --- a/translations/fr/README.fr.md +++ b/translations/fr/README.fr.md @@ -23,7 +23,7 @@ Ces huit dimensions couvrent les aspects clés de la livraison de logiciels mode **🃏 Jeu de cartes**: Rendre l’évaluation amusante et interactive à l’aide de [the 66-card Software Delivery Assessment printed card deck from Agile Stationery](https://agilestationery.co.uk/pages/software-delivery-assessment). Élaboré en collaboration avec Conflux, le jeu de cartes comporte des indicateurs Fatigué et Inspiré pour chacun des critères d’évaluation, ainsi que des cartes émoticônes pour le vote rapide des membres de l’équipe. Le jeu de cartes fonctionne aussi pour les évaluations à distance! -Assessment cards from Agile Stationery Five emoji voting cards +Cartes d'évaluation d'Agile Stationery Five emoji voting cards > Droit d’auteur © 2018-2021 © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) > From de2b0076867575a63f52c078fd6c3312155effcf Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 17 Sep 2021 16:09:30 -0400 Subject: [PATCH 20/21] updating link and adding missing translation to french readme --- translations/fr/README.fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translations/fr/README.fr.md b/translations/fr/README.fr.md index 6e0631d..9526d5e 100644 --- a/translations/fr/README.fr.md +++ b/translations/fr/README.fr.md @@ -23,7 +23,7 @@ Ces huit dimensions couvrent les aspects clés de la livraison de logiciels mode **🃏 Jeu de cartes**: Rendre l’évaluation amusante et interactive à l’aide de [the 66-card Software Delivery Assessment printed card deck from Agile Stationery](https://agilestationery.co.uk/pages/software-delivery-assessment). Élaboré en collaboration avec Conflux, le jeu de cartes comporte des indicateurs Fatigué et Inspiré pour chacun des critères d’évaluation, ainsi que des cartes émoticônes pour le vote rapide des membres de l’équipe. Le jeu de cartes fonctionne aussi pour les évaluations à distance! -Cartes d'évaluation d'Agile Stationery Five emoji voting cards +Cartes d'évaluation d'Agile Stationery Cinq cartes de vote emoji > Droit d’auteur © 2018-2021 © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/) > From f8a793909ca4b3caa47f9ff26e7c1b0230fb3c8b Mon Sep 17 00:00:00 2001 From: jaysonmc Date: Fri, 17 Sep 2021 16:17:12 -0400 Subject: [PATCH 21/21] updating titles to french (many were missed) --- translations/fr/README.fr.md | 2 +- translations/fr/continuous-delivery.fr.md | 2 +- translations/fr/deployment.fr.md | 2 +- translations/fr/flow.fr.md | 2 +- translations/fr/operability.fr.md | 2 +- translations/fr/print/print-flow.fr.md | 2 +- translations/fr/print/print-on-call.fr.md | 2 +- translations/fr/print/print-operability.fr.md | 2 +- translations/fr/print/print-reliability.fr.md | 2 +- translations/fr/print/print-team-health.fr.md | 2 +- translations/fr/print/print-testability.fr.md | 2 +- translations/fr/team-health.fr.md | 2 +- translations/fr/testability.fr.md | 2 +- 13 files changed, 13 insertions(+), 13 deletions(-) diff --git a/translations/fr/README.fr.md b/translations/fr/README.fr.md index 9526d5e..149fdb1 100644 --- a/translations/fr/README.fr.md +++ b/translations/fr/README.fr.md @@ -1,4 +1,4 @@ -# Multi-team Software Delivery Assessment +# Évaluation de la livraison de logiciels à plusieurs équipes L’évaluation de la livraison de logiciels à plusieurs équipes est une approche simple et facile à exécuter pour évaluer la livraison de logiciels dans de nombreuses équipes différentes dans une organisation. Conçue par [Matthew Skelton](https://github.com/matthewskelton) de [Conflux](https://confluxdigital.net/), elle est utilisée comme élément clé de Software Delivery Assessment à Conflux, mais peut être utilisé librement par n’importe qui (sous réserve de la licence CC BY-SA ci-dessous). diff --git a/translations/fr/continuous-delivery.fr.md b/translations/fr/continuous-delivery.fr.md index 06f01d3..a5f721b 100644 --- a/translations/fr/continuous-delivery.fr.md +++ b/translations/fr/continuous-delivery.fr.md @@ -1,4 +1,4 @@ -# Continuous Delivery check +# Vérification de livraison continue > **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) > diff --git a/translations/fr/deployment.fr.md b/translations/fr/deployment.fr.md index dd85af7..f0d7a4f 100644 --- a/translations/fr/deployment.fr.md +++ b/translations/fr/deployment.fr.md @@ -1,4 +1,4 @@ -# Deployment check +# Vérification du déploiement > **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) > diff --git a/translations/fr/flow.fr.md b/translations/fr/flow.fr.md index ab62f10..89e12ea 100644 --- a/translations/fr/flow.fr.md +++ b/translations/fr/flow.fr.md @@ -1,4 +1,4 @@ -# Flow check +# Contrôle du flux > **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) > diff --git a/translations/fr/operability.fr.md b/translations/fr/operability.fr.md index 6edef1b..0e8c669 100644 --- a/translations/fr/operability.fr.md +++ b/translations/fr/operability.fr.md @@ -1,4 +1,4 @@ -# Operability check +# Vérification d’exploitabilité > **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) > diff --git a/translations/fr/print/print-flow.fr.md b/translations/fr/print/print-flow.fr.md index d2572a4..06c1f6a 100644 --- a/translations/fr/print/print-flow.fr.md +++ b/translations/fr/print/print-flow.fr.md @@ -1,4 +1,4 @@ -# Multi-team Software Delivery Assessment: Flow (3) +# Évaluation de la livraison des logiciels effectuée par des équipes multiples : Flux (3) | **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | | ------------------------ | ---------------------------- | ----------------- | ---------- | --------- | diff --git a/translations/fr/print/print-on-call.fr.md b/translations/fr/print/print-on-call.fr.md index 8f4816c..366d0ff 100644 --- a/translations/fr/print/print-on-call.fr.md +++ b/translations/fr/print/print-on-call.fr.md @@ -1,4 +1,4 @@ -# Multi-team Software Delivery Assessment: On-call (8) +# Évaluation de la livraison des logiciels effectuée par des équipes multiples : Sur appel (8) | **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | | ------------------------- | ---------------------------- | ----------------- | ---------- | --------- | diff --git a/translations/fr/print/print-operability.fr.md b/translations/fr/print/print-operability.fr.md index 47af115..2a3e829 100644 --- a/translations/fr/print/print-operability.fr.md +++ b/translations/fr/print/print-operability.fr.md @@ -1,4 +1,4 @@ -# Multi-team Software Delivery Assessment: Operability (5) +# Évaluation de la livraison des logiciels effectuée par des équipes multiples : Exploitabilité (5) | **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | | ------------------------ | ---------------------------- | ----------------- | ---------- | --------- | diff --git a/translations/fr/print/print-reliability.fr.md b/translations/fr/print/print-reliability.fr.md index a5e0432..70ce560 100644 --- a/translations/fr/print/print-reliability.fr.md +++ b/translations/fr/print/print-reliability.fr.md @@ -1,4 +1,4 @@ -# Multi-team Software Delivery Assessment: Reliability and SRE (7) +# Évaluation de la livraison des logiciels effectuée par des équipes multiples : Fiabilité et ingénierie de la fiabilité des sites (SRE) (7) | **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | | ------------------------- | ---------------------------- | ----------------- | ---------- | --------- | diff --git a/translations/fr/print/print-team-health.fr.md b/translations/fr/print/print-team-health.fr.md index 17a433d..07c8769 100644 --- a/translations/fr/print/print-team-health.fr.md +++ b/translations/fr/print/print-team-health.fr.md @@ -1,4 +1,4 @@ -# Multi-team Software Delivery Assessment: Team Health (1) +# Évaluation de la livraison des logiciels effectuée par des équipes multiples : Santé de l’équipe (1) | **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | | ------------------------- | ---------------------------- | ----------------- | ---------- | --------- | diff --git a/translations/fr/print/print-testability.fr.md b/translations/fr/print/print-testability.fr.md index 46b5614..0e58305 100644 --- a/translations/fr/print/print-testability.fr.md +++ b/translations/fr/print/print-testability.fr.md @@ -1,4 +1,4 @@ -# Multi-team Software Delivery Assessment: Testing and Testability (6) +# Évaluation de la livraison des logiciels effectuée par des équipes multiples : Mises à l’essai et testabilité (6) | **Critères** | **Cote 😥 1-2 😐 2-3 😊 4-5** | **Tendance (↑ → ↓)** | **Mesure** | **Notes** | | ------------------------- | ---------------------------- | ----------------- | ---------- | --------- | diff --git a/translations/fr/team-health.fr.md b/translations/fr/team-health.fr.md index 94345dd..2cc297d 100644 --- a/translations/fr/team-health.fr.md +++ b/translations/fr/team-health.fr.md @@ -1,4 +1,4 @@ -# Team Health check +# Vérification de la santé de l’équipe > **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) > diff --git a/translations/fr/testability.fr.md b/translations/fr/testability.fr.md index 832538c..b5c02ca 100644 --- a/translations/fr/testability.fr.md +++ b/translations/fr/testability.fr.md @@ -1,4 +1,4 @@ -# Testability check +# Vérification de la fiabilité > **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md)) >