60. アジャイル開発を学ぼう

95IG7y3HHX7yl4/07_チーム開発/05_アジャイル開発を学ぼう/課題.md

@@ -0,0 +1,226 @@
+# 以下の文献に目を通しましょう
+- [x] アジャイルマニフェスト　（必須）
+- [x] アジャイルサムライ　（任意）
+
+# 課題１（質問）
+## アジャイル開発とは何でしょうか？どのような問題を解決するのでしょうか？
+アジャイル（agile）は「素早い」「機敏な」を意味し、ソフトウェア開発における柔軟で反復的なアプローチを指す。
+ウォーターフォール型とは異なり、短い開発サイクル（イテレーション）で『計画→設計→実装→テスト』を繰り返し、各サイクルで機能を追加・改善する。
+これにより、顧客のフィードバックを迅速に反映し、変化する要求や市場のニーズに対応できる。
+
+<img src="https://www.fujitsu.com/jp/imagesgig5/wf_tcm102-6254287_tcm102-2750236-32.png" width=500>
+
+[アジャイル開発とは（前編）](https://www.fujitsu.com/jp/services/agile/featurestories/about-agile-01.html)より
+
+
+### アジャイル開発のメリット(アジャイル開発が解決する主な問題)
+
+1. **開発途中の仕様変更に柔軟に対応できる**:
+アジャイル開発は、ウォーターフォール開発のデメリットである開発途中での仕様変更がしにくい点を改善する目的で生まれたものであり、開発途中の仕様変更を想定した方法であるため、柔軟に対応できる点が最大のメリットである。
+
+2. **迅速なソフトウェアリリース**:
+アジャイル開発では、短いイテレーションでの開発を行い、各サイクルで動くソフトウェアをリリースする。
+これにより、早期にユーザーのフィードバックを得て、次のサイクルで改善を行うことができる。
+ドキュメントよりも動くソフトウェアを重視するため、ドキュメント作成にかかる時間を省略し、開発に集中できる点も速さの一因である。
+
+ただし、継続的な変更を前提としているため、プロジェクト全体の完成までの期間が長くなる可能性もある。特に、期間があらかじめ指定されているプロジェクトでは、アジャイルの柔軟性が制約となることもある。
+
+3. **ユーザビリティが向上する**:
+アジャイル開発では、開発工程で何度もリリースとテストが行われ、そのたびにクライアントやテストユーザーからの意見を取り入れるため、ソフトウェアにユーザーの意見が反映される。その結果、よりユーザビリティの高いソフトウェアの完成が期待できる。
+
+### アジャイル開発のデメリット
+
+1. **長期的な計画の不確実性**:
+アジャイルでは変化に柔軟に対応することを重視するため、初期の計画が細かく決まっていない場合がある。
+これはプロジェクトの初期段階での不確実性を増す可能性がある。特に大規模プロジェクトでは、計画の変更が頻繁に発生することで混乱を招くことがある。
+
+2. **顧客の関与が必要**:
+アジャイル開発では、顧客からのフィードバックを頻繁に求めるため、顧客の関与が不可欠である。しかし、顧客が十分に関与できない場合、開発の方向性が不明確になり、期待通りの成果を得られないことがある。
+
+
+## アジャイル開発を取り入れると機能の開発スピードが上がる、と言われることがあります。これは果たして正しい考え方でしょうか？
+
+アジャイル開発において迅速なのは、短いイテレーションでの開発からのユーザーのリリースまでのこと。
+プロジェクト設立から完成までの期間という文脈ではない(そもそもソフトウェアに完成はない気がするが)。
+継続的な変更を前提としているため、最初に提示されたプロジェクト全体の要件を満たすまでの期間が長くなる可能性はある。
+
+## アジャイル開発、およびアジャイル開発を実践する手法の一つである「エクストリームプログラミング」に関連する以下の用語を説明してください。 また付随する質問がある場合は回答してください
+
+
+### ユーザーストーリー
+#### 説明
+ユーザーストーリーとは、エンドユーザーの視点から書かれた、ソフトウェアの機能に関する簡単な説明のことです。これらのストーリーは、開発チームに背景情報を提供する目的で、技術的な言葉を使わずに書かれる場合がほとんどです。
+
+ユーザーストーリーは、通常、「(ペルソナ) として、(結果) ができるように、(ソフトウェアの目標) をしたい」という形式に従って一文で書かれます。
+
+[ユーザーストーリー: ユーザー価値の高め方 (3 つの実例付)](https://asana.com/ja/resources/user-stories)
+[ユーザーストーリーとは？アジャイル開発における活用例や書き方を解説](https://spice-factory.co.jp/development/user-story/#i)
+
+#### 付随質問
+> ユーザストーリーはあまり具体的に書かない（インデックスカードに収まる3行程度で書く）ことを推奨されています。これは何故でしょうか?
+ユーザーストーリーにはそれを叶えるための、具体的な実装手段は書かない。
+具体的な手段は、ユーザーにとって実装手段重要ではない。
+
+[ユーザーストーリー駆動開発で行こう。](https://www.docswell.com/s/papanda/ZJW8EK-ss-41638116/27)
+
+### ストーリーポイント
+#### 説明
+ストーリーポイントは作業アイテムの大きさと複雑さの目安となる基準である。 (略)ほとんどの場合、アジャイルチームはストーリーポイントの尺度として1～13のフィボナッチ数列（1,2,3,5,8,13）を使用し、各作業アイテムのサイズをストーリーポイントで割り当てる
+
+[More Effective Agile ー"ソフトウェアリーダー"になるための28の道標](https://amzn.to/3uO8RKz)（Steve McConnell 著、長沢 智治 監訳、クイープ 訳、日経BP、2020/6/11）の209ページ
+
+
+ストーリーポイントとは、チームがタスクを完了するために必要な工数を調べるための見積もりの手法であり、アジャイルのプロジェクト管理メソッドで用いられます。ストーリーポイントは、タスクの難易度や不確実性などの要因 (ファクター) を考慮するため、時間ベースの見積もりをはじめとするその他の見積もりの方法よりも、正確に推測できます。
+
+[asana ストーリーポイントとは？6 つの簡単なステップでアジャイルで仕事量を見積もる方法](https://asana.com/ja/resources/story-points)
+
+#### 付随質問
+> イテレーションの途中で、思ったより時間がかかったストーリーのストーリーポイントは増やすべきでしょうか？それとも当初予定通りのストーリーポイントとして残しておくべきでしょうか？
+
+増やすべきではない。
+ストリーポイントは、チームの見積もり精度を向上させるための学習ツールとしても機能する。
+イテレーション終了後のレトロスペクティブ(振り返り)で、なぜ見積がズレたのかを分析して、次回以降の見積に活かすべきである。
+
+
+
+> ストーリーポイントには「実際に開発にかかった時間」と「当初見積もった時間」、どちらを使うべきだと思いますか？
+
+ストリーポイントは必要な工数を見積もる手段なので、「当初見積もった時間」を使用すべき。
+
+> ストーリーポイントはマネージャーがエンジニアを全力で働かせるための管理ツールとして誤用されていることが多いとXPの考案者が嘆いていました。本来ストーリーポイントとはどのように活用されるべきなのでしょうか？
+
+見積？？？
+
+### タスク
+#### 説明
+ユーザーストーリーを実現するために必要な具体的な作業項目
+
+#### 付随質問
+> タスクとユーザーストーリーはどのように異なり、どのように相互関連しているのでしょうか？
+
+エンドユーザーの視点から見た機能の説明
+タスクはユーザーストーリーを実現するための具体的な作業
+
+
+### イテレーション
+#### 説明
+短期間で開発を繰り返すアジャイル開発、その中で使われる開発サイクルの単位を表す言葉を、イテレーション (Iteration) といいます。
+
+「設計」「開発」「テスト」「改善」 から構成されるイテレーションは通常1〜4週間で設定され、システム開発のサイクルを一通り回すことが特徴です。一つのサイクルを回した後にリリース、これを イテレーション 1 とした時、イテレーション 2、イテレーション ３… というように繰り返します。
+<img src="https://ctf-cci-com.imgix.net/7wG3bhWAvzTQp5dIYL6UR/1debad22671673fef3f656dafb071517/what-is-iteration.png?ixlib=rb-3.2.1&auto=format&fit=max&q=75&dpr=1&w=750" width=500>
+[5分でわかるイテレーションとは？ 開発プロセスやスプリントの違い、特徴などを全て解説](https://circleci.com/ja/blog/iteration/#%E3%82%A4%E3%83%86%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3iteration%E3%81%A8%E3%81%AF)
+
+
+### [イテレーション計画](https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/plan/iteration-paths#iteration-planning)
+#### 説明
+イテレーション計画は、特定の期間内に達成すべき作業を計画することを指します。
+
+### [リリース計画](https://shorturl.at/ViCke)
+#### 説明
+プロダクト開発を正しく進めるために、理論的なリリースを頻繁に行うことがリリース計画の目的です。
+遠い未来ではなく、近い未来を詳細に計画します。各リリースにおける作業概要の説明ではありません。
+
+[リリース計画を成功させるための5つのステップ](https://shorturl.at/ofJSB)
+
+#### 付随質問
+> イテレーション計画とはどのような相違点があるのでしょうか？
+
+イテレーション計画
+- スコープ: 短期間（通常1〜4週間）の開発サイクルに焦点を当てた計画
+- 目的: 各イテレーションで達成すべき具体的な作業を計画し、チームが短期間で成果を出すための詳細なタスクを設定する。
+
+リリース計画
+- スコープ: プロダクト全体のリリースに関する計画で、通常は数ヶ月から1年程度の長期的な視点で行われる。
+- 目的: プロダクトの主要なリリースをスケジュールし、どの機能がどのリリースに含まれるかを決定する。
+
+### [プランニングポーカー](https://shorturl.at/eOud8)
+#### 説明
+目的
+- 見積もり担当者と実装担当者とのギャップを埋める
+- 一人で見積もりするよりも早く正確に見積もれる
+
+やり方
+1. ユーザーストーリーの一覧を洗い出す
+2. ユーザーストーリーの中から基準となるストーリーを決めて、1pt もしくは3ptを割り当てる
+3. ユーザーストーリーの1つずつ読み以下を繰り返す
+  1. ストーリーの詳細をヒアリングする
+  2. ストーリーが大きすぎる場合は分割する
+  3. 全員で見積もって、各自プランニングポーカーのカードを裏返しに場に出す
+  4. 全員同時にカードを表にする
+  5. チームでそれぞれの意見を聞いて妥当な数字で合意して決める。特に一番大きい数字と一番小さい数字の意見を聞く
+
+### ベロシティ
+#### 説明
+ベロシティとは、開発チームが1回のイテレーション（スプリント）で完了したストーリーポイントの合計値です。
+
+#### 付随質問
+> 同じ人数のAチームとBチームが居ます。AチームはBチームと比較してベロシティが2倍ほど高いようです。AチームはBチームより優秀だと断言しても良いでしょうか？
+イテレーションの期間の設定の違い、ストーリーポイントの基準が異なる場合や、チームが担当しているの性質も考慮する必要がある。
+ベロシティのみからは判断できない。
+
+> 部分的に完了しているユーザーストーリーがある場合、途中進捗のストーリーポイントはイテレーションのベロシティに含めるべきでしょうか？（10ptのユーザーストーリーが半分くらい終わっている場合、5ptを今週のベロシティに追加するべきでしょうか？）
+部分的に完了したユーザーストーリーのストーリーポイントは、通常、そのイテレーションのベロシティには含めません。
+ベロシティは完了したストーリーのポイントの合計で計算されるため、次のイテレーションでストーリーが完了した時点で全体のポイントを加算します。
+これにより、ベロシティの計測が一貫性を保ち、チームの進捗を正確に反映することができます。
+[部分的に完了したストーリーの再見積もり](https://shorturl.at/NZzwa)
+
+### [レトロスペクティブ](https://shorturl.at/YWFbm)
+スプリントで、”何がうまくいったのか”、”何がうまくいかなかったのか”の振り返り
+
+# 課題2
+## あなたが現在開発しているサービスのユーザーストーリーを5つ作成してください
+1. 漫画アプリを開いたときに、前回読んでいた漫画の続きからすぐに読み始めたい。
+
+2. 好きな作品の新しい漫画がリリースされたときに通知を受け取りたい。
+
+3. 漫画をオフラインで読むために、事前にダウンロードしておきたい。
+
+4. 好きな漫画を友達に簡単にシェアしたい。
+
+5. 自分が面白いと思う新しい漫画を素早く見つけたい
+
+## XPやアジャイル開発とは直接関係しないものの、以下の用語も理解しておくと何かと便利です
+> バーンアップチャートとバーンダウンチャート
+分かりやすくまとめられている画像があったので拝借
+<img src="https://assets.st-note.com/img/1663054611621-YtNdhwnbpO.png?width=1200" width=500>
+[進捗を一目で把握！バーンダウンチャート・バーンアップチャートの特徴と使い分け](https://note.com/tanny_pdm/n/n9a7f8c2c46e3)より
+
+> ブルックスの法則、コンウェイの法則
+### ブルックスの法則
+> ブルックスの法則（ブルックスのほうそく）は、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。
+[Wiki ブルックスの法則](https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87)
+
+理由
+1. 新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる
+2. 人員の投下は、チーム内のコミュニケーションコストを増大させる
+3. タスクの分解可能性には限界がある
+
+### コンウェイの法則
+「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」 1967年にアメリカのコンピュータープログラマーのメルヴィン・コンウェイ（Melvin Edward Conway）が提唱した原則
+(原文: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.")
+
+シングルモジュールでサービスを開発していると、開発チームも一塊になる。
+もし、サービスを分割してマイクロサービス化したなら、それに合わせて開発チームも機能単位と変わっていく。
+
+### 逆コンウェイの法則
+コンウェイの法則を逆手に取ったのが、逆コンウェイの法則
+アーキテクチャによって組織構造を変化させる後追いのではなく、そもそも最初から最適なアーキテクチャに合うような組織デザインを設計するという「アーキテクチャのための組織を作る」というイメージ。
+
+[コンウェイの法則と逆コンウェイの法則から組織構造を考える](https://medium.com/i35-267/%E3%82%B3%E3%83%B3%E3%82%A6%E3%82%A7%E3%82%A4%E3%81%AE%E6%B3%95%E5%89%87%E3%81%A8%E9%80%86%E3%82%B3%E3%83%B3%E3%82%A6%E3%82%A7%E3%82%A4%E3%81%AE%E6%B3%95%E5%89%87%E3%81%8B%E3%82%89%E7%B5%84%E7%B9%94%E6%A7%8B%E9%80%A0%E3%82%92%E8%80%83%E3%81%88%E3%82%8B-bf3f32ebb022)
+このサイトわかりやすかった。
+
+> QCDS（Quality, Cost, Delivery, Scope）
+
+生産管理における主要な要素
+- Quality(品質)
+- Cost(予算)
+- Delivery(納期・スケジュール)
+- Scope(範囲)
+
+Quality(品質を下げて不具合のあるシステムは出せない)とCost(コストを上げてエンジニアを増やしたところで、半分の納期になるわけではないし、開発スピードが悪化する可能性がある)ではなく、DeliveryとScopeを柔軟に変更しようぜっていう考え方。
+
+この説明が[非エンジニアにこそ読んでほしい、自社開発WebサービスのQCDS](https://qiita.com/rf_p/items/bd825d702f4be942e1ba)とても良かった！
+
+
+任意課題の資料がめちゃくちゃ良かった。
+http://www.jp.square-enix.com/tech/openconference/library/2011/dldata/PM/PM.pdf