IDEAL Garden

这篇文章讨论了全栈开发的好处和如何开始转型，以及在需求分析和架构设计中如何分层和隔离业务变化。作者分享了不同类型知识的学习方法和针对语言和框架的练习建议，以及通过结对编程和TDD加速学习的技巧。

互联网信息检索是一个非常重要的能力。这里，我整理了一些常用的信息检索材料，希望能帮助到写作和需要在网络中获取数据的人们。

这里有四种离岸交付合作模式：Team Extension Model，Hybrid Collaboration Model，E2E Collaboration Model和Onshore/Offshore Collaboration Model。每种模式都有其优势和挑战，需要根据组织自身情况选择合适的模式。其中E2E Collaboration Model是一种全面的离岸交付模式，适用于团队成熟度较高、业务模块相对独立的情况。

本文探讨了如何构建低碳 Web 应用来应对气候变化和碳排放问题。文章指出，通过精简压缩 Web 应用、降低数据传输量以及优化应用性能等措施，可以减少碳排放。文章还强调了在软件开发生命周期中落地相关举措的重要性，并提供了一些测试工具和实践经验。

随着气候灾害，极端天气的频繁出现，关于气候变化的讨论已经越来越多。各国政府，各行各业也逐渐将可持续发展提上议程。软件作为日常工作生活中不可或缺的一部分，它和气候变化之间有什么关系呢？我们作为软件从业者，又可以做些什么来促进气候目标的达成呢？本文将从软件对可持续发展的影响出发，举例介绍软件如何从三个方面降低碳排放。然后就其中一个方向-软件自身碳排放进行介绍，再到绿色软件的定义，度量和原则。最后提出作为软件从业人员现在可以做些什么。那么到底什么是绿色软件呢？

一个合格的职场人，所需要具备最重要的三项技能：沟通能力，时间管理能力和团队合作能力，其中沟通能力又是作为基础当中的基础。

在团队成员向Tech Lead寻求帮助时，Tech Lead首先要做的是明确提示期望，识别能力差距，其次是引导团队成员自己得出解决方案，最后制定培训计划以提升团队能力。

这篇准备了很久，又临时起意，而终于“完成”了的短文，旨在将一些我觉得重要的建议讲给渴望成长，又不知从何做起的同学们。这里分享的几个小的点，做起来难度应该都不算大，如果能持之以恒，我相信你可以看到自己成长的速度。

度量软件开发生产力的指标维度和数量，需要取得平衡，既要少到能恰好代表软件开发生产力关键要素，也要多到恰好能提供用于持续改进的上下文。

敏捷文化的核心或者源泉，是对团队的”信任和Ownership“，团队的每个人知道项目想要取得的结果，并对结果肩负责任，它们是团队活力和创新的基础，也是高绩效的基础

打工人的发展困境，主要集中在价值感缺失、晋升通道不明朗和干系人不满意几方面，本文将会讨论困境发展的成因，并通过列举一些可能有效的尝试和思维转变，探讨可行的方法，以突破职业生涯的瓶颈期。

对于敏捷软件开发者来说，及时获取完成任务所需的信息及实现共识，包括业务价值、技术方案、验收标准以及反馈，显得更为重要。因为这些决定了他/她将以什么样的方法、多少成本去交付何种价值的可工作软件。

团队由一群身怀绝技又各不相同的人所组成，大家有共同的目标，并愿意为之而努力。打造你的全明星团队，和团队一起设立愿景，这是你团队走向成功的基石！

好的日志不仅可以为程序开发提供便利，为故障排除提供最重要的辅助信息，更可以为业务或基础设施提供优化建议或数据统计。

作为一名程序员，总有一些时候，会对自己所做的重复性的工作感到厌倦，也会羡慕明星项目做得热火朝天 Star 数蹭蹭上涨。而读代码，则是缓解焦虑的良方。

行动者的异质性导致了技术发展的多样性。当我们结合微观与宏观的视角时，技术对于社会的影响便不再是点对点的，而更像是一层层洋葱圈。本文将从三个方面探索技术对于个人以及社会的作用力。

程序员的日常就是要在无数失败中找寻让程序正常运行的那一种组合，成功运行更像是运气与实力的双重作用，这也就有了失败驱动开发（Failure Driven Development）。

近几年，随着数据和人工智能越来越受关注，数据与人工智能项目（统称数据项目）也遍地开花，和传统应用类项目相比，数据项目有其自身的特点和挑战，本文就来盘一下这些挑战。

本文从“团队协作的五大障碍”出发，首先对团队协作过程中遇到的各种问题进行抽象归类，然后分享我们在团队中试过且效果很好的一些敏捷实践，最后展示建设成果，最后展示建设成果。

反馈文化在敏捷实践中能起到积极作用，团队成员在收到了正向的反馈之后，会觉得工作得到了团队的肯定。这样也就知道了自己所做工作是有价值的，在一定的程度上促进了团队的凝聚力。

分享离不开写作，写作并不需要多好的天赋，写作贵在坚持，不要担心写的不好，完成比完美更重要。分享可以打破封闭，只有你能分享的知识，才是真正属于你的，分享可以让你结识同道中人，同时实现自我价值。......

充分熟悉和理解项目背景，产品愿景和干系人关系永远是重要的第一步。在拒接“标签化”客户的同时，也不要“标签化”自己，在认清当前不足的前提下，也要敢于质疑，勇敢尝试, 最终才能自信地和客户"say no“。......

Retro 是敏捷软件开发方法中的回顾，有很多种形式，可以根据团队所处的上下文来选择。本文分享了Retro的形式和注意事项，帮助避免其流于形式。

如何学习某个知识，在我看来，主要矛盾在于解决这三个问题。

面对问题时，我们都希望有个上帝视角的智者给出标准答案，但是很难如愿。通过复杂问题的的简单拆解，可以将难以决策的事情转化为可执行的行动项。剩下的过程就交给时间，不管结果怎样，都比浪费大量心力去纠结要划算得多。

当我们在工作中交流时，能注意概念的统一和尊重同一律、矛盾律、排中律等逻辑学基本要素时，沟通会变得更加高效，吵架也更加有理有据，并从中得到成长。

搭建一个有吸引力的变革第三空间，不仅要注重个人和团队的成长，更要设计并公开先锋者能够得到的利益，从组织和机制上保护先锋队；不仅要保护变革领导者和先锋队的连动，更要鼓励两者与组织其他角色的互动，鼓励与其他两个空间的交互，形成开放系统。

Stand-up会议必须在每一天的同一时间、同一地点召开。这么做可以省去定会议室、通知团队成员等一系列不必要的步骤，进一步提高团队的沟通效率，也是一种仪式感，让 Scrum 深入每个团队成员的DNA。

最近，我总在思考一个问题「产品经理需要懂技术吗？」当我和研发团队深入交道的这段时间，在发现产品经理和技术团队交流时的两大「忌」后，体会到：大公司的产品经理要不要，我不知道。但小团队中，尤其是创业团队中的产品经理 需要 懂技术！产品经理交流两大「忌」01. 忌「不懂技术」「懂」技术，更直白的讲，应该叫了解技术。这并不是要求我们产品经理要完全掌握技术，能像技术人员一样，写代码实现需求。准确的说，是不能缺乏设计、开发一个互联网产品基本的技术常识。因为如果不懂，则很难在合作时具备同理心，经常会出现以下对话：

我在《我的时间管理工具》与《我的笔记系统》中分享过我不断演进的时间管理工具与笔记系统。在使用这些系统多年后，始终有个困惑萦绕在我耳边，那就是：单纯的记录时间、笔记和资金是一种碎片化的行为，容易导致过于追求细节而忘掉全局，让自己成为一个忙碌的战略懒人。时间管理、记账、记笔记、学习、写作、阅读、交流这些行为都不是最终目的，它们只是一种实现个人长期目标的辅助方法，如果做这些事对长期目标毫无帮助，那没必要浪费时间去做。虽然我做了大量的时间与资金开销记录，但我也很难评估这些开销对实现长期目标有何影响。这种困扰可

“How to Use Open Source and Shut the Fuck Up At the Same Time”去年在用 Node.js 编写一个 side project 的过程中，因为需要集成不同第三方网站的 OAuth 登陆，所以接触到了 passport.js 。虽然各类渠道都表明它似乎是 OAuth 解决方案的不二之选，但是在实际集成的过程中发现问题颇多，在前往 GitHub 上查看有没有相关的 issue 时，惊讶的发现 passport-github （passport 下允许使

我比较幸运，无论是读书时期的兼职零工，还是毕业后的正式工作，和老板（直属领导）关系都还行，没有发生一些不愉快的事情。不过对身边发生的一些见闻感触很多，对一个优秀的管理者的样子有一点自己的思考和理解。这里写几个亲历的故事，大家不妨看个热闹。小老板的故事高中毕业的时候在老家的小城市找了一份暑期兼职，工作的内容就是在手机零配件批发部给手机维修师傅送货。那个时候还是功能机时代，手机维修的需求很多，手机维修需要一些屏幕、听筒、排线等配件。城市不大，骑个自行车市区10 -20 分钟内大部分地方可以送到，所以老板喜欢

会议是职场中常见的团队协作活动，也是进行决策、传递信息、达成共识的重要工具。相信屏幕旁的你也经常组织和参与各种大大小小的会议。可是，你真的会开会吗？“这还不简单，将人拽到一起，说一下主题，订1个小时，再弄个线上会议室，不就结了？”“要不要提前准备一下，会上遇到问题怎么办？”“不用，能有啥问题，到时再说呗。”呃? 这么说也没有错。可是听起来不太对，问题在哪里呢？让我带你进一步分析一下。前文讲到，任何能解决问题的方法，它必定有可以工作的隐藏假设和论据在支撑。那么，上述看似不合理的对话中，你认为有

困惑的概念相信接触过传统企业数字化转型项目的话，你应该都听过敏态与稳态这两个词。敏稳结合的转型方法在大多数的客户转型咨询方案中会提及。但随着客户越来越多，其上下文也越来越复杂，我们发现在和客户交流敏稳态的时候理解上会有很大差异，最直接的表现就是词汇越来越多，但对它们的理解并不一致，例如：敏态、稳态；敏捷、精益；双模、双态、双速等， 所以本文尝试梳理这些概念的含义以及彼此之间的关系。“敏态”与“稳态”数字化是近些年传统企业的转型方向，其中敏捷转型是企业在数字化转型中很重要的一部分。一方面企业引入敏捷方法

几天前，同事小Y发来微信。“嗨，你参加过AWS考试吗？你说我要不要先考一下AWS从业者证书？” 小Y问道。“你对AWS证书了解吗？” 我说。“不是很了解。” 小Y回答。“建议你先做做功课再做决定哈，了解清楚在考这个证书的过程中你能学到什么？证书有什么作用？你为什么在当下选择考它而不是别的？”“另外，你为什么忽然想要考AWS证书呢？” 我问道。“我看到XX和XX都在考，所以想一起考。” 小Y答。小Y是2019年毕业加入公司的QA，和大多数新人一样好学上进，眼里充满对知识的渴望和对

两年前写过一个女性专栏，用讲故事的方式把自己在职场的成长经历扒了个遍，两年来，断断续续有很多女性找我聊天，聊职场的困惑，聊家庭和工作的压力，聊育儿的焦虑，聊成长和发展的瓶颈，以及各种不甘心，作为职场女性，我能感受到，我们遇到的大部分问题都具有普遍性，只是平时公开交流的机会少，很多人会认为自己是最另类的那一个，甚至认为自己是“不幸中”的“不幸”。我整理了一下经常和身边的女性讨论的问题，也和当事人确认过，现在把这些问题分享出来，如果你也遇到过，希望我们共勉，接下来咱们就来聊聊天。01 无休止的平衡问题“你

看到题目你可能就笑了，买书还用你教？确实，对于书这种相对廉价的消费品，有啥可说的，买就得了呗。但如果你没有那么大的房子可以存放下你任性购买的图书，亦或是搬家时对着成箱的书籍一筹莫展（正所谓买书一时爽，搬家火葬场），那我建议你读一下这篇文章。希望它能帮你买到值得买的书籍。选书买书的第一件事情是要知道买哪本书。这方面一般有三个渠道：他人推荐、网络推送、自己发现。他人推荐是非常重要的知道一本书的渠道，尤其是靠谱的人的推荐。师长、朋友、同事，在和他们的交流过程中都可能会得知一些书籍的线索。比如前些天我和几

软件测试人员该何去何从？“好多QA转PM，因为QA（的地位）始终是要低一些”“我现在做的事情跟几年前没有区别”“资深QA在项目上做的事情新来的毕业生也能做”上面的话你是不是也有同感？我相信大部分人会这么认为，因为这些表面上看起来的确是这样的！那么，软件测试人员或者说QA真的有这么惨淡吗？对于开篇引用的几句话，我们一一来分析一下。测试工作的价值不容置疑“好多QA转PM，因为QA（的地位）始终是要低一些”说这话是没有看到QA所做工作带来的价值。相反的，我认为QA之所以可以转PM是QA工作过程中

我有个闺蜜的朋友，时任某公司高管，每天的日程从早上到下班满满当当，晚上回家继续工作，闲聊的时候她经常调侃，你知道吗？每次我老公说今天又要加班? 其实那时候我当天的工作才刚刚开始。我就问她为什么？她说，你不知道啊，日程上全是会。开完了这个喝口水下一个又接上了。微信还叮叮当当好多人找，刚有点空想思考一下计划或方案，就总会蹦出一些事打断你。所以我就养成了夜猫子的习惯，基本上方案都是晚上回家半夜里熬出来的。我继续问她，白天一点时间都没有吗? 那如果你有30分钟，你会做什么？她说，其实也不是一点时间没有，因为有.

学习和分享都是存在于ThoughtWorks基因里的东西，这几年ThoughtWorks陆陆续续推出了多个版本的《读书雷达》，有的专注产品创新，有的专注软件开发，还有关注社会公益领域的内容。通过这样的方式给这些领域分享我们的学习方法和总结，也为对这些领域感兴趣的人提供一些从快速入门到进阶的指导。ThoughtWorks数据智能事业部自三年前成立以来，就致力于将ThoughtWorks在敏捷软件开发、精益数字化产品创新等工作方法与数据智能领域的成熟实践结合，为客户解决新形势下如何实现数据驱动的智能企业的问.