但说实话,如果我是Zenhub这样的公司,我可能会对这个声明感到有些担心…
…但说实话,如果我是Zenhub这样的公司,我可能会对这个声明感到有些担心,因为这种特定功能几乎肯定会足够让人们对不再需要第三方管理问题。我知道在我之前工作的公司中,这个特定功能(正确的父子关系)是他们使用Zenhub的原因,我现在的公司使用Linear也是同样的原因。
源讨论GitHub引入了子问题、问题类型和高级搜索原帖 206 条评论 · 导入时统计…但说实话,如果我是Zenhub这样的公司,我可能会对这个声明感到有些担心,因为这种特定功能几乎肯定会足够让人们对不再需要第三方管理问题。我知道在我之前工作的公司中,这个特定功能(正确的父子关系)是他们使用Zenhub的原因,我现在的公司使用Linear也是同样的原因。
源讨论GitHub引入了子问题、问题类型和高级搜索原帖 206 条评论 · 导入时统计我认为GitHub是一个悲伤的故事。可能至少有3家上市公司本应只是GitHub的功能:GitLab(GitHub Enterprise)、Sourcegraph(搜索)和Linear(GitHub Issues)。有数十家新兴公司正在“解绑”GitHub的功能,这些功能确实有用,但被忽视和投资不足,其中一些肯定会成功。感觉GitHub不断发明未来,然后等待别人将其真正做好。 看着这一切非常痛苦,因为我非常喜爱GitHub。我2013年大学毕业,这意味着我开始编程的时候他们刚好起步。我每天都读他们的开发博客,期待新功能(每隔几天发布一次)。我看着他们的团队页面逐渐扩大,仔细研究他们做了什么才得以进入这样一家酷公司。我到处寻找信息…
完整原文把你的经验,加入这段讨论。
抱歉,这里的目的是不是轻视GitHub,或者暗示他们工程能力差,甚至不是说这很容易。我只是在说我的个人看法,那就是我希望核心功能(拉取请求、问题)早就有所改进了。我曾是一个排名前0.01%的项目的维护者,我看到过它带来的阻碍,其他工具会更可接受。做他们的粉丝并不总是容易的事。
完整原文> 顺便说一下,这个特定功能——他们现在称之为子问题——实际上更准确的描述是他们在系统中建模正确父子关系的框架,这是一件很难做对的事情。 这是一个错误的框架。父子关系是任务之间依赖关系的一个特例,可以更一般地建模为开始/完成关系,即:开始-开始、开始-完成、完成-开始和完成-完成;在这里,父子关系是完成-完成。当你想要规划比你能在看板上快速看到的更多工作项时,这种区别就开始变得重要了,而这其实是近一个世纪以来的已有知识,而我们整个行业对此完全无知。 有用的搜索词:PERT,甘特图,关键路径,PMBOK。 在我们行业中偶尔会看到一些流行的软件使用。…
完整原文尊重不同观点,分享具体经验。
登录后即可发帖、评论、转发和引用。