敏捷开发

摘要： 团队用于估算时间过多，留给开发的时间会相应减少，大家工作紧张，状态不佳。团队过度承诺直接造成迭代目标不能完成，士气低落。以上弊端直接伤害敏捷团队，是敏捷团队保持稳定健康节奏的阻力。 背景 敏捷江湖桃花岛社区下线会议时，敏捷实践者问了很多关于估算的问题。作者在这里把具有共性的问题简单做了梳理。问题主要集中在团队只关心估算结果，也就是数字。再则团队经常在外界压力下过度承诺迭代目标。这两个比较集中的问题描述如下： 问题一： 团队只关心数字。计划会议大家只关心估算的数字，经常花费大量时间做估算，怎么办？ 问题二： 团队过度承诺。有时候，团队被迫承诺过多的工作，迭代目标完不成，怎么办？ 团队用于估算时间过多，留给开发的时间会相应减少，大家工作紧张，状态不佳。团队过度承诺直接造成迭代目标不能完成，士气低落。以上弊端直接伤害敏捷团队，是敏捷团队保持稳定健康节奏的阻力。 问题分析 以上两个问题也是敏捷初始团队经常遇见的问题，现简单分析发生原因如下： 问题一：团队只关心数字。 团队从瀑布开发方式转为敏捷开发后，学习了敏捷Scrum框架，然后开始使用敏捷开发。他们知道其中有一个事件是迭代计划会议。在会上团队成员经常耗费大量时间做估算。常见对话：“这个估算数字合理吗，我们要不要再好好想想清楚？”因此团队常常陷入无休止的讨论中。团队狭隘的理解为，计划会议中最重要的事情就是估算

　　企业数字化转型作为一个系统工程，需要着眼未来、集思广益；选好试点、敏捷开发；不断迭代，生态协同，在不断的探索和实践中，推进和实现数字化转型。而今天我们就一起来了解一下，企业数字化转型发展需要关注那些问题。 　　企业数字化转型发展需要关注那些问题 　　1.收集可以解释关键点的事实和数据 　　没有人希望看到企业领导者经常改变发展方向。如果要改变策略，从一开始就解释需要改变策略的原因，并使用数据和事实来证明策略改变的合理性。 　　2.定义没有在做什么或正在减慢速度 　　太多的支点是累加的，并且期望相同的团队承担更多的责任。真正的重点需要确定优先级，并向员工解释新功能，以及为实现新优先级而停止的事情。 　　3.重新定义未来愿景 　　每个数字化转型计划都应包括未来发展愿景。很多人都知道其未来前景并不明确，因此，如果要宣布一个关键点，好是发布新版本的愿景声明，并阐明其主要差异。 　　4.定义需要测试的假设 　　如果企业拥有所有答案，则说明其过分自信或将计划提交团队的时间太晚了。企业领导者在需要持续验证的假设的基础上定义数据化转型。测试假设更是必不可少的，没有人相信领导者的销售新方向，而又不知道在市场、客户群、供应商、技术、分析或内部运营方面需要进一步发现的内容。 　　5.审查现有预算、合规性因素和其他限制条件 　　如果企业要求团队生产小型摩托车，将会无法支配并期望以相同的预算开发摩托车

作为Java程序员来说，最痛苦的事情莫过于可以选择的范围太广，可以读的书太多，往往容易无所适从。下面就按照学习顺序，给大家推荐下面这些JAVA书籍。 一、Java编程入门类,选择大于努力，入门太重要。 对于没有Java编程经验的程序员要入门，随便读什么入门书籍都一样，这个阶段需要你快速的掌握Java基础语法和基本用法，宗旨就是“囫囵吞枣不求甚解”，先对 Java熟悉起来再说。用很短的时间快速过一遍Java语法，连懵带猜多写写代码，要“知其然”。 1.《JAVA编程思想》在有了一定的Java编程经验之后，你需要“知其所以然”了。这个时候《Java编程思想》是一本让你知其所以然的好书，它 对于基本的面向对象知识有比较清楚的交待，对Java基本语法，基本类库有比较清楚的讲解，可以帮你打一个良好的Java编程基础。这本书的缺点是实在太 厚，也比较罗嗦，不适合现代人快节奏学习，因此看这本书要懂得取舍，不是每章每节都值得一看的，挑重点的深入看就可以了。推荐一个java群，名字是java从入门到精通，第一组是二二零,第二组是一四二，第三组是九零六，里面有大量视频资料，欢迎java爱好者加入学习。 2.《Agile Java》中文版，这本书一大特点是以单元测试和TDD来贯穿全书的，在教你Java各种重要的基础知识的 过程中，潜移默化的影响你的编程思维走向敏捷，走向TDD。另外这本书成书很新

转载自 诺普博客 4.11 日周六，我参与了由 [Bob 老师]组织讲授的一期 Certified Scrum Master（即 CSM）课程，从中收获颇丰，特记于此，与君分享。 CSM 通常是现场授课，但本次由于疫情的限制导致人们不得不尽可能减少外出。而 Bob 老师也适时地将原本现场的授课改为了远程的方式。吸引我参与这次课程的，正是这种远程授课的安排。因为正是受制于目前的困难情况，我所在的红帽开放创新实验室的不少活动也难以高效开展。所以参与本次课程的目的，除了学习 Scrum 之外，我还想了解一些远程引导的技巧并观察与我一同参与课程的其他同学的情况。 本以为可能不少人会出于对远程授课效果的担忧而不倾向于参与远程课程，但临到开课前组织的微信群的参与者竟达 30 多人，着实令人意外。在开课之前，Bob 老师还在微信群里发来了第二天上课用的 Zoom 会议链接，并提醒大家提前装好 Zoom 软件。 课程于 4.11 日早九点开始，一共两天。第一天主要讨论了敏捷和 Scrum 的基本概念，并介绍了 Spotify 大规模敏捷的实施案例，第一天结束时 Bob 老师给大家留了家庭作业；第二天以回顾各位的家庭作业开始，之后我们逐个探讨了 Scrum 的各种角色和事件等关键内容。作为练习，大家还以分组、迭代的形式制作了一个 Scrum 视频，成为了课程的意外收获。课程结尾时，Bob

这个作业属于哪个课程 2020春北航计算机学院软件工程(罗杰 任健) 这个作业的要求在哪里 提问回顾与个人总结 我在这个课程的目标是 增强软件开发能力，增强沟通表达能力 这个作业在哪个具体方面帮助我实现目标 总结回顾本学期软工之旅 以前提问题的博客地址 个人博客作业 对自己曾经提出的问题进行解答 问题： 在结对编程模式下，一对程序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起单元测试，一起集成测试，一起写文档等。 　　诚然，在公司的开发人员中使用结对编程是一个大大提高效率的方法，但是我对在大学课堂中使用结对编程的方法持怀疑态度，因为大学中同学水平差异更大，特别是在编码能力方法，大部分　　人并没有经过特殊训练，在结对编程之后，很有可能出现水平较差同学被水平高的同学完全拖着走，或是两个水平都不好的同学浑水摸鱼。 解答： 课堂中使用结对编程不失为一种很好的工作方法，但没有必要强制结对。因为结对编程的效率往往建立在结对双方能力的匹配和一定的默契。我在结对编程项目中体验并不理想，就是因为和队友的不了解，以及在编程能力上有所差异。强制结对就会带来这样的问题，当双方从零结对，并且工作时期只有一周的时候，结对所带来的工作形式上的强制性可能成为一种累赘，导致效率的变低

Beta冲刺(4/7) 这个作业属于哪个课程 班级 这个作业要求在哪里 作业要求 这个作业的目标 记录冲刺当日的SCRUM会议和PM报告 作业正文 刚下飞机——Beta冲刺(4/7) 其他参考文献 ... SCRUM会议 会议记录表 学号 组员 昨天花了多少时间 还剩余多少时间 昨日完成的任务 遇到什么困难 今天的进度 明天的计划 221701317 卓晓鑫 6h 3d 完成敏感词功能、重构Admin部分代码 无 实现举报处理中相关接口、修复bug 实现成就、认证学校管理相关接口，重构Action和Service层代码 221701328 张春翔 5.5h 3d 前端完成编辑问题、回答功能，完成删除问题、回答、评论、回复的功能 无 前端完成查看消息界面和认证界面 前端完成查看成就功能，对需要显示认证信息的地方进行补全 221701319 郭秋中 4h 3d 完成编辑问题的获取问题内容，以及修改Bug 无 消息的生成，以及将未读消息已读 修改Bug，优化后端代码，完成剩余功能。 221701333 池政涛 3h 3d 编辑回答接口，bug修复 暂无 认证接口编写，举报信息处理接口编写，bug修复 修复bug，优化代码，编写相关接口 221701337 朱凯文 6h 3d 实现分页，单个删除，问题举报处理的批量选择，举报处理气泡提醒 无 完成批量删除。评论，回答，举报，回复处理界面

这是一个填坑博客，负责把之前 挖坑博客 里面所挖的坑填满，以及一个学习软件工程课的心得。 项目 内容 课程：北航2020春软件工程 博客园班级博客 作业：提问回顾与个人总结 提问回顾与个人总结 提问博客 软工个人博客作业1 疑问解答 问题一：测试 在之前的面向对象设计的课程中，我初步地尝试了使用JUnit对自己的单元进行测试。但是对于测试的对象、粒度和测试的样例数据，我还是不能很好的把握。测试的粒度可以从小到大，从函数、方法到类再到模块，循序渐进。但是测试的样例数据方面，是否存在比较合理而且固定的方法，能够固定地按照一个流程去分析自己的应用，做到不重不漏，覆盖到所有的分支和情况？还是说单纯依靠代码的编写者去“我 觉得 ，这个地方 可能 存在问题”这样的直觉和经验呢？ 覆盖所有分支肯定是不太可能的，每个模块的输入和输出变化非常大，这也是为什么说“测试需要写代码的人做”的原因。但是其中我们当然可以使用一些工具比如分支覆盖率工具，在给定输入的情况下检查代码的覆盖率。在结对编程和团队工作的过程中，我的测试方法主要分为两种： 人工制造数据，分别检测“一般情况”和“边界情况”，并同时利用分支覆盖率工具来检查代码的正确性 通过随机生成函数，批量制造随机输入数据和对应的期望输出，然后挂机让电脑自己测试 问题二：结对分配 过程中，我想知道结对编程过程中，是否会发生两者的贡献不匹配的情况。作为领航员

各位小伙伴们久等了，撸主花了无数个深夜吐血训练了100万小黄图做了一个鉴黄图床，终于在今天开放给大家了。2019年11月22日图床上线了，网友们也都很积极，甚是踊跃的上传了不少有趣的图片，当然由于一些特殊原因被过滤掉了，没能展示给各位网友。 也有不少小伙伴在后台问，图床什么时候开源呀？鉴黄是怎么做的啊？小黄图素材是从哪里找的啊？这个…恕无可奉告。后面也写了一系列文章来阐述相关功能，然而当时只是个半成品，一时半会放出来也不大合适，就拖到了现在。 此后的重点已经不是图床那么简单的功能了，后面撸主陆陆续续整合了不少功能模块，以方便大家能更加快速高效的开发。 前一阵子撸主上线了爪哇妹，一个集万千宠爱于一身的小程序。不过以后，爪哇妹可能要下线了，为了方便大家秒速预览，撸主接入了阿里云存储，奈何流量真的有点耗不起。爪哇妹里这么多妹子都是通过小程序后台管理模块添加的。 当然了，扩展不仅仅如此，目前项目分为组织机构、系统监控、应用管理、系统管理。 组织机构分为：机构管理、用户管理、角色管理、行政区域，一个比较通用的组件，各位小伙伴们可以通过它改造成一个后台管理系统。 系统监控目前只上线了系统日志和在线用户，后期会慢慢追加完善。 应用管理上线了任务调度、邮件管理、图片管理、文章管理，每个模块只需要你稍作修改就可以打造成一个项目了。 系统管理上线了敏捷开发、系统菜单、全局配置

我常说我可能发明了故事点，如果真是这样，现在我会感到很抱歉。让我们一起来探索我现在对故事点的思考。至少有一个人对我所想的很感兴趣。 -- Ron Jeffries 当然，故事是极限编程的思想，不是Scrum的。不知何故，Scrum践行者接受了这个理念。尽管在Scrum官方指南中有关待办事项的内容，将待办事项作为用户故事是一种普遍的Scrum实践。 至少在某种程度上来说，他们是对的。我已经在其他地方写了关于故事的常规用法，正如它应该被写下来一样。在这里，我们将讨论的是"故事点"。 在极限编程中，故事最初是用来估算时间的：实现故事需要花费的时间。紧接着我们来谈谈"理想天数"，它是用来非正式地描述如果别人让你尽自己最大努力单独完成故事需花费的时长。我们用理想的天数乘于一个"负载因子"转换得到实际需要的时间。负载因子通常是3（3天才能完成一个理想天数的工作量）。 我们刚谈到用天数来估算，经常是把"理想"抛开。这将导致的结果是我们的老板很疑惑，怎么是要花费3天来完成本来1天就可以完成的任务，又或者说，为什么我们不能用3周来完成50"天"的工作。 我记得，我们开始称"理想天数"只是"点"。所以一个故事应该用3个点来估算，这就意味着这个故事需要花费大概9天来我完成。总之，我们确实也是只用点来决定多少工作进入一个迭代，所以如果我们说大概20个点，没人会反对。 我可能已提出改名字的建议

通过理解这些永恒的见解，你将成为更好的开发人员。 成为一名优秀的程序员，就是让你自己接受不断学习的生活（活到老，学到老）。包括新功能、新语言、新工具、新框架等优秀的源头——学习永不停息。但是，其实计算机科学也是一个令人惊讶的传统领域，这是基于久经考验的原则得出来的。我们已经添加了面向对象、现代硬件以及人工智能。然而，尽管发生了这么多的变化，许多上一代人提出来的见解在今天仍然适用（这点和我们现在的名言警句类似）。 在这篇文章中，我剖析了一些我最喜欢的关于计算机科学的引用。我设置的唯一条件就是，每个优秀的引用必须至少有20年的历史。因为古老的技术很快就会变得毫无用处，而我们编程祖先的古老戒律却有更强的持久力。 1. 关于Indirection "计算机科学中的所有问题都可以通过另一种间接的方式来解决"。——David Wheeler 这里有一个很少被开发者愿意解释却又经常被复用的compsci的引用。但这是我最喜欢的编程真理之一，因为它触及了编码的核心。 开始考虑Indirection的最简单的方法是想像层次。例如，假设您有一个小项目，需要将组件A放入组件B： 两个都是标准的组件，因此你不能破坏他们并更改他们的工作方式。你可以构建一个全新的组件，但这需要大量的工作和不必要的重复。一个更好的方式就是这两个部分之间添加一层——一个适合于两个组件并在它们之间进行转化的适配器。