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

私たちは1つの製品を持つ小さなソフトウェア会社です。 私たちはscrumを使用し、開発者は各スプリントに含める機能を選択します。残念ながら、過去18か月の間に、チームはスプリントのためにコミットした機能を一度も提供していません。 「ソフトウェアは、完了したらすぐに、すぐに、もうすぐに...完了します。チームにプレッシャーをかけたり、より多くの人を投入したりするのには役立ちません。 ...」スプリントの成功率をどのように改善できるかという質問に対して、開発者の1人から同様のフィードバックを受け取りました。ああ、そうです、私たちは回顧展を使用しています。 私の質問は基本的に： 開発者の質の問題を探すのはいつですか？ 独自の作業/機能を選択しても、各スプリントに失敗する場合は、次のように考え始めています。-独自のコードの複雑さを監督することはできません。-または、コードが非常に複雑であるため、誰もその複雑さを監視できません。 何か不足していますか？

124 scrum  planning 

私はコンピューターサイエンスの新入生で、Pythonで実際のプロジェクトを始めました。教授がクラスで提案したペンと紙の方法を使用すると、非常に効率的であることがわかりました。しかし、問題を書き留めることができず、アルゴリズムを紙に書き出すことができないと、本当に遅くなります。ラボでは、宿題を宿舎に戻す必要があるようです。そこに着いてそれを書き出すと、クラス全体を5分ほどでかかった問題を解決します。 たぶん、私が目の前で人々が研究室を解いているのを見るのがストレスになるからでしょう。または多分それはペンと紙の方法です。 私はフォーラムを閲覧していましたが、誰かがプログラムを紙に書かなければならないなら、プログラマーになってはいけないと書いています。実際にコードを入力する前に、プログラムが何をしているのかを確認し、それを自分のやり方で追跡できるようになったときのほうがずっと良いので、本当に心配です。私は何か間違っていますか？ 編集：不明瞭で申し訳ありませんが、紙に書いたとき、問題解決のアプローチ（例の作成、値を含むテーブルの作成など）は実際のコードではありませんでした。紙を使ってアイデアを出しているだけです。

54 algorithms  planning 

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

50 agile  scrum  estimation  planning 

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

50 agile  planning 

ここでストーリーポイントをアジャイル開発に使用し始めていますが、説明するのが難しく、またそれらが何であるかについての明確な答えも見つけることができません。私ができる最善のことは、他のサイト（http://blog.mountaingoatsoftware.com/tag/story-pointsなど）をポイントし、それらが何であるかについて漠然とした一般化を与えることです。私は、他の人が使用するのに役立ついくつかの使用例を含む良い説明を探しています。ストーリーポイントを説明するのに役立つリソースはありますか？

36 agile  estimation  planning 

私は、アプリケーションの書き直しが悪いことについての複数の投稿、プログラマに関するここでの人々の経験、およびこのテーマに関するJoel Spolskyによる準備ができた記事を見ましたが、確固たる証拠や事例研究はありません。Joelが提供した2つの例とここの他の投稿以外に、悪いコードベースで何をし、実際の研究に基づいてどのようにそれを行うかを決定しますか？ 適切な例として、私が知っているクライアントは2つあり、どちらも古いレガシーコードを持っています。彼らは、書き直しが惨事であり、費用がかかり、コードを大幅に改善することが実際にはできなかったため、彼らはそれに合わせてリンプを続けています。リライタがすぐに見つけたように、その顧客は非常に複雑なビジネスロジックを持っています。 どちらの場合も、これらは企業にとって多くの収益をもたらすミッションクリティカルなアプリケーションです。書き直そうとした人は、将来のある時点でレガシーソフトウェアがアップグレードされなければ、レンガの壁にぶつかると感じていました。私にとって、この種のリスクは、成功する道を確保するための研究と分析を必要とします。 これを調査した実際のケーススタディはありますか？実際の研究に基づいたいくつかのベストプラクティス、落とし穴、成功を知らずに、大規模な書き直しを試みたくありません。 あとがき： さて、さらに検索した結果、ケーススタディに関する3つの興味深い記事が見つかりました。 書き換えまたは再利用。彼らはJavaに変換されたCobolアプリの研究を行いました。 もう1つは、ソフトウェアの再利用：開発者の経験と認識に関するものでした。 再利用または書き換えメンテナンスと書き換えのコストに関する別の研究。 最近、このテーマに関する別の記事を見つけました：The Great Rewrite。そこで、著者は主要な問題のいくつかにぶつかったようです。これに加えて、提案された新しいテクノロジースタックを使用し、開発者がそれを拾った速さを測定することによるプロトタイピングのアイデアがありました。これはすべて書き直しの前奏曲であり、素晴らしいアイデアだと思いました！

36 source-code  planning  code-reuse  rewrite 

スクラムチームは、計画会議で開発/インフラストラクチャタスクをどのように考慮しますか？ 一見、エンドユーザーの価値を提供しないため、ユーザーストーリーのようには見えません。 ただし、それらをタスクとして特定のユーザーストーリーに添付することも意味がない場合があります。たとえば、タスクが「Bambooのセットアップ」であるとします。チームが手動でビルドおよびデプロイできるため、ユーザーストーリーを完了するためにそのタスクは必要ありません。そのため、ユーザーストーリーを完了するのにこのタスクは必要ないため、ユーザーストーリーに添付しても意味がありません。 したがって、これは、これらのタスクがユーザーストーリーになることを示唆しています。しかし、その後、チームストーリーがそれらを指し示している場合、プロダクトオーナーがバックログに対して速度を知りたいので、これに奇妙な速度が変更されます。

33 scrum  planning 

多くの企業と同様に、私が働いている会社は、SMARTの目標に基づいたパフォーマンスレビューシステムに移行しています。私のチームは、Extreme Programmingのプラクティスを採用した高機能でアジャイルな開発チームです。私たちの大きな利益のために、私たちのアジャイルプラクティスの採用は、直属の管理職の完全なサポートを持っています。 作業を完了するために、私たちのチームは3週間の反復を利用します。即時の反復を超えて、四半期ごとに一般的な計画を立てています。これから数四半期で達成したことは、当四半期で達成することよりもはるかに厄介であることを意味します。私たちのプロジェクトがどこに向かっているのかは確かに一般的な考えを持っていますが、ここでのキーワードは一般的です。 私自身を含む私のチームのプロジェクト計画メンバーへのアプローチを考えると、具体的、測定可能、達成可能、関連性、および時間制限（SMART）の目標を書くことは難しいと感じています。 SoftwareEngineering.seに関する2つの既存の質問は、私たちの懸念のいくつかに対処するのに適しています。 プログラマーにとって良いSMART目標の例は何ですか？ SMARTの目標はプログラマにとって有用ですか？ ただし、アジャイル開発チームで作業する場合、質問はSMART目標を処理するための詳細よりも一般的な回答を引き出しました。アジャイル開発者として、具体的、測定可能、達成可能、関連性があり、時間制限のある5〜7年間の目標をどのように記述しますか？

29 agile  management  planning  review 

オフィスで、視覚障害のある新しい同僚を見つけました。 私はポーカープランニングの企画を担当しており、新しい同僚はチームのメンバーとして参加する必要があります。素晴らしいポーカーカードのセットがあり、そこにポーカーナンバーが計画されていますが、それはもちろん新しい同僚にとっては役に立ちません。 これまでは、見積もりに名前を付けるだけでこの問題を修正し、新しい同僚に残りの人がカードを置いた直後に見積もりを言うようにし、残りの人がカードを裏返し、見積もりに名前を付けました。 私の質問：このような状況を経験し、より良い解決策を持っている人はいますか？点字ポーカーカードのようなものはありますか？ 現在のソリューションは機能しますが、たとえば点字ポーカーカードを使用することで、これは私たち全員にとって改善できると思います。

24 agile  scrum  planning  project-planning 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私のチームが開発する新しいオープンソース製品に貢献することを考えていました。できるだけ多くのコミュニティからできるだけ多くのサポートを得ることが奨励されていますが、これは多くの時間を費やし、オフィスの外にあるサードパーティがコード品質などに関して順調に進んでいることを確認できます。また、プロジェクトの開始時に、システムの設計、スパイクなどに関してコアチーム内で多くの非公式な議論が行われる可能性があり、これらをオンラインでコミュニティに参加させることは時間がかかり、議論はあまり効果的ではありません。 これにはもっと人間的な側面があり、おそらく検討する必要があります。設計プロセスへのコミュニティの関与を許可することは、プロジェクトの所有権の認識に関しても利点があり、初期の関与がコアの問題を拾う可能性が常にありますチームは気づいていません。 では、質問：オープンソースプロジェクトのどの段階で、コミュニティからの貢献を招待すべきでしょうか？

23 project-management  open-source  team  contribution  planning 

ポーカーを計画することでプロジェクトの見積もりの​​精度が向上するというのが一般的な意見ですが（この質問でその小さなサンプルが実証されています）、このテーマに関して明確な研究が行われていますか？ 具体的には、ポーカーのプランニングが従来の推定手法よりも改善されることを示す非状況情報を探しています。

20 agile  estimation  planning  research 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私は小さなスタートアップ組織のディレクターです。現在、Webアプリケーションプラットフォームを構築している2人のプログラマ（1人は経験豊富、もう1人は経験不足）がいます。 これまでの最大の課題の1つは、計画プロセスです。プログラマーは通常、自分の仕事の計画を担当しますが、私たちは自分で決めた期限を超過し続けます。たとえば、彼らが見積もったタスクは2日かかり、8日かかります。 特定のタスクがどれくらい続くかを正確に推定するための技術的なノウハウが不足しているため、私にとって計画を支援することは困難です。 あなたは何か考えがありますか： これの理由は何ですか、これはプログラマーに一般的ですか？ 計画を立てるために私ができることは何ですか？小さなチームのプログラマーに役立つ方法やツールはありますか？

18 php  planning 

チーム内で初めてスクラムを実装するとき、チームの速度がわからないときに、最初のスプリントにあるストーリーポイントの量をどのように決定する必要がありますか？ これは時間の見積もりに基づいており、後の段階でのみポイントを使用する必要がありますか？

18 scrum  planning 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 クライアントからプロジェクトの仕様を受け取ったとします。そして今、プロジェクトの開発を開始します。通常、最初のモジュール（通常はユーザー登録）から始めて、あるモジュールから次のモジュールに進みます。モジュールの動作を開始する直前に頭の中で計画するだけですが、その前に計画はありません。 ただし、仕様を検討し、コーディングする前にシステムがどのように機能するか、たとえば主要なコンポーネントは何か、それらはどのように相互作用するかなどを計画しておいた方が良いと思います。私が何を計画すべきか正確にはわからない。 私が何を求めているのかをよりよく理解するには、どのようにすればよいですか- a）プロジェクトをコンポーネントに分割し、 b）相互作用を計画します。たとえば、クラス図を作成したり、単体テストを作成したりする必要がありますか？ 何か案は？

17 project-management  design  self-improvement  planning  specifications 

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

16 agile  scrum  planning