一、瀑布式和敏捷式
瀑布式：阶段明显，重产品质量。工期比较长。
敏捷式：小版本迭代，速度快。产品质量无法保证。
二、项目管理常见问题
1、项目管理常见问题
缺少系统的管理理论和方法。
对项目的估计偏乐观。
需求分析、任务分解不够细致。
项目周期不合理，前松后紧。
2、研发常见问题
缺少统一的编码规范。
结构混乱，架构不合理。
滥用全局变量。
没有良好的注释习惯。
变量命名随意，含义不清晰。
缺少安全和性能意识。
研发缺少测试意识，代码质量无法保证。
跟风选择时髦的技术或者框架，遇到问题无法解决。
3、测试常见问题
项目前期无法展开测试，测试人员只能等待。
研发无法按期交付，压缩测试时间，最后牺牲质量。
没有很好的bug管理规范，只能口头、email和im跟踪。
缺少压力测试。
不做版本控制，混乱的代码库和开发环境。
4、沟通问题
项目启动后，产品经理消失，无人解释和确认需求。
遇到问题相互扯皮，强调这是其他人的责任。
一人负责一部分，知识难以传承，风险较高。
缺少团队合作，遇到问题不愿或不能请别人帮忙。
项目内部沟通不畅，每个成员只是埋头做自己的事情。
5、项目战略和组织常见问题
跟风，别人做什么，自己也做什么。
不专注，虎头蛇尾。
产品没有创新，模式没有创新。
等级划分太严格，管理人员拖累一线研发。
招人难，留人难。
三、敏捷价值观
敏捷宣言：
个人与交互 重于 开发过程和工具
可用的软件 重于 复杂的文档
寻求客户的合作 重于 对合同的谈判
对变化的响应变化 重于 遵循固定的计划
1、交付
目标是通过尽早且持续地交付有价值的软件来满足客户。
欢迎对需求提出变更，即使是在项目后期。
不断交付可用的软件，周期越短越好（1-4周）。
可用的软件是衡量进度的主要指标。
倡导可持续地开发，形成开发、销售和客户稳定的节奏。
2、沟通
业务人员与开发人在一起工作。
激励项目团队，给他们以所需要的资源，并信任他们。
最有效的沟通方法是面对面的交谈。
3、团队
团队的敏捷性依赖于对技术、过程和架构持续地改进。
保持简洁，尽最大可能减少不必要的工作。
最佳的架构、需求和设计出自于自组织的团队。
定期反省总结改进研发过程，并制定具体计划改进。
四、极限编程
（1）极限编程概念
1、极限编程5个价值标准
沟通：都是团队成员，面对面沟通，从需求到编码一起努力。
简单：聚焦于解决当下需求，不做过多设计，通过重构应对将来变化。
反馈：系统反馈（单元测试），客户反馈，团队反馈。
勇气：真实面对工时和进度，无惧失败，无惧将来变化。
尊重：尊重他人，提交可测试通过的代码，通过重构获得高质量的代码。
2、极限编程4个原则
快速反馈：系统反馈，客户反馈，团队反馈。
假设简单：简单设计，聚焦当下。
增量前进：小步快跑，快速迭代。
包容变化：拥抱变化，积极应对。
3、极限编程5个方面的规则
计划：用户故事，发布计划，小型发布，迭代开发。
管理：开放空间，可持续节奏，站立会议，评估速率，角色互换。
设计：简单设计，隐喻，原型，莫过早加入功能，重构。
编码：现场客户，规范，单元测试，结对编程，持续集成，集体所有。
测试：单元测试覆盖，发布前测试通过，bug先创建测试。
（2）极限编程实践
1、反馈
结对编程：质量，减少犯错，集体所有。
计划游戏：用户故事，优先级排序。
测试驱动开发：测试代码先行。
客户加入团队。
2、持续改进
持续集成：单元测试，持续集成服务器。
重构：非重写，每时每刻都应该进行。
小版本发布：小步快跑。
3、共识
编码规范：团队的共识，尊重，集体所有的基础。
集体所有权：消除单点，知识传播。
简单设计：参考unix设计哲学。
隐喻：意会，好的命名。
4、程序员福利
可持续地节奏。
5、编码
随时和客户沟通。
单元测试优先。
串行集成。
延迟优化。
莫加班。
6、测试
单元测试完全覆盖。
发布前单元测试全通过。
发现bug后先写测试用例。
定期执行验收测试并公布结果。
（3）极限编程好的实践
结对编程。
代码规范。
源代码管理。
代码review。
每日提交。
交叉测试。
重构。
分享会议。
简单设计。
自动化。
框架。
五、scrum
瀑布式：接力赛。
敏捷式：橄榄球。
（1）scrum精要
SCRUM聚焦于如何在最短时间内交付最有价值的产品。
SCRUM能让团队快速且经常地监督产品的进展。（2-4周）
每隔2-4周，就可以看到上线的产品，并据此作出调整。
团队按照商业价值的高低，优先完成高优先级的功能。
团队实施自主管理，持续改进团队内部流程，提升效率。
（2）Sprint
Scrum项目周期以一组迭代周期“sprint”组成。
可以和极限开发的迭代周期类比。
典型的迭代周期为2-4周或者最多一个自然月。
一个固定的周期能够创作出项目开发更优美的节奏感。
产品的设计、开发、测试全部都在一个迭代内完成。
（3）scrum并非小瀑布，它不是串行工作，而是以并行的方式每次完成一小部分需求、设计、代码、测试。
（4）确保迭代进行中不受影响，新的需求和需求变动往后排队等候。一个迭代周期的长短设定取决于你能保障多长时间需求变化不影响到产品开发。
（5）产出 PRODUCT BACKLOG
从产品需要完成的功能列表。
一般用用户故事来组织。
每一个用户故事都应创造价值。
产品所有者负责整理故事列表，对其价值进行排序。
产品所有者应指定发布计划。
根据实际的情况动态调整需求的排序。
（6）SPRINT BACKLOG
每个人领取自己想要完成的功能，不是单纯分配。
每个人任务有明确的负责人和初始的估计。
对于剩余工作量的估计每天需要更新。
团队成员都可以添加，删减或更改迭代中的任务。
网友评论