詳細情報-ウィキペディアのパーソナルソフトウェアプロセスおよびウィキペディアのチームソフトウェアプロセス。
2つの質問があります：
- これらのプロセスからどのようなメリットがありますか？
- これらのプロセスに従うためにどのようなツールや方法を使用していますか？
4248 次
10 に答える
14
私はトレーニングを受け、会社がお金を払ってカーネギー メロン大学に行き、PSP インストラクター トレーニング コースを受講してインストラクターとしての資格を取得しました。目標は、これを当社の CMM/CMMI の取り組みの一環として使用することだったと思います。私はワッツ・ハンフリーに会い、彼が親切で穏やかな魂であり、プロセスについての深い考えを持っていることを知りました. 彼の本も何冊か読みました。
これが私の考えを一言で言うと、ほとんどの人が従うにはあまりにも構造化されていることです。過去の情報に基づく見積もりの考え方は、特に教室での設定では問題ありませんが、要件と方向性の潮流が変化するために見積もりが 1 日で取り消される現実の世界では、あまり役に立ちません。また、Wide Band Delphi の見積もりも行いましたが、それは問題ありませんでしたが、正直なところ、私が作成した「最良の推測」よりも必ずしも優れているとは限りませんでした。
私のチームは PSP にそれほど熱心ではありませんでした。これが問題の一部です。つまり、開発者の賛同です。私の会社は間違った理由でそれを行っていました.単に「ねえ、私たちはPSPを使用していて、認定されたインストラクターが何人かいるのを見てください!」.
最終的に、「アジャイル」アプローチを使用する方が優れていることがわかりました。やるべき仕事のバックログがあり、概してかなりうまく見積もることができます。私は十分に長い間それを行ってきたので、時間通りにかなり良い大まかな見積もりをすることができました. おそらく環境によってはうまくいくかもしれませんが、私の場所では、疑わしい利点をもたらすすべてのプロセスフープなしで、高品質のソフトウェアを送り出し続けます.
ちょうど私の2セント。
于 2008-09-20T01:15:38.300 に答える
6
私はPSPとTSPプロセスを4年間心から使用してきました（それは私のソフトウェアキャリアの始まりでしたが）。理想主義者として、あなたはあなたによって行われていることを気に入るはずです、そしてもちろんそうです、驚くべき結果もあります。
PSPはあなたの欠陥をコア（;やタイプミスなど）に記録することを提唱していますが、私はワッツ・ハンフリー氏と会話していて、多くの人がコンパイラーの進歩とオブジェクト指向性の欠如について彼に尋ねました（私は感じました、私はOOプログラマーであり、正常に使用していたので、どのように欠落していますか）。彼から非常に良い答えがありました。「PSP、または実際のところ、プロセスの方法論は、単一のアイデアに固執する概念ではありません。コアとなるアイデアは、人々に質の高い方法と分析を紹介することです。
「常に適応性があります。ニーズに合わせて調整できます。ファンクションポイント法を採用する場合は、先に進んでもかまいません。どの見積もり手法でも同じです。ただし、常に繰り返し実行する必要があります。 。
「コンパイラの進歩と同じです。PSPの構造のWBSが開発に適合しないと思われる場合は、それを変更して使用しますが、再度継続的に実行します。
「継続的に行うことで、過去のデータを収集し、すべてのパラメータについて統計的に予測可能で正確な見積もりを行うことができます」
この回答は遅れているかもしれませんが、すべての回答を読んだとき、私は感じましたこれを共有したかった。ツールごとに、プロセスダッシュボード、PSPエクセルシートなどがあります。
于 2013-03-13T07:05:35.753 に答える
6
PSP ダッシュボードを使用してみました。
ついていくのが難しすぎる。すべての活動にストップウォッチを使用したいのは誰ですか? 痛みのないスケジューリングとエビデンスに基づくスケジューリングに関する Joel のアドバイスに従ってください。
この質問に +1、PSP に -1。
于 2008-08-27T03:53:04.497 に答える
4
PSPについては、ソフトウェアプロセスダッシュボードを見たことがありますが、使用するのは非常に難しいようです。
于 2008-08-26T14:30:36.547 に答える
3
私は大学のこの最後の学期にそれを学びましたが、それは私にとってとてもうまくいきました. 文字どおりに実行することで、Compile を実行してもエラーが発生せず、Run を実行することで、プログラムを修正して再コンパイルして何度も実行する必要がなくなると確信できます。混乱が収まるまで。
「セミコロンの欠落」などを記録しなければならないことについて不満を言う人もいますが、プログラム 7 を使用する頃には、そのような些細な間違いを犯すことはなくなり、代わりにプログラムの重要な部分で欠陥が見つかります。実際のシナリオに適用する機会はありませんでしたが、本当に楽しみです!
于 2009-12-11T02:06:51.247 に答える
2
私は可能な限りPSP2.1のプロセスに従うようにしています。これは、プロジェクトの重要ではあるが刺激的ではない部分をスキップしないことに集中するのに本当に役立ちます。通常、これは小規模プロジェクトの設計および設計レビューです。
時間を追跡するために、PSPダッシュボードを使用できます。このダッシュボードには、プロセスの実行に役立つ一連の組み込み機能とスクリプトがあります。
タイムトラッキングツールを探しているだけなら、http：//slimtimer.comも気に入っています。それはまた、いくつかのまともなレポートを行うことができます。
于 2008-09-02T21:49:02.227 に答える
2
私は PSP コースを修了しました。次のコースは、他の人が言うように、チームのダイナミクスを目的とした TSP になるはずです。私は PSP について複雑な気持ちを持っています (ほとんど否定的ですが、結果は興味深いものでした)。次の結論に達しました。
- まず第一に、私のフラストレーションの主な原因は、デザイン テンプレートがあまりにも退屈で実用的でないことです。それらを UML と BPMN に変更し、インストラクターに最初から IMPOSE IF NECESSARY と伝えます。本自体には、デザイン テンプレートは UML を知らない、または学びたい人向けであると書かれています。
- 第二に、見積もりは私にとって唯一の貴重な部分でした。本自体は、コード行から離れて他のものを使用できると述べており、それらが統計的にどの程度関連しているかを知る方法についても説明しています. これに対する私の見解 (コードの行数を数えること) は、VCS (git、mercurial) に接続するツール/プラグインが存在し、パーソナル データベースの構築を自動化する必要があるということです。
- プロセス自体は素晴らしいですが、大規模なプロジェクトには適用できません。なぜなら、反復に対応できないからです。現実の世界では、要件の変更により、常にプロジェクトを繰り返す必要があります。この規律は、小規模なプログラムのタスクにも適用できます。これは、計画、設計、設計のレビュー (設計基準と覚えやすい小さなチェックリストを用意する)、コーディング、コードのレビュー (明確なコーディング標準と小さなメンタル チェックリストを用意する) です。暗記することができます）、テストし、間違いについて熟考してください。経験豊富なプログラマーは、これらが最終的に直感的な手順に従うことを知っているでしょう。実際の私の推奨事項: プロセスに従いますが、設計以外のものを文書化しないでください。単体テストを実装する場合は、それらを十分に文書化してください。
- このプロセスは、実際には従う価値があり、実用的かもしれません...間違いの余地がまったくないリアルタイムシステムプログラミングの場合、それ以外の場合は価値がないと感じます。
- 集中力を整理して改善するための方法論を探している場合は、まずGTD (Get Things Done)とPomodoroを試してください。
- 強迫性障害がある場合は、実際に PSP を楽しむことができます =)。
私の最後の推奨事項は、参照としてそれから学ぶことで、より優れた実用的なものにつながる可能性があります. このことはあまりにも学術的です。
PS: RIP ワッツ・ハンフリー
于 2010-11-20T03:43:21.903 に答える
2
PSPを半年ほど使っています。
時間がかかります。私の見積もりでは、フォームに記入する時間の 7% を費やさなければなりませんでした。「セミコロン抜け」の間違いを何度も入れなければならないのはもどかしい。
しかし一方で、プロセスに慣れるにつれて、自分が主に行っていたエラーがわかり始め、「自然に」それらを回避し始めたため、重要になりました。
また、コードを「レビュー」して、コンパイル ボタンを押す前に問題がないかどうかを確認できます。
ツールについては、Timetracker の使用をお勧めします: http://0xff.net/
少なくとも 2 か月間は PSP を試すことをお勧めします。コンパイルと小さなバグの修正に費やす時間を短縮するのに役立つ習慣を身につけることができるからです。
于 2009-04-20T13:39:55.567 に答える
1
私のグループが実験したかったので、私は数年前にPSPを数週間追跡しました. 私はそれが非常に残念で、一緒に仕事をするのがイライラすることさえありました。それは私の忍耐力を使い果たしました。私の主なマイナス点は次のとおりです。
- タイプミスやセミコロンの欠落などのばかげた強調。
- 手で記入しなければならない非実用的なフォーム。
- オブジェクト指向ではなく、手続き型プログラミングに焦点を当てます。
- 見積もりには、ループ、関数などの数のカウントが含まれます。
私はそれが時間の無駄だと思いました。PSPに従うことを余儀なくされるよりも、この職業を辞めることを選択したいと思います.
関連資料: 「開発者に推奨しないプログラミング本は?」という質問に対するPSP の本に関する私の回答。
于 2009-01-07T20:44:55.467 に答える