我们的最高目标是,通过尽早持续交付有价值的软件来满足客户的需求。
一般产品只有20%左右的功能是用户常用的,即对用户有价值的,为实现其他80%功能的投入被视为浪费;同时对客户无用的功能不仅不会产生价值,反而会让客户反感、甚至放弃使用整个产品;所以交付有价值的功能或产品是最基本的要求;
尽早地交付产品,小则可以通过客户的反馈尽早发现产品的调整点,减少后期的不合理成本投入;大则可以及早调整产品策略或先于竟争对手抢占市场,进而让产品获得更大成功;
持续地让“尽早”交付“有价值的”产品的能力具备持续性,而不是建立在一种临时突击的策略上,好比打了兴奋剂能跑得更快,但是好名次不能总靠打兴奋剂得来;
另外持续交付产品一方面可以满足用户持续增长或改变的需求,另一方面任何一个产品都不可能一次做完美、只有通过持续优化才能越来越好,越来越符合用户的使用。
欢迎对需求提出变更,即使在项目开发后期也不例外。敏捷过程要善于利用需求变更,帮助客户获得竞争优势。
要经常交付可用的软件,周期从几周到几个月不等,且越短越好。
这条里的“不断”、“可用”“越短越好”与第一条的“持续”、“有价值”、“尽早”上的表达的应该是一个意思;只是说的更具体明了一点、同时特别强调了周期越短越好,较短的迭代周期为团队提供架构并强化团队持续关注客户的价值;
对于“越短越好”,需要有个“度”,这个“度'是要用户能接受的;不同业务特点、用户特点、反馈方式让这个“度”会不同,需要我们灵活的去判断。
Scrum的迭代周期大概为一个月,XP的迭代周期会短至一周。
频繁的交付,项目团队可以得到更多的商业机会和反馈。通常在交付演示时,项目团队会得到新的业务优先级的变更要求,这都是很有价值的。
项目实施过程中,业务人员与开发人员必须始终通力协作。
业务人员和开发人员是一个团队的不同角色,要像一个团队那样工作;他们最好物理空间上在一起,可以迅速达成有效的沟通合作。
开发人员通过每天和业务代表的共同工作,开发团队对业务的学习速度远远超过通过需求收集会议中对业务的理解。
当业务代表和开发团队不能每日在一起交流敏捷方法经常尝试的方法是将两个工作小组一起工作,或者使用“代理客户”(他们对相关业务的商业分析非常的有经验,将“代理客户”作为商业代表的替身。
要善于激励项目人员,给予他们所需的环境和支持,并相信他们能够完成任务。
我们不能总是挑选出我们梦想的团队,我们可以做的是尝试去激励团队成员。团队作为项目的一个重要的因素,敏捷方法促进鼓励团队成员。当员工开始自组织和计划工作,他们会工作的更好。敏捷方法主张将团队从微观管理和甘特图中的任务重释放出来。取而代之的重点是工作技巧、平等合作和团队合作,将会提高生产率。
知识性项目也包含有特殊经验和技能的成员。如果允许开发团队可以更好的做出日常决定和处理本项目的计划。这不意味着我们放弃和抛弃了项目团队反而是认为项目团队中每个成员都是专家,可以为项目的成功做出支持。
无论是对开发团队还是团队内部,信息传达最有效的方法都是面对面的交谈。
写文档是记录事件和决定的好方法,但缓慢的速度也会造成高额的生产成本。相对比的是,面对面的沟通可以快速传达大量的信息,也包括表情和肢体语言。
在面对面的会谈中,问题可以立刻得到解决的答案,而不是暂时搁置问题等待解释或者答案会过一段时间再反馈。
当然,在此推荐的面对面会谈不能运用于所有的沟通场合,但是应该尽量遵循。随着团队规模的不断增长,面对面的沟通将会越来越难去组织,就需要引入适当的文档要求。
可用的软件是衡量进度的首要衡量标准。
敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保持步调稳定。
对于时间长而且紧张的开发阶段,敏捷方法认为保持稳定的进展速度的价值在于允许团队成员有工作和生活的平衡。不仅对团队有好处,对于整个组织也会带来益处。过长的工作时间会导致员工的辞职,组织也会失去很多才能和知识。重新雇佣和整合新的成员都会是一个缓慢和高成本的过程。
保持一定的工作速度可以创造一个更加开心和高效的团队。开心的团队也比过劳团队给业务代表带来更多的正能量。这里有更少的紧张压力,会提高工作关系。就类似极限编程(XP)推荐保持每周40小时的工作时间。
对技术的精益求精以及对设计的不断完善将是高敏捷性。
当我们希望开发团队可以努力工作并且提交大量有价值产品,我们同样必须注意保持设计的清晰、高效、和对变更的开放性。精艺的技术和良好的设计会使产品或开发团队更早的理解和更新的设计。
在软件世界中,一旦编程的基础紊乱了,组织将丧失对变更响应的能力换句话说。丢失了敏捷性。所以我们需要给开发团队足够的时间来组织重构。重构就是类似于家政清洁、打扫清理、和简单化,使编码更加稳定和维持更长的时间。
对于一个项目需要平衡精力在持续关注于解决方案设计的高价值特性交付物上。这种平衡将使系统交付长期的价值,而不是难以维持、难以变化和扩展的。
简洁,即尽最大可能减少不必要的工作,这是一门艺术。
最为可靠的特性我们尚未完成-但是好像也没有什么做错的。然而,在软件世界里,完成的多达60%的功能是很少使用或者从不使用的。
很多的功能并没有实际的使用,而且复杂的系统更有潜在不可靠情况,敏捷方法注重于简洁。这意味着只完成必要的元素。不为未来的需求写代码,不为写文档而写文档当是专注于如何用最简单的方法解决现在的问题,尽可能的减少浪费的产生。
完成复杂的项目会用时更长,会暴露出更长的风险视界( horizon of risk),会带来更多在失败点和更多成本泛滥的风险。因此,敏捷方法寻求可以允许工作的最简洁品并推荐为首先完成的解决方案。
最佳的架构、需求和设计将出自于自组织团队。
团队要定期反省怎样做才能更有效,并相应地调整团队的行为。
在项目最后收尾过程来进行学习,太少也太迟了。我们应该在项目进展的时候进行收集和学习。这意味着在项目的进行中要对已经完成的任务进行学习和调整,为剩下的项目工作做好准备,这点非常重要。
多次回顾的好处在于可以注意很多可能被遗忘的细节。相比较项目单次的复习而言,在很长时间后,团队成员很难记得项目在哪里做的好,哪里出现了问题。团队通过定期的反省,找出可以改进的方向并据此调整团队的行为,以团队认可的方式不断修正达到目标的路径,保持团队的敏捷性。
定期的回顾会议与反省是让团队成长和进步的最好的机会。
