这一周，老师让我们做了有关于数组的动态规划问题，我们遇到的问题就是只能想出复杂度n*n的算法，可是题目要求确是时空复杂度为n的算法。最后问了一下班上的大牛同学，教会我一个动态规划的问题。其实我觉得和递归有点一样。

这周我读了构建之法的第六章，关于敏捷的流程。那什么事敏捷的流程呢？我也是第一次听说，书上的定义是--敏捷的流程是一系列价值观和方法论的集合 。敏捷开发的原则包括：1.尽早并持续地交付有价值的软件以满足顾客的需求。2.欢迎需求的变化，并利用这种变化来提高用户的竞争优势。3.经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。4.业务人员和开发人员在项目开发过程中应该每天共同工作。5.以有进取心得人为项目核心，充分支持信任他们。6.无论团队内外，面对面的交流始终是最有效的沟通方式。7.可用的软件是衡量项目进展的主要指标。8.敏捷流程应能保持可持续的发展。9.只有不断关注技术和设计，才能越来越敏捷。10.保持简明尽可能的简化工作量的技艺极为重要。11.只有能自我管理的团队才能创造优秀的构架，需求和设计。12.时时总结如何提高团队效率，并付诸行动。这些原则让我对敏捷开发有了自己的理解，敏捷开发是极大程度的满足市场的需求，并在满足需求的基础上再实现自我技术上的超越。那如果我们要用敏捷开发，我么应该怎么做？书中介绍了敏捷开发的步骤，第一步，找出完成产品需要做的事情--product back-log。第二步，决定当前的冲刺（sprint）需要解决的事情--sprint backlog。第三步，冲刺（sprint），外部人员不能打扰内部人员，要注意“集中精力”和“交流”的矛盾。在冲刺阶段，每天要开一个每日例会，报告：我昨天做了啥?我今天要做啥？

   但是再美妙的理论在实践中都会碰到这样那样的问题，比如，各个需求之间是有优先等级的，单除了优先等级之外还有相互之间的依赖关系，那怎么在计划中体现依赖关系呢？

把一个任务从产品层级的描述逐步细化到技术实现层面，是很需要技术能力和交流能力的。成员任务分配不均的情况又怎么办？每日例会中每天遇到的问题有可能流于形式了有怎么办？书中说每天跟踪三个时间值：实际剩余时间，预估剩余时间，实际花费时间。这样才能在实践中脱颖而出。一个敏捷的团队要怎么衡量，包括下面的条件：1.自主管理。2.自我组织。3.多功能型。但是一个团队只有在团队很强的基础上才能转变为敏捷团队。看了《构建之法》才了解到软件开发原来有很多种思想，所以要多学习，多了解，才能让自己的知识库不断更新不断丰富。