纪特、妈问和奥尼Flow
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
高质效交付
扫码关注公众号
扫码阅读
手机扫码阅读
在进行培训咨询评估的过程中,发现不同企业和团队存在着自己特有的“方言”,即对专业术语的非标准发音或理解。例如,将Git错误地读作“纪特”,将Maven读作“妈问”,以及普遍将Feature Branch误读为Future Branch。
有趣的是,在西北某地的经历中,作者遇到了将Aone Flow误读为“奥尼Flow”的情况。面对这种情况,作者选择不直接纠正,而是在交流时使用正确的术语发音。
在某些情况下,作者会跟随团队的叫法,例如将Feature Branch接受为团队称之的“开发分支”,以确保交流无障碍。重要的是明确团队对需求条目的叫法和层次结构,作者关注的是识别出每个最小独立需求条目,无论它被称为Epic、Story、Task还是用户场景,并且确保它是否对应于Feature分支。
如果需求条目没有正确对应Feature分支,作者将其视为一个“Finding”,即潜在的问题点。对于为什么这种对应关系重要的深入讨论,作者推荐阅读《高质效交付》一书。
高质效交付
高质效交付
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
高质效交付的其他文章
GOPS演讲实录:AI4SE修炼之道——从小工到专家
在软件开发过程中,如何让大模型从当前像小工一样的辅助角色,变成高质高效开发的资深专家?这需要把隐性知识显性化。上个月末GOPS大会闭幕大咖秀环节讨论了这方面的内容。本文做了整理,以图文的形式展现出来。
LLM支持软件开发的窍要:喂什么,吐什么
要想在软件开发过程中用好大模型,让它靠谱地为你工作而不是胡扯,那就要提供给它合适的信息。这是喂什么。而另一方面,你和大模型也要一起协作,输出合适的信息,以便将来大模型使用。这是吐什么。
到底什么地方要写单测?其实就一句话
前面说到,从管理角度从技术角度,到底什么地方要写单元测试,什么地方不用写单元测试呢?
单测覆盖率:不要逼人造假
上级领导或者过程改进部门对单元测试的抓手往往是代码覆盖率这个指标。然而这容易演变成“做给上边看”。那应该怎么做呢?
想让开发人员充分自测?他有这条件吗?
如果我们想给开发人员提供一个理想的端到端的自测联调的环境,那这样的环境应该长什么样?
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线