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

顧客満足の狩野モデルは、製品機能のさまざまなクラスを定義します。それらの中には 必須の品質：これらが実装されていない場合、顧客は製品を受け入れません。 魅力的な品質（喜び）：顧客が最初に期待することさえないが、発見されたときに興奮と喜びをもたらす機能。 魅力的な資質は明らかに多くのビジネス価値を持っています。5.000未満の使用済みフィアットがすべての必須要件を満たす場合、人々は500.000でフェラーリを購入します。 ただし、私が知っているすべてのアジャイルプロセスは、必須の要件を強く支持しています。これらは常に最高の優先度を取得します。アジャイルには魅力的な資質がある場所すらありません。 アジャイルプロセスはソフトウェア開発に非常に役立つと思います。しかし、どうすればそれらを適用して、必須の要件をかろうじて満たす最低限のものだけでなく、楽しい高品質のソフトウェア製品を作成できますか？ 補遺：最初の2つの答えが指摘したように、必須要件に最高の優先順位を与えることは理にかなっています。しかし、私たち（および顧客）は、必要な要件が何であるかを事前に常に知っていますか 私は、最初に高い優先度が与えられた要件が、後で役に立たないとしても、それほど重要ではないことが判明したことを何度か経験しました。したがって、私は、必要な要件に慎重に焦点を合わせるべきではないと考えています。

61 agile  project-management  scrum  requirements 

私は自分自身とチームの人々が実際に毎日何をしているかを追跡する方法に苦労しています。完成したカードを毎週調べることで良い全体像が得られ、スタンドアップは少し助けになりますが、チームの日々の仕事をうまく扱えないと感じています。カードは毎日のスタンドアップで更新されることなく何日間も進行し続けます。一部のエンジニアは、私のチームは最もコミュニケーションが取れていません。 メーリングリストまたは共有のgoogleドキュメントを介してすべての人が記入する何らかの日次記録を実装することを考えましたが、これはかなり面倒で手作業のようです。 GitHubアクティビティを監視することは問題ありませんが、毎日送信する電子メールの数に少し圧倒される場合があります。私はそれのためにダイジェストシステムを構築しようと考えましたが、余裕がある時間はありません。 「進行中」のタスクの作業を測定できるように、チームが毎日行っていることを常に把握するためにどのような戦略を実施しましたか？

61 project-management  agile  time-tracking 

アジャイルアーキテクトの原則を読んで、次の原則を定義しました。 原則＃1システムをコーディングするチームがシステムを設計します。 原則＃2動作する可能性のある最も単純なアーキテクチャを構築します。 原則＃3疑わしい場合は、コーディングします。 原則＃4構築し、テストします。 原則＃5システムが大きいほど、滑走路は長くなります。 原則＃6システムアーキテクチャは役割のコラボレーションです。 原則＃7イノベーションに関する独占権はありません。 この論文では、アーキテクチャ設計の大部分はコーディング段階で行われ、その前のシステム設計のみが行われると述べています。それは結構です。 それでは、システム設計はどのように行われますか？UMLを使用していますか？または、インターフェイスと主要なブロックを定義するドキュメントですか？たぶん何か他に？

59 architecture  agile  large-scale-project 

私が働いているところでは、3週間の反復でスクラム駆動のアジャイルを実践しています。はい、繰り返しが短くなればいいのですが、それを変更することは現時点では選択肢ではありません。 繰り返しの終わりに、私は通常、最終日が非常にゆっくりと進むことに気付きます。実際の作業はすでに完了し、受け入れられています。いくつかの会議（回顧と次の反復計画）がありますが、それ以外はあまり進行していません。 チームが最終日まで勢いを維持するためにどのようなテクニックを使用できますか？欠陥に対処する必要がありますか？とにかく次のイテレーションの作業を早期に開始しますか？他に何か？

56 agile  development-process  scrum 

バグが開かれ、修正され、検証され、閉じられました。1か月後、回帰なしに数回繰り返した後、次のバージョンで再び現れました。 バグの特性が同じであれば、既存のバグID を再度開くか、閉じたバグへのリンクを含む新しい IDを開きますか？

55 project-management  agile  issue-tracking 

あなたの経験（逸話的またはその他）で、アジャイルを非アジャイル組織または会社に導入するための効果的な方法は何ですか？ 更新：アジャイルを導入しようとしたが「撃ち落とされた」ケースについてだれでも話せますか？また、なぜあなたが「撃down」されたのかを振り返って理解していますか？

55 agile  scrum  methodology  culture 

2週間のスプリントの終わりに、タスクにコードレビューがあります。このレビューで、機能する、読み取り可能な関数を発見しましたが、非常に長く、コードの匂いがいくつかあります。簡単なリファクタリングジョブ。 それ以外の場合、タスクはdoneの定義に適合します。 2つの選択肢があります。 このスプリントでチケットが閉じないようにコードレビューに失敗します。チケットを渡すことができないため、士気に少し打撃を与えます。 リファクタリングは小さな作業であり、次のスプリント（または開始前）で小さなハーフポイントストーリーとして行われます。 私の質問は次のとおりです。レビューを失敗するのではなく、レビューの裏からチケットを上げることに固有の問題や考慮事項がありますか？ 私が見つけることができ、詳細コードのレビューを読んだことがあるリソースは、通常、100％または何もありませんが、通常は現実的ではありません。

53 agile  code-reviews 

スクラムを使用した滝からアジャイルへの移行のほぼ中間です。テクノロジー/規律サイロの大規模なチームから、部門を超えた小規模なチームに変更しました。 予想どおり、アジャイルへの変更はすべての人に適しているわけではありません。アジャイルに慣れるのに苦労している開発者は少数です。私は本当に彼らを引き付け、挑戦し続け、最終的には毎日仕事に来ることを楽しみたいです。これらは賢く、幸せで、やる気のある人であり、私は個人的レベルと職業的レベルの両方で尊敬しています。 基本的な問題は次のとおりです。一部の開発者は、主に難しい作業をし、設計を熟考し、潜在的な問題を熟考し、次に他の人との最小限の相互作用のみで問題を部分的に解決する喜びに動機付けられます期間。彼らは通常、高品質のタイムリーな方法で作業を完了します。それらの作業は保守可能であり、アーキテクチャ全体に適合しています。作業に対する相互作用と共有責任を重視する職域を超えたチームに移行し、短い間隔で作業機能を提供することで、チーム全体がその困難な問題を克服するように進化します。多くの人がこれを前向きな変化だと感じています。最初から最後まで問題を抱えて独立してそれを所有するのが好きな人は、そのような仕事の機会を失います。 これは、人々が変化に対して開かれているという問題ではありません。確かに、変化を嫌う少数の人々を見てきましたが、私が懸念しているケースでは、個人は良いパフォーマンスをし、真に変化に対してオープンであり、努力をし、チームの残りの部分がどうであるかを確認します変化し、彼らはそれに適合したいと思う。それは誰かが困難であるか妨害者であるか、または最もジューシーな仕事を買いだめしたいというケースではない。彼らは以前のように仕事に喜びを見いだせません。 これにぶつからない唯一の場所になることはできないと思います。他の人はこれにどのようにアプローチしましたか？あなたが個人的に大きな仕事の塊を端から端まで所有することによって動機付けられている開発者であり、あなたが別の働き方に適応した場合、それはあなたのために何をしましたか？

52 agile  scrum 

私は、大きなバックエンドコンポーネントを備えたAndroidおよびiOS用の新しいモバイルアプリに取り組んでいる開発者です。私たちはこのプロジェクトの3つのスプリントに参加しており、スクラムをそのすべてのセレモニー（洗練、計画、デイリー、回顧など）で使用しています。 2つのスプリントでは、チームは残業と週末に（無給で）働かなければなりませんでした。誰もが一生懸命働きましたが、外部の依存関係と楽観的な見積もりにより、すべてのスプリントストーリーを達成するのに苦労しました。 私の経験では、一部のスプリント中にストーリーの一部が完了しないことはある程度普通であり、次のストーリーで取り組むことができます。しかし、プロジェクトマネージャーは、自分で見積もりを行ったのは私たちのせいだと言っているので、スプリントのすべての項目を完了する必要があります。 これは、私が知らないスクラムの許容可能な/一般的なバリエーションですか？ これに基づいて行動することをどのように提案しますか？

52 agile  project-management  scrum  development-process 

私たちのスプリント計画会議は面白くないだけでなく、実に恐ろしいものです。 会議は退屈で退屈で、永遠にかかります（1日ですが、ずっと長く感じます）。 開発者はそれについて文句を言い、今後の計画を恐れます。 私たちのルーチンはかなり標準的です（優先順位によってスプリントバックログに挿入されるユーザーストーリー>>ストーリーはタスクに分解されます>>タスクは時間単位で見積もられます>>繰り返し）、何が間違っているのかわかりません。 どうすれば会議をもっと楽しくすることができますか？ ... 詳細情報のリクエストへの応答として、さらに詳細を示します。 バックグラウンドアイテムがスプリントキックオフの前に挿入および優先順位付けされないのはなぜですか？ ユーザーストーリーは確かに優先されます。それらをタスクに分解するまで、どれだけ時間がかかるかわかりません！ここの（優れた）回答から、タスクをまったく推定すべきではなく、ユーザーストーリーのみを推定すべきであることがわかります。タスク（ストーリーではなく）を見積もる理由は、ストーリーの見積もりがひどく間違っているためです。しかし、それはまったく異なる質問の主題だと思います。 開発者が文句を言うのはなぜですか？ 会議は長いです。 会議は単調です。ストーリーごと、タスクごと、苦労（はい、苦労）にかかる時間とその内容を推定します。 タスクを見積もると、ユーザーストーリーの推定が無意味に見えます。 会議が長ければ長いほど、部屋に集中できなくなります。集中力の低い同僚ほど、会議に時間がかかります。再帰的なヘイトスパイラルが発生します。人々を集中させるために会議を2日間に分割することを検討しましたが、開発者はそれを聞きませんでした。計画の1日で十分です。これで2つになります。 私たちの問題の一部は、（より正確な推定を得るために）非常に小さな詳細になることです。しかし、おおよその見積もりをするときは、大したことはありません！ 質問を要約するには： 私たちは何を間違っていますか？ 一般的に会議をより楽しくするために、他にどのような方法がありますか？

51 agile  scrum  sprint  meetings  process-improvement 

常にプログラムをペアリングするのではなく、チームでペアプログラミングを選択的に使用します。次のような状況で最適に機能すると思います。 プロジェクトの新しいチームメンバーを増やします（ドキュメントやコードを自分で歩くのではなく）。 ジュニアとシニアの人々が一緒に働くことは（より経験豊富な開発者のスキルとトリックの一部を示すのに役立ちます。また、老犬が時々新しいトリックを学ぶことができます）。 誰かが欠陥を追跡しようとするとき、それはしばしば新鮮な目のセットとペアリングするのに役立ちます。 ペアプログラムを使用するタイミングとその理由 ペアプログラミングを回避する場合 どうして？

51 agile  pair-programming 

ストーリーポイントをバグ修正タスクに割り当てる必要があるかどうかだけを考えています。私たちの問題追跡ソフトウェアであるJIRAには、バグタイプの問題のストーリーポイントフィールドがありません（StoryおよびEpic専用です）。 ストーリーポイントフィールドの該当する問題タイプにバグ問題タイプを追加する必要がありますか？長所と短所は何ですか？スクラムに適しているでしょうか？

50 agile  scrum  bug  user-story 

私たちはスクラムを使用していますが、時折、それが計画されたスプリントでユーザーストーリーを完了できないことがあります。とにかく真のスクラムスタイルでソフトウェアを出荷し、次のスプリントプランニングセッション中に次のスプリントにユーザーストーリーを含めることを検討します。私たちが引き継いでいるユーザーストーリーが部分的に完了している場合、次のスプリントプランニングセッションでどのように正しく見積もることができますか？私達は考慮しました： a）ストーリーポイントの数を減らして、ユーザーストーリーを完了するために残っている作業のみを反映するようにします。残念ながら、これは製品バックログの報告を台無しにします。 b）部分的に完了したユーザーストーリーを閉じて、新しいストーリーを作成して、ストーリーポイントの少ない残りの機能を実装します。これは、そのスプリントで完了しなかったものを遡及的に見る能力に影響し、少し時間がかかるようです。 c）aまたはbのいずれにも煩わされず、スプリントプランニング中に「ユーザーストーリーはXストーリーポイントかもしれませんが、95％が終了していることを知っているので、それが収まると確信しています。」

50 agile  scrum  estimation  planning 

今週仕事で私はまたもや心を動かされました。標準的なアジャイル、TDD、共有所有権、カード上のいくつかのユーザーストーリーを超えて何も計画しないアドホックな開発方法論を経て、実際には何もせずにサードパーティの統合広告の吐き気の技術性を口頭でかみ砕きます思考またはデューデリジェンスと、すべての製品コードを過去数か月の間に誰かの頭に浮かぶ最初のテストにアーキテクチャ的に結合することで、リリースサイクルの終わりに到達し、開発中の外部から見える主な機能を見ることは遅すぎます使用、バギー、迷路的に複雑になり、完全に柔軟性がなくなります。 このプロセス中に「スパイク」が行われましたが、文書化されることはなく、単一のアーキテクチャ設計は作成されませんでした（FSがなかったので、何を開発しているのかわからない場合、どのように計画または調査できますか？）-プロジェクトはペアからペアに渡され、それぞれが一度に1人のユーザーストーリーのみに焦点を当て、結果は避けられませんでした。 これを解決するために、私はレーダーから飛び出し、（恐ろしい）滝に行き、計画し、コード化し、基本的にペアを交換せず、単体テストではなく、単体テストではなく堅牢なアーキテクチャと仕様に焦点を当てましたすべてがピン留めされると、後で表示されます。コードは今でははるかに優れており、実際には完全に使用可能で、柔軟で高速です。特定の人々はこれを行うことに本当にreallyしているようで、アジャイルの神聖なプロセスに反するので、私の努力を妨害するために（おそらく無意識に）邪魔をしています。 それでは、開発者として、自分の作業を計画することは「非アジャイル」ではないことをチームにどのように説明し、アジャイルプロセスに計画をどのように適合させるのでしょうか。（私はIPMについて話しているのではなく、問題に座って、問題に取り組む人なら誰でも何ができるかを十分に詳細に解決する方法を示すエンドツーエンドの設計をスケッチすることについて話している使用するアーキテクチャとパターン、および新しいコードを既存のコードに統合する場所）

50 agile  planning 

私たちの開発ショップはもっとアジャイルなプロジェクトを本当にやりたいと思っていますが、クライアントを乗せるのに問題があります。多くのクライアントは、予算と期限を望んでいます。競合他社がウォーターフォールベースの固定期限と固定価格を考え出すとき、アジャイルプロジェクトでクライアントを売るのは難しいです。固定数が悪いことはわかっていますが、クライアントはそれを知りません。そのため、価格や期限を修正することはできませんが、競合他社は修正できるため、クライアントにとって見栄えが悪くなります。 それでは、アジャイル開発手法を使用するプロジェクト、またはそのような手法を使用して開発された製品を販売チームに成功させるにはどうすればよいでしょうか？私が見つけたすべての情報は、プロジェクト管理と開発者に焦点を当てているようです。

49 agile