《敏捷无敌》章节试读

《敏捷无敌》的笔记-第3页 - 第一次立会

项目经理又不出意料的“嘟嘟”的跑过来，当时很想录下来：每个人在说话时都是脑袋在scrum master和项目经理之间摆动。
前面user story划分带来的第一个问题来了：每个人都不关心别人做的事情，所以轮不到我时，我寻思一下外边风大不大，适不适合出去打羽毛球。
时间控制的很好。
这个团队非工作气氛很好，工作气氛没有，都由项目经理和开发经理控制完成。

《敏捷无敌》的笔记-第七章 镜子反射 - 第七章 镜子反射

演示会
演示会不止局限于产品本身，不然一个sprint可能不见得能在界面上见到什么可见的东西。
任何对团队有贡献的都可以演示。如一个新建的wiki网页、某人新写的小工具、一份说明文档或其他任何具体的可以让该团队感觉到有价值的东西！
还有像性能测试对比结果这样的直接呈现出来就可以。

《敏捷无敌》的笔记-第87页

阿捷跟product owner的介绍和沟通中聊了sprint会议的内容：
第一部分：讨论backlog中各条目的目标和背景，并且回答开发团队的问题，以深入了解需求和做需求人的想法。
第二部分：开发团队从product backlog中按优先级挑选条目，并给出完成任务的承诺。
第一部分主要是问答，backlog作者和使用者的问答。
第二部分主要是讨论。带啊一起详细讨论如何做，做到什么程度，如何演示，即给出“done”的标准。在sprint演示会上成员做演示的时候，就可以根据done的标准来评定是否真正完成了任务，而且在细化任务的时候，肯定会有一些问题需要跟product owner澄清。
“如果在一个sprint期间想要做需求的改动的话，只能等到下一个新的sprint才行。”————这个为什么呢？

《敏捷无敌》的笔记-第9章 - 第9章

做事情可能都是这个道理，特别是集体的：
先做到再写到，先短期利益再长期利益，先实施再完备。
我们的code review，太过程式化，过于庞大，要到plm上建立一个流程，走审批，然后notes通知，然后去页面提交，过于繁琐的结果就是敷衍，每个人自己把流程简化了。
觉得可以在两方面提高：一方面，严格要求，每个cpp文件，必须有一个函数或者一个类提交review，一个比较大规模的模块，必须要提交review，记录每个人的代码review量（比例或者数量皆可）。而不是现在这样只有很少的代码提交凑数。代码注释里至少加上两个人名：作者和review人
另一方面，不必局限于提交公司的流程，面提，网聊，等等皆可。

《敏捷无敌》的笔记-第94页

scrum的目的是什么呢？或者说目标？
是这个产品团队成为一个自组织的团队，这个团队能够自我修复，能够自我提高，自我引导，自我管理，能够自己主动把问题搞定。这个目标是管理目标，可能是所有组织的领导所追求但是永远做不到的。著名的理想演说家魏老师以前经常表达他的这个理想，但是从来没有通过有效的管理实践加以实施过。
领导一般会想：你怎么没有关注这么一样影响项目里程碑的大故障呢？你写代码的时候怎么没有想想你这样写会影响其他模块呢？你怎么不关注项目或者部门的考核呢？——太奇怪了，你们这些人！！
可事实上，这只是人之常情，让团队成员做这些事情的时候，你想没想过，why？
这一章讲daily scrum，每日立会。
最先触动我的是立会的时间。
一是要短，不要成为负担。
二是时间固定，并且每日scrum要避免成为每天的开始。如果这么做的话，那立会之前，大家都会认为今天的schedule还没有开始，就不会做任何事情了。——这个太现实了，我肯定会这样。
书里边列举了这样几个指导原则：
1、主题明确，不能掺杂无关话题。主题就是：昨天完成了什么？今天打算做什么？有什么障碍？给出最新的工作量估算。这个与项目进度汇报会的区别就是：这里强调的是团队的自组织，自我发现困难，自我提高，这是交流，另一个是汇报。
2、立会只能
╭︿︿︿╮
{/ o o /}
( (oo) )
︶ ︶︶说话，鸡不能讲话。这个的好处是什么呢？？？
3、站立，不要坐下。提高紧迫感，防止走神。
4、每个人都要参加。
5、会议时间在15min以内。
6、不要让立会成为每个人一天工作的开始。
7、立会要每天同一时间同一地点举行。
对于scrum master，他要及时解决daily scrum上提出的障碍。
burn down chart需要让每个成员在任何时间点都能看到。而不是每周。

《敏捷无敌》的笔记-第278页

完结了。今天利用编译的时间看完了。推荐给周围刚开始实践的人看。优点有几个：
1、故事性强，理论说教少，能读进去；
2、内容比较综合，敏捷方方面面的知识都有所涉及，对于入门者能提供一个比较宽阔的视野。

《敏捷无敌》的笔记-第5页 - 敏捷日记-回顾会

今天是周五。咨询公司的人要到项目组进行情况调研，解决实际中遇到的困难。
团队的转变需要一个强力而又心细的人投入，并能够与大家沟通交流，这是一个怎样的人呢？

《敏捷无敌》的笔记-第2页 - 敏捷日记2-第一次“user story”领取

到目前为止我的最大疑问是：公司为啥不给项目经理进行培训呢？敏捷从结果上来说确实是“压榨”了员工，但是项目经理以上层面的所谓领导，要付出的更多。这也就是为什么现在上海部门的经理没有写代码的时间。
言归正传：今天的主题是《项目敏捷的第一个实践成果：基于详细设计或猜谜语的工作量估计》。
项目经理和开发经理分别作为se，分解了两部分backlog，以下简称b1和b2。其中一个开发经理已经把框架搭好，定好接口就可以直接写代码了，b2是项目经理分解的，他没有接触过项目代码架构。如前面所述，两个人都是按照架构模块还划分的，只是项目经理完全没有经过培训，不知道从哪里找来了一个野鸡例子，写成了“作为软件开发工程师，我想要做这个功能。。。”。这个都让人没法评论。。。。
当然，user story的划分方式，就决定了详细设计的地位。一个有了类似详细设计的东西，工作量评估时很顺利，一个大脑空白，工作量评估任务只能挂起了。
但是，这种基于详细设计或者猜谜语的方式，真的符合敏捷么？你相信么？

《敏捷无敌》的笔记-7章 镜子反射2 - 7章 镜子反射2

演示会不要成为批斗会！！
而是庆功会。
不管提不提意见，都要在轻松的气氛下进行。
印第安人灵魂的故事：从前，有个古老的传说，讲的是当印第安人在赶了3天路后，就会停下来小憩一天，因为他要等着自己的灵魂跟上来。

《敏捷无敌》的笔记-第284页

用2天的时间快速过完这本书，赞一下，推荐阅读。敏捷并非是一成不变的，而是需要在项目开发执行中，不断地总结教训、吸取经验，在不断地探索中找到正确的那条路。scrum、xp、lean、toc书中谈到了很多来自于不同书籍的内容，深为作者能够融汇而钦佩。

《敏捷无敌》的笔记-第1页 - 1-1

今天是敏捷日记第一天。
背景这样。
项目经理一人，需求工程师一人，开发组长一人，普通开发人员7人，其中专职做db一人，server4人（使用c++），client 2人（使用java）。
项目需求多为内部用户，开发人员对项目熟悉程度一般，之前分工比较明确，每个人很少关心也不懂其他人其他领域的内容，代码质量处于恶化之中。但因为项目客户多为内部客户，而且需求不算很多，所以大多数情况都能应付。
实施敏捷的动力来自于外部，公司要考核每个部门实施敏捷的程度。
上一周，项目经理和开发组长+需求工程师做了backlog到user story的划分。
今天是第一次user story的划分会，也是第一次郑重其事的全项目开始“敏捷”。
会议由项目经理主持，需求来源于两部分：项目外的一位需求工程师所做的需求，本项目专职需求工程师的需求。
第一个feature是对网络进行某个指标的评估。项目经理讲解，他的划分是：1、client；as a 界面软件开发工程师 i want a xxx 2、server；as a server软件开发工程师， i want a yyy;然后进行工作量评估，项目经理给出的工作量与开发人员给出的工作量相差甚远。
——这个的疑问有两个：对用户价值的理解和工作量评估的方法。user story的问题一是没有做到端到端，这个user story无法验证。二是没有做到体现用户价值，as部分竟然写成了开发人员，如果我是这个开发人员，我就告诉赶紧把需求给我撤掉，嘿嘿。工作量的评估，差别大的原因是对未知问题考虑不到，搞不清楚工作量到底如何，项目经理认为工作量较少的，往往开发人员会觉得自己需要更大的工作量。这个原因分析应该是ba和se前期工作太少，应该做到：自己了解系统，有较深的认识，与开发人员有比较充分的沟通。
会议气氛很不好，项目经理一如既往的习惯发指令，大家各自挑着自己关心的话题进行关注。
这个项目的敏捷就是这样浑浑噩噩的起步了。

《敏捷无敌》的笔记-第1页 - 敏捷日记1-2

还是第一天第一次故事分解会的内容：
针对上面user story分解中几乎是典型的错误划分，原因是什么呢？
大家之前分工太过于明确，每个人对别人的领域都不是很了解，按照端到端的纵切方式比较困难。
如果这样，user story如何验证呢？sprint的存在的意义就没了，敏捷失去了敏捷本身的意义。
中午跟lp说了上午会议的情况，lp大笑，你们搞的这是什么玩意啊。。。
也许结对编程，共同申领user story卡片和让ba学习user story划分方法是现在的唯一路径。
如果不呢？
后面希望能看到这样的后果到底是什么。

《敏捷无敌》的笔记-第1页

这里插一本别的书：
user stories applied in agile software development.
1.疑问：用户代表需要代表上下游客户吗？听培训的时候，他们的用户代表长期在运营商出差沟通，我疑问是，他们是否需要跟内部客户沟通，比如一般认为做单板的也是网管的客户，而且在当前是最重要的客户，他们的需求需要考虑吗？现在情况是，如果考虑，他们经常会搞错，以往改来改去的需求基本都是他们提出来的，他们其实也并不了解运行商也就是我们最终外部客户的需求，如果不考虑，那如何合作？
觉得可以划分一下，内部上下游的这些客户作为重要客户，外部客户作为更高优先级的客户，都关注，都注意沟通。

《敏捷无敌》的笔记-第4页 - 破冰时的问题

项目遇到的问题有这么几个：
1、项目leader认识不足，相关能力不达标，急需提升；
2、项目新手多，并且用java和c++两种语言开发；
3、user story划分困难，造成后续工作很多无法展开或者实施变形；
4、团队对敏捷认识不足。