タグ付けされた質問 「agile」

ここでストーリーポイントをアジャイル開発に使用し始めていますが、説明するのが難しく、またそれらが何であるかについての明確な答えも見つけることができません。私ができる最善のことは、他のサイト（http://blog.mountaingoatsoftware.com/tag/story-pointsなど）をポイントし、それらが何であるかについて漠然とした一般化を与えることです。私は、他の人が使用するのに役立ついくつかの使用例を含む良い説明を探しています。ストーリーポイントを説明するのに役立つリソースはありますか？

36 agile  estimation  planning 

そのため、スクラムスプリントは、特定の機能セットを実装する必要がある固定期間です。そして、スクラムチームは、これらの機能を提供することに全力を注いでいる人々で構成されており、その大部分は通常、開発者とテスターです。 これらのルールを確立した後、スプリント全体でこれらすべての人々を忙しく保つ方法を疑問に思うかもしれません。スプリントの開始時にはまだテストするものはありません。また、スプリントの終了時には、通常、開発/修正するものがまったくないか、ほとんど残っていません。 これを処理する2つのアプローチを見てきましたが、どちらも問題を適切に解決していないようです。 1）チームメンバーに、タスクがなくなったときの対処方法を決定させます。 短所： 彼らがすることを徹底的に計画していない場合（すなわち、主要なリファクタリング、新しいテストフレームワークへの切り替え）、彼らの仕事は役に立たないか、途中で立ち往生するかもしれません 一方、そのような作業の計画には多くの時間がかかる可能性があり、クライアントは即座に価値をもたらさないものにチームが時間を浪費するのを見ることに失望するかもしれません 通常、このようなタスクは完全に見積もることができないため、未熟な労働者がスクラムボードや他の場所に反映されることなく、YouTubeの猫を見ることに時間を費やすことは非常に簡単です。 2）スプリント内に開発専用のスペースを確保し、スプリントの終了後にテストを開始します（開発者が次のスプリントから機能の作業を開始するとき） 短所： 現在のスプリント用の機能を開発している間、開発者は前のスプリントからバグを修正することに気を取られ、現在のスプリント中に行われると推定された量の作業を実行できない可能性があります 2つのスクラムボードが必要です。1つは現在のスプリント機能用で、もう1つは以前のスプリントバグ用です。 だから私の質問は、スプリント中に開発者とテスターの間で作業を適切に分散して、誰も作業で過負荷になったり、いつでもタスクなしで終わることがないようにする方法ですか？上記のアプローチを改善する方法はありますか？または、より良いアプローチがありますか？

33 agile  scrum  sprint 

私は金融ソフトウェア会社を立ち上げており、その過程でアジャイルの原則と方法を研究していますが、まだ対処していない開発の1つの側面は、開発者が開発に新しいスキルと技術を習得する絶え間ないニーズを満たす場所ですプロセス。 過去数年間金融ソフトウェアに取り組む前は、3DグラフィックプログラマーとしてのキャリアのほとんどをビデオゲームやGISおよび生体認証ソフトウェアに取り組んでおり、崖から飛び込んで物事を理解する方法を常に簡単に考えていました。飛ぶ。私は常に成功していましたが、一度に100時間の週と月を費やして自分自身を殺さなかったならば、私はそうするまで生き続けるつもりはありません。 3Dグラフィックスの革新的な要求がまったくないソフトウェア会社を立ち上げたので、開発に対するより包括的なアプローチを確立したいと思います。 おそらくアジャイルはこれに対処していないかもしれませんが、もしそうなら、私はどこでこれを見つけたかわからず、誰もがこれについて持っている知識や専門知識や経験に感謝します。

32 agile 

「典型的な」SCRUMチームがあり、スプリントで働き、バックログを維持することを約束します。最近、帯域外作業（通常の労働時間/スプリント以外で作業することを選択）を行っている、過剰に達成している開発者の作業を統合/処理しようとする問題に遭遇しました。 例として、チームが50ポイントの仕事を引き受ける場合、スプリントの終了までにSCRUMフレームワーク内ですべての仕事を完了し、彼らと会社は満足しているとしましょう。チームメンバーの1人が、自分で、バックログアイテムで、自分の自由時間に取り組むことにしました。彼らはこの作業をチェックインせず、代わりに保存します（TFSを使用し、シェルフセットにあります）。 これを処理する方法は？問題のいくつか.. 次のスプリント中に、このチームメンバーは、プログラミング作業が99％完了し、コードのレビューとテストのみが必要であると言います。SCRUMおよびアジャイル方法論でこれをどのように扱いますか？ 他の開発者は、作業が帯域外で行われたため、これらのストーリーに関連する設計決定に関与していないことに不満を述べています。 私たちの製品所有者はこの「無料」の仕事を引き寄せようとしますが、チームがスプリントで達成できないような機能を製品に追加するために、過剰達成メンバーが意図的にこれを行っている可能性があります。これが「プロセス」を壊しているという見方があります。明らかに、QA、UI、およびドキュメントの作業をこの作業で行う必要があります。 SCRUMチームに時間外労働を強制しないことについて多くの議論がありますが、スプリントの計画と実行中に出された期待以上の仕事をしているチームメンバーはどうでしょうか。私はこの人物を統治することをheし、あなたが余分に働くことはできないと言います（もちろん燃え尽きないように注意してください）が、同時にそれはチームの特定のメンバー（しかしすべてではない）でいくつかの問題を引き起こしているようです。 達成度の高いメンバーが行った作業を、ソフトウェア開発のSCRUMおよびアジャイルプロセスに統合する方法

32 agile  scrum  team 

私の友人は、すべての開発者が嫌うプロジェクトで小さな会社で働いています：彼はできるだけ早くリリースするように圧力をかけられています、彼は技術的な負債を気にしているようです、顧客は技術的な背景などを持っていません 彼は私に、このようなプロジェクトでのデザインパターンの適切性について考えさせた物語を教えてくれました。ここに物語があります。 Webサイトのさまざまな場所に製品を表示する必要がありました。たとえば、コンテンツマネージャーは製品を表示できますが、APIを介してエンドユーザーまたはパートナーも表示できます。 製品から情報が欠落している場合がありました。たとえば、製品が作成されたばかりのとき、それらの束には価格がありませんでしたが、価格はまだ指定されていませんでした。説明のないものもあります（説明は、変更履歴、ローカライズされたコンテンツなどを含む複雑なオブジェクトです）。出荷情報が不足しているものもありました。 デザインパターンに関する最近の読み物に触発され、私はこれが魔法のNull Objectパターンを使用する絶好の機会だと思いました。だから私はそれをやったが、すべてがスムーズできれいだった。product.Price.ToString("c")価格を表示するため、またはproduct.Description.Current説明を表示するために電話する必要がありました。条件付きのものは必要ありません。ある日、利害関係者はnull、JSON を使用して、APIで別の方法で表示するように要求しました。また、「Price unspecified [Change]」と表示することにより、コンテンツマネージャーにとっても異なります。そして、私は最愛のヌルオブジェクトパターンを殺さなければなりませんでした。それはもはや必要ではなかったからです。 同様に、いくつかの抽象的な工場といくつかのビルダーを削除しなければなりませんでした.3か月間、基礎となるインターフェイスが1日に2回変更されたため、美しいFacadeパターンを直接のugい呼び出しに置き換えました。関係するオブジェクトはコンテキストに応じて異なる必要があることを要件が告げたとき。 3週間以上の作業は、デザインパターンを追加してから1か月後にそれらを引き裂くことで構成され、私のコードは最終的に自分を含む誰もが維持できないほどのスパゲッティになりました。そもそもこれらのパターンを使用しない方が良いと思いませんか？ 確かに、要件が絶えず変化し、製品の凝集性や一貫性を実際に意識していない人によって指示されるようなタイプのプロジェクトで自分自身で作業する必要がありました。この文脈では、あなたがどれだけ機敏であるかは問題ではなく、問題に対する洗練された解決策があり、最終的にそれを実装すると、要件が大幅に変更され、エレガントな解決策が適合しないことがわかりますもはや。 この場合の解決策は何ですか？ デザインパターンを使用せず、思考を停止し、コードを直接記述しますか？ チームがコードを直接記述している間に、別のチームが入力前に2回考えて、数日後に元のデザインを破棄するリスクを冒すような体験をするのは興味深いでしょう。同じ技術的負債。そのようなデータがない場合、20人月のプロジェクトに取り組むとき、事前に考えずにコードを入力するのは適切ではないと断言するだけです。 もう意味をなさないデザインパターンを維持し、新しく作成された状況にさらにパターンを追加しようとしますか？ これも正しくないようです。パターンは、コードの理解を簡単にするために使用されます。パターンを入れすぎると、コードが混乱してしまいます。 新しい要件を含む新しいデザインを考え始めてから、古いデザインをゆっくりと新しいデザインにリファクタリングしますか？ 理論家として、またアジャイルを好む人として、私は完全にそれに夢中です。実際には、毎週ホワイトボードに戻って以前のデザインの大部分をやり直さなければならないこと、そしてその費用を支払うだけの十分な資金も顧客も待つ時間がないことを知っているとき、これはおそらく動作しません。 だから、提案はありますか？

32 design-patterns  agile  changes 

社内で使用しているプロジェクトの一部はスクラムですが、それでもお客様に「すべてを修正」しています。私たちは複雑な成功を経験しています（顧客はバーンダウンチャートの可視性を好む）。作業するプロジェクトの種類は、アジャイルメソッドを使用して正常に実行できますか？

32 agile  scrum 

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

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

私の会社は、ウォーターフォールスタイルの開発からアジャイル/スクラムへの移行の最中です。とりわけ、私たちは私たちが持っている期待があることを告げている新しい作業を、テスト可能（QAによっては）毎日の終わりにしています。 開発者のほとんどは、会議やその他の企業のオーバーヘッドにより、1日約2時間を失います。つまり、6時間（せいぜい）の期間で、QAが機能するための完全な機能を生成するのに十分なコードを設計、作成、単体テスト、ビルド、デプロイ（リリースノート付き）する必要があります。ビルド/デプロイ/リリースノートは適切なCIセットアップで自動化できることを理解していますが、まだそこにいません。 また、サーバー側のコードを作成する大規模なオフショア部隊があり、12時間の時差によりこれがさらに困難になります。 機能をできるだけ早くエンドツーエンドで完了するために、ストーリーを狭くて深い垂直スライスに仕上げようとしますが、ほとんどの日はかなり必死に感じます。私はしばしば、QAが確実にビルドされるように、愚かで壊れやすいショートカットを取っている人々を捕まえます。この問題は、スプリントが数日間進行した後、不可避な欠陥が入り込み始め、同じ6時間のウィンドウに収まらなければならないときに悪化します。 これはアジャイルチームにとって通常のペースですか？CIセットアップを実装できたとしても、このペースを維持し、高品質のソフトウェアを作成する方法がわかりません。 編集： ここにいくつかの良い答えがあります。アジャイルチームが毎日新しい機能を提供すべきかどうか、私が本当に求めていたことを実感しました。それに応じてタイトルを更新しました。

31 agile  scrum 

私は非常に小さな会社で「Windowsエキスパート」と呼ばれています。この会社は、私、セールスおよびトレーニングの役割を担う機械エンジニア、および設計、開発、サポートの役割を担う社長から構成されています。 私の役割も同様に一般的ですが、主に、現在のWindowsのバージョンで製品を実行するために必要な、製品のプログラミングを設計および実装します。 ウェブキャストで提供されたスクラムパラダイムの高レベルの概要を見終えました。私の質問は、「製品の国際化とローカライズ」など、開発作業項目が通常非常に高いレベルで与えられることを考えると、製品開発へのこのアプローチについてもっと学ぶ価値があるかどうかです。 もしそうなら、スクラムを一人のプログラマーの使用に適応させることをどのように提案しますか？そのためには、クラウドベースのツールやその他のツールが有用でしょうか？ そうでない場合、一人のプログラマーが日々努力を整理するためにどのようなアプローチを提案しますか？（おそらく、質問はその単純な質問に還元されます。）

31 agile  programming-practices  scrum  solo-development 

テスト駆動開発（TDD）では、最適ではないソリューションから開始し、テストケースを追加してリファクタリングすることにより、より良いソリューションを繰り返し生成します。ステップは小さいと想定されています。つまり、新しいソリューションはそれぞれ前のソリューションの近くにあることになります。 これは、勾配降下法やローカル検索などの数学的なローカル最適化方法に似ています。このような方法のよく知られた制限は、グローバルな最適値、または許容可能なローカルな最適値を見つけることを保証しないことです。開始点が悪い解の大きな領域によってすべての許容可能な解から分離されている場合、そこに到達することは不可能であり、メソッドは失敗します。 より具体的に言うと、いくつかのテストケースを実装した後、次のテストケースではまったく異なるアプローチが必要になるというシナリオを考えています。前の作業を破棄して、最初からやり直す必要があります。 この考え方は、TDDだけでなく、小さなステップで進行するすべてのアジャイルメソッドに実際に適用できます。この提案されたTDDとローカル最適化の類推には重大な欠陥がありますか？

30 agile  development-process  tdd  development-methodologies 

ペアプログラミングは、2人のプログラマが1つのワークステーションで連携するアジャイルソフトウェア開発手法であることを知っています。一方のドライバーはコードを記述し、もう一方のオブザーバーは入力されたコードの各行をレビューします。 しかし、私はこの戦略がこのケースでまだ機能しているのだろうかと思う。例えば プログラミングスキルレベルがまったく異なる場合。 ある人が問題の領域で経験したことがなく、別の人が経験した場合。 プログラミングのスキルレベルが低い場合でも大丈夫ですか？ 上記の場合のペアプログラミング戦略を提案できますか？

30 agile  pair-programming 

私のチームと私は、約10年前に開発したサイトを再構築しています。アジャイルでそれをしたいと考えています。 そのため、読書に多くの時間を費やした後（おそらく十分ではない）、開発者間で作業を分割する方法についての質問に苦労しています。 もっと具体的に言うと、サイトは互いにあまり統合されていない別々のモジュールに分割されていると言います。 開発者間で作業を分割するための最良/最も受け入れられている方法は何ですか？ 作業するために各人に異なるモジュールを与える。 すべての開発者を同じモジュールに割り当て、モジュールの異なる部分（UnitTesting、DALおよびマッピング、ロジック、UI）で作業を分割します すべての開発者を同じモジュールに割り当て、異なるロジック（たとえば、各開発者が特定のロジック（おそらくBLのメソッド）を担当する）と、そのUnitTesting、DAL、およびマッピングとUIによって作業を分割します... それとも完全に異なるものですか？

30 web-development  agile 

Gunther Verheyenのスクラム-ポケットガイドを読んでいます。 Standish Groupによる2011年のChaosレポートは転換点を示しています。従来のプロジェクトとアジャイル手法を使用したプロジェクトを比較するために、広範な研究が行われました。このレポートは、ソフトウェアを期限内に、予算内で、すべての約束された範囲で提供しなければならないという古い期待に反して、ソフトウェア開発へのアジャイルアプローチがはるかに高い歩留まりをもたらすことを示しています。このレポートは、アジャイルプロジェクトが3倍成功し、従来のプロジェクトと比較して失敗したアジャイルプロジェクトが3倍少ないことを示しています。 ですから、一部のプロジェクト（要件が変わらない医療/軍事など）では、アジャイル（および特にスクラム）がすべての会議などでオーバーヘッドであり、より論理的であると言う同僚との議論がありますたとえば、ウォーターフォールを使用します。 私の見方では、このようなプロジェクトにスクラムを採用する必要があります。これにより、プロセスがより透明になり、チームの生産性が向上するからです。また、1か月間のスプリントのために8時間をスプリントプランニングに費やす必要がないため、スクラムイベントが必要なければ、それほど時間はかからないと思います。全員が同じページにいることを確認して作業を開始するためだけに、5分間を節約できます。 では、スクラムは、要件が変わらないプロジェクトに追加のオーバーヘッドを作成しますか？

29 agile  project-management  scrum  methodology 

多くの企業と同様に、私が働いている会社は、SMARTの目標に基づいたパフォーマンスレビューシステムに移行しています。私のチームは、Extreme Programmingのプラクティスを採用した高機能でアジャイルな開発チームです。私たちの大きな利益のために、私たちのアジャイルプラクティスの採用は、直属の管理職の完全なサポートを持っています。 作業を完了するために、私たちのチームは3週間の反復を利用します。即時の反復を超えて、四半期ごとに一般的な計画を立てています。これから数四半期で達成したことは、当四半期で達成することよりもはるかに厄介であることを意味します。私たちのプロジェクトがどこに向かっているのかは確かに一般的な考えを持っていますが、ここでのキーワードは一般的です。 私自身を含む私のチームのプロジェクト計画メンバーへのアプローチを考えると、具体的、測定可能、達成可能、関連性、および時間制限（SMART）の目標を書くことは難しいと感じています。 SoftwareEngineering.seに関する2つの既存の質問は、私たちの懸念のいくつかに対処するのに適しています。 プログラマーにとって良いSMART目標の例は何ですか？ SMARTの目標はプログラマにとって有用ですか？ ただし、アジャイル開発チームで作業する場合、質問はSMART目標を処理するための詳細よりも一般的な回答を引き出しました。アジャイル開発者として、具体的、測定可能、達成可能、関連性があり、時間制限のある5〜7年間の目標をどのように記述しますか？

29 agile  management  planning  review 

私が所属する開発チームは、最近アジャイルのプラクティスに従って作業するようになりました。これは、コード（およびドキュメント）のゴールドメッキを止めることができないという事実を個人的に強調しており、その結果、要件をはるかに早く満たすソリューションを提供できたときに、当初の見積もりを上回りました。 私は自分の倫理が強迫観念に接していると思います。私はコードに執着しすぎて、リファクタリングしてn度完成させる前にリリースすることはめったにありません。これに気づいたことを嬉しく思いますが、どのように自分の態度/精神を変えて自分の進歩に満足し、代わりに時間通りにリリースできますか？

29 agile  programming-practices  productivity  development-process  scrum