专栏名称: 聊聊架构
聊聊架构
目录
相关文章推荐
架构师之路  ·  我升级了,欢迎大家试用 ·  3 天前  
美团技术团队  ·  老显卡福音!美团开源首发INT8无损满血版D ... ·  4 天前  
51好读  ›  专栏  ›  聊聊架构

如果Scrum不行,那到底什么才行?

聊聊架构  · 公众号  · 架构  · 2018-04-24 07:40

正文

策划| Gary
编辑| Alice
1.软件构建工作具有不可预测性

由于存在这种固有的不可预测性,因此大家不应对版本的预期发布时间及功能列表作出过于严格的限制。事实上,即使是增派人手往往也解决不了问题。正如 Fred Brooks 的著名言论,“为已经延期的软件项目增派人手,只会进一步加剧其延期问题。”这样的事实非常残酷且令人头痛,导致很多工作变得异常艰难;(对未来版本进行营销、签订谈判合同以及创建产品路线图等等。)但忽视这一前提则将引发冲突甚至更为严重的异常。

流程建议:

  • 选定较为合适的发布周期,例如每月一次,而后定期发布您已经完成的部分;

  • 选定一组功能并将其完成时间作为新版本的发布时间;

  • 宣传您已经有的,别宣传您将会有的;

  • 不要过度依赖于长期发展路线图,因为一切都有可能发生改变;

  • 不要强迫程序员们承诺在冲刺期限或者特定时间之前完成某些功能。

2. 流程也有成本。其总会对生产力及道德产生影响——且往往极为显著

所有的流程都是有成本的。最轻松、最简洁的流程总是最好的——大家可能对自己实际需要的流程之少感到相当惊讶。另外需要强调,程序员的主要动力源自自我管理与自我激励。

流程建议:

  • 别想着追踪一切。这通常会带来不必要的额外流程及工具;

  • 允许每位程序员使用其最喜爱的工具进行任务追踪——具体包括便笺、纸笔或者软件。总之只要其效率合理,就不要过多介入;

  • 程序员们最适应扁平化的组织结构。事实上,很多有前瞻性的企业都能够在无需管理者的情况下良好运转(例如 Valve、Medium、Zappos 以及Treehouse 等)。

3. 软件从不会真正“完成”。其总是在趋近于完成,但只能无限趋近

软件当中总会存在 bug,您总需要对用户体验作出调整,总会存在需要清理的代码,您也总需要编写更多测试、说明文档乃至更多工作。您必须判断何时停止进一步调整。因此,“完成”这样的定义并不确切。

流程建议:

  • 不要试图收集指标或执行标准以自动执行“完成判断”;

  • 在这个问题上,相信程序员们的直觉、自尊心以及威胁。这将推动产品达到足够的质量水平,且保证他们的工作不受干扰。

4. 程序员需要长时间不间断集中注意力

在理想情况下,程序员既可以远程工作、又可以拥有个人办公室,或者二者兼而有之。只要可能,协作应该是异步加联机并重,远程与本地齐行,同时为讨论项目保留永久记录。

流程建议:

  • 即使众多程序员在同一间办公室内工作,每个人也都可以在线组织会议;

  • 尽量少使用视频 /语音工具(Hangouts、Skype、FaceTime 等),多使用不打扰他人的异步工具(IM、电子邮件、内部版 Reddit 以及 IRC 等);

  • 避免将办公室布置得太过开放,为每个人保留一点私人空间。

5. 编码更像是设计或艺术,而非生硬制造

大家可以想象,如果我们要求雕塑家估计完成一尊雕像的手臂部分所需要的时间,或者要求其承诺在两周期限之内完成整座雕像——这明显非常荒谬。雕塑家拥有完全自我的实现过程。他也许首先会勾勒出自己的思路,甚至会在真正动手之前先用石膏构建一个完整的版本。这些工作最好交给他独自完成——换言之,硬要介入只会给他带来挫败感、低下的质量以及工期滞后等影响。

对于创意工作者们来说,这一点无疑非常重要,而必须强调的是,这一点同样适用于软件编写工作。每一位程序员都有自己的工作方式。有些人喜欢画类图,有些人则喜欢先进行原型编码设计。有些采取自上而下的方法,有些则使用自下而上的方兴未艾。由于创建软件中存在着巨大的复杂性,因此大多数程序员都已经拥有自己的一套完备的测试工具与技术,能够很好地解决这一复杂问题。别干涉,再说一次,别干涉。







请到「今天看啥」查看全文