敏捷开发

生而“混合”的青云QingCloud一直扮演着混合云市场的探索者和引领者角色。 出品 | 常言道 作者 | 丁常彦 十多年前，云计算在诞生之初，就让业界耳目一新：计算资源将像水、电、煤气一样，随取随用且按需付费。因此在云计算发展早期，公有云被认为是绝对的主角，目前主流的云计算企业几乎都是从公有云起家，青云QingCloud也不例外。 但企业上云过程中，需求也是五花八门，单纯的公有云并不能完全解决企业的所有需求。很多时候，企业都会根据自身业务特点和需要，在上云过程中采用私有云与公有云混合应用的模式。慢慢的，混合云逐渐成为企业上云的主流选择。 2012年，青云QingCloud在创立之初就已经洞察到这一趋势，并在2013年正式上线了公有云平台，紧接着在2014年也进入企业私有云市场，在统一的云计算战略框架下，青云QingCloud的公有云与私有云完全基于同一套架构代码设计。 不论在业务布局的时间点上，还是在最初的设计理念上，青云QingCloud都先人一步，称得上是生而“混合”。 在那个混合云刚刚兴起的时代，生而“混合”的青云QingCloud始终坚持公有云业务与私有云业务齐头并进，不断完善混合云产品与服务。 正是凭借坚定的战略定力，以及一以贯之的产品、技术策略，青云QingCloud一直扮演着混合云市场的探索者和引领者角色。 01 生而“混合” 早在2014年，Gartner就提出了

增长是一款产品或者一家公司从出生到死亡一直在经历的过程，产品从0-1的过程是业务增长、用户增长的关键时期，这决定了它最终能不能活下来；产品从1-N的过程是持续业务、用户、商业持续增长的时期，这决定了它能不能活的更好，是在互联网世界中默默无闻还是成长为独角兽。 这里介绍一个在产品工作中常见的驱动数据指标增长的方法论：当老板给你一个增长指标时，掌握如何分析指标背后的增长因子、以及如何针对这些因素采取策略并通过数据不断验证优化的增长闭环。 增长实践的方法： 明确增长指标，分析目标本质 基于本质拆解增长因子 评估增长策略的优先级 策略落地及数据验证 数据、策略、数据迭代闭环 相信很多产品同学都经历过这样的一个阶段，老板指派给你一个任务，某某指标在这个季度结束前提升至X%，并且会在最后加一句这个指标的完成情况就是你这个季度的KPI或OKR。作为被动接受的你，可能第一反应是抗拒的，但是当你应用上述的增长方法去对指标进行分析并实践，相信增长这件事对你来说不会很难。 01 明确增长指标，分析目标本质 拿到一个增长目标后，首先去分析，为什么要增长这个指标，对于一个产品或者对于一个公司来说，增长的目标无外乎两个方向：为了用户、为了公司。这里的用户指用户价值及用户体验，通过驱动指标增长，提升用户体验及用户价值，带动整体的用户增长；为了公司则是为了商业价值的提升，没有一家公司是为了公益而做产品的

雪莉叹了一口气，调整了一下被汗水濡湿的刘海，然后向后靠在办公椅中，伸手在电脑键盘上输入了一些内容，最后拿起印刷着房地产广告的扇子，边扇风边等待着。 她的工位在办公室的东侧角落，侧靠着窗。此时虽已然是初秋，但是夏日的余威还是不减。尽管办公室里冷气开得很足，但大楼外烈阳炙烤所带来的能量，还是越过了玻璃窗泄漏进来。靠窗的雪莉热得满身是汗，恨不得赶紧找地方冲个凉。 过了十来分钟，电脑上显示的画面没有任何变化，“加载中”的动画依然在屏幕中心跳动着。雪莉盯着屏幕紧皱眉头，牙齿咬着下嘴唇发出生气的哼哼声，同时将Enter键敲得啪啪作响。她现在这个样子，也能够理解，毕竟有研究表明，相比舒适的气温环境，当人处在炎热的环境下时，情绪会比较容易躁动不安，忍耐力和耐心都会受到负面影响。 一旁的同事小新注意到了她。怎么了雪莉？不舒服吗？小新表达了关切。啊？哦，没事，没有不舒服。雪莉抬头看向小新，即使已经做了安慰性的回答，但小新依然满脸担忧。她叹了一口气，继续说，那什么，十几分钟前我MIS系统账号莫名其妙下线，任何就一直无法登陆，挺烦人的。说完了自己烦躁的真正原因，雪莉意识到小新脸上浮现出一丝惊讶。 原来你也遇到这个问题！还以为只有我是这样！小新表现得激动，以至于讲话声音很大。雪莉做禁声手势提示小新，他也意识到自己失态，于是咳嗽一声来缓解尴尬。在恢复正常情绪之后，小新说，我也是这样，MIS莫名其妙就下了线

敏捷转型有很多坑，今天你跳了没有？ 1、敏捷和瀑布式只能二选一？× 1、敏捷开发和瀑布式开发是有结合的可能的，举一个例子，当有一个新的项目创意时，我们可以采用敏捷的方式快速试错，快速获得市场反馈，产出符合客户和市场需求的产品，但是如果后续的市场和需求比较稳定，我们完全可以回归的瀑布式开发的模式。 2、另一方面如果一个组织原有的模式是瀑布式开发，现在要转型为敏捷模式，那一定会有一个过渡期，这个转变的过程绝不是“一刀切”，会有很长一段时间采用混合模式！ 2、项目敏捷就够了（有项目就申请资源，结束了就回到资源池）；× 这是非常欠妥的做法，这种模式是希望做到项目敏捷，而不是组织敏捷，理想的认为项目采用敏捷管理方式即可，项目结束了就回到职能团队，所以每当有新的项目都要有一个磨合期，要重新确定项目角色，而职能组织并不能有效的给予支持，这样的结果是组织永远停留在原有的模式，项目敏捷也最终会变为伪敏捷。 3、TDD和ATDD是测试团队的实践；× 不管TDD还是ATDD都是团队整体的实践，TDD让测试与开发界限模糊，ATDD让需求与测试界限模糊；所以归根结底都是各个角色间合作的实践，而不是测试自己的变革； 4、价值驱动；× 价值驱动其实是没有错的，这正是敏捷提倡的交付原则，但是只有价值驱动吗，如果一切的情况只考虑价值，那就会带来很多问题，价值高的风险低，价值低的风险高，这样的情况一定是先做价值高的吗

当「小步快跑」的敏捷开发已成为国内互联网项目主流模式时，海外研发管理工具老牌军Jira集公有云版慢、私有部署贵、产品生态杂、长期维护成本高等弊端，无法良好满足本土需求，中国研发团队，亟需适应国内研发管理土壤的好产品。 深耕协同场景，聚焦 “ 效能 ” 7年的Worktile今日重磅上线企业级敏捷研发效能管理工具——PingCode，旨在帮助本土研发团队解决复杂的管理问题，降本增 效。 CEO王涛说： “ 数字化中国的未来，将诞生越来越多的软件公司和数字科技，PingCode将成为所有软件诞生过程的起点和基础设施，让每个伟大的团队生产伟大的产品，我们的职责是支撑这个开发的全过程，从Dev到Ops，让研发管理智能化、简单化、自动化。 ” PingCode，为效能而生 新平台PingCode的诞生，其背后是「十年蛰伏，一日破茧」的蓄力。 回顾过往，中国的协同SaaS领域群雄并起，彼时Worktile作为一款通用团队协作工具应用于泛行业场景，凭借产品力突出重围，成为赛道领头羊。 随着各行各业的数字化智能化演进，创始人王涛和李会军发现，在服务的几十万团队之中，有50%的协作企业覆盖研发管理场景，而“提升研发效能”恰恰是两人创立Worktile的初心。 2019年初，以多年协同工具研发经验为基石，Worktile团队开始迅速调整战略路径：保持原来的团队协作的同时，向研发管理领域开疆拓土。

大家好，我是安晓辉。上节课我们介绍了目标设定与执行的方法，这一讲我们来看看如何培养精进的四个习惯。 习惯是很强大的力量，要把精进落实到日常习惯中。我个人有这4个习惯，供同学们参考： 1. 对标管理 2. 三个问题 3. 刻意练习 4. 复盘 1．对标管理 我们在第5讲介绍了个人对标管理法的运用，它应该成为我们的习惯，成为习惯后，我们就可以自发地运用它，随时找到前进方向。 2．三个问题 参考《Scrum 实战——敏捷软件项目管理与开发》一书，在 Scrum 开发模型中，有个每日站会。每日站会一般早上站着开（坐下来会让会议变长），用时10到15分钟。在每日站会上，每个人都要回答三个问题： 我昨天完成了什么。 我遇到了哪些问题。 我今天做什么。 回答完这三个问题，就可以更新看板上的任务状态，别人也都能了解到你的状态，如果有需要配合的，也都可以即时做出决定。 这三个问题，不仅可用于开发过程，还可演化成个人的工作习惯，指导我们每天的工作。 我是这么用的： 每天晚上下班时记录完成了什么、遇到了什么问题、明天准备做什么。记录在纸质的笔记本上。 每天早上正式开始工作前，审视昨天记录的内容，决定今天要做哪几件事（最好不要超过三件），今天就聚焦在这些事情上。 非常简单，但是好用。坚持这么做，你的工作就会越来越高效、轻松 来源： oschina 链接： https://my.oschina.net/u

摘要： 这篇文章主要解决因为不能很好地理解需求而估算做不好的问题，在这里可以了解下如何利用用户故事了解需求。 背景 很多团队在应用敏捷开发时，对估算经常感到困惑。这里所说的估算是指产品列表条目（PBI, Product Backlog Item）的估算 。比如，估算以什么标准进行？开发、测试的工作量都要估算进去吗？又比如，估算出了预计工时，但是实际工作中这个预计工时经常不准，为什么还要估算这个预计工时呢？还有，做估算管理时，实际工时也会经常被使用，但很多团队成员不按实际情况做实际工时的更新，它的意义何在？ 问题分析 为什么做估算呢？在规划和管理产品开发过程中，我们需要回答一些重要的问题，例如：“将要完成多少个特性？”“我们什么时候做完？”在使用敏捷时，为了能回答这些问题，我们需要估算产品的工作量大小并测算工作速率。有了这些信息，用特性集的估值除以团队速率，我们就能推算出产品开发的持续周期了。 从小目标来讲，做好了估算也可以很好的理解需求，帮助团队成员认领任务。换句话说，团队成员通过估算过程（持续沟通、确认）达成对需求的理解一致，明确完成定义是最重要的。 团队之所以做不好估算，首先是因为没有足够细化需求，更不了解敏捷估算的几个重要核心概念 ，即：“团队估算”、“估算不是承诺”、“要准确，而不是精确”和“使用相对值，而不是绝对值”。其次是不了解估算的正确方法

每次迭代结束后，团队需要召开迭代验收会议，展示本次迭代取得的进展。在验收会议中，Scrum团队成员可以采用demo的方式来演示完成的功能或者改进。 视频地址： https://www.zentao.net/scrum/Sprintreviewmeeting-80187.html 在《Scrum站立会议：猪与鸡的故事》视频中，我们介绍了站立会议中“猪”与“鸡”的角色，像研发人员等“猪”类角色是团队的核心，可以在站立会议中发言，而像市场销售等“鸡”类角色，在站立会议中是不能发言的。不过，风水轮流转，在验收会议中，终于轮到他们登场了。 验收会议是一个非正式会议，并不是进度汇报会议，无需整理幻灯片，只要提前准备下要演示的内容即可。 验收会议的意义并非单纯的演示，最主要的目的是通过演示获取反馈，从而促进产品优化改进。根据最后的完成情况，所有参会人员协同讨论，并记录下发现的Bug及问题。 验收会议中，整个团队都需要参加，并会邀请所有与产品相关人员参加。会议的结果产出，也就是演示过程中，发现、商讨并记录的所有问题，会列入到Product Backlog中，以便产品负责人后期管理。 更多精彩视频戳这里： https://www.zentao.net/page/college.html 来源： oschina 链接： https://my.oschina.net/candou/blog

在 Scrum站立会议中，可能有不同部门或岗位的人一起参加，但是要注意，只有真正参与项目的人才有发言权。 视频地址： https://www.zentao.net/scrum/daily-standup-80186.html 会议中可准备一个话筒或道具，只有拿着该道具的人才能发言，每个人说一下昨天做了什么，今天做什么，以及遇到的问题，但会议中并不去解决问题，可以会后探讨。 其他非参与项目的与会人员可以旁听，但不可喧宾夺主，每个人的角色、职责不同。 视频中跟大家分享了“猪”与“鸡”的故事， 在Scrum中，“猪”类角色包括Scrum Master 、产品所有者、开发团队等成员，而客户，市场商务人员都是Scrum中的“鸡”类角色。“ 猪”类角色才是团队的核心，拥有较大的话语权。 但实际项目中往往是“猪”类角色没有发言，而“鸡”类角色喋喋不休，最后每个决定却让“猪”去承担后果，这是Scrum要尽力避免的。 更多精彩视频请见： https://www.zentao.net/page/college.html 来源： oschina 链接： https://my.oschina.net/candou/blog/4327829

实验十 团队作业6 ：团队项目用户验收&Beta 冲刺 实验时间 2020-6-24 Deadline： 2020-6-30 10:00，以团队随笔博文提交至班级博客的时间为准。 评分标准: 按时交 – 根据实验十评分细则打分，满分138 +40分，检查项目包括： - 任务1部分（50分+40分） - 任务2部分（40分） - 任务3部分（48分） 本实验为团队任务，团队成员成绩以团队博文成绩为准 晚交 - 0分 抄袭 - 倒扣本次作业分数 评分截至日：2020-7-3 22:00 一、实验目的与要求 （1）掌握软件黑盒测试技术； （2）掌握软件项目确认测试内容，学会编制软件项目总结PPT。 二、实验环境要求 （1）实验六—实验九所编制团队项目文档； （2）实验九所开发团队项目软件包。 三、实验内容与步骤 任务1：团队作业Beta冲刺：团队项目经过Alpha阶段冲刺后，已基本完成项目编码工作。进入Beta阶段冲刺后，需要开发者对软件进行用户使用体验或典型用户应用场景测试并完善功能，此时常用黑盒测试技术完成测试工作。请根据团队项目中软件的需求分析文档、需求规格说明书和软件设计说明书，编写软件用户功能测试方案，并执行测试过程，在日期区间[6.25-6.30]内，任选连续4天进行Beta冲刺，冲刺当天晚23点前发布一篇团队Beta冲刺博客，冲刺博文内容要求如下： 各个成员今日完成的任务