敏捷方法
在瞬息万变的互联网、软件行业，大家渐渐体会到敏捷的优势。我们参考了几种经典的敏捷模式，按照产品、团队的需要定制了属于自己的敏捷方法，特点如下：
有计划，更要“拥抱变化”。
随着时间变化，必然有新的信息出现，特别是市场环境、用户情况等瞬息万变的互联网业界，所以死守着的项目计划不调整是没有逻辑的做法。并且，项目估计的不确定性是会累积的，80%×80%×……以后，能确定的就更少了，所以开始订的项目计划，在一个月后很可能已经面目全非，强行遵守是没有意义的，而应该不断地修正，当然，在一开始的计划中间就应该留有一些弹性。
迭代周期内尽量不加任务。
敏捷再灵活，也不能容忍毫无控制的变化，“迭代”权衡了变化的成本和不变的成本，这是一个将“大项目长期不变”细化为“当前迭代不变，下次迭代待定”的做法。此外，如果某次迭代内的任务无法完成，可以为了时间点的要求，移出一部分任务到下一个迭代。
集中工作，小步快跑。
项目干系人都在一个区域办公，或者在一间会议室里办公，这样可充分利用白板和墙壁。相应地就要求团队较小，一般小于十几人，太多了可分割为多个团队。同时，项目有较短的迭代周期，通常是2～4周，我们推崇每日“站立晨会”，会长小于20分钟，每个人只能说3 个问题：昨天做了什么？今天要做什么？碰到什么问题，打算如何解决，需要什么帮助？集中工作也是为了倡导较少的文档，更多地口头沟通，其实这点对团队成员要求很高，特别是对国内的技术人员。
持续细化需求，强调测试。
需求唯一不变的特征就是“不断变化”，项目与产品都要小步快跑，用不着在需求阶段纠缠。
我们在开发和测试过程中完善需求，而且特别看重测试驱动项目，更早的测试，重度的测试。这需要有很强很严谨的测试人员，TC编写、TC评审，甚至测试执行的过程可以用来补充和细化需求，比如业务逻辑里的一些限制条件、异常流程等，往往都是测试人员提出来的。
不断发布，尽早交付。
让需求方不断地、尽早地看到结果，并给予反馈，当然需求方代表要有话语权，不然半途杀出个老板说三道四是令人极其郁闷的。这点也要求需求方充分投入，包括集中办公、参与验收测试等。我们的“冒烟测试”、“每日构建”就符合“尽早交付”的概念，可以让需求方尽早看到最新的产品。不断的发布也是为了把大问题分而治之，先解决最核心的，风险最大的部分。我们会先完成最重要的功能，所以说敏捷的里程碑是功能驱动的。
I 用自己的话重述知识
Why:软件行业，互联网瞬息万变，怎么样适应变化呢？我们在做项目过程中是不是也常常遇到预料之外的困难呢？
What:通过使用敏捷方法，适应变化，得到最大收益。
How:1 有计划，更要“拥抱变化”。2 迭代周期内尽量不加任务。3 集中工作，小步快跑。4 持续细化需求，强调测试。5不断发布，尽早交付。
When:做项目流程化的工程方法受局限时采用敏捷方法去做。
Where:在项目管理或处理复杂需要应对变化的事情时适用。
A1描述自己的相关经验
2月份给自己制定了一个读书计划，计划每天3小时学习并输出读书笔记。理想是美好的， 实行了将近1周，开始三天打鱼两天晒网。因为开始远程办公了，优先处理工作呀， 花一下午和面剁馅包饺子啦，日程出现变化了，我计划节奏就打乱了，最后读书计划搁浅。
A2 我的应用
0321~0408计划学习运营思维
通过学习敏捷方法，为了实现这个计划，我准备这样去做：
1 有计划，更要“拥抱变化”。每天的便签和音频计划是在12:00前完成，会出现需要工作或者外出办事等变化，在拥抱变化的同时便签放在晚上完成。
2 迭代周期内尽量不加任务。在便签训练周期里，先不增加把便签加工成拆书练级稿子的任务。
3 集中工作，小步快跑。与运营思维组的小伙伴们集中在群里每日反馈，跟上进度。
4 持续细化需求，强调测试。完善运营思维的学习，从了解什么是运营到学习运营思维方法。
5不断发布，尽早交付。完成1篇同时录喜马拉雅音频，不断发布，尽早地看到作品。
网友评论