构建之法阅读笔记01——四月

关于 Scrum（敏捷开发原则）的阅读笔记​
一、我过去怎么做的​
以前搞项目开发，一开始就得花老多时间去把需求摸得透透的，再仔仔细细做项目规划，想着把项目里大大小小的事儿都提前定好。然后就按需求分析、设计、写代码、测试、部署，这么一步步来，一个阶段完了才进入下一个阶段。团队合作方面呢，做需求分析的、搞设计的、写代码的、做测试的，各干各阶段的活儿。大家交流主要靠文档，只有到阶段交接的时候，才凑一块儿好好聊聊。​
二、这样做的好处是什么​
文档全乎：看重每个阶段都得有文档。这样项目做完，各种文档都在，以后维护项目、给新人讲项目情况，还有应付审计啥的，都方便。新来的人翻翻文档，就能大概知道项目是咋回事。​
阶段清楚：每个阶段干啥很明确，管理和跟进项目进度就容易。领导能一眼看出来项目到啥地步了，每个阶段要交出啥东西也清楚，对把控整个项目的节奏有好处。​
规划提前做：项目刚开始，把需求和规划弄得明明白白，能早点发现项目里可能出的问题和风险。提前规划好，就能把做项目需要多少资源、得花多长时间，估摸得更准，项目开展起来也就更顺利。​
三、我以后要怎么做​
用 Scrum 框架：以后做项目，打算试试 Scrum 框架。把项目分成好多个短的小阶段，叫迭代，一般一个迭代也就 1 到 4 周。每次迭代开始，大家开个 Sprint 计划会，从产品待办事项清单里挑出这次迭代要做的任务，再列个详细的 Sprint 待办事项清单。迭代的时候，每天开个简短的站会（Daily Scrum），团队成员说说前一天干了啥、今天打算干啥，还有碰上啥问题了，这样消息能及时传，问题也能赶紧解决。​
团队协作更紧密：打破原来各干各的局面，组建个啥都能干的 Scrum 团队，大家齐心协力朝着项目目标使劲儿。每次迭代结束，开个 Sprint 评审会，给相关的人看看这阶段做出来的成果，听听他们的意见；同时再开个 Sprint 回顾会，团队成员一起说说这阶段有啥经验、有啥不足，下次迭代好改进。​
灵活处理需求变化：不再想着一开始就把所有需求都定死，而是通过产品待办事项清单灵活管需求。产品负责人按业务重要程度和优先级，给需求排排队、调一调。团队每次迭代都按最新的需求情况干活，就能更好地适应市场和客户需求的变化。​