原则
核心原则
…更多「原则」介绍请查阅全文…
成功
随机应变
要达到敏捷的成功—交付支撑业务的最佳软件—软件专家也可以引用这些规则。自主权
专注于工作,交付正确的软件,而不是被他人的愤怒情绪所影响。分享经验
构建完美软件开发流程,并没有统一的模式。但是在这个领域,敏捷技术,加上持续的应用和改进,都能够达到敏捷的成功。
工具
visual studio team foundation server (tfs)
tfs,即团队基础服务器(team foundation server),是微软应用程序进行生命周期管理的服务器,用于帮助团队在visual studio的协作开发。最近,它进行了升级,包括工作项目执行改进、富文本编辑器的改进,以及富文本编辑器中改善的超链接体验。 tfs中的kanban面板也做了改善,提升了可以录入和跟踪的项目数量。该服务器现在有一个“利益相关者”许可,来规范服务器的访问权限。
…更多「工具」介绍请查阅全文…
实践
核心实践
…更多「实践」介绍请查阅全文…
建模者的个性
团队竞赛
第一点,也是最重要的一点,敏捷建模者总是积极的寻求协作,因为他们意识到他们不是万事通,他们需要不同的观点,这样才能做到最好。软件开发可不是游泳,单干是非常危险的。在敏捷的字典中没有“我”这个词。畅所欲言
敏捷建模者都有良好的沟通技巧--他们能够表达出他们想法,能够倾听,能够主动获取反馈,并且能够把需要的写出来。脚踏实地
敏捷建模者应当脚踏实地 他们的精力都集中在满足用户的需求上,他们不会在模型上画蛇添足,即便那双足是多么的好看。他们满足于提供可能的方案中最简单的一种,当然,前提是要能够完成工作。好奇
…更多「建模者的个性」介绍请查阅全文…
建模误区
走出一般性的设计误区,迈向成功之途
误区一
…更多「建模误区」介绍请查阅全文…
遵循原则
团队合作的原则
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
…更多「遵循原则」介绍请查阅全文…
团队原则
最大的分歧
最大的分歧在于开发人员和测试人员之间。作为敏捷团队的成员,测试人员被期望能编写一点代码,同时开发人员可以做一些测试。各自的强项还是很重要:新的角色要求每个成员成为大家所谓的“通才”。测试人员大多数时间作测试,开发人员大都编写代码,但所有人都分享他们的工作,而且有能力承担他们面前的任务。发现中立点
团队决定作为一个团队需要做什么,如何最好地分配工作。第一步是让团队成员说说他们自己的技能集、优点和缺点。但却不希望他们根据以前角色(如,软件测试员或开发员)来定义自己。所以找到一个中立点,她列出了小型离线会议,和每周工作之外的小时集体活动所需的事项。这样,该团队去当地的农场采摘蓝莓。他们一起上瑜珈课。他们集体在厨房里烤燕麦棒,做果沙。正确执行
…更多「团队原则」介绍请查阅全文…
分布式敏捷开发
分布式敏捷开发方法并不能在所有组织中都工作良好。拥有一个已经建立完成的分布式敏捷开发工作文化,对于分布式团队是很重要的。有些公司一直坚持“面对面”的工作文化,这给分布式地开展敏捷站立会议增加了难度。
但是如果分布式的文化一直存在于团队中,那么开展敏捷站立会议和其它会议就会很容易。其中的一个选择是使分散的团队成员按照同一计划表工作,即使他们所处的时区不一致。如果所有团队成员同意,且时差不超过几个小时的话,这才是有效的。
敏捷开发的原则
1· 快速迭代
相对那种半年一次的大版本发布来说,小版本的需求、开发和测试更加简单快速。一些公司,一年发布仅2~3个版本,发布流程缓慢,它们仍采用瀑布开发模式,更严重的是对敏捷开发模式存在误解。
2· 让测试人员和开发者参与需求讨论
需求讨论以研讨组的形式展开最有效率。研讨组,需要包括测试人员和开发者,这样可以更加轻松定义可测试的需求,将需求分组并确定优先级。 同时,该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高,大家更活跃,参与感更强。
…更多「敏捷开发的原则」介绍请查阅全文…