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

4人の開発者から成るチームがアプリケーションを構築している状況を想定しましょう。テスト段階では、バグがユーザーから報告されます。誰がそれらを修正する必要がありますか？エラーのあるコードをコミットした人、それとも無料の人？ アジャイル開発で好ましいアプローチは何ですか（スクラム）？

17 agile  debugging 

スクラムには、チーム、プロダクトオーナー、スクラムマスターの3つの役割が定義されています。プロジェクトマネージャーはいません。代わりに、プロジェクトマネージャーの仕事は3つの役割に分散しています。 例えば： スクラムマスター：プロセスの責任者。障害を取り除きます。 プロダクトオーナー： ROIを最大化するために実行する作業のリストを管理および優先順位付けします。すべての利害関係者（顧客、利害関係者）を表します。 チーム：自分自身で作業を見積もり、配布することにより、作業を自己管理します。自らのコミットメントを満たす責任があります。 したがって、スクラムでは、プロジェクトの成功を担当する責任者は一人もいません。コマンドとコントロールの構造はありません。それは多くの人々、特にアジャイル手法に慣れていない人々、そしてもちろんPMを困惑させているようです。 私はこれとスクラムの実装を壊す可能性があるものの1つだと思うので、これとあなたの経験に本当に興味があります。 プロジェクトマネージャーは必要ないという点でスクラムに同意しますか？そのような役割はまだ必要だと思いますか？どうして？

17 project-management  agile  scrum 

アジャイルソフトウェア開発は、最近ではかなり楽しい流行語になりつつあります。 開発者として、私は反復開発の実際的な価値を理解していますが、（ほとんどの場合）ソフトウェア開発へのアジャイルアプローチを採用することは開発者の選択ではありません。トップダウンの管理選択です！クリスタル、アジャイルメソッド、dsdm、rup、xp、スクラム、fdd、tddのいずれであっても、名前を付けてください。開発者の選択ではありません。 世の中のすべてのマネージャーにとって、（私の経験では）ほとんどのマネージャーがコードの一部に触れさえしていないときにアジャイル開発を選択する最大の理由は何ですか？

17 project-management  agile  management  project  scrum 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 かなり最近、開発者として働き始め、以前はシステム管理者として働いていました。 アジャイル機能を使用するソフトウェア開発チームの私の理解は、「実装する必要がある」コミュニケーションは、製品の所有者から開発者への一方向でほとんど発生するということです。開発者は、技術的負債について製品所有者に懸念を表明することができますが、機能のアイデアを思い付くことは、主な責任の1つではありません。 私が働いている会社は別の見方をしています。開発者は、自分のチームの製品所有者に行って機能のアイデアを提案するだけでなく、他のチームの製品所有者にそのチームの製品に貢献する何かがあると思われる場合は行ってください。アイデアは、私たちはすべて1つの大きなチーム<会社名>であり、すべての開発者は、自分の専門知識を使用して、役立つと思われる機能をプッシュする必要があるということです。 より良い言葉がないため、そのようなアプローチは「通常」ですか？私は消極的すぎますか？イニシアチブを取り、製品所有者にアイデアを押し出すべきですか？逆に、会社はそれを完全に間違ってしまったので、他の場所で雇用を探すべきですか？

16 agile  product-owner 

高度にサイロ化された「一匹狼」の開発部門構造で2年以上働いた後、アジャイルスクラムを採用しています。すごい。私はアジャイルが好きです。開発者として、無数の利害関係者が昨日プロジェクトを終えた後、プロジェクトをスローダウンすることなく、集中して忙しく生産的になります。 しかし、現在の「モデル」と対比してSCRUMに移行する側面が1つあり、開発部門以外の人は少しでも好きになれないと思います。それが、「待機中」に小さな変更を行う現在の能力です。私たちの開発の大部分は、社内での消費のみを目的としており、ほぼ全員が同じ建物内にいます。そのため、他の部門のリーダーまたはマネージャーが特定のアプリケーションの「コードベースの所有者」に来て、小さなものを要求することは長年にわたって一般的な慣習でした（それほど小さくはありませんが、これらの「ドライブバイ」に基づいた週プロジェクト）。私たちの上司でさえ、彼に持ち込まれたものをこのように中継することがあります。非常に頻繁に、その時点で問題のコードベースで作業している場合、ソースファイルをポップアップ表示するだけで、 基本的なアジャイルSCRUM方法論では、これらの調整は、欠陥（以前に消費したストーリーで指定された要件を満たしていない）または新しい小さなストーリー（記載されているすべての要件を満たしましたが、それらの要件は不完全、曖昧、または不正確でした） 、またはユーザーが新機能を見た後に配信後に変更されました）。どちらにしても、大半はないがほとんどゼロで、1-ポインタとなり、比較的低い優先度（システムは、現在の状態で使用可能ですが、それは次のようになりそうならば...ずっとクーラー）であることが、彼らがそうなって、バックログをトップダウンで操作するときにスプリントに持ち込まれます。 この可能性は、他の部門によるアジャイルプロセスへの積極的な反対の源として開発者会議で提起されました。これはIMOにとって有効な懸念事項です。POの背後にある利害関係者は、すべてが同じ視点を持っているわけではないため、最も重要なことについて常に同意するわけではありませんが、最終的な決定を下すのは通常マネージャーだけです。製品バックログに表示されます。 その後、暫定的に「キャンディジャー」と呼ばれる解決策が提案されました（別の用語は「グレービーボート」でした）。さまざまな部門の「リトルガイ」によって要求された小さな調整。既存のストーリーの欠陥ではなく、チーム内のコンセンサスまたは称賛により、開発者の1日の半分以下で済むと推定されます。エンドユーザーの意見では、ユーザーエクスペリエンスに対する即時の重要なプラスの影響が、プライマリバックログと並行してリストに追加されます。それらは「ストーリー」として識別されますが、優先順位付けの対象となる「大きな」ストーリーの主要なバックログとは別に保持されます。スプリントの通常の進行中にいつでも、これらの調整のいずれかを行うことができるシステムの領域で作業している場合、微調整を簡単にすることで、スプリントに微調整を加え、より大きなストーリーと一緒にコーディングできます。これをする大きなストーリーやその他のコミットされた作業の完了を危険にさらしてはなりません。POはこのリストにもアクセスでき、微調整を含む基本機能に触れる今後のユーザーストーリーに取り組んでいる場合、要件としてストーリーに組み込むことができます。その他。これにより、微調整がより早く実行される可能性が高くなると考えられていました。 これにより、スクラムマスターによる「ええと」のトレーニングが行われ、私たちの間に反応が生じました。バックログが1つあります。2つのバックログは、どの＃1アイテムが本当に最も重要であるか、どのリストのアイテムが実際の速度を決定するか、2つのバックログのうちどちらが実際に属するかという問題を紹介しますどちらか一方に勝手に）。「プロセスを機能させる」と私たちは言いました。変更がエンドユーザーにとって本当に重要な場合、彼らは部門長が時間/お金の決定を行うのに十分な騒ぎをし、バックログのトップに対する開発チームの意識にぶつかるでしょう。 私は床に質問を投げかけると思った：あなたの意見では、「一口サイズ」の物語の平行リストは、小さく、有用であるが最終的には優先度の低い変更をより速くすることに価値があるか、それとも全体的に良い決定ですか？それらをメインのバックログに組み込み、スプリントへの組み込みを基本プロセスで管理するにはどうすればよいですか？

16 agile  feature-requests  product-backlog 

ウィキペディアによると、アジャイルは「RAD」の一種であり、これは間違っていると思います。私が知っていることから、アジャイルはRAD自体が90年代に成功しなかったために開発されました（変更にはあまりにも厳格です）。それとも私は間違っていますか？ （備考：どうやらアジャイルソフトウェア開発に関するWikipediaの記事は、間に改善されたが、それだけで一覧表示されますRADをないスーパーセットとして、アジャイルの前身として）。 本Radical Project Management（Thomsett）からの参照 「..RAD、アジャイル、オブジェクト指向などの新しい開発の流行...」 CISA認定情報システム監査員： ..2 つの代替ソフトウェア開発を認識しています。メソッド：アジャイルで迅速なアプリケーション開発 ソフトウェアのアジャイル管理： アジャイルメソッドは、主にRADの軽量アプローチから派生しています。 ソフトウェア推定のベストプラクティス： swの主な方法。開発者 次のように要約できます 。1.ウォーターフォール.. 4. RAD 5.アジャイル この質問のポイントは次のとおり です。アジャイル型はRADですか、それともスタンドアロン開発アプローチですか？

16 agile  development-process  rad 

あなたの経験では、スプリントプランニングミーティング（スクラム）の期間はどれくらいですか？8時間？それとももっと短く（簡潔に）、スプリントの一部としてさらなる議論を計画すべきですか？私たちのスプリントは10日間です。

16 agile  scrum  planning 

興味深いことに、メディアがどこにあるかを見るために、この質問をそこに投げ出したいと思います。 過去12か月で、TDDとソフトウェア開発におけるアジャイルの価値の多くを取り上げました。私はソフトウェアの開発がどれほど良くなったかに圧倒され、それらを原則から外すことはありませんでした。まで...私は年間の持ち帰り給与を倍増する契約の役割を提供されました。 私が参加した会社は特定の方法論を踏んでおらず、チームはコードの匂いやソリッドなどのことを聞いていませんでしたし、チームでさえもしていないなら、TDDに時間を費やすことはありませんでした実際にユニットテストを見ました。売り切れですか？いいえ、完全ではありません...コードは常に「ボブおじさんの教えに従って」「きれいに」書かれ、SOLIDの原則は必要に応じて私が書くコードに常に適用されます。しかし、テストフレームワークを作成したとしても、テストフレームワークを正しく使用/保守することはありませんでした。 それを例にとると、開発者は個人的にお金/その他の利益のために職人技の原則を落とすべきではないという点を教えてください。これは、自分のニーズ、ビジネスニーズ、職人技などのためにどれだけ関心があるかについて、非常に個人的な意見になり得ることを理解しています。しかし、たとえば、テストチームは、プログラミングの単体テストを理解するのではなく、私がやったように自分自身を許すことができるでしょうか？あなたが落とすものがあることを考えると、通常はあなたが落とすものを補うビジネスに等しい費用があるはずです-できれば、もちろんあなたがあなた自身のポケットを並べてコミュニティ/社会的コラボレーションではなく）。 お金を2倍にして、RADに戻りますか？または、歩いて、アジャイルをしている人を探して、決して振り返らないでください...

16 agile  testing  unit-testing  tdd  sdlc 

アジャイル以外の方法論に対して誇らしげに認定され、説明責任を実証するための顧客へのセールスポイントとして使用している会社を考えてみましょう。 かんばんやスクラムを、システム全体を壊さずに徐々に導入し、それでもなお説明責任/監査可能であると自信を持たせるにはどうすればよいですか？ これは「スクラムのようなアジャイルな方法論をどのように導入しますか」に関連する可能性がありますが、ここでは、会社がSDLCを誤ったふりをしてSDLCを管理する特定の方法を課しているという事実を回避/回避する方法について疑問に思っています監査証跡を持つ唯一の方法。

16 project-management  agile  development-process  sdlc 

私のチームは最近、私たちの仕事のほぼ1年の計画を立てるプロセスを経験しました。計画を3つのフェーズに分けました。各フェーズにはいくつかの起動が含まれます。 あなたの機敏な点から、これは間違っているのだろうか？私たちは最初のいくつかのステップ以外の設計にあまり時間を費やしていないので、それは悪い考えではないと思います。方向を変えることは可能です。同時に、目先の短期だけで行動しないことは素晴らしいことです。

16 project-management  agile 

私たちのビジネスアナリストとプロジェクトリーダーは、ストーリーとしてのクライアントの要件を教えてくれます。すべてのスプリントプランニングでは、開発者はプランニングポーカーをプレイするよう求められます。 彼らは私たち全員に、「努力」ではなく「複雑さ」を考慮するように頼みました。私たちは本当に混乱しており、会議に時間を浪費しています。ある開発者は、「何を本当に検討したいのですか？この要件（時間の見積もり）で行う必要があるコード/ DDLの変更に関するものですか、それとも要件を理解したかどうかに関するものですか？ しかし、彼ら（ビジネスアナリストとプロジェクトリーダー）は、「要件を理解する」と「カードを調達する」とはどういう意味ですか？ さらに、個々のスクラムチーム用のスライス会議があり、各開発者が各スクラムチームの特定のタスクの時間を見積もります。それで、彼らはPlanning Pokerで本当にどんなことを話しているのでしょうか？ 例を使用してこれを説明できる人はいますか？彼らが「複雑さ」と「努力」と言うとき、彼らが本当に話していることを区別するようにしてください。

15 agile  scrum  planning 

一部のチームメンバーは、作業する可能性が最も高いストーリーが議論されるまで待ってから参加します。それ以外の場合、彼らは自分の携帯電話で遊ぶだけで、耳を傾けません。 どういうわけか私はこの立場を理解しています。Sprintでの開発に役立つとは思われない機能に関する議論を聞くのはなぜですか？ 何をすべきだと思いますか？

15 agile  scrum 

XP（エクストリームプログラミング）、特に同じ画面に2人のプログラマーがいる部分が好きですやっています。 過去10年ほどで、XPスタイルの作業は時代遅れになり、作業方法論であるアジャイルおよび/またはかんばんが採用されたようです。どうして？XPは私にとって非常に優れた作業方法であるように思われ、プログラミングについて多くのことをしているのに対し、アジャイルとかんばんはプロセスに関するものです。

15 agile  extreme-programming  kanban 

私は約3年間アジャイル手法（SCRUM）を使用しており、特に多くのレベル（実装された機能への早期アクセス権を持つ顧客から、機能をテストできるテスターからの短期フィードバックで）それらが実装されるとすぐに、レビューなどを通じて新しいコードに関する非常に早いフィードバックを提供できる他の開発者から。 一方、私は2つの未解決の問題を抱えています。最初の問題については、この質問で説明します。 問題：良いデザインを得るのが難しい コードが乱雑になり次第、リファクタリングを試みます。できる限り単体テストを作成します（これは一般的なバグ、特にリファクタリングの際に役立ちます）。一方で、毎日のコミットで少しずつ複雑な機能を開発し、構造化されていないコードを継続的に再考すると、本当に良いデザインを作成できません。 最近作成した唯一の適切に設計されたモジュールは、別のアプローチをとることで得られました：数日間問題を分析しました（実際に問題に取り掛かる前に数か月間、問題が頭に浮かびました） ）、関係するすべてのクラスとそれらの関係の詳細な設計をさらに数日間スケッチし、その後約3週間作業を中断せずにオフィスに閉じ込めてコード全体を書き留めました。結果は、私がしばらくの間作り出した最高のものであり、バグを見つけたり修正したりするのはかなり簡単で、それ以降は関連する変更を必要としない非常に明確な設計でした。 そのため、これまでは、全体像が魔法のようにプロセスに現れることを期待して、少しずつコードを書き始めるよりも、事前にやりたいことの全体像を把握する方がはるかに効果的でした。私の最善の努力により、小刻みの開発アプローチは常に私をより悪い設計へと導いてきました。 質問：同様の経験がありますか？SCRUMを間違った方法で適用しているのですか、それとも少しずつ開発しても、うまく設計されたソフトウェアを作成したい場合、何に注意する必要がありますか？または、実際のコーディングを開始する前に、デザインユーザーストーリーをスケジュールする必要がありますか？少なくとも平均よりも複雑な機能については、これは良い習慣と考えられていますか？ 編集-注 良いデザインは絶対的なものではなく、それ自体に価値はありませんが、コンテキストに依存するという事実と、手近な問題に十分なデザインを目指すべきであるという事実を知っています。 たとえば、（1）できるだけ早く準備する必要がある、（2）一度だけ使用する、（3）しないという単純なコンポーネントを実装する必要がある場合、良いデザインを（あまり）気にしませんシステムの他の部分（YAGNI）によって使用されます。 コンポーネント（1）が数回使用され、製品のいくつかの異なるリリースで使用される場合、（2）長期にわたって保守および拡張する必要がある場合、（3）それに応じて他の多くのコンポーネントを使用する場合、良いデザインが重要です。

15 design  agile 

私が経験したアジャイル開発の最大の欠点は、開発に携わらない人が、ユーザーストーリー（3〜10人の理想的な人の日）が次のような1〜3文を超えてはならないというマントラに集中することです。 顧客として、フリーテキスト検索を使用して、探している製品を見つけることができます。 この文を与えて、プロジェクトマネージャーは私が開発者として見積もりにコミットし、ストーリーを開発することを期待しています。彼らは、アジャイル開発とは、開発者に提供する必要があるのはこのような文だけであると想定していることです。 アジャイル開発に関する有名な文献が、これが実際に機能するという印象を与えるので、私はそれらを責めません。「Planning XP」の記事ごとに自然言語で2ページのようなものを読みましたが、それだけです。「包括的なソフトウェア」よりも「動くソフトウェア」が好まれるため、このトピックは一般的には避けられているようです。 もちろん、現実には、開発者にそうする機会が与えられた場合、顧客とのインタビューによって、顧客がストーリーに関して持っている要件の長いリストが表示されます。 ANDやORなどのブール演算子が必要です。 すべての用語でファジー検索が必要です。 フレーズだけでなく単一の単語でも検索する必要があります。 基準X、Y、およびZを満たす製品を検索する必要はありません。 結果をソートします。ああ、ところで、ユーザーはオプションa、b、cのコンボボックスで並べ替え条件を選択できます。 技術的な詳細やソフトウェアの設計、実装の詳細についても話しているのではないことがわかります。それは純粋な要件です。話す時間が長ければ長いほど、顧客は実際に彼らが望むものについて多くのことを言うことに気付きます。 しかし、多くの場合、そのような情報が提供されていない状況や、非常に見苦しいやり方で自分自身を見つけます。私がインタビューを行うことも、インタビューを行う立場にある人がその結果を提供することもできません。 マネージャーは、「Lucene検索が必要」などの技術的な詳細を思い付く場合もありますが、製品名だけでなく製品の説明も検索するかどうかを考えたくない場合があります。時々私は彼らがただ怠け者だと思う;） 私にとって、これは私が働いているプロジェクトの最大の問題です（e-business Webアプリケーション、プロジェクトごとに500〜2000人日）。私はこの問題に十分な頻度で対処してきましたが、マネージャーはほとんどの開発者が状況に問題があることを認識しています。しかし、彼らは開発者があまりにも「完璧主義者」であると信じています。彼らは開発者が「常にすべてを指定したい」と悩んでいるようです。 一般的に認められている数字がないため、議論するのは難しいです。反復の長さは誰でも知っています。しかし、ストーリーを見積もり、開発するために必要な要件を誰も知ることができません。 参考資料はありますか？

15 agile  requirements