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

誰もがこのようなことを経験したと確信しています。プロジェクトを持っているクライアントと会議に参加します。彼らは念頭に置いて/いくつかの要件と彼らが欲しい/必要なもののあいまいな理解を持っていません。この時点で、2つのオプションがあるようです。 1）ユーザーに、「わかりました。まだ説明することさえできなければ、私はあなたのために何かを構築することはできません。あなたが望むものを知ってから数週間で一緒に戻ってみませんか」。 2）ユーザーと数回会って、良いole Socraticの方法でユーザーをガイドすることで、ユーザーが望むものを理解するのを助けます。「Xを追跡する必要がありますか？」、「Yはどうですか？」、「機能Zが必要ですか？」 最初のオプションでは、他の人の仕事をしたり、精神力を獲得したりすることはありませんが、ユーザーは一貫した仕様をあなたに決して提示しないかもしれませんし、期限が近づき続けると永遠にかかるかもしれません。2番目のオプションでは、ビジネスアナリストになるために多くの時間を浪費し、おそらく二度と使用しないビジネス知識を頭の中に詰め込む必要がありますが、次のような仕様が出てくる可能性が高くなります。理にかなっています。 私にとって、これは開発の最も困難な側面の1つであり、この感情の中で私は一人ではないと感じています。あなたの経験では、これらのオプションのどれがよりよく機能する傾向がありますか？

16 requirements  planning  specifications 

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

15 agile  scrum  planning 

1週間のスプリントのスプリント計画に5時間以上かかりました。それは多すぎるようです。 ほとんどのチームメンバーはシニアではないため、スプリント計画で詳細を議論します。そうしないと、実装中にミスが発生し、スプリント中に再設計されます。 これにどう対処しますか？ 1週間のスプリントあたりわずか2時間の長さに合わせるために、計画中にどの程度詳細に議論する必要がありますか？

14 agile  scrum  planning  sprint 

スプリントで多数のユーザーストーリーを計画しており、1つの候補ストーリーがチームに何かを提供する外部プロバイダーに依存している場合。たとえば、オンラインサービスプロバイダーが新しいAPI呼び出しをシステムに追加したり、システムなどでテストアカウントを有効にしたりします。 あなたはそれが「もうすぐ」来ることを知っています。 あなたは先に行くと、彼らはあなたがあなたの物語を完了するための時間が必要であるものを提供します望んでスプリントに話を追加してくださいまたはあなたはそれが可能な状態になりますし、あなたがしても、すぐに始めることができます知っているとき、あなたは次のスプリントまで待つんできるだけ早く話を始めないことを意味します。 前者が依存関係のために失われた「未学習」のストーリーポイントをどのように処理するか？部分的なクレジット（eek！）またはあごにそれを取る。

13 project-management  agile  scrum  planning 

私は、長年取り組んでいたPHPフレームワーク（MVCを使用）を完全に書き直すことにしました。これまでの私の問題は、フレームワーク自体の設計を気にせずに、アイデアを思いついてチケットとしてTracに投入し、後で追加することでした。時間が経つにつれて、これはいくつかの問題を引き起こし、書き直しが役立つと思いますが、どこで計画を始めるべきかわかりません-Tracを使いたくないことは知っています。チケットとマイルストーン-しかし、他に何が必要ですか？ 私は本当にこの書き直しを徹底的に計画し、必要なすべての機能、それがどこに行くのか、そしてそれが他のすべての部分にどのように接続するのかを詳細にしたいのですが、このレベルの計画の経験はありません。何かアドバイス？役立つプログラムはありますか？私はTracにうんざりしています。 設計文書が必要になることは知っていますが、従うべきレイアウトはありますか？また、バグ追跡、チケット、マイルストーンなども必要になりますが、Trac以外では、それが何が良いのかわかりません。必要なものはもっとあると思いますが、何がわからないので、どんな助けでも感謝します。

13 php  project-planning  planning 

注：ここでコーディングのヘルプは必要ありませんProgrammers。理由があります。Javaの（単なる）理解ではなく、プログラムの計画/作成スキルを向上させたい。 ここでこのLARPゲームのスキルに基づいて、任意のカテゴリシステムを持つツリーを作成する方法を見つけようとしています。私の以前の試みは、スキルがカテゴリーでもあったかどうかについては愚かでした。それをコーディングしようとするのは面倒でした。自分のツリーを描くと、自分の「葉」だけがスキルであることに気付き、他のカテゴリにはカテゴリとしてラベルを付けました。 私が望んでいるのは、モデルとビューを分離しようとするツリーを作成し、任意の親に任意のタイプの子ノードを（編集/レンダリングの別の方法で）追加できるようにする方法です。 NBここにあるものはすべて、財産のように思える場合でも、スキルとして購入されます。エンドユーザーは、これを購買スキル（紙のATMで行う）と見なすため、同じページにすべて表示する必要があります。 ツリーの説明：ツリーは、ハードコードされた最高レベルのカテゴリ（武器、物理的および精神的、医療など）のセットで「生まれ」ます。このことから、ユーザーはスキルを追加できる必要があります。最終的に、彼らは「片手剣専門化」スキル（アイテムではない）を追加したいと考えています。そのためにはWeapons、選択One-handedした状態で「追加」をクリックし、その子に表示されるコンボボックスノードから選択し、もう一度追加をクリックして、表示されるその子ノードのテキストフィールドに名前を入力します。次に、もう一度追加をクリックして、そのリーフの「レベル」または「ティア」を追加/指定します。最初に習熟し、次に専門化（例えば）。 もちろん、別のスキルを購入する場合は、リーフへの完全に異なるルートです。武器の例で行ったように、ツリーの同じレベルにコンボボックスは必要なく、その背後にある他のロジックも必要になる場合があります。これは、プログラミングは言うまでもなく、頭を悩ませている問題です。一連のクラスを作成し、それらをどの順序でアタッチするかを指定せずに、すべてを適合させる方法。 この種のツリーをコードで記述するのに適したシステムは何ですか？私が見た他のすべてのJTreeの例には、予測可能なパターンがありますが、私の場合はそうではありません。これをすべて「リテラル」でコーディングする必要はありません。どのタイプ（コンボボックス、テキストフィールドなど）の子ノードの長いリストをどの親で許可する必要があります。抽象クラスを使用する必要がありますか？インターフェース？ 上にリストされていない、異なる動作をする他のスキルを追加するときに、この種のオブジェクトのクラスターを拡張可能にするにはどうすればよいですか 使用する適切なシステムがない場合、この種のことを行う方法を決定するための適切なプロセスはありますか？ 私の頭の中の歯車が回っています： 私はいつもする必要があります： 親を確認する 親に基づいてオプションを提供する 私はこの共通性のskillために、スキルとカテゴリの一般的なメソッドを定義/概説する何らかの抽象/インターフェイスクラスが必要だと考え始めています。（できれば）ルールとオプションをデータベースに入れて、そこから読み込めます。問題は、抽象メソッドまたはインターフェイスメソッドと、それを実装する方法との間の問題です。

12 planning  trees  extensibility 

親愛なる仲間のプログラマー、 学術研究が関係する場合、どのように「ソフトウェア計画」を行いますか？そして、副次的に、ソフトウェアを書くことは家を建てるようなものではなく、小説を書くことに似ていると上司にどのように説得しますか？ 厄介な詳細は以下のとおりです。 私は、研究室で働く小さな開発チームを担当しています。ある日公開することを目的にソフトウェアの開発を始めました（つまり、それを売ってお金を稼ぐ）。このようなソフトウェアは、とりわけ、少なくとも2つの独立した研究ラインに依存しています。つまり、少なくとも2つの博士号があります。願わくば、いつか私たちが必要とするものを実際に実装してくれる候補者です。 メインソフトウェアは、グラフィックレンダリング、ソフトボディの変形など、開発者が処理できる他のより具体的なリソースにも依存します。 上司から、プロジェクト全体の仕様、要件、血まみれのガントチャートを書くように頼まれました。私は研究部分についての手がかりがなく、そのような研究はソフトウェアの基本であるという事実に直面して、彼は「仮定を立てる」と言った。議論を明確にするために、彼は博士号を持つ教授です。学生は必要な研究を考え出す必要があります。そして、彼は厳密にエンジニアリングのバックグラウンドから来ています。最初にすべてを計画し、仕様を書き留めてから、「最後の部分」であるコードを書き留めます。 私が今していること： 製品の機能を分解しました。事実上、各「機能」は個別の製品です。 各機能は、前の機能の上に構築されています。 機能（A）が機能するプロトタイプを作成すると、チームは次の機能（B）の作業を開始できます。AのQAは完了します（お金が許せば、より多くの人を持ち込むことができます）。 研究に依存する機能は、最後に来る。（その後で、うまくいけば、研究の一部は、完成されたときにはまだ大きな問題です）。 また、数か月後に予定されている「バージョン1.0」の開発にSCRUMを使用するようにチームを設定しました。この期限は、合理的な仮定に基づいて設定できます。必要な機能をすべてリストし、可用性を数え、合理的な見積もりを出しました。 私の質問は次のとおりです。 上司を喜ばせながら、ドアから何かを取り出すにはどうすればよいですか？ 私たち-開発者-ができるかどうかの手がかりがないものの仕様を書くにはどうすればいいですか？（一部のタスクに使用するライブラリをまだ決定していません。必要に応じて決定します） まだクライアントも投資家もなく、多くの利益と約束があるのに、どうすればその要件を取得できますか？ 世界で平和を得るにはどうすればいいですか？ 私の質問の少なくとも1つが答えられると確信しています:) ps：潜在的な投資家がこれを発見すると裏目に出るかもしれないので、私はこれを匿名で書いています。ご理解いただければ幸いです。しかし、私はこの「真実を隠す」という考え方が好きではないと言う必要があります。このプログラムは多くの人に利益をもたらす可能性があり、これについて公然と話すことができない（私の名前と私の評判を付けて）検閲のように感じます。しかし悲しいかな、私はあなたの提案をもっと気にしています。

11 planning  research 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私の（技術者ではない）同僚が、現在計画している新しいプロジェクトのガントチャートで脅迫しています。これは私たちに何を提供する可能性があり、それは有用なツールになりますか？

11 project-management  planning  gantt-chart 

計画は非常に困難です。私たちは自然に自分の将来を予測するのが得意ではなく、多くの認知バイアスが問題を悪化させています。グループ計画はさらに困難です。不完全な情報、一貫性のない状況の見解、およびコミュニケーションの問題は、困難をさらに悪化させます。 アジャイルメソッドは、グループ計画を整理するための1つのフレームワークを提供します。全員に見える計画（ユーザーストーリー）を作成し、それを小さなチャンク（スプリント）に分割し、レトロスペクティブ分析を提供して計画を改善します。しかし、これらのプラクティスをサポートするための優れたツールを見つけることは難しいことです。 これらの目標を達成するためにどのソフトウェアツールを使用していますか？なぜそのツールを使用しているのですか？どのような成功はしているあなたは、特定のツールを使用していましたか？

11 tools  programming-practices  planning 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 私のチームは4人の開発者で構成されています。すべての味付けと熟練。それらの1つは、Planning Pokerで見積もりを下す前に、ストーリーの技術的な解決策を定義することを主張する、言葉の多い、意図的なチャップです。彼は、合意された技術的解決策の大まかなアイデアがないかどうかを見積もることを拒否します（これは合理的に聞こえますよね？）。 問題は、見積りセッションが終了するまでに時間がかかるということです!! あなたの経験では、プランニングポーカーをプレイするとき、このような性格をどのように扱いますか？

10 agile  planning 

私たちは最初のスプリントの真ん中にいて、何かが明け暮れています。 この2週間の反復で理想的な114時間を計画し、最初の週の終わりにスプリント全体を完了しました。今何をすべきか？「本」は、バックログから次の優先度の高いアイテムを取得する必要があることを示しています。しかし、それらをバーンダウンチャートに追加するにはどうすればよいでしょうか。それらを最初から存在しているかのように説明するために書き直しますか？あるいは、それらの作業を開始する日にy軸にそれらの推定値を単に追加します（90度の角度ジャンプを示しています）。 どんなフィードバックでも大歓迎です！

10 scrum  planning 

ここで私は、比較的小さな新しいソフトウェア開発プロジェクトの範囲を定め、見積もっている最中です。私は、お客様から提案されたユーザーストーリーに目を通し、それぞれに対してタスクを配置しました。見積もりと、タスクがどのように達成されるかについての簡単なメモを付けました。受け入れ基準があります。すべては世界と良くなるべきです。 予定していた作品を見ていると、何か足りない部分があることに気づきました。機能を追加できるものをセットアップするだけの初期費用がかかります。特定の1つのユーザーストーリーではなく、すべてのユーザーストーリーに属するもの。 たとえば、このアプリケーションの一部は、XMLを解析するサービスです。ユーザーの観点から見ると、XMLの内容に応じてさまざまな処理を行う必要がある特定のストーリーがあります。実際にXMLパーサー（ファイルを探し、それを読み取り、内容をどうするかを決定する前に関連データを取り出すビット）を書くことは、これらすべてのストーリーの一部です。インストーラーなどを使用してWindowsサービスにラップする場合と同様です。これは、ユーザーに直接関係のない開発者中心のタスクです。 この特定のアプリケーションのもう1つの関連する例は、このアプリの機能に役立つ貧弱なレガシーコードのブロックを取得して書き換えることです。繰り返しますが、これはユーザーに直接の結果はありませんが、必要な作業です。ユーザーストーリーに焦点を当てたプロジェクト計画の中で、この作業の計画と実行はどこで「ライブ」ですか？ 「開発者として、私はしたい...」というユーザーストーリーを書いて人々がこれを解決するのを見てきましたが、他の場所で議論されているように、これはユーザーストーリーではありません。それは開発者のものです。 私（および他の人）がオンラインでTFSのような厳密な管理フレームワークを使用してプロジェクトを計画するのを助けるために、これに対する具体的な答えを探しています。これらは、「利害関係者の物語」や、計画会議でのスクラムチームによるインフラストラクチャタスクの説明への回答で言及されている他のあいまいなメタソリューションを作成する機能を備えていない傾向があります。

9 agile  team-foundation-server  planning  user-story 

私はスクラムミーティングで、開発者がストーリーについて現実的な見積もりを行うことが多いことに気付きました。ただし、かなり単純なストーリーであっても、構成、サードパーティコンポーネントのセットアップ、テスト、最終ビルドに多大な労力が必要であり、システムにはかなりの技術的負債が蓄積されているため、製品の所有者や管理者にとって見積もりが高すぎることがよくあります。 POは次のような見積もりを頻繁に打ち消そうとします。たとえば、「このストーリーには13ストーリーポイント[4日間]が必要です。これは不可能です。これを経営者に説明することはできません。誰かがこれをコーディングできるはずです。 3 SP [4時間以内]で！」その結果、開発者は5または8ストーリーポイント（1.5〜2日）の見積もり（スクラムの見積もりは、単なる予測ではなく、コミットメントと見なされます）にコミットするために腕をひねります。 もちろん、（主にテストと品質に関する）期待を排除する計画がなければ、これらのスプリントは頻繁に失敗します。開発者の見積もりは正直で現実的なものであり、見積もりを打ち負かしても実際に行われる作業に影響が及ぶことはありません。 「誰かがあなたにそうするように強いたからといって、あなたは不可能な約束をするべきではありません！」しかし私の意見では、開発者の仕事はソフトウェアの設計とコーディングであり、交渉や圧力に対抗することではありません！すべての取引のジャックが存在する可能性がありますが、通常は外部の顧客と直接取引しますが、これはオフィス開発者の大多数ではありません！ 私にとって、この実践は、プログラマーをぎくしゃくさせ、絶え間ないスプリントの失敗を引き起こし、現実的な見積もりを妨げるだけでなく、実際の改善点も探します。 スクラムガイドラインはこのトピックについて何を言っていますか、または彼らはそれに何を言っていますか？ 編集：時間をストーリーポイントに置き換えました。私は、タスクの詳細計画ではなく、Planning Pokerとストーリーポイントを使用して最初の見積もりフェーズを参照していました。日/時をそこに置いたのは、このような典型的な対話であり、ポイントではなく時間も含まれていたためです。混乱してすみません！ストーリーポイントの例は、時間の例よりも長い期間を表しています。 編集2現在、専用のスクラムマスターはなく、POは見積もり会議に関してその役割を果たします。したがって、中立的なまたは開発者のスクラムマスターではなく、権威として表示されるため、おそらくロールコンフリクトがこの不適切な交渉を悪化させています。おそらく、これが何もない限り、彼を「マスター」ではなく偏った参加者とすることで修正できます。

9 scrum  estimation  planning  sprint 

私は現在、スプリント中（2週間）で、特定のユーザーストーリーの要件とUXを定義することをデザイナーに課しています。 同じスプリントで、私はこのデザインを実装します。スプリントの計画中、私はこの未定義のユーザーストーリーがどのくらいの時間を要するかについて、かなりの推測をしなければなりませんでした。 今日、ようやくデザインを受け取りました。残念ながら、設計は不完全で曖昧であり、設計よりもクライアントの要件に似ています。ただし、このことから、まだ十分に見積もっていないことがわかります。 さらに悪いことに、これは初めてではありません。最後のスプリントでは、まったく同じことが起こりました。私はそれを振り返ってフラグを立てましたが、スクラムマスターは「それはあなたのための単なる開発だ」と言うのではなく、これを解決する方法の答えがありませんでした。皮肉なことに、バーンダウンが目標に達していない場合、彼はイライラします... 今、私は彼の仕事を成し遂げるためにデザイナーに尋ねる/協力する必要があります。私は他のすべてのタスクを完了しているので、これは私を我慢するでしょう。 だから私の質問は A）スプリント計画で依存関係をどのように処理しますか？編集：ユーザーストーリーのデザイン/ UXが実装と同じスプリントで発生しても問題ありませんか B）今はどのようにスプリントにアプローチすべきですか？現在のユーザーストーリーを再推定し、バーンダウンがバーンアップに変わり、無能/非生産的と見なされるのを確認しますか？または、「デザイナーが適切なデザインを作成するのを助ける」という行に沿って、現在のスプリントに新しいタスクを追加します

9 agile  scrum  planning 

過去5か月間、私たちはスクラムをかなりうまく実装してきました。しかし、我々はせずに3週間離れPRODからですこれまでの任意のエンドツーエンドの統合テストを行います。痛い！私は助けが必要です。これの原因に取り組むことなく（この時点で）、現在のイテレーションを計画する必要があります。これは、マイナーな改良と多くの未知のバグ修正で構成されています。このシナリオをどのように説明しますか？まだ発見されていないバグを修正するための反復をどのように計画しますか？

9 scrum  bug  planning