物联网|是哪些人,在实践中华田园敏捷?

物联网|是哪些人,在实践中华田园敏捷?

在外国知乎Quora上曾经有人提出过一个问题“为什么像谷歌这种公司的开发人员认为敏捷开发是扯淡?”前谷歌技术工程总监David Jeske提供了一些看法 。
他的主要看法在于适用于敏捷开发的软件主要是面向外部人员需求的软件 , 客户占主导地位 , 可以在任何时候改变自己的想法 。 因此敏捷开发具有短期规划、直接与客户接触、持续迭代的风格 , 这种开发风格 , 适用于可用性可以不断叠加的软件 。 而对于那些只有简单的用户接口 , 却具有非常复杂的内部实现的复杂软件并不适合 。
因此 , 像谷歌这样一直在编写革命性软件的公司 , 在复杂的子组件编写完成之前 , 对于用户来讲 , 软件是无法工作的 。 因此并没有向对于软件一窍不通的外行人展示的需要 。
David举了谷歌内部的Bigtable和Borg项目的例子 , 这种类型的颠覆性创新需要大量的预先设计时间 , 并且需要在超过一周的迭代中为编写组件而工作 。 由于项目的外部接口如此简单 , 以及内部复杂性如此之高 , 以至于许多工作对“客户”甚至无法可见的 , 因此没有办法编撰客户可见的相关用户故事 。 这种类型的软件需要8-20个月的时间向客户交付第一个工作版本 。
而这种类型的软件天然是反Scrum的 , 它们代表了技术领导者的长远考虑 。 在长期的软件研发过程之后 , 成果让谷歌获得了极其丰厚的回报 , 并且进而影响了整个行业 。 成为了大数据技术发展史上重要的里程碑事件 。
从David对于敏捷开发的看法 , 我们可以看出 , 是否适用敏捷开发的项目有一个重要的特点 , 那就是技术领导者是否能够掌控更为长期的软件特性设计 。 这种掌控力体现在软件设计的能力和对需求方的控制力 。

所以对于外国的程序员而言 , 如果软件本身是类似于财务或者电脑游戏之类有着确定的产品特性的 , 那么在软件部分完成的时候 , 并不适合交付给用户体验 , 因此并不适用敏捷开发模式 。 相反 , 那些需要经常考虑用户体验的 , 像很多外包项目 , 则比较适合采用敏捷开发模式 。
然而敏捷开发到了中国却发生了一些细微的变化 。 外国的程序员本身和其它工作一样 , 是一种普通的工作 , 大家都很淡定 , 专职的从来不管人的资深程序员并不会受到歧视 。
【物联网|是哪些人,在实践中华田园敏捷?】而中国是一个官本位的文化 , 程序员本质上是一个不掌握社会资源的职业 。 因此 , 在程序员内部就会出现一些热衷于管人的开发团队领导者 , 从而出现了中国特有的 , 在无需向客户每周汇报的情况下 , 开发团队领导者自己无法掌控软件的产品特性 , 却热衷于享受对团队指指点点的快感 。 在此情况下 , 发展出了中国特有的需求不懂就瞎定、开会吵架就甩锅、临时突击赶上线、人肉测试新功能的中华田园敏捷开发模式 。
开发模式无所谓好与坏 , 只有适合不适合 。 然而总有一些教条主义者奉某些方法为圭臬 , 忽视了软件开发本身是一项强脑力劳动的特性 。 更有甚者 , 在一些完全不适用敏捷开发的场合强行敏捷 , 例如说某个研究所引入了一名大厂的高级专家 , 强行对某军用软件搞敏捷 , 最终的结果就是团队只能跑到用户单位在内网驻场敏捷 。 该专家此前还表示过先上线 , 出了问题远程修复 。 后来被人一巴掌拍回来:有种你丫给原子弹远程修个bug试试!