DPEが最近流行っているようで、関連資料をメモしてみました。
DPE(Developer Productivity Engineering)が新しいソフトウェア開発工学の方法論で、ビルド・テストとCIなどの自動化ツールにフォーカスしています。その実践をDPEチームにより担当されます。
DPEとSREの違いは、SDLCフェーズの違いであって、DEV(development & test)開発生産性とOPS(deployment & maintenance)運用信頼性の違いだと思われます。
なお、DXE(Developer Experience Engineer)はDPEを実現するためのエンジニアロールの一つと自分が解釈しています。
ちなみに、GoogleのEngineering Productivity部門にDPEやDXEとのロールがなく、通常のSoftware Engineer (SWE)とTest Engineer (TE)だけあります。
4年前に開発生産性を考えるサービス化(API化)の本質はソフトウェア開発産業化記事は、DPEのようにツールチェーンのことを意識していたが、明確的に言葉定義として出てこなかったのが残念。
DPE - Developer Productivity Engineering
1 From QA to Engineering Productivity
Google Testing Blog Tuesday, March 22, 2016
In summary, the work done by the SETs naturally progressed from supporting only product testing efforts to include supporting product development efforts as well. Their role now encompassed a much broader Engineering Productivity agenda.
2 The Effect of Work Environments on Productivity and Satisfaction of Software Engineers
Brittany Johnson, Thomas Zimmermann, Senior Member, IEEE, and Christian Bird, Member, IEEE
2019/09
3 Developer Productivity Engineering: Introduction and Key Concepts
gradle.com By Dennis Welter
September 9, 2019
Hans Dockter, CEO & Founder of Gradle, talks about the emerging practice of developer productivity engineering, a discipline of using data to improve essential development processes from build/test to CI/CD.Topics covered in this webinar are:
Quantify the costs of a low productivity environment with wasted time waiting for builds, tests, and CI/CD pipelines
Communicate the importance of fast feedback cycles and catching errors earlier, including incorrect signals like flaky tests
Discuss acceleration technologies for speeding up feedback cycles
Make the practice of developer productivity engineering a respected discipline
Use data to understand and improve essential development processesビルド、テスト、CI/CDパイプラインの待ち時間にかかる無駄な時間など、生産性の低い環境におけるコストを定量化する
フィードバックサイクルを高速化し、不具合テストのような不正確なシグナルを含むエラーを早期に発見することの重要性を伝える。
フィードバックサイクルを高速化するためのアクセラレーション技術について説明します。
開発者生産性エンジニアリングの実践を尊重される規律とする
本質的な開発プロセスを理解し、改善するためにデータを使用する
4 Developer Productivity Engineering Overview
gradle.com
Developer Productivity Engineering (DPE) is a software development practice used by leading software development organizations to maximize developer productivity and happiness.
DPE（Developer Productivity Engineering）は、開発者の生産性と幸福度を最大化するために、大手ソフトウェア開発企業が採用しているソフトウェア開発手法です。
As its name implies, DPE takes an engineering approach to improving developer productivity. As such, it relies on automation, actionable data, and acceleration technologies to deliver measurable outcomes like faster feedback cycles and reduced mean-time-to-resolution (MTTR) for build and test failures. As a result, DPE has quickly become a proven practice that delivers a hard ROI with little resistance to product acceptance and usage. その名が示すように、DPEは開発者の生産性を向上させるためにエンジニアリング的なアプローチを取ります。そのため、自動化、実用的なデータ、高速化技術に依存し、フィードバックサイクルの高速化、ビルドやテストの失敗に対する平均解決時間（MTTR）の短縮など、測定可能な結果を実現します。その結果、DPEは、製品の受け入れや使用に対する抵抗が少なく、確実なROIを実現する実証済みの手法として急速に普及しました。Organizations successfully apply the practice of DPE to achieve their strategic business objectives such as reducing time to market, increasing product and service quality, minimizing operational costs, and recruiting and retaining talent by investing in developer happiness and providing a highly satisfying developer experience. DPE accomplishes this with processes and tools that gracefully scale to accommodate ever-growing codebases.
組織はDPEの実践により、開発者の幸福に投資し、満足度の高い開発者体験を提供することで、市場投入期間の短縮、製品やサービスの品質の向上、運用コストの最小化、人材の採用と維持といった戦略的なビジネス目標の達成に成功しています。DPEは、増え続けるコードベースに柔軟に対応するプロセスとツールでこれを実現します。
5 THE DEVELOPER PRODUCTIVITY ENGINEERING HANDBOOK: A Complete Guide
gradle.com 2019/09
This contrasts with a Developer Productivity Management (DPM) approach that views developer productivity as a people challenge that can be addressed by applying management best practices and developer activity-based metrics.
開発者の生産性を、管理のベストプラクティスと開発者のアクティビティベースのメトリクスを適用することで対処可能な人的課題と見なす開発者生産性管理（DPM）アプローチとは対照的です。
Developer Productivity Engineering is of similar importance when it comes to the production of software with similar stakes in achieving a company's economic potential and global competitive impact.
It is quickly becoming a critical practice within software engineering organizations that strive for industry leadership across diverse and highly dynamic marketplaces.
開発者生産性エンジニアリングは、企業の経済的可能性や国際的な競争力を達成する上で、ソフトウェアの生産に関しても同様の重要性を持っています。
多様で非常にダイナミックな市場において、業界をリードするために努力するソフトウェアエンジニアリングの組織において、このことは急速に重要な実践となりつつあります。
However, process improvement initiatives will fail without bottom-up, grass-roots user acceptance.
The intuitive case for DPE is not based on the impact to management and financial objectives like development costs, time-to-market, and quality.
Instead, it is based on a visceral understanding of the pains experienced every day by developers from problems that DPE addresses -- slow builds and inefficient troubleshooting, to name two -- and the impact they have on the developer experience and productivity.
しかし、プロセス改善の取り組みは、ボトムアップで草の根のユーザーに受け入れられなければ失敗します。
DPEの直感的な利点は、開発コスト、市場投入までの時間、品質といった経営・財務目標に与える影響に基づくものではありません。
むしろ、DPEが解決しようとする問題（例えば、遅いビルドや非効率的なトラブルシューティングなど）により開発者が日々経験している苦痛と、それが開発者の経験や生産性に与える影響についての直感的な理解に基づいています。
The intuitive case for DPE starts with and is built upon the intuitive premise that software productivity depends heavily on toolchain effectiveness.
This is because toolchain effectiveness can be defined as the ability to facilitate developer creative flow, collaboration, and team productivity.
It concludes that software productivity suffers without DPE.
DPEの直感的なケースは、ソフトウェアの生産性はツールチェーンの有効性に大きく依存するという直感的な前提から始まり、それに基づいて構築されています。
これは、ツールチェーンの有効性とは、開発者の創造的なフロー、コラボレーション、およびチームの生産性を促進する能力であると定義できるためです。
そして、DPEがなければソフトウェアの生産性は低下すると結論付けています。
The developer toolchain in the enterprise is an ever-changing and complex piece of machinery with ever-changing and complex inputs.
Sub-optimal feedback cycle times and unreliable feedback is the norm.
This is commonly the case since most enterprises do not performance manage or quality control their toolchain by leveraging modern acceleration or troubleshooting technologies.
In a recent study, over 90% of survey respondents indicated that improving time spent waiting on build and test feedback was a major challenge.
企業内の開発者ツールチェーンは、常に変化し続ける複雑な入力の機械である。
最適とは言えないフィードバックサイクルタイムと信頼性の低いフィードバックが常態化しています。
これは、ほとんどの企業が、最新のアクセラレーション技術やトラブルシューティング技術を活用して、ツールチェーンのパフォーマンス管理や品質管理を行っていないため、一般的にこのような状況になっています。
最近の調査では、90%以上の調査回答者が、ビルドとテストのフィードバックの待ち時間を改善することが大きな課題であると回答しています。
The job of DPE is to improve developer productivity across its entire lifecycle and to close the significant and growing gap between actual and potential software development team productivity.
Too often CI/CD teams are not responsible for developer productivity and make decisions that optimize for other metrics, such as auditability or vulnerability checking without taking into account the adverse effects to developer productivity. The priorities and success criteria for a DPE team are primarily based on data that comes from a fully instrumented toolchain.
For such a team to be successful it needs a culture that values and is committed to the continuous improvement of developer productivity.
DPEの仕事は、そのライフサイクル全体にわたって開発者の生産性を向上させ、ソフトウェア開発チームの実際の生産性と潜在的な生産性との間の著しいギャップと増大するギャップを埋めることです。
CI/CDチームは、開発者の生産性に責任を持たず、開発者の生産性への悪影響を考慮せずに、監査性や脆弱性チェックなど他の指標に最適化する決定を下すことがあまりにも多くなっています。DPEチームの優先順位と成功基準は、主に完全にインストルメント化されたツールチェーンから得られるデータに基づいています。
このようなチームが成功するためには、開発者の生産性を継続的に向上させることを重視し、それを約束する文化が必要です。
A developer's happiness depends on their productivity.
Most developers want to work in an environment that enables them to work at their full potential.
Organizations that cannot provide such an environment are seeing a drain on their talent leading to project slowdowns or outright abandonment.
開発者の幸せは、その生産性にかかっています。
開発者の多くは、自分の能力を最大限に発揮できるような環境で働きたいと考えています。
そのような環境を提供できない企業は、人材が流出し、プロジェクトの遅延や放棄に繋がっています。
Developer Productivity Engineering applies broadly across the software development process landscape.
It's impact starts with the coding process and extends to CI/CD to the point where DevOps distributes and scales production applications.
開発者生産性エンジニアリングは、ソフトウェア開発プロセス全体に広く適用されます。
その影響はコーディングプロセスから始まり、CI/CD、そしてDevOpsによるプロダクションアプリケーションの配布とスケールにまで及びます。
To be clear, Developer Productivity Engineering is not about treating developers like factory workers but instead like creative craftspeople.
It is about the developer experience, unlocking creative flow, restoring the joy of development, and facilitating better collaboration with the business.
開発者生産性エンジニアリングとは、開発者を工場労働者のように扱うのではなく、クリエイティブな職人のように扱うことを意味します。
それは、開発者のエクスペリエンス、クリエイティブフロー、開発の喜び、そしてビジネスとのより良いコラボレーションを促進することです。
Rather than this largely ad hoc approach, the most successful DPE-enabled businesses formalize those investments by establishing a dedicated team.
Here are three reasons why it makes sense for your company to launch a DPE initiative now.
- DPE requires focus
- DPE delivers a compelling ROI
- DPE provides competitive advantage
このような場当たり的なアプローチではなく、最も成功しているDPE対応企業は、専門チームを設立することで投資を正式なものにしています。
ここでは、DPEへの取り組みを今すぐ開始することが有意義である3つの理由をご紹介します。
- DPEには集中力が必要
- DPEは魅力的なROIを提供する
- DPEは競争優位性をもたらす
Developer Productivity Management (DPM) focuses on the people, and answers questions like,
"How can we get more output out of individual developers and teams by defining and tracking the right metrics?"
Such metrics typically help to quantify output, evaluate performance and competencies, build and manage teams, and optimize collaboration and time management.
開発者生産性管理（DPM）は、「人」に焦点を当て、次のような質問に答えます。
「正しい測定基準を定義し追跡することで、個々の開発者やチームからより多くの成果を引き出すにはどうすればよいでしょうか。
このような測定基準は、通常、アウトプットの定量化、パフォーマンスと能力の評価、チームの構築と管理、コラボレーションと時間管理の最適化などに役立ちます。
Developer Productivity Engineering (DPE) focuses on the process and technology, and answers questions like,
"How can we make feedback cycles faster using acceleration technologies to speed up builds and tests?"
and
"How can we make troubleshooting easier, faster, and more efficient using data analytics?"
開発者生産性エンジニアリング（DPE）は、プロセスと技術に焦点を当て、次のような質問に答えます。
"ビルドとテストを高速化するアクセラレーション技術を使用して、フィードバックサイクルを高速化するにはどうすればよいか？"
そして
「データ分析を使って、トラブルシューティングをより簡単に、より速く、より効率的に行うにはどうすればいいか？
In analogous terms, suppose you're the owner of an auto racing team.
To win, you need both the best drivers and the fastest cars.
In the software engineering world, the drivers are your developers, while the cars are your highly performant processes and technology toolchain.
例えて言うなら、あなたが自動車レースチームのオーナーだとします。
勝つためには、最高のドライバーと最速の車の両方が必要です。
ソフトウェアエンジニアリングの世界では、ドライバーは開発者であり、車はパフォーマンスの高いプロセスやテクノロジーツールチェーンです。
DPM and DPE are complementary, not competing approaches to improving developer productivity.
DPMとDPEは、開発者の生産性を向上させるための補完的なアプローチであり、競合するものではありません。
A Developer Productivity Engineering solution framework that aligns pain points, benefits and key solution technologies
6 How We Improved Developer Productivity for Our DevOps Teams
August 27, 2020
Spotify.com
Published by Maria Jernström and Jason Palmer
7 Is Developer Productivity Engineering the Next Big Thing in Software?
gradle.com By Wayne Caccamo
January 28, 2021
1970s: JIT Manufacturing
1980s: Business Process Reengineering (BPR)
1990s: Change Management
2000s: Lean Six Sigma
2010s: Agile and DevOps
2020+: Developer Productivity Engineering
8 Engineering Productivity: How To Measure And Improve It
Michiel Mulders
March 2, 2021
How Is Engineering Productivity Measured?
1. Cycle Time
2. Deployment Frequency
3. Number of Bugs
4. Review to Merge Time (RTMT)
9 アジャイル・DevOpsからDeveloper Productivityへ ~食べログのDeveloper Productivityチームが目指す姿~
2021-12-23
食べログのDeveloper Productivityチームのミッションは「 開発サイクルのフィードバックを素早く、リッチにすることで最高の開発・テスト体験を実現する 」です。
「最高の開発体験」に対しては「 開発者の影響分析・デバッグにかかる労力を最小化する 」を中・長期目標とし、開発環境や開発ツールなどをモダン化していく計画です。
また、「最高のテスト体験」に対しては、「 コード修正後すぐにテストからフィードバックを得られるようにテスト体験を向上する 」を中・長期目標として、テスト自動実行基盤やテストデータ基盤などの構築を行っていきます。
チーム名を変えただけでまだ具体的に何か参考できるものがない。。
10
Engineering Productivity : Delivering frictionless engineering and excellent products
What is Engineering Productivity?
We are a data-driven engineering discipline focused on optimizing the engineering process so that Google can deliver amazing experiences to our users, faster.
エンジニアリング プロダクティビティとは？
Google がユーザーに素晴らしい体験をより早く提供できるよう、エンジニアリング プロセスの最適化に注力するデータ主導型のエンジニアリング部門です。
Core Principles
-System analysis
-Instrumentation
-Tools and infrastructure
-Focus on the user
How does EngProd (Engineering Productivity ) make development easier at Google?
Contrast this to working on a large system at Google that supports billions of users and millions of queries per second. Several thousand engineers make thousands of changes per day and asynchronously release various parts of the system. It is likely impossible for a single engineer to know every aspect of the system.
Googleでは、数十億のユーザーと毎秒数百万のクエリをサポートする大規模なシステムに取り組んでいます。数千人のエンジニアが1日に何千もの変更を行い、システムの様々な部分を非同期でリリースしています。一人のエンジニアがシステムのあらゆる側面を知ることは、おそらく不可能でしょう。
Let's re-examine the development process in this situation. Design and coding, of course, come first. Where the rubber really meets the road is in the testing and debugging stage, where you see if your change works as expected. Reasoning about the correctness of your change is now much more difficult.
このような状況下で、開発プロセスを改めて考えてみましょう。もちろん、設計とコーディングが先です。しかし、本番はテストとデバッグの段階であり、変更した内容が期待通りに動作するかどうかを確認することになります。自分の変更が正しいかどうかを判断するのは、これまでよりずっと難しくなります。
Some questions come up, including: How do you make sure your change works? How do you make sure your change didn't break an obscure use case for a user in a different geography? How do you prepare your change such that the next 100 engineers that modify the system don't break the feature you just added?
次のような疑問が湧いてきます。自分の変更がうまくいったかどうかは、どうすれば確認できるのか？自分の変更がうまく機能することをどうやって確認するのか？自分の変更が、別の地域のユーザー向けの不明瞭なユースケースを壊さなかったことをどうやって確認するのか？次にシステムを修正する100人のエンジニアが、追加したばかりの機能を壊さないように、どのように変更を準備すればよいのか？
These are complex problems that require tooling and infrastructure to help engineers reason about the correctness of their change. EngProd's purpose is to make engineering easier and better, so we spend a lot of time on the hardest part of the process: building tools and infrastructure to make testing and debugging simpler.
これらは複雑な問題であり、エンジニアが変更の正しさを推論するためのツールやインフラが必要です。EngProdの目的は、エンジニアリングをより簡単に、より良くすることです。そのため、プロセスの最も難しい部分である、テストとデバッグをより簡単にするためのツールとインフラの構築に多くの時間を費やしています。
11 2022年3月~4月に読んだDeveloper Productivity・Developer Experience・Platform Engineering関連のリソース
１２ Developers Summit 2022 Summer 「アジャイル・DevOps時代のプロダクトとエンジニア組織を支える、Developer Productivityへの道」
13 "Unblocking Workflows: The Guide to Developer Productivity in 2022" (Mattermost)
Fragmented Tools issue
Solution: Build Connections with More Robust Integrations
Look to ChatOps for Inspiration
Leverage Open Source to Build Bespoke IntegrationsTeam Distribution Collaboration Issues
Solution: Improve Communication Culture and Tools to Optimize Collaboration
Work on Improving Async Collaboration Practices
Look for Signal Boosters, Not Noise-MakersFinding and Retaining Developer Talent
Solution: Invest in Creating a Developer-Friendly Environment
Lean into the Technologies That Developers Want to Work With
Become a Part of the Open Source CommunityManual Task Overload
Solution: Automate Strategically
Start Small and Work Your Way Up
Invest in Technologies That Enable AutomationFragile Workflows
Solution: Create More Robust Workflows
Build Better Integrations
Document and Refine Repeated Processes
Invest in Fixing Broken Systems
DXE - Developer Experience Engineer
1 Maximize Developer Productivity and Engagement with the Developer Experience Engineer
Engineering teams need Developer Experience Engineers (DXE) to ensure they have the right tools, processes, and environment to maximize productivity and create the greatest business value possible. The size of the DXE team can range from 1 - 10 or more people, depending on the size of the engineering organization, and they work to solve, automate, and eliminate the daily toil developers encounter. A DXE is always thinking about the business impact, the costs, where the most time is spent, the biggest drag on delivery, and what it will take to solve a tooling or process problem. They are focused on achieving maximum efficiency so that the engineering team is free to focus on achieving the goals of the business.エンジニアリングチームは、生産性を最大化し、可能な限り最大のビジネス価値を生み出すための適切なツール、プロセス、環境を確保するために、デベロッパーエクスペリエンスエンジニア (DXE) を必要としています。DXEチームの規模は、エンジニアリング組織の規模に応じて1～10人以上になり、開発者が日々遭遇する労力を解決し、自動化し、排除するために働きます。
DXEは、ビジネスへの影響、コスト、最も時間を費やす場所、納期の最大の障害、ツールやプロセスの問題を解決するために必要なことを常に考えています。DXEは、エンジニアリングチームがビジネスの目標達成に集中できるよう、最大限の効率化を実現することに専念します。
2 The experience of working in Developer Experience
The innovative idea behind the DevEx concept is that in this case the focus is not only development tools, but also development processes. This means that yes, creating tools and scripts that simplify usual and repetitive tasks will be part of your daily life inside a DevEx team, but also things like identifying bottlenecks in CI processes that are making your pipelines slower or looking for inefficiencies in compilations or in build scripts.
Reducing waiting times and cognitive load is essential in order to let developers focus on what is important and avoid switching from task to task, losing the focus on what they are doing.DevExのコンセプトの背後にある革新的なアイデアは、この場合、開発ツールだけでなく、開発プロセスにも焦点を当てるということである。つまり、通常の反復作業を簡略化するツールやスクリプトを作成することは、DevExチーム内の日常生活の一部となりますが、パイプラインを遅くしているCIプロセスのボトルネックを特定したり、コンパイルやビルドスクリプトの非効率性を探したりといったことも含まれます。
開発者が重要なことに集中し、タスクからタスクに切り替えて集中力を欠くことを避けるためには、待ち時間と認知的負荷を減らすことが重要です。
3 Why Developer Experience Engineers (DXE) are the key to accelerating your business -- CircleCI
Engineering teams need a leader -- a developer experience engineer (DXE) -- who ensures developers have the right tools, processes, and environment to maximize productivity and create the greatest business value possible. The DXE is the foundation for engineering team success. They make it easy for developer teams to focus on their highest purpose and generate the highest value by solving, automating, and eliminating the daily toil developers encounter.
They are a major unlocking force that boosts teams to new heights.
エンジニアリングチームには、開発者が適切なツール、プロセス、環境を利用して生産性を最大化し、最大のビジネス価値を創造できるようにするリーダー、デベロッパーエクスペリエンスエンジニア (DXE) が必要です。DXE は、エンジニアリングチームを成功に導くための基盤です。DXE は、開発者が日々遭遇する労力を解決し、自動化し、排除することで、開発者チームが最高の目的に集中し、最高の価値を生み出せるようにします。
DXEは、チームを新たな高みへと押し上げる大きな力となるのです。
While in many ways we're entering the golden age for the developer, a large number of organizations haven't made the shift to create the right environment to help developers thrive. Developers remain plagued by toil, disengagement, and inability to do what they do best: build.
Yet teams that focus on creating the best possible environment for developers to succeed see meaningful results on their bottom line. A recent report from McKinsey showed that businesses that prioritize developer velocity have four to five times the revenue growth of their counterparts.
多くの点で開発者にとっての黄金時代を迎えている一方で、多くの企業は開発者が成功するための適切な環境づくりにシフトしていません。開発者は依然として、労苦や離職に悩まされ、本来の仕事であるビルドができないでいます。
しかし、開発者が成功するための最適な環境づくりに注力するチームは、収益面で大きな成果を上げています。McKinsey社の最近のレポートによると、開発者のベロシティを優先する企業は、他の企業の4倍から5倍の収益成長率を示しています。
A DX owner or function isn't a new idea. Twitter formed an "engineering effectiveness" organization in 2014, and Google has a massive "engineering productivity" team.
In many companies, however, the role emerges organically and it's growing as a trend as the software engineering landscape changes. As of May 2021 we found 117,151 results for "developer experience" in the United States alone.
DXオーナーや機能というのは、新しいアイデアではありません。Twitterは2014年に「エンジニアリング・エフェクティブネス」組織を結成し、Googleは大規模な「エンジニアリング・プロダクティビティ」チームを持っています。
しかし、多くの企業では、この役割は有機的に出現し、ソフトウェアエンジニアリングの状況が変化するにつれて、トレンドとして成長しています。2021年5月現在、米国内だけで「デベロッパーエクスペリエンス」の検索結果が117,151件見つかりました。
DXEs implement a common set of principles, maintain the right tools, and create cohesive standards that clear the path to developer success. Without them, too many languages, frameworks, engineering styles, and processes can add drag.
A drag on developers is a drag on the business. Beyond the expense of wasted developer minutes, low performance can affect overall innovation, execution quality and timeliness, and the customer experience. In fact, it all adds on to the bottom line.
DXEは、共通の原則を実施し、適切なツールを維持し、開発者の成功への道を開くための一貫した基準を作成します。DXEなしには、多すぎる言語、フレームワーク、エンジニアリングスタイル、およびプロセスが足かせとなります。
開発者の負担は、ビジネスの負担になります。開発者の時間を無駄にするだけでなく、パフォーマンスの低下は、全体的な革新、実行品質と適時性、そして顧客体験に影響を及ぼします。実際、これらはすべて最終的な収益に結びつきます。
Developers are experts in their domain -- they build. They are not necessarily experts in the field of process optimization. Sensibly, they'll optimize for their own speed (such as choosing their favorite language to write in), but sometimes at the detriment to the velocity of the team as a whole. As the number of developers in an organization grows, complexity grows tenfold. The role of the DXE becomes ever more important to create efficiencies and shared practices between ambitious and energized teams.
開発者は、その分野の専門家です - 彼らは構築します。彼らは必ずしもプロセス最適化の分野の専門家ではありません。感覚的には、彼らは自分のスピードのために最適化しますが（好きな言語を選んで書くなど）、時にはチーム全体のスピードが損なわれることもあります。組織内の開発者の数が増えれば増えるほど、複雑さは10倍になります。野心的で活気のあるチーム間で効率化とプラクティスの共有を実現するために、DXEの役割はこれまで以上に重要になります。
Finally, a DXE helps identify and eliminate waste, i.e., the toil involved in maintaining existing software systems. Without DXE expertise, engineers spend time on maintenance instead of building. This is less efficient than having a person with centralized authority do maintenance, allowing developers to write code. Software developer teams can thus spend more time focused on doing what they love with the right processes in place.
最後に、DXEは、既存のソフトウェアシステムを維持するための労力など、無駄を発見し排除するのに役立ちます。DXEの専門知識がないと、エンジニアは構築の代わりにメンテナンスに時間を費やしてしまいます。これは、集中管理された権限を持つ人が保守を行い、開発者がコードを書くことを可能にするよりも効率的ではありません。このように、ソフトウェア開発者チームは、適切なプロセスを導入することで、より多くの時間を自分たちの好きなことに集中することができます。
CircleCI recommends that Developer Experience Managers have these qualifications:
Experience in leading software development teams
A deep understanding of modern development practices and tools
Ability to set team goals that align with business goals
Is a process expert who can organize and disseminate information
Decision-making ability
CircleCIでは、デベロッパーエクスペリエンスマネージャーに以下の資格を持つことを推奨しています。
ソフトウェア開発チームを率いた経験
最新の開発プラクティスとツールの深い理解
ビジネスゴールと整合するチーム目標を設定する能力
情報を整理し、広めることができるプロセスの専門家であること
意思決定能力
4 Developer Velocity: How software excellence fuels business performance
mckinsey.com
Comments