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

アジャイル開発プロセスでは通常、主な焦点はユーザーストーリーにありますが、1つの要件が複数のユーザーストーリーにまたがることもあります。 たとえば、クライアントはフォーラム内のすべてのユーザーの検索ページを要求する場合があり、ユーザーの禁止、ユーザーの削除、パスワードのリセットなど、ユーザーごとに実行できるアクションがいくつかあります。 この機能は、少なくとも4つのユーザーストーリーに分割できます。 ユーザーを検索 ユーザーを禁止 ユーザーを削除 パスワードを再設定する ユーザーインターフェイスデザイナーは、このようなユーザーインターフェイスをどのように実装しますか？彼/彼女は最初のユーザーストーリーに取り組み、それからUIへのより多くの機能を増やし始めるべきですか？ただし、最終的なUIは台無しになると思います！ 彼が機能全体（検索+アクション）で作業することに決めた場合、アクションの優先順位が低く、検索機能が実行された後に複数の反復が実装されるとしたらどうでしょうか。

11 web-development  agile  user-interface  user-story  user-experience 

チームの燃焼度チャートと反復ごとの速度をプロットしました。私にはそれは本当に悪いように見えます（速度は大きく変動します）。この振る舞いの根本原因を診断するために何を探すべきですか？

11 agile  scrum 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 継続的インテグレーションの概念、どのように機能するのかを理解しやすい方法で説明してくれる人がいますか？そして、企業がコード配信ワークフローにCIを採用する必要があるのはなぜですか？私は開発者であり、私の会社（主にビルド​​チーム）はTeam Cityを使用しています。開発者として、私は常にコードをチェックアウトし、更新してSVNにコミットしますが、TeamCityやCI全般について気にする必要はありませんでした。それでは、CIの有用性を理解したいと思いますか？CIはアジャイル手法の一部ですか？

11 agile  continuous-integration  jenkins 

最近のほとんどの開発者と同様に、顧客コラボレーションや変更への対応などのアジャイルプリンシパルを高く評価していますが、製品所有者（または要件と優先順位を決定する人）が頻繁に要件と優先順位を変更するとどうなりますか？1日に数回好きですか？ 私は最近、バグがあり、不完全であり、想定される最も単純なシナリオを処理することさえできなかった小さなコードベースを継承しました。技術的な問題に対処することはできますが、1日に数件のメール、テキスト、または電話があります。さらに悪いことに、ほとんどのことは、ソフトウェアが実際に行うこととは関係なく、実装するのに何日もかかるような些細なことです。時間は非常に長く、最も重要なことに最初に集中する必要があることを説明しようとしましたが、翻訳が1日か2日後に起こるため、翻訳で何かが失われるようです。 無駄な努力の量を減らすのに役立つ、または少なくともこの混oticとした行動のコストを説明するのに役立つ製品所有者ハンドラーの役割、詳細な研究、比phor、または引用がありますか？

11 agile  product-owner 

反復はすでに開始されており、新しいプログラマーがチームに参加しています。タスクXは別の開発者によって既に30時間と見積もられています。 この状況でのベストプラクティスは何ですか？ 新しい開発者は指定された推定値で実行します（速度の計算時に矛盾が修正されるという考えですか？） 新しい開発者はタスクを再評価しますか？（もしそうなら、それが著しく高く、反復にもはや適合しない場合はどうなりますか？） 手を上げて滝に戻る？ 完全に何か他のもの？

11 agile  estimation 

Dogsa T、Batic Dでの以前の作業の要約を読んでいたとき、テスト駆動開発の有効性：産業のケーススタディ。ソフトウェア品質ジャーナル。2011; 19（4）：643-661。TDDに関する多くの研究で使用されている測定値は、コードの行、欠陥、開発に費やされた時間などに基づいていることが印象的でした。 TDDを使用して開発された製品と従来の開発またはテストラストを使用して開発された製品の総所有コストに焦点を当てた研究はありますか？ 私は、買収と運用の総費用に特に興味があります。

11 agile  management  tdd  computer-science 

すべてのチームメンバーに共通の言語が1つもないチームがあります。チームは2つの場所に分かれています（ただし、地理的な問題は主要な問題ではありません）。各場所のすべてのチームメンバーは同じ言語を話し、両方の場所で両方を話すことができるメンバーがいます。スクラムを紹介したいのですが、言語の問題に対処するためのロジスティックスに苦労しています。 これはオフショアチームではありません。すべてのチームメンバーは会社の従業員ですが、異なる国の2つの異なるオフィスにいます。幸いなことに、タイムゾーンに関する問題はありません。言語が第一の障壁です。各場所の人々の規模とスキルセット、およびその他の外部要因を考慮して、チームを2つのチームに分割することもできますが、単一のチームとして統合することがより望ましいです。 コミュニケーションを豊かにし、チームが団結してお互いを見て真のスタンドアップアプローチを行えるようにするには、ビデオ会議を使用することが望ましいと思います。しかし、これは言語間でのコミュニケーションが困難になると思います。チームのバイリンガルメンバーは口頭で翻訳する必要がありますか？代わりに、分散スクラムの言語の問題に関する唯一のリファレンスで推奨されているインスタントメッセージを使用することもできます。私は「貧しい」コミュニケーションを心配しており、おそらくそれはスクラムの概念への不十分な紹介です。 チーム内で言語の違いに対処した経験のある人から、問題にどのように対処し、どの程度うまく機能しましたか？

11 agile  scrum  team  spoken-languages  distributed-development 

私は、行動駆動開発方法論（別名BDD）の声明的な支持者です。私は数年前からBDDを適用してきましたが、DotNetアプリケーションを開発する際の選択のフレームワークとしてStoryQを採用しました。私は長年ユニットテストを行っており、以前はテストファーストのアプローチに移行していましたが、BDDフレームワークを使用することでより多くの価値が得られることがわかりました。コード内の英語をクリアします。テストはテストを途中で終了することなく複数のアサーションを実行できるため、デバッグすることなく、どの特定のアサーションが合格/失敗するか一目で確認できます。 これは本当に私にとって氷山の一角でした。テストコードと実装コードの両方をより的を絞った方法でデバッグできることにも気づきました。その結果、生産性が大幅に向上し、ビルドログに出力されるために問題が統合ビルドに至るまでに発生した場合、障害が発生した場所を簡単に判断できます。さらに、StoryQ apiには、習得が容易で、非常に多くの方法で適用できる美しい流な構文があり、使用するために外部の依存関係を必要としません。 したがって、これらすべての利点があれば、チームの他のメンバーにこのコンセプトを簡単に導入できると思います。残念ながら、他のチームメンバーはStoryQを見てそれを適切に評価することを嫌がり（BDDを適用するというアイデアを楽しまないでください）、お互いの説得力のあるテストフレームワークから多くのStoryQ要素を削除しようと互いに確信していますただし、元々StoryQの使用をサポートしており、削除したいコードがテストシステムの他の部分に影響を与えることはありませんでした。そうすると、特定の作業環境でテストファーストで作業するより良い方法であり、より大きな結果につながるだけであると実際の経験から確信しているので、全体的にワークロードが大幅に増加し、実際に穀物に反することになります私のソフトウェアの品質の改善 veは、BDDを使用して最初にテストに固執する方が簡単だと感じました。さらに明確にするために、私たちが行った単体テストの大部分は非常に脆弱で維持が難しい傾向があります。テスト駆動型プロセスに固執することを嫌がって開発者が古い習慣に戻り、プロジェクトの最後にすべてのテストを行います（同じ人がアジャイルだと主張しています！）。 したがって、質問は次のようになります。 このチームがStoryQを使用すること、少なくともBDD方法論を採用することの方が良いと主張するために、どのような議論を使用できますか？ BDDを標準的な選択方法として採用するという私の主張を裏付けるために使用できる事例証拠を教えてください。 チームがBDDを採用することを奨励したいという私の希望が間違っている可能性があることを示唆する反論はありますか？はい、議論が健全なものであれば、間違っていることが証明されてうれしいです。 注：テスト全体を書き直すことを推奨するのではなく、将来のすべてのテスト作業のために、できればお客様と交わる方法で異なる方法で作業を開始することを推奨します。 また、BDDの詳細については、次のリンクが役立ちます。 http://dannorth.net/introducing-bdd/ http://en.wikipedia.org/wiki/Behaviour_driven_development http://behaviour-driven.org/Introduction 詳細に興味がある人のために、私たちは4人の小さなチームで約5つの大きなプロジェクトに取り組んでいます。BDDの「パイロットトライアル」は、最初は約2か月間、その後約4か月間実行されました。チームは、私がこの方法で作業を続ける必要があることを受け入れ、独自のトライアルを行うことになりました。トライアルが終了してから約2年間BDDを行っていますが、他の人は問題をうまく解決することができました。この問題について「対立」を強要するのではなく、私はチームを優しく説得して、集団の背後から抜け出し、少し時間をとる方法を探しています。

11 productivity  agile  unit-testing  bdd 

アジャイルの教義の一つは... 契約交渉を介した顧客コラボレーション ...もう1つは... プロセスとツールを介した個人と相互作用 しかし、少なくとも顧客とのやり取りに関しては、根本的な問題があります。 顧客の考え方は、ソフトウェアエンジニアの考え方とは異なります はい、それは少し一般化するかもしれません。間違いなく、そこにあるこれは必ずしも真実ではないところの事業領域は---これらは少数とはるかにかかわらず、間にあります。ただし、多くのドメインでは、典型的な顧客は次のとおりです。 日常の運用上の懸念に関心がある-短距離戦術...必ずしも戦略ではない; 当然のことながら、当面の解決策のみに関係します。 抽象的思想家ではなく、実践的思想家。 ソリューションが将来の懸念をどのようにサポートするかを検討するよりも、「仕事をやり遂げる」ことにずっと興味があります。 一方、理想的には、アジャイルを実践するソフトウェアエンジニアは次のとおりです。 品質についてよく考える人。 少し前もって作業することで、後の労力を大幅に節約できることに感謝する個人。 経験豊富な分析的思想家。 そのため、「顧客コラボレーション」を阻害する傾向がある文化の不一致があるようです。 これに対処する最良の方法は何ですか？

11 agile 

スクラムは、ジェネラリストメンバーがいるチーム、つまり、少なくとも2人が同じタスクを実行できるチームに最適です。私の主な関心事は、専門家で構成されたチームのためにスクラムを適応させるための優れたソリューション（何を保持し、何を削除し、改善するか）を見つけることです。 5人の開発者からなるチームがあると仮定します（実例ではなく、単なる例です）。 Cの強力なスキルを持つ1人の数学者。 1人のDB開発者。 1人のWeb開発者。 UX / GUI開発者1人。 1人のソフトウェアアーキテクト。 ここでは、すべてがスペシャリストであり、誰も他の誰かを置き換えることはできません（このようなチームを構築するリスクは気にしません。スクラムに集中したいと思います）。だから、スクラムの文脈で、ここに私の考えがあります： 役に立たない春の計画：実際、数学者が特定のタスクに2ポイントの価値があると言ったとき、誰も彼に反対することはできません。 役に立たないチーム速度メトリック：誰もが自分のタスクに任意の数のポイントを割り当てることができるため、速度の計算は意味がありません。 毎日のスクラム会議を毎週（より長い）スクラム会議に置き換えます。チームの各メンバーが自分のタスクに取り組んでいるため、毎日のスクラム会議は「チームスピリット」を維持するために非常に重要です。ただし、毎日のスクラム会議は約15分間続くことになっています。これは明らかに、他の人が何をしていて何をするのかを理解するには不十分です。さらに、数学者はほとんどの場合、同じことを答えます。「私はまだ％＆Lo（+？$$ +＆）をやっています」...毎週のミーティングでより多くの時間が与えられます。「最初の」スクラム会議と「毎週の」スクラム会議の間で同じ会議時間を維持するには、各週のスクラム会議を継続する必要があります（週5日、4週間のスプリント、スプリント会議は4時間、毎日の会議は15分）。 （4 * 60 + 20 * 15）/ 4 => または、スクラムはまだ使用可能ですか？たぶん別のアジャイル技術を使用する必要がありますか？

11 agile  scrum 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 7年前に閉鎖されました。 プロジェクトのログや日記を保存するのがどれほど難しい/役に立つか知りたいです。私がやったことを追跡するのに時間がかかりすぎるのではないかと心配しています...

11 project-management  agile 

最近、私はプログラム開発中に、彼らがアジャイル開発プロセスを使用する場合はこれが正常であると言って、新しい機能と正当化された事に取り組んでいる間、定期的にテーブルとカラムを定期的に作成および削除することを述べた開発者と議論しました。 私のバックグラウンドのほとんどはウォーターフォール開発環境にあるので、これがアジャイル開発で実際に適切であると考えられているのか、またはこれが根本的な問題の兆候であるのか、プログラムアーキテクチャまたはアジャイルプロセスのフォローに関するものなのか疑問に思います。

11 architecture  agile  database 

私は比較的新しい開発チームの一員です。Scrumスプリントの終わりに、いくつかの大きなストーリーがPOによってin progress行わacceptedれたか、行われなかったとします。 まず、これらのユーザーストーリーはどうなりますか？次のスプリントに引き継ぐだけですか？ もしそうなら、それらは再評価されるべきですか？私の考えでは、これらのユーザーストーリーに残っている作業は最小限で済むのでしょうか？そうでない場合は、なぜですか？ 編集：私の特定のケースでは、ユーザーストーリーの過小評価のためではなく、数日にわたる障害のためにストーリーは完了しませんでした。それが役立つかもしれないあなたのために、私たちは使用していますVersionOne

11 agile  scrum 

私は、スクラムモデルに大まかに沿ってプロジェクトに取り組んでいます。2週間のスプリントを行っています。私が明確にしていない（そして相談する本がない）ことは、スプリント間で起こるはずのことです。製品が構築されて配信される「ラップ」プロセスがあるはずです。 これには通常どれくらい時間がかかりますか？ チーム全体が関与する必要がありますか？ 開発者が次のスプリントアイテムの作業を開始する前に、厳密に終了する必要がありますか？ コードのレビューとテストが行​​われるのはこれですか？ 3人の開発者がいて、合計で約1人のFTEがいます。したがって、スプリントは実際に非常に短いです。

11 agile  scrum  sprint 

Martin Fowlerの有名なブログ記事Is Design Deadを読んでいたとき 、私が得た印象的な印象の1つは、アジャイル方法論とエクストリームプログラミングでは、デザインとプログラミングが進化的であるという事実を考えれば、物事をリファクタリングする必要がある点が常にあるということです。 プログラマーのレベルが高く、設計の意味を理解し、重大な間違いを犯さない場合、コードは進化し続ける可能性があります。しかし、通常の状況では、この状況での地上の現実は何ですか？ ある重要な開発が製品に組み込まれている通常の日には、要件に重大な変更が生じた場合、それがどれだけ望むかという制約ではないので、基本的な設計の側面を変更することはできませんか？（コードの大部分を捨てずに）。設計と要件のさらなる可能な改善で行き止まりに達する可能性は非常に低いですか？ ここではアジャイル以外のプラクティスを提唱していませんが、実際の経験に関しては、アジャイル、反復、または進化の開発方法を実践している人々から知りたいです。 あなたはそのような行き止まりに達したことがありますか？どうやってそれを避けたり、逃れたりできましたか？または、デザインが進化してもクリーンで柔軟なままであることを保証する手段はありますか？

11 design  agile