現在表示中:

完了の定義に基づいて作業する

チームごとに「完了」の定義が異なりますが、定義を統一し、状況が定義済みの条件を満たしていることを確認してから受け入れることが重要です。 

次に、チームが一般的に指定しているいくつかの条件を示します。

  • コードのフォーマットがレビュー済みである
  • コメント/Javadoc が追加されている
  • 必須のテスト範囲レベルを満たしている
  • 単体テストおよび統合テストに合格している
  • QA 環境で検証済みである
  • ローカリゼーションが実装されている

DoD が明確に定義されていないと、多くが半ば完了した状態で本当に完成したものはないという状況に陥りやすくなります。

コーディングとフォーマット規則を定義し、準拠する

インデントレベルや空白など、重要とは思われないようなものでも、正しいフォーマットでコーディングすることは、読みやすさと保守性に大きな効果があります。チームで表記規則について話し合って合意し、その規則に準拠してコーディングする必要があります。

広範なテスト範囲を目指す

プロジェクトの実装サイズが大きくなると、テストに必要な時間が長くなります。テスト範囲が適切に設定されていないと、テスト担当チームの規模を調整できず、結局は開発者がバグに埋もれてしまうことになります。

開発者は TDD を実践し、失敗する単体テストを記述してから、要件を満たす実稼動コードを記述します。QA は、上位レベルから見てシステムが想定どおりに機能することを確認するために、一連の自動受け入れテストを作成します。

Jackalope や Prosper などのカスタムフレームワークを使用すると、JCR API のモック作成がシンプルになり、単体テストを記述する際の開発者の生産性が高まります。

デモを使用可能にしておく

各反復の終了時には、システムのデモを使用できるようにする必要があります。システムのデモを使用可能な状態にしておくことによって、チームは常に実稼動準備完了の反復内にいることになり、技術的な負債を維持可能なレベルに保つことができます。

継続的な統合環境を導入して使用する

継続的な統合環境を導入すると、単体テストおよび統合テストを簡単かつ反復して実行できます。また、デプロイメントが開発チームから分離されるので、チーム内の他の部門が効率的に作業できるようになり、デプロイメントの安定性と予測可能性が向上します。

ビルド時間を短く抑えて開発サイクルの高速性を維持する

単体テストの実行に長時間かかる場合、開発者は単体テストの実行を避けるようになり、単体テストの価値が失われます。コードのビルドおよびデプロイに長時間かかる場合は、ビルドおよびデプロイの頻度が減ります。短いビルド時間の方を優先すると、テスト範囲および CI インフラストラクチャにこれまで費やしてきた時間はそのままチームの生産性向上につながります。

Sonar とその他の静的コード分析ツールを微調整し、ツールが出力したレポートに基づいて対処する

コード分析ツールは、そのレポートが開発チームメンバー側の対処につながって初めて有用であると言えます。ツールが提供する分析を微調整しないと、ツールが生成する推奨事項は関連性のないものになり、ツールの価値が失われます。

ボーイスカウトのルールを守る

ボーイスカウトには、「帰るときには、その場所を来たときよりもきれいにする」というルールがあります。開発チームのメンバー全員がこのルールを守り、散らかっていたらそのままにしないで片付けるようにすると、コードは継続的に改善されます。

YAGNI 機能を導入しない

YAGNI(You Aren't Gonna Need It の略)機能は、今は必要なくても将来は必要になると思われる場合に導入するものです。理想は、今すぐ機能する最も単純なものを導入し、継続的にリファクタリングを行って、システムのアーキテクチャが要件に応じて長期間で進化していくようにすることです。このようにすると、重要なことに集中することができ、コードの膨張や機能クリープを防ぐことができます。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー