1,557
社区成员
发帖
与我相关
我的任务
分享敏捷开发探讨
2015了
现在在一家国内大型电商工作，我们公司使用的是敏捷技术， 有几个问题
1我们项目的代码很多模块已经很臃肿，可读性也不高，每次进行修改光查看代码就需要很长时间,但是没人重视重构。
2敏捷虽然不要文档，但并不代表没有文档，而我们项目的几个核心流程没有什么文档，更不谈与线上情况相同的文档了，每次做一个不熟悉的功能 都需要问好几个人
3我们有自动化 ，但是自动化是为了补指标而已，很多都是为了改自动化而改自动化
4单元测试，有了自动化 基本没人写自动化测试
我觉得有几个重要的点需要补上
1 每个模块必须有一个大的业务流程图，核心的模块能有详细的业务流程就更好了
2 代码的可读性，设计，清晰性非常重要，其实我们80%的时间都在阅读别人的代码和修改
3 核心的逻辑进行自动化覆盖，通过率是为了重构和预警 100%的通过率是基线
4 单元测试还是需要写 这里暂时不提tdd 起码核心的功能写点单元测试
大家有什么看法
现在在一家国内大型电商工作，我们公司使用的是敏捷技术， 有几个问题
1我们项目的代码很多模块已经很臃肿，可读性也不高，每次进行修改光查看代码就需要很长时间,但是没人重视重构。
2敏捷虽然不要文档，但并不代表没有文档，而我们项目的几个核心流程没有什么文档，更不谈与线上情况相同的文档了，每次做一个不熟悉的功能 都需要问好几个人
3我们有自动化 ，但是自动化是为了补指标而已，很多都是为了改自动化而改自动化
4单元测试，有了自动化 基本没人写自动化测试
我觉得有几个重要的点需要补上
1 每个模块必须有一个大的业务流程图，核心的模块能有详细的业务流程就更好了
2 代码的可读性，设计，清晰性非常重要，其实我们80%的时间都在阅读别人的代码和修改
3 核心的逻辑进行自动化覆盖，通过率是为了重构和预警 100%的通过率是基线
4 单元测试还是需要写 这里暂时不提tdd 起码核心的功能写点单元测试
大家有什么看法
...全文
请发表友善的回复…
发表回复
qq_39963327 2018-12-04
- 打赏
- 举报
国内小公司没有进行敏捷的环境
伏其 2017-07-17
- 打赏
- 举报
真正采用敏捷方法的项目开发需要两个先决条件：1、管理层支持；2、团队认同。达不到这两个条件，谈其他的都太早了。
smallcrocodile 2016-08-30
- 打赏
- 举报
敏捷就是个被炒作的概念
阿三 2016-03-01
- 打赏
- 举报
主要看如何运用了，再好的方法工具不会用也白搭
伏其 2015-07-29
- 打赏
- 举报
同意楼上的观点，先问问你们自己到底是不是在敏捷吧。
楼主第一句话就错了：敏捷不是一门技术，它是一门艺术。判断是不是敏捷不是因为你们有没有文档，或者有没有自动化测试。不要想是不是敏捷了，也不要纠结现有代码的臃肿繁琐了，先把人员的意识培养起来再说。
以专业开发人员为伍 2015-02-21
- 打赏
- 举报
写“可执行的”测试用例其实比开发更需要实力。绝不是什么“有了自动化 基本没人写自动化测试”。一个人可能可以轻松写出几万行代码，但是感觉最难的一定就是“实在不知道如何写出那一行测试代码”。所以但凡假的敏捷开发人员，都是只注重行政上的敏捷，一旦要他写出大量tdd它就怂了。
敏捷不是不重视文档，而是要求开发人员“水平平均”之后，经常亲自做较大规模的代码重构，也就俗话说的“把飞机推下悬崖，然后在坠地前使其顺利飞起来”，具有此类“执行力”层次的人所知道的“诀窍”来写文档。熟悉了这个过程，人的层次提高了之后，你肯定可以写适应这些层次的人想看的文档的。有些人想看畅销小说或者经济管理分析专著，而你们说的文档则可能只是小学生的“练习题答案”。其根本区别就是“读者对象不同”。
你现在把问题归咎于“核心流程没有人教你们，代码不够有洁癖，测试代码没有时间去写，感觉自己无法理解tdd的决定性作用”，这些都跟一个小作坊的程序员硬提拔起来的小经理的想法一样。
以专业开发人员为伍 2015-02-21
- 打赏
- 举报
对于敏捷开发来说，随便拿出一个核心业务，你能够立刻回顾出来围绕这个核心业务的7、8和核心的测试代码是怎么写的？有没有压测到内部的所有主要功能？有哪些内部功能可能（估计明知道）漏过去了？
看人的状态就知道，这样的人不存在了。大凡是这个时候，随便用自己的肝、胃都可以想到，剩下的人就一定会纠结“文档”问题。
因为核心业务、核心代码、核心测试，都根本拿不起来了。
以专业开发人员为伍 2015-02-21
- 打赏
- 举报
这就是在“维持”而已，这时候说“敏捷”则可能就是给自己脸上贴金的口号，敏捷只是过去式了。
敏捷是高强度的，不是给哪些层次较低的小工找借口。一些公司时过境迁，把真正实施敏捷开发的人挤走了（至少人家呆不下去了），剩下的人自认为“很容易接手人家的东西”，结果现在考虑的都是“维持”
如果什么“精通业务流程、阅读代码、tdd”都成了滞后项目的因素，那么你们早就已经进入小作坊、行尸走肉的开发状态了。请
不要用“敏捷开发”这个词儿，因为从描述中根本没有看出敏捷开发的技术素质，我感觉你们至少需要3年学习，或者请来真正懂得敏捷开发的人用半年时间重新开始才有可能。
kelph 2015-01-26
- 打赏
- 举报
你们哪里使用的是敏捷的技术？没看出
偏离了敏捷的目标，何谈敏捷
你们已不是方法论的问题了
缪军 2015-01-20
- 打赏
- 举报
这些问题恰恰是"敏捷"重点解决的问题
ckc 2015-01-19
- 打赏
- 举报
敏捷可以解决一些问题，它不能解决所有问题。
我觉得敏捷实际上可以比较好的解决用户需要变化快、确定明确用户需求需要代价很大的问题。
它并不是万能的，测试的问题，重构的问题明显不是敏捷所能解决的范围
缪军 2015-01-17
- 打赏
- 举报
没有先进的生产和管理工具,就不是敏捷制造;
如果开发不以文档来驱动,连正规的开发都算不上,
如果有文档,但是就是word或者excel之类的"死"的文字,那是落后产能的表现
一个开发组织,如果有十几年产品的经验,却没有自主研发或者购买软件生产企业的信息化管理系统(Erp),是说不过去的,
软件企业一天到晚忙着为别人做软件,自己却不曾意识到为自己花上百八十万搞信息化建设是值得的
yuwupian 2015-01-16
- 打赏
- 举报
楼主提的问题都不简单啊。
关于你说的1和2，我们公司也正面临着这些挑战，做了十几年的产品积累下来的代码不仅臃肿，而且漏洞百出。产品交付后，运维人员抱怨该有的文档没有，开发人员又抱怨要写的文档太多。。。。
关于第3点，自动化可以节约回归测试的工作量，但自动化不能完全替代手工测试。自动化工具需要维护、回归用例的数据需要配置和调试，又想马儿跑又想马儿不吃草的事儿是不可能的。
关于第4点，单元测试当然有必要，但众所周知，能写好单元测试用例的基本是开发人员。因国内程序员的待遇水平与高负荷工作的矛盾日益突出，以及程序员看自己的代码如同看自己孩子似的越看越欢喜的现状，让开发人员写好单元测试用例确实有点儿太为难他们了。。。此处建议引入代码交叉走查流程，单元测试只能慢慢推。
