云服务器内容精选
-
如何识别用户故事的坏味道（BadSmell） 如同低质量的代码会有Bad Smell，用户故事也一样会有坏味道： 几十页上百项需求堆在Product Backlog里。 提交的需求，自始至终没人和你沟通，某一天突然发现需求被实现了。 排在Product Backlog中段和后段的用户故事太过详尽。 大家依赖Product Backlog电子系统，而不是面对面进行沟通。 用户故事长得像需求规格说明书。 说不出故事的目标用户以及带来的价值。 很难为众多故事排优先级（不是高中低，而是唯一顺序）。 故事之间牵一发而动全身。 如果你发现上面任意一条出现在你的项目中，那说明你的用户故事还需要改进。
-
非功能性需求以及技术类需求 非功能性需求（Non Functional Requirement）往往是决定产品或项目成败的关键，却往往容易被忽视。当非功能性需求欠缺太多，就背负了技术债务，需要通过定期的技术类活动进行清理。 典型的非功能性需求包括：性能、可移植性、可扩展性、可用性、易用性、可维护性、可重用性、可操作性、安全性、容量等。 技术类需求的例子包括：重构、搭建持续交付流水线、测试自动化活动、环境的维护与搭建、架构改造等。 目前CodeArts没有预置非功能性需求和技术类需求作为单独的工作项类型，不希望工作项类型过于膨胀而增加了使用的复杂性。 通过新增字段可以标识不同类型的需求，更好的方式则是采用Tag标签。善用标签和过滤器的结合，可以实现非常强大的功能，关于过滤器的使用技巧，我们可以单开一个主题来讨论。
-
如何创建和收集故事？ 通常有几种方式进行用户故事的创建和收集，其中前两种是最经常采纳的： 用户访谈 故事编写工作坊 问卷调查 观察 用户访谈的关键是找到真正的用户，所以用户访谈之前是用户画像，也就是找到Who的过程。 “你们的确开发了我所说的功能，但它并不是我真正想要的”，用户往往不知道或很难准确表达自己想要的，所以沟通需要频繁，需要拿着不同阶段的产物进行确认。说者无心，听者有意，会不会是自己主观臆断？说者有心，听者无意，会不会遗漏关键字？同理心说起来容易，做起来很难。 用户故事编写工作坊是捕获需求最有效的方式，原则是：数量优先而不是质量优先，鼓励大家输出，而不要去评判某个故事的好坏；深度优先而不是广度优先，先把一条路走通，而不要中途跳到岔路上。用户最可能做什么？可能会犯什么错误？会有什么困惑？会需要什么信息？在工作坊里最好用贴纸，便于交互，随后再整理到工具平台上。 观察用户真实使用产品的机会是难能可贵的，你会发现用户永远不会按照你设计的方式使用产品。
-
有关用户故事的一些零散建议 需求要有时间点。多问一句“什么时候需要？”，你往往会发现对方其实心里没数，ASAP不是一个好答案，越快越好只能说明不信任。尽管会有顾虑，我依然会如实说“这个功能与一个月之后的某个活动相关，在此之前实现即可，但需要预留给我一周的时间进行验证和修复”。 进行故事优先级排序时，需要考虑成本，一个重要的需求，有可能因为成本过高而延后，另一种方法是对其进行拆分。 不要着急给用户故事添加细节，遵循Kent Beck提出的最后责任时刻原则（Last Responsible Moment），团队要等到开始实现软件特性前才写下特性的具体细节，优先级排序，近期、中期、长期需求的详略程度。 纸质卡片、贴纸，还是电子工具？ 在需求收集和引导的前期，例如需求编写工作坊，建议采用纸质卡片，便于交互，并且卡片的有限文字空间保证了我们不会过早进入细节。 当需求收集告一段落，统一将需求录入到CodeArts平台，需求不只是Card一个维度，多方位的信息需要有工具平台来支撑和记录。同时平台也提供了团队成员之间的协同，CodeArts团队异地的协同场景就是基于CodeArts平台进行的。
-
我们遵循Ron Jeffries提出的原则 关于用户故事，Ron Jeffries用3个C来描述它： Card（卡片）：我们在用户故事编写工作坊中使用贴纸或卡片编写，随后录入到CodeArts成为工作项，展现方式可以是卡片、列表或树状结构。卡片代表需求而不是记录需求，详尽的需求内容可以用其他文档表述。 Conversation（讨论）：讨论的过程建议是面对面的，如果与CodeArts的成员一样，分布在不同地域，可以通过电话或IM工具（华为内部用eSpace，可以聊天，也可以语音、视频）进行，将重要的结论写在工作项提供的讨论功能中。简单的讨论可以直接通过工作项的讨论进行，但需要牢记的是，文字的讨论永远无法取代面对面或是电话的沟通。 Confirmation（确认）：用户故事并不具备契约性质，达成协议的验证要点是测试的依据，用来验证用户故事是否符合用户的期望。在用户故事编写工作坊中，验证信息可以写在故事卡片的背面，随后录入工作项。针对每一个测试要点都应该变成完整的测试用例，测试用例会与需求进行关联，由此完美的将3C结合在一起。 在CodeArts中的用户故事： 卡片是用户故事的展现形式，我们会切换到迭代视图的卡片模式，通过拖动卡片完成状态更新。 讨论是沟通的方式，不要让讨论的内容蒸发掉，讨论过程中最大的浪费就是大量的信息随后被遗失掉了。我们通常在Story工作项的评论中记录讨论结果，或是直接在评论中进行讨论，并用@通知他人。 确认是验收方式，验收信息可以填写在描述信息中，也可以在项目设置中在Story工作项的模板中添加一个属性字段完成，具体实现方式不一，并且实现起来非常灵活，所以并未做进预置的项目模板中。 一个用户故事工作项，事实上是一个需求的入口，以条目化或是卡片的形式展现，同时可以进行多方位的关联。 由验收信息生成的测试用例，会关联到工作项的“关联用例”中。 在对话和沟通的过程中会产生的有用信息，可以通过Wiki（知识共享）、Docman（文档协同）来保存，并且可以关联到Story工作项。 可以将现有的文件添加为工作项的附件。
-
前言 秉承吃狗粮的文化，CodeArts团队在践行精益敏捷DevOps的同时，也在使用CodeArts工具进行实践落地。 需要说明的是： 本文中提到的实践方式，CodeArts团队在践行，所以具有一定的示范性。 不具备普适性，每个团队都应该根据自己团队的业务特性、团队成熟度、流程以及对方法论的解读，来进行落地实现。 里面有很多优化的空间，并没有最好的实践，只有适合的实践。 通常而言，软件开发起始于需求收集与分析，所以本文从需求谈起。 传统的瀑布研发模式基于三个假设： 用户准确的知道自己想要什么。 开发人员能够完全理解用户在说什么。 需求在研发过程中不会发生变化。 但事实上这三个前提假设都不存在，需求沟通之后做出来的产品，往往与需求大相径庭。
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
