公式アカウント[InterconnectionCommunity]に注意し、[Agile Software Project Management and Development]に返信して、すべてのコンテンツを入手してください
前書き
「スクラムの実際の戦闘-アジャイルソフトウェアプロジェクトの管理と開発」は、アジャイルソフトウェアフレームワークスクラムを正常に実装する方法に関するソフトウェアプロジェクトチーム向けの実用的なガイドを提供します。この本の物語は明確で正確であり、実践的な状況のために実践者によって書かれた実践的なガイドです。この本は、プロジェクトチームの価値を最大化する方法、多くのスクラムとプロジェクト管理の本の欠けている部分を補う方法を説明します。これには、金銭的条件を使用して上級管理者と通信する方法、客観的な評価手法を使用する方法、ソフトウェアアーキテクチャをスクラムに適合させる方法が含まれます。付録では、この本に記載されている手法と提案を使用して、2つのソフトウェア製品を正常に構築および展開する方法を説明するケーススタディを提供します。メインコンテンツ
◆経営陣との良好な連携に必要な基本的な財務知識。
◆ミドルマネージャーのサポートを受ける方法。
◆スクラムプロジェクトの要件を視覚的に収集する方法。
◆アーキテクチャビジョンを使用して、チームの速度の変動を緩和する方法。
◆エンタープライズレベルのスクラム展開のストーリーポイントを客観的に評価する方法。
◆自動化、回帰、および統合テストの重要性。
◆スクラム環境のチームリーダー。
コンテンツの抜粋
スクラム実用的な読書ノート
最近プロジェクトマネージャーについて学んでいるからです。スクラムの第7章を完了しました。実際、最初の4つの章はそれほど大きくは感じず、単なる学習本と見なされています。
第5章から始めて、この本はとてもよく書かれていると思います。上記の問題は何度も発生しているので、ここで理由を見つけました。
スクラムの3つの役割：スクラムマスター、製品所有者、チームメンバー現在私たちが直面しているジレンマは、スクラムマスターと製品所有者がすべて同時にプロジェクトマネージャーに引き継がれ、プロジェクトマネージャーもリーダーシップのプレッシャーに直面することです。メンバーの保護はなく、誰もが疲れ果てています。
DoD：定義は完了しました。これは、現在直面している問題の1つです。一つの要求がやってくるが、三言の要求は誰もがそれを見たかどうかわからない。弊社では3文の需要が一般的です。開発によって提出されたコードは、まったく統合できないか、さまざまな問題と統合できません。多くの場合、テストは時間がないときにのみ煙テストを実行し、機能テストは時間内にのみ実行できます。DoDの定義は、処理がはるかに簡単です。要件を明確にし、開発用のユニットテストを作成する必要があります。テストは、ホワイトボックステストとブラックボックス設定の両方で実行する必要があり、パフォーマンステストは各リリースの前にチェックする必要があります。
ブレーンストーミング：ユーザーストーリーのソースは、プロジェクトマネージャーの発言でも、システムアナリストの仕事でも、特定の開発者のブレーンストーミングでもありません。ユーザーストーリーは、各チームメンバー間で合意に達する必要があります。
目次
-
第1章アジャイルとスクラムの基本知識1
-
1.1アジャイルソフトウェア開発とプロジェクト管理の基礎は何ですか2
-
1.2スクラム3の起源
-
1.3ソフトウェアプロジェクト管理でアジャイルとスクラムが効果的である理由7
-
1.4まとめ9
-
第2章ファイナンスについて11
-
2.1プロジェクトコストの計算11
-
2.2プロジェクト投資の選択12
-
2.2.1回収期間12
-
2.2.2購入してビルド12
-
2.2.3正味現在価値（NPV）13
-
2.2.4投資収益率（ROI）14
-
2.3プロジェクトのパフォーマンスの監視15
-
2.3.1コストパフォーマンス15
-
2.3.2パフォーマンスのスケジュール16
-
2.3.3プロジェクト予算予測17
-
2.4まとめ18
-
第3章さまざまなレベルのマネージャーと通信する方法19
-
3.1上級管理職とのコミュニケーション20
-
3.2上級IT管理者との協力22
-
3.3ITミドルマネージャーとの連携23
-
3.3.1品質保証24
-
3.3.2運用および保守管理24
-
3.3.3エンタープライズアーキテクチャ24
-
3.4直属のマネージャーを味方に変える28
-
3.5まとめ28
-
第4章製品バックログの直感的な要件収集方法29
-
4.1 Agile and Scrum29の新しい直感的な要件収集プロセス
-
4.1.1ステップ1：利害関係者とその目標を特定する29
-
4.1.2SMART原則30
-
4.1.3ステップ2：製品バックログの要件を収集する31
-
4.1.4CUTFIT原則33
-
4.2例33
-
4.3まとめ37
-
第5章ストーリーポイント評価を比較可能にする39
-
5.1比較できないストーリーポイントの問題39
-
5.2ポーカー40の文化的問題の計画
-
5.3客観的基準に基づく評価プロセス40
-
5.4まとめ46
-
第6章アーキテクチャビジョンがチームの生産性とソフトウェア品質に与える影響47
-
6.1建築ビジョンの重要性48
-
6.2建築ビジョンを特定する方法52
-
6.3アーキテクチャビジョンのもう1つの利点54
-
6.4まとめ58
-
第7章アーキテクチャビジョンからリリースおよびスプリント計画、並列ソフトウェア開発まで61
-
7.1建築ビジョンからリリースおよびスプリント計画まで61
-
7.2インクリメンタル開発からパラレルソフトウェア開発へ66
-
7.3まとめ68
-
第8章プロダクトオーナーについて69
-
8.1利害関係者の期待と優先順位の管理70
-
8.2明確な製品ビジョンと知識を持っている70
-
8.3製品バックログの要件を収集する方法を知る71
-
8.4常にチームと一緒にいる71
-
8.5優れた主催者になる方法を知る72
-
8.6より良いコミュニケーションの方法を知る72
-
8.7サービスリーダーになる方法を知る72
-
8.8まとめ72
-
第9章自動テストと継続的統合テストの重要性73
-
9.1「完了」の定義の重要性74
-
9.2最も重要なテスト76
-
9.2.1自動テスト76
-
9.2.2継続的な統合テスト76
-
9.3テストインフラストラクチャの編成77
-
9.4まとめ78
-
第10章チームワークの重要性79
-
10.1個人79
-
10.2グループ80
-
10.3チーム81
-
10.4カーシーの気質型理論81
-
10.5チームの5つのステージ82
-
10.6チームの競合を解決する方法83
-
10.7良いチームワークの条件83
-
10.8まとめ84
-
第11章スクラムプロジェクトにおける管理とリーダーシップの新機能87
-
11.1高性能トレーニング：GROWモデル90
-
11.2思いやりのあるリーダーとマネージャーの特徴91
-
11.3まとめ92
-
第12章スクラムを環境に適応させる方法93
-
12.1ネガティブなスクラムのふりをせずにスクラムを環境に適応させる方法しかし94
-
12.2環境へのスクラム適応のいくつかの例94
-
12.2.1組織の側面94
-
12.2.2インフラストラクチャの寸法96
-
12.2.3チームディメンション97
-
12.2.4技術的寸法97
-
12.2.5プロセスディメンション97
-
12.2.6ビジネスディメンション98
-
12.3まとめ99
-
第13章スクラムプロジェクトの準備状況の自己評価101
-
13.1スクラムの準備状況を評価するためのシンプルなツール101
-
13.2例106
-
13.3グループ化109
-
13.4まとめ110
-
第14章スクラムマスターが必要な場合111
-
14.1スクラム112の理論的および実践的な深い知識
-
14.2優れたサービス指向のリーダーシップスキル112
-
14.3強力な組織力112
-
14.4優れたコミュニケーションスキル112
-
14.5優れたプレゼンテーションスキル113
-
14.6紛争解決能力113
-
14.7優れた人間開発能力113
-
14.8まとめ113
-
第15章別れのメッセージ115
-
付録A2つの実際のソフトウェア製品開発事例117
-
スプリントの早期終了に関する付録B175
公式アカウント[InterconnectionCommunity]に注意し、[Agile Software Project Management and Development]に返信して、すべてのコンテンツを入手してください