团队项目开发管理流程

Markdown语法子集.md

项目文档Markdown语法子集

标题及章节

文档标题使用“#”的语法，章节标题使用“##” ~ “####”共三个级别

文本格式

鉴于中文字体问题，仅使用黑体__Bold__和删除线~~Strikethrough~~，不使用斜体。

列表

使用“-”表示列表。

数字列表为避免修改，可统一使用“1. ”作为开始，除非编辑器自动生成。忽略与实际序号不一致的情况。例如：

0. 列表项1
0. 列表项2

表格

支持使用表格语法，但建议使用合适的Markdown编辑器以迅速发现语法错误。 原则上所有文档的阅读均通过Web进行，可以假设已经过渲染，因此不要求文本层面将列对齐。

最佳实践 2017-11.md

团队开发管理最佳实践

基本流程

• 立项
  • 确认范围、时间、成本且建立项目团队
• 项目初始化 -通过BitBucket建立新的团队项目，选择项目成员。 -根据对范围划分的结论在项目下分别建立不同的代码仓库，并在该仓库下建立README.md，描述该仓库的业务目标和基本思路。
• 文档管理 -在项目下建立名为【projectName_doc】的仓库，对项目成员全面开放读取权限，不同文档由指定的负责人维护。该仓库下仅维护master分支，各类更新直接提交。
• 基于特性的GitHub Flow策略
  • 所有新特性、Bug修复均建立新的Branch，命名为feature_xxx或bug_xxx。
  • 特性和Bug的来源必须是该项目的ISSUE记录。
  • 开发完成后，提交pull request到master，审核通过后合并并关闭。
  • feature合并后Minor版本号加一，bug合并后Patch版本号加一。
  • master按新的版本号新建tag，命名T_Major.Minor.Patch.
• 发布、测试流程
• 项目跟进
• 项目总结

原则

• 所有文档、资料、代码均通过代码管理系统进行管理
• 内部文档全部使用Markdown文本，仅合同、协议、等对外内容或最终交付内容使用二进制文档

约束

• GitHub支持私有仓库，但需要支付$7/month，在公司购买GitHub前，使用BitBucket
• 目前BitBucket上整合的Trello运行相对缓慢，在没有提供类似GitHub的关联功能（Issue、Pull Request直接进入白板）前，直接在原生的Trello中进行管理
• 考虑到通过Git的代码管理策略来限制每个功能点的过程，Trello在流程限制方面的弱点（相对于Jira）被弱化，因此使用Trello+Issue直接进行管理，不使用Jira

版本号.md

使用Major.minor.patch形式的语义化版本规则。

补丁（patch）不会改变任何功能，次（minor）版本只包含增量修改，而破坏性变更则留给主（major）版本。