-3

開発者およびプロのエンジニアとして、Kent Beck によって「バージョン 1」で定義されているように、Extreme Programming のテナントに触れてきました。これらの 12 の基本原則のうち、現在の仕事や他の仕事で実践することを許可されているか、少なくともその一部になることが許可されていると感じているのはどれですか?

* Pair programming[5]
* Planning game
* Test driven development
* Whole team (being empowered to deliver)
* Continuous integration
* Refactoring or design improvement
* Small releases
* Coding standards
* Collective code ownership
* Simple design
* System metaphor
* Sustainable pace

エンジニアの観点からは、XP の主なエンジニアリング原則は、私が関わってきた他のどの原則よりもはるかに優れていると感じています。あなたの意見は?

4

5 に答える 5

2

私たちはあなたが言及したこれらの慣行に従っています:

  • 企画ゲーム
  • テスト駆動開発
  • チーム全体（提供する権限を与えられている）
  • 継続的インテグレーション
  • リファクタリングまたは設計の改善
  • スモールリリース
  • コーディング基準
  • コードの共同所有権
  • シンプルなデザイン

そして、1 年後には、これまでと違う働き方を想像することはできないと言わざるを得ません。

ペアプログラミングに関しては、非常に困難な領域がある場合や、初期の優れた設計が不可欠な場合 (インターフェースの設計など) には意味があると言わざるを得ません。しかし、私はこれが非常に効果的であるとは考えていません。私の意見では、ペア プログラミングが理にかなっている場合は、より小さなパーツのコードとデザイン レビューを実行する方がよいでしょう。

「チーム全体」の練習に関しては、チームが成長するにつれて、それが苦しんでいることを認めなければなりません。誰もが個人的な意見を述べることができるのに、計画セッションが長すぎました。現在、コア チームは、初期の大まかな計画を立てて計画ゲームを準備しています。

于 2008-09-16T20:25:03.900 に答える
1

私は自分自身を幸運だと思っています。「ペアプログラミング」以外はすべて実行できますが、日常的にではなく大きな問題を解決するためだけです。「集団的なコードの所有権」も達成するのが難しく、ペアプログラミングを行わないと、反復から反復への論理的な次のユーザーストーリーを維持する傾向があります。

于 2008-09-16T20:22:38.663 に答える
0
  • チーム全体（提供する権限が与えられている）
  • 小さなリリース
  • コーディング基準
  • 集合的なコードの所有権

しかし、その後、私は非常に保守的なミッションクリティカルな開発チームで働いています。XPが開発の良い方法であるとは限りません。自分に合った方法を見つけて、教義を無視する必要があります。

于 2008-09-16T21:06:43.377 に答える
0

私たちは小さなリリースを除いてすべてを行いましたが、それは素晴らしいものでした. 他の方法で働くことは想像できません。私の経験から、私が最も重視する信条は次のとおりです。

  • 継続的インテグレーション (堅実なテスト スイートを使用)。
  • コードの共同所有権。
  • TDD
  • チームのエンパワーメントと意思決定。
  • コーディング標準。
  • リファクタリング。
  • 持続可能なペース。

残りの部分もあると非常に便利ですが、TDD、共同所有権、およびリファクタリングがある限り、ペアリングなしで生活できることがわかりました。

于 2008-09-18T13:57:37.260 に答える
0
  • ペアプログラミング[5]

この点を経営陣に納得させるのは難しい。しかし、エンジニアが行き詰まったり、技術や取り組みに慣れていないエンジニアがいる場合、これは実行可能であることがわかりました。

  • 企画ゲーム

はい。

  • テスト駆動開発

管理者に簡単に販売できます。ただし、一部の管理の難しい部分は、より多くの時間を追加することです。多くのマネージャーは、エクストリーム プログラミングやアジャイル プログラミングによって時間を節約できると信じています。彼らはあなたに何かを届ける時間を節約しません。実際、一定の要件の収集をテストすることは、労力を追加します。それがすることは、顧客が望むものをより速く手に入れることです。

  • チーム全体（提供する権限を与えられている）

間違いなく、これは Xtreme の驚くべき側面です。

  • 継続的インテグレーション

各反復 (スプリント) の終わりに、完全な統合が行われます。日次完全積分は発生しません。

  • リファクタリングまたは設計の改善

最初の努力が最高のものになることはめったにありません。そうです、私は Xtreme が常により優れたソリューションを提供していることに気づきました。

  • スモールリリース

1 週間または 2 週間のイテレーションの推奨期間を延長できるインフラストラクチャとリソースを考えると、それはわかりました。これの多くは、展開先に依存します。システムが運用環境に展開されている場合、正式なシステムとストレス テストにより、多くのオーバーヘッドが追加される可能性があります。したがって、この環境では、1 か月または 2 か月続く反復を行います。システムが開発領域に展開されており、本番環境には展開されていない場合、1 日続くイテレーションのようなタイトなものでも実行できます。

  • コーディング基準

新しいチーム メンバーのためのペア プログラミングは、これを促進することができます。ここでもコードレビューが役に立ちます。これの多くは、お互いにどれだけ長く働いているかによって異なります。

  • コードの共同所有権

ここで Xtreme が本当に役立つとは思いませんでした。誰もが自然にコード ベースの特定の領域に分類されます。そのため、人々は自分が多くの時間を費やしているものの所有権を取得します。優れたソフトウェア エンジニアは、この方法で作成したものに誇りを持っているため、これは実際には良い推進力となる可能性があります。

  • シンプルなデザイン

実際、短い反復サイクルは単純な設計を促進します。短いリリースでは保守可能である必要があります。

  • システムの比喩

ここで何を意味するかわからない？

  • 持続可能なペース

チームの速度は、適切な指標を使用してのみ正確に見積もることができるタスクです。メトリックは、タスクの見積もりとタスクの完了期間に保持する必要があります。

于 2016-04-04T22:56:24.227 に答える