dynamics 365: プロジェクトにおけるアジャイル開発の考察

前のこちらの記事では、PJの種類が大きく3つが分けられると言いました。

dynamics 365 プロジェクトの種類をまとめ | shenghao365 (shenghaohuang.com)

どんなプロジェクトにおいても、インテグレーション、ETL、カスタマイズ、拡張などの開発タスクは不可欠です。

アジャイル開発が流行っている現在、dynamics 365のプロジェクトにおけるアジャイル開発の手法、および考え方を個人的な見解も含めてシェアしていきたいと思います。

アジャイル開発の要点
4つの基本用語の説明
3つのアウトプット
3つの役割
5つのミーティング
まとめ：自分の居場所を見つける

アジャイル開発の要点

第一に、常にビジネス戦略を把握し、変化を受け入れ、製品の機能に優先順位をつけて、現時点で最も重要なことを可能な限り迅速に実行する。つまり、適切と思われることを実行する。

第二に、パターンの発見、オペレーションの合理化、コラボレーションの改善により、単位時間当たりの能力を最大化すること。つまり、物事を正しく実行する。

開発手法がアジャイルと呼ばれるためには、「漸進的」「協調的」「素直」「適応可能」という4つの本質的な特徴を持つ必要があります。

「漸進的」：小規模なバージョン、頻繁なリリース。

「協調的」：お客様と開発者と密なコミュニケーションを取った上で、共同作業を行う。

「素直」：メソッド自体は簡単に習得でき、変更も可能。

「適応可能」：変化を考慮し、柔軟に対応する能力。

4つの基本用語の説明

スクラム：アジャイル開発。軽量のソフトウェア開発方法論であり、漸進的、反復的な開発プロセスである開発フレームワーク。

スプリント：開発サイクル全体が、スプリントと呼ばれるいくつかの小さなイテレーションで構成されており、各スプリントの推奨期間は2〜4週間です。

バックログ：To-Doタスクのリスト。スクラムでは、製品やプロジェクトの要件を管理するために「製品バックログ」を使用します。

ストーリー：タスクの詳細で、通常はバックログリストのエントリの形をしており、ユーザーストーリーとも呼ばれる。ソフトウェア要求仕様書と同様に、システムの様々なユーザーのそれぞれの使用シナリオの観点から記述された機能である。ユーザーストーリーでは、ユーザー、システム、ソフトウェアの購入者にとって価値のある機能を説明します。

3つのアウトプット

製品バックログ：要求リストに似た製品機能のリストで、製品機能計画会議からの出力です。

スプリントバックログ：反復タスクリスト。スプリント計画会議のアウトプットで、スプリントで選択された要求の分析、議論、見積もりを行い、スプリントのタスクリストを作成するもので、これをスプリントバックログと呼ぶ。

Burn-down Chart: 進捗状況を把握するためのチャートツール。

3つの役割

役割	職責、立場
1.プロダクトオーナー	製品の所有者。プロダクトマネージャーと似たような立場で、彼が重視するのは「適切と思われることを実行する」ということ。
2.スクラムマスター	スクラム活動のマネージャーやコーチで、プロジェクトマネージャーのようなポジション。彼が重視するのは「物事を正しく実行する」ということ。
3.スクラムチーム	実装チームで、通常はResearch、Development、テストを行いますが、オペレーション、セキュリティ、UIも担当します。

以下は役割ごとに詳しく説明します。

プロダクトオーナー：

　大まかに言えば、プロダクトオーナーはCEOであったり、会社のプロダクトディレクターであったり、プロダクトラインのプロダクトマネージャーであったりします。また、一部の経営者を加えて2〜3名の製品決定委員会を構成し、意思決定の責任を共有することもできます。

　プロダクトオーナーの主な仕事は、製品機能の定義、市場価値に基づいた製品機能の優先順位付け、リリース日と内容の決定、結果の受け入れなどです。プロダクトオーナーの役割で最も重要なのは、「何をすべきか」を決めることです。資源は常に限られていて貴重であり、市場のチャンスはつかの間のものですから、誰かがステップアップして、今何をすべきで何をすべきでないかを決定し、その結果とコストに責任を負うつもりでいなければなりません。その人は、製品の所有者であるプロダクトオーナーです。私はProduct Ownerというオリジナルの書き方がとても好きなので、他の言葉に解釈したくありません。

スクラムマスター：

　スクラムマスターは、一般的にはアジャイルコーチと訳されています。スクラムマスターに専任者を採用している企業もあれば、コスト面から技術リーダーをスクラムマスターに採用している企業もあり、また、プロジェクトデリバリーの要求からプロジェクトマネージャーをスクラムマスターに採用している企業もあります。どれが一番合理的か？

　スクラムマスターの主な責務を分析したところ、このポジションはチームリーダー、リソースの保護者、コストオーナーとして機能し、チームメンバーにタイムリーな支援を提供できるプロダクトオーナーと密接に連携する必要があることがわかりました。彼は、チームのリソースが十分に活用され、メンバーが協力し合い、外部からの干渉を遮断して、高い生産性を実現しなければなりません。

　フルタイムのスクラムマスターを雇用する予算がない企業では、プロジェクトマネージャーやテクニカルリードなど、パートタイムで埋める他のポジションを見つけることができます。会社ごとに、またITチームごとに異なるので、スクラムマスターの責任を1人または複数の人に割り当てることができます。私のアプローチは以下の通りです。

　1、プロダクトマネージャーとプロジェクトマネージャーは、「チームのリソースが十分に活用されるようにする」「外部からの干渉を遮断する」という仕事を担います。私はプロダクトディレクターに「リリース間の中断がないこと」というKPIを課し、企業戦略の変更に合わせてプロダクトバックログには常に「最新のもの、優先順位の高いもの、最小の粒度に分解されたもの」があることを要求しています。要件のクエ。 R&Dチームは、前のSprintが終わっていれば、直接、技術的なプレリサーチ、レビュー、開発に着手することができます。

　2、Research&Developmentの担当者は、「スケジュール通りに開発が進むようにする」「開発上の障害を解決する」という仕事を担うことになります。例えば、テスト、セキュリティ、運用・保守などの部門横断的な調整作業については、プロダクトマネージャーチームに頼らず、彼が主体となってリアルタイムに推進していく必要があります。むしろ、より自発的に、積極的に協力部署に注意を促しています。これにより、製品チームは効果的に保護され、製品オーナーとしての中核的な機能に集中することができ、些細なことに煩わされることなく、革新と思考を行うことができます。

スクラムチーム：

　アジャイルメンターは、標準化された生産パイプラインを作る必要があります。ビジネス、オペレーション、プロダクトマネージャー、インタラクション、ビジュアル、R&D、テスト、オペレーション、セキュリティなど、すべての人が仮想パイプラインの中の適切な固定された位置にいて、「ルールと規則」と「タイムスケジュール」によって、各位置が、指定された時間に、指定された基準で、計画されたことを行うことを求められます。

　また、各職能は「品質管理検査」というKPIを持ち、前工程が「適格」であるかどうかをチェックし、「受領」「拒絶」をさせなければなりません。受け入れる」か「拒否する」かの権利です。

　もし、プロダクトマネージャーの要求文書が詳細でなく、論理が穴だらけであれば、R&Dはその製品を受け入れない権利があります。

　もし、R&Dのコード品質が標準に達しておらず、最初のテストがバグだった場合、そのテストには納品を受けない権利があります。

　プロダクトマネージャーの受け入れが設計と矛盾していることが判明した場合、プロダクトマネージャーは商品を受け取らない権利を有しています。

　そうすることの配当は、第一に、前のセッションのアウトプットをより注意深く確認し、そのエラーが自分のセッションに波及しないようにすること、第二に、時間の概念を強化し、納期が近くなると、品質管理の検査を担当するポストは、自分の「検査」を遅らせないように、前のセッションに細心の注意を払って、納期に間に合うかどうかを確認することです。

5つのミーティング

MTG項目	説明
Product Backlog Refinement	プロダクト・フィーチャープランニング MTGに似ている。これは通常、社内のプロダクトオーナー会議で、意思決定者を呼んで議論することができます。
Sprint Planning Meeting	プロジェクト要件の明確化、タスクブレークダウン活動に似たスプリント計画会議。一般的にはテクニカルレビューと理解されています。
Sprint Review Meeting	スプリント・レビュー・ミーティング。
Sprint Retrospective Meeting	プロジェクトの振り返りや反省会に似たような、スプリントの振り返りミーティング。
Daily Scrum Meeting	毎日朝会・夕会を含めて、作業報告のMTG。

　噂話ですが、テンセント(Tencent)のデイリースクラムは非常に厳しく、何をしていても、会議の時間になるとプロジェクトマネージャーに強制的にプロジェクトボードに運ばれます。毎日のスタンドアップミーティングというのが一番しっくりきます。デイリースクラムは毎朝行うのがベストです。朝が一番楽で、ニュースを見たり、お茶を飲んだりしているうちに1～2時間は経ってしまいます。デイリースクラムはメンバーの気合を入れるのに適しているので、チームリーダーはもっと頻繁にスクラムに参加して、スクラムの最後にチームを後押しするべきだと思います。