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

私たちは約200人の開発者で構成される組織であり、特定の日にリリースされる予定の1つの製品（リビジョン管理Gitを使用）で継続的に作業しています。 開発者が非常に多いため、各チームに約10人の開発者がいる「クロスファンクショナル」チームを作成しようとしています。その結果、組織内に約20の開発チームができます。 メインリポジトリ内の製品の継続的な「高水準」（開発者がプルするとき、製品が少なくともコンパイル可能であることなど）を維持したいので、何らかの品質ゲートを使用したいと思います。 質問の言い方が少しわかりませんが、単一の製品に取り組んでいるこのような大規模な開発者グループの開発方法論に関するアドバイスを得ることができるかどうか疑問に思っています。 私たちの意見では、スペクトルの一端は各開発者がメインリポジトリに直接コミットできるようにすることですが、開発者/コミットの数が多いため、「メインリポジトリ」が常に壊れた段階にある可能性があることを恐れていますコミットごとに厳しい「品質ゲート」を持つことはできません。 スペクトルのもう一方の端は、（メインリポジトリ）に3つのプルソースのみがあり、これら3つに少数の信頼できるプルソースのみがあるツリーまたはピラミッド構造のようなものです（Linus Torvalds / Linuxが行うと思います）しかし、そのような構造では、変更が「メインリポジトリ」に入るために登るには長いチェーンがあると感じています。さらに、マージの競合が発生した場合、「元の開発者」以外の別の開発者に問題が発生します。 この背景情報と意見をすべて述べた上で、非常に多くの開発者に推奨される開発方法論をどのように学び、読むことができますか？大規模な組織（Microsoft、Facebook、Ubuntuなど）はどのように開発を構成していますか？

19 agile  workflows  software  development-methodologies  gitflow 

私のPivotal Trackerボードにいくつかの技術的負債に対処するユーザーストーリーをいくつか追加しました。それらを機能（速度レベルを維持）または雑用/バグ（速度を低下）として考慮する必要がありますか？どちらか一方を一貫してやったとしても、長期的には何の違いも生じないことは理解していますが、技術的な負債のストーリーを追加するたびに判断しなければなりません。 いくつかの考え： それらは実際にはバグではなく、何も壊しません ユーザーに影響を与えないのは低レベルの実装であるため、ユーザーは何も要求していませんが、長期的な開発を容易にします あなたもユーザに付加価値を話、などの機能を定義した場合）彼らは、ユーザーが行うすべての直接的な利益が、その後B）は表示されませんしない限り、彼らはその可能な将来の開発/メンテナンスを行うために行い、追加値を、ちょうど今ではない 私は実際に作業を行うかどうか、またはいつスケジュールするかを決定していません。プロジェクト管理ツールで技術的負債と呼ぶべきものとその理由を知るだけです。

19 project-management  agile  technical-debt  kanban 

私たちはプロジェクトでスクラムをフォローしています。ほとんどの場合、スクラムマスターがタスクを割り当てます。しかし、私は多くのスクラムの本を読んで、スクラムが逆に機能し（「プル」アプローチ）、チームメンバーがタスクや機能を取り上げることを読みました。スクラムマスターはタスクに正しいアプローチを割り当てていますか、それともアジャイルイデオロギーに反していますか？

19 project-management  agile  scrum 

「ユーザーストーリーは要件ではなく、顧客が望むものを思い出させるだけであり、ストーリー内に要件を置くことはできません」と言われました。しかし、顧客がクレジットカードごとに異なる処理を望んでいる例を見てみましょう。テストケースを作成できるように、実装する必要のある厳密な要件があります。ユーザーストーリーにない場合、要件はどこに行くべきですか？ より低い要件がない場合、開発者はストーリーからどのように開発できますか？テスターはユーザーストーリーに基づいてテストケース（詳細なケース）をどのように作成できますか？DB制約、フィールドの検証などの要件は、ユーザーストーリーの外側にありますか？

18 agile  scrum  requirements 

このプロジェクトでは、ゼロバグ（別名ゼロディフェクト）方法論で作業します。基本的な考え方は、バグは常に機能よりも優先度が高いということです。ストーリーの作成中にバグがある場合は、ストーリーを承認するために解決する必要があります。古いストーリーのスプリント中にバグが見つかった場合は、バックログに次に配置して解決する必要があります-最優先事項。 私が解決と言っている理由は、バグを常に修正するとは限らないからです。それほど重要ではないので、「修正しない」と宣言することもあります。全体的に素晴らしいですね。私たちは高品質の製品を出荷しており、巨大なバグのバックログの形で「こぶ」を運んでいません。 しかし、このアプローチが正しいかどうかはわかりません。深刻なバグをできるだけ早く修正する必要があり、重要ではないバグを破棄する必要があることに同意する傾向があります。しかし、重要ではあるが新機能ほど重要ではないバグはどうでしょうか？それらは適切な優先順位でバックログにファイルされるべきだと思う傾向があります。 より明確にするために例を挙げます-私のプロジェクトでは、flexで書かれたUIを使用します。すべての画面解像度で同じサイズで開くウィザード画面があります。ウィザードウィンドウを拡張すると、ページの1つが見栄えがよくないことがわかりました（ウィザードはすべてを表示でき、スクロールバーを必要としないにもかかわらず、消えない垂直スクロールバーがあります）。このバグは見苦しいと思います。修正する必要があると確信しています。しかし、私たちは厳しいスケジュールにあり、多くの機能を備えているので、カットを加えてリリースすることはできないと考えています。私たちはそのようなバグに耐えることができると感じています。修正する必要はありますが、他の機能よりも優先度が低くなります（したがって、完了できない場合は、少なくとも重要な機能を除外しませんでした）。だが、 「修正できない」とマークしたくないが、最も重要ではないバグに対処する方法について意見を聞きたいと思います。

18 agile  scrum  bug  backlog 

スクラムに関する最近の白熱した議論の後、私の問題は、管理が完全にアジャイルなチームで非常に不必要で冗長な活動であると考えることであることに気付きました。成熟したアジャイルチームは、管理や非技術的な意思決定プロセスを一切必要としません。私の（明らかに間違い）目には、成熟した開発チームを管理するのに適した能力があるのはコーチ（適切なコミュニケーションスキルを持つ最も技術的に有能な同僚）だけであることは明らかです。スクラムマスターがこのようなチームにどのように貢献できるか想像できません。 私は、スクラムとそのようなベテラン開発者ではないが、チームにコーチがいる場合の生産サイクルの計画に長けているマネージャーの価値を理解し理解するのに非常に苦労しています。それは一体何の意味ですか？開発の最先端スキルを持たない人が高度な技術チームを管理するにはどうすればよいのでしょうか？おそらくここでの管理は何か他のものを意味するのでしょうか？ 管理は時間の無駄であり、未熟さの副産物だと考えています。私の理解では、成熟したチームは完全に自己管理しています。どうやら私は多くの偉大な人々が反対を言うので間違っていますが、私は自分を納得させることができません。

18 agile  scrum  management  extreme-programming 

私は主にプロジェクトでウォーターフォール方法論を使用しましたが、今ではアジャイル方法論に視野を広げています。これまで読んだことから、そしておそらく間違ったことを読んだことから、アジャイルは小さな滝を意味します。1年または2年にわたって広がる大きな滝の代わりに、最後の数週間またはせいぜい数ヶ月の小さな滝があります。 私の理解は正しいですか、それ以上のものがありますか？アジャイル哲学とは何ですか？

18 agile  development-process 

最近、「xページからログインページに移動するとエラーが表示されます。そのエラーを削除したい」というアイテムが製品所有者によって製品バックログに追加されました。 これはユースケースではなく、PBI（Product Backlog Item）であってはならないようです。しかし、私が議論したとき、スクラムマスターは、ユーザーストーリーはPBIではなく、PBIはバグレポート、タスク、ユーザーストーリー、あらゆるもの、文字通り最初に対処する必要のあるアイテムであると教えてくれました。 これについてはわかりません。また、ウェブ上でPBIの適切な定義を見つけることができません。だから、私の質問は、どのようなものがアイテムとして製品バックログに入ることができるのですか？製品バックログアイテムはユーザーストーリーにマッピングされますか？彼らは同じですか？

18 agile  scrum  definition  product-backlog 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 「クロスファンクショナルチーム」の一般的な意味は、目標を達成するために必要なさまざまな分野の専門家を組み合わせたチームです。 しかし、アジャイルのクロス機能性とは、異なる専門家を組み合わせるだけでなく、それらを混合させることを意味するように見えます。Henrik Kniberg は、クロスファンクショナルチームを次のように定義しています。 しかし、線はどこに描かれていますか？必要な場合、開発者に反復のテスターに​​なるように依頼するのは普通ですか？

18 agile  team  organization 

ソフトウェアの開発方法を改善したい。より速く、優れたコードを開発したい！今日、私はフリーランサーとしてウォーターフォール法を使用し、Webスタッフ（サイト、システムなど）を作成しています。このように動作するアジャイル開発（XP、SCRUMなど）を使用する方法はありますか？アジャイル開発について何も知らないのですが、どこから始めればいいですか？どうもありがとうございました。

18 agile  freelancing  scrum  web 

アジャイル手法をどのように適用するかは、大規模で複雑な組み込みシステムソフトウェア（100人以上のエンジニア）に本当にあるのかといつも思っていました。ファームウェア開発には、アジャイルを実行するのを難しくするいくつかの独自の特性があります（つまり、ハードウェアは開発サイクルの後半まで利用できません。製品がリリースされると、ファームウェアを簡単に更新できませんなど）。 この種の開発の標準は、厚手のドキュメントと厳しいピアレビューです。2〜3個の署名なしで変数の名前を変更するなどの簡単なコード修正を取得することはできません。（少し誇張しますが、これは典型的なことです。さらに、多くの人がショートカットを採用しており、特に厳しい市場の締め切りに直面して、プロジェクトマネージャーはそれらを承認します。） ファームウェア開発プロジェクトにアジャイル手法を採用する方法に関するヒントやガイドラインを聞きたいです。

17 agile  scrum  embedded-systems 

チケットの推定時間を作成するとき、テスター（QA）にかかる時間をチケットの推定に含める必要がありますか？以前は、テスターの時間なしで常に見積もっていましたが、常にそれを含めることについて話し合っています。チケットがあと1週間でかかる合計時間を知る必要があるため、現在のスプリント、リリース前の最後のスプリントには意味があります。 チームのリソースを制限する傾向があるため、見積もりは開発者向けの時間であると常に理解していました。同僚は、テスターの時間より前に働いていた場所はどこでも含まれていると言っています。 明確にするために、これは、開発者が適切なカバレッジでユニット、統合、およびUIテストを記述しているプロセスのためのものです。

17 agile  scrum  estimation  qa 

私の会社では、アジャイルプラクティスでの作業に成功していますが、反復は使用していません。主な理由は、反復サイクルでQAに適合するクリーンな方法を見つけることができないからです。 QAは、特定のビルド（リリース候補）に対する追加の検証として、このビルドが顧客に展開される前に理解します。ポイントは、1つの悪意のあるコミットがリリース全体に損害を与えることを避けることです。あなたはそれがどれであるかを決して知らないので、QAはリリースのすべての機能/コミットがビルドに含まれるまで待つ必要があります。（有名な最後の言葉「それはほんの小さな変化でした」は許可されていません。） QAがリリース候補でバグを見つけた場合、開発者はそれぞれのリリースブランチでこれらのバグを修正します（そして、トランクにマージします）。すべてのバグが修正されると、QAが再テストするために新しいビルドが展開されます。特定のリリース候補にバグが見つからない場合にのみ、検証のために顧客に提供されます。 これには通常、リリースごとに約2〜3つの候補、約1週間かかります。通常、修正を記述する時間は、テスト作業よりもはるかに短いです。したがって、開発者を忙しくしておくために、彼らはリリースN + 1に取り組み、QAはNに取り組みます。 反復を使用しなくても、リリースNとN + 1の作業を重複させることができるため、これは問題になりません。しかし、私が理解していることから、これはスクラムやXPのような反復ベースのアプローチと互換性がありません。彼らは、すべてのテスト作業がイテレーションに組み込まれ、イテレーションが最後にリリース可能であることを要求します。 これは必然的に次の望ましくない結果のいずれかにつながることがわかります。 （A） QAはリリース候補を確認する時間が必要であり、バグ修正作業が開発者を完全に忙しくしていないため、開発者はイテレーションの終わりにアイドル状態です。 （B）最初のリリース候補の準備が整う前に、QAがすでに機能し始めています。これは、Stack Exchangeで最も推奨されるものです。しかし、テストされた特定のリリース候補がないため、それは私の会社がQAとして理解しているものではありません。そして、すべてを壊す「小さな変化」は、気付かれずに導入される可能性があります。 （C）バグは次の反復に引き継がれます。これはStack Exchangeでも推奨されます。私はそれがまったく解決策だとは思わない。基本的に、バグ修正が行われるたびに、新しい未検証のコミットが同じブランチに追加されるため、検証済みビルドが取得されないことを意味します。 このジレンマから抜け出す方法はありますか？

17 agile  teamwork  qa  sdlc 

私の雇用主（開発者ではない）は、CASEツールが開発プロセスとドキュメントの改善に役立つと考えています。それについては定かではありませんが、私たちはローカルクライアント向けのモバイルバンキングソリューションを構築する5人の開発者から成る小さなチームです。CASEツールは購入する必要があるため時間とお金の無駄になり、慣れるまで時間がかかり、モデリングや作業のために効率的に作業する必要があると思います。コード生成は別の問題です。CASEで生成されたコードは、優秀な開発者が作成したコードほど優れていないと思います。 アジャイルの原則を守り、パターンを設計し、TDDを使用し、コードをクリーンに保つと思います。私たちは良いはずです。そして、分析と設計に関しては、ホワイトボード上の単純なUMLダイアグラムがトリックを行うはずだと思います。ドキュメントは適切で重要ですが、できる限り少なくする必要があります。ドキュメントに集中してコードを忘れてはなりません。これは私が思うことです。 私は正しいですか？または、雇用主の声に耳を傾け、適切なCASEツールの調査を開始する必要がありますか？

17 agile  development-process 

私たちは誰もがアジャイルな方法でやろうと言っているプロジェクトを持っていますが、アジャイルとは何かを明確に理解しているとは思いません。 以前のプロジェクトでは、計画会議を開いてから、製品バックログを定義し、2〜3週間のスプリントで開発者に作業を割り当てました。毎朝、スクラムミーティング（毎回1時間半行われているように見えた）があり、その後、各開発者がスクラムミーティングに参加しました。スプリントが終了し、完了していない作業が次のスプリントに追加されるまで、誰もテストを作成しませんでした。 開発者はお互いに話をすることはほとんどなく、開発に関与するTDDはありませんでした。実際、ほとんどの開発者は最初に仕様を持っていて、スプリントがアレンジされた2週間または3週間だけそれを使いました。クライアント/ステークホルダーとのコミュニケーションはほとんどありませんでした。 通常、QAは数か月後に関与し、それまでに要件が欠落していることがわかりました。これにより、必要な作業量がさらに増加し​​ました。明らかに、フィードバックループはありませんでした。 だから私の質問は、どこで間違ったのか、そしてチームが同じ間違いをするのをどのように防ぐことができるのかということです。

17 agile