写在前边： 我是CodeWhite，最近都没有写过博文了，今日程序员节日，我也花时间出一篇我最近出来工作的总结，还是一个实习生，这是我d对我公司项目组负责管理的方案。

项目管理方案

需求分析、功能设计、程序设计、代码开发和功能测试(敏捷开发流程)

项目文件管理

项目进度：前端、后端

节点管理：交付时间的节点、计划、甘特图

文档管理：wink文档、项目文档、接口文档、框架文档等

文件管理：项目的资料文件，Excel、流程图、需求书等等

项目问题

命名的规范，文件名称、函数名称、属性名称、css、js规范
进度概念，一定要有一个进度的概念，系统进度
测试概念、写出来的东西肯定不会一下就完整，写完功能点一定要测试不能走捷径
问题点：可以总结问题到一个文档中、开会解决、与开发方案
工作汇报、每日的汇报
git管理、需要熟悉git命令、文件冲突、分支、提交规范的管理。
接口文档规范
质量管理：开发习惯问题：不能说我方便这样写、调试的方法要及时删除、重复的东西需要抽取、不能说后续再去完善、最好尽早的发现，后续处理，可能牵一发动全身、有缺陷的请使用 // TODO 标注、方法名称和参数需要标注
需求不明确，有时候有需求不能及时的解决、
由于软件的复杂性，总会由于环境不同、工具不同、新技术的不确定、测试的不充分而带来意想不到的结果

项目总结

这个项目遇到的最大困难
怎么解决的
学到了什么
对后期的工作又有那些启发

代码编写要求

遵循前后台代码规范
项目中不允许出现多余的代码，代码生成器生成的代码如果没有用到要及时清除
接口单一原则，一个接口一个方法坚决只允许完成一件事情，如果是同一类任务，需要通过if判断来处理不同的逻辑，那么if判断中的代码一定要抽取出方法而不能全部挤在一个方法中
禁止硬编码，所有的配置一定要写到配置文件中
禁止编写复杂sql，除非不得已为之，在实现功能和可读性之间我们更偏向于可读性
接口传值最小化，前端传值给后台应该尽量少传，后台能自己处理的就自己处理，把业务逻辑尽可能的留在后台
禁止使用map传参写接口，必须使用统一的AjaxResult类作为参数传递的格式
接口的录入公共参数不需要录入比如createBy，createTime limint 这些参数不需要录入。
接口录入要进行分类，不能全部录在一个分类下
如果处于测试需要要写死用户信息，那么一定要通过拦截器去写，不能再代码中硬编码
对于暂时无法实现的业务逻辑一定要在代码中加待办的标注 //TODO ,在发版本之前先检查一下所有的TODO标记
自己开发的功能一定要自己进行测试，测试的时候要尽量使用符合业务要求的数据进行测试，通过后在用非常规的字符进行测试，自己测试完了在移交到测试那边测
每天下班前要提交当天完成的代码，代码提交的备注尽量写清楚本次提交的目的
编写查询功能一定要考虑数据库表的记录条数，如果数据量上百万的表要尽量分历史表与作业表
金额计算要使用专门的类BigDecimal
及时解决程序员的环境、配置等问题，让其安心开发
bug要及时督促修复不要留到后期集中修复，那样会导致后期要交版本的时候非常紧张

BUG修复

测试要把发现的bug提到极客平台上并选择对应的开发人，和功能
开发收到bug提示后要及时响应解决完bug后，在极客平台把bug设置为解决状态,并选择方案为修复代码
测试收到开发解决的bug后进行bug的回归，如果确实解决了则关闭bug

每日三个问题

昨天做了什么，是否完成
今天打算做什么
提出团队或者自己的问题如：

阻碍工作的问题
需要协助的问题
可以改进的问题
代码或者功能有变动需要通知其他人知晓的问题

晨会的目的是同步信息，发现阻碍项、项目经理要总结工作情况，鼓励与批评对应的人

注意事项：

体验不好的界面坚决拒绝，不管开发愿不愿意都要改，对开发的宽容就是对客户的伤害，对客户的伤害就是对公司整体员工的伤害

接口文档规范

测试管理

相应的软件测试管理.xlsx文档。

进度管理

每日的进度汇报：每日工作.xlsx

整体的进度汇报: 项目规划.xlsx

前端代码规范

vue文件：

<!-- Author: XXX Date: 2021-08-21Description：工作单模块
-->
<template>
</template>

字段注释：

// 姓名
let name = "小米";

函数注释：

/*** Book类，代表一个书本.* * @date 2021-08-01* @param {string} title - 书本的标题.* @param {string} author - 书本的作者.*/
function book (title, author) {this.title = titlethis.author = author
}

有时我们发现某个可能的 bug，但因为一些原因还没法修复；或者某个地方还有一些待完成的功能，这时我们需要使用相应的特殊标记注释来告知未来的自己或合作者。常用的特殊标记有两种：

// FIXME : 说明问题是什么
// TODO : 说明还要做什么或者问题的解决方案

function book (title, author) {this.title = title// TODO: 这是一个未完善的方法this.author = author
}

具体看：前端代码规范.pdf

后端代码规范：

具体看阿里巴巴代码规范.pdf

数据库规范：

建表规范

建表规范
- 表设计规范
- 表业务前缀和建表标准字段
- 帮助脚步

表设计规范

1.主键必须为：ID，类型 [Long(19)] 唯一索引，因为历史原因暂时用String(32)类型
2.外键字段命名：{【关联表名】去掉业务前缀}+“_”+ {关联字段名}，例如：order_main_id
3.区分位: iz_* [String(1)] 1表示是 0表示否，（禁用 is_,代码生成实体有问题 )
4.状态位: *_status [String(1-2)] 状态字段必须加注释说明每个值代表含义
5.字段命名，多单词采用下划线分隔例如：school_id
6.索引命名：主键索引命名为：pk_表名缩写_字段名（索引要求全库唯一，为兼容多数据库）；
唯一索引命名为：uniq_表名缩写_字段名 或 uk_表名缩写_字段名；
普通索引命令为： idx_表名缩写_字段名（表名缩写：下划线分隔单词首字母组合）
7.区分、状态、类型字段，尽量用String类型，避免数字类型的一些问题；如果需要考虑性能建议用int类型
（禁用tinyint类型，需要兼容其他数据库）；

表业务前缀和建表标准字段

1.表命名必须带上业务前缀：例如 sys_开头(系统表前缀)
2.所有的表加字段：所属部门，用于部门数据权限
3.所有的表加字段：创建时间，创建者，最后更新时间，更新人
4.逻辑删除字段，del_flag [String(1)]，1表示删除 0表示未删除，可选择加
5.乐观锁字段， update_count[Integer]，可选择加
6.字符串类型字段，varchar类型长度不允许超过1000（过长转库会变类型）
7.大文本尽量少用，字段类型采用text、longtext，禁用blob系列类型（必须用要确认）

帮助脚步

ALTER TABLE `表名`
ADD COLUMN `create_by`  varchar(32) NULL COMMENT '创建人',
ADD COLUMN `create_time`  datetime NULL COMMENT '创建时间' AFTER `create_by`,
ADD COLUMN `update_by`  varchar(32) NULL COMMENT '修改人' AFTER `create_time`,
ADD COLUMN `update_time`  datetime NULL COMMENT '修改时间' AFTER `update_by`,
ADD COLUMN `del_flag`  varchar(1) NULL COMMENT '0表示未删除,1表示删除' AFTER `update_time`;

其他说明：

表字段注释，每个字段必须设置注释说明;
表字段注释，状态类型的字段必须说明取值规则（比如性别sex取值规则）
比如：‘性别 0男,1女’
索引，查询频率高的字段加索引（单字段索引、组合索引、唯一索引）;
状态、类型字段，尽量用字符串varchar类型1-2长度，少用int类型，避免不必要的问题。****

Git规范：

常用命令：git教程.pdf

分支：

master：项目的主分支，给用户提供正式版本的。
release:release是发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
develop：开发用的分支为Develop。
feature：feature是为了开发后续版本的功能，从Develop分支上面分出来的。开发完成稳定后，要再并入Develop。
fixbug：fixbug分支是从master分支上面分出来的。fix结束以后，再合并进Master和Develop分支。最后，删除"fixbug分支"。

提交规范：

1. type

用于说明 commit 的类别，只允许使用下面7个标识。

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style：格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动

2. scope(可选)

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

3. Body 部分是对本次 commit 的详细描述，可以分成多行，每行尽量不超过72个字符。下面是一个范例。

<type>(<scope>): <subject>
// 空一行
<body>

新增接口的示例：

feat(Controller): 用户查询接口开发
fix(Bean): 用户查询缺少username属性新增xxxxx

写在后边：

如果需要软件测试文档、前端代码规范、以及阿里巴巴java规范可以私信我。

个人团队的敏捷开发管理方案相关推荐

主程序员团队与敏捷开发的联合应用（小型敏捷团队管理）
作者:陈勇出处:blog.csdn.net/cheny_com 主程序员团队是曾经风靡一时的小型研发团队组织架构形式,很多团队都曾经有意无意地使用过.其模式是:由一个最好的程序员编写所有最终代码,其 ...
java set%3c %3e哈希,敏捷开发实施方案.PPT
敏捷开发实施方案 /person.do?xcase=updateEmail&coreLogonInfo.emailAddress=flyh4t%40126.com&coreLogonI ...
打造Worktile敏捷开发管理工具的思与惑
从2019年初,我们团队准备开发一款适合研发团队使用的敏捷开发管理工具,那时候我们也在思考,到底什么样的工具才算是优秀的研发管理工具,研发管理的场景.方法和流派有很多,市面上关于研发管理工具的产品也是 ...
如何高效地进行敏捷开发管理
敏捷开发其实是企业的一种管理文化. 目前软件行业敏捷开发管理最大的问题在于太看重具体的形式,而忽略了敏捷的初衷. 很多公司请几个敏捷教练建立流程,把会议室的椅子都搬走宣布从今以后大家站着开会了,使用敏 ...
高效团队协作——敏捷开发环境架构（一）
作者简介: 一个曾经不爱分享的挨踢从业者,对软件产业充满好奇,并投身于此8载有余,为什么突然写起博客主要原因是自己的脑子不够用,总是容易把事情给忘了,一个好朋友建议我把这些年的工作经验做个总结,一来不 ...
参考行标对云效以及LinKE的“持续交付”及“敏捷开发管理”能力打了下分，大家看肿么样？
中国信息通信研究院发布(已在中国通信标准化协会立项)的行标,其中"研发运营一体化(DevOps)能力成熟度模型"中对"持续交付""敏捷开发管理&quo ...
Leangoo：用敏捷开发管理思维做团队协作的SaaS软件
第一次看到leangoo这个产品时,笔者觉得又是一款团队协作软件工具,和其它的团队协作并没有什么本质区别. 当听创始人廖靖斌说起leangoo人员结构时,笔者起初蛮诧异,一家20多人的创业公司,顾问和 ...
研发团队如何低成本实现敏捷开发管理
敏捷开发的实质是通过迭代式增量软件开发的方式,防止出现长期闭门造车严重偏离客户需求,达到快速响应市场变化的目的. 应用敏捷就会一帆风顺吗?显然答案是否定的.越来越多的组织.团队开始学习.实践.导入敏捷 ...
PingCode与Jira 敏捷开发管理能力的对比
敏捷开发是一种以拥抱用户需求为核心.采用不断迭代的方式进行的软件开发模式,依靠自组织的跨职能小团队,在短周期内通过快速.频繁的迭代,迅速的获取反馈,进而不断的完善产品,给用户带来更大的价值. 虽然敏捷 ...

个人团队的敏捷开发管理方案

项目管理方案

项目文件管理

项目问题

项目总结

代码编写要求

BUG修复

每日三个问题

注意事项：

接口文档规范

测试管理

进度管理

前端代码规范

后端代码规范：

数据库规范：

建表规范

表设计规范

表业务前缀和建表标准字段

帮助脚步

Git规范：

分支：

提交规范：

1. type

2. scope(可选)

3. Body 部分是对本次 commit 的详细描述，可以分成多行，每行尽量不超过72个字符。下面是一个范例。

新增接口的示例：

写在后边：

个人团队的敏捷开发管理方案相关推荐

最新文章

热门文章

个人团队的敏捷开发管理方案

项目管理方案

项目文件管理

项目问题

项目总结

代码编写要求

BUG修复

每日三个问题

注意事项：

接口文档规范

测试管理

进度管理

前端代码规范

后端代码规范：

数据库规范：

建表规范

表设计规范

表业务前缀 和 建表标准字段

帮助脚步

Git规范：

分支：

提交规范：

1. type

2. scope(可选)

3. Body 部分是对本次 commit 的详细描述，可以分成多行，每行尽量不超过72个字符。下面是一个范例。

新增接口的示例：

写在后边：

个人团队的敏捷开发管理方案相关推荐

最新文章

热门文章

表业务前缀和建表标准字段