时间点的制定经验分享
本文并不是一个说教的文章，是一个经验分享的文章，既然如此，便是抱着讨论的心态。
我想分享一点我参与过的项目中关于时间点的一些感想
?
1、先定时间点再定需求
我经历过两次项目，一个很大，一个一般大，都有一个共同点，就是先定Deadline再定的需求。
第一个大项目Deadline是由CEO定的，目的是为了在融资。第二个项目我也不清楚是谁定的，但是，和前一个一样，产品经理和开发团队都感觉无法保质保量完成，甚至无法完成。
但是没办法呀，硬着头皮上呀。
于是大家就忙的和狗一样啦，加班呀，这个不是重点。重点是：
A.团队缺少士气，一个坏的开始
B.产品出现对产品规划不完全
C.产品总能在开发中甚至提测后发现需要增加的不大不小的需求，后知后觉是经常的事，该需求这种东西是又伤士气又破坏团队和谐的事情
D.开发人员为了在量上达标，只好放弃质量。优秀TDD习惯的团队也会被迫把写单元测试的时间分在下一个需求的开发中。
E.缺少TDD，开发人员对项目的成果缺少信心
F.更多的设计缺陷和代码bug，如果在项目初期就埋下这么多的Bug隐患，我断言在未来这是一个会逼死人的项目，等开发人员被逼走，低劣质量的代码让新工程师很难接手，这就是恶性循环的开始。
G.第一个迭代的产品就是一个不合格的产品，缺少细节的产品，第一次见人做演示效果不会好到哪里，产品价值无法体现，开发团队还没有荣誉感
?
那我们就不要先定时间了，啥时候做完啥时候算吗？
当然不是，我认为，定时间一定要有开发、测试团队在场，不能只有产品和用户。用户关心的永远是产品，有时他们甚至不关心质量和未来的维护。但是只有开发和测试团队才知道自己如何用键盘敲出高质量的代码。
?
2、领导一人定时间点
一个人的主观判断总是局限的，一个领导对一个完善的需求分析十分清楚，根据经验判断给出一个时间。但是这样的主观臆断，往往忽视很多客观原因
A.团队有很多新成员
B.项目涉及的是一个团队人员都陌生的领域
C.成员年假之类的可预计的请假
D.团队成员是否可以全力投入，例如有人身兼多个项目
?
所以，和团队人员一起过需求，让大家一起评估，手法参照Scrum会是一个更好的选择。团队成员对一个需求达成统一开发周期的认识，这个时间往往会更准一点。
?
3、缺少测试时间的考虑
开发团队给出了时间，记得，一定要测试团队一起参加，也给出测试时间。不要到时候让测试人员手忙脚乱。没有足够的测试时间，软件的Bug数量上升是不言而喻的。
?
4、缺少小的时间点
我并不是说要把每个任务的完成时间都规定到分钟，每到一个任务自己的Deadline，我们检查完成情况。我们也不应该把这个时间看的那么重，我们应该看重的是Delay的原因，或者说，未来可能造成Delay的原因，甚至是早完成的原因，是因为对需求的无解读吗？！
每天早会是个不错的手法，它告诉我们，我们关注的是每天做的是什么，不是手里的任务做了多少，还剩多少，而是我昨天遇到的问题是什么，什么可能会造成Delay。在Delay前尽量发现困难并解决。
燃尽图是个好东西。
?
----------------------------------------
?
一些经验很明显是从Scrum中总结而来的，所以，这并不是我的创新，只是我的经验。
?
