阳光蝙蝠:Bug与ToDoList都可以通过持续集成方案处理,恐惧的根源在于无休止的需求变更。
繁少LeSaRDe:于是当部门经理问开发人员,“搞的怎样啦?”,开发人员说,“还有bug”,当项目经理问部门经理,“搞的怎么样啦?”,部门经理说,“还有bug”,当总经理问项目经理,“搞的怎么样啦?”,项目经理说,“还有bug”,当用户翻开产品使用说明书,第一页赫然的写着,“本产品还有bug”……
woshigoushiyun:我也觉得标题很刺啊,不过我也没法直接反对这个说法呢,在敏捷开发过程中,bug统计确实可有可无啊,测试驱动开发,有问题当时就解决了,干净的逻辑看来,记录已解决的问题成本有些多余。当然仅限于事情本身了,管理角度的想法估计不同吧,毕竟一个公司来说开发不只是那点事。
其实我一直都不低调:bug统计到底有没有用见仁见智,关键要看怎么统计,想得到什么。从来没有认真分析过bug数据的人,肯定不会知道数据里面隐藏着什么。抛开bug统计这个问题,缺陷追踪工具到底是一个什么地位?一个项目2000bug,如果没有工具辅助,所有人估计要崩溃了。没有人直接反对这个想法,应该这是DEV的内部会议,与测试无关。
双子的天马行空-Adey:其实我觉得他说得很有道理的, 真正的敏捷应该不需要bug track system。Facebook的开发模式,就是dev直接面向客户,它有多个直接面向客户的开发团队,,只要有需求,开发后直接上线。如果后面有issue,是有second tier的dev team来support fix。tier one的dev永远在敏捷快速状态。
柴阿峰:回复@双子的天马行空-Adey:三五个人的成熟团队敏捷也许不需要,大部分还是需要的。否则各种基于bug trace的管理系统就不需要开发持续集成、变更驱动测试的功能了。好的软件可以帮助实施敏捷,而不是反过来,不可能什么都靠嘴和白板的。
Sab866:敏捷的基础是团队成员都是自律自发且积极的,不需要用报告来鞭策,但是简单易用的缺陷管理工具还是必须的,不然还真是会一片混乱。
欢迎光临 思步网 (http://www.step365.com/) | Powered by Discuz! X3.2 |