作者回复: 给你点赞👍
你说的这一段是我文章总结所欠缺的部分,Ticket跟踪系统还不能完全替代项目计划工具,需要结合使用。
作者回复: 总结的非常好👍
其实每个阶段都有关于工具的章节,比如这一篇就是项目规划篇的项目管理工具。
需求分析篇的工具要讲原型设计,需求阶段还有需求收集管理工具,通常可以用Ticket管理系统(如Jira)、源代码管理(如git)或文档管理工具(如Google Docs/石墨文档)来做。
设计阶段其实主要用文档工具,用MS Visio/PPT画图。
编码阶段主要是源代码管理工具、各种IDE、持续集成平台(Jenkins)的搭建
测试阶段主要是有测试用例管理系统(例如TestRail),有Bug跟踪系统(基本上和项目管理工具一起的,例如Jira)
运维监控有日志管理系统(例如ELK),监控(例如Wavefront),报警(例如PagerDuty)
作者回复: 实际项目中确实有很多残酷的现实,而我们学习软件工程,不就是为了知道理想的开发软件是什么样子,好的开发方式是什么样子,然后超那个方向努力么!
作者回复: 文中只是一个示例,可以针对性调整,比如你可以增加一栏:开发完成。对于完成但不具备测试条件的先放到开发完成栏,等到相关ticket都开发完成,再一起放到待测试,这样就会更准确。
作者回复: 进度跟踪时,拍脑袋想一个进度百分比这种我也经历过,开始百分比进展很快,然后80%之后就越来越慢了,90%可能都好多天才能100%。
所以说:一个任务,只有 0% 和 100% 两种状态是准确的,中间状态都是不靠谱的。像看板这种只有“TODO”、“进行中”、“完成”等这样几种状态还是更科学可行。
作者回复: 其实很多工具的定制能力都非常强,例如Jira,可以考虑基于它定制,尤其是可以开发插件,开发成本不高,但可以做很多个性定制化的事。
燃尽图是有天然偏差的,因为任务的复杂度其实不一样的,有的几小时就完了,有的得好几天,有时候你看只剩下一个任务了,但这个可能是最难耗时最长的。
所以我个人更喜欢看板视图,可以直观看到当前Sprint具体什么任务还没完成。
作者回复: 我没有用过码云的,但Github自带的也很好用。
作者回复: 用了看板我对燃尽图就懒得看了,毕竟看ToDo栏还有多少Ticket也是很直观的:)
作者回复: 我没做过C++的CI集成,理论上是没问题的,例如:
https://www.viva64.com/en/m/0005/
https://www.viva64.com/en/b/0393/
即使不用CI,也还是可以用一些自动化脚本辅助,例如git hook。
这种事情就属于磨刀不误砍柴工,第一次肯定要投入一些时间精力的,后面会获益良多。具体怎么做还得你自己权衡,也不用一步到位,一点点慢慢改进。
作者回复: 以Jira为例:
Ticket之间是可以建立关联的,好像不是强依赖。
修改Sprint属性就可以切换看板,修改状态就可以切换看板的泳道。
Ticket可以克隆(Clone),同一个需求可以克隆多份,然后稍作修改。
作者回复: 我个人更喜欢看板,因为我更关注具体的任务人不是数字图表。
作者回复: 你说的几种方法我都试过,用下来发现还是看板最最好用,每天大家根据看板做事情,项目进展和要做什么一目了然。
很多项目管理软件都支持看板视图的
作者回复: Jira很好用的
作者回复: 1. 我觉得学习新技术和使用新工具是要把握好度的,一方面不能过于保守,排斥新技术新工具,另一方面不能过于追新技术新工具,对新技术新工具不要急于应用在实际项目中,需要小心论证。
相应的对于成员学习新技术,也一样要鼓励他们去学习,将学到的新技术和新工具在内部进行分享。
同时也要限制和约束对新技术的使用,建立合理的机制去验证和推广新技术。
2. 谁提Ticket谁验收验证
3. 项目经理最主要工作就是协调好项目资源,有计划有顺序的推进项目,保障好项目的正常运行。
作者回复: 可以参考用户故事的做法,虽然需求描述很简单,但是有相应的验收条件。
参考:https://gitbook.cn/books/59d883784730b27bd0d228cf/index.html
作者回复: 这个有几种解决方案:
1. 服务端先实现一个模拟的接口
2. 客户端自己模拟接口
3. 第三方服务,例如:
https://github.com/easy-mock/easy-mock
https://getman.cn/mock/
https://apizza.net/
作者回复: 即使小,也应该用起来的,强烈建议用起来。
现在很多在线的项目管理工具都不贵,也不用自己维护,特别适合小团队。
作者回复: 心动不如行动,加油⛽️
作者回复: 赞,Redmine也有听说过,只是没用过。