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

    作者回复: 给你点赞👍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    多谢!

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

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

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

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

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

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

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

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

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

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

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

    作者回复: Jira很好用的

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

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

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

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

    2. 谁提Ticket谁验收验证

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

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

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

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

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

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

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

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

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

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

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

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

    
     1
  • 俊杰
    2020-01-29
    控制每个阶段的开发范围,避免中间插入新需求,给开发造成干扰。 但是这要求我们的阶段开发范围必须很明确,同时要做好问题与需求的切割。 对于问题,还是要马上响应。
    
    
我们在线,来聊聊吧