scrum

如果还不知道Scrum敏捷开发的朋友们，同理，还是请出门左转，点击 Scrum 了解下。 以下是原文中提到的9个Scrum不行的理由。除此之外，作者陈皓在里面加入了自己的分析（感谢陈皓提供的精彩内容）。 Reason 1: Scrum的基石是相信人。创造一个安全的环境，这样每个人都能相互学习，相互直言。但是，这是不行的，这世上有很多人并不关心这些，而且竞争到处都是，办公室里无小事，你和别人交心，你相信他们，最终受伤的你自己。你真的以为那里有空间让你可以去犯错，去冒险吗？ Reason 2: Scrum认为只要给员工足够多的自由员工就能做得最好。这该死的理论是基于什么玩意？不可能，人的天性是懒惰的，他们才不会把事做好的，他们只会做相应报酬的工作量，还可能基本甚至达不到其相应的报酬，大多数人都在混日子。尤其是和经理比起来，谁不想能尽快地成为经理或Team leader啊，因为那样他们就可以即不干活，又挣得多。另外，你给他们自由，你就会发现，他们会只会做他们感兴趣的事，要么聊QQ，要么打游戏，看闲书，反正不干正事。直到你催了，他们才动一动。 Reason 3: 因为前面的原因，所以，我们仍然要把一个PM放在Scrum团队的上面做管理，这样才会有产出。于是，PM给团队分配任何，管得细枝末节，事无巨细，天天让你做进度汇报，等等。直至把团队拖垮。 Reason 4:Scrum只不过是一个流程

因大部分看到的 Story Point 估計方法都是用 Planning Poker。 實際導入的過程中，稍嫌用 Poker 有點麻煩，所以找了其他的估計方法。 推薦一種我個人比較喜歡的估計方式，雖然我不知道這個方法的名稱，姑且稱之為 九宮格估計法 。 前言 估點之前，PO (Product Owner) 要先產出 Product Backlog。 且 PO 要讓每個成員都了解 PBI (Product Backlog Item) 的需求。 步驟 垂直欄位 首先在白板上畫出三個垂直欄為，分別寫上 小 、 中 、 大 ，如下： 分類PBI 請團隊成員將 PBI 歸類在小型、中型或大型欄位，可以用難度、複雜度、範疇等作為比較基準。任何團隊成員都能有意見，開方式的互相討論，任意移動 PBI 位置。 切記 ！是讓團隊成員決定 PBI 放在哪裡，PO 跟 SM (Scrum Master) 這種不實際做事的角色不要亂入干預決定。但差距太離譜的部分，可能是需求認知不清，PO 可能需要主動解釋一下。 在我個人經驗裡，將 PBI 分為三類應該不會花太多時間。結果大致如下： 水平欄位 橫向切出三個水平欄位，分別寫上 小 、 中 、 大 ，如下： 再次分類PBI 請團隊成員從左邊垂直區的小型欄位開始歸類在小小、小中或小大；分完後，將焦點移到中間的垂直欄分類，最後是右邊的垂直欄分類。

背景介绍 我从大学05年开始直到现在就总共干了10年的软件开发，期间参与了各种类型的软件项目开发，包括高校和企业应用软件项目，外企的金融软件项目以及互联网软件项目，也参与过最近流行的移动端互联网项目的开发。分别在外企、创业企业、自己创业和中大型互联网公司工作过，所以实际参与的互联网项目种类繁多，工作过的公司类型也较多，因此对于软件项目开发这件事情有一些自己的思考和实践经验。 从2011年开始接触到敏捷项目管理，期间学习和实践了像Scrum和看板方法等敏捷方法，也进行了包括持续集成、代码评审等多种敏捷工程实践，也使用了谷歌公司发明的OKR工作方法。因此对于敏捷软件开发也有一些总结的经验。 因此本文就是将自己多年的软件开发和敏捷软件开发的多年学习和实践经验进行汇总，形成本文。 软件的价值 提高数据计算和存储效率 首先软件带来的价值就是提高工作效率。互联网盛行之前软件开发行业主要是为企业开发应用软件，它的价值是提升企业员工的工作效率，比如财务软件及各种管理类软件，主要是解决信息存储和检索问题，解决数据计算效率问题。 提高信息传递效率 其次软件及互联网带来的价值是提高信着互联网技术的广泛应用，软件给人们带来的价值是以更低的成本，更高的效率传递来传递信息。 还有其它的一些价值。上述两类价值是软件及互联网带来的核心价值。 那么我们软件开发的目标就是通过一系列的过程和活动让软件的价值得以体现

当前各大互联网公司都宣传自己是敏捷开发，各种技术论坛上也讨论得非常多得议题也是敏捷，好像公司不敏捷都好不意思跟人打招呼。那么我们到底为什么需要敏捷呢？传统软件开发到底存在什么样的问题呢？作者从自己的视角来给各位分析一下。 软件及互联网的价值 首先我们从软件开发的成果软件的价值说起。软件到底能够为软件的客户及用户带来什么样的价值呢？ 提高数据计算和存储效率 软件带来的价值就是提高工作效率。互联网盛行之前软件开发行业主要是为企业开发应用软件，它的价值是提升企业员工的工作效率，比如财务软件及各种管理类软件，主要是解决信息存储和检索问题，以及解决数据计算效率问题。 提高信息传递效率 随着互联网的普及和广泛应用， 软件及互联网带来的价值是以更低的成本，更高的效率传递来传递信息。人们用互联网来查找信息；用互联网来随时随地的沟通；用互联网来连接消费者和零售商，让消费者足不出户实现全球购； 还有其它的一些价值。上述两类价值是软件及互联网带来的核心价值。 那么我们软件开发的目标就是通过一系列的过程和活动让软件的价值得以体现，脱离了实现价值的软件开发就是耍流氓。 另外我要强调的是价值它绝对不能等同于软件功能，开发软件功能只是第一步，只有用户去使用软件解决了问题之后软件的价值才得以实现，软件的总价值等于所有软件用户获得价值总和。 传统软件开发的问题 由于我在不同类型的软件公司工作过

微服务与敏捷开发（Scrum/Kanban）的核心思想之我见   关于“微服务”和“敏捷开发”的文章网络上有很多，所以这里不再重复叙述这些概念的解释和特点，而是就个人实际工作中对他们的核心思想的理解及运用分享给大家，希望能对大家有所帮助。   当下IT开发领域，“微服务”及“敏捷开发”越来越被各公司及团队重视。但是在交流中发现很多人对“微服务”及“敏捷开发”存在很大的误解，尤其在各公司的招聘岗位介绍中更能看到很多描述错位的地方。   首先，微服务和敏捷开发都是指导思想，是模式和方法，并不是特指某个软件应用、开发语言、开发框架等。并不是使用了某个软件应用或某个框架就算是微服务或敏捷开发了，也不是采用微服务和敏捷开发理论指导开发工作，就必须要使用某些软件或开发框架才能进行，这个是对微服务和敏捷开发的严重误解。   其次，在实际开发工作中，这两个指导思想要紧密的联合起来运用，才能达到更高效的团队运作，才能既快又好的进行产品迭代，将这两种指导思想的优势充分发挥出来。 先说一下微服务   微服务是一个架构理念，是指导架构设计的一种思想模式，延伸了领域驱动设计（DDD）。微服务是为解决逐渐复杂的系统设计、开发问题而提出的。当一个应用系统太过复杂时，设计与开发难度要比简单功能的系统大得多。其主要原因就是系统内有太多的耦合。这对系统迭代可能是致命的。DDD理论则较好的解决了这个问题