今天，我们来探讨一下，程序员到底苦在哪里。算法很难，编程不易，但这些并不是程序员加班的全部原因。身为程序员的你，一定也听到过下面这样的段子： 产品经理有三句奇葩口头禅 这个功能必须加 那个需求不能砍 明天上线 老板有三句奇葩口头禅 这个其实很简单 具体细节我不管 你们抓紧 客户有三句奇葩口头禅 我不要这个我要那个 我不要那个我要这个 都不是我想要的 客户不到关键的时候见不着 老板是神龙见首不见尾 产品经理要么下班就走 要么留下看着别人加班 剩下一班程序员夜以继日敲代码 哒哒哒哒哒…… 需求定不下来，功能变来变去，沟通艰难，误会一堆……你没有办法把力气用在刀刃上。 在这样的环境中，很多程序员都会心生困惑。你会隐约觉得这个行业应当更加高效，但看看周围，有类似毛病的企业不少，跳槽好像不能解决问题。 很多程序员就在这样混乱的工作环境中消耗着自己。而企业也并没有因为程序员的频繁加班提升效益。核心研发工作长期陷入僵局，企业最终也会面临危机。 直击问题根源 寻找解决方案 从“很多企业都是这样的”，并不能推出“这是正确的”。事实上，早在十几年前，就有几位技术大咖对这种混乱的软件开发模式提出了质疑。 2001年，17位IT大咖在犹他州盐湖城外群山中的Snowbirt Retreat旅馆相聚。他们有感于软件开发行业的僵化、混乱和信息不畅，草拟了一份特殊的文档。他们的目的是为软件开发提供新的思路，为程序员高效工作提供更好的环境。这就是大名鼎鼎的《敏捷宣言》，它的核心是以下四则价值观 个体和互动 高于 流程和工具 可工作的软件 高于 详尽的文档 客户协作 高于 合同谈判 响应变化 高于 遵循计划 传统软件开发的理解是按部就班和各司其职。这一套听上去很不错，在实际操作中却屡屡出现问题。一来客户的需求会变，二来这个行业本身就日新月异，定好全套计划然后只管埋头苦干这对于软件开发而言并不切实。各司其职这到了实际工作中更是成了推卸责任的借口（想想那几个段子）。 与之相反，敏捷宣言所提倡的软件开发方式是动态的、灵活的、切实的，讲究打破绝对化的分工，让所有人都真正参与产品的创造，形成完整的团队，而不是把压力都强行积攒在程序员身上。 理念固然不错 具体如何实践？ 《敏捷宣言》提出了一套新的价值观，这当然是一种飞跃。但悬空的价值观没有实际成效，具体到实践中，这套理念又该如何发挥作用呢？ 现在，敏捷的开发观念已经被人们广泛接受。在十几年间，软件行业的前辈们摸索出了几套不同的敏捷实践。 既然是实践，自然会涉及很具体的方法。这四套实践都包含可操作的技巧，比如：如何让软件团队的会议简短而富有成效，如何争取客户的理解和协作，如何在团队中保持信息通畅，如何掌握快速迭代的窍门…… 目前比较出名的敏捷实践有Scrum、看板方法、极限编程和精益。这四套实践又各有侧重。Scrum强调集体行动，极限编程适合应对变化。精益已经形成自己独特的小体系，近年来势头很好。看板方法更像一种技巧，也像一味调料，可以加入其他敏捷实践，起到锦上添花的作用。 对于团队和企业而言，接受敏捷就是跟上趋势，对于个人而言，接受敏捷就是适应未来。 在信息时代，周围的一切都在飞快地变化。曾经，新生团队难以超越定型的老团队，小企业也不可能快速崛起。而现在，这些都是很平常的现象。软件行业越来越开放，技术垄断这种传统大招已经很难玩出花样。想要争夺人才，提升成效，软件团队必然要为技术人员提供更好的环境。 在这个大背景之下，能不能掌握敏捷的精髓，很有可能决定一个软件开发团队未来的成败。 诚然，敏捷一词现在很受欢迎，但这并不意味着有更多的人真正了解敏捷。从价值观到具体实践，敏捷已经构建出一个颇有深度的领域。如果缺乏全局观，只是“拿来看看”“照着做做”，团队很难真正获得敏捷的力量。 值得一提的是，关于敏捷的图书往往侧重于理念的讲解，或者只是选取一套具体的实践。兼顾价值观、历史和实践，将不同的几套实践全部介绍清楚的书很少。对于不愿盲目选择具体实践，希望真正了解敏捷全局的读者而言，这是一个缺憾。 终于，O'Reilly近年推出的《学习敏捷：构建高效团队》填补了这个缺憾。 作者：Andrew Stellman，Jennifer Greene 译者：段志岩 郑思遥 本书赞誉
作为一名工程师，我一直认为敏捷实践解决的是行业中的大问题。其实做到敏捷很难，这不仅仅是实践的问题。正如作者所说，零碎的敏捷方法只能带来“聊胜于无”的结果。如果你刚刚开始实践敏捷，或者只做到了“聊胜于无”，那么你可以从这本书中得到很多实用建议，Andrew 和 Jennifer 会告诉你如何深入理解“敏捷宣言”，真正做到敏捷。 James W Grenning，Wingman 软件公司创始人，敏捷宣言起草人之一
书中全面整合了很多实战资源，想要学习敏捷的人都可以轻松获取。他们在书中谈到了敏捷的诸多方面，而不只是讲解了敏捷团队的理想状态。通过挖掘敏捷的不同要素，他们呈现了敏捷的标准实践和最佳效果，也指出了人们对敏捷的常见误解及对应的结果。此外还讲解了具体的实践和做法会对不同职责的个体造成怎样的影响。对于初学者和有经验的敏捷实践者而言，这本书都是很好的学习资源。 Dave Prior，敏捷顾问兼教练
在软件开发团队中，相比专业知识和工具，文化氛围对于项目的成功更为重要。关于如何将不同人的割裂视角凝聚成全体成员的统一视角，让团队共享价值观和实践，Stellman 和 Greene 的建议能够为任何组织的项目经理提供帮助。他们比较了 Scrum、极限编程、精益和看板方法，分析了敏捷原则的多种实践方式。书中生动的例子解释了人们在走向敏捷的过程中所遇到的困境以及收获的成果。 Patricia Ensworth，Harborlight 管理服务有限责任公司董事长 附：目录 第 1 章 学习敏捷 第 2 章 理解敏捷价值观 第 3 章 敏捷原则 第 4 章 Scrum 和自组织团队 第 5 章 Scrum 计划和集体承诺 第 6 章 极限编程与拥抱变化 第 7 章 极限编程、简化和增量式设计 第 8 章 精益、消除浪费和着眼全局 第 9 章 看板方法、流程和持续改进 第 10 章 敏捷教练 写在最后 软件开发团队的领导者一定更要学习敏捷，否则会被时代甩在身后。有志向的基层程序员也应该学习敏捷，因为懂得敏捷的优秀程序员更有可能得到晋升。 如果你想了解敏捷，如果你对敏捷还有困惑，那就来看《学习敏捷》。如果你被领导折腾得苦不堪言，那你就送他（她）一本《学习敏捷》。如果领导不接受，书就留着自己看吧，看懂了，你迟早能当上领导。 【阅读原文】亚马逊购买《学习敏捷》 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
