- 博客(182)
- 资源 (4)
- 收藏
- 关注
RSS订阅原创 用户故事的扩展-新的故事类别
用户故事自最早1998年诞生以来，由于其突出的优点，到现在得到了广泛的应用。从最开始的克莱斯勒C3项目，用户故事当中的用户一般是指软件系统的人类用户，这类用户故事一般涉及人机交互界面。 而随着用户故事在多种场合扩展使用，慢慢衍生出另外两类故事。本文试图来整理下新的故事。新的故事1，系统故事 System Story 2，赋能故事 Enabler Story，也称推动者故事，或者使能故事 为什么不
2016-08-21 13:18:33
1775
原创 用户故事之好标题
在利用电子工具的情况下，经典的用户故事句型的长度是超出电子工具的标题栏，而且标题过长，也难以让读者最快的抓住用户故事的重点。因此在电子工具的情况下，需要探索更短更好的用户故事标题写法。 用户故事的标题希望达到的效果是能够让读者快速了解这个用户故事的要点和大致范围。常见的做法有： 1. 从用户角度提炼动宾短语； 1. 从系统角度提炼动宾短语； 1. 主谓宾齐备写法1：用户角度的动宾短语样例：新
2016-08-14 18:37:51
3893
原创 用户故事的简要历史
【说明：敏捷类实践大都集中在最近20年出现，但变化很快，通过了解变化的历史，可以更好得理解趋势和当前为什么要这样。正因为此，笔者试图整理了用户故事的历史，所费时间不多，错漏难免，请大家点评，纠正补充，进而得到更加全面准确的记录】1998年，用户故事首次提出。 用户故事的起源是来自与XP极限编程的计划游戏环节，据现在能够追查的记录，最早是在1998年这样提到“用户故事”的：客户通过用户故事（像用例）
2016-08-14 12:27:41
2850
原创 强大的代码扫描工具SonarLint之安装使用
SonarQube（曾用名Sonar）之前的提供的本地工具是需要依赖SonarQube服务器的，这样导致其运行速度缓慢。 新出的SonarLint的扫描引擎直接安装在本地，速度超快，实时探测代码技术债务，给程序员最快速的反馈，排除代码异味的绝佳利器，帮助程序员获得Clean code。 新版SonarLint也能链接SonarQube服务器，但这并不必要。 本地安装SonarLint来做代码
2016-08-13 21:25:12
11977
3
翻译 写好用户故事的10个提示
用户故事可能是在捕获产品功能方面流传最广泛的敏捷实践。 利用用户故事来工作是容易的，但是讲述有效故事却是有困难的。 如下的10个提示能帮助到写好用户故事。1 用户先来如同名字所说明，一个用户故事描述了一个顾客或者一个用户如何使用产品；它是从用户角度来
2016-08-13 12:37:17
3944
原创 一个跨国银行的敏捷转型案例要点之全员培训
银行敏捷转型要点：Agile Center全员培训本文说明全员培训 •“Being Agile” is a deep change of values & mindset Rather than just implementing practices. “成为敏捷”不仅仅是采用敏捷实践，更是价值观和观念的深刻变革。 •“Doing Agile”is also not easy, the
2016-08-06 23:50:39
2079
原创 迭代燃尽图画法小议
在早期的Scrum培训中，燃尽图的典型画法如下： 1，在Sprintd的第一天，识别所有任务的工作量，常常使用理想工时作为单位，缩写是IMD，全文是ideal man day，这样得到燃尽图的第1个点 2，以后每天跟踪各个任务未完成的工作量，早期的工具不多，常用Excel来跟踪，并利用Excel来绘制燃尽图。跟踪部分形状如下： 利用Excel绘制得到的燃尽图如下： 为方便讨论，将此画
2016-08-06 15:39:27
10775
翻译 规模化敏捷框架（SAFe）的原则
The impression that “our problems are different” is a common disease that afflicts management the world over. They are different, to be sure, but the principles that will help to improve the qual
2016-07-23 16:17:11
8192
原创 一个跨国银行的敏捷转型案例要点之Agile Center
本文摘要为了更快更好的满足业务增长需要，这个跨国银行在全球各分支进行敏捷转型和推广，将敏捷实践应用到大型金融系统开发和维护。本文首先来介绍关于Agile center和敏捷教练的实践背景情况1.案例简述IT系统是银行运营的重要支撑，极端重要，极端慎重 包括变更审批评审文档格式等等在内的重型流程成为快速响应的障碍经过比较选择和试行，进行全球的敏捷转型2.达到的目标更快响应客户，缩短了
2016-07-21 08:16:47
6050
1
原创 关于精益和敏捷的对话
2012年12月的某日，@scmroad配置管理之路 发出了条微博 “求教，agile 和 lean， 请问这两个词在敏捷中都是是啥含义？有什么特殊的意思”, 后面@张克强-敏捷307，请我来回答。@张克强-敏捷307:回复@scmroad配置管理之路:lean的翻译是精益。agile的翻译就是敏捷。有观点认为，精益软件开发是敏捷软件开发的其中一种。也有观点认为，精益软件开发与敏捷软件开发是并列的
2016-07-08 09:06:40
9247
原创 User Story的常见困难
User Story已经在业内使用了多年，到目前为止，在与业界交流时，仍然存在着不少困难，试图列举下，再来看看解决方法。 常见的困难1：如何分拆故事？ 往往故事来自于史诗，刚开始比较模糊，到后面发现有许多细节要处理，而一个迭代内来不及处理了，如果坚持一个故事在一个迭代内能够处理完，那么这个故事就要分拆。 分拆之后，2个故事是存在上下文关联的，如何保持关联追溯？常见的困难2：如何处理关联到以前故事的
2016-07-07 12:15:36
6499
原创 团队章程---促进团队更合作和更高效
团队章程概述以前多数软件建设是按项目进行的，有明确的起始和收尾，随着互联网经济的兴起，互联网类软件建设不再是有明确的收尾，不再按照传统项目制进行，更加追求从开发到运维的高效运作，因而组织各种团队，而不是组织项目来处理。 因而项目章程也就不再适用到团队，也就转向了团队章程。 团队章程与项目章程存在很大的相关性，可以理解为从项目转到了团队。 团队章程是提供指导原则、规则并管理团队成员行为的方针政策。
2016-06-27 11:57:10
7417
原创 试论敏捷开发方法的共同特征
随着敏捷软件开发宣言的签署和发布，多个敏捷方法框架在全球得到传播和使用。因为各个敏捷方法框架由不同的专家组维护，所以各个方法有不同的表述方式，有不同的着眼点和侧重点。本文将为你介绍敏捷开发方法框架的共同特征，理解与传统软件工程的联系和不同。短迭代的生命周期模型生命周期是事物发展的客观规律，软件同样存在生命周期。早期的软件生命周期往往是说“软件从计划、需求开始，经历分析设计、实现、部署、维护，直到最后
2016-06-21 21:15:58
6172
原创 说说TDD的好处和坏处-对话
小帆 17:20谁来科普下TDD的好处和坏处是啥？我们市场VP听说了TDD以后情有独钟，但是大致看了一些好像很难推广？菌菌 17:21好处是大大的，坏处是成本很高罗耀秋 17:22你自己开发写代码 你愿意这样干不小帆 17:23@JuneC 好处具体是啥？福瑞德孟 17:24对于一锤子买卖的项目来说，如果没有自动化的工具，那成本一定是大于收益的；对于产品来说，一定是小投入，大收益菌菌 17:28据说
2016-06-21 21:13:53
9518
原创 苍狼敏捷软件开发团队建设指南-3-干系人管理
本指南的组成结构为了便于博客阅读，拆分成如下3部分： 1. 苍狼敏捷团队模型 2. 团队建设 3. 干系人管理干系人管理基础干系人管理是为了帮助团队在计划阶段识别组织内外部的干系人，在团队全生命周期当中计划并跟踪干系人的参与活动，以保障团队的成功。干系人又称为相关利益者。下文交待了干系人的基础说明，列举了潜在的干系人，给出了干系人管理策略和典型的干系人参与的活动。说明了如何识别干系人及其
2016-06-14 16:00:33
7024
原创 苍狼敏捷软件开发团队建设指南-2-团队建设
组建项目团队团队领导者根据项目情况、技能需要和组织人力资源布置来组建项目团队。进入条件团队领导者得到指派。输入项目情况和目标； 组织项目管理政策。活动1.团队领导者在与关键干系人沟通后选择团队模型，根据项目情况，从常见的团队模型中选择恰当的团队模型； 2.确定团队边界，帮助识别项目干系人（参见第6章），考虑与干系人的接口，更多相关内容见下文干系人相关内容； 3.确定团队成员，得到上级以及
2016-06-14 15:42:14
6661
原创 苍狼敏捷软件开发团队建设指南-1-团队模型
前言目的本团队建设指南的目的是帮助项目来定义和控制项目团队如何建立、如何运作来达成项目目标。范围适用于项目团队人数少于等于25人的项目。概要1．苍狼敏捷团队模型得到了描述，为项目团队组建提供了框架性的指导； 2．根据项目目标、实际情况和团队模型，组建项目团队； 3．指导团队下一步工作的团队章程由所有团队成员一起来制定； 4．推荐采纳合适的团队建设活动来使得团队工作作更有效、高效；
2016-06-14 15:29:18
7268
原创 需求评审五个维度框架分析及其带来的启示-5-结束语
本文整理归纳了需求评审的各种类型，分析识别了需求评审的5大关键方面，提出了五维需求评审框架，并分析验证了此新需求评审框架的有效性。结合此新需求评审框架，对软件开发主要情境进行了分析，得到了15个高效需求评审的启示，得到了结合需求条目化管理的多级小瀑布模型，这新瀑布模型也许将为陷入困局的传统瀑布模型打开一条新路。软件需求评审还有一些其他重要的方面，比如检查表和度量等等，本文限于篇幅不再更多分析，但值得
2016-06-09 10:31:11
5259
原创 需求评审五个维度框架分析及其带来的启示-4-需求条目化管理
需求条目化管理是指需求的主体分条目管理，比如对于用例、用户故事、特征点的条目化列表管理，有些工具中条目称为工作项(work item)。条目化管理的特征是1，状态流转实现工作流；2，条目属性字段可定制。3.3节所分析的敏捷开发下的需求绝大多数是已经实现了条目化管理，产品待办列表就是Scrum进行条目化管理的载体。而条目化需求管理并不是敏捷开发的专利，当前已经有不少组织在非敏捷环境下采用条目化需求管理
2016-06-09 10:29:04
9184
原创 需求评审五个维度框架分析及其带来的启示-3-典型需求评审
典型情境是指软件开发的常见情境，本文选择如下来进行分析： 1. 传统瀑布模型开发下的需求评审 2. 使用IEEE Std. 1028的需求评审 3. 敏捷开发下的需求评审传统瀑布模型下的需求评审对传统瀑布模型现有需求评审的分析传统瀑布模型在需求阶段末期安排有关键的需求里程碑评审，其特征参见2.8节情况1。在业界实际操作中，往往出现如下情况： 1，召集包括领导在内的各方代表，历经1～2小
2016-06-09 10:21:08
14601
原创 需求评审五个维度框架分析及其带来的启示-2-框架原理
本文试图归纳分析近年来出现的需求评审方式方法，全面涵盖系统性评审和非系统性评审，提出五维需求评审框架。首先确定对于需求评审的定义，结合传统需求阶段评审和敏捷迭代开发中相关需求实践，得如下定义。 定义1(需求评审). 需求评审是指基于需求文档阅读或者观察软件运行并且对当期工作有时效性的人工检查。根据以上定义，需求评审的范畴不包括机器自动检查，不包括需求审计；包括了需求上线后的校对，包括了系统性需求评
2016-06-09 10:07:38
5826
1
原创 需求评审五个维度框架分析及其带来的启示-总起
摘要 近年来随着CMMI、敏捷软件开发的推进，出现了多种多样的需求评审类型，这些类型超出了标准评审类型的范围。根据这些情况进行分析，得到了一个新的软件需求评审框架，这个新框架由5个维度组成： 1，组织形式；2，时机；3，侧重；4，评审者；5，对象 分析了分别在传统开发和敏捷开发下的典型需求评审情境，显示新框架能够适用于所有系统性的和非系统性的评审类型上。从分析中得到了15个有价值的启示。新需求评
2016-06-09 09:42:51
6673
原创 敏捷到底有没有带来新的东西？
有些敏捷传播者把敏捷看成是划时代的发明，敏捷里面所用到的实践大都归功于敏捷。 而有些敏捷反对者或者质疑者认为敏捷大量的抄袭了原来就有的方法实践，其实没有什么新东西。本文试图来分析下 敏捷到底带来了哪些新东西。 许多东西并不是截然分明的，为了便于表达，定义如下原创程度表示法： - 5 - 绝对原创 - 4 - 不是原创，但大幅度更新 - 3 - 不是原创，但有中幅度更新 - 2
2016-03-19 06:40:43
1812
原创 #软件配置管理#之坏味道搜集
软件开发热点词汇不断推陈出新，cmmi，agile，精益，持续交付，持续集成，灰度……但有一个词其实一直在那里，支持着各种各样的新热点，它是#软件配置管理#。 它也是影响团队软件开发效率的重大因素。下面来把我微博提到的坏味道归纳下#软件配置管理#之坏味道1：版本控制之下文件名里带版本号#软件配置管理#之坏味道2：通过评审或者发布的文件移到另外一个目录下，而不使用基线/lable/tag版本等等控制
2016-01-10 20:08:45
1898
2
原创 软件需求分层处理的多种常见方式
当前的需求 常见分 几个层次来管理？ 原先的SRS只有一个层次，在瀑布型生命周期中发挥了重要作用，需求里程碑评审和需求变更管理都是围绕着SRS来进行的。随着时间推移，瀑布型生命周期的弊端越来越明显，而瀑布型生命周期的需求管理是首先被改进的。一个明显的趋势是不再只有SRS，而是分多个层次来分析需求，进而开展需求管理。目前，业界出现了多种需求层次划分方式，本文来列举下。
2015-10-31 07:36:05
3919
2
原创 说说长篇文档的评审
对于长篇文档的评审，其实结果是很滑稽的，往往是通过稍作修改。很少有不通过的。而稍作修改就是随便改改。最终文档质量是没有保障的。因此现在条目化文档处理成为了新常态。比如需求是分条起草并评审的，通过就是通过。 diabloneo：确实是这样，我还没遇到完全重写文档的情况因此，有效评审长篇文档的办法就是把长篇文档拆短。需求被分解为小颗粒度的条目，请产品经理或者产品主管逐条确定，让各方理解。us
2015-03-28 17:14:26
1438
原创 说说#条目化需求#
之1：需求不再是传统的SRS文档，而是一条一条的，能够逐条查询，编辑，修改，状态跟踪。比如scrum提出的Backlog中的user story。之2: 需求条目的层级划分，一级的划分往往是不够的。第一级需求往往收集原始需求素材，难以控制其范围和规模，所以不便于直接开发；第二级需求经过第一级的过滤整理，适合提供给程序开发。在敏捷里常见划分出epic和story，在cmmi中分成了客户需求，产品需求
2015-03-28 17:02:02
6709
原创 代码夹带是洪水猛兽吗？
什么是代码夹带代码夹带是一个并不陌生的词组。一般的理解是在正常的代码中夹带入别有用心的其它代码。通过网上搜索，得到如下：其通常在计算机正常的程序传播当中将额外的一段代码夹带着,对计算机的网络安全造成破坏。从表面上看来,其不会对计算机进行主动攻击,但是只要安装了正常程序,而该程序...知道任何保密条款也无法阻止员工夹带代码出去。您必须保证您是诚实的,稳定的;由于我们的程序非常复杂(仅PHP文本就3G
2015-02-01 11:08:48
2132
原创 敏捷毒药-敏捷中有损组织整体的负面实践
首先声明1：敏捷毒药不是说敏捷是毒药，而是指敏捷中有损组织整体的负面实践，或者说在敏捷旗帜下的负面实践。笔者认为敏捷整体上是很好的，当前研发开发不学习利用敏捷，那就是固步自封了。声明2：本文做说的组织是多于200人的商业组织，尤其不包括少于50人的创业组织。声明3：来自Scrum创始人的一句话-There are a lot of development centric practices tha
2015-01-31 10:41:40
1657
1
原创 需求文档可以不签字吗之三-一个实例
AB公司试图管理自主产品的许可证发布，保障软件不被盗版，并进行统计，要利用已经有的AI系统扩充这部分功能。新功能主要分成2块：1，产品管理，2，许可证发布在产品管理里主要维护产品和产品版本的信息。许可证发布中，根据已经有的产品版本来申请许可证，产品开发部门审批后，IM系统能够自动生成许可证。为了开发这部分功能，在2010年，项目组首先书写了长达86页的《产品管理模块功能需求规格书》，历经了2次会议
2015-01-12 21:24:25
1900
2
原创 需求文档可以不签字吗之二-理论推导
怎么可能在没有需求文档的情况下，把软件开发出来？完全有可能。回想下当年读书的教研组，回想下自己的编程经历，总有至少那么几次，在种种的原因下，在没有需求文档的情况下，软件已经编写好了。也许那个软件规模小些，质量不是太好，但确实是没有需求文档的情况下把它编了出来。所以没有需求文档是可以把软件开发出来的。为了保证这样的软件达到要求，显然需要另外的手段。笔者认为最要紧的手段是快速地将运行的软件给用户试用或
2015-01-12 21:21:09
1647
原创 需求文档可以不签字吗？ 之一
在软件开发中，需求分析和需求管理一直被认为是软件开发成功与否的关键。在CMMI中，需求管理是CMMI2级的过程域，需求开发是CMMI3级的过程域。在瀑布型生命周期当中，安排了需求分析阶段，一般也安排需求分析里程碑评审。瀑布型生命周期存在了很多年，曾经几度写入到软件开发的国际标准、国家标准当中。由于瀑布型生命周期如瀑布般顺流而下，在设计阶段开始后，根据需求文档的结果来开展工作，要求需求文档的结果比较
2015-01-12 21:15:38
2779
原创 过程质量保证PQA的几个关键方面
过程质量保证的范围是什么？过程质量保证是指不同于测试的、主要针对过程和中间工作产物的质量保证，一般而言，早年间的过程质量保证根据最早的CMM，也称为软件质量保证，缩写为SQA。现在最新的CMMI将其对应的过程域称为产品和过程质量保证，缩写是PPQA，这里面的一个P产品包括了最终产物，但其焦点是中间工作产物，所以这个P放在这里反而是带来一些混淆，与测试存在一些重叠。所以过程质量保证（PQA）这个提法
2015-01-11 16:12:33
4854
原创 在“软件工程：研究与实践”研讨会上关于UML Use-Case的开放空间讨论
2014年12月20日我有幸参加了复旦大学承办的“软件工程：研究与实践”研讨会。在下午的开放空间活动中，我推荐了UML Use-Case作为6个话题之一，成为了这个话题的主持人。就这个话题与多位老师和业界专家进行了探讨。最后我作为此话题的代表向大家汇报了话题讨论。本文试图来整理记录下当时的讨论。1，在产业界UML和Use Case并没有得到很广泛的使用，能够用Use Case表达出原来SRS表达的
2015-01-02 10:56:49
2071
1
原创 关于软件项目工作量估算的若干问题
作者：张克强软件项目工作量估算从估算依据上看可以分成如下两类：1，基于规模估算2，基于工作量估算基于规模估算的情况下，需要估算软件项目的规模。本文首先来看规模方面的问题。问题1：如何表达规模？软件产品或项目的功能规模是涉及软件开发和交易的成本、项目资源投入的预测、项目维护成本的预算、项目质量管理的要求以及产品上市的时间等方面的关键指标。因此，进行软件产品的功能规模测量显得尤其重要。如何测量软件规模
2015-01-01 10:40:38
13241
原创 软件设计最近发展趋势对话录
QA美美 15:16 概设和详设，模版究竟涵盖哪些比较合适，更加有效？目前我所接触到的概设，有的主要涵盖的是模块的集成方案，但是现在又遇到的不是以模块间数据流为模版，而是类与类之间的交互，而详设也是对类进行描述 张克强 22:20 概设详设是以前的分法，还有HighLevelDesign和LowLevelDesign的分法。概设往上走，就是现在的架构设计，那么这样的概设到组件或者模块。 概设也可
2015-01-01 10:28:22
1809
原创 软件配置管理七重境界
软件开发热点词汇不断推陈出新，cmmi，agile，精益，持续交付，持续集成，灰度……但有一个词其实一直在那里，支持着各种各样的新热点，它是#软件配置管理#。 它也是影响团队软件开发效率的重大因素。英文缩写SCMSCM从软件工程诞生时，甚至诞生前就在那里，因为程序代码文档总是要存放的.SCM发展历经了许多阶段，试做七重境界分级七重境界之第一重共享目录，复制来处理多人合作，每天或每周备份下。每部分只
2014-12-21 10:16:44
4642
5
原创 曾经成功的敏捷团队为什么失败？
对于保持权威，即是让续任的项目经理继续坚持好的实践，续任的项目经理要同样的理解敏捷实践，理解其中利弊，能够做出权威的正确决策。这其实是对一个组织的项目经理培养机制的考验。一个成功的项目经理晋升了，续任者不可能有前任相同的看法和经验。中国人信奉新官上任三把火，续任者总是有些不一样的。“萧规曹随”虽然也是国人古代的智慧，但貌似在中国用得不多。 目前而言，培养权威的项目经理较之培养合格的敏捷教练，我认为培养前者更容易些。 在东方官文化下，合格的敏捷教练实在是太稀缺了。
2014-11-09 16:17:56
3997
8
DevOps下架构设计的趋势特征
2017-04-09
中国信息技术服务标准ITSS白皮书第二版.pdf
2014-04-19
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人