2017年10月站立会议旁观笔记
发布于 2024-10-02
1028
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
项目晨会改进点摘要
在近期观察的一个项目晨会中,发现了几个关键的改进点,并提出了相应的建议:
- 晨会参与人数达到22人,建议分成2-3个小组举行站立会议,这样可以提升会议效率。
- 出现了迟到现象,为此需要制定规则并执行惩罚措施,如微信群内发红包或会议室设立储钱罐,以此培养团队文化。
- 白板上的任务状态列应明确,包括待办、编码、代码评审、待修复和完成等状态,以便于发现资源瓶颈。
- 当前迭代周期和交付周期都设置为1个月,建议缩短周期并采纳持续集成,以实现开发与测试的并行,并尽早发现接口问题。
- 部分成员在晨会中未能充分说明工作情况,因此每个人都需要回答三个关键问题:昨天完成了什么、今天要做什么、需要什么帮助,以及及时报告问题。
- 有成员未能在看板中及时更新任务状态。建议使用物理看板与电子看板(如Jira)并行,以提高信息的可见性和及时性。
- 站会结束时应展示燃尽图,最好在物理白板上手工更新,增强团队成员的参与感和项目进度的可见性。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 820.8K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
不练基本功,遇事多返工
俗话说,练拳不练功,十年一场空!基本功与天赋决定了一个人做事成功的概率,决定了一个人成功的层次。
测试用例评审的旁观记录
测试用例评审应该如何做?
软件开发中的三次法则
摘要:"事不过三"原则强调第三次重复是优化改进的关键节点。在软件开发或AI工程中,当同一问题、错误或操作第三次出现时,应当立即采取重构、自动化、流程优化等措施。这包括代码重构、自动化测试、文档补充、流程改进等具体行动。该原则能有效预防技术债务积累,减少重复劳动,提升团队效率和质量,实现从被动应对到主动治理的转变。
为什么必须首先做规模估计?
这个问题客户问过我,我也解答过多次,但是我一直没有更直接的理由说服我自己,认为必须先做规模估计再做工作量估计。 比如:对维护类的项目,或者是维护类的活动,为什么要估计规模呢?项目组的人没有技术风险,对需求很熟悉。 我总结了如下的理由: (1) 以规模来估计工作量与成本 (2) 规模估计与实现的人与技术无关,比较客观 (3) 可以度量项目的开发效率:规模/工作量 (4)
对愚公移山的反思
愚公移山的故事从小就学过,故事原文如下: 太行,王屋二山,方七百里,高万仞,本在冀州之南,河阳之北。北山愚公者,年且九十,面山而居。惩山北之塞,出入之迂也。聚室而谋曰:“吾与汝毕力平险,指通豫南,达于汉阴,可乎?”杂然相许。其妻献疑曰:“以君之力,曾不能损魁父之丘,如太行、王屋何?且焉置土石?”杂曰:“投诸渤海之尾,隐土之北。”遂率子孙荷担者三夫,叩石垦壤,箕畚运于渤海之尾。邻人京城
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线