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

私のケースの少し紹介： より大きな製品の一部として、私のチームはDSL用の小さなIDEを実現するように求められます。この製品のユーザーは、コードで関数呼び出しを行うことができます。また、いくつかの便利な関数ライブラリを提供することも求められます。チームは、POと一緒に、IDEユーザーのさまざまなライブラリに関する特定の数のユーザーストーリーを壁に配置しました。それらの最初のストーリーを推定するとき、チームは関数呼び出しメカニズムが魅力的ではあるが完全に明白ではないタスクであると判断したため、そのユーザーストーリーの推定は単純な3からより危険な5に上がりました。 問題に来る： 次に、チームは他のライブラリに関するユーザーストーリー（実際には10のストーリー）に移動し、これらの2つの「関数呼び出しメカニズム」のことを各ユーザーストーリーに追加しました。これですぐに20ポイントの商品の合計ポイントがアップしました！チーム内の誰もが、各ユーザーストーリーはいつでも次のイテレーションのPOによってピックアップされる可能性があることを知っているので、1つのユーザーストーリーでその部分を分離するべきではありませんが、それらの20ポイントは非常に非現実的に感じられます。 私は解決策を提案しましたが、完全に満足していません： 「デザインストーリー」を作成し、面倒な2点を載せました。しかし、私たちがそれを実現して顧客に示すようになったとき、私たちはその話について彼らにとって本当に価値のあるものを示すことができませんでした！ ここでの問題は、孤立したユーザーストーリー（それらの間の依存関係なし）の原則を無視すべきかどうかです。 このような状況で、あなたは何をしますか？ （小さな脚注：提案に従って、この質問をstackoverflowから移動しました）

8 estimation  planning  agile 

受け入れテスト-駆動計画と受け入れテスト-駆動開発の違いは何ですか？彼らは同じですか？

8 agile  development-process  acceptance-testing 

アジャイルは多くの先行設計を奨励しません。これは、要件管理とソフトウェア開発の観点からは適切であり、プロジェクトを変化するビジネスニーズに適応させることができます。 しかし、開始時に何を構築するのか本当にわからない場合、リソースの長期計画をどのように行うのでしょうか。確かに、何を構築するかについての概念モデルはありますが、プロジェクトを完了するために必要なリソースの数や、それにかかるコストを測定するための測定可能な詳細はありません。 誰かがアジャイル環境で長期計画を行う方法について何か提案はありますか？

8 project-management  agile  planning 

これは、私がたった今聞いた別の質問にいくらか関係していますが、プロジェクト管理をする請負業者、つまりいわばコードを書くのに大きな泥の塊を、一人でリモートでフリーランスしています。 私は彼のプロジェクトを本当に機敏な方法で処理するという提案に取り組むことについて多くのことを考えてきました。私が見ているように、これはいくつかのクライアントフレンドリーでウェブベースのアプリを含みます： コミュニケーションのためのベースキャンプ リポジトリとしてのgithub ユーザーストーリーや進行中の作業の表示のための重要なトラッカー 受け入れテストを収集するためのツール（提案に賛成票を投じます！） 私はアジャイルについてかなりの読書をしましたが、すべての優れたリソースは、チーム内のコミュニケーションの重要性に重点を置いており、共同配置されていないチームにはアジャイルを推奨していません。唯一のプログラマーであるので、これはそれほど問題ではないように見えましたが、クライアントに会うことはめったにないので（たとえあったとしても）、この種の管理を可能にするほどコミュニケーションが十分に効果的ではないのではないかと心配しています。 編集：チームの他の人には次のものが含まれます： -顧客（ビジネスマン） -製品マネージャー（私のクライアントのクライアント） -プロジェクトマネージャー（私のクライアント） -UIデザイナー

8 project-management  agile  web-applications  freelancing 

バックログを作成するとき、エラー処理やフィードバックなどのアプリケーションの側面など、非常に多くのユーザーストーリーに適用されるいくつかの要件があります。これらをどのように含めるのですか（各ユーザーストーリーで#includeディレクティブを使用せずに）？エラープレゼンテーションを機能として扱い、「システムが例外をキャッチし、情報をユーザーに表示する」など、この機能のユーザーストーリーを用意する必要がありますか？

8 project-management  agile  scrum 

構築したばかりの新しいプロジェクトバックログから2つのユーザーストーリーを達成しました（いい言葉ですか？）。これらはユーザー登録とパスワードのリセットで、どちらもメールが必要です。私が最初に選択したもの、および通常は信頼できるものが機能しなかったため、代替メールコンポーネントを実装する必要があります。メールコンポーネントのデバッグではなく、ユーザーストーリーの配信に重点を置いていたため、スプリントの最後に機能するコードを配信するためにそれを交換しました。メーラーの新しいサポート問題をログに記録しますか、それともこれらのストーリーをバックログに「再挿入」しますか？後者を実行する場合、ユーザーストーリーに技術の詳細をあまり紹介していませんか？

8 agile  development-process  scrum  user-story 

私の同僚は、アジャイル開発に関するセミナーにかつて、ユニットテストを技術文書として使用することが可能だと聞いていました。クラスの使用方法の例として単体テストを使用するようなもの。 Googleのクイック検索でTDDとドキュメントが提供されました。これにより、それが可能であることが証明されます。しかし、コードを見ると、明らかにそのような方法で単体テストを実装できていないことがわかります。 私の意見では、ユニットテストは、モックおよび偽のクラスと関数の助けがあっても、最小限のユニットとしてコードをテストするためにあります。 したがって、質問は次のとおりです。 クラス（またはクラスのセット）の使用方法を示すのは、機能テストのタスクではありませんか？ 単体テストを技術文書として使用できる場合、そのような単体テストの実装方法に関するガイドラインはありますか？

8 agile  unit-testing  documentation  tdd 

エンタープライズアプリケーションを開発しようとしているが、アジャイルプロセスから理解できる限り、機能を小さなチャンクに分割し、それらを繰り返し開発します。データベースとアプリケーションのコアを最初に作成してから、これらを繰り返し拡張していました。 問題は、以前に使用していたことを維持する必要がありますか（コアを最初に開発する必要がありますか）、ストーリーの開発にコア開発を分配する必要がありますか？後で、私はコードが将来の拡張のために十分に柔軟であるかどうか確信がありません！ 何か案が？

8 architecture  agile  object-oriented-design 

現在のところ、この質問は、Q＆A形式には適していません。私たちは回答が事実、参考文献、または専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張ディスカッションを誘います。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前に閉鎖。 なぜアジャイルになるのですか？これは、私がアジャイルになることを考えるときに頭に浮かぶ最初の質問です。アジャイルに移行することで実現できる財務上のメリットは何ですか？ 私たちのほとんどは、顧客やクライアントを自分が何を望んでいるのかを知らない人だと考えるのは確かです。では、なぜ彼らを助けるのか？寄生的な会社である彼らのお金を吸い込んで、彼らを毎日愚かにさせないのはなぜですか。従来のソフトウェア開発は悪くはなく、おそらく（ほとんどの場合私が見た限りでは）アジャイルプロジェクトよりも作業しやすい環境です。 では、なぜアジャイルに移行するのでしょうか。アジャイルは、従来のソフトウェア開発ではできない（経済的に）余分なものを何に与えることができますか？

8 agile  development-methodologies 

私たちの会社は最近、ほぼ一人（Joe）によってコード化された製品でスクラムに移行しました。私たちは、私たちのプロセスに統合しようとする既存の顧客との関係をサポートしています。 とりあえず、次の方法を試しました。 毎週担当者のローテーションを行っています。 1週間の担当者は、最大8時間のサポートに費やすことができます。 しかし、私たちはそれを機能させることができませんでした： Joeは常にコードをよく知っているため、常にサポートを提供します。説明するよりも、実行するほうが常に速いです。 私たち（残りの私たち）は、サポートタスクではなく、新しいストーリー（つまり、新しいストーリー）の内容に集中する傾向があります。 ジョーは仕事が多すぎて、スプリント以外でも何かをしなければならないので、自分ですべてのサポートを処理することはできません。 あなたはすでに同じような状況に直面しましたか？どのようにしてそれから抜け出したのですか？ 注：現在のところ、サポート担当者を1人にすることはできません。今後ともよろしくお願いいたします。

8 agile  scrum  support