アジャイルのベストプラクティスのリスト
使用するアジャイルプラクティスを定義しようとしていますが、アジャイルベストプラクティスのリストを定義するのが困難です。技術的な観点（エンジニアの視点）からより多くのリストを作成し、ソフトウェアエンジニアが開発に取り組む方法を定義する必要があります。リストは、できる限り経営陣に関連している必要があります。
それが重要であれば、私たちはc ++でプログラミングしています。
多くのベストプラクティスを見つけるのはかなり簡単です。これは、これまでに作成したリストです。
- リファクタリング
- 小さなリリースサイクル
- コーディング基準
- 共同所有
- システムのメタファー
- プレーニングゲーム
- チーム全員
- スクラムの毎日の会議
- ペアプログラミング
- テスト駆動設計
- 行動主導型開発
- 継続的インテグレーション
- コードと設計のレビュー
- アクティブな利害関係者
- 遅れて文書化
- デザインパターンの広範な使用
リストのプラクティスの一部をすでに使用しています。使用しないものもあります。
リストに追加できる優れたアジャイルプラクティスはありますか？
PS要請があれば、プラクティスの簡単な説明を追加できます。
[〜＃〜]編集[〜＃〜]
私が言ったように、私たちはすでにいくつかのアジャイルプラクティス（主に最良であることが証明されているプラクティス）を使用しています：
- 継続的インテグレーション-これは非常に良い習慣です。最新のチェックインに関する迅速なフィードバックを得ることは非常に便利です。誰かがビルドを壊したためにダウンタイムが発生すると、特にそれが長持ちする場合、非常にイライラすることがあります。
- システムのメタファー-わかりやすいクラス名と関数名を使用すると、コードをよりよく理解できるため、ほとんど役に立ちません
- コード標準-コーディングに入る前にコーディング標準を作成しました。誰もが他の人のコードを取り、自分のように作業できるので、統一されたコードスタイルを使用するのは良いことです。
- TDD-コーディングを開始する前に、単体テストを簡単に作成できる環境をセットアップしましたが、最近まで、TDD原則の採用を開始しました。私は数年前に個人的に試してみましたが、うまくいきませんでしたが、今では大好きです。残念ながら、すべてのチームメンバーがそうしているわけではありません-チームの半分だけです。
- スクラムの毎日の会議-私たちは毎日の会議を試みましたが、うまくいきませんでした。以前の仕事と同様に、毎日の会議は通常30分以上の議論に変わります。良いスクラムマスター（またはリーダー、それはどのように呼ばれますか？）を逃したと思います。
- リファクタリング-リファクタリングを行いましたが、チームの誰かが変更リクエストを作成した場合のみです。私たちは故意にそれをしませんでした：「今座り、技術的負債を減らしましょう」。
- 小さなリリースサイクル-現在、巨大なリリースサイクル（6か月）があり、次のリリースでは、サイクルを4〜6の内部リリースに分割する予定です。
- コードとデザインのレビュー-最初のデザインレビュー（5年前など）を行いましたが、この期間中にいくつかのマイナーサブコンポーネントのデザインレビューはほとんど行いませんでした。一部のクラスのコードレビューを行いました
- ドキュメントが遅れました-このリリースで作成しました。必要なドキュメントのみとは、ドキュメントを書くことを少なくし、楽しいコーディングを意味します。開発者はそれを愛しています:)
- デザインパターンの使用-必要に応じて、既にデザインパターンを使用しています。
私たちの組織の構造上、他のプラクティスを使用することはできませんが、ご覧のとおり、リストは長く、すべてを選択することはできません。また、現在、私たちはたった4人のSW開発者であり、それぞれが約80 kLOCを維持し、新しいものに取り組んでいます。したがって、たとえばペアプログラミングや集団所有はできません。
このテキスト は、すべてのアジャイルのベストプラクティスを要約しています（リンク付き）：
要件
-製品ビジョン/ビジョンステートメント
-製品バックログ
-ユーザーストーリー
-使用例
-使用シナリオ
-ペルソナ
-ポーカーの計画
要件の優先順位付け
デザイン
-建築スパイク/スパイクソリューション
-ドメイン駆動設計
-創発的デザイン/進化的デザイン
-CRCカード
-契約による設計
-システムメタファー
建設
-コーディングスタイル/コーディングガイドライン/コーディング標準
-テスト駆動開発
-行動主導型開発
-ペアプログラミング/ペアリング
-リファクタリング
-集団的コード所有権
-毎日のビルド/自動ビルド/ 10分のビルド
- 継続的インテグレーション
-コードレビュー/ピアレビュー
-ソフトウェアメトリック/コードメトリックおよび分析
-ソース管理/バージョン管理
-問題追跡/バグ追跡
-構成管理
-頻繁な配信/頻繁なリリース
Testing-ユニットテスト
-煙のテスト/ビルド検証テスト
-統合テスト
-システムテスト
-探索的テスト
-テストの自動化
-ストーリーテスティング/受け入れ基準/受け入れテスト
プロセス
-タイムボクシング/固定スプリント/固定反復長
-リリース計画
-反復計画/計画ゲーム/スプリント計画
-スプリントバックログ
-タスクボード
-完了の定義/完了
-毎日のスタンドアップミーティング/毎日のスクラム
-速度
-スプリントレビュー/反復デモ
-バリューストリームマッピング
-根本原因の分析/ 5つの理由
-バーンダウンチャート/バーンアップチャート
-大きな可視チャート/情報ラジエーター
-回顧/リフレクションワークショップ
組織
-小規模チーム
- クロス機能チーム
-自己組織化チーム/スクラムチーム
-コロケーションチーム/一緒に座る/共通ワークスペース
-オンサイト顧客/製品所有者
-スクラムマスター
-持続可能なペース
-人々を移動させる
-スクラムオブスクラム
まず、 アジャイルソフトウェアの12の原則 を読みます。
第二に、自分にとって最も重要な原則を達成する方法を知っていることから理解します。
人々は常に、アジャイル開発がSilver Bullet、またはソフトウェア開発を成功させるために遵守する必要がある厳格な一連のプロセスであると期待することを間違えています。
それは本来あるべきことではありません。 15の「ベストプラクティス」のリストが既にあるという事実は、少し怖いです。あまり真剣に考えすぎないでください。何かを見逃していることがわかった場合は、次の反復で取得してください。
私は今「アジャイルで成功する」を読んでいる最中です。第2章では、Mike Cohnが、あらゆる種類の「ベストプラクティス」を確立することに対する悲惨な警告を提示しています。
「スクラムに移行するとき...ベストプラクティスを収集するのは危険です。岩からサイレンが私たちに歌うように、ベストプラクティスはリラックスして、スクラムに不可欠な継続的な改善の努力をやめさせます...チームメンバーは常に新しく発見された優れた働き方をお互いに共有するには、一連のベストプラクティスにコード化したいという衝動に抵抗する必要があります...」
彼はさらにトヨタの大野泰一氏を引用します：
「...標準的な作業と呼ばれるものがありますが、標準は常に変更する必要があります。その代わりに、標準を「できる最善のこと」だと考えると、それは終わりです... [私たちが何かを確立する場合]可能な方法では、カイゼンのモチベーション[継続的な漸進的改善]はなくなります。」
あなたが追加することができる本当に重要なもののカップルは次のとおりです。
自己管理チーム-「最高のアーキテクチャ、要件、および設計は自己組織チームから生まれます」を参照
回顧-「定期的に、チームはより効果的になる方法を振り返り、それに応じてその動作を調整および調整する」
作業を最小限に抑えるシンプルなデザインソリューション
ベストプラクティスのリストを作成することは、アジャイル移行のためのBDUFのようです。アジャイルになりたい場合は、アジャイルな方法でそこに到達してみてください。
現在のプロセスで最悪の問題は何ですか？その問題に対処するために何を変更できますか？試してみて、どのように機能するかを確認してください。
すすぎ、繰り返します。
そして、これらすべてをチームとして行います。
編集：
いくつかのコメントを賢くコメントに入れるのは難しいので、ここでいくつかのコメントを詳しく説明します。
問題はユニットテストを書くことを拒否する人がいることだと思いますが、私の意見では、ユニットテストはより大きな安全なネットを提供しています。それについて何ができるかわかりません。
テストカバレッジの低下は、実際には否定的な解決策であり、実際の問題ではありません。
テストのカバレッジが悪い場合は、バグのあるソフトウェアを配信している可能性があります。または、バグを導入せずに変更を加えることが困難で時間のかかる場所です。これらは問題です。
人々がテストを書くことを拒否している場合、彼らは問題があると信じていないか、ユニットテストを書くことがそれを解決すると信じていないか、彼らは気にしない。
これについて行う最善のことは、チームと集まり、問題が何であるかを決定し、改善しようとすることに同意することです。
改善に興味のないチームメンバーがいる場合、それはさらに大きな問題です。チーム全体で引き続き対処する必要がありますが、困難であり、管理の助けが必要になる場合があります。
すでに述べたように、私たちはすでにいくつかのアジャイルプラクティスを使用して成功していますが、おそらく新しい、より優れた方法があります。私がやろうとしていることは、私たちがどのようにやっているかを再評価することです。
良い。これは基本的に私が提案すべきことですが、チームとして実行し、ベストプラクティスの大きなリストを作成するのではなく、特定された問題の解決に集中してください。
追加する他のいくつかのアイデアですが、一部はあなたが持っている他のプラクティスから暗黙的であるかもしれません：
それぞれが独自の方法でカスタマイズされる可能性があることを忘れないでください。これが重要な側面であるのは、状況に役に立たない場合でも、練習に従うことについてあまり信心深くなるのは必ずしも良いことではないからです。
スプリントレビューは、少なくとも私の考えでは、スプリントレトロスペクティブとは異なります。レビューは、スプリントで終了した内容を他のユーザー（通常は利害関係者）に表示して、フィードバックを取得し、製品のバックログを、製品の表示から生じる可能性のある新しいアイテムで更新する場所です。 Retrospectiveは、チームが集まり、うまくいったことや、次のスプリントで改善できる点について話し合う場所です。
あなたのリストはかなり完全だと思います。それは「小さなリリースサイクル」のほんの一部であると主張することはできますが、実際に問題が頻繁に見られるため、「反復ごとに明確で固定されたスコープ」を追加できます。
また、「小さなリリースサイクル」と「リファクタリング」を別々のポイントとして挙げます。これらはかなり独立しています。
とにかく、アジャイルの「欠けている」部分について過度に心配することはありません。アジャイルメソッドの重要な特性の1つは、それらがすべてか何でもないということです。まずは、自分に合った部分から始めて、徐々に増やすことができます。一部のプラクティスは互いに依存しますが（例：リファクタリングとコードの所有権の集合）、ほとんどは独立して使用できます。
「アジャイル」または「アジャイルソフトウェア開発」は単一の方法ではありません。これは、保持することを選択する可能性のある「値」のコレクションのみを対象とする包括的な用語です。 2つの異なる方法はどちらも「アジャイル」でありながら、実行すべきか実行すべきでない練習に関しては互いに競合する可能性があります。
「アジャイル」の明確な定義がないため、「アジャイルプラクティス」の完全なリストを作成することはできません。
基本的なエクストリームプログラミングプラクティスの決定的なリストがあります（つまり、の基本的な定義を満たすために行う必要があること「XPを実行しています」）。
また、スクラムを実行するために実行する必要がある最小限の事項もあります（ただし、特定のエンジニアリング手法についてはまったく何も言わないため、それほど役に立ちません。）
Scrums 所定の期間ごと（毎日、毎週など）およびその結果として発生するスプリント。
曖昧ではありませんが、とにかく説明へのリンクの価値があります。