一，软件的质量和软件管理，软件技术的关系：
项目管理的最终目标是和软件工程的目标都是为了项目高质量的完成。项目的成败光靠项目管理是解决不了的，保证软件项目的真正成功需要软件工程的支撑才行，项目管理中不会有设计、抽象、可维护性等内容。
目前衡量软件项目的质量忽视了代码的质量，客户验收、功能完成、稳定上线，没耽误进度就算是完成了一个项目，却忽视了代码的质量。
有相关帖子表明：质量直接决定了项目进度，当代码质量越来越差的时候就失去了对项目进度的控制。再多的度量指标都是无意义的，就算可以统计出BUG数上升了，但是控制不了BUG数下降，因为已经偏离正常航线太远，就算可以控制需求变更的速度和次数，但是无法控制适应变更的代码的速度和次数。变更是无法避免的，代码无法面对这些复杂的变化，因为代码不是设计出来的而是堆出来的，导致最后项目质量也无法很好的保证。
因此，作为应用开发人员，我们日常学习代码，写代码的时候需要有专业的职业素养，写代码需要有追求，寻找更好，更优的解决方案，梳理并重构自己写过的代码，使其逻辑更清晰，而不只是测试后完成了相应的功能—“能跑就行”。
（内容源自：王清培）
二，敏捷开发:
1.敏捷开发是什么：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发，它是一种开发方式（过程）而非开发技术。一次迭代的周期大致是1个月时间（4个星期），在开发过程中团队成员一次迭代的开发内容需要以最快的速度完成。迭代就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。
2.敏捷开发通常与瀑布模型（传统）对比：
瀑布模型会提前规划大型项目，并根据计划完成它们。在传统的瀑布模型中，需要写大量的文档（需求分析等文档），一切以文档内容进行开发。然而敏捷开发更强调人与人交流时产生的需求，强调更有效地使用文档，写必要的文档，可以写在wiki系统。
3.敏捷开发的具体方式：
通常有Scrum和XP两种方式，Scrum偏重于过程，XP则偏重于实践。
Scrum主要角色：
产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写用户故事，排出优先级，并放入产品订单。Scrum主管（或促进者）促进Scrum过程，他的主要工作是解决那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。Scrum主管确保Scrum过程按照初衷进行。Scrum主管是规则的执行者。开发团队是负责交付产品的团队。由5至9名具有跨职能技能的人（设计者，开发者等）组成小团队来完成实际的开发工作。
Scrum 定义了一种称为“每日Scrum”的做法，通常称为“每日站立”。 每日 Scrum 是限制为 15 分钟的日常会议。 团队成员经常在会议期间站立，以确保保持简短。 每个团队成员都简要报告了他们自昨天以来的进度、今天的计划，以及任何阻碍他们进步的事情。
4.敏捷开发适用场景：
1、敏捷开发属于增量式开发，对于需求范围不明确，需求变更较多的项目而言，可以很大程度上响应及拥抱变化。
2、对于互联网产品而言，市场风向转变很快，需要一种及时快速的交付形式，而敏捷开发则能更好地适用于此。
3、敏捷开发可最大程度体现80/20法则的价值，通过增量迭代，每次都优先交付那能产生80%价值效益的20%功能。能最大化单位成本收益。
5.敏捷开发的原则：
快速迭代（小版本的需求、开发和测试）；让测试人员和开发者参与需求讨论（可以更加轻松定义可测试的需求，将需求分组并确定优先级）；编写可测试的需求文档（先主要关注需求，其次再关注实现技术）；多沟通，尽量减少文档；用草图和模型来做好产品原型；尽早考虑测试（可以尽早发现需求中存在的问题）。
posted on
