Loading article…
アジャイル原則では、タイムボックス化は、計画されたアクティビティが行われる時間の最大単位 (タイムボックスと呼ばれる) をアクティビティに割り当てます。これは、アジャイル原則に基づくプロジェクト管理アプローチや個人の時間管理に使用されます 。
プロジェクト管理において
タイムボックスはプロジェクト計画の手法として使用されます。スケジュールはいくつかの別々の期間 (タイムボックス) に分割され、各部分には独自の成果物、期限、予算があります。[要出典]独立変数としてのスケジュール(SAIV)と呼ばれることもあります。 [1]「タイムボックスは、時間がほとんどかからず、同じ時間枠に収めることができる多段階プロジェクトやタスクに最適です。完了までのタイムフレームが予測できる業務の場合にも実装する価値があります。」[2]
スコープを固定する代わりに
プロジェクト管理では、一般的に、時間（場合によってはスケジュール）、コスト（場合によっては予算）、範囲という3つの制約があると考えられています。[3] [4] [5] [6] [7]（品質は、三角形の中央で表される4番目の制約として追加されることがよくあります。[8] [9] [10]）1つの制約の変更が他の制約に影響を及ぼすという前提があります。[6]
タイムボックス化を行わない場合、プロジェクトは通常、固定されたスコープ内で作業します。[11]その場合、一部の成果物が計画された時間内に完了できないことが明らかになった場合、期限を延長するか（固定されたスコープを完了するための時間を増やすため）、より多くの人員を関与させるか（固定されたスコープを同じ時間内に完了するため）のいずれかを行う必要があります。多くの場合、両方が発生し、納品の遅延、コストの増加、そして多くの場合、品質の低下につながります（神話的な人月の原則による）。
タイムボックスでは期限が固定されるため、範囲を縮小する必要があります。これは、組織が最も重要な成果物を最初に完了することに集中する必要があることを意味するため、タイムボックスは成果物の優先順位付けスキーム（MoSCoWメソッドなど）と密接に関連していることがよくあります。[12]
リスクを管理する
タイムボックスはリスク管理の一形態として使用され、不確実なタスク/時間関係、つまり期限を簡単に超える可能性のある作業を明示的に識別します。時間制約は計画の主な推進力となることが多く、プロジェクトまたはサブプロジェクトのクリティカル パスを考慮せずに変更してはなりません。つまり、通常は期限を守ることが重要です。期限に間に合わないリスク要因には、プロジェクトの上流での複雑さ、プロジェクト内の計画エラー、チーム関連の問題、または計画の実行ミスが含まれます。上流の問題には、プロジェクトのミッションの変更や経営陣からの支援/サポートが含まれる場合があります。一般的な計画エラーは、作業の実行に必要な時間を過小評価することにつながる、不適切なタスクの内訳です。チーム関連の問題には、チーム間コミュニケーションの問題、経験不足または必要な部門横断的な機能の欠如、コミットメント/意欲/モチベーションの欠如 (つまり、チームの構築と管理が不十分) が含まれます。
期限を守るために、3 つの制約に対する次のアクションが一般的に評価されます。
- 範囲を縮小する: 影響度の低い要件（ユーザーが直接見逃すことのない要件）を削除する
- ここでは時間が固定された制約である
- コストの増加: 例: 残業やリソースの追加
ソフトウェア開発における採用
多くの成功したソフトウェア開発プロジェクト、特に小規模なプロジェクトでは、タイムボックス化が使用されています。 [13] 80年代にデュポン社では、タイムボックス化の導入により、開発者の生産性が3倍以上に向上しました。 [14]場合によっては、仕様を完成させるのにかかると見積もられた時間内にアプリケーションが完全に納品されました。[14]しかし、スティーブ・マッコーネルは、すべての製品が適しているわけではないと主張しており[14]、タイムボックス化は、顧客が品質ではなく機能の削減に同意した後でのみ使用すべきであると述べています。[14]最大規模のプロジェクトで積極的に採用されているという証拠はほとんどありません。[13]
タイムボックスは、いくつかの著名なソフトウェア開発方法論で採用されています。
- 動的システム開発手法（DSDM）。[12]
- リーンソフトウェア開発では、カンバンによるプルスケジューリングが短期的な時間管理を提供します。長期計画が必要な大規模で複雑なシステムを開発する場合は、タイムボックスがその上に重ねられます。[15]
- ラピッドアプリケーション開発（RAD）ソフトウェア開発プロセスは、反復開発とソフトウェアプロトタイピングを特徴としています。スティーブ・マッコーネルによると、タイムボックスはRADの「ベストプラクティス」であり、典型的なタイムボックスの長さは60〜120日です。[14]
- スクラムは、タイムボックスと反復開発の考え方に影響を受けています。[16]スプリントと呼ばれる定期的なタイムボックス単位が開発の基本単位を形成します。[17]スプリントの典型的な長さは30日未満です。[18] [19]スプリント計画、スプリントの振り返り、スプリントレビューの会議はタイムボックス化されています。[18]
- エクストリームプログラミング手法では、開発計画は通常1週間、2週間、または3週間の反復にタイムボックス化されます。ビジネス部門は、各反復の前に保留中のユーザーストーリーを再評価します。[20]
アジャイルソフトウェア開発は、計画主導型開発から価値主導型開発への移行を提唱しています。品質と時間は固定されていますが、範囲には柔軟性が認められています。最も重要な機能を最初に提供することで、ウォーターフォールモデルよりも早い投資回収につながります。[7]
詳細な仕様が欠如している理由は、通常、時間が足りないか、望ましい最終結果（ソリューション）に関する知識が不足していることです。多くの種類のプロジェクト、特にソフトウェアエンジニアリングでは、実現フェーズの開始前にすべての要件と仕様を分析して定義することは不可能です。タイムボックスは、期限が最も重要であり、すべての要件が事前に完全に指定されていないプロジェクトに適した契約形態です。これにより、プロジェクト中に発見された新しいフィードバックや洞察を最終結果に反映させることもできます。[12]
個人的な時間管理
タイムボックスは個人的なタスクにも使用できます。その場合、時間のスケール (例: 30 分) と成果物 (例: プロジェクトの成果物ではなく家事) が縮小され、タイムブロッキングと呼ばれることがよくあります。
個人的なタイムボックスは、完璧主義の傾向を抑制する（しっかりとした時間を設定し、タスクに過度にコミットしない）ライフハックとしても機能し、創造性と集中力を高める（緊急感やプレッシャーの増大を生み出す）とも言われています。[21]
他の方法との関係
タイムボックスは、他の個人的な時間管理方法の基盤として機能します。
参照
- デザインスプリントは、デザイン思考で使用される時間制限のある 5 段階のプロセスです。
参考文献
- ^ ボーム、バリー W.; ボーム、バリー; ターナー、リチャード (2004)。敏捷性と規律のバランス: 困惑した人のためのガイド。アディソン・ウェズリー・プロフェッショナル。ISBN 9780321186126。
- ^ 「タイムボックス – なぜ使用すべきか？」Firmbee 2022年1月17日2022年1月25日閲覧。
- ^ プロジェクト管理における 3 つの制約とは何か アーカイブ 2006-08-20 at archive.today、Rod Hutchings による Project Management Australia の記事 アーカイブ 2009-02-16 at the Wayback Machine (2008 年 10 月 22 日)
- ^ Chatfield, Carl. 「プロジェクト管理短期コース」 Microsoft.
- ^ ドブソン、マイケル (2004)。プロジェクト管理における 3 つの制約。ウィーン、バージニア州: マネジメント コンセプト。ISBN 1-56726-152-3。
- ^ ab Kanabar, Vijay (2008). MBA Fundamentals: Project Management . ニューヨーク: Kaplan Pub. p. 51. ISBN 978-1-4277-9744-5。
- ^ ab Leffingwell, Dean (2011). Agile Software Requirements: Lean requirements practice for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley. pp. 17–19. ISBN 978-0-321-63584-6。
- ^ スネダカー、スーザン、ネルス・ホーニグ（2005年）。ITプロジェクト管理でごまかす方法。Syngress。ISBN 1-59749-037-7。
- ^ ベック、ケント (2000)。エクストリームプログラミングの解説：変化を受け入れる。マサチューセッツ州レディング：アディソンウェスレー。pp. 15–19。ISBN 0-201-61641-6。
- ^ ダンジェロ、マーク (2005)。革新的な関連性: 利益のために組織を再編成: それは「海岸線」のための戦いではなく、目的のための闘いです。ニューヨーク: iUniverse。p. 53。ISBN 978-0-595-67081-9。
- ^ Godin, Seth. 「Getting Real: 成功する Web アプリケーションを構築するための、よりスマートで、より速く、より簡単な方法」。37signals。
- ^ abc Jennifer., Stapleton (1997). DSDM、動的システム開発手法：実践的手法。ハーロー、イギリス：Addison-Wesley。ISBN 0201178893. OCLC 36755892.
- ^ ab すべてのプロジェクト タイプで、タイム ボックスは 23 位にランクされ、「非常に優れた実践」と評価されています。小規模 (1000機能ポイント) プロジェクトでは、 Jones、Capers (2010)の調査で 7 位にランクされ、「ベスト プラクティス」と評価されています。トップ企業の成功したプロジェクトから学ぶソフトウェア エンジニアリングのベスト プラクティス。ニューヨーク: McGraw- Hill。ISBN 978-0-07-162162-5。
- ^ abcde McConnell, Steve (1996). Rapid Development: 野生のソフトウェアスケジュールを管理する. Redmond, Washington: Microsoft Press. pp. 575–583. ISBN 1-55615-900-5。
- ^ Poppendieck, Mary (2010). Leading Lean Software Development: Results are not the Point . Upper Saddle River, NJ: Addison-Wesley. pp. 137–140. ISBN 978-0-321-62070-5。
- ^ Coplien, James (2010). アジャイルソフトウェア開発のためのリーンアーキテクチャ。チチェスターホーボーケン、ニュージャージー：Wiley。p. 25。ISBN 978-0-470-68420-7。
- ^ コーン、マイク (2010)。アジャイルで成功する: スクラムを使用したソフトウェア開発。アッパーサドルリバー、ニュージャージー: アディソンウェスレー。pp. 257–284。ISBN 978-0-321-57936-2。
- ^ ab Schwaber, Ken (2009). アジャイルプロジェクトマネジメント with Scrum. ニューヨーク: O'Reilly Media, Inc. ISBN 978-0-7356-3790-0。
- ^ Leffingwell, Dean (2011). Agile Software Requirements: チーム、プログラム、企業のためのLean要件プラクティス。アッパーサドルリバー、ニュージャージー州: Addison-Wesley。p. 15。ISBN 978-0-321-63584-6。
- ^ ベック、ケント (2000)。エクストリームプログラミングの解説：変化を受け入れる。マサチューセッツ州レディング：アディソンウェスレー。pp. 85–96。ISBN 0-201-61641-6。
- ^ Pash, Adam (2011). Lifehacker よりスマートに、より速く、より良く働くためのガイド。インディアナポリス、インディアナ州: Wiley。Hack 29。ISBN 978-1-118-13345-3。
- ^ Nöteberg, Staffan (2009).ポモドーロテクニック図解. ローリー、ノースカロライナ州: Pragmatic Bookshelf. ISBN 978-1-934356-50-0。
- ^ ハント、アンドリュー (2008)。実用的な思考と学習：ウェットウェアのリファクタリング。ローリー：プラグマティック。ISBN 978-1-934356-05-0。