敏捷开发经验：bigtall的敏捷日记
“闪亮快乐人”通过精心收集，向本站投稿了9篇敏捷开发经验：bigtall的敏捷日记，下面小编为大家整理后的敏捷开发经验：bigtall的敏捷日记，欢迎阅读与借鉴!
篇1：敏捷开发经验：bigtall的敏捷日记（1）
虽然接触敏捷已经很久很久了，零零碎碎实施过，但是始终没有机会将传统的项目管理方法彻底抛弃，现在终于决定要彻底投入敏捷的怀抱了，为此我准备了整整一年的时间。我将会在这一系列的文章里，请你和我一起分享这个改变的过程。
传统的scrum方式有三个角色：产品经理(Product Owner)，scrum教练(Scrum Master)和组员(Team Member)。因为我们以产品研发为主，所以在角色上有一些改变：
1、把产品经理的角色分散到每一个组员，但是保留一个经验比较丰富的人专门对backlog进行验收
2、把scurm教练的保持SCRUM流程的那一部分职责分离出来，作为“教练”的角色。教练一般是其他部门的人(比如项目管理部)担任，负责对敏捷过程中产生的任何问题进行纠正和解答
3、保持传统的项目经理角色，负责backlog的分解和任务跟踪事项。
目前公司有两个项目在进行scrum方法的实施，A项目已经完成了两个迭代，B项目刚刚完成了一个迭代。两个项目各有特点，A项目是他们的部门经理直接找我，让我担任他们的scrum教练，而B项目则是因为被批工作分配不饱满，才找到我让我知道实施敏捷方法。正是因为前提的不同，导致了两个项目的实施效果也有一些差异。考虑到两个项目支持力度的差异，所以我也给两个项目安排了不同的实施方法。
对于A项目，我采用的方法是这样的：
1、A项目除了实施Scrum之外，还加入了“结对测试”，具体的结对测试方法，可以参考我今后几天的文章
2、没有使用软件，而是使用了传统的scrum card的游戏方法，但是指派专人对数据进行同步
对于B项目，我采取的方法是这样的：
1、仅仅进行scrum方法的实施，没有结对，
这么做的另外一个方法是该项目处于项目收尾和新版本开始前期的研究阶段，可以协作的工作比较少。
2、使用软件进行scrum记录
另外，两个项目都采用的方法如下：
1、前期仅对backlog进行评估point数，每个point对应0.5个工作日。但是不要求对分解的task进行评估
2、每天要开站立会议，A项目选择在早上9点，B项目选择在下午5点
3、每一个sprint开始于计划会议，结束于回顾会议
4、在回顾会议之前要有一个产品演示会议
刚才已经说了，两个项目因为采用scrum的前提不同，结果相差也比较大：
1、A项目因为是自发的行为，他们的PM在此之前自己零碎实验了将近3个月，所以实施效果也相对较好
2、B项目有一点临时抱佛脚的意味，所以在实施过程中比较松散和随意。
不过两者都有如下几个共同点：
1、队伍士气非常高昂，尤其是A项目，明显看到工作效率的提升
2、团队成员都比较认同Scrum的方式，认为比之前的项目管理方法有了质的提高
3、我个人感觉，只要使用了scrum方法来管理项目之后，没有人再愿意回到以前的管理方法中去了
(待续)
篇2：8044敏捷开发方法
一句话评论：复习一下敏捷的12条原则，然后看看，Marty如何理解产品经理在“敏捷团队”里的角色定位，
Marty Cagan 发表于6月1日，原文地址，译者：蒋彬 / 审校：周舜莉 徐定翔
许多产品开发机构都尝试过所谓的“敏捷软件开发”方法，其中最为流行的是“极限编程”（XP），此外还有其它一些敏捷方法，比如Crystal、Adaptive、Scrum和Pragmatic Programming等。
在使用这些敏捷方法时，产品经理常常弄不清自己的角色定位。有些产品经理甚至担心采用敏捷方法会影响产品质量。
我打算首先总结敏捷开发的核心原则，然后以极限编程（XP）?为例，指出极限编程的难点，以及如何更好地发挥它的作用。
敏捷方法一览
各种敏捷方法的要求千差万别，但是它们都遵循以下12条原则。?
1、最重要的是通过尽早地、频繁地交付有价值的软件来满足客户——尽早交付有价值的软件。
2、?频繁地交付可运行的软件，数周或者数月交付一次——频繁发布新版本。
3、可运行的软件是衡量进展的主要标准——软件比文档更重要
4、接受?需求变更，即便是在开发最后阶段——倾听，并快速学习
5、项目期间业务人员与开发者共同工作——紧密协作?
6、找积极主动的人来开发项目——为他们提供所需的环境和支持，相信他们能做好自己的工作
7、开发团队里最节省时间最有效的信息传递方式是面对面的交流
8、?自发组织的团队才能做出最好的架构、和设计——架构要敏捷，好主意无处不在
9、?持续关注先进的技术和优秀的设计能促进敏捷性——频繁地重构
10、?敏捷过程促进可持续的开发——此举应能维持相对稳健的节奏——而不是?导致失败
?11、简洁是一切的基础——少即是多
12、?团队定期反思如何提高效率，并调整?工作流程——事后反思?
极限编程概览?
要阐述?遵循敏捷方法到底意味着什么，?不妨看看敏捷方法中最为流行的极限编程的详细规范。该方法的发明者强调，极限编程并非万能，应该有选择性地加以使用。其主要原则如下。
-结对编程——两位程序员使用同一台电脑开发同一款软件
-简单设计——只设计和开发你现在就需要的东西，不考虑将来的潜在需求
-现场客户——客户代表入驻开发团队，他代表了所有产品的需求，在开发过程中不断的说明需求并帮助决策
-增量开发——频敏小规模发布产品?，快速推动产品?进入理想状态
-做好规划——工程师只做评估，客户决定?每次发布的功能和时间
-持续评审代码——基于结对编程的模式，两位开发者相互评审对方的工作
-持续测试——开发者在编码时就撰写单元测试，客户则撰写用例中规定的功能测试，?这些测试均是自动、持续地进行
-持续构建——持续开发和整合软件，这样能及早发现问题，系统也一直处于可构建的状态
-持续重构——软件开发人员不懈努力，通过重构代码来简化和改进工作，同时保证所有测试正常运行?
-代码共有——与每个开发人员“独享”?自己的代码这一模式不同的是，极限编辑模式中每个开发人员只要认为有机会有必要，就可以优化系统中任意处的任意代码?
-开放的工作场所——指整个团队都在一个在房间里共同工作，其中开发人员坐在中间
-每周工作40小时——限制加班以提高工作质量?
-代码即文档——最有用的文档就是软件本身，整个团队应该遵循编码规范
当然了，这种方法是从软件开发人员的角度提出来的，
在他们看来，除了程序员和用户（客户），就不需要其他工作人员了。这正是让产品经理感受担忧的地方。?
产品经理的工作至少包含以下三个方面。?
定义产品
首先弄清楚要开发什么产品。极限编程方法是针对定制化软件项目提出来的，目的是满足特定客户的特定需求（比如内部员工薪资系统），它并不适用于通用产品。事实上，在描述极限编程方法的图书和文章里，几乎很少提及产品管理或是界面设计。
最让人担忧的通常产品经理能否代替现场客户的作用。只有在深入研究目标用户、理解用户需求、使用环境以及竞争格局，产品经理才能发挥最大的作用。
更让人担心的是产品设计（界面设计）角色的缺失。对于产品来说（不同于那些签署合同后开发的定制软件），用户界面和用户体验至关重要，需要专业设计师运用其专业技能进行设计，因此在工作流程中引入这一重要职位非常重要。
只要把最初的迭代作为持续演进的原型并不断检验，以确保开发团队能开发出正确的产品，然后再在接下来的迭代中实施产品执行，就能更好地利用极限编程方 法。关键是确保你开发的产品是客户想要购买的，而且客户能搞清楚该如何使用。只有一个客户或是产品经理理解这个产品并不足够，它应该为目标市场的广大群体 所检验。
开发产品
其次要考虑的是，??这些用来开发可扩展、?高性能、可靠、易维护产品的技术会带来什么样的后果。这些担忧使人马上陷入一种近乎宗教狂热的争论，争论的重 点是，什么才是开发和测试软件的最佳方法，而这完全在产品管理职责之外。?产品经理?只需要清晰地确定需求，然后让技术团队按自己认为最合适的方式来控制 风险。?
极限编程过程依靠客户来定义用例（又被称为用户故事）?，以此作为功能测试的基础。这用在小型项目上或许还不错?，但如果是大型、通用产品的话，有必要请 专人来负责设计必要的测试用例，以确保可扩展性、功能、性能、容错性和本地化特性等。这些通常都是QA的职责，极限编程的方法完全也可以借鉴。关键是让开 发人员负责单元测试，QA人员负责其它测试（比如系统、集成和功能测试等）?。?
部署产品
最后一个为人们所关注的，是产品的发布。人们长期以来一直认为随着时间的推移，做出改变的成本也越来越高，但极限编程挑战了这一看法。换言之，只要遵循极 限编程实践，你可以降低开发中系统需要变更带来的影响。这对于定制化软件来说这没错，但对于许多商业软件产品来说，变更带来的影响仍然很大，尤其是对于拥 有大量活跃用户群体的互联网服务来说。
我曾经探讨过“平滑部署”的?策略，这些方法有助于降低极限编程项目所提倡的频繁发布和更新策略所带来的负面影响。
?总结
大到敏捷开发，小到极限编程方法，都是为了解决传统软件开发方法中的实际问题而创造的，尤其是致力于增强开发人员与客户的沟通，节省时间及早弄清楚你所开发的产品是否正是客户需要的，并减少增量开发过程中的风险，同时优先开发高优化级的功能。此外还有另外一些颇有价值的技术，尤其是结对编程、增量开发、持 续集成与自动化测试等。?
?然而，对于提供商用产品及服务的公司来说，更重要的是将这些方法与产品管理、产品设计、质量保证结合起来，确保你开发的产品能为广大用户和消费者使用。这样的话才能覆盖较广的消费者群体。
本文节选自《启示录：打造用户喜爱的产品》作者Marty Cagan的博客。该书从人员、流程、产品三个角度介绍了现代软件（互联网）产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。
VN:F [1.2.0_562]
篇3：关于敏捷开发的一点小想法
针对最近又比较火热的敏捷开发，我有一些个人的想法和认识，粗浅之处，还请大家指教了，
个人不太感冒，或者说持观望态度吧，原因如下：
1、首先概念是国外提出来的，是英文的，翻译成中文往往就会有质的区别，中国人喜欢歪曲外国人的概念，也可能是翻译的问题吧
2、敏捷开发对个人素质的要求是很高的，国外的软件人员要比国内的专业很多
3、对环境的要求也很高，国内环境还不成熟，有待提高
不过个人认为，还是可以在一定程度上使用敏捷开发，但不是一味的追求概念上的一致和做法上的一致如果只是追求形式上的敏捷，有可能造成类似大跃进的闹剧来。
评论
#2楼-05-21 00:26Mien
“概念是国外提出来的”我们就不学？
“国外的软件人员要比国内的专业很多”真的？
“对环境的要求也很高，国内环境还不成熟”不能苟同。
呵呵，凡事积极并力求客观对待－－个人意见，不必参考。
#4楼 [楼主]2008-05-21 09:05virus
@Mien
@Mien
谢谢
1、概念是国外提出来的，我们要选择的学，不是一概而论的学习，而且要修正很多的东西，比如说方式或者思路什么的，要是照抄不就是拿来主义了吗
2、不得不承认，国外的软件人员普遍要比国内的专业，这个你可以问一些有国外工作经历的
3、是啊，所以我没有苛求环境，我说的就是要根据国内环境变通地学习敏捷开发
#5楼2008-05-21 09:08程序小斯 [未注册用户]
楼主大概还不了解每捷开发的真正内涵吧
敏捷，是一种理念，并不是一种形式
#6楼2008-05-21 09:24小寒
敏捷开发重要的是理解其内涵，具体的表现形式可以依据具体的情况来定
要推行敏捷开发的思想，
首先要让其成员接受敏捷开发的思想，接受这种理念
然后再一步一步地进行从过程开发到敏捷开发的演变
#7楼2008-05-21 09:58坏人
理解好敏捷的思想后，你将不会要求自己把敏捷的手段全部用上，
敏捷代表着灵活与不拘泥。
倘若你只单单去执行敏捷方法论，可能真的会弄巧成拙。
#12楼2008-05-21 10:56球球
敏捷不算是什么新的东西，七年前就开始了，不用太担心。
怕英文变成中文有问题，那就看原版书吧。
国外的普通的软件人员也不一定就比国内强，只不过顶尖的软件人员比国内强，而且人数相对多，敏捷现在最大的问题不是程序员的技术问题，而是有没有客户肯和你玩敏捷的问题。
环境是大家创造的，有条件的话在自己的一亩三分地先在小工程上试验试验好不好用总是应该的，我还是比较看好敏捷的。
#14楼2008-05-21 12:46金色海洋（jyk）
关键看客户是否配合，好像敏捷是根据工作时间来付钱的，现在国内的客户都不会这么认为吧。客户不愿意付钱，那还怎么玩呀？
敏捷对程序员的要求会更高。
#15楼2008-05-21 13:35炭炭
谁说只有素质高，环境好才能用敏捷？
敏捷恰恰是解决你素质不高，环境不好的问题的。
只能说你的客户好糊弄，你对优秀设计追求不高，所以你看不出敏捷的优势
#16楼2008-05-21 13:56路人丙
其实说到底是人的问题，敏捷对程序员跟客户都要求“专业”...
#17楼2008-05-21 16:03坏人
说敏捷要专业要钱要什么什么的，感觉对敏捷的理解只停留在方式方法上。
敏捷开发不仅仅是一个方法论，更是一种思想论。
#20楼2008-05-21 16:05紫色阴影
1. 有多少是国内提出来的？
2. 我们公司很多是应届毕业生，没有开发经验，学了一段时间也很熟练 我也是敏捷新人 呵呵
3. 什么环境？
来自：关于敏捷开发的一点小想法
篇4：敏捷开发的主要原则都有哪些
敏捷开发的主要原则都有哪些
1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意，
2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3.经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4.在整个项目开发期间，商务人员和开发人员必须天天都工作在一起。
5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的.交谈，
7.工作的软件是首要的进度度量标准。
8.敏捷过程提倡可持续的开发速度。责任人(sponsors)、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9.不断地关注优秀的技能和好的设计会增强敏捷能力。
10.简单——使未完成的工作最大化的艺术——是根本的。
11.最好的构架、需求和设计出自于自组织的团队。
12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
篇5：敏捷拥护者眼中敏捷开发的常见问题
近几个月来，关于Scrum、技术负债、质量等等问题的争论一直无休无止，先有James Shore的敏捷的衰落一文，而后Martin Fowler在博客上发表了Flaccid Scrum，指出Scrum教练应该承担更多的责任，在推广Scrum的同时，也不能忽视技术实践。Uncle Bob和Ron Jeffies也分别发表文章（Dirty Rotten ScrumDrels，Speed Kills，Context, My Foot，Quality-Speed Tradeoff, Are You Kidding Yourself?）表示类似的观点。
一些敏捷实践者在盐湖城的敏捷圆桌会议中也对敏捷开发中的常见问题进行了讨论，Sean Landis会后在个人博客上总结了常见的十一个问题：
1. 技术负债在敏捷团队中会快速的膨胀。2. 敏捷软件开发团队会想当然地认为每个团队成员都专业，称职并富有责任心。如果事实不是如此，项目开发很快会变得举步维艰。
3. 由于对敏捷开发实践的错误理解，导致团队不合理地频繁交付，疲于奔命。
4. 实施敏捷的门槛太高，敏捷开发需要更强的团队和个人的纪律性，勇于承诺和高度的公开性，但对一个不成熟的组织来说这个门槛太高。
5. 绩效差的团队成员很难在高度公开的敏捷团队中掩饰自己能力的不足。好的团队往往能够采取一定的措施来帮助这类成员。但如果没有采取措施，这些成员往往会想方设法通过消极怠工来掩饰自己能力的不足。
6. 敏捷团队容易过份关注眼前的短期目标，而忽视长期的战略目标。尽管在短期内能够取得成功，长期注定还是会失败。
7. Product Owner承担了太多的责任，不堪重负，从而成为团队的瓶颈。
8. 敏捷的效用被过度夸大，大家的期望值太高，很多人认为导入敏捷能以最小的投入解决实际开发中的所有问题。
9. 可能出现另一种形式的“相互诟病”。成功的敏捷开发团队一般不会成为产品开发的瓶颈，因此其他部门不能以这个为借口来指责开发团队，但是这有可能进一步演变成为政治游戏。
10. 当Product Owner开始决定开发的方向，他就会被过度授权。敏捷开发中缺乏足够的审查和平衡机制。
11. 敏捷实践大多是针对程序员的，很难在组织内平衡工作量。缺乏对团队中的非程序员提供更好的文档以及培训支持。
Chris Tyler在个人博客（注，可能需要爬墙）中针对这些问题做出了回答。
问题一，是事实，但这并不是敏捷本身的问题，只不过是在敏捷导入和实施过程中没有引起足够的重视。经验丰富的敏捷教练往往十分重视工程类实践，会强调重构在迭代中的重要性。很多的敏捷实践(比如TDD，持续集成，重构)及很多敏捷开发者提倡的原则(比如S.O.L.I.D原则，Clean Code,Implementation Patterns )都能帮助敏捷团队避免过多的技术负债。Uncle Bob甚至认为应该在最初的敏捷宣言中加入第五条原则“Craftsmanship over Crap”，来强调技术的对成功的敏捷项目的重要性。问题二，是事实，但这恰恰又是敏捷的卖点。我们应该做到：谦虚有耐心；勇于承诺；团队成员互信互助，而不是互相指责批评；承认自己的能力不足，不断追求进步，需要的时候寻求团队成员的帮助。很多方法论认为只能通过审查监控的手段来确保项目的顺利运行，而敏捷团队更多的是依靠个人的责任心。在优秀的敏捷团队中，能力较弱的的团队成员会感受到来自其他成员的压力，要不然尽力做好，要不然只有走人。
问题三，说老实话，在了解敏捷之前，研发团队才是疲于奔命。敏捷原理打破了传统的思维模式。人很容易犯错误，但是很多敏捷实践(结对编程，持续集成，TDD)能够帮助开发团队及早发现问题，纠正错误。因此敏捷反而把我们从传统的思想束缚中解脱出来。可能是由于对敏捷的过度宣传，导致大家对敏捷期望值过高，认为敏捷开发是解决所有问题的万灵药。其实我们导入敏捷也是受种种因素（客户环境，团队对敏捷的认识程度，成员的能力）限制的。如果能够从其他更成熟的敏捷团队或者敏捷教练那里吸取经验这样会更好，否则只能合理的逐步的导入实践。很多敏捷项目确实存在过于频繁的交付，那是由于人们迫于各种压力，“好大喜功”的天性而忽略了敏捷其实一直在强调的“根据每个迭代能够实际发布量”（也就是真正能够达到Done标准的工作量）来调整下一个迭代工作量，
管理资料
如果团队不能自主调整工作量，这其实已经偏离了敏捷。
问题四，是事实。但是这并不意味着不能在不成熟的组织中导入敏捷实践。这类组织可以逐步地导入敏捷实践。很多人太过心急，想“一口吃一个胖子”，但这往往是不切实际的。当然，同时必须要注意的是，不能因为采取逐步导入的手段，而降低敏捷定义的门槛(Ron Jeffries有一篇文章“Agile Is, Not, Maybe”)。
问题五，绝对是事实，敏捷需要勇气，但是这绝对是好事。态度决定一切！敏捷团队所不能容忍的是那种故意偷懒的成员。每个人都会经历从学徒到专家的过程（获得技能的Dreyfus模型，及Apprenticeship Patterns: Guidance For The Aspiring Software Craftsman）。由于每个人的能力不同，背景不同，能达到的高度也是不一样的。团队成员应该承认个体差异，努力帮助较弱的团队成员，使其快速成长。
问题六，可能是事实，但是这在非敏捷团队中也屡见不鲜。不可否认的是在敏捷项目中，很多人过分强调了YAGNI，因而在早期忽视了一些战略性的目标，尤其是业务需求目标，从而导致后期重构十分困难。YAGNI是很有用的，但是需要其他实践比如TDD和BDD（行为驱动设计）的支持。Kent Beck在极限编程一书中讲述了怎样借助TDD，实现演进式设计。另外需要注意的是，这其实在很大程度上是一个平衡的问题，怎样在YAGNI与预先设计之间做平衡。
问题七，也是事实。但是作为对产品最有热情的人，Product Owner难道不愿意花时间和精力帮助团队开发出符合需要的产品么？敏捷极大地缩短了从需求到软件的周期。再也不会出现Product Owner等上6个月或者更长的时间，结果发现做出来的并不是自己想要的东西的情况。Product Owner可以在短时间内就能看到软件，及时作出调整，因此敏捷极大地减少了开发成本以及相应的机会成本。公司高层的支持也是十分必要的。没有高层的承诺和授权，不可能组成全功能的团队。
问题八，这可能也是事实。其实在其他方法论风行的时候，也遇到过类似的批评，比如RUP。大家都期望找到一种能够解决所有软件开发痛苦的方法论。作为有经验的敏捷实践者，教练，经理和架构师，对敏捷的宣传应当适度，尽管敏捷确实能够解决很多软件开发中遇到的问题，但是它毕竟不是万灵药。不要使他人有过高的期望。
问题九，这绝对是事实。Chris Tyler提出的建议是，尽早与其他部门沟通，大家的最终目标是一致的，各个部门应当一起寻找生产系统的瓶颈，然后努力突破瓶颈（参见约束理论）。基于这个共同目标，各个部门一起对流程进行修改，就会减少相互诟病。
问题十，这并不是一个问题！Product Owner应该控制产品发展的方向。Product Owner应当熟悉业务，明确他最终想要什么。尽管开发团队要利用技术手段，提供解决方案，满足业务需求。但作为开发团队不应该对业务方面干涉太多。
问题十一，对于这个Chris Tyler既同意也不同意。敏捷团队是全功能的团队。如果业务分析师、Product Owner没有和团队在一起参与开发，那不是真正的敏捷。敏捷教练、经理也应该承担培训团队中除了工程师以外的成员的职责。对某些团队来说，文档会是一个问题，因为客户总是要求开发团队提供文档。其实行为驱动测试BDD就是一种既能够提供需求文档又能够照顾到代码实现的好方法。敏捷中也有文档（参见“敏捷的文档”），只不过是文档的形式发生了变化，变成了XUnit测试以及代码。进一步BDD可以成为业务人员和开发人员的桥梁，能够使业务人员更好地理解XUnit测试以及代码（另外其实还有Fit）。对于已经习惯于基于类似于IEEE的那种需求管理方式的Product Owner和公司高层们，对开发文档形式的改变，他们应当保持开放和学习的心态，充分信任团队，而不是给开发团队带来阻碍。
最后，Chris Taylor总结到，敏捷理论很美好，但是实践起来还是会有各种各样的问题，也有可能失败。其实理论描述的是理想情况，实际情况往往不尽相同。但是我们不能因为这个就放弃向理想努力。尽管过去有很多团队导入敏捷失败，我们还是不能全面否定敏捷，毕竟也有很多成功的敏捷团队。正如敏捷项目团队在开发中不断进行反省修正一样，我们也要通过反省来加深对敏捷的理解和认识。
作者简介：滕振宇（ Daniel Teng），Irdeto BSS高级软件经理，CSP。对Scrum、精益软件开发、系统架构设计、领域驱动设计有多年研究，有着丰富的实践经验以及教练经验。创建并领导 Irdeto BSS上海开发团队并成功导入Scrum以及极限编程的一些实践。
来自：www.infoq.com/cn/news//03/agile-traps-and-pitfalls
篇6：安全代码开发：敏捷的牺牲者？
敏捷团队以快速产生可靠和高质量的代码而著称，然而，快速交付的压力可能会导致走捷径的评审，缩减测试并缺乏对安全代码的重视。安全开发与敏捷共存是否只是一厢情愿的想法呢？
根据一项中小型企业的研究表明，敏捷团队并没有把安全当回事，即使是开发通过Web访问的系统。该研究引用说，
采访表明，小型和中型的敏捷软件开发组织不使用任何特定的方法来实现安全目标，即使当他们的软件是面向Web的，是潜在的攻击目标。这种情况下，研究证实即使在某些案例中安全是被明确要求的，安全设计作为实施团队的输入要求之一，最终的结果是否满足安全目标也没有保证。Adrian Lane，也关注 敏捷方法开发软件风险的安全方面。 Adrian
关注功能的高效交付、以牺牲软件开发的安全为代价基于书本式的敏捷实施问题，并推动软件之外的安全确认与服务。Rocky Heckman认为，像TDD和结对编程这样的技术， 主要还是聚焦在功能上。
测试的重点放在高质量代码与可靠的可重复性操作。很少或根本没有提及渗透式测试或威胁模型。敏捷开发是否意味着完全无视安全？看起来也许有一些解决方法。
Jim Bird提出，通过一点点地提醒可能是一种渐进地解决这些风险的方法.
据Jim的观点，就像其他的质量提升实践那样，安全实践是要融入团队的意识中，
管理资料
团队可以使用增量受攻击面分析来监控系统的安全风险状况的变化，这可能是由于接口架构的改变导致的。
对于逐步构建软件并对代码非常熟悉的团队来说，威胁模型并没有想象的那么严重。大部分可在1周或2周的Sprint做完的变更并不大，而且可以增量的修改，不用花太多时间来评审，即使受攻击面被改变了。Jim还提到了利用安全Sprint，微软称之为安全突击或“迷你安全推进”，在该sprint中，团队寻找现有代码的安全漏洞，然后再作出进一步的重大变更。Jim引用Adrian Lane的话，他提到，开发团队比客户更关注安全性。开发团队在其开发过程中应给予足够的重视并担负起责任。
即使一个强大的和善意的客户也不能被指望了解应用程序的安全问题，或如何构建安全的软件。他们自己的事情已经很多了。因此，正确的措施和心态有可能把安全作为开发过程的一部分。
Jim说，
没有理由认为敏捷开发=安全故障。技术工作，对于质量和细节与构建安全软件的承诺是相同的，而不论团队采用什么样的开发方式。查看英文原文：Secure Code Development: A Casualty With Agile?
篇7：敏捷开发技巧消除代码异味Java
下一页 1 2 3 4 摘要: 本文通过简单通俗的例子,告诉我们如何判断代码的稳定性和代码中的异类,并且如何重构此类代码. 异味这个词,可能有点抽象,我们先看一下下面的例子 这是一个CAD系统.现在,它已经可以画三种形状了:线条,长方形,跟圆.先认真的看一下下面的代
下一页 1 2 3 4
摘要:
本文通过简单通俗的例子, 告诉我们如何判断代码的稳定性和代码中的异类, 并且如何重构此类代码.
异味这个词,可能有点抽象,我们先看一下下面的例子
这是一个CAD系统. 现在,它已经可以画三种形状了:线条,长方形,跟圆.先认真的看一下下面的代码:
class Shape {
final static int TYPELINE = 0;
final static int TYPERECTANGLE = 1;
final static int TYPECIRCLE = 2;
int shapeType;
//线条的开始点
//长方形左下角的点
//圆心
Point p1;
//线条的结束点
//长方形的右上角的点
//如果是圆的话,这个属性不用
Point p2;
int radius;
}
class CADApp {
void drawShapes(Graphics graphics, Shape shapes[]) {
for (int i = 0; i < shapes.length; i++) {
switch (shapes[i].getType) {
case Shape.TYPELINE:
graphics.drawLine(shapes[i].getP1(), shapes[i].getP2());
break;
case Shape.TYPERECTANGLE:
//画四条边
graphics.drawLine(...);
graphics.drawLine(...);
graphics.drawLine(...);
graphics.drawLine(...);
break;
case Shape.TYPECIRCLE:
graphics.drawCircle(shapes[i].getP1(), shapes[i].getRadius());
break;
}
}
}
}
代码都是一直在改变的,而这也是上面的代码会碰到的一个问题.
现在我们有一个问题: 如果我们需要支持更多的形状(比如三角形), 那么肯定要改动Shape这个类, CADApp里面的drawShapes这个方法也要改.
好,改为如下的样子:
class Shape {
final static int TYPELINE = 0;
final static int TYPERECTANGLE = 1;
final static int TYPECIRCLE = 2;
final static int TYPETRIANGLE = 3;
int shapeType;
Point p1;
Point p2;
//三角形的第三个点.
Point p3;
int radius;
}
class CADApp {
void drawShapes(Graphics graphics, Shape shapes[]) {
for (int i = 0; i < shapes.length; i++) {
switch (shapes[i].getType()) {
case Shape.TYPELINE:
graphics.drawLine(shapes[i].getP1(), shapes[i].getP2());
break;
case Shape.TYPERECTANGLE:
//画四条边.
graphics.drawLine(...);
graphics.drawLine(...);
graphics.drawLine(...);
graphics.drawLine(...);
break;
case Shape.TYPECIRCLE:
graphics.drawCircle(shapes[i].getP1(), shapes[i].getRadius());
break;
case Shape.TYPETRIANGLE:
graphics.drawLine(shapes[i].getP1(), shapes[i].getP2());
graphics.drawLine(shapes[i].getP2(), shapes[i].getP3());
graphics.drawLine(shapes[i].getP3(), shapes[i].getP1());
break;
}
}
}
}
如果以后要支持更多的形状,这些类又要改动……，这可不是什么好事情！
理想情况下，我们希望当一个类，一个方法或其他的代码设计完以后，就不用再做修改了，
敏捷开发技巧消除代码异味Java
，
它们应该稳定到不用修改就可以重用。
现在的情况恰好相反！
每当我们增加新的形状，都得修改Shape这个类，跟CADApp里面的drawShapes方法。
怎么让代码稳定（也就是无需修改）？这个问题是个好问题！不过老规矩，先不说，我们以行动回答。
我们先看看另外一个方法： 当给你一段代码，你怎么知道它是稳定的？
原文转自：www.ltesting.net
篇8：看图说话-21天学通敏捷开发？
【21天学通敏捷开发？】 21天可以了解敏捷，学通请做好需用的准备，
看图说话-21天学通敏捷开发？
，
篇9：深入理解敏捷开发的常见九大误区
责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度，敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。
1、敏捷是“一个”过程
敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷价值观，遵循敏捷的原则。
敏捷的价值观如下：
◆个体和交互 胜过 过程和工具
◆可以工作的软件 胜过 面面俱到的文档
◆客户合作 胜过 合同谈判
◆响应变化 胜过 遵循计划
由价值观引出的12条敏捷原则：
◆我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
◆即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
◆经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
◆在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
◆围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
◆在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
◆工作的软件是首要的进度度量标准。
◆敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
◆不断地关注优秀的技能和好的设计会增强敏捷能力。
◆简单是使未完成的工作最大化的艺术??是根本的。
◆最好的构架、需求和设计出自于自组织的团队。
◆每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
建立敏捷联盟的17位大师所创立的敏捷方法包括：极限编程，Scrum，特征驱动开发，动态系统开发方法，自适应软件开发，水晶方法，实用编程方法。这些方法统称为敏捷方法。
其实每个人都可以从敏捷宣言和原则出发，明确问题，找出一些解决方法，形成自己的过程。我觉得国内的软件环境这么复杂，程序员的自主精神又这么强，敏捷方法应该是在中国首先提出才对，只是国人都有唯标准唯规范至上的心理定式，即使找出好办法，也觉得不规范，没有深入形成理论，无法提升高度，始终是跟着鬼子屁股后面走，我想这也是国外软件行业不成熟的表现之一吧！
2、敏捷仅仅是一个软件过程
如果仅仅从软件过程的角度去认识敏捷实施敏捷，效果不会太好。敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。
涉及到人的问题，就已经不再是过程所能覆盖的了，就到了企业管理的层面上了，包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍：
把客户当作合作伙伴而不是对手，从客户角度出发去想问题，充分的跟客户沟通，而不是出了问题推诿责任。目标是让软件实现客户的价值，而不是收钱就完事儿。
把人的能动性调动起来，给动力而不是给压力。
要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。
没有绝对的权威，每个人都有可取之处，
3、迭代就是敏捷，UP属于敏捷。
看到这么多人都把UP归入敏捷，我都开始怀疑是不是自己搞错了。但是在我的印象中：
UP是重型的过程，虽然引入了迭代，但是其原则和价值观与敏捷是不同的。敏捷注重的是反馈，迭代周期尽量的短，重在客户的参与，通过客户的参与，获取持续的反馈，不断调整使整个项目走在正确的方向上。同时也给客户一个感受和思考的机会，因为对于大多数客户而言，目标是明确的(不排除有些客户目标也不明确)，但是具体怎么做，开始时是没有想法的，只有看到具体的东西的时候，才知道“噢，原来可以这样，那我想把这里调整一下”。
4、敏捷是彻底革命的。
敏捷，特别是XP，让人有耳目一新的感觉，觉得以前的所有软件工程理论，设计方法都可以抛弃掉了，推翻一切，从头再来。抱着这种想法实施敏捷，那就错了，敏捷不是“石头里蹦出个孙大圣”，以前的软件过程中也有敏捷的影子，只是没有像敏捷一样上升到价值观和原则的高度，比如快速原型法。敏捷是在对已有的软件过程方法的改进，抛弃的是传统软件工程低效的外表，以往的软件过程中很多技巧都是很实用的。实施敏捷应该以现有的软件过程为基础，从敏捷宣言和原则出发，利用敏捷的方法来改善过程。
5、敏捷是反文档的。
文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题?难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。
应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价(特别是更新同步文档的代价)。
因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。
文档不是目的，有效沟通才是目的。
6、为了敏捷而敏捷
“嗯，敏捷这么好，我们也敏捷吧”，可能很多人会有这种想法。忘了以前是在哪儿看的大师采访录：
Q：“我们现有的过程很好，不知道怎么用敏捷改进?”
A：“既然很好，那就不要用敏捷”。
做什么事情都要有明确目标的，敏捷虽好，得看你需不需要，能不能解决你现在头疼的问题，如果不是，那就不要给自己找麻烦了。
7、敏捷是CMM的反义词
在讨论中，很多人把CMM作为敏捷的反义词，我觉得这不是很合适。CMM只是一种衡量软件成熟度的标准，并非过程，和敏捷不是一类概念。如果要给敏捷找一个反义词，我觉得传统的瀑布式开发应该更合适一些。
并且，我认为，如果CMM还能继续流行下去的话，应该会有公司可以用敏捷改善的过程通过CMM认证。
8、敏捷是自由的，无约束的。
敏捷强调的是自组织团队，发挥人的能动性，以动力代替压力，让人有绝对自由的错觉。但是应该清楚，凡事都是要讲究一个平衡，人也是两面的，消极的一面和积极的一面同时并存，绝对的自由会放纵人消极的一面。敏捷并非是绝对自由，无约束的。作为管理者，有一个职责，就是引导团队成员用自己积极的一面去压制消极的一面，不能放任团队中出现搭便车的现象，否则将打击整个团队的士气。如果实在无效，那就只能将其排除出团队了，这个惩罚够有约束力吧?
9、重做就是重构
重做不等于重构，很多场合这两个概念是混淆的。但是在敏捷中，重构的一个特征是必须可控的。当对系统结构进行大的调整时，如果没有测试驱动辅助的话，那么可控性就会很差，这不能叫做重构。
来自：tech.it168.com/m/2008-01-11/200801111523383.shtml
【敏捷开发经验：bigtall的敏捷日记】相关文章：
1.敏捷的反义词
2.敏捷的爷爷作文
4.敏捷就是微观管理
文档为doc格式
