软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决

宝玉 2019-03-28
你好,我是宝玉,我今天想与你分享的主题是:一切管理问题,都应思考能否通过工具解决。
早些年我在做项目管理工作的时候,除了制订计划外,还要花不少时间去跟踪计划的执行情况。
项目管理上出了问题,管理者总是喜欢从流程规范的角度去想办法,于是为此设定了不少流程规范,例如每天要写日报,根据日报更新项目进度,每周要开周例会,看看项目有没有执行上的问题。
对任务进度的量化也是个很困扰项目经理的事情,需要频繁的去问程序员:“你这个任务进展如何,大概完成比例多少?”,从程序员那得到的答复通常都是个很乐观的数字,例如 80%。第二天以为他能做完,结果一问是 90%,就这样要持续好多天才真的算做完。
所以后来我得出来一个结论:一个任务,只有 0% 和 100% 两种状态是准确的,中间状态都是不靠谱的。
除此之外,还有个问题就是,项目的进展并不太直观,除了项目经理每天看计划表,对计划有一个大概了解以外,其他人可能只有在到了计划设置的“里程碑”时,才对进度有比较直观的感觉。
项目成员手头事情做完,如果和计划有出入,也不知道自己接下来该干嘛,都要跑去问项目经理,所以项目经理对于很多事情都要从中协调,日常有很多繁重的任务管理工作。
后来我发现其实很多管理者都有类似的困惑:任务不好量化难以估算,项目成员对当前项目进度缺少直观感受,管理者要花大量时间在任务管理上。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(23)

  • 刘晓林
    我觉得辅助计划工具是从项目规划和任务分解出发,以任务之间内在逻辑关系为依据组织任务,优点是能够清晰地看到整个项目的蓝图,缺点是结构化程度太高,不够灵活,不能适应项目执行期间遇到的变化。基于tickt的管理跟踪系统是从项目执行的角度出发,以执行周期为依据组织任务(如一个sprint),注重任务的状态跟踪,优点是灵活,缺点是缺乏结构化,各任务之间的关系不明确,容易只见树木不见森林,因此不适合做项目规划和任务分解。因此,需要将二者结合起来用,在规划和任务分解阶段,用项目规划工具,生成蓝图,最后把分解后的任务做成一个个tickt,做项目跟踪

    作者回复: 给你点赞👍

    你说的这一段是我文章总结所欠缺的部分,Ticket跟踪系统还不能完全替代项目计划工具,需要结合使用。

    2019-03-28
    8
  • kirogiyi
    完全手工方式管理的优点在于自由空间大、项目结构松散,比如临时添加需求、临时添加人员、临时改变策略等。一旦管理者没有足够的能力去驾驭项目的整体架构,随着项目时间的推移,项目不是越做越简单,而是越做越难,可能到处都是窟窿,根本没法持续下去,并且责任和义务大部分集中于项目管理者。

    尽量采用软件工具管理的优点在于对需求、人员、进度、里程碑等可以进行事无巨细的分解或者组合,明确每个人的职责,明确每件事完成的要求,既可以让参与人员看到长期目标,也可以让他们看到短期目标,而不是遥遥无期。可以这样讲,没有路标的100公里总是比有路标的100公里来得费尽得多,还有就是很容易让参与者失去信心,丧失斗志。

    宝玉老师在上面提到了部分工具,能否把项目管理每个阶段用到的典型工具分享一下,谢谢。

    作者回复: 总结的非常好👍

    其实每个阶段都有关于工具的章节,比如这一篇就是项目规划篇的项目管理工具。

    需求分析篇的工具要讲原型设计,需求阶段还有需求收集管理工具,通常可以用Ticket管理系统(如Jira)、源代码管理(如git)或文档管理工具(如Google Docs/石墨文档)来做。

    设计阶段其实主要用文档工具,用MS Visio/PPT画图。

    编码阶段主要是源代码管理工具、各种IDE、持续集成平台(Jenkins)的搭建

    测试阶段主要是有测试用例管理系统(例如TestRail),有Bug跟踪系统(基本上和项目管理工具一起的,例如Jira)

    运维监控有日志管理系统(例如ELK),监控(例如Wavefront),报警(例如PagerDuty)

    2019-03-28
    5
  • Charles
    我们在用云效,用云效之前用过tower主要用看板和任务管理,还自己搭过jira之类的

    云效相对来说更加健全一些,主要解决需求管理、版本任务、bug、测试用例、代码管理、持续部署等大部分项目管理的问题

    优点:因为用他云服务,所以整合度挺好的

    缺点:因为不算他特别核心业务,所以感觉细节问题还挺多的,部署也经常失败,但是最近好像有改善


    另外,问老师一个问题,文章中讲到ticket做完到待测试,这一步测试人员是否马上应该跟进测试,但是很多ticket其实是有关联的,所以到底是一个版本计划内的任务全部完成再测试还是一个一个ticket分开测试?如果是单个ticket测试的话,这个ticket是否需要保证和其他模块无关联或关联性较少?

    作者回复: 文中只是一个示例,可以针对性调整,比如你可以增加一栏:开发完成。对于完成但不具备测试条件的先放到开发完成栏,等到相关ticket都开发完成,再一起放到待测试,这样就会更准确。

    2019-03-29
    3
  • 胖虫子
    说的好好,但在现实中,往往只有最后一个完成时间,明明完不成,硬上,项目经理就是天天催

    作者回复: 实际项目中确实有很多残酷的现实,而我们学习软件工程,不就是为了知道理想的开发软件是什么样子,好的开发方式是什么样子,然后超那个方向努力么!

    2019-04-22
    2
  • 纯洁的憎恶
    工具是流程的进阶,它使流程规范真正发挥作用的同时,将其“副作用”控制在合理范围内。

    Ticket、可视化看板等工具灵活、便捷、高效,不仅可以用于软件工程,也可以简单改造后用于多种琐碎而重要的协作中。但是对于很多传统企业,市面上缺少针对性强的现成产品,而这些企业自身也没有精力和意愿,非常深入的做一款适用于本领域管理工具。毕竟这种工具只有一两人用的意义不大,这个组织都用起来才最有意义。

    PS:我看燃尽图好像是根据ticket数量的历史变化情况,线性的预测未来的工作进展。但工作真实进展很可能不是线性的,这是否说明燃尽图的剩余工作预测存在天然偏差呢?

    作者回复: 其实很多工具的定制能力都非常强,例如Jira,可以考虑基于它定制,尤其是可以开发插件,开发成本不高,但可以做很多个性定制化的事。

    燃尽图是有天然偏差的,因为任务的复杂度其实不一样的,有的几小时就完了,有的得好几天,有时候你看只剩下一个任务了,但这个可能是最难耗时最长的。

    所以我个人更喜欢看板视图,可以直观看到当前Sprint具体什么任务还没完成。

    2019-03-29
    2
  • 龙哥
    现在正在学习使用码云企业版自带的任务管理,我认为这个软件最大的优点就是1)买了企业版就自带了 2)可以和git联合使用,可以指定任务相关代码库、分支

    作者回复: 我没有用过码云的,但Github自带的也很好用。

    2019-03-28
    2
  • dancer
    jira 禅道都用过,比较喜欢用jira的看板。另外燃尽图不错,做事会有成就感!

    作者回复: 用了看板我对燃尽图就懒得看了,毕竟看ToDo栏还有多少Ticket也是很直观的:)

    2019-03-28
    1
    2
  • bearlu
    老师,看你这个课程。我刚好遇到类似问题,我们公司做C++静态代码检查是这样的流程。大家上传代码,然后我用PVS检查,然后查出问题,找到对应的提交代码的人。现在领导叫我,写些工具能自动化找到对应提交代码的人,但是我觉得这样不合理,我觉得提交前不合理就不然提交,我也这样和领导提过,但是领导说这个成本很大?我现在不知道怎么做,听他说做个工具,还是要坚持提交前做检查。

    作者回复: 我没做过C++的CI集成,理论上是没问题的,例如:
    https://www.viva64.com/en/m/0005/
    https://www.viva64.com/en/b/0393/

    即使不用CI,也还是可以用一些自动化脚本辅助,例如git hook。

    这种事情就属于磨刀不误砍柴工,第一次肯定要投入一些时间精力的,后面会获益良多。具体怎么做还得你自己权衡,也不用一步到位,一点点慢慢改进。

    2019-03-28
    2
  • busyStone
    请问新的这些工具还能看到并方便的编辑任务依赖么?
    有没有工具可以直接通过修改状态就自动换看板的?
    另外,像同一个需求需要多端,安卓,苹果,PC同时开发的,请问有没有好的方法来建立任务? 之前都是一样建一个,有点烦。

    多谢!

    作者回复: 以Jira为例:
    Ticket之间是可以建立关联的,好像不是强依赖。

    修改Sprint属性就可以切换看板,修改状态就可以切换看板的泳道。

    Ticket可以克隆(Clone),同一个需求可以克隆多份,然后稍作修改。

    2019-03-28
    2
  • Felix
    工作以来一直用的jira,之前经常使用看板,去年开始我们转用仪表盘了,它可以利用jira中自带的小工具个性化定制想要的东西,公司用jira的同学可以一试

    作者回复: 我个人更喜欢看板,因为我更关注具体的任务人不是数字图表。

    2019-03-28
    2
  • 西西弗与卡夫卡
    正好和项目经理讨论这个话题。因为项目涉众比较多,如何及时高效披露项目路线图和进展就成了问题。就有同事拿着时间表跑过来过来问,你们进度是什么,一看是去年已经完成的计划。这不是同事的问题。主动披露项目进展、资源使用情况,是项目组的责任之一。有时候需要汇报,但按时凑齐人不容易,如果是多方汇报,那就更耗费时间。

    比较好的实践是给项目设定一个主页,里面包括蓝图、进展、资源使用以及问题等。关心的人可以自己订阅。

    再好一点的方法是将上述实践做成流程和工具,以便每个项目和团队不用为采用什么样的协同机制而太操心,更多精力放在业务之上

    作者回复: 你说的几种方法我都试过,用下来发现还是看板最最好用,每天大家根据看板做事情,项目进展和要做什么一目了然。

    很多项目管理软件都支持看板视图的

    2019-03-28
    2
  • Geek_long
    公司用的jira。

    作者回复: Jira很好用的

    2019-03-28
    2
  • 熊斌
    之前我们项目经理是从IBM出来的,非常擅长使用Excel,我们的项目wbs都是他用VBA做的工具。
    不足之处是,无法有效追踪项目进度。
    追踪进度的时候,需要问参与的相关人员完成情况。作为开发,我要是完成了20%,为了数据好看一点,我可能会报50%......

    作者回复: 进度跟踪时,拍脑袋想一个进度百分比这种我也经历过,开始百分比进展很快,然后80%之后就越来越慢了,90%可能都好多天才能100%。

    所以说:一个任务,只有 0% 和 100% 两种状态是准确的,中间状态都是不靠谱的。像看板这种只有“TODO”、“进行中”、“完成”等这样几种状态还是更科学可行。

    2019-10-31
    1
  • 小老鼠
    1、如何管理好成员学习新技术?新工具?
    2、如何确定ticket的状态,比如完成,是真完成了还是假消息:-(
    3、项目经理更重要的工作是什么?

    作者回复: 1. 我觉得学习新技术和使用新工具是要把握好度的,一方面不能过于保守,排斥新技术新工具,另一方面不能过于追新技术新工具,对新技术新工具不要急于应用在实际项目中,需要小心论证。

    相应的对于成员学习新技术,也一样要鼓励他们去学习,将学到的新技术和新工具在内部进行分享。

    同时也要限制和约束对新技术的使用,建立合理的机制去验证和推广新技术。

    2. 谁提Ticket谁验收验证

    3. 项目经理最主要工作就是协调好项目资源,有计划有顺序的推进项目,保障好项目的正常运行。

    2019-09-11
    1
  • GeeStu
    公司的项目管理工具是禅道,结合钉钉的开发接口做了很多机器人,集成到了公司的自动化部署工具上,每次自动部署结束和任务发布都会在群里@相应的人通知。项目上主要使用迭代开发,两周一个迭代,看起还是很便捷且灵活性也较高。但有时候需求跟任务发布和文档编写的进度相差太大,有时候根本没时间在禅道上去写相关的需求文档,以至于开发完了,测试需要不断跟产品去对需求细节,有时候开发写完了以为完成的相应的功能,但最后发现要做的是A但搞出来的是D,再改成C最后交付了B。所以在这样的交付场景下,需求变更频繁时候如何去平衡使用工具一步一步来和直接口头说明的开发先行文档随后的尴尬关系呢

    作者回复: 可以参考用户故事的做法,虽然需求描述很简单,但是有相应的验收条件。
    参考:https://gitbook.cn/books/59d883784730b27bd0d228cf/index.html

    2019-04-05
    1
    1
  • oldlee
    请问前后端开发分离工具有没有好产品推荐?现在遇到的问题是,客户端经常需要等待服务端开发完,才能调用接口联调。

    作者回复: 这个有几种解决方案:
    1. 服务端先实现一个模拟的接口
    2. 客户端自己模拟接口
    3. 第三方服务,例如:
    https://github.com/easy-mock/easy-mock
    https://getman.cn/mock/
    https://apizza.net/

    2019-03-31
    1
  • 一路向北
    工欲善其事,必先利其器。
    使用好项目中每个阶段的工具,能够提升项目的效率。选择合适的工具和正确的使用工具是其中的关键。之前我们用过禅道来做敏捷开发的管理,后来是团队变小了,就没有用下去。现在没有用工具,看完老师的文章,需要重新用起来,用到工具成为长在自己身上一样了,自然效率提高了。

    作者回复: 即使小,也应该用起来的,强烈建议用起来。

    现在很多在线的项目管理工具都不贵,也不用自己维护,特别适合小团队。

    2019-03-29
    1
  • -Helen怪物
    一直在学习工程思想和项目思维,我是做测试的,今天的课程让我突然想到可以创建一个质量保证的项目督促团队更好地保证质量,然后用敏捷思维确保此项目的不断完善和提高,谢谢!很棒!

    作者回复: 心动不如行动,加油⛽️

    2019-03-29
    1
  • hua168
    菜鸟打卡,公司用的是Redmine和禅道

    作者回复: 赞,Redmine也有听说过,只是没用过。

    2019-03-28
    1
  • Panda
    国产禅道也是很好用的

    作者回复: 👍谢谢推荐!

    2019-06-04
收起评论
23
返回
顶部