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

私はテクノロジー企業のソフトウェア開発者です。私が取り組んでいる製品の文書化作業を主導する任務を負っています。目標は開発者の内部でドキュメントを作成することであり、プロジェクトはビジネス側に波及し、そこで要件のドキュメントがカバーされます。 このプロジェクトは挑戦的です。具体的には、次のような製品を扱っています。-少なくとも6年間、長い間使用されています。-あちこちにある古くて小さな断片を除いて、ドキュメントの形式はありません。-コード内にコメントがありますが、それらは技術的であり、包括的な技術的な動作を伝えません（技術的な側面でも）。-ドキュメントがほとんどないか、まったくないため、多くの場合、不必要に複雑になっています。 また、このプロジェクトに取り組む時間はあまりありません。 私は正式な文書やライティングの背景、トレーニング、または経験がありません。私は執筆やオフィス内でのコミュニケーション能力を発揮したため、このプロジェクトに割り当てられたのかもしれません。 このプロジェクトの準備と対処に役立つリソースに関するアドバイスや推奨事項を教えてください。マイルストーンを含む計画の設計を思い付き、ベストプラクティス、タスクの委任、テンプレート、バイインなどについて学ぶために、本/ウェブサイト/フォーラム/その他への参照を探しています。 私は特に、既存の、文書化されていないプロジェクトに優れた文書を導入することをターゲットにしたり、特別な言及をしたりするリソースに期待しています。

9 development-process  documentation  teamwork  planning 

問題のケース： スプリントはほぼ終了し、私のスクラムチームの1つはいくつかのタスクを完了しませんでした。（この理由は、この質問では必須ではないので、それに応じて対処します。）それらの1つは、かなり多くのストーリーポイントを持つ古典的な「90％完了」のケースであり、次のスプリントの一部になります。こちらの質問です。 バックロググルーミングと次のスプリントのためのいくつかの予備的な見積もりを行い、この未完成のタスクを処理する方法について説明しました。このスプリントの速度にはカウントされないことに私たちは皆同意していますが、真の複雑さと実行された総作業を次のようにしたいので、5つのストーリーポイントではなく1でほぼ完全なケースを再推定しないでください。まだ見えています。そして推定を振り返ってみると正しかった。-私たちは（スケーリングされた）アジャイルに移行しているだけであり、一部の管理レベルでは、提供された製品よりも多くの点で生産性を維持していることを「確認」する必要があります。 明らかに、このスプリントの速度は低下しますが、転送された「既に完了した」パーツは、次のスプリントで再び上昇するはずです。 これまでのところ、全員が同意しています。 しかし、私たちのチームはかなり小さいので、4ポイントは大きなかたまりです。このタスクのみで適切なドキュメンテーションがあれば、意識的に4つのポイントの過負荷を計画できると提案しました。 それは実現可能なアプローチですか、それとも私は まだ予想していない問題に遭遇する ほんの数か月前にアジャイルに移行したチームに悪い例を示しますか？

8 agile  scrum  planning  sprint  scrum-master 

序文 大規模なスパゲッティコードクラスをリファクタリングする方法を探しているのではありません。そのトピックは他の質問で取り上げられています。 質問 4000行を超え、2000行を超える単一の巨大な更新メソッドを持つ別の同僚が作成したクラスファイルを理解するための手法を探しています。 結局、私はこのクラスのユニットテストを構築し、DRYと単一責任原則に従う多くの小さなクラスにリファクタリングしたいと考えています。 このタスクをどのように管理およびアプローチできますか？最終的には、クラス内で発生するイベントの図を描き、次に抽象化機能に進むことができるようになりたいのですが、クラスの責任と依存関係が何であるかをトップダウンで把握するのに苦労しています。 編集：人々が入力パラメーターに関連するトピックをすでにカバーしている回答では、この情報は初心者向けです。 この場合、クラスのメインメソッドには入力パラメーターがなく、停止するように指示されるまでwhileループが実行されます。コンストラクターもパラメーターを取りません。 これにより、クラス、その要件、および依存関係の混乱が増します。クラスは、静的メソッド、シングルトンを介して他のクラスへの参照を取得し、すでに参照しているクラスを介して到達します。

8 design  refactoring  planning  legacy-code 

データベースへのインターフェースを提供するREST APIの機械で読み取り可能な記述（WADL、Swagger、RAMLなど）があるとします。 私のユーザーは、基になるデータベースに関するクエリをSQLまたは同様のクエリ言語の形式で送信します。ただし、REST APIを介してのみ、データベースに直接アクセスすることはできません。 そのようなSQLクエリを特定のREST APIへの一連のリクエストに変換するシステムを（できれば記述から半自動で）構築するには、どのアプローチを選択しますか？ そのような問題をどのように表現しますか？役立つアルゴリズム、理論的フレームワーク、またはツールはありますか？ REST APIは以下をサポートします。 読み取り専用操作、つまりSELECTSQLクエリのみ XPartialプロジェクション（例/persons?fields=firstname,lastname） RSQL制約（別の例を/persons?query=firstname==John;department.code==42参照）。 テーブル間の一部の参照（外部キー）はREST APIでは属性として表されますが（Person.department上記の制約の例など）、一部の参照はサブリソース（例：）として表されます/persons/{userName}/projects。つまり、一部のクエリでは、RESTリクエストに関して回答される「計画」を考案する必要があります。 例：「チャックノリスのアクティブなプロジェクトの名前」のクエリは、次のように変換されます。 /persons?query=firstname==Chuck;lastname==Norris userName結果から得る /projects/{userName}?fields=name&query=state==ACTIVE

8 java  sql  rest  planning  translate 

ユーザーストーリーのバックログがあり、それぞれにストーリーポイントの推定数があるとします。今、スプリント計画を実行しています。 これで、ストーリーはタスクに分解されるはずであり、多くのスクラムリソースは、各タスクを人時間で推定する必要があることを示唆しています。この時点ではすべての質問についてチームが話し合っているため、タスクの見積もりに1分以上かかることはありません。ただし、タスクは1日より長くすべきではないため、8人の開発者による3週間のスプリントを想定すると、120タスクを意味し、見積もりにのみ2時間かかることは、私には少し多く思えます。 経験豊富なチームがタスクの見積もりをスキップまたはショートカットできることは知っていますが、まだその段階ではないとしましょう。 あなたの経験では、スプリントにはいくつのタスクがあり、それらすべてを推定するのにどれくらいの時間がかかりますか？（それらの半分だけを見積もることはあまり意味がありませんか？） 明確化： 答えはスプリントの長さとチームのサイズに依存するので、8人の開発者と3週間と仮定します。 言及された数値は経験則である可能性がありますが、それらがオフの場合（たとえば、より多くのタスク、それぞれを推定するために必要な時間の短縮）でも、推定には約2時間かかります。それで、おそらく質問は「計画会議の何パーセントが純粋なタスク推定のために予約されるべきであり、そして私たちがより良いことをすべきではないのか」であろう。

8 scrum  planning  user-story 

私のケースの少し紹介： より大きな製品の一部として、私のチームはDSL用の小さなIDEを実現するように求められます。この製品のユーザーは、コードで関数呼び出しを行うことができます。また、いくつかの便利な関数ライブラリを提供することも求められます。チームは、POと一緒に、IDEユーザーのさまざまなライブラリに関する特定の数のユーザーストーリーを壁に配置しました。それらの最初のストーリーを推定するとき、チームは関数呼び出しメカニズムが魅力的ではあるが完全に明白ではないタスクであると判断したため、そのユーザーストーリーの推定は単純な3からより危険な5に上がりました。 問題に来る： 次に、チームは他のライブラリに関するユーザーストーリー（実際には10のストーリー）に移動し、これらの2つの「関数呼び出しメカニズム」のことを各ユーザーストーリーに追加しました。これですぐに20ポイントの商品の合計ポイントがアップしました！チーム内の誰もが、各ユーザーストーリーはいつでも次のイテレーションのPOによってピックアップされる可能性があることを知っているので、1つのユーザーストーリーでその部分を分離するべきではありませんが、それらの20ポイントは非常に非現実的に感じられます。 私は解決策を提案しましたが、完全に満足していません： 「デザインストーリー」を作成し、面倒な2点を載せました。しかし、私たちがそれを実現して顧客に示すようになったとき、私たちはその話について彼らにとって本当に価値のあるものを示すことができませんでした！ ここでの問題は、孤立したユーザーストーリー（それらの間の依存関係なし）の原則を無視すべきかどうかです。 このような状況で、あなたは何をしますか？ （小さな脚注：提案に従って、この質問をstackoverflowから移動しました）

8 estimation  planning  agile 

アジャイルは多くの先行設計を奨励しません。これは、要件管理とソフトウェア開発の観点からは適切であり、プロジェクトを変化するビジネスニーズに適応させることができます。 しかし、開始時に何を構築するのか本当にわからない場合、リソースの長期計画をどのように行うのでしょうか。確かに、何を構築するかについての概念モデルはありますが、プロジェクトを完了するために必要なリソースの数や、それにかかるコストを測定するための測定可能な詳細はありません。 誰かがアジャイル環境で長期計画を行う方法について何か提案はありますか？

8 project-management  agile  planning