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

ユーザーストーリーがアジャイルの世界を支配していることは理解していますが、これらのアーティファクトはどのように保存されるので、チームに参加する新しい開発者が要件に追いつくことができますか？ ユーザーストーリーが後で変更された場合、どのように更新され、アーティファクトとして保持されますか？多くのチームが、元のストーリーを追跡するのではなく、新しいチケット/機能のリクエスト/バグレポートを開くだけを見てきました。

22 agile  scrum  user-story 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 2年前に閉店しました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 先日の会議で、アジャイルは開発時の効率がウォーターフォールと比較してわずか60％であるという主張がなされました。私はこの主張を検証したり、反論したりするつもりはありません。2つの方法論を比較する研究があったかどうかを調べるのは興味深い。 2つを比較する研究はありますか？

22 project-management  agile 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 プランニングポーカー 要約、wiki記事を読みたくない場合： 次のイテレーションで実行したいタスクのリストを取得します 各タスクについて： 2.1グループが必要とするものについて話し合う 2.2全員がタスクに必要な労力の見積もりを書き留める/選択する 2.3誰もが見積もりを明らかにする 2.4最高と最低の外れ値 がコンセンサスに達するまで繰り返す2.5 通常、0、½、1、2、3、5、8、13、20、40、100のようなフィボナッチ数列の数字に似た値が許可されているので、23のような近い値に対して長い引数を取得しません。 27。 さらに、数字は努力の単位のない値を表し、その値は、誰もが約1に等しいことに同意するベースラインタスクによって決定され、他のすべてはそれに関連しています。 最終的に、目標は、特定のチームの「速度」、つまり特定の反復で完了することができるこれらのポイントの数について良い感触を得ることです。これにより、特定の機能にかかる時間をかなり正確に見積もることができます。 私が働いていたある会社でのイテレーション計画会議でこれを行いましたが、それはその特定の会社にとって数少ない良いことの一つだと思いました。だから、私が思っているのは、誰かがこれを使ったことがありますか？推定に役立つツールだと思いますか？すべての状況で機能しますか、それとも特定のチーム、プロジェクトなどに役立ちますか？

22 agile  estimation  iterative-development 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私は一般的に、バックエンドおよびフロントエンドの開発があるストーリーを見ます。たとえば、いくつかのテーブルといくつかの動的コントロールを備えた大きなダイアログを考えてみましょう。複数のストーリーを作成します（各テーブルに1つずつ、動的制御システムに1つずつ）。 その後、開発チームはバックエンドで1人、フロントエンドで1人に分割されます。これにより、バックエンドの人はSQLレイヤーの構造を心配するだけで済み、フロントエンドの人はレイアウトなどに集中できます。バックエンドとフロントエンドの間の最初のインターフェースが合意された後、2人の開発者はスプリントの終わりまでに自分の部分を成し遂げるために注意を集中できます。 それからカオスが来る。誰がどの物語を「所有」していますか？「進行中」とはどういう意味ですか？バックエンドとフロントエンドの2つの別々のストーリーを作成する必要がありますか？もしそうなら、それは機能に基づいたユーザーストーリーのアイデアを壊しませんか？私たちのシステムには「サブタスク」という概念があり、これらの問題のいくつかを緩和します。ただし、サブタスクはさらに複雑になります。もっと良い方法はありますか？これはスクラムを使用する「悪い」方法ですか？ 過去数年間、いくつかの場所で何らかの形のアジャイルを使用しています。公式のトレーニングはまだありませんので、間違った用語やイデオロギーはご容赦ください。プロセスを改善する実用的な方法を学ぼうとしています。

21 agile  scrum 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 アジャイル方法論は、要件が十分に理解されていない設定で優れている、または重要な新規性が関係していると言うことは一つのことです。しかし、完全なイノベーションが必要な場合に適用すべきでしょうか？はいの場合、どのように？ 考えていることが業界で不明であるか、不可能であると思われる場合でも、ユーザーストーリーと関連タスクを想像することは困難です。たとえば、アルバート・アインシュタイン（または彼が報告する仮想の雇用主）にとって、一般相対性理論を叙事詩、短距離走、および課題に分解することで考案したのは有益でしょうか？答えが「はい」の場合、アインシュタインのアプローチが革命的な洞察を達成するアジャイルのアプローチと最もうまく機能するのを助けるために、どの特別な宿泊施設が組み込まれるべきでしたか？ 特定のソフトウェアの例を挙げると、2008年であり、WCFを使用してCOMETまたは「ロングポーリング」タイプの機能を提供したいと考えてください。「以前の仕事」に関するあなたの研究はすべて何も見つかりませんでしたし、MSDNのブロガーはそれが不可能だと言っていました。 繰り返しますが、この試みの発明性（または大胆さ）に対応するために、ユーザーストーリーおよびタスクにどのような調整または「フレーバー」を組み込むことができますか？それとも、その努力は非常に革新的であると結論付ける方が良いでしょうか（2008年）、それは無向のシンクタンクの練習として残すのが最善です。 2週間のスプリントで動作しているイノベーターは、デッドエンドタスクを放棄し、スプリントが定義されたときに想定されていなかった新たに発見されたタスクで作業を開始するたびに撃certainlyされることを望みません。同様に、スプリントが終了し、実行中のコードまたは実行中のアプローチが配信されない場合、イノベーターは経営陣に打ち倒されるべきではありません。このような状況でも、努力を「成功」とラベル付けする方法が必要です。おそらく、この種の「行き止まり」の追求の1つまたは3つ以上のスプリントで、イノベーターは最終的に機能する何かにぶつかります。 アジャイルは、革新的な後退にもかかわらず、各スプリントが「OK」であることを経営者がどのように知ることができるのですか？バーンダウンチャートが不合理に見えないように、これをどのように管理しますか？

21 agile 

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 私は最近、より正確にアジャイル、スクラムを行ういくつかの企業にインタビューしましたが、私にはアジャイルとは思えないものがいくつかあります。私が特に興味を持っているのは、スクラムスプリントのケースです。 私が話した特定のプロジェクトマネージャー（はい、私はプロジェクトマネージャーと言いました）は、彼女のチームの人々が、勤務時間を過ぎても家に帰らないことを理解していることを誇らしげに述べました、仕事がどれだけかかっても家に帰ります。行間で読んだことは、できる限り多くの機能をスプリントにまとめ、それを実現するために残業することです。 今、私は今までにアジャイルをやっていません（ほとんどの場合、ウォーターフォールを好む金融機関や政府機関と協力しました）が、私の理解は次のとおりです： スクラムのスプリントは、アジャイルの一般的な反復の名前です。 チームは持続可能なペースで作業し、長期的な残業を避けるように努める必要があります。これは、短時間にしか影響を与えず、その影響は長期間に発生する問題によってd小化されるためです。 私の声明は正しいですか？そして、マネージャーのプレゼンテーションを危険信号とみなすべきですか？

21 agile  scrum  development-methodologies 

プロジェクトに最近参加したプロのスクラムマスターコンサルタント[*]がいます。残念ながら、私たちは彼女の名前を知りません（彼女は私たちに自己紹介したことはありません、彼女は1日で来て、「私たちは毎日立ち上がっている」と言いました）、そして彼女は椅子a毎日のスタンドアップミーティング-私は冗談で彼女にミーティングで毎日フィードバックをするように頼んだとき、彼女は非常にf辱され、「参加せずに促進する」ことがスクラムマスターの仕事だと言った。 これはかなり反アジャイルのようです（他のアジャイルプロジェクトに取り組んでおり、チームは自己指示されていました）。これは平等主義であるはずですが、スクラム方法論でどのように機能するかはわかりません。私は彼女が一日中あまり役に立たないと思います、そしてそれがこの問題に対する彼女の防御の理由です。 スクラムマスターは、スタンドアップミーティング中に「昨日、今日、障害」という演説に参加しますか、それとも、会議の議長を務める（「促進する」）役割がありますか？ [*]彼女は自分の仕事が何であるかを実際に知らされていませんでした。

21 agile  scrum  methodology  meetings 

アジャイル開発では、ポリシーとアプリケーションロジックは永続化メソッドなどの詳細よりも重要であるため、最後に永続化の決定を下す必要があると誰かが説明してくれました。したがって、この方法の弱点が明らかになるまでフラットファイルなどのより単純な永続性から始めてから、リレーショナルデータベースなどを使用して永続性を変更することをお勧めします。 これは本当ですか、それともコンセプトを誤解しましたか？これはアジャイルチームが通常どのようにアプリケーションを構築するのですか？その理由は何ですか？また、このアプローチを採用すべきではないのはいつですか？

21 architecture  agile  database  persistence 

TDDアプローチを使用することを自分で学びたいと思っていたので、しばらくの間、やりたいプロジェクトがありました。大規模なプロジェクトではなかったので、TDDの良い候補になると思いました。しかし、何かがおかしくなったように感じます。例を挙げましょう： 高レベルでは、私のプロジェクトはMicrosoft OneNoteのアドインであり、プロジェクトをより簡単に追跡および管理できます。また、いつか自分のカスタムストレージとバックエンドを構築することにした場合に備えて、このためのビジネスロジックをOneNoteから可能な限り切り離したままにしておきたいと考えました。 最初に、基本的な平易な言葉の受け入れテストから始めて、最初の機能で何をしたいかを概説しました。これは次のようなものです（簡潔にするために説明を省略しています）。 ユーザーがプロジェクトの作成をクリックします プロジェクトのタイトルにユーザーが入力する プロジェクトが正しく作成されたことを確認します UIのものといくつかの中間計画をスキップして、最初のユニットテストに行きます。 [TestMethod] public void CreateProject_BasicParameters_ProjectIsValid() { var testController = new Controller(); Project newProject = testController(A.Dummy<String>()); Assert.IsNotNull(newProject); } ここまでは順調ですね。赤、緑、リファクタリングなど。今では実際に保存する必要があります。ここでいくつかの手順を省略して、これで終わります。 [TestMethod] public void CreateProject_BasicParameters_ProjectMatchesExpected() { var fakeDataStore = A.Fake<IDataStore>(); var testController = new Controller(fakeDataStore); String expectedTitle = fixture.Create<String>("Title"); Project newProject = testController(expectedTitle); Assert.AreEqual(expectedTitle, newProject.Title); } …

20 c#  agile  unit-testing  tdd  refactoring 

多数のアジャイルスクラムチームを持つ組織には、「エンタープライズアーキテクト」として任命された少数の人々のグループもいます。EAグループは、品質と意思決定の遵守のためのコントロールおよびゲートキーパーとして機能します。これにより、チームの決定とEAの決定が重複します。 たとえば、チームはライブラリXを使用するか、SOAPの代わりにRESTを使用する場合がありますが、EAはそれを承認しません。 現在、これはチームの決定が却下された場合にフラストレーションにつながる可能性があります。十分に考えれば、EAの人々がすべての力を「つかむ」可能性があり、チームはやる気がなく、あまり機敏ではないという感じになります。 スクラムガイドこれはそれについて言いたいことがあります。 自己組織化：開発チームに、製品バックログをリリース可能な機能の増分に変換する方法を教えてくれる人はいません（スクラムマスターでさえも）。 それは合理的ですか？EAチームは解散すべきですか？チームは拒否するべきですか、それとも単に従うべきですか？

20 agile  scrum  teamwork  architect 

ポーカーを計画することでプロジェクトの見積もりの​​精度が向上するというのが一般的な意見ですが（この質問でその小さなサンプルが実証されています）、このテーマに関して明確な研究が行われていますか？ 具体的には、ポーカーのプランニングが従来の推定手法よりも改善されることを示す非状況情報を探しています。

20 agile  estimation  planning  research 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 アジャイルソフトウェア開発は、ユーザーストーリーと呼ばれるワークアイテムタイプに大きく依存しています。たとえば、ユーザーストーリーでいっぱいのバックログがあり、それらのいくつかを選択して次のスプリントで作業することができます。 しかし、バックログに入れるユーザーストーリーをどこでどのように見つけますか？ストーリーマッピングと呼ばれる一般的な手法があります。ジェフパットンがそれを発明しました、そして、ここにそれをする方法に関する決定的なガイドがあります。 問題は、Pattonのストーリーマッピング手法をサポートする電子ツールは何ですか？ 私は少し調査を行ったところ、Pivo​​talおよびRallyプラグインが見つかりましたが（どちらの顧客でもありません）、現在SilverStoriesを試しています。 他にどんなツールがありますか？何を使いましたか？あなたは何をお勧めしますか（しません）？どうして？ 更新：コメントを書いた人の中には、この手法を電子ツールで適用することは単に不可能であるという答えに傾いているようであり、それを受け入れるべきです。誰かが答えとしてそれを書くことはできませんか？ 更新（Alex Feinmanのコメントを踏まえて質問を明確にするため）：質問は、ストーリーマッピングのオプションを識別することです。ジェフ・パットンのテクニックは、明らかにスティッキー付きのホワイトボードで実行できるため、質問は電子ツールで提供される可能性のある追加オプションに焦点を当てています。（未熟な）特定のツールまたはツールのクラスに対するコミットメントは、この質問のポイントではありません。

20 agile  user-story  product-backlog 

私は最近新しい仕事に着手しましたが、ペアリングを行うことで非常に迅速に効果的になりました。ただし、ワークフロー中にAPIの機能、コード例、またはコマンドオプションをカバーする簡単な共同研究を行う必要がある場合、私は苦労しています。私のチームリーダーは、個々のラップトップではなくペアリングステーションですべての調査を行い、異なるWebリソース間で手順を口頭で交渉することで調査を同期することをお勧めします。 私はペアリングパートナーとは異なる方法で情報を調査、読み取り、吸収します。また、正確なペースと場所を維持しようとするのではなく、次のWebページに正確に行きたいときに調査のスレッドをたどることができると、生産性が大幅に向上します私のパートナーの読書。私たちは賢くて速いのですが、物事を考え出すとき、さまざまな方法で動き、瞬時の速度を出すことはできません。誰かが「私はそれを手に入れました」と言ってから、一緒に戻ってコードを書くまで、1分間個別に動き回るのは非常に簡単に思えます。 プログラムをペアリングするとき、短い研究タスクをどのように処理しますか？あなたに最適なものは何ですか？また、パートナーと同期を保つ方法は？

20 agile  pair-programming 

アジャイル手法、ドメイン駆動設計、オブジェクト指向分析および設計など、ソフトウェア開発への多くのアプローチでは、開発への1つの反復アプローチを採用することをお勧めします。 そのため、プロジェクトでの作業を初めて開始したときにドメインモデルを正しく実行することは想定されていません。代わりに、時間が経つにつれてモデルをリファクタリングします。なぜなら、時間とともに問題の領域をより深く理解できるからです。 それとは別に、完璧なモデルを事前に取得しようとしても、私はすでに非常に難しいと確信していますが、要件は変わる可能性があります。ソフトウェアがそのようにした後にしている生産に配備され、エンドユーザーは、一定の要件を完全に理解していなかったことに気づくかもしれない、あるいは悪化し、いくつかの要件が欠落していました。 ここでのポイントは、ソフトウェアの展開後にモデルの変更が必要になる場合があるということです。これが発生した場合、問題が発生します。本番データベースには重要なユーザーデータがあり、古いモデルの形式に既に適合しています。 コードが適切に設計されておらず、システムが大きい場合、コードの更新は困難な作業になる可能性があります。しかし、それは時間とともに実行できます。Gitのようなツールを使用すると、本番対応バージョンを損傷することなくそれを実行できます。 一方、モデルが変更された場合、クラスのプロパティが消失した場合など、データベースも変更される必要があります。しかし、問題があります。そこには、失われないデータが既にあり、古いモデル用にフォーマットされています。 ここのリレーショナルデータベースは、エンドユーザーの要求に応じて反復的な開発を行ったり、ソフトウェアを更新したりすることを妨げる障壁になっているようです。 私がすでに使用したアプローチの1つは、古いデータベーステーブルを新しいテーブルにマップする特別なクラスをコーディングすることでした。したがって、これらのクラスは古い形式のデータを選択し、新しいモデルで使用される形式に変換して、新しいテーブルに保存します。 このアプローチは最良の方法ではないようです。ここでの私の質問は次のとおりです。リレーショナルデータベースで反復開発を調整するためのよく知られた推奨アプローチはありますか。

19 database  agile  domain-driven-design  relational-database  ooad 

アジャイルチームでは、現在のスプリントで行われている作業だけでなく、システム全体に影響する高レベルのアーキテクチャと設計の決定を担当するのは誰ですか？ プロダクトオーナー、スクラムマスター、スクラムチーム、または他の誰かでしょうか？

19 agile  scrum