2014-01-11 18:46:45 YHC2113 阅读数 747
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10424 人正在学习 去看看 CSDN讲师

开发工作中使用的敏捷开发模式

来现在的公司有一段时间了,现在主要用java开发采用敏捷的开发模式。因为以前工作中对敏捷的了解比较少所以觉得有必要进行梳理总结下。

敏捷开发的定义及解释说明这里就略过了,想要详细了解的朋友可以猛点这里(敏捷开发详解)。

谈敏捷开发先从流程讲起吧。首先,每天早上我们会有一个晨会( 站立会议 ),主要汇报昨天自己所做的工作及自己在工作的过程中所遇到的问题,然后叙述今天计划的工作,组内成员依次汇报组长做好笔录。如果组内成员有遇到自己不能解决的问题,晨会上提出来大家共同探讨,但如果估计讨论时间会比较长的时候就会安排会下协调处理,毕竟每个人的时间是宝贵的。这是一个高效的会议意在了解组内各成员的工作进度及状态。

会议结束后大家就得忙各自的Story去了,说到Stroy可能有朋友会问了,什么是Story?下面我们就一起来了解下,说白了敏捷里面Story就是项目启动前你的项目经理或组长将项目划分出来的一个独立的功能模块。然后根据组内成员的特长安排的开发任务,在迭代中(通常两个星期为一个迭代周期)开发完成。一般测试人员会在开发人员开发Story的期间完成测试用例的编写,便于开发完成Stroy后showCase(开发人员在本地环境运行story供测试人员测试)时进行验收。showCase通过后Story算是初步通过,因为迭代模式中的每个模块交付时都必须是独立可运行的也是集成可测试的,所以,功能代码在测试环境集成测试无误后该Story才算验收通过。

开发人员完成编码工作后并不意味着任务就结束了,这只是刚刚开始。是的,没说错,刚刚开始!测试人员会在测试环境对各个模块进行测试,如果发现问题会及时的在bug反馈系统中(用于跟踪问题的解决进度及完成情况)提出问题单进行跟踪,开发人员编码完成后最主要的工作估计就是和这个系统打交道了,需要及时的查看解决bug系统上面的问题单然后对问题单的状态进行变更,便于测试人员回归测试。

当然,让测试人员发现并反馈了很多的问题也是让我们开发人员比较苦恼的一件事情,毕竟不是什么好事儿。谁都希望自己交付的代码能够经得起考验,少出现或不出现问题(当然我们知道这是不可能的),那么怎么办呢?敏捷里面针对类似的情况也有合理的应对流程,确保高效、高质、高产按时的交付。那就是我们常说的结对编程,通俗的说就是A和B两个人划分为一个编程小组,有问题及时沟通反馈。甚至A看着B或B盯着A写代码也是一件比较常见的情况。A在提交自己的Stroy时必须先让B检视Review一下自己的代码,发现了问题应修复完成后才能让测试人员去测试。这样可以避免一些不必要的错误和疏忽出现,提高开发效率的同时提高编码质量。

还有一种防范问题发生的措施,那就是集体检视代码。

迭代开发中一个星期后,团队成员的编码工作基本上完成了或完成了大半。这时候头儿会组织一个开发人员会议,就是开发人员坐到一个会议室里面瞪着大眼在投影仪上找bug或编码规范问题。团队的力量还是巨大的,一会儿功夫一个功能模块可能就给你揪出了十几个bug,大家一起发现的问题会议结束后会形成一个bug列表,按责任人给依次分配下去解决。相当于集体重构了一次代码,让系统更加的健壮、稳定。

经过九九八十一难般的两个星期就这样循环反复中一闪而过,这时候我们可以暂时的小憩一会儿了。

这一会儿是多久呢,大概也就是一天左右的时间吧。因为一个迭代周期结束后,项目组成员会再次的坐在一起开一个即重要又轻松的会议--迭代回顾会议。大家吃着零食边谈论总结这个迭代中做的好的部分及需要改进的部分,“嘿,那个谁上次那个地方我说应该XX做样吧!”、"这个迭代中XX同学给予了我很大的帮助,感谢",大家你一言我一语就这样展开讨论开来...

回顾会议的第二天,开始了上面工作的第二次循环,直到整个项目交付......

原文链接:http://www.cnblogs.com/zzxbest/archive/2012/10/29/2745639.html


2011-05-05 21:22:12 hyj956948933 阅读数 152
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10424 人正在学习 去看看 CSDN讲师

    在敏捷开发当中有一个每日站会,开会的时间不是很长。基本是总会昨天做了什么时事,遇到了什么问题,然后今天准备做什么事情。

    由于是第一次使用这种模式开发,刚开始很不习惯,感觉这些事情好像用一封邮件就可以解决了,没必要开什么每日站会,甚至有点浪费时间,而且我们在前面开会的时间都不好把握, 有时开得很长,然后一天上午基本做不了什么事情。

    虽然很不情愿,但事情还是得照例做,会还是照例开。

    经过几个星期后,发现慢慢就习惯了,同时也发现这个每日站会解决了很多问题。

    首先说明一点,我们团队当中基本是实习生,没有什么开发经验,同时项目要求不是很急,于是就出现了如下问题:

    1. 开始团队成员之间互相了解不够,甚至讲话都很少,都保持异常低调。。。

    2. 发现有些天根本没做项目的事情,而是做其它与项目无关的事情去了。

    3. 每天的总结与计划都一样,甚至每个人做的事情基本都差不出,在发言时,有时就一名话带过,如,我和他做的一样,然后就没有下文了。汗。

    4. 反感是"一传十,十传百",暂且让我这么说吧!

 

    以上的问题,从不同的角度折射出敏捷开发中每日站会的好处:

    1. 时刻了解团队成员的工作情况

    2. 沟通-- 让我们更加了解对方,了解项目

    3. 遇到问题时,大家讨论,团队的力量,很快就会有解决方案。

    4. 每日计划-- 自己不会盲目,不会找不到事情。

    5. 如果当天没有安排,小组长肯定根据实际情况帮你安排一些事情。

    6. 至于时间的把握,会随便的每日站会次数的增加,相应的也会有所改进。

 

以上是我参加敏捷开发一个月以来的小小的总结,如果有写得不好地方,还请原谅。

 

    以后可能还会有改进。

2018-06-11 09:09:17 mebusw 阅读数 894
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10424 人正在学习 去看看 CSDN讲师

Daily Scrum的问题

当你问一个初创敏捷开发团队“你们会开站立会吗”,经常会碰到这样的回答“我们的开发团队对开站会比较抵触,团队本来就在一起坐着,认为站立会太形式化,没有什么价值”。还碰到过实行过两年以上的敏捷研发团队,也经常说到“开高质量的站会很难”。

敏捷团队到底怎么开高品质站立会?

先看看敏捷教练口中的站立会(Daily Scrum)。

敏捷教练说站立会

  • “在15分钟内,团队站着开。“
  • “Scrum培训中讲到Scrum指南标准定义中,团队在开每日站会的时候需要回答三个问题:我昨天完成了什么?我今天计划做什么?我遇到了什么障碍?”
  • “开站立会的目的是:
    1. 我们团队的昨天的目标是否达成了?每个人的贡献是什么?有哪些差距?
    2. 我们团队的Sprint目标现在还有多大差距?是否延迟了?遇到了哪些问题和障碍?
    3. 为了达成Sprint的目标,我们今天的目标是什么?为了实现今天的目标,我们每个人做什么?”

回归敏捷站立会的实质,它有以下作用: 1)对齐目标:互相同步信息,聚焦于当前迭代目标;2)相互协作:尽快交付工作成果,减少半成本,发现当前障碍,团队成员通力协作让价值流动。

每日站立会实践的反模式

  • 每日站立会的时间定在下班前

在敏捷实施过程中,我们的敏捷团队就走过这样的弯路:一个号称自组织的敏捷团队,起初站立会定在早上9:00开始,后因早上经常有迟到现象,大家倡议更改到9:30;再因各种会议冲突问题,站立会时间更改到下午18:00;又因种种原因,变更成17:00。在一次次以自组织的名义下,团队成员在不断互相妥协迁就的过程中,站会的时间变成下班之前。在这个过程中,站会变成了一天的结束会。

开站会时间定在下班之前,有以下问题,会议的目的之一--大家相互协作,如果会上有人遇到障碍,需要寻求帮助解决,但是因为这个时间以后大家有可能下班,有两种处理方式:强制加班当天要求处理和第二天再处理。无论哪种解决途径,都影响到敏捷迭代的正向促进作用,因此每日站立会不建议在下班之前开。

  • 开会时间过长或过短

会议时间太长或太短都是问题。太长的情况通常有两种:1)当某个成员抛出一个问题的时候,大家都对这个问题有浓烈的兴趣,这个时候很可能会陷入一种集体的讨论环节,人人都有话说,或者对一个话题陷入帕金森琐碎中。开会时间不可控,很可能还没有实质讨论成果。2)开会人数多,敏捷的每个站立会建议是5-9个人;如果人数过多,一轮站立会下来,就很容易超时。

还有一种是开会时间特别短,内容通常是这样“我昨天修了XXBug,今天计划修XXBug”; “我昨天做XX功能,今天继续做XX功能”;“按计划进行,我这边没什么问题”,“我这边也没啥问题”。多次这样简短又没内容的站立会,和敏捷站立会的目标:对齐目标和相互协作都相距甚远,这样没营养的站立会要少开。

  • 每日站立汇报会

这个主要发生在开站立会的成员中有绝对权威性的情况,通常都是领导在场,开会的时候,不自觉的从互相相同步信息的会议,改成单向领导汇报工作的形式。

很多敏捷团队的站立会议是以上这种形式,如果领导这个时候表达某种倾向性,与会成员很容易就直接接受并执行。特别是技术方案相关决策,很可能没有充分讨论清楚,因为某方的一言堂决策,导致多走弯路甚至失误。

  • 开站会发言表达混乱,没有主次

还有就是开站会时轮到某些人发言的时候,表达逻辑不清,有时候还出现当场回忆昨天工作内容,讲的内容都是流水账,与会听众关注不到重点。这样的发言多了,其他的人,也不愿意听,很容易造成与会者三心二意,这种情况不及时制止,对团队建设危害大,很容易导致团队整体氛围差,大家对待站立会的态度松懈下来,越来越不重视,流于形式。

出现这样的原因,多半是因为敏捷迭代过程中对迭代目标以及每日进行的任务没有一个清晰的关联,就会感觉任务琐碎,对任务的价值不清楚。

  • 抛出障碍无人响应

站会的目的之一,是希望能发现障碍,大家群策群力解决,但是有一些障碍(如:专业性特别强的技术问题),当与会者提出碰到一个技术难点的时候,很多时候与会人员暂时都无法给出有效的建议或方案,就会出现有人抛出障碍,无人响应。当团队不能提供实质性的帮助或建议的时候,站立会抛障碍的发声就会越来越少,渐渐站立会的价值减弱。

那怎么样才能在敏捷团队经营出高质量的站立会?下面有一些优秀的实践,可以参考。

开站会的优秀实践

  • 有规矩成方圆,尊重团队约定

“少成若天性,习惯成自然”。站立会是固定在每个工作日的同样地方同样地点站着开的会议,团队约定之后,需严格按照约定执行。站立会原则上是团队最高优先级的事,没有经过团队认可的特殊原因,成员不得缺席迟到。

我所在的团队就有过两个第一优先级的约定“1)站会是团队第一优先级别;2)团队协作是第一优先级别”。有了好的约定,还要有好的执行力,团队遵守的约定才是有效约定。

  • 把站立会上升到团队整体仪式,注重团队仪式感培养,强化敏捷价值理解

强化团队仪式感实际上就是增强团队认同度,可以把站立会看作是一个敏捷团队整体开工仪式。以站立会为起点,成员实现对团队交付的执行承诺。

我们实践中发现早上是一个好的开始。它是一种强化的仪式,大家就一定要准时,必须要有严格的执行规则。比如:早上9:00开始,任何人不得迟到,有迟到就有戳心又不打脸的惩罚措施,而且要保证公开,透明。

  • 迭代目标明确,和每日任务紧密相关

每日站立会,每个与会成员都需确保迭代目标是清晰的,当天的工作目标是清晰的。这个职责通常都落在Scrum Master身上,他能根据每位成员表述的内容和抛出的障碍,判断是否所有成员都清楚迭代目标和当前关注点。如果发现有成员对迭代和当日工作目标不够清晰时,需及时说明。整体会议的过程和发言的内容是“关注细节,又不特别详细”。

  • 开放自主的氛围:围圈站,站位很重要,你的站姿决定你的态度,聚焦圆心

所有人站立围成一圈,每日站会是团队交流会议,不是报告会议,发言的人要面向所有站立会成员,每个与会者都是在互相汇报和交流,而不是向主管或经理做汇报。

                  

  • 站会之后有小会

每日站会之后,针对抛出的障碍,问题等,会有一段活跃的讨论会议,相关人员群策群力提供合适的解决方案。

  • 站立会应立规矩有原则:有“刺头”,欢迎“刺头”,鼓励“刺头”行为

关于团队约定,团队成员要严格遵守,对于违反团队约定的事,团队鼓励“刺头”行为,在第一时间指出,并让当事人做出对应的约定承诺。

  • 更重要的,敏捷的实施,有一个最重要的原则--打造价值共同体

站会只是组织内敏捷实施的一个缩影,它可以反馈很多的问题,其实如果打造价值共同体,或者说是利益共同体,才是我们需要值得反思的问题。敏捷中当团队的所有人价值是统一的,团队是有向心力,站会也能开得足够高效有序,当大家的利益不统一的时候,站会的时候也会暴露出很多团队管理上的问题。一个敏捷团队站立会实施的情况,可以反映出团队或组织的敏捷成熟度。

 

需不要要开站会,视团队整体情况而定,“无招胜有招”,领会敏捷以聚焦团队价值,构建价值共同体的团队才是敏捷实施的灵魂。无敏捷的形式,但是自成体系,也是好的敏捷。

总结

敏捷团队的站立会,是敏捷实施对外展示的“形”,更重要的还是站立会背后披露出的团队整体的敏捷文化、价值观建立和演进。让我们在敏捷实施的道路上越走越稳,带来更多的敏捷真谛。

(作者:罗琼,浙江移动云平台及DevOps产品经理,CSM认证、CSPO认证,原文链接http://www.uperform.cn/rethinking-about…m-by-agile-coach/)

2013-11-01 09:36:49 jk050802 阅读数 2127
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10424 人正在学习 去看看 CSDN讲师

敏捷开发的简单歌诀,这也概括了敏捷开发的全部内容

迭代开发,价值优先

分解任务,真实进度


站立会议,交通畅通

用户参与,调整方向


结对编程,代码质量

测试驱动,安全可靠


持续集成,尽早反馈

自动部署,一键安装


定期回顾,持续改进

不断学习,提高能力

以上这个歌诀,1,2段表明敏捷开发的开发总模式;3,4段表明敏捷开发的项目管理;5,6段表明敏捷开发的编码方式;7,8段表明敏捷开发的反馈方法;9,10段表明敏捷开发中,如何协作和提升自己能力。


敏捷宣言

敏捷开发是一种把一人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。


敏捷的精神

只关注真正重要的事情,少关注那些占用大量时间而无甚裨益的不重要的事情它强调团队合作,人们专注于具体可行的目标实现真正可工作的软件)。它打破那种基于计划的瀑布式软件开发方法,将软件开发的实际重点转移到一种更加自然和可持续的开发方式上。

它要求团队中的每一个人(包括与团队合作的人)都具备职业精神,并积极地期望项目能获得成功。它并不要求所有人都是有经验的专业人员,但必须具有专业的工作态度——每个人都希望尽最大可能做好自己的工作。


敏捷的核心——持续前进

事实上,只要有人继续使用这个软件,开发就没有结束。我们进行的是持续开发、持续反馈。这种持续前进的方法根植于敏捷方法。它不但应用于软件开发的生命周期,还应用于技术技能的学习、需求采集、产品部署、用户培训等方面。


敏捷软件开发概括

敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善

1.它要整个团队一起努力。敏捷团队往往是一个小型团队(10个人以内),团队的所有成员在一起工作,如果可能,最好有独立在一起的工作空间,一起共享代码和必要的开发任务,而且大部分时间都能在一起工作。同时和客户或者软件的用户紧密工作在一起,尽可能早且频繁给他们演示最新的系统。

2.不断从自己写的代码中得到反馈,并且使用自动化工具不断地构建(持续集成)和测试系统。在前进过程中,你都会有意识地修改一些代码:在功能不变的情况下,重新设计部分代码,改善代码的质量。这就是重构,它是软件开发中不可或缺的部分,因为编码永远没有一天是真正意义上的“结束”。

3.以迭代的方式进行工作:确定一小块时间(一周左右)的计划,然后按时完成它们。给客户演示每个迭代的工作效果,及时得到他们的反馈(这样可以保证方向正确),并且根据实际情况尽可能频繁地发布系统版本让用户使用。


2012-10-29 23:50:00 weixin_30828379 阅读数 1
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10424 人正在学习 去看看 CSDN讲师

      来现在的公司有一段时间了,现在主要用java开发采用敏捷的开发模式。因为以前工作中对敏捷的了解比较少所以觉得有必要进行梳理总结下。

 

      敏捷开发的定义及解释说明这里就略过了,想要详细了解的朋友可以猛点这里(敏捷开发详解)。

 

      谈敏捷开发先从流程讲起吧。首先,每天早上我们会有一个晨会( 站立会议 ),主要汇报昨天自己所做的工作及自己在工作的过程中所遇到的问题,然后叙述今天计划的工作,组内成员依次汇报组长做好笔录。如果组内成员有遇到自己不能解决的问题,晨会上提出来大家共同探讨,但如果估计讨论时间会比较长的时候就会安排会下协调处理,毕竟每个人的时间是宝贵的。这是一个高效的会议意在了解组内各成员的工作进度及状态。

      

      会议结束后大家就得忙各自的Story去了,说到Stroy可能有朋友会问了,什么是Story?下面我们就一起来了解下,说白了敏捷里面Story就是项目启动前你的项目经理或组长将项目划分出来的一个独立的功能模块。然后根据组内成员的特长安排的开发任务,在迭代中(通常两个星期为一个迭代周期)开发完成。一般测试人员会在开发人员开发Story的期间完成测试用例的编写,便于开发完成Stroy后showCase(开发人员在本地环境运行story供测试人员测试)时进行验收。showCase通过后Story算是初步通过,因为迭代模式中的每个模块交付时都必须是独立可运行的也是集成可测试的,所以,功能代码在测试环境集成测试无误后该Story才算验收通过。

 

      开发人员完成编码工作后并不意味着任务就结束了,这只是刚刚开始。是的,没说错,刚刚开始!测试人员会在测试环境对各个模块进行测试,如果发现问题会及时的在bug反馈系统中(用于跟踪问题的解决进度及完成情况)提出问题单进行跟踪,开发人员编码完成后最主要的工作估计就是和这个系统打交道了,需要及时的查看解决bug系统上面的问题单然后对问题单的状态进行变更,便于测试人员回归测试。

 

      当然,让测试人员发现并反馈了很多的问题也是让我们开发人员比较苦恼的一件事情,毕竟不是什么好事儿。谁都希望自己交付的代码能够经得起考验,少出现或不出现问题(当然我们知道这是不可能的),那么怎么办呢?敏捷里面针对类似的情况也有合理的应对流程,确保高效、高质、高产按时的交付。那就是我们常说的结对编程,通俗的说就是A和B两个人划分为一个编程小组,有问题及时沟通反馈。甚至A看着B或B盯着A写代码也是一件比较常见的情况。A在提交自己的Stroy时必须先让B检视Review一下自己的代码,发现了问题应修复完成后才能让测试人员去测试。这样可以避免一些不必要的错误和疏忽出现,提高开发效率的同时提高编码质量。

 

       还有一种防范问题发生的措施,那就是集体检视代码。

 

       迭代开发中一个星期后,团队成员的编码工作基本上完成了或完成了大半。这时候头儿会组织一个开发人员会议,就是开发人员坐到一个会议室里面瞪着大眼在投影仪上找bug或编码规范问题。团队的力量还是巨大的,一会儿功夫一个功能模块可能就给你揪出了十几个bug,大家一起发现的问题会议结束后会形成一个bug列表,按责任人给依次分配下去解决。相当于集体重构了一次代码,让系统更加的健壮、稳定。

 

       经过九九八十一难般的两个星期就这样循环反复中一闪而过,这时候我们可以暂时的小憩一会儿了。

 

       这一会儿是多久呢,大概也就是一天左右的时间吧。因为一个迭代周期结束后,项目组成员会再次的坐在一起开一个即重要又轻松的会议--迭代回顾会议。大家吃着零食边谈论总结这个迭代中做的好的部分及需要改进的部分,“嘿,那个谁上次那个地方我说应该XX做样吧!”、"这个迭代中XX同学给予了我很大的帮助,感谢",大家你一言我一语就这样展开讨论开来...

 

       回顾会议的第二天,开始了上面工作的第二次循环,直到整个项目交付......

 

      

      

转载于:https://www.cnblogs.com/zzxbest/archive/2012/10/29/2745639.html

没有更多推荐了,返回首页