People-oriented in Agile
- People-oriented in Agile
- One Leader
- Prepare
- Good ideas from users
- People-oriented
- Performance
- No silver bullet , But people management
- Summary
面向人的敏捷开发，恩，这就是我今天想要表达的主题。之所以想表达这个主题，主要还是因为我在项目中的职能：项目经理——在管理一个团队与沟通的过程中，关于这一点触动最深。
下面就以这一点为核心谈谈我的一些想法吧。
One Leader
The Cathedral and the Bazaar： “given enough eyeballs, all bugs are shallow”
这句话是The Cathedral and the Bazaar的主旨，按我理解来说它的意思是：只要搏人眼球，瑕疵无所遁形。
在大教堂的模型中，是由一个完整的开发团队来开发一个项目。而在集市的模式中，一个完整的项目是借助于互联网的东风由网上的各位爱好者贡献而产出的。粗略来看，集市模式看起来更好，因为它能减少大量的个人开发时间。瑕疵之所以无所遁形，是因为群众的眼睛是雪亮。同时，开源的代码让不同的思想在同一个项目中产生了碰撞，可能会产生非常奇妙的灵感。
但是我个人是谈不上赞同或不赞同哪种模式的。大教堂模型更像是当前主流公司所采用的模式，有一个完整的开发团队来开发某个软件或模块。在看过另外一篇文章Lost in CatB后，我觉得一味争论开源化还是商业化的问题本身是没有任何意义的，一味地肯定或否定某种模式只是片面之说，一种模式的存在即是其合理的表征。我更加赞同的一种观点是：不管是开源还是商业化，都必须要有一个人对整个项目负责。不是两个人，不是三个人，而是一个人。
这一点上让我感受颇深是因为另外一支队伍。这支队伍是我们团队初期预想的最有竞争力的一支队伍——最根本的原因是他们队伍里我欣赏的人很多。这就意味着团队里的每个人都有着独当一面的能力，独自解决问题的思路与别树一帜的想法。
但是他们的开发过程中出了一些毛病，我也能明显感受到：
- 名义上的项目经理参与不到真正的项目开发中来
- 实际上的项目经理没有完全发挥项目经理的职能，没有一个整体的规划和组织
我了解他们组的同学，也知道他们的设计师和文档撰写人员的厉害。他们的文档有些时候我真的是自愧弗如，而他们的设计师本身也是工程经验非常丰富，也非常有责任感。
但是，他们组缺少一个灵魂核心：项目经理。一个项目缺少好的项目经理等于缺少润滑剂。如果没有对一个项目负责的项目经理，项目虽然可能在磕磕绊绊中会前进一些，但是发展到后期就会彰显出它的不协调。
设计上的事情可能框架的设计师可以全权负责。但是要把这些理想的图纸付诸实践，到每一个人身上的时候，就需要项目经理来安排进度。
Prepare
Do less, start earlier。
Once we have the design, we can plan the construction。
看到这句话，突然感慨万千。联想到了我们项目初期时我做出的选择，现在看来那时的拼命确实是有必要的。
当时还是团队项目的第一周，本来是需要在第一周只需要项目经理做NABC需求分析的。但是深谙设计的重要性的我没有满足于现状。从第一周开始我就和设计师商量框架、实现方案、设计思路以及可行性。并且在第一周就已经制定出了可行的，学习成本较低，并且可以让大部分人都参与进来的技术方案。
不止这些，我还和UI设计师卤蛋一起商量网页原型设计，寻找好用的设计工具。其他人也没闲着：主程序员在寻找各个实验的标准原始数据录入表，而两外两位开发人员则在寻找标准的预习报告模版以减轻后面的工作量。
虽然第一周的工作在后来被验证依旧是没做到非常细致与缜密，但是第一周我们的规格说明书的雏形初成有着重大的意义。它不仅是团队风貌的展示，更是后面我们前端后端对接顺利的保障。界面原型设计是前端与后端工程师无形的接口，它在项目开始前就已经得到多次修缮，这使得前端和后端第一次对接非常成功。
Start earlier，上帝不会亏待任何一个早准备的孩子。
Good ideas from users
The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
提到这一点我就不得不提到敏捷开发。敏捷开发中的迭代周期短，是因为在短周期的迭代后可以获得最新的用户反馈并及时更新需求以获得更好的软件满意度和质量，这也是敏捷开发的特点之一：Responding to change over following a plan。
因此，我们团队设计了一些激励措施例如发红包等来激励用户向我们反馈他们最真实的需求。并且由于我们产品本身定位方向切实戳中了学生通点，有很多热心的学弟学妹会主动在群里反馈一些可行的建议，这样动态调整需求，让我本身对第二轮迭代要做的功能进行了大幅度的修改，更加符合用户的需求。最好的建议往往来自想使用的人。
People-oriented
Agile methods are people-oriented rather than process-oriented.
Furthermore his studies of software projects have led him to conclude the people are the most important factor in software development.
敏捷开发是面向人而不是面向过程的，是要以人为本的。这一点上我的感触最深。我在团队项目中充分地感受到了我自己身为项目经理的胶水作用。我就像个跟屁虫，每天都跟在每一位我还不放心的开发人员后面一直追问他的进度，发展情况，是否遇到了解决不了的困难，是否希望可以调换任务，是哪里出现了问题等。即使有每日scrum meeting，我也会每日如此追踪，一直到督促他们完成当天的任务或者跟他们一起解决当天的任务为止。
而每个人在项目中发挥的作用都非常重要。
人和程序不一样，程序接收固定的输入，执行固定的步骤，给出可行范围内的解。但是人，只要是愿意参与沟通的，他们身上都会有无限可能。
Performance
但是典型的软件项目往往是没有规律及可预测环境的。项目成功的唯一正确度量就是：最终的结果通过整个生命周期里的实施达到了预期目标吗？ 很难知道什么关键活动导致了项目成功和失败，很少有人能够通过旧有或现有的项目获得答案。几乎不可能判定哪些决策导致了成功或失败。
在这一点上我感触比较深的是，在团队最后绩效分配上我做出的选择。我最终还是没有选择严格按照当初定好的团队贡献分配策略来严格给分。一方面确实有很多地方是我的失误:
- 时间估计错误
- 任务量估计不足
- 中间形式规定含糊
这些都是我的失误，而且因为这些失误导致我和队员都付出了巨大的时间，却收获较小，有很多是可以使用非常简单的技巧就可以完成的，最终却绕了远路。我没法因为我安排任务不合理而使得任务最后完成效果较差而把他们的真正贡献打折。另一方面就是队员本身能力的确有限，虽然我已经设身处地地在分配任务时按照不同能力分配门槛不同的任务，但是也有很多时候效果依然不尽人如意。
No silver bullet , But people management
我认同在软件的开发中没有任何一项技术可使软件工程的生产力在十年内提高十倍的说法，但是我认为在软件开发的过程中，为了提高生产力，更需要的可能不是从软件开发的方法下手，而是要从团队的人力管理上下手。好的项目经理应当懂得如何为合适的人分配合适的任务。不论是瀑布模型，敏捷开发模型，模型本身都不应该是一个软件开发的关注重点——人才是软件开发的关注重点，模型只是建议，可人才是决定性因素。
一个团队是否能协调有力地前进，不在于他们采用了哪种模型，使用了什么工具，懂得了什么不一样的方法，而在于团队内的好程序员和他们的项目经理。
Summary
自我当项目经理以来，初期时每日兢兢业业，生怕哪天自己没有安排好后两天的进度计划而使整个项目被迫停止下来。虽然途中也遭遇了许多挫折，遇到了很多的意外情况，比如有时因为中间形式不规范（数据处理部分）而导致对接困难，大部分时候我遇到这种情况都得把双方的代码阅读一遍，然后修改代码格式才能对上。心里的疲惫与苦涩，导致有一天上午我真的有感受到身体负担过大而心绞痛。
每天都有人劝我早些休息，不要那么拼命，但是为了团队能协调前进，有些时候我不得不费非常大的力气去做一些很琐碎的事，很麻烦的事，很吃力不讨好的事。
但是这些都是值得的吧，至少在我看来，这些独有的经验与心路历程，都将是我一生的财富。