项目管理经验总结补充

项目启动

项目启动前相关开发人员先讨论整体架构(架构：维护的成本，性价比)设计，包括：

梳理需求，保证所有人员完全理解业务需求
可能遇到的技术问题、可行性分析，需求争议（排优先级，按优先级开发，实际开发中时间不够的情况下考虑将低优先级的任务放到在一期完成）
如何进行相关人员的对接，包括业务技术对接、前后台对接、模块对接等
域名、服务器申请
路由设计、数据库设计、安全分析、设计，token设计，业务边界设计
文件组织，公共模块、业务模块分类存放，创建文件夹及文件需要得到同意
配置参数
相关依赖包
git管理等，
对开发任务进行划分，让开发人员自己挑选任务。 讨论结束后相关人员自己花一定时间梳理任务，然后再组织讨论，讨论会上有问题及时提出来。
确保开发前已经明确技术可行性和开发思路，避免开发中产生无法解决或需要花费大量精力处理的技术问题。

项目进行

一切工作都只是工作，合作的过程是为了共同完成一个工作，任务由自己讨论挑选的情况下不要猜疑工作安排，带着愉快的心情开展合作，互相帮助，共同提高，一切都商量着来
充分利用框架已提供的依赖包，如laravel中的GuzzleHttp、Mailer，避免重复开发未经优化的代码
每个自己创建的文件必须要有注释，包括开发者名称，代码中必要的提示注释，注意代码对齐以便于浏览；适当使用换行以区分“高内聚低耦合”的代码
服从项目经理或架构师安排，开发人员有问题（不理解的或有争议的）要及时沟通，不要只按自己的想法走，要服从项目目标，保证项目质量，为项目负责，为自己负责
要有代码优化意识，遵守DRY(don’t repeat yourself)原则，避免出现重复代码

项目完成

尽量找出时间进行讨论、总结，分析总结关键的业务流程、项目执行过程中出现的问题、新使用的技术及注意事项等

Git管理

项目保留master和dev两个分支，以及tag标签
前缀
功能增加分支加前缀feature，加功能名称，如:feature-posts(帖子管理分支)，feature-register(用户注册管理)，后面还可以自行补充版本号如：feature-register-01，完成后push到dev
bug修复分支加前缀fix，加问题名称，如:fix-ie(ie兼容问题)，后面还可以自行补充版本号如：fix-ie-02，完成后push到dev
发布分支加版本标签前缀v，后面根据情况加版本号，如：v1.1.0，完成后push到仓库
服务器
测试服务器直接从dev分支拉取代码，测试没有问题push到master分支
预发布服务器从master分支拉取代码，测试没有问题打上版本标签push到仓库
正式服务器从最新的版本标签仓库拉取代码，第一次发布可以直接从master拉取代码并打上标签并push到仓库
解决ignore不生效问题

git rm -r --cached .
git add .
git commit -m 'update .gitignore'

仓库中的分支及tag示例如下图

任何项目可能存在的问题

团队成员配合度不高，项目进行中沟通不畅
个别成员没有团队精神，缺乏集体荣誉感，没有从整体的角度安排工作，更愿意按照自己的计划”自由安排“，工作“跟着感觉走”
项目进行中因个人想法出现脱离退伍的念头，这样不但人员减少，还耽误其他人员的进度
没有”负责人“，每个人都不知道”负责人“的存在，有问题不找项目负责人，等着别人找他探讨问题，任由工期拖延
项目实施前没有对项目进行充分的讨论、设计，没有形成统一的规范、框架。项目人员在项目开展过程中”摸爬滚打“。