Category: 敏捷开发 Agile

公司的 No-blame 文化

有一次, 在公司敏捷开发的例会上, 有一些测试用例在一些代码合到主分支上不通过了导致其他开发者需要等待处理, 这时候Scrum Master说 这是谁干的? 旁边的一个工程师立马说, 我们这是 “No blame culture…” 这时候 Scrum Master立马笑着说: “你说的对, 我们找出是谁干的 we find out who did it and…, 然后我们就继续前进(意思是说找出谁干的就好了) we move on…” 还有一次, 也是谈到这个 …

说说敏捷开发的例会 Daily Standup

敏捷开发 Agile Development 是国外比较流行的软件迭代流程. 虽然有几个变种(稍微有点不同), 但是每天例会 Daily Standup 是必不可少的. 每天例会大部分是在早上的9点到10点, 也有的安排在下午 – 比如公司的开发团队比较大, 被分成了几个小组, 而开会的办公室不够用了. 敏捷开发的例会的长度 例会应该尽量控制在 15到20分钟内完成, 会不是越长越有效. 敏捷开发的例会怎么开? 在哪开其实无所谓, 甚至可以在厨房开, 大家也不需要很严肃. 我在GE开例会, 经常有开发人员拿蛋糕吃的放在桌上, 然后会后切着分着吃, 很和睦. 开例会有一点前提, 就是要站着, …

说说技术债 Technical Debt

技术债 Technical Debt 是软件工程上特别是敏捷开发 (Agile Development) 中的一个概念. 指的是解决一个当前问题最好的方法往往需要更久的时间和精力, 但是为了加快软件开发进度, 赶在代码冻结前按时交差, 采取的一个较为折衷的解法方法. 但是这就是一笔债一样, 可能会把潜在的问题越积越大(利息), 甚至将来却无力偿还(修复). 1年半前, 我提了个BUG, 这个BUG大概是说一种数据文件里如果用TAB而不是空格来隔开字段, 则导入数据过程中软件会崩溃, 这个BUG的确是有效的, 因为把这数据文件放到别的软件中导入则是没有问题的. 前前后后讨论了半年, 然后总算被批准了, 不过由于开发任务繁重, 而且也不是那种非改不可的BUG, 所以就一直拖, 拖到今年10月份, 突然接到邮件通知: “agreed to …

敏捷开发扑克游戏

敏捷开发 Agile Development 在每个短跑 Sprint 开始的时候都会有一个 圆桌会议. 开发小组成员会聚在一起 讨论需要开发的任务 并且会细分每个任务. 这时候我们就可以用到下面的扑克卡片. 预先需要有一个成员(可以是随机, 可以是轮流) 先把需要开发的任务汇总一下 并且把每个开发任务尽可能的细分成子任务. 这时候一开始会选一个难度适中的任务做为标准 (分数为1) “每副卡片可供4人预估 分数为 ?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, …

敏捷开发 – 燃尽图 (Burn Down Chart)

之前介绍了敏捷开发中的大显示器和任务分解, 还有一个比较有用的图表就是 燃尽图 (Burn Down Chart). 横坐标 是剩余时间 纵坐标是剩余任务数量. 理想状态下 我们会有一条 y = -kx + b 的直线. 当到最后规定时间的那一天 整个团队刚好完成所有的任务. 当然 团队做得进度比理想的要好的时候 实际的这条线就会在下面 相反如果进度拉后就会在上面 或者交叉前进. 这时候我们可以从这个表中大概估计团队的整体进度 或者及早发现如果有的任务卡住了怎么办. 英文: https://helloacm.com/agile-development-burndown-chart/ 本文一共 …

敏捷开发 – 短跑墙

在敏捷开发里 (Agile Development), 每一个短跑(Sprint) 就是在一段时间内 保证完成计划的任务 而不受其它事情的干扰 这样在时间段结束后工作进度就能被 审核. 在黑板上 贴有每个被细分的任务, 不同颜色代表不同的工作类型, 当工作无法完成(因为没有预料到的难度或者其它事情的影响) 这时候就可以把项目所代表的便贴纸给移到 “Blocked” 那栏. 同样, 如果完成了 就移到”完成”那栏, 这样团队的成员就可以随时了解到团队的整体进度. 英文: https://helloacm.com/agile-development-sprint-board/ 本文一共 175 个汉字, 你数一下对不对. 敏捷开发 – 短跑墙. …

大屏幕 – 敏捷开发

公司搞了一台50寸的大显示器, 非常好用;可以在上面显示各种代码数据.这些数据都是从编译服务器(Continuous Integration 持续集成)上获得的.统计数据包括:代码行数,单元测试用例的个数(每个开发人员都有自己的一条曲线),通用异常,编译警告等等. 每周团队计划的任务也一并的显示在上面(记事本大字体显示就可以),这样大家都很清楚自己要干什么,甚至别的部门也能了解,减少了沟通成本. 这样做挺好的. 英文:https://helloacm.com/a-big-monitor-does-help-in-improving-agile-development/ 本文一共 161 个汉字, 你数一下对不对. 大屏幕 – 敏捷开发. (AMP 移动加速版本) 赞赏我的几个理由. ¥ 打赏支持 扫描二维码,分享本文到微信朋友圈