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

スプリントの真ん中にある毎日のスタンドアップミーティング中に、デファクトプロジェクトマネージャー/スクラムマスターは通常、開発者に次のバージョンを尋ねます。 「それで、これはいつ行われるのですか？」 「では、今日の午後4時までにこのタスクを完了させることはできますか？」 「このサブタスクには何時間残っていますか？」 これは率直に言って非常に迷惑であり、物事をより速く終わらせません。その結果、開発者は多くのプレッシャーにさらされていると感じることが多く、スタンドアップはコラボレーションよりも戦場のように感じることがよくあります。 開発者として、これを処理する確かな方法は何ですか？

8 agile  scrum  user-story  sdlc 

Pivotal Trackerの技術的負債のユーザーストーリーに対して、私たちは何をすべきですか？これらを特徴（ポイントを与える）または雑用（ポイントを与えず、速度を下げる）と見なす必要がありますか？ 私は雑用と見なされるべきものを混乱しています： コードの重複-複数の場所に同じコードを配置した場合、それはコードの習慣としては非常に悪いことであり、チームの開発者はソフトウェアを保守可能にするためにより多くの検討を行い、リファクタリングを行い、コードレビューに時間を費やす必要があることを示しています。これにはすべて、成熟度、時間、コードレベルの経験が必要になるため、提供するポイント数を少なくして、コードの品質が損なわれないようにすることをお勧めします。したがって、そのようなミスは罰せられるべきであり、雑用にポイントを与えないことによって速度を下げる必要があります。 テクノロジーのアップグレード-JS、HTTP2、React、MVCまたはその他の新しい/より優れたテクノロジーのモジュール化への移行のように。これらの手順により、コードのパフォーマンスとメンテナンスが改善されます。しかし、これは雑用か機能か？これがテクノロジーの世界のあり方であり、新しいテクノロジーが時々やって来て、それに移行する必要があると思います。したがって、そのような作業に対してチームの速度にペナルティを課すことには意味がありません。提案？ レガシーコードの複製/サブスタンダードコード-長い間使用されていないコードや、新しいチームが結成されたがコードベースが少し古い場合、この問題に直面します。チームはこのセクションをコーディングしていないので、なぜそれらの負債を作成したことがないので、なぜそのような技術的負債を選ぶことによって彼らの速度にペナルティが課せられるべきであるとチームは言います。 ビジネスの緊急性が原因の標準以下のコード-競合他社/ターゲット/ビジネス/ユーザーのプレッシャーが原因で、開発者は機能をすぐにライブでプッシュしなければならない場合があります。そのような悪いコードのクリーンアップも雑用（ポイントを与えない）と見なす必要がありますか？今回の開発チームに問題はないので、なぜ彼らの速度を下げなければならないのですか？ 上記のすべてのタイプの雑用は、賢明に行えば、将来的にチームの速度を向上させるはずです。しかし、チームの速度を維持しながらバランスを保ち、チームが悪い決定を下すことで技術的なミスを罰する必要があるでしょうか。 質問は次のようなものです。 技術的な負債は機能または雑用（またはバグ）としてスケジュールする必要がありますか？が、4つのポイントすべてを網羅する説得力のある回答が見つからなかったため、別の方法で再投稿しています。

8 agile  scrum  estimation  technical-debt 

有効にするために100のルールをカバーする必要がある検証エンジンがあるとします。 また、チームは反復ごとに約10のルールしか配信できないと仮定します。 ルールエンジンにコアルールの90がまだ不足している場合、最初の反復の終わりまでに「リリース可能な製品の増分」を行うにはどうすればよいでしょうか。 たとえば、すべてのルールが実装されていないという事実に基づいて常に起動する一時的な失敗/警告を追加しますか？ コンテキストの編集：私は、大規模なモノリスを複製して置き換えることを目的とした、多くのレガシーユースケースを持つ複雑なビジネスプロセス用のミドルウェアを開発しています。100％カバレッジなしでライブ配信するのは困難です。サービスを要求する運用で表示されるトリッキーなユースケースを決定または制限する機能が限られているためです。

8 agile  scrum 

問題のケース： スプリントはほぼ終了し、私のスクラムチームの1つはいくつかのタスクを完了しませんでした。（この理由は、この質問では必須ではないので、それに応じて対処します。）それらの1つは、かなり多くのストーリーポイントを持つ古典的な「90％完了」のケースであり、次のスプリントの一部になります。こちらの質問です。 バックロググルーミングと次のスプリントのためのいくつかの予備的な見積もりを行い、この未完成のタスクを処理する方法について説明しました。このスプリントの速度にはカウントされないことに私たちは皆同意していますが、真の複雑さと実行された総作業を次のようにしたいので、5つのストーリーポイントではなく1でほぼ完全なケースを再推定しないでください。まだ見えています。そして推定を振り返ってみると正しかった。-私たちは（スケーリングされた）アジャイルに移行しているだけであり、一部の管理レベルでは、提供された製品よりも多くの点で生産性を維持していることを「確認」する必要があります。 明らかに、このスプリントの速度は低下しますが、転送された「既に完了した」パーツは、次のスプリントで再び上昇するはずです。 これまでのところ、全員が同意しています。 しかし、私たちのチームはかなり小さいので、4ポイントは大きなかたまりです。このタスクのみで適切なドキュメンテーションがあれば、意識的に4つのポイントの過負荷を計画できると提案しました。 それは実現可能なアプローチですか、それとも私は まだ予想していない問題に遭遇する ほんの数か月前にアジャイルに移行したチームに悪い例を示しますか？

8 agile  scrum  planning  sprint  scrum-master 

ユースケース（図ではなく説明について話している）と、要件を収集してより適切に整理するために使用されるユーザーストーリーの両方について聞いたことがあります。 私は一人で仕事をしているので、要件を整理し、開発で何をすべきかを理解するための最良の方法を見つけようとしています。巨大なドキュメントなどを扱う正式な方法論はありませんし、必要もありません。 私が製品バックログを作成するために使用されているように見えるユーザーストーリーには、開発で実行する必要があるすべてのものが含まれています。 一方、ユースケースは、システムでの処理方法、外部のアクターとシステム間の相互作用のフローの説明を提供します。 1つのユースケースに複数のユーザーストーリーがあるように思えます。 これは私に次の質問を導きます：要件を見つけるとき、最初に何をすべきですか？ユーザーストーリーを見つけて書いたり、ユースケースを見つけて書いたりしますか？それとも、何とかして「同時に」行う必要がありますか？ 私は実際にはかなり混乱しています。ユースケースとユーザーストーリーに関して、単独で作業する開発者にとって、より良い開発を行うためにこれらの方法論を正しく使用するには、良いワークフローとは何ですか？

8 agile  requirements  user-story  use-case 

私たちは最近、モノリシックWebアプリをマイクロサービスに分割し始め、ゆっくりと機能をスライスして個別のマイクロサービスに書き直しました。フロントエンドの作業を整理する最善の方法がわからない場合を除いて、すべて順調に進んでいます。私たちは製品チームに分かれて、少数のマイクロサービスのコードをそれぞれ管理し、検索、CMS、チェックアウトなどの機能領域を提供します。各チームには製品所有者、技術リーダー、スクラムマスターがいます。 問題は、これらの製品チームがそれぞれ独自のバックエンドコードベースを持っている一方で、フロントエンド開発者が各製品チームに座っている単一のフロントエンドReact.jsコードベースがあることです。これは多くの問題を引き起こしています： フロントエンド開発者間の製品チーム間のコミュニケーションの欠如 他のチームの新機能をサポートするために他のチームが「所有」しているフロントエンドコードに変更を加える際の問題 フロントエンドチームを代表する単一の技術エキスパートは存在しませんが、他の製品チームには技術的なリードがあり、フロントエンドでこの役割を果たしている人はいません。 私たちは他の人がこれをどのように扱っているのか疑問に思い、フロントエンドコードベースの分割、ビジネスユーザーが新機能のために通常従事するフロントエンド製品チームの作成、データ/サービスのリクエストなど、フロントエンドチームの他の製品チームですが、どちらにも独自の問題があります。

8 agile  microservices  organization 

私はコンピュータサイエンスを研究し、ほぼ1年間、非常にアジャイルなJavaプロジェクトで単一の開発者として会社で働いています。プロジェクトはまもなく成功します（少なくとも私はそう願っています！）。 コア機能...は機能しており、start-requirementsに含まれていなかった他の機能も機能しています。不要な新機能についてはたくさんのアイデアがありますが、プログラムの使いやすさと機能性には役立ちます。 プログラムのいくつかの部分は非常にうまく機能しますが、他の部分には私があまり誇りに思っていないコードがあります... プロジェクトの開始以来、私は多くのことを学んだので、理論的にそれらの部分でより良いコードを書く方法を知っています。 問題：プロジェクトの後、何かをする時間があまりないため、ゼロから書き直すことは不可能です。そして、悪い部分だけを書き直すには、コア機能に深く入り込む必要があります->時間がかかります！ 私の過ちから学び、次のプロジェクトをさらに良くする方法/戦略はありますか？ プロジェクトの完了後、次のプロジェクトに進む前に他にすべきことはありますか？

8 agile  clean-code  solo-development  retrospective 

私の現在のスクラムマスターは、公式のスクラムに屈することをいとわない真の信者です。私はこれが不確かに聞こえるようにしたくありません、私は過去に公式の用語で物事を再キャストすることによって彼と一緒に問題を解決することに成功しているので、この問題の正統な解決策について本当に尋ねています。 現在発生している問題の現在の例は、一部のストーリーの間に順序付けの依存関係があることです。（特に、開発の一部では、シングルシートライセンスしか持っていないサードパーティプログラムを使用しています。）これに関連するいくつかの必要なセットアップタスクがあり、「セットアップストーリー」にまとめられています。任意の順序で実行できるタスク。 問題は、現在のスプリントについて、セットアップストーリーと後続ストーリーの1つをプルしたことです。その時点で、スプリントが半分以下であっても、このグループでこれ以上のストーリーをとることはできないと述べました。このグループよりも優先度が低いバックログには無関係なストーリーがあり、スプリントに取り入れることをお勧めします。ただし、これらはすべて、このグループのストーリーの下で優先されました。この時点で、スクラムマスターは、「セットアップタスク」に群がってそれをより速く実行する必要があると述べました。これは、以前に発生した競合であり、彼は問題を抱えています。 したがって、このスプリントの前半では、2人の開発者と1つのテストリソースが、外部ベンダーの構成Webサイトでの作業、リソースのダウンロード、および証明書のシャッフルを監視しています。3つのスプリントでリリースされる予定で、POが希望するバックログのほぼ全体を取得できることはわかっていますが、誰もが座っている間はこれらのタスクで作業が行われていないので（er、群れ）最も優先度の高いストーリーのセットアップタスク。 私のスクラムマスターは、私たちの唯一の懸念は、スプリントに受け入れたストーリーを完成させることだと言っています。私は理解していますが、私たちは、製品の所有者から受け取った優先順位付けが引き起こしている「不良箱の梱包」を伝えないことによって、より大きな組織を失敗させているように感じます。 それでは、ストーリーと本質的に連続するストーリーとの間の依存関係の問題は、方法論によってどのように公式に処理されますか？

8 agile  scrum  scrum-master 

問題は： 私が働いているチームは、開発者が10人、テスターが2人という比率です。つまり、「テスト」よりも早くコードを作成することになります。 では、アジャイルの専門家によると、このようなシナリオでの活動を追跡するための正しいアプローチは何でしょうか？ 以前のスプリントで「完了」と呼ばれるもの（テストは行われていません）がたくさんあるときに、近いうちにその日が来るのではないかと心配しています。 努力をシームレスに追跡するにはどうすればよいですか？テストは「完了定義」の一部である必要がありますか？そうでない場合の落とし穴は何ですか？ 私によると、実際に機能テストされる前にストーリーを「完了」と呼んでいるので、これは一種の「ウォーターフォール」です。

8 testing  agile 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 始める前に、先取りの謝罪をする必要があります。 この投稿で使用している用語や語彙の一部が明らかに間違っている可能性が非常に高いため、重要な側面の一部を完全に誤って解釈している可能性もあります。私はこれが初めてなので、批判的になりすぎないでください。建設的なフィードバックを歓迎します。;） バックグラウンド 現在、200名の開発部門をマルチメソッドから「アジャイル」に移行しています。理由、理由、長所、短所は、この質問の範囲をはるかに超えています。 この開発部門には、正式に「ソリューションアーキテクト」と呼ばれる10人で構成されるアーキテクチャサービスチームが含まれています。実際には、それらはソリューションだけでなく、プロジェクトのすべての技術アーキテクチャ面（つまり、ハードウェア、ソフトウェア、セキュリティ、ガバナンスなど）をカバーする技術者です。また、開発チームに特別な機能（コードレビュー、標準ガイダンスなど）と幅広いビジネス（入札への技術的インプット、顧客の要件の事前契約技術プレビュー）を提供します。 この移行の一環として、私は、建築サービスチームが責任を負う作業活動を把握するために、かんばんボードを作成する任務を負っていました。開発/コーディングチーム用の無数のサンプルボードがありますが、アーキテクチャ用に見つけることができるものはありません。だから私は様々なソースから取って「何か」を作成しました、それについての真のフィードバックを本当に感謝します。 また、これは開始点/進行中の作業としてチームに提示されることにも注意してください。それは彼らのボードであり、私は彼らにそれを所有してほしいと思っています。 これまでのところ私はこのようなものを持っています メインボード メインボードは、すべてのアクティブ/バックログプロジェクトを保持する場所です。すべてのアクティブな作業はこのボードで行われます。これは、毎日の建築スクラムで簡単にレビューされ、毎週の終わりにさらに詳細なレビューが行われます。 ------------------------------------------------------------------------ | Evaluation | Implementation | Ad- Hoc | | Todo | Doing | Done | Todo | Doing | Done | Todo | Doing | Done | ------------------------------------------------------------------------------- Person | | | | | | | …

8 architecture  agile  kanban 

私が働いている場所では、最近、スクラムを使用してアジャイル開発を切り替えました。典型的な高まる苦痛を経験しましたが、今のところうまくいくように見えるアプローチに達しました（長期的にうまくいくかどうかは別の質問です！）。 明らかに、部門管理者はスクラムへの移行が機能していることに満足しています。しかし、彼らは私にとっては間違っていると感じることを始めています。 経営陣はチームを観察し、彼らにとって何が有効かを確認し、それを部門全体に処方します。のようなもの： 「完了」の定義 ストーリーポイントに使用できるストーリーポイント値（たとえば、1、2、3、5、13などが、スプリント中に使用された唯一の値であるため、fib。シーケンスから8を省略） ストーリーポイント値1を「UIラベルの更新」に調整する必要があることをチームに伝え、上限を20に制限する （すべてのプロジェクトにクライアントがいるわけではなく、すべての開発者がUIの経験があるわけではありません） ストーリーポイントの推定値100を使用して「このストーリーは後で分割する」ことをチームに伝える 無限のストーリーポイントの推定値を使用して、「これは壮大です」または「詳細情報が必要」を意味することをチームに伝える 私は彼らが役に立とうとしていることを理解していますが、上記のすべてがスクラムチーム固有のものではないのですか？つまり、あるプロジェクトの個人のグループで機能するものは、別のプロジェクトの別のグループでは意味をなさない場合があります。 非常に規範的で堅固なアジャイルアプローチに移行しているのではないかと心配しています。私はこれを考えることで正当化されますか、それとも私は過剰反応していますか？ 編集する 明確にするために...「管理」と「マネージャー」によって私は製品の所有者を意味しません。私は、スクラムチーム外の、ソフトウェア部門内のマネージャーを意味します。

8 agile  scrum  management 

私たちは、プロジェクトに最適なスプリントの長さを見つけようとしていました。3週間ベースで作業した後、スプリントを2週間に削減すると、速度が向上すると考えました。 利点は明らかでした-短いフィードバックループ、小さなストーリー（ユーザー価値あり）など。一方で、セレモニー（企画、回顧）など、私たちが制作しておらず、より頻繁に発生するデメリットもたくさんあります。 新しいチームのために、最適なスプリントの長さをどのように決定できるのかと思っていました。

8 agile  scrum  sprint  feedback 

受け入れ基準に関するこのブログの投稿で、著者は適切な受け入れ基準は次のようでなければならないことを説明しています。 解決策ではなく意図を述べる（たとえば、「ユーザーはドロップダウンからアカウントを選択できる」ではなく「ユーザーはアカウントを選択できる」） 実装に依存しない（理想的には、この機能/ストーリーがWeb、モバイル、音声起動システムなどに実装されるかどうかにかかわらず、フレージングは​​同じです） 比較的高いレベルである（すべての詳細が書面である必要はない） 次のような詳細： 列見出しは「バランス」です ローリングバランスの形式は99,999,999,999.9 D / CRです。 チェックボックスではなくドロップダウンを使用する必要があります チームの内部ドキュメントまたは自動受け入れテストのいずれかに移動する必要があります ただし、GUIテストを実行するためにCucumberまたは同様のフレームワークを使用することについて眉をひそめる人々をよく耳にします。さらに、内部ドキュメントを使用すると、ドキュメントを定期的に更新できないために多くの問題が発生する可能性があります。 私はまだ、お客様との会話中にそのような詳細をキャプチャする効果的な方法を見つけるのに苦労しています。

8 agile  development-process  scrum  requirements  user-story 

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

8 agile  software  extreme-programming  engineering 

私は、システムを介したユーザーワークフローなど、大きなユーザーストーリーを役立つ方法で分割するためのさまざまな手法を読んでいます。私が苦労しているのは、これらの小さなストーリーを実現するために次のステップを促進する場合、どのようにこれらの小さなストーリーを表現するかです。プロセスとユーザーへのアプリケーションの主な利点を提供していません。 たとえば、私の新しいシステムが3つの小さなストーリーに分割されている場合、 オンラインで新しいアカウントを作成する 新しいオンラインアカウントに対して特定のエンティティを作成する 私のモバイルデバイスにこれらのエンティティを私のアカウントに対してクエリさせ、それらに作用させる システムは、すべてのストーリーが完成したときにのみ、エンドユーザーに本当に役立つ機能を提供します。したがって、従来の「[ユーザーとして] [機能]で[メリット]を実現したい」とする場合、最初と2番目のストーリーのメリットは、後続のストーリーを促進するだけであり、ユーザーに主要な機能（叙事詩）。これはこれを行う正しい方法ですか？

8 agile  user-story