2019-03-09有个疑问v1.1 v1.2 开发分支是不是从master同一个版本拉下来的吗，因为到1.2的时候，v1.1处于待测，不可能合到了master作者回复: 好问题，这个通常有两种方案：
方案一：v1.1可以不合并回master，如果有bug修复，现在v1.1上修复，然后把修复的代码同时cherry-pick到master，就是要提交两个PR，内容一样。
方案二：v1.1在部署后合并到master，这样就可以把v1.1上的修改合并到master，但是可能会有不少代码冲突
各有优缺点，具体怎么做还是看项目组的决策。 8
2019-05-06这真是极客专栏的典范，有问必答，购买专栏的目的更多是为了跟大师有交流的机会，而有些专栏仅仅只是发布了文章或视频。说回我的问题，老师在文中说到的主分支切割"测试验收通过后，预部署分支的代码会部署到生产环境。"，我的理解是部署的分支的代码，上线测试没问题之后，再把这个代码合并回主分支，不知道这样理解对不对？作者回复: 谢谢支持！
这里有两种策略：
1. 每次线上bug，修复后只合并到预部署分支，最后统一把预部署分支合并会主分支。优点是简单，缺点是合并时可能会有很多冲突；
2. 每次线上Bug，修复后同时合并预部署分支和主分支。优点是以后就不用再合并回去，还有可以及时同步bug修复，缺点是麻烦，每次要cherry pick。
我们项目中选的是后一种策略，因为能及时同步Bug修复到主干对我们很重要。 7- 2019-03-09读了老师这篇文章，给我最大的启发就是扑克估算；我之前的做法是让具体开发自己先估算，我再基于他的估算结果根据自己的认识进行微调，虽然这估算经过两个人，但这种形式还是有估算不准的情况
下周周会我就要确定新的流程；后续我会让小组内成员加上我一起针对Ticket进行估算，充分讨论后达成一致
还有一个问题问一下宝玉老师，我对于结对编程的概念不是很明晰；一个冲刺，分派给两位同学开发，他们相对来讲都很资深，分工明确，互相配合，但是分别在自己的电脑上开发……这种是否是结对编程呢作者回复: 赞，可以先实验，看看扑克估算是不是适合，如果好的话就可以进一步固定下来。
你说的那种不算结对编程。
结对编程（英语：Pair programming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。 一个人输入代码，而另一个人审查他输入的每一行代码。 输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。 两个程序员经常互换角色。 6 
2019-03-11这篇学习完后，对敏捷的实际操作有了更深的理解。
对于小公司小团队的项目，因为项目经理，产品经理都是身兼数职，是否有更好的实施方式呢？
目前认为的难处：1. 作为项目成员的程序员可能还需要去做项目经理或者产品经理的工作，2. 项目交织在一起，有新的项目在做，也有原先项目的维护工作或者新的需求。这样的情况在实施敏捷开发的时候应该如何最大化的发挥敏捷的优势？作者回复: 项目经理、产品经理兼多个项目是正常的，也没大问题。
但是让程序员同时兼做开发和项目经理工作就很不好，因为项目经理需要更多全局掌控，而一旦要花精力在开发上，很难跳出具体的开发工作，会极大影响项目管理工作；项目管理工作也会频繁打断开发，造成进度延迟。
所以我建议应该有专职的项目经理，不应该让程序员兼职项目管理。
新旧项目交织并不是问题，可以放在一个项目一个Sprint里面一起管理，也就是同一个Sprint里面有维护的Ticket，也有新需求的Ticket，只要保证开发人员同一时间只是做一件事，而不要几件事并行，就可以最大化发挥敏捷优势。 5
2019-03-11请问老师对于C++开发有什么好用的单元测试、继承测试框架推荐？作者回复: 这个问题我真帮不上你，因为我C++不懂，你得自己去网上问问别人。
帮你发了条微博问问，希望有用：https://weibo.com/1727858283/Hko9VyVbI
更新：微博上大家都推荐gtest，应该不错。 5
2019-03-09看了上下两篇文章，自己当前紧急的问题是成员的责任心和能力问题，就是怎样培养团队成员？老师有没有好办法作者回复: 这个呀，有一些建议参考：
1. 招人和开人都很重要，招优秀的，开掉没有责任心，没能力的。这两点都不容易做到，不过得坚持做；
2. 设置合理的流程，配合一定的奖惩制度；你奖励什么，团队就会往哪方面发展；
3. 团队要有梯队，不能都是资历浅的也不能都是资深的，保持一个合适的比例是比较健康的；
4. 实战中锻炼，实战中磨合；给他们有挑战的任务，给予合适的指导（这就是有梯队的原因，需要高一级别的待低一级别的）
仅供参考 5
2019-03-09老师好！关于人工测试，我想向您请教一个困惑。
我所在的团队正在尝试敏捷开发，遇到的问题是“人工测试”不知该摆在什么位置。
我们当前在Jira上设置的工作流是这样：todo→进行中→已完成→测试中→已测试。这种工作流是可行的吗？还是说把当前sprint的测试工作，都放到下个sprint会比较好？
由于我们有专职测试的同事，但是很多issue是测试同事很难进行测试的，导致工作流走不顺畅。
但如果不设置“测试中”这列，又觉得质量没有足够的保障（我们的自动化测试还很不完善）。
谢谢老师！不知您后续是否会就敏捷开发中测试的话题单独讲述。展开作者回复: 我觉得当前Sprint的测试，还是应该和当前Sprint一起走比较好，因为这个Sprint的内容是不是上线，还是要看测试是不是已经通过。另外两个Sprint或多个Sprint是可以同时存在的。
针对文章中的流程，以下工作流可以参考：
ToDo->开发中->代码审查中->合并master->部署测试环境->测试通过->已部署
设置“测试中”取决于测试人员是不是很多，任务可能有冲突，要不要知道测试人员当前正在干嘛，不需要的话其实不需要，只需要知道测试结果就好了：测试通过移动到“测试通过”栏，测试没通过，回到“To Do”栏。
有些测试只有开发能测试的，这种应该在Ticket中标明，例如在标题上加上“[开发]”标签，然后由组内其他开发人员辅助测试，或者根本不需要测试。
自动化测试要放作为日常开发任务的一部分，比如一个任务，你可以创建两条Ticket，一条是开发的ticket，一条是自动化测试代码的Ticket，分别进行打分。
后面还会有测试章节。 1 4- 2019-03-09模式差不多。但我们测试和开发同步，我们有自动测试和专门的测试人员，测试人员测试前一天开发提交的代码，开发人员优先解决测试发现的问题（会导致开发加班）。如果不同步，会影响版本发布
作者回复: 其实早期我试过在一个Sprint里面开发和测试，后来发现测试时间不充分，上线后老有小问题，所以调整为一周开发，一周测试，错开的这种方式，就特别稳定了，每周也有发布。
4 - 2019-03-09关于课后提问:
我觉得可能是第一个sprint一时间还不能写完完整的代码可以去跑测试，所以只能放到下周…如果执念于第一个sprint也要做测试，可能项目代码没能好好完成，测试出一堆bug，那么这个强求的测试可能没什么意义了，反而还要回来再改bug,违背了敏捷的理念
缺点:如果说在安排的时候过于专注在开发上，有些bug不能及时在第二个sprint安排前发现，导致sprint2的进展出现困难，也违背了敏捷的理念作者回复: 👍
是的，测试需要时间的，如果功能开发星期五才完成，那么下周一部署就没时间测试。
线上Bug的修复优先级是最高的，其次是预部署环境的Bug，高于新功能开发的优先级。 4 
2019-03-18老师有个问题没理解， brach分隔图上 sprint v1.1 在生成环境验证没问题的话，合并到master。
这个sprint v1.2需要测试，怎么做呢， v1.2不包含sprintv1.1的更新啊？作者回复: 好问题👍
v1.1的更新，同步更新到master，这样从master创建v1.2的时候，就包含了v1.1的更新。
例如用git的cherry-pick可以方便的选取v1.1的更新commit到master。 3
2019-03-12老师，你不是说当前的sprint可以放到下一个进行测试吗？为什么在回答alan的问题时又建议他放到当前的sprint里呢？作者回复: 抱歉这是我没表达清楚。
我把时间上的Sprint和看板的Sprint混在一起说了。
我们以文中的Sprint1.1为例，Sprint1.1在第一周，某个功能（例如：Ticket-123）属于Sprint 1.1。
然后到了第二周，Sprint1.2开始开发了，这时候，Sprint1.1开始测试了。发现了Ticket-123的Bug，测试提了一个Bug（例如：Ticket-234），这个Bug的Ticket属于Sprint 1.1，而不是Sprint 1.2。
像Jira这种软件，可以多个Sprint共存，也就是你看Sprint 1.1，可以看到Sprint 1.1的所有的Ticket状态；切换到Sprint 1.2，可以看到Sprint 1.1的所有的Ticket状态。
这就是为什么我建议alan把Bug放到当前的sprint里。
希望我这么补充说明能说清楚，而不是更混乱了。
如果不清楚请继续留言。 3
2019-03-09优点：新开发的功能有足够的时间测试
缺点：合并分支有点麻烦，开发和改bug同时进行，如果前一个sprint开发的代码bug比较多，可能会影响这个sprint的开发
关于分支部署那里，我们采用的办法是拉个新分支做开发，在预发测试好了再合并但master部署。
另外阅读本文的收获有两个：扑克牌估算工作量，这个确实之前是非常头疼的环节，准备尝试一下新方法；不同的会议的作用和介绍，有些可以借鉴一下用展开作者回复: 👍分析的很到位
分支不一定要合并，也可以考虑一个Commit放到两个Branch，git用cherry-pick可以支持
新分支开发也是个不错的办法，有一个小问题就是如果线上版本要打补丁，而这时候开发版本和master合并了，就稍微麻烦一点。 3
2019-07-18现在基本都前后端分离了，一个团队4个开发，一个是架构能力的资深人士，另外3个是要前后端都会，但是现在趋势都是前后端分离，这个团队的配置怎么更合理呢？
另外我看微服务架构的下都建议一个模块有3人团，如果前后端分离那就要6个人呢？作者回复: 微服务的架构下，通常一个微服务的小组要么前后端都做，要么通过架构将前后端分离：只做前端或者只做后端。
因为拆成微服务一个主要目的就是要将大开发团队分拆成小开发组，一个微服务小组通常只有3-6个开发，在做微服务的架构拆分时就要同时考虑好组织架构的设计。
参考《45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术》中提到的康威定律：
> 你设计的软件系统架构，会以某种方式反映出构建软件背后团队的组织架构。你在设计软件的系统架构时，同时也在设计你的组织架构，反之亦然。也可以简单理解为：组织架构的设计等同于系统架构的设计。 2- 2019-04-26老师，分支管理那块是项目组所有的开发人员都使用同一个开发分支还是每个人拉去一个分支开发呢？如果所有人用同一个分支PR怎么做？如果每个人拉一个开发分支会出现频繁删除拉取分支的情况？
作者回复: 是每一个功能创建一个新的分支，分支会频繁的创建和删除。
但这对git来说不是任何问题的，每个人主要是拉取master和自己关心的分支，所以还好。 2 
2019-03-27一周开发，一周测试，测试的时候，开发人员开始下个迭代，那bug啥时候修改呢？如果下一个迭代期间也要修改bug，那本次迭代工作也进度也难以保证样，不是很理解如何操作作者回复: 是这样的，开发当前Sprint新功能的时候，同时要修改上个Sprint的bug。比如说这周是Sprint 1.2，那么同时要修改Sprint1.1的Bug。而且Sprint 1.1的Bug的优先级要高于Sprint 1.2新功能的开发。
其实改Bug通常不需要花太多时间，所以一般影响不大。
如果偶尔Bug修改时间过长，不能如期完成的，需要推迟上线。
如果团队不适应这种节奏，那么应该延长Sprint周期，例如两周一个Sprint。
文章的例子只是一个参考，并不是说一定要这样做。 2
2019-03-21关于Ticket工期估算那里有个疑问。团队中一般都是一两个人负责一个小模块，之所以这样做是为了提高工作效率，避免同一段代码每次迭代都由不同的人去修改，因为大家对自己的小模块很熟悉，所以工作效率很高。但这样带来的问题是，团队成员对其他人负责的模块不熟，所以工期估算只能由模块负责人自己完成，别人很难帮上忙。这种情况怎么解决啊作者回复: 这是个好问题。
我的建议是模块要换着做，宁可慢一点，不然的话不仅仅是其他人不能帮忙不能估算，万一有人离开团队了，麻烦更多的。
如果团队不大，甚至于做的时候，分工都不要太细，都不要太局限前端后端，这样其实对整个团队来讲是最好的，互相能替换。
当然，也不要着急，慢慢来，不要一下子改变很大。 2
2019-03-18扑克估算很赞！另外还有一个问题，目前我们的开发方式是，每个成员基于要开发的feature，从master上创建一个分支进行开发，当开发测试完成后，再merge到master上部署上线。想请问老师，和文中提到的分支开发方式相比，各自的优缺点是什么？作者回复: 不知道你们有没有测试环境，merge到master后是不是会部署到测试环境，还是直接部署到生产环境？
如果有从master部署到测试环境测试的阶段，其实差不多的。
如果没有测试环境，我想主要差别在于没有专门测试人员的测试，或者说除了负责开发的人以外，其他人不方便去这个分支测试。
因为通常测试环境也只有一个，不方便每个分支都部署到上面测试，所以测试环境通常是部署master上的代码或者专门测试分支的代码。
文章中这种有专门测试分支的方式，优点就是可以通过测试分支，在测试分支上不增加新功能只修复bug，这样可以保证分支的质量趋向稳定；缺点就是比较繁琐。 2
2019-03-13请问老师，对于需求更新极快，基本上每周都需要迭代更新上线的项目，在架构设计和项目部署上会不会有什么特殊的要求？作者回复: 架构设计上，一定要定期需要重构，优化设计，不然后续新需求效率会降低，包括代码上也会越来越臃肿。比如我现在所在项目组，每1-2年会有一次大的架构升级调整，日常每隔几周会有小的架构优化，这样基本上可以保证快速迭代不会受太大影响。
部署的话，一个是要自动化，可以快速方便的部署，另外一个部署后，需要有配套的数据监控和高于阈值报警的机制，因为上线后可能会有严重问题，需要及时发现，及时处理。 2
2019-03-12看了老师的讲解，这才恍然大悟，原来我们部门有的项目组使用的正是敏捷开发方法。另外，老师有适合c代码的自动化测试工具推荐吗？作者回复: 是的，软件工程的知识并不神秘，把很多项目的经验和知识点一结合，你会发现对于你来说那些知识一直在，只是没有理论化。
前天有人问c++的，大家都推荐gtest，不知道是不是适合C语言，建议还是问问专业人士。 2
2019-03-11如果用敏捷开发，开发人员变动频繁的话，用敏捷开发项目的相关文档那么少，有的开发就简单写一下，万一负责该项目的开发都走了，后期要对该代码进行改动怎么搞？要从头到尾的读一遍源码吗？😂
要怎样做才防止上面的事发生？作者回复: 文档这个事呀，和是不是敏捷开发真没多大关系，敏捷开发从来没说文档不重要，只是说“工作的软件 高于 详尽的文档”。就算是敏捷开发的团队，必要的文档也是要写的。
瀑布模型的时候我也没看大家多爱写文档，文档质量也差得很，很多人无非就是找个借口不写文档罢了。
你知道对于代码来说最好的文档是什么吗？——良好的代码规范和单元测试！
要是真能按照敏捷开发的要求，保证一定量的单元测试代码覆盖率，从命名和测试代码很容易就可以看出来一个方法的输入和输出，边界条件等。 2