アジャイルは「研究フェーズ」に必要な時間をどのように見積もりますか？
canonical agile development によると、問題の解決策を実装する前にエンジニアが行うべき適切な学習量はどれくらいですか？
エンジニアは、特定のトピック（圧縮など）を知らないために実装を開始できないことを知っている場合は、必要なことを学び、ソリューションを実装します。
明らかに、このトピックをより深く理解することで、 could はより良い実装になりますが、俊敏性が犠牲になります。反対に、エンジニアがトピックについてほとんど学んでいない場合、彼女が実装するのが著しく不十分または壊れており、近い将来または近い将来に顧客に悪影響を与える危険性があります。多くの調査が必要ない場合もあれば、最上級の開発者でさえほとんどまたはまったく知らないトピックに開発者が直面する場合もあるため、この質問への回答には、両方の状況に対応するスケーラビリティの要素が含まれます。
このスケールのどちらの端に向かって、もしあれば、アジャイルのガイド原則はエンジニアを導きますか？または、アジャイルはこれをスライドスケールとして残しますが、所与の状況では答えが異なる場合がありますか？
言い換えると、アジャイル開発の研究がいつ/どのように行われるのかではありません、さらには、トピックの学習に費やす「適切な」時間を見積もる方法ソリューションの実装に移る前の調査フェーズ。
アジャイルチームは、学習が必要な場合に 研究スパイク を検討する場合があります。
ただし、そのチームは、調査にかかる時間を検討する際に、リード開発者の判断を尊重する必要があります。実際、調査の急増の期間は、対象となるユーザーストーリーの複雑さとチームのスキルレベルに完全に依存しています。
アジャイルを貫く基本的なテーマは、チームが快適で責任感を持って前進できるように「x」を十分に実行する必要があるという概念ですが、それ以上ではありません。これは、設計、文書化、テスト、調査など、ソフトウェア開発ライフサイクルの多くの側面に適用されます。
これらのいずれかに任意の厳密なタイムボックスを配置する（「この機能のコーディングに最大4時間かかりますが、それ以上は費やさない」）ことは、それほどアジャイルではありません。 4時間後、機能が完了したことに不安を感じる場合はどうなりますか？次の機能に進むのは無責任です。
同様に、調査時間を検討してください（「この機能の調査には最大4時間かかりますが、それ以上はかかりません」）。 4時間後、設計上の決定を行うことに抵抗がある場合はどうなりますか？チームが気に入らないデザインにコミットするのは無責任です。
ただし、明らかに、特定のテクノロジーのすべての機能を習得して、それに慣れる必要はありません。研究者は、十分な時間をかけて、責任ある意思決定を行うことができると感じるべきです。それ以上でもそれ以下でもありません。
私がアジャイルで働いていたとき、私たちは「テクニカルスパイク」と呼ばれるものを使ってこの種の作業を処理しました。
コンセプトはシンプルです。スプリントに一定期間を置いて、手元にある技術的な問題（チームにとって新しい特定のテクノロジで機能するために必要なことなど）を調査します。次に、これを見積もりのある人に割り当てます。この見積もりは、スプリント計画の一部になります。
これは本当にうまく機能します。または、少なくとも、特定のAPIを使用してタスクを実行することを調査するために、それをどのように使用していたかというコンテキストで実行されました。確かに制限があります-学習タスクが大きすぎる場合（C++を最初から学習する場合や、そのようなクレイジーなものなど）はうまく機能しません。
"アジャイル"はこれについて具体的には何も述べていませんが、このようなことはチームによって最もよく決定されると明確に述べています。このようなことを指示した場合、それは"Agile"と呼ばれません。
指定できるアジャイルはアジャイルではありません。
ジュニア開発者とシニア開発者の速度は、チーム全体の速度に考慮されます。したがって、単一のメンバーが知識を欠いている場合、これは違いはなく、速度が調整されると非常に迅速に反映されるはずです。チームの上級レベルの開発者がいて、特定のタスクに取り組む可能性が最も高いのは誰かを知っている場合、見積もりは立ち上げ時間を考慮に入れる必要があり、速度に目立った影響はまったくありません。
チーム全体がトピックを学習する必要がある場合、上級レベルの開発者は、トピックの複雑さに基づいて、立ち上げ時間の量を一貫して予測する必要があります。これは、仕事で物事を学ばなければならない以前の経験によるものです。つまり、学んだ能力です。
結局のところ、最悪のシナリオは、速度が予期せず低下し、チームがスプリントからスプリントへの期待値を再調整して下げる必要があることです（もしあれば）。そうすれば、期待される速度はすべての関係者によって合意されます。この学習曲線が克服されると、速度が増加し、コミットメントの調整が再び上方に移動する可能性があります。