さらに効果的なアジャイルブック

こんにちは住民！これは利益に直接影響するため、どの企業もソフトウェア開発の効率を高めたいと考えています。アジャイルの文献の多くは大規模で高成長の企業に焦点を当てていますが、あなたの会社がITの最前線にいない場合はどうでしょうか。良いニュースは、すべての組織がパフォーマンスを向上させることができるということです。この本は、アジャイルを最大限に活用するための特定のパスとソリューションを見つけるのに役立ちます。 「私はアジャイルの伝道者ではありません。私は何がうまくいくかを支持し、多くのことを約束するが結果をもたらさないものの反対者です。この本では、アジャイル手法は、意識を高める必要のある運動としてではなく、ビジネスマンやITスペシャリストがその効果と相互作用を理解できる、一連の特別な管理および技術的手法として提示されています。アジャイル愛好家は、アジャイルのベストプラクティスを宣伝していないとしてこの本を批判するかもしれません。しかし、それがポイントです。効果的であることが証明されている実用的な方法に重点を置いています。アジャイルの歴史は、いくつかの組織の数人の愛好家によって首尾よく実行されたが、他のすべての人が使用することはできないアイデアでいっぱいです」とスティーブ・マコーネルは言います。伝説的な本CodeCompleteとSoftwareEstimationの著者であるSteveMcConnellによる新しい本は、何百もの企業の実際の経験をまとめています。現代的で最も効果的なアジャイルプラクティスへのシンプルでわかりやすいガイドを使用してください。これは、一部の組織の2人の愛好家によって正常に実装されましたが、他のすべての人によって使用されているわけではありません」とSteveMcConnell氏は述べています。伝説的な本CodeCompleteとSoftwareEstimationの著者であるSteveMcConnellによる新しい本は、何百もの企業の実際の経験をまとめています。現代的で最も効果的なアジャイルプラクティスへのシンプルでわかりやすいガイドを使用してください。これは、一部の組織の2人の愛好家によって正常に実装されましたが、他のすべての人によって使用されているわけではありません」とSteveMcConnell氏は述べています。伝説的な本CodeCompleteとSoftwareEstimationの著者であるSteveMcConnellによる新しい本は、何百もの企業の実際の経験をまとめています。現代的で最も効果的なアジャイルプラクティスへのシンプルでわかりやすいガイドを使用してください。

さらに効率的なプロジェクトの実行

前の章では、Agileで作業するときに開発者を編成およびサポートする方法について説明しました。この章では、アジャイルで作業するときに開発プロセスを適切に編成および維持する方法について説明します。



ほとんどのソフトウェア開発はプロジェクトに編成されています。組織は、製品、プログラム、リリース、リリースサイクル、機能、バリューストリーム、ワークフローなど、プロジェクトに関連する概念を説明するためにさまざまな用語を使用します。 ..。



用語はかなり異なります。一部の企業は、リリースはプロジェクトと同義であると信じています。他の人はリリースが進歩的な開発を指すと思うので、彼らはそれを使うのをやめました。さらに、「機能」の概念を3〜9人および1〜2年間に設計された作業量として定義する人もいます。この章では、「プロジェクト」という言葉は、リストされているタイプの作業のいずれか、つまり、特定の数の従業員の長期間の作業を意味します。

重要な原則：プロジェクトのサイズが小さい

過去20年間で、小規模プロジェクトでAgileを使用して成功した最も有名な事例。 Agileは、その存在の最初の10年間、プロジェクトを小さく保つことに大きな注意を払いました。つまり、チームの5〜10人（たとえば、3〜9人の開発者、製品所有者、スクラムマスター）です。図に示すように、小さなプロジェクトは大きなプロジェクトよりも扱いやすいため、小さなプロジェクトサイズに重点を置くことは非常に重要です。 9.1。





ケイパーズジョーンズは20年間、小さなプロジェクトは大きなプロジェクトよりも成功すると仮定してきました[ジョーンズ、1991; 2012]。プロジェクトの成功とサイズに関する研究のほとんどをCodePerfectの本にまとめました[McConnell、2004; SPb。：Peter、2007]およびソフトウェア推定：ブラックアートの謎を解き明かす[McConnell、2006]。



小さなプロジェクトは、いくつかの理由でより安全です。大規模なプロジェクトでは、より多くの専門家の関与が必要であり、チーム内の人々間およびチーム自体間の関係の数は、非線形の進行で増加します。そして、関係が複雑になるほど、相互作用でより多くの間違いが起こります。相互運用性エラーは、要件、設計、コーディングのエラーにつながります-一般的に、他のエラー。



その結果、プロジェクトが大きくなるほど、ミスが多くなります（図9.2）。これは、エラーの総数が増加しているだけでなく、大規模なプロジェクトでは計り知れないほど多くのエラーがあることを意味します。



エラー率が高いほど、欠陥検出戦略の有効性は低くなります。これは、完成品の欠陥の数が不均衡に増加することを意味します。





また、エラーを排除するためにより多くの努力が必要です。したがって、図に示すように。9.3では、プロジェクトが小さいほど1人あたりの生産性は高くなりますが、プロジェクトのサイズが大きいほど、生産性は低下します。この現象は、スケールのコストとして知られています。





サイズとパフォーマンスの間のこの逆の関係は、40年以上にわたって広く研究され、テストされてきました。 Fred Brooksは、彼の著書The Mythical Man-Monthの初版で、ソフトウェア開発の規模のコストについて説明しました[Brooks、1975; SPb。：Peter、2021]。ソフトウェア開発コストの見積もりに関するLarryPutnamの作業は、Brooksの観察を裏付けました[Putnam、1992]。開発コストモデル（Cocomo）の研究では、スケールのコストの存在が2回確認されました。1970年代後半の研究と1990年代後半の最新の研究です[Boehm、1981; 2000]。



重要な点は、アジャイルプロジェクトが成功する可能性を最大化するには、プロジェクト（およびチーム）を小さく保つようにすることです。



もちろん、すべてのプロジェクトを小さくすることは不可能です。第10章「大規模プロジェクトのさらに効率的な実行」では、大規模プロジェクトの縮小方法の提案を含め、大規模プロジェクトのアプローチについて概説します。

重要な原則：短いスプリント

プロジェクトのサイズが小さい方が望ましいという自然な結論は、スプリントは長くは続かないということです。小さなプロジェクトはすでに成功の秘訣だと思うかもしれません。しかし、1〜3週間の短いスプリントは、プロジェクト管理の全体的な成功に貢献します。これについては、次のいくつかのセクションで説明します。



スプリントを短くすると、中間要件の数が減り、新しい要件への応答性が向上します



。スクラムでは、スプリント間に新しい要件を追加できます。ただし、スプリントが開始されると、次のスプリントまで要件を追加できません。これは、スプリントの長さが1〜3週間の場合に意味があります。



開発サイクルに時間がかかる場合、利害関係者は途中で要件を追加することをますます強く求めているため、要件の追加を延期する要求はもはや正当化されません。順次開発モデルのサイクルが6か月続く場合、次のサイクルまで新しい要件の実装を延期するように関係者に依頼すると、要件の作業は次のサイクルでのみ開始されます。つまり、サイクルの開始時に、この要件は追加されるだけであり、この終了時に製品の配信を待つ必要があります。サイクル。平均して、1.5サイクル、つまり9か月かかります。





対照的に、通常のスクラムスプリントは2週間続きます。これは、新しい要件を追加したい利害関係者は、平均3週間待たなければならないことを意味します。





要件が実装されるまで9か月待つように利害関係者に求めることは、多くの場合不適切です。そして、ほとんどの場合、3週間が適切です。これは、スプリントの途中で新しい要件を恐れることなく、スクラムチームが静かに作業することを意味します。



短いスプリントは、クライアントや利害関係者と協力する際の応答性を向上させます



各スプリントは、動作するソフトウェアを紹介し、要件を検証し、利害関係者からフィードバックを生成する新しい機会を提供します。標準の2週間のスプリントで、チームは年に26回速くなる機会を自分たちに与えます！ 3か月の開発サイクルで、この機会は年に4回だけ提示されます。 15年前、3か月のプロジェクトは短いと見なされていました。今日、そのようなスケジュールは、利害関係者、顧客、および市場からのフィードバックに迅速に対応することができないことを意味します。



より短いスプリントは利害関係者の信頼を構築します



チームがより頻繁に結果を提供するにつれて、進捗状況はより透明になり、進捗状況は利害関係者に表示され、利害関係者とチームの間の信頼が構築されます。

短いスプリントは、学習と適応のサイクルを通じて開発速度を



向上させます。 反復率が高いほど、チームが学んだ教訓を振り返り、結論を導き出し、その結果を実際の作業方法に適用する機会が増えます。この分野の理論的根拠は、顧客の対応と同じです。チームに年に26回、または4回だけ学習して適応させる方がよいでしょうか？短いスプリントは、チームの改善を早めるのに役立ちます。



短いスプリントは実験時間を短縮するのに役立ちます



Cynefinのもつれた問題の文脈では、作業の全範囲を理解する前に、まず問題を調査する必要があります。そのような研究は次のように特徴づけられるべきです：「これまたはその質問への答えを得るために、必要とされる最小限の仕事をしてください。」残念ながら、パーキンソンの法則によれば、作業には利用可能なすべての時間がかかります。そして、チームが鉄の規律を開発するまで、問題の解決には、1か月が割り当てられている場合、正確に1か月かかります。しかし、2週間しかない場合、ほとんどの場合、問題の解決には2週間かかります。



短いスプリントにより、コストとリスクをタイムリーに検出できます



短いスプリントを使用すると、進行状況をより頻繁に追跡できます。ほんの数回のスプリントの後、新しいタスクに取り組むときに、チームの「スピード」または進行のペースが決定されます。作業の進行状況を監視する機能により、製品のリリースのタイミングを簡単に予測できます。作業に当初の計画よりも時間がかかっている場合、これはわずか数週間で明確になります。短いスプリントは、情報を常に入手するための強力なツールです。これについては、第20章「さらに優れた予測可能性」で詳しく説明します。



短いスプリントはチームの説明責任を促進します



チームが2週間ごとに作業機能を提供する責任がある場合、チームは暗闇の中で長時間作業する機会がありません。彼女はスプリントレビューミーティングで自分の仕事の結果を示し、2週間ごとに利害関係者に報告します。

製品の所有者は、労働の成果をさらに頻繁に目にします。



製品の所有者は作業を承認または拒否し、作業の進行状況が明確に表示されます。したがって、チームは自分の仕事に対してより責任があります。



短いスプリントは説明責任を促進します



何世代にもわたって、開発チームは何ヶ月も暗い部屋に閉じ込められた「星」に苦しみ、作業が進行しているかどうかは完全に不明でした。スクラムの場合、この問題はもう存在しません。誰もがスプリントでチームの目標をサポートするために働いています。さらに、毎日立ち上がって、昨日何が行われたかについて話し合う必要があります。これ以上自分を閉じ込めることはできません。開発者が協力し始めて、ある方法で問題を解決するか、状況に耐えられず、別の方法ではありますが、問題を解決するチームを離れます。私自身の経験から、何週間も何ヶ月も報告なしで働いている場合よりも、いずれの結果も良好であり、最終的には実際には何も行われていないことがわかります。







短いスプリントは自動化を促進するチームはしばしば調整を実行するため、短いスプリントは、そうでなければ反復的で時間のかかるタスクを自動化できます。自動化は、アセンブリ、統合、テスト、および静的コード分析で広く使用されています。



スプリントが短いほど、満足感が得



られる可能性が高くなります。2週間ごとに動作するソフトウェアを提供するチームは、作業に満足する可能性が高く、成果を祝う機会もあります。これは、モチベーションを育むプロ意識に貢献します。

短いスプリント。概要

一般に、短いスプリントの利点は次のように要約できます。「すべての点で配信速度は、作業量に対処するのに役立ちます。」小さなバッチと短いケイデンスでの機能の提供は、大きなバッチと長いケイデンスでの機能の提供に比べて非常に多くの利点をもたらします。

タスクの速度に基づいて計画する

ストーリー難易度の単位は、タスクのサイズと複雑さの尺度です。速度は、タスクが完了し、ストーリーの難易度の単位で測定される頻度に基づく進行状況の尺度です。速度ベースのスケジューリングは、履歴難易度単位と作業速度に基づいて作業を計画および追跡します。



スピードのスケジュールと追跡はスクラムチュートリアルの一部ではありませんが、私の経験では、それらを含めることをお勧めします。次に、ストーリーの難易度の単位と速度の見積もりがどのように適用されるかについて説明します。



製品バックログサイズの見積もり



難易度スコアは、製品バックログのサイズを決定するために使用されます。製品バックログの問題のサイズは通常、ストーリーの難易度の単位で見積もられ、次にストーリーの複雑さの単位が追加されて、製品バックログの合計サイズが計算されます。これは、リリースサイクルの開始時、および作業がバックログに追加または削除されたときに実行する必要があります。これは、チームが予測可能である必要がある範囲で行われます。詳細については、第20章「さらに優れた予測可能性」を参照してください。



速度の計算



各スプリントでチームが完了した作業量は、ストーリーの難易度の単位で計算されます。各スプリントで達成されたストーリー難易度ユニットの数は、チームのスピードを表しています。速度は、平均を計算することにより、各スプリントの結果に基づいて計算されます。



スプリント計画



チームは、チームの速度の観察に基づいて、スプリントごとの作業範囲を計画します。これもストーリーの難易度の単位で測定されます。



チームがスプリントごとに平均20ストーリー難易度ユニットを完了し、次のスプリントで40ストーリーユニットを完了するという目標を設定した場合、チームは計画を削減する必要があります。チームメンバーが休暇をとる場合、または複数のチームメンバーがトレーニングイベントに参加する場合、チームはスプリントごとのストーリーの難易度を平均よりも少なく計画する必要があります。チームが眠れない夜のおかげでストーリーの難易度20ユニットを完了し、週末に作業することができた場合は、バーも下げる必要があります。チームが一貫して簡単にスプリントの目標を達成する場合は、平均よりも多くのストーリー難易度をスケジュールしてみてください。いずれにせよ、チームは実際の速度に基づいて計画を立てています。



リリース追跡



平均速度に基づいて、製品バックログのタスクを完了するのにかかる時間を計算または予測できます。製品のバックログに200ストーリーの難易度ユニットがあり、チームの平均速度がスプリントあたり20ストーリーの難易度ユニットである場合、チームはバックログのすべてのタスクを完了するために10スプリントが必要になります。これがどのように機能するかについては、第20章「さらに優れた予測可能性」で詳しく説明します。



プロセスの変更、チーム構成、およびその他の変更の影響の説明



速度に基づいて、プロセス、チーム構成、およびその他の変更の変更の影響を追跡できます。この詳細については、第19章「プロセスをさらに改善する」で説明しています。

重要な原則：垂直スライスでの製品配送

スプリントを効果的にするには、チームは機能機能の小さなバッチを頻繁に提供する機能を開発する必要があります。これを容易にする設計アプローチは「垂直スライスの使用」と呼ばれ、増分または値を取得するために各アーキテクチャレイヤーに変更を加えることを意味します。



垂直スライスは、銀行の明細書にフィールドを追加したり、ユーザーのトランザクション確認を1秒速くしたりするなど、スタックの完全な機能を表します。図1に示すように、これらの各例では通常、テクノロジースタック全体を実行する必要があります。 9.4。



垂直スライスは、技術者以外の利害関係者がビジネス価値をよりよく理解、観察、および測定するのに役立つ傾向があります。これにより、チームはリリースをより迅速にリリースし、ビジネスにとっての製品の真の価値を実現し、ユーザーから真のフィードバックを得ることができます。



水平スライスを使用するチームは、いくつかのスプリントを続けてジャングルに突入するリスクを冒し、ある程度の進歩を反映しているが、目に見えるビジネス価値をもたらさないストーリーに取り組んでいます。





チームは、通常は効率が低いため、垂直スライスの使用に消極的な場合があります。たとえば、ビジネスロジック層でより多くの作業を行ってから、インターフェイス層に移動する方が効率的であると主張します。このアプローチは、水平スライスの使用と呼ばれます。



場合によっては、技術的な観点から、水平レイヤーでの作業がより効率的かもしれませんが、そのような技術的効率は、原則として、製品の個々の部分の最適化につながります。これは、価値のある機能を取得するほど重要ではありません。水平スライスを使用すると効率が向上するという主張に反して、当社は、水平スライスを使用すると、多くのチームが大幅な修正の必要性に直面していることを発見しました。



垂直スライスはより厳密なフィードバックを提供します



垂直スライスを使用すると、ビジネスユーザーに機能をすばやく提供できます。これにより、正しく機能している機能に関するフィードバックをすばやく取得できます。



垂直スライスはエンドツーエンドの開発を必要とするため、チームメンバーは設計と実装に協力することを余儀なくされ、チーム全体に有用な技術的フィードバックを提供します。



垂直スライスを使用すると、エンドツーエンドのテストも促進され、タイトなフィードバックを確保するのに役立ちます。



垂直スライスはより多くのビジネス価値を提供します



垂直スライスは技術的な詳細を知らない利害関係者によってよりよく理解され、これはビジネスが新しい機能と改訂された機能の実装の優先順位と順序について行うより良い品質決定につながります。



垂直スライスは完全な機能の増分を提供するため、多くの場合、ユーザーに作業機能を提示する機会を提供し、ビジネス価値を高めます。



水平スライスを使用すると、開発者はアーキテクチャを製品として認識するようになります。そして、これは、機能の提供に完全に不要なやりがいのある活動や、価値の低下につながる他の方法につながる可能性があります。



チームが垂直スライスを使用するために必要なもの垂直スライス



で機能を提供することは難しい場合があります。それは、チームの構成、そのビジネス、開発、およびテスト機能に依存します。これには、テクノロジースタック全体にわたるスキルが含まれます。



チームは、垂直スライスを操作するように設計と実装の考え方を変更する必要がある場合もあります。これは、コンポーネントや水平レイヤーを操作する場合とは異なります。一部のチームはこれを行うための設計スキルを欠いており、対処するためにそれらのスキルを開発（および開発を維持）する必要があります。



最後に、チームは垂直スライスで作業を行う必要があります。製品の所有者と開発チームは、結果が垂直スライスになるようにバックログを改善するアプローチを見つける必要があります。

重要な原則：技術債務の管理

「技術債務」とは、過去に質の悪い仕事が蓄積され、現在の仕事のペースが遅くなることを指します。古典的な例は、バグを修正しようとするたびに1つ以上の新しいバグを生成する脆弱なコードベースです。単純なエラーを修正するだけでも時間がかかり、追加のエラーを修正します。



技術的な負債には、低品質のコード、低品質の設計、弱いテストスイート、難しい設計アプローチ、面倒なビルド環境、遅い手動プロセス、およびチームが短期的な利益のために長期的なパフォーマンスを犠牲にするその他の方法が含まれます。



技術的債務の結果



債務は通常、品質を犠牲にして短期間の放出を優先するという圧力の結果として蓄積されます。投資されたリソースと得られたリターンの全体像には、時間の経過に伴う技術的債務の影響の説明が含まれます。





技術チームとビジネスチームには、この負債を累積するやむを得ない理由があります。一部のリリースは時間に敏感であるため、現在の作業をより速く実行したいという要望があるため、後で追加の作業を行う必要があります。



ただし、技術的な負債を処理する計画なしに時間の経過とともに蓄積することを可能にするモデルは、最終的にチームの速度を低下させます。チームは、スピードを維持または向上させるために、債務管理計画を作成する必要があります。





Kruchten、Nord、およびOzkayaは、技術的負債がどのように発生するか、それが持つ（可能性のある）ビジネス価値、および最終的に資産よりも負債になる方法についての優れた図を作成しました（図9.5）。





ゼロから作業する場合、チームはそもそも技術的な負債の蓄積を回避できます。すでに開始されている作業を実行する場合、チームは多くの場合、すでに蓄積されている技術的負債を処理する以外に選択肢がありません。すべての種類の作業で、チームが技術的な負債をうまく処理していない場合、速度は時間の経過とともに低下します。



技術的債務の返済技術的債務の返済には、



チームごとに異なるアプローチがあります。一部のチームは、負債を返済するために、開発サイクル（スプリントまたはリリース）ごとに株式で分配します。他のチームは、製品のバックログまたはギャップリストに債務を追加し、債務と残りの作業に優先順位を付けます。いずれにせよ、重要な特徴は、技術的債務が公然と管理されていることです。



債務の種類とその対処方法



すべての技術債務が同じであるとは限らず、分類も異なります。私はこれらのカテゴリーが役に立つと思います：

• 意図的な債務（短期）。時間に敏感なリリースを時間どおりにリリースするなど、戦術的または戦略的な考慮事項から生じる債務。
• 意図的な債務（長期）。クロスプラットフォームをサポートするのではなく、最初に単一のプラットフォームをサポートするなど、戦略的な考慮事項から生じる負債。
• 意図しない借金（不誠実）。質の悪い開発方法が原因で偶然に発生する債務。この種の借金は、現在と将来の両方で仕事を遅くするので、避けるべきです。
• 意図しない債務（誠実）。ソフトウェア開発の自然なミスにより偶然に発生した債務（「私たちの設計アプローチは計画どおりに機能しなかった」または「新しいバージョンのプラットフォームは重大な設計上の欠陥を示した」）。
• 相続債務。新しいチームが古いコードベースから継承した債務。

表9.1は、これらのタイプの債務に対応するために推奨されるアプローチを示しています。





技術的債務について話し合うことの利点



私の経験では、「技術的債務」という比喩は、技術専門家とビジネス専門家の間の話し合いを促進するのに役立ちました。ビジネスの専門家は一般的に技術的な負債を返済するためのコストが何であるかを知りません、そして技術者は一般的にビジネスの利益を知りません。技術的な負債を故意に積み上げることを許可するのが良い考えである場合もあれば、そうでない場合もあります。債務は、技術的およびビジネス上の考慮事項に関する意見交換を促進し、それをより意味のあるものにします。これにより、債務を引き受ける時期と理由、および債務をいつどのように返済するかについての決定の質が向上します。

バーンアウトを回避するために作業構造を構築します

アジャイルの純粋な見方は、同じスプリント期間（「共有ケイデンス」として知られている）を想定しています。チームが全体的なリズムを十分に許容している場合、変更を加えても意味がありません。ケイデンスを共有すると、スプリントを計画するときに速度やその他の要素を簡単に計算できます。



スクラムを実装する際の一般的な不満は、スプリントの無限のシーケンスが疲労とホイールでの走行感につながることです。一貫した開発により、特に分野間でのパフォーマンスの自然な失敗、および高強度の期間中のバランス調整があります。



各スプリントが実際にスプリントのペースで実行されている場合、一定のスプリントは休む時間がありません。



スプリント後の疲労に対する対抗策の1つは、必要に応じてスプリントの期間を変更することです。これを行う体系的な方法は、6x2x1パターン、2週間の6つのスプリントと1週間続く1つのスプリント、合計13週間、つまりちょうど4分の1​​を使用することです。



別の方法は、メジャーリリース後、休日、およびチームの速度がまだ安定しないその他の時間に、短縮されたスプリントを使用することです。 1週間のスプリント中に、チームはインフラストラクチャやツールに取り組んでいる、準備イベントやチームイベントに参加している、ハッカソンに参加している、技術的な負債に取り組んでいる、スプリントで完了するには大きすぎる改善に取り組んでいるなどの場合があります。



スプリントケイデンスの長さの変化は、アジャイルで使用されている持続ペースの概念と一致しています。多くのアジャイル研究は、安定したペースと無料の夜と週末の欠如を同一視しています。しかし、これは、さまざまな人々の労働条件に対する好みの違いを無視する、厄介な過度の単純化だと思います。安定したペースとして週40時間の労働を提案する人もいますが、退屈への道である人もいます。個人的に、私は爆発モードで最善の仕事のほとんどを行いました-2週間で55時間、次の2週間で30時間。平均して、1週間に約40時間の作業が可能ですが、チームごとに40時間の作業があるとは限りません。安定したペースの理解は人によって異なります。

その他の考慮事項

設計外のソフトウェア開発



この章の冒頭に多くの定義がある場合でも、すべてのソフトウェア開発がプロジェクトに編成されているわけではありません。技術サポートの電話処理、リリースの問題の解決、パッチの作成など、通常は1人で作業する場合があります。



もちろん、そのような作業はソフトウェア開発に関連しており、アジャイルプラクティスにも役立ちます。リーンマニュファクチャリングやカンバンなどの実用的なアジャイルメソッドを導入することで、より効率的、定性的、系統的に実行できます。しかし、私の経験では、企業はプロジェクト全体のソフトウェア開発よりもこの種の作業で問題がはるかに少ない傾向があるため、この本は臨時の作業ではなくプロジェクトでの作業に焦点を当てています。

推奨事項の

調査：

• プロジェクト合計の履歴を確認します。あなたの会社の経験は、小さなプロジェクトは大きなプロジェクトよりも成功する可能性が高いという一般的な認識と一致していますか？
• プロジェクトのポートフォリオを閲覧します。あなたの大きなプロジェクトのうち、いくつかの小さなプロジェクトに分割できるのはどれですか？
• , . ? ?
• , .
• , .
• . ?
• .
• , , .
• .

• [ , 1975]. -. , , .
• [ , 2019]. Understanding Software Projects Lecture Series. Construx OnDemand. (2019 ). ondemand.construx.com. .
• [ , 2012]. Essential Scrum: A Practical Guide to the Most Popular Agile Process. , .
• [ ., 2019]. Managing Technical Debt. .

»本の詳細については、出版社 のWebサイトを参照してください

» 目次

» 住民向けの抜粋



クーポンの25％割引- 機敏性



本の紙版の支払い時に、電子書籍が電子メールに送信されます。