タグ付けされた質問 「extreme-programming」

Webでいくつかの記事を読んで、アジャイル、XP、スクラム、ペアプログラミングが互いにどのように異なり、互いに関連しているかを調べ、次の行を導き出しました。 スクラムとXPはほぼ同じです。XPのリリース期間はスクラムよりも短い ペアプログラミングは、アジャイルとXPの両方の方法論で採用されています しかし、アジャイルがXPとどのように異なるかを特定できませんでした。 URLを提供するだけでなく、これに関するあなたの経験と考えを読んで喜んでいるでしょう。

32 project-management  agile  scrum  pair-programming  extreme-programming 

私はアジャイル手法を実践しようとする多くのチームに所属しており、多くの場合、これらのチームはテスト中心です。テストはアジャイル手法を実践するのに必要な部分ですか、それとも長年にわたって定着しているXPの実践ですか？

24 agile  testing  extreme-programming 

私は最近、まだ自分自身をセットアップしている若いハッカースペースに参加しました。幸いなことに、このスペースには作業が必要な内部プロジェクトがいくつかあり、作業を行うボランティアが不足していません。 これらのプロジェクトを整理する方法についていくつかの議論がありました。私の最近の専門的な経験はスクラムであったため、ソフトウェアプロジェクトにスクラムアプローチを提案することを検討していますが、それが適切かどうかはわかりません。 スクラムはフルタイムの小規模なチームでうまく機能しますが、この組織の性質は異なります。 メンバーはボランティアです。一部はフルタイムの学生です。他の仕事はフルタイムで仕事をしています。実際の生活が優先されるため、誰からも一定レベルの貢献は期待できません。 ほとんどすべての人がソフトウェアを作成する長年の経験を持っていますが、専門家やチームでこれほど多くのメンバーはそうしていません。 プロダクトオーナーはいません。これらのプロジェクトの要件は、委員会によって決定されます。この委員会のメンバーも実装に取り​​組んでいます。つまり、専任の専任のプロダクトオーナーはいません。 期限はありません（ソフトまたはハード）。プロジェクトは完了すると完了します。 これらはかなり重要な違いですが、私は彼らがスクラムを適用するためのブロッカーになるとは確信していません。ちょっとした微調整でこのハードルを克服できると思います。 スプリントを固定してストーリーポイントサイズを固定するが、継続時間（時間）が流動的である場合、ボランティア開発者に非現実的な配信のプレッシャーをかけることなく、繰り返しのリリースから利益を得ることができます。 バーンダウンチャートと速度計算を捨てることができます。私が正しく理解していれば、これらは開発チームと経営陣の間の橋渡しとして機能するツールと指標です。開発者と利害関係者の両方にとって意味のある形式で進捗状況を報告するのに役立ちます。報告する人がいない（プロジェクトマネージャー、プロダクトオーナー、外部関係者がいない）ことを考えると、これを完全に削除できると思います。 微調整を必要としないメリットがあると思います。 要件収集会議（複数可）。全員がテーブルの周りに座って、ユーザーストーリーについて議論し、UIモックをスケッチし、製品バックログを作成します。 スプリントの回顧展。これは、ボランティアチームとして機能する開発プロセスに集中するための興味深い方法です。 よくわからないこと： 毎日のスタンドアップはどのように扱われるべきですか？私たちの環境では、彼らは非常に価値があるのでしょうか。スタンドアップ式の儀式についての私の理解は、チーム全体に自然に情報を広めることでコミュニケーションを支援することです。私たちのスプリントはおそらく平均的なスプリントよりもはるかに少ない複雑さを提供する可能性があるという事実を考慮すると、他のすべてのチームメンバーの進捗状況/開発に遅れをとる必要が少なくなる可能性があります。 継続的インテグレーション、コードレビュー、TDDなどのXPを推進すべきですか？私はこれが多くを求めているのではないかと心配しています。人々がスクラムに精通し、チームとして働くようになれば、将来のプロジェクトでこれらの概念を取り入れたいと思うでしょう。 私の質問： スクラムはボランティアベースの環境に適応できますか？ そして、私の計画したアプローチはこれまで正しい方向に向かっていますか？

18 scrum  extreme-programming 

スクラムに関する最近の白熱した議論の後、私の問題は、管理が完全にアジャイルなチームで非常に不必要で冗長な活動であると考えることであることに気付きました。成熟したアジャイルチームは、管理や非技術的な意思決定プロセスを一切必要としません。私の（明らかに間違い）目には、成熟した開発チームを管理するのに適した能力があるのはコーチ（適切なコミュニケーションスキルを持つ最も技術的に有能な同僚）だけであることは明らかです。スクラムマスターがこのようなチームにどのように貢献できるか想像できません。 私は、スクラムとそのようなベテラン開発者ではないが、チームにコーチがいる場合の生産サイクルの計画に長けているマネージャーの価値を理解し理解するのに非常に苦労しています。それは一体何の意味ですか？開発の最先端スキルを持たない人が高度な技術チームを管理するにはどうすればよいのでしょうか？おそらくここでの管理は何か他のものを意味するのでしょうか？ 管理は時間の無駄であり、未熟さの副産物だと考えています。私の理解では、成熟したチームは完全に自己管理しています。どうやら私は多くの偉大な人々が反対を言うので間違っていますが、私は自分を納得させることができません。

18 agile  scrum  management  extreme-programming 

Peopleware（DeMarco、Lister）を読み終えたばかりで、少し前にExtreme Programming（XP）について調査しました。私が今見ているように、2つのアプローチは互いにほぼ排他的です。 Peoplewareは、プログラマーを妨害から分離することを提案し、プログラマーがフローを達成できるように、中断のない作業に優先順位を設定します。一方、XPは可能な限り多くのコミュニケーションを確保することを提案し、プログラマーが「一緒に座って」ペアでコーディングし、同じ部屋で作業することを提案します（多くのノイズを生成します）。 これら2つの競合する考え方は、おそらく正しい/間違っていると証明されているのでしょうか、それとも効果的な妥協があるのでしょうか？私は双方が指摘する点を見ることができますが、合理的な妥協を見ることができません。 ソフトウェア開発管理を勉強するのは初めてなので、何かを誤解している可能性があります。すべてのコメントを歓迎します。 PS追加のミニ質問として、プログラマーとして、どちらの生産性を高めますか？

16 productivity  management  extreme-programming 

私はTDDにかなり慣れていないので、実装コードの前に来る最初のテストを作成するときに問題があります。実装コードにフレームワークがなければ、私は最初のテストを自由に書くことができますが、Java / OOの問題に対する考え方によって常に汚染されているようです。 たとえば、私のGithub ConwaysGameOfLifeExampleで最初に書いたテスト（rule1_zeroNeighbours）では、まだ実装されていないGameOfLifeオブジェクトを作成することから始めました。存在しないsetメソッド、存在しないstepメソッド、存在しないgetメソッドを呼び出し、アサートを使用しました。 テストはさらにテストを書いてリファクタリングするにつれて進化しましたが、元々は次のようなものでした： @Test public void rule1_zeroNeighbours() { GameOfLife gameOfLife = new GameOfLife(); gameOfLife.set(1, 1, true); gameOfLife.step(); assertEquals(false, gameOfLife.get(1, 1)); } この最初のテストを書くためにこの初期段階でどのように決定したかに基づいて実装の設計を強制していたので、これは奇妙に感じました。 あなたがTDDを理解する方法でこれは大丈夫ですか？私はテストと実装がリファクタリングによって時間とともに進化したという点でTDD / XPの原則に従っているようです。この方法で開始することにより、ソリューション。 TDDは他にどのように使用されますか？GameOfLifeオブジェクトなしで、プリミティブと静的メソッドのみで開始することにより、リファクタリングの反復をさらに行うことができましたが、それはあまりにも不自然に思えます。

15 java  testing  tdd  extreme-programming 

XP（エクストリームプログラミング）、特に同じ画面に2人のプログラマーがいる部分が好きですやっています。 過去10年ほどで、XPスタイルの作業は時代遅れになり、作業方法論であるアジャイルおよび/またはかんばんが採用されたようです。どうして？XPは私にとって非常に優れた作業方法であるように思われ、プログラミングについて多くのことをしているのに対し、アジャイルとかんばんはプロセスに関するものです。

15 agile  extreme-programming  kanban 

極端なプログラミングプロジェクトでは、プログラマはほとんどの場合ペアプログラミングを行います。 これらのペアも回転するため、つまり、プログラムをさまざまな人とペアにし、集団所有権の感覚があるため、ソースコードは頻繁にレビューおよび更新されています。 そうであれば、コードレビューが必要ですか？つまり、プログラミングを停止し、実際にコードレビューを行うだけです。

14 agile  code-reviews  pair-programming  extreme-programming 

私はExtreme Programming Explained、Second Editionを読み、第11章「制約の理論」で著者は古くて時代遅れの「プッシュ」開発モデルとXPの方法、「プル」開発モデルについて話しています。それは非常に重要な概念のように見えますが、非常に小さなパラグラフと、「滝」と反復プロセスの単なるイラストである2つの画像のみを必要とします。私は検索しましたが、本の残りの部分ではそれについてこれ以上説明しません。それについてのさらなる説明や議論もインターネットで見つけることができませんでした。 それらについての唯一の違いが、一方が「ウォーターフォール」であり、もう一方が反復的である場合、それらはなぜプッシュし、なぜプルするのでしょうか？ 誰が本当にこれら2つの違いが何であるかを理解し、いくつかの良い例を挙げていますか？

14 agile  development-process  extreme-programming 

アジャイル手法を使用してアプリケーション全体を書き直さなければならないとしたら、どうしますか？ 現在のシステムの動作に基づいて、多くのユーザーストーリーを作成できると思います。そして、それらを小さな反復で実装します。しかし、これは私たちが前方に要件を持っているという意味ではないでしょうか？ また、いつリリースを開始しますか？アジャイルは、早期かつ頻繁にリリースすべきだと言っていますが、完全な書き換えが完了する前にリリースすることはあまり意味がありません。

13 agile  scrum  software  extreme-programming  rewrite 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 私は過去2週間、小規模で営利目的のマルチプレイヤーアーケードゲームのために、いくつかの基本的な極端なプログラミングコンセプトを扱ってきました。1週間かけてユーザーストーリーを作成し、リリース計画を作成するための要件を決定しました。また、思いついた最初の反復計画のコーディングと適用に1週間費やしました。私は、1人の開発者にとって明らかに便利な概念のいくつかを特定しました。 継続的インテグレーション 早期に機能を追加しない テスト駆動開発 システムのメタファーを選択 単一の統合ポイントを使用する すべてのバグをテストする 常にリファクタリング 持続可能なペースを設定する シンプルさ 頻繁なリリース 特に、単一の開発者プロジェクトでの作業に適したものがないとしたら、私は興味がありますか？ また、シンプルさとテスト駆動開発の考えを踏まえると、この観点から、確立された機能豊富な既製のプラットフォームを使用する方が良いでしょうか？ それとも、可能であれば、絶えずリファクタリングし、機能を早期に追加しないなどのルールで提示される問題に遭遇しないように、ゼロから作業する必要がありますか？

10 design  project-management  extreme-programming  solo-development 

私は、XPを実行するという真の意図を持つ非常に優れた会社で働いています。コミュニケーションは良好で、経営陣は建設的な議論を受け入れることができますが、差し迫った時間の制約があるため、RUPで議論することができないものもあると見なされています。 現時点では、ストーリーの実装中に必要となる変更の量に少し悩んでいます。これらの発見の多く（もちろん時間と労力がかかります）は、ストーリー作成者（顧客、エンドユーザー、製品所有者）の責任であり、開発者の責任ではないかと思います。簡単に言うと、ユーザーストーリーは概念的すぎて、根本的な意図を伝えているだけですが、十分な詳細（特に、前提条件と事後条件、他のストーリーとの関連性、依存関係など）が不足しています。開発者は、XPの開発者がデザイナーとアナリストを兼ねているため、独自の裁量で空白を埋めることが期待されています。問題は、これらの空白の多くが、最初の予想よりも複雑さが増していることに気付いてから、いくつかの誤った仮定が評価時間とコードに組み込まれた後に発見されることです。それでも適切な項目を見つけるには時間がかかります。これは、さまざまな程度で、初期の見積もりからの逸脱と見なされます。 私は、これらの影響を経営陣に伝える建設的な方法を探しています。不必要に物事を複雑にしようとしている人として私を装うような方法ではありません。私は新しいですが、まだ信頼性を確立していません。 あなたの洞察は大歓迎です。 密接に関連し、どういうわけか答えを与える：開発者はユーザーストーリーの詳細をどのくらい期待できますか？

10 user-story  extreme-programming  estimation 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 スクラムとXPについて何を読むことをお勧めしますか。私はトレンチからスクラムとxpを持っていますが、価値のあるいくつかのリファレンスを見てみたいです。

9 scrum  extreme-programming 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 私は、エクストリームプログラミングのトピックと、その実践がアプリケーションのエラーやバグのためのスペースを作ることにつながるかどうかについて、学術的な研究を行っています。 多くの人から集めた経験から、双方に当てはまるコメントがあります。多くの人がそれをサポートし、変化するプロジェクト要件を容易にすることができるダイナミクスでそれを毎日の必要性と見なしています。他の多くの人はそれが次のような多くの問題につながると主張します： プロセスでの顧客との過度の関わりは、ニーズではなく顧客の希望の表現につながります 多くの製品には複数の顧客がいて、ニーズと意見の対立を引き起こし、不要な封鎖を引き起こしています。 多くの製品には外部の顧客がなく、製品は内部で使用するため、または将来的に販売するために作られています。これらのケースでは、チーム自体が開発者だけでなくユーザーも演じているため、プロセスの有効性が失われています。 正式なドキュメントには多くのものが存在しません。この非公式性は曖昧なビジョンにつながり、これが私たちが求めたものではないなどと顧客が言う可能性がある問題を引き起こす可能性があります。 問題は、XPに関してこのような相反する意見が存在する理由です。異なるシナリオの問題ですか？他に何かありますか？（タイトルに書かれている）主張はどの程度真実ですか？ ここでXPを使用している、または使用した経験のある人に、学習と実際の経験を提供してほしい。回答を裏付ける事実や参照がある場合は理想的です。

8 agile  software  extreme-programming  engineering 

まあ、タイトルは本当にすべてを語っていますが、少し詳しく説明すると、ランダムで通常は効果的なQA部門を担当し、XP環境での作業を学ぶことができます（もちろん、XPワークフローを習得するための学習曲線があります）。彼らは効果的になるためにより多くのプログラミングスキルを必要とするでしょうか？もしそうなら、彼らは何を知る必要がありますか？

8 agile  training  qa  extreme-programming