来自前 iOS team 成员的抱怨

iOS，macOS 近年来质量稳步下降，大家有目共睹、怨声载道，我们有各种猜测，这里有一则前员工的抱怨，大家可以从中管窥苹果到底发生了什么问题：

https://www.reddit.com/r/apple/comments/7x0eif/how_apple_plans_to_root_out_bugs_and_revamp/du4z6bx/

As someone who used to work on iOS at Apple, what that company honestly needs is a culture not beholden to the whims of their EPMs (project managers). They used to help organize and work with engineering to schedule things across the company ’ s waterfall style development. However, by the time I left, they essentially took power over engineering. Radar became the driver for the entire company and instead of thinking about a holistic product, everything became a priority number. P0 meant, emergency fix immediately, P4 meant nice to have. You get the idea.

Nothing could be worked on if it wasn ’ t in Radar with a priority number attached and signed off by the teams ’ EPM. No room for a side project or time away from your daily duties because there were always P1s to fix. If you didn ’ t personally have any left for the day, you ’ d take one from another engineer who was likely swamped with their own list of P1s.

P1 P1 P1, everything is always in crises mode. Also why I and everyone around me felt bad for taking any vacation. If we weren ’ t constantly thinking about fixing those P1s, we were some how letting our team down.

This is how you get bugs in shipping software. EPMs driven to schedule things and over manage engineers would decide on a whim that something was a P2. That was basically always shelved to a follow-up .1 release.

Ultimately, engineers lost the freedom to decide when a feature was ready to ship. So here I see some “ leak ” about quality and I think, this is just PR spin for a buggy iOS 11. Unless the company is willing to take power away from the all-mighty EPM org, I just don ’ t see how engineering will really change.

bookit

2018-02-13 16:12:08 +08:00

这个工作流程看起来是敏捷开发那套，任何任务都有优先级，然后根据优先级重要性评个分数，每个 team，每个人都被分配到几个任务，每周每月按完成分数排名次，定绩效

十年前我就觉得这套玩意不行，搞出来的软件质量不如传统开发模式。这模式极其容易被混子钻空子，非常有利于善于表现自己，是抢功劳的嘴子升官发财的模式。

当时以为是 team 成员能力不够，搞敏捷开发不能达到书中说的那样高效快速精简，没想到苹果这种大公司也经不起这套模式的折腾，我猜微软也不行，看 win10 那个完成度，怎么好意思拿的出手。。。。

gefranks

2018-02-13 17:54:01 +08:00

我觉得涉及基础的软件和上规模的软件不该用什么敏捷开发
急吼吼的搞个设计看看能用就上了，后面做起来留下一堆坑，坑这个坑那个，最后都搞得一坨，后面的杂事还多了一堆
今天看了状态这个 sprint 又 fail 掉一堆 story，反正我时间就这么多。搞不出来就是搞不出来。
我就觉得每天早上的 5 分钟会比较有用。。至少知道别人都干啥了

beimenjun

2018-02-13 18:21:40 +08:00

@cairnechen 个人觉得开发领域有什么模式是不被喷的，至于 Alan Cooper 喷还是不喷对这个结论影响不是太大。

我还是觉得 iOS 的问题是要做的太多了，以前 iOS 的稳定，是建立在几种分辨率几种机型上的，现在盘子这么大，每年又在追赶新技术，安排就算不失当，内部开发工作觉得体验极差，也只是一种历史的必然。也许重写一遍 iOS 会改善很多问题，又是好几年后见了。