[阅读]我的阅读做业week7

 

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

自我当项目经理以来，初期时每日兢兢业业，生怕哪天本身没有安排好后两天的进度计划而使整个项目被迫中止下来。虽然途中也遭遇了许多挫折，遇到了不少的意外状况，好比有时由于中间形式不规范（数据处理部分）而致使对接困难，大部分时候我遇到这种状况都得把双方的代码阅读一遍，而后修改代码格式才能对上。内心的疲惫与苦涩，致使有一天上午我真的有感觉到身体负担过大而心绞痛。

天天都有人劝我早些休息，不要那么拼命，可是为了团队能协调前进，有些时候我不得不费很是大的力气去作一些很琐碎的事，很麻烦的事，很吃力不讨好的事。

可是这些都是值得的吧，至少在我看来，这些独有的经验与心路历程，都将是我一辈子的财富。