Being Agile 单元测试认知篇

自动化测试是必然选择，而单元测试必然中的必然。因为单元测试是一切测试的基础，长远看，研发投入成本最低，反馈最快。今天我们继续聊Being Agile 单元测试。

单元测试与重构

今天跟大家来聊一聊敏捷相关的话题，单元测试与重构，一些想法和见解，以及相关的书推荐给大家！

Being Agile! 人均年利润千万的公司の开发规则，你要不要知道？

今天被下面这位长发飘飘的Programmer圈粉了！ John Romero，顶级游戏公司Id Software的创始人，在2017全球开发者大会上John分享了他们的Programming Principles，仔细咂摸，满满的敏捷思维，为了乃们的钱途，我果断节选了以下几个，与大家分享。

Being Agile！一个“积极的悲观主义”者

有一个敏捷教练，他这样评价自己：我是个积极的悲观主义者：积极而审慎的做事，不因失败而懊恼，不因成功而浮躁。此句话献给在敏捷中的伙伴们！无论你们是从0到1，还是从1到100，只要还认可你的目标，就做起来吧，持续的做，思辨的做！

Being Agile！敏捷团队行云玩法大公开

听项目管理的大大说，行云看板要在团队内普及起来。敏捷主力军的勇敢者俱乐部的团队成员也在使用行云，让我们一起来看看，他们都有哪些玩法吧！

Being Agile！快坦白支援的时候都想了啥？

一线支援不同于用户调研，但似乎更胜于用研，这是一场“沉浸式的体验”！区别与其他事业部的小伙伴，作为物流技术发展部的你，有没有一边挥汗如雨，一边满脑子奇思妙想呢？

Being Agile! 当评PRD的时候我们聊什么？

“需求评审时，做一个没得感情的杀手”；需求评审是一个几方对齐的过程；大家要扩大共识，把“你知道，我不知道；你不知道，我也不知道“的信息孤岛消除到最小。所以，我们在评审的时候应统一站位，即客户视角；并基于调研、基于逻辑、基于数据；而不是，“领导说”、“业务说”……。文中还提到了对边界问题的思考，也是同理，要跳出“XX决定脑袋“迷局，以技术和客户的视角去站位、思考。

敏捷开发下的Git工作流应用实践

在计算机技术发展到今天的同时，协同开发工具也不断进步着，向我们熟知的SVN和Git，本身就是成熟的协同开发框架。尤其是GitFlow工作流模式，更是一度被许多公司奉为协同开发的典范并纳入开发规范中。那么，今天就说一下敏捷开发过程中，我们应该使用怎样的工作流模式才能更高效的完成开发工作呢？

Being Agile！契约测试看图说话

Provider发生了变更，而Consumer却很难主动了解到；这个窘境（锅）有没有技术的方法来打破呢？即：有没有办法能让接口发生变化的时候消费方和生产方都能及时发现呢？

Agile Alliance 玩转大项目-大项目如何做好敏捷拆分

传统意义上的大项目与敏捷开发似乎成了两个对立的概念，一个大而全，一个小而美，事实上后者可以是前者顺利推进的一种方法论和有力保障工具。而做好大项目的敏捷拆分是敏捷开发实施的关键。今天我们结合源动TC团队的一个较为典型的案例，来和大家分享一下如何做好大项目的敏捷拆分。