团队组建
并不需要个个都是技术超一流的，相反，下面几个特性在组建团队时更应该得到重视：
- 社交敏感度
- 同理心
重新定义领导力
领导力就是有能力去创造一种环境，让其中的每个人都能集思广益
创造一种环境：
在技术上
在研发过程上，能够自驱动自组织
不需要过多干涉运行，只需要保证团队的正常运作，倾听团队的意见并确保他们遵守原则。
Scrum 规则：
- 规则迭代：在每个sprint结束后，在retrospective会议上进行调整，统一后在下个sprint 内严格遵守
- 惩罚规则：Daily Scrum Meeting，定好时间后，未按规定时间到会，每迟到一分钟10元红包…不超过50元。或者选择唱歌、真心话大冒险
- 需求变更控制：所有有关需求的事项（如需求不明确/需求变更），均需要在worktile 的话题模块进行讨论，并让所有人进行关注，避免结论被忽视，禁止进行单独对接和群内讨论；有了结论后，需要Scrum master 根据结论调整“todo” 栏目，并且邮件通知
调整说明：项目组成员内部能解决的由测试进行记录到worktile；需要与外部沟通的由Scrum master记录；所有重大需求变更由Scrum master发邮件通知。 - DoD 完成标准（Definition of Done）：在每个sprint 启动时，由团队一起制定，sprint内的任务完成 评判以此为标准 调整说明：原则上：功能性task，由测试人员进行验证；其他非功能性task， 需要相关干系人对输出物评审讨论后确定是否进行验收（如测试用例、数据库结构模型等）；sprint启动会的时候对验证规则具体问题，具体分析。
- 会议规则：如果需要组织相关人员进行会议，需要提前一天在worktile 的日历中，新建会议，说明会议主题，会议时间，并且通知到相关干系人
- Scrum 活动：Sprint Plan Meeting、Daily Standup Meeting、Review Meeting、Retrospective Meeting
- Scrum 工件：Product Backlog 记录在worktile 任务看板中的todo 栏；sprint backlog以worktile中项目的任务面板为准（backlog，in-progress、to-verify、done）；燃尽图以实物白板手绘
DailyScrum 规则：
- DailyScrum例会由项目组成员轮流做Scrum Master，ScrumMaster 负责任务看版上的 task 拖动、task计时和燃尽图的更新
- 每天需要在worktile 任务看板中，从“todo” 栏目 领用任务，且要拖拉到 “in progress” 栏；第二天Scrum例会前，需要保证 在 “in progress” 栏目中的task 要全部 放到“to verify” 栏目；如果没有完成，需要在例会中说明缘由，并得到团队的认同。特殊task（用时超过1天）除外；
- 根据DoD规则，Task验收通过后，，由测试/SM 将Task拖拉到 “done” 栏目
- 根据DoD规则，Task验收不通过，需要 测试/SM 从“to-verify” 栏目 将task 放回到 “in-progress” 栏，并在描述信息中注明原因，Task 责任人需要优先解决 验证不通过的Task
- 所有bug，由测试人员添加BUG到 《同名BUG项目》 的“BUG列表”栏目，并提醒相关责任人进行修复
- 原型/设计稿/测试用例图/共享资源等文件，请上传到 worktile 的 “文件”中；研发过程文档/API文档/系统配置部署说明文档等 均需要体现在worktile 的”文档”内