有关更多信息，请参阅Wikipedia上的"个人软件过程"和Wikipedia上的"团队软件过程"。

我有两个问题：

• 我们从这些过程中看到了什么好处？
• 我们使用什么工具和/或者方法来遵循这些过程？

解决方案

回答

对于PSP，我已经看到了"软件过程仪表板"，但是似乎很难使用。

回答

我参加了一次，甚至尝试使用PSP仪表板。

很难跟上。谁想在所有活动中使用秒表？遵循Joel关于无痛计划和基于证据的计划的建议。

+1此问题，-1至PSP。

回答

我尝试尽可能遵循PSP 2.1流程。这确实有助于我专注于不跳过项目的重要部分，但不那么令人兴奋的部分。通常，这是小型项目的设计和设计审查。

为了跟踪时间，我们可以使用PSP仪表板，该仪表板具有许多内置功能和脚本，可以遵循该过程。

如果我们只是在寻找时间跟踪工具，我也喜欢http://slimtimer.com。它还可以做一些体面的报告。

回答

我接受了培训，然后我的公司付钱给我去了卡内基·梅隆(Carnegie Mellon)，并参加了PSP讲师培训课程，获得了讲师资格证书。我认为目标是将其用作我们公司CMM / CMMI工作的一部分。我遇到了沃茨·汉弗莱(Watts Humphrey)，发现他是一个善良而温柔的灵魂，对工艺有着深刻的理解。我也读了他的几本书。

简而言之，这是我的看法，假设我们遵循这封信，它对于大多数人来说太结构化了。基于历史信息进行估算的想法是可以的，特别是在教室环境中，但是在现实世界中，由于需求和方向的变化趋势，一天之内无法进行估算，因此它的用处不大。我也做了宽带Delphi估算，虽然还可以，但老实说并不一定比我所做的"最佳猜测"要好。

我的团队对PSP不那么热衷，这是开发人员买入问题的一部分。我的公司之所以这样做是因为错误的原因，只是说："嘿，看来我们使用PSP并拥有一些认证的讲师！"。

最后，我发现使用"敏捷"方法会更好。我有很多积压的工作要做，通常可以很好地估计。我已经做了足够长的时间，所以我可以按时做出相当不错的粗略估计，而且坦率地说，我认为时间跟踪并不能真正改善事情。也许在某些环境中它会很好地工作，但是在我自己的位置，我们将不断推出高质量的软件，而不会产生产生可疑收益的所有过程。

只是我的两分钱。

回答

几年前，我跟随PSP了几周，因为我的团队想尝试一下。我发现使用它非常令人失望，甚至烦人。我的耐心都累了。我的主要缺点是：

• 错别字或者缺少分号之类的可笑emphasys。
• 我们必须用手填写不切实际的表格。
• 专注于过程编程而不是面向对象。
• 估算涉及计算循环，函数等的数量。

我发现这浪费大量时间。我宁愿选择离开该行业，也不愿被迫跟随PSP。

相关资料：在"我们不推荐给开发人员的哪本编程书"问题中，我对PSP书的回答。

回答

我在大学期间曾用过它，但在工作中我们根本没有任何流程。直到最近，我们才开始使用版本控制。

我的经验是，它似乎太乏味而无法使用。如果不是自动化的，那么它可能会消失。

回答

在过去六个月中，我一直在使用PSP。

这很耗时。据我估计，我不得不花7％的时间填写表格。
不得不一遍又一遍地犯下"缺少分号"的错误，这令人沮丧。

但是另一方面，当我习惯了该过程时，变得很重要，因为我开始看到我主要在做什么错误，并且我开始自然地避免它们。

它还使我们可以"查看"代码，以便可以在单击编译按钮之前查看是否存在任何问题。

对于工具，我建议使用Timetracker：http://0xff.net/

我建议至少尝试几个月的PSP，因为我们会养成一些习惯，有助于减少花在编译和纠正小错误上的时间。

回答

我刚刚在上学期才学到它，对我来说非常有用。我知道，只要紧跟字母，我就能确信自己可以执行Compile并且不会出现任何错误，而单击Run则不必再花时间修复和重新编译程序来一次又一次地运行它直到混乱解决。

人们抱怨不得不记录"遗漏的分号"，但是当我们进入程序7时，我们不再犯这样的小错误，而是在程序的重要部分中发现了缺陷。虽然我没有机会将其应用于实际情况，但我真的很期待！

回答

我已经完成了PSP课程，下一个课程应该是TSP，正如其他人所说的，TSP是为团队动力而设计的。我对PSP感觉好坏参半(大多是负面的，但结果很有趣)，我得出以下结论：

• 首先，我沮丧的主要根源是设计模板过于繁琐且不切实际。将它们更改为UML和BPMN，从一开始就告诉讲师IMPOSE IF NECESSARY。该书本身说，设计模板是为不了解或者不想学习UML的人设计的。
• 其次，估计对我来说是唯一有价值的部分。该书本身说，我们可以在代码行中使用其他东西，甚至告诉我们如何知道它们在统计上的相关性。我对此的看法(计算代码行)是必须存在与VCS连接的工具/插件(git，mercurial)并自动构建个人数据库，否则太麻烦了以至于无法跟踪基础/添加/重用的零件。
• 这个过程本身很好，但是为什么不适用于大型项目呢，因为它不能解决迭代问题。在现实世界中，由于需求变化，我们将始终必须重申项目。我们仍然可以将纪律应用于小型编程任务，这是：计划，设计，审查设计(具有设计标准和我们可以记住的小清单)，代码，审查代码(具有清晰的编码标准和小型精神清单)我们可以记住)，测试，仔细考虑自己的错误。任何有经验的程序员都会知道，这些都是最终要遵循的直观步骤。我在实际实践中的建议：遵循该过程，但不要记录设计以外的其他内容，如果要实现单元测试，请记录好它们。
• 对于实时系统编程来说，绝对没有错误余地，否则，这个过程实际上可能值得遵循和实用。
• 如果我们正在寻找一种方法来组织和改善焦点，请首先尝试GTD(完成任务)和Pomodoro。
• 如果我们患有强迫症，那么我们实际上可能会喜欢PSP =)。

我的最终建议是从中学习作为参考，它可能会带来更好，更实用的内容。这个东西太学术了。

附言：R.I.P。瓦特汉弗莱