27 lines
1.5 KiB
Markdown
27 lines
1.5 KiB
Markdown
|
---
|
|||
|
title: Programming Methodology
|
|||
|
localeTitle: 编程方法论
|
|||
|
---
|
|||
|
### 基础敏捷原则
|
|||
|
|
|||
|
**_流程和工具上的_** **_个人和互动_**
|
|||
|
|
|||
|
**_工作软件_** **_综合_**
|
|||
|
|
|||
|
**_合同谈判中的_** **_客户协作_**
|
|||
|
|
|||
|
**_响应变更_** **_遵循计划_**
|
|||
|
|
|||
|
## 用户故事
|
|||
|
|
|||
|
用户故事帮助我们将用户的需求直接与我们以对话格式实现的功能联系起来。他们**总是**遵循这样的语法: _“作为用户/利益相关者,我需要/希望能够做某事”_ 。这可能会导致“明显”功能的一些尴尬故事,如_“作为用户,我需要能够相信我的信用卡信息是安全的”。_但是,为了让我们能够有效地将工作分解成可管理的部分,所有功能必须与故事联系起来。
|
|||
|
|
|||
|
## 冲刺
|
|||
|
|
|||
|
“Sprint”是一个短暂的(1-3周)开发周期,在此期间,许多故事或子任务的目标是在sprint结束时完成。 “短跑”背后的想法是让我们向项目冠军**提供**一个故事以供反馈/批准。这个迭代工作流程确保我们从项目冠军那里获得持续的支持,并且我们提供的功能既有效又有价值。
|
|||
|
|
|||
|
## SCRUM
|
|||
|
|
|||
|
在基础层面,SCRUM帮助我们保持专注并了解每个指定任务的状态以及打破沟通障碍。在许多专业设置中,工作日以“每日Scrum”开头。我们将遵循每周一次的争议,以配合我们的冲刺。常见的Scrum失败是在scrum期间尝试解决问题。故障排除和头脑风暴应始终作为SCRUM的单独任务完成。
|
|||
|
|
|||
|
[在这里](http://scrummethodology.com/)阅读更多。
|