-
 step four*

－new：

敏捷流程，PM：

看到敏捷这个章节时候还是比较激动的，因为在开学时的讲座里面曾经讲到敏捷开发，依然记得那位大姐豪迈着说敏捷怎样先进，怎样出彩...

看过书之后，可以确认那位大姐是“敏捷”的铁杆粉，敏捷的效能很高，顾名便可思义，它是以时间进行驱动，强调短时间的迭代，要求团队具有较高实力，鼓励交流，能自主管理，组织，团队成员是走多功能路线，Spec，Communication，Test，每个人都要对团队负责，这对能力很弱的团队来说要求太高，容易get just the opposite。没有事情可以特别完美，敏捷也会有问题，backlog定义模糊；成员任务分配导致忙闲不均；sprint阶段的每日例会可能慢慢就变成形式 …敏捷也不能应用于所有场景，大型项目，长期工程，成员技术较差等等都不适合Agile，书中老师也介绍了一些解决方法，有度量的燃尽图可以更好的跟踪项目进度，既然是时间驱动流程，那么关注时间是非常必要的，另外个人认为团队成员的素质和准备阶段必要要搞好，素质不单单是说能力，还有工作态度等，准备充分了，才能达到好的冲刺结果，因此需要一个优秀的master，也就是PM。

不看不知道，原来PM的P还分为很多种，product，project，program，书中重点介绍了微软的program manager，可能是老师的工作情怀～ 微软的看起来更加专业一点，要求也更高，因为他要做开发和测试之外的所有事情，需要广泛的知识储量，个人技术也不能低，较强的沟通调解能力，当然在微软中分为几个类别的PM，如果都让一个人达到这些要求......微软的PM并不是行政管理人员，这样他可以和其他人员平等的讨论，很赞同这个’好的产品设计是在争论的基础上产生的’观点，因为如果存在领导和命令关系，其他人员有意见也不会说，毕竟喜欢“不听话”的员工的老板并不多，从而导致最终产品达不到预期效果。PM最大的贡献是带领团队达到最重要的目标，并保持balance，还要在整个项目的生命周期管理风险，可见，PM是要有较高的专业能力和广阔的知识面，对于每一位想成为PM的小白来说都是任重道远的！

典型用户和场景：

看完章节内容之后，感觉典型用户很好用，有时候，用户的需求并不是百分百实现就可以收工，因为用户大多是不会把自己的需求全部描述清楚，背后的需求动机更是需要仔细研究的，典型用户迫使我们考虑问题时从用户的角度出发，这样分析出来的产品设计会更容易被用户接受，定义典型用户时，分为两类别， 一类是受欢迎的，指的是能够合理使用产品功能，并能带来正常效益的群体，另一类是不欢迎的，那就是黑客这样子盗取数据，乱发广告等的一些不招人喜欢的用户。确定典型用户的用户范围，虽然会损失范围之外的用户，但是却是值得的，如果用户群体模棱两可，结果会是大家都不满意，软件就没人用了。典型用户包含名字性别等基本信息以及和产品相关联系的内容，整理出不同类别的用户后，我们还需要进行场景模拟，书中的例子就很典型，银行无卡取现，多Cool，好像很方便，到了之后发现没卡进不去自助银行，这就很尴尬。因此，我们需要进行严格的场景模拟，整理达到目标必须经历的过程，可以帮助我们发现“进不去门“的漏洞，把产品完善。

－PS 项目学习：

最初计划是移动端的软件开发，所以一直在学ios，但是时间和精力各方面调配有问题，进度不是很快，不过考虑到团队成员的技术倾向，所以最终可能会通过C#进行软件编写，关于ios的学习和git指令的学习之后写一篇独立的博客来纪录学习进度。