問題タブ [development-process]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
4 に答える
414 参照

usability - ユーザビリティ研究のための視線追跡パッケージ?

これは、視線追跡ソフトウェアを使用して、ユーザーが画面上のどこで大部分の時間を費やしているかを示す「ヒートマップ」を生成するという興味深い記事です。

誰かが入ってあなたのために評価を実行するために鼻からお金を払うことなく、これを行うための良いパッケージに関するリードはありますか?

http://www.useit.com/eyetracking

0 投票する
37 に答える
19148 参照

project-management - 期限を逃した場合のペナルティ/対応はどうあるべきですか?

ソフトウェア業界に比較的慣れていないので、期限の強制についての質問に出くわしました。

アカデミアの牧歌的な時代に戻ると、締め切りは学期の終わりであり、ペナルティは明確に定義された「F」(または地域の同等物)でした。現実の世界では、現在および将来のピアが使用できるコードを作成する必要があります。締め切りが来て、締め切りが過ぎても、プロジェクトがまだ完了していないという状況に直面しています。

それで?極端な場合は、関係者全員を解雇することができ、他方では、関係者全員に豊富な報酬を与えることができます。

  1. 期限を過ぎた場合の「ペナルティ」としてどのようなアクションが適用されたと思いますか。また、これらのうちどれが最終的にはより良いコードになりましたか。

  2. プロジェクト管理の対応により、プロジェクトが完全に失敗したのはどのようなものでしたか。

  3. どのような応答が正常に機能し、後で維持できるコードをもたらしましたか?

  4. どのような応答がより悪いコードをもたらしましたか?

0 投票する
3 に答える
4423 参照

agile - スクラム:非技術的なPOによって管理されているバックログの技術的なアイテム?

「サーバーをv1からv2にアップグレードする」、「起動パフォーマンスを向上させる」、「ログインモジュールをリファクタリングしてコードの複雑さを軽減する」などの技術的な項目が製品のバックログに含まれる場合、技術的でない製品所有者がそれらに優先順位を付けるにはどうすればよいですか。対他のより機能的なバックログアイテム?

技術的なもののために別のバックログがあるべきですか?製品のバックログで機能的および技術的なものを優先できる2人の共同POの役割を担う必要がありますか?

0 投票する
6 に答える
533 参照

project-management - スクラム。アーキテクチャの変更を導入する優先度の低いストーリーへの対処

今日、大学でスクラム演習 (ソフトウェア ソリューションを作成するプロセス全体をシミュレートする) があり、よく理解できない問題を思いつきました。

ストーリーを定義し、適切な優先順位を付けたとしましょう。そして、優先度がほとんどないストーリーがあります...おそらく、最後のスプリントで行われるでしょう。

問題は、このストーリーがソリューションの設計に大きなアーキテクチャの変更をもたらした場合はどうなるかということです。たとえば、スタンドアロン アプリケーションの場合、この話だけのために、クライアント サーバー アーキテクチャを使用する必要があります。

私の見解では、どのストーリーが確実に(ある特定の時点で)行われるか、どのストーリーが行われることが重要であるが、いつ重要ではないかを何らかの方法でマークするのは自然ではないでしょうか。それらを念頭に置いて、彼のソリューションを設計するより良い決定を下します。または、この問題にどのように対処していますか?問題がある場合。

前もって感謝します!そして、私のおそらく不自由な質問を許してください。

0 投票する
6 に答える
522 参照

agile - 滝の中でアジャイルを維持する

プロジェクトのスコープが設計され、正式なウォーターフォールプロセスを使用して最終的にコード化される大規模なエンタープライズアプリケーションがあります。コードの同じセクションにあるという理由だけで、関連のないイニシアチブのコード変更が頻繁に与えられます。すべてのイニシアチブは同時に引き渡される必要があります。開発チームは、範囲や納期についてもほとんど発言していません。ビジネスを知らない要件収集のグループを通過する必要があるユーザーと話すことはできません。

そのような定着した環境に最小のアジャイル技術を実装する方法について、誰かがアドバイスを持っていますか?

0 投票する
5 に答える
5512 参照

project-management - アプリケーション ライフサイクル管理ツールを探している

従業員が約 15 人のチーム向けのアプリケーション ライフサイクル管理ツールを探しています。次の機能を提供する必要があります。

全般的

  • マルチユーザーネットワークシステム
  • 各ユーザーのダッシュボード
  • スクラムに適している必要があります
  • 複数のプロジェクト

課題トラッカー

  • バグ、機能強化、新機能の分離
  • 問題に含める必要があるもの: カテゴリ、重大度、ステータス、説明、添付ファイル、担当者、推定時間、所要時間、進行状況
  • 課題間の依存関係
  • 優先順位
  • 階層レベルに応じて重要業績評価指標が蓄積された課題とプロジェクトの階層構造 (サブプロジェクトの進捗状況など)

製品/リリース管理

  • これは単にプロジェクトとして扱うことができるかもしれません

資力

  • アクセス制御によるユーザー管理
  • 一人当たり労働時間、休日
  • 従業員一人当たりの時給

テスト管理

  • テスト ケースを作成する
  • テスト結果の追跡 (手動テスト)

報告

  • 進捗状況やコストなどを含むすべてのプロジェクトの概要
  • リソースの監視

変更管理

推奨事項はありますか?

0 投票する
7 に答える
2313 参照

uml - UML図。それらはいつ使用されますか?

さて、UMLダイアグラムはプログラムの構築に役立つことを理解していますが、いつ使用されますか?コーディングを始める前に必要ですか?何をコーディングする必要があるかを知るためにそれらが必要ですか?それとも、プログラムをコーディングした後でそれらを使用しますか?

0 投票する
1 に答える
457 参照

tfs - 別のチーム プロジェクトの作業項目に関連付けられたチェックインを許可しますか?

Team Foundation Server 2008 では、すべてのチェックインを作業項目に関連付けることができますが、複数のチーム プロジェクトにまたがる機能を開発している場合はどうすればよいでしょうか?

たとえば、クライアント向けの特定の製品を開発していて、その製品には独自のチーム プロジェクトがありますが、別のチーム プロジェクトで独立して維持されている他のコンポーネントやツールも使用しています。

両方のプロジェクトの変更を伴う要件の作業項目はどこで作成しますか?

  1. 個別のチーム プロジェクト内のすべての作業項目
  2. 関連付けられたソース コードに関係なく、クライアントのチーム プロジェクト内のすべての作業項目

後者の方が保守と制御が簡単に思えますが、あるチーム プロジェクトからのチェックインを別のチーム プロジェクトの作業項目に関連付ける必要があります。

0 投票する
1 に答える
602 参照

tfs - MFS アジャイル プロセス テンプレートの作業項目

バグ、リスク、シナリオ、タスク、サービス品質要件の作業項目の使用方法に関する実用的な例はどこにありますか?

MSDN のドキュメントで、次のトピックを見つけました: http://msdn.microsoft.com/en-us/library/bb668962.aspxしかし、いつどちらを使用するかを深く理解するには十分ではありません。

ありがとう!

0 投票する
5 に答える
414 参照

development-process - プログラマーを失った場合、どのような手順を踏む必要がありますか?

私たちのチームのプログラマーの 1 人が、より緑豊かな牧草地に向けて出発します。6 から 5 に移行します。開発プロセスをスムーズに継続するために必要な手順は何ですか。

現在、反復開発による短いリリース サイクルに取り組んでいます。設計 - コード - レビュー。退職するのはチームの最年長の開発者であり、特に設計段階では、チームの他のメンバーに多くのフィードバックを与えることがよくありました。