用戶故事與敏捷方法

前言

數(shù)年前，Mike Cohn寫了這本User Stories Applied: For Agile Software Development，而我從2007年才真正開始接觸敏捷，沒想到在2009年我竟有機(jī)會(huì)能夠參與翻譯這本有關(guān)用戶故事的經(jīng)典著作，我感到十分的榮幸。 敏捷開發(fā)近些年在國內(nèi)軟件開發(fā)公司中十分流行，因?yàn)樗鼮檐浖_發(fā)指引了一個(gè)方向。而用戶故事是敏捷實(shí)踐中一個(gè)十分重要的環(huán)節(jié)。它能幫助我們高效地收集客戶真正的需求。軟件開發(fā)都起始于需求收集與分析。如果一開始需求都弄錯(cuò)了，軟件的成功也就無從談起。同時(shí)，用戶故事帶來了一個(gè)十分重要的作用，即高效溝通，不論是開發(fā)團(tuán)隊(duì)與客戶的溝通，還是團(tuán)隊(duì)內(nèi)部成員之間的溝通。溝通使客戶和團(tuán)隊(duì)成員都朝同一個(gè)方向前進(jìn)，這意味著更少的錯(cuò)誤，更少的浪費(fèi)、風(fēng)險(xiǎn)和成本。用戶故事還是敏捷計(jì)劃與估算的重要基礎(chǔ)。 我十分有幸能在Irdeto BSS進(jìn)行敏捷開發(fā)。在這里，我們使用Scrum，結(jié)合XP進(jìn)行開發(fā)。用戶故事自然是不可或缺的。在這里，每個(gè)團(tuán)隊(duì)都有一個(gè)白板，上面貼有一些卡片。它們是這個(gè)Sprint團(tuán)隊(duì)計(jì)劃完成的用戶故事以及這些故事劃分的任務(wù)。這些用戶故事卡片概要描述了需求，形如“作為(角色)，我想要(功能)，以此(商業(yè)價(jià)值)”，有時(shí)上面還附著另一張卡片寫著驗(yàn)收條件。在做計(jì)劃和開發(fā)的時(shí)候，團(tuán)隊(duì)可以拿著這個(gè)用戶故事討論故事細(xì)節(jié)，故事如何才算完成，等等，正如Ron Jeffries所描述的3C：Card(卡片)，Conversation(交談)和Confirmation(確認(rèn))。 用戶故事從始至終貫穿于整個(gè)開發(fā)流程。首先產(chǎn)品負(fù)責(zé)人根據(jù)收集來的需求編寫用戶故事，放入產(chǎn)品Backlog中。在Sprint計(jì)劃會(huì)議中，團(tuán)隊(duì)成員討論其中的一些用戶故事，細(xì)化故事細(xì)節(jié)，確定驗(yàn)收標(biāo)準(zhǔn)，使用Planning Poker(計(jì)劃撲克)估算故事點(diǎn)。然后，將故事分成一些小的任務(wù)，并估算工作時(shí)間。最后，將故事放入Sprint Backlog中，并按優(yōu)先級(jí)排序。Sprint開始時(shí)，故事卡片和任務(wù)卡片都放在白板的To Do欄，團(tuán)隊(duì)成員按故事的優(yōu)先級(jí)挑選任務(wù)，將任務(wù)卡片挪到Doing欄。任務(wù)完成后，將任務(wù)卡片挪到Done欄。團(tuán)隊(duì)盡可能地先完成優(yōu)先級(jí)高的故事。在故事開發(fā)的初始階段，測試人員和產(chǎn)品負(fù)責(zé)人一起確認(rèn)測試用例。故事的任務(wù)都完成后，產(chǎn)品負(fù)責(zé)人驗(yàn)收并確認(rèn)故事已完成，將故事卡片挪到Done欄中。如此完成整個(gè)Sprint的所有故事。Sprint結(jié)束時(shí)，團(tuán)隊(duì)還要將完成的故事演示給利益相關(guān)人、其他產(chǎn)品負(fù)責(zé)人和團(tuán)隊(duì)等。這樣，每個(gè)Sprint團(tuán)隊(duì)都會(huì)通過完成一系列的用戶故事來向客戶輸出商業(yè)價(jià)值。 這次翻譯我們一共四個(gè)人參與，我和石永超主要負(fù)責(zé)翻譯，滕振宇和李國彪主要負(fù)責(zé)審核。前期的第一個(gè)月，我們幾乎沒有什么太大的進(jìn)展。我們討論過后，發(fā)現(xiàn)這次翻譯其實(shí)是一個(gè)具有固定交付時(shí)間、固定范圍(21章和兩個(gè)附錄)且依賴虛擬兼職開發(fā)團(tuán)隊(duì)的項(xiàng)目，包含開發(fā)(翻譯)和測試(審核)等工作，何不用敏捷的方式來開展？于是，第二個(gè)月開始，我們使用敏捷的思想來指導(dǎo)翻譯工作。我們首先把每一章當(dāng)作一個(gè)用戶故事，每個(gè)故事估算一個(gè)故事點(diǎn)(這個(gè)是我們做的不足的地方，一個(gè)故事點(diǎn)顯然不能準(zhǔn)確反映各章的不同篇幅)。我們以一個(gè)星期為一個(gè)迭代，用一份Excel文檔作電子白板。每個(gè)周末固定時(shí)間用Skype開一次網(wǎng)上語音會(huì)議。如同Scrum的每日例會(huì)一樣，大家回答三個(gè)問題：這個(gè)星期我做了什么，下個(gè)星期準(zhǔn)備做什么，有什么困難。然后討論大家遇到的一些翻譯難點(diǎn)，統(tǒng)一一些術(shù)語的翻譯。大家在完成每個(gè)星期的翻譯工作的同時(shí)，必須及時(shí)簡單地更新Excel中故事的狀態(tài)。這樣一來，每個(gè)人都能及時(shí)知道每一章的進(jìn)度，哪一章可以審核，哪一章沒有人翻譯，可以任領(lǐng)。同時(shí)，Excel中還有燃盡圖，告訴我們離目標(biāo)還有多遠(yuǎn)，是否需要調(diào)整。如此，這份Excel文檔就成為我們的另一個(gè)溝通工具。另外，我們還有十分重要的工具，如同我們的軟件項(xiàng)目一樣，對于項(xiàng)目中的所有文件(包括電子白板和術(shù)語表)，我們使用版本管理工具Subversion和持續(xù)集成工具CruiseControl。我們每次簽入，持續(xù)集成工具都會(huì)立即發(fā)一封郵件通知大家有新的改動(dòng)，郵件包含有簽入的描述，這樣可以提醒大家某一章翻譯完了，應(yīng)該審核，等等 。這樣，從第二個(gè)月開始，我們的翻譯工作就始終保持穩(wěn)定的進(jìn)度，團(tuán)隊(duì)通過更多更頻繁的回饋不斷學(xué)習(xí)成長，持續(xù)改善譯稿和翻譯過程，最終按時(shí)交付了翻譯稿。 這次翻譯成為我們軟件開發(fā)之外的一次敏捷實(shí)踐，獲益良多。同樣，我們也希望能夠讓更多的人了解敏捷，讓更多從事軟件開發(fā)的人和其他行業(yè)的人從中獲益。翻譯這本書也希望能為傳播敏捷思想與方法盡一份力。讓更多的人了解用戶故事，使用用戶故事，帶來更多成功的項(xiàng)目。 在此感謝一起翻譯的伙伴們：李國彪、滕振宇和石永超。感謝你們讓我能夠獲得參與翻譯此書的機(jī)會(huì)，我從中學(xué)習(xí)了很多很多，不僅僅是對用戶故事更深入的了解，還有在這次翻譯過程中對敏捷更全面、深刻的理解。

內(nèi)容概要

本書詳細(xì)介紹了用戶故事與敏捷開發(fā)方法的結(jié)合，詮釋了用戶故事的重要價(jià)值，用戶故事的實(shí)踐過程，良好用戶故事編寫準(zhǔn)則，如何搜集和整理用戶故事，如何排列用戶故事的優(yōu)先級(jí)，進(jìn)而澄清真正適合用戶需求的、有價(jià)值的功能需求。
　　本書對于軟件開發(fā)人員、測試人員、需求分析師和管理者，具有實(shí)際的指導(dǎo)意義和重要的參考價(jià)值。

作者簡介

科恩（Mike Cohn），是敏捷聯(lián)盟的發(fā)起成員之一，并擔(dān)任其文章項(xiàng)目的總監(jiān)。他1984年開始編程，1988年開始管理軟件項(xiàng)目，客戶包括富達(dá)投資、維亞康姆、寶潔、NBC和花旗銀行。Mike寫本書時(shí)是Fast401k的軟件工程副總裁。這家行業(yè)領(lǐng)先公司提供基于互聯(lián)網(wǎng)的401（k）檔案保存和管理解決方案。Fast401k向金融服務(wù)行業(yè)客戶提供自主品牌的e401k軟件產(chǎn)品，作為外包服務(wù)供應(yīng)商，利用專有技術(shù)實(shí)現(xiàn)規(guī)模經(jīng)濟(jì)效應(yīng)。在本書之前，Mike著有或合寫了4本編程方面的書籍。（譯者注：Mike也是《敏捷估計(jì)及估算》及Succeedingwith Agile兩本重要敏捷著作的作者，并與其他兩位敏捷泰斗Ken Schwaber和EstherDerbv一起創(chuàng)辦了Scrum聯(lián)盟。）

書籍目錄

第Ⅰ部分 起步
　第1章 概覽
　第2章 編寫故事
　第3章 用戶角色建模
　第4章 搜集故事
　第5章 與用戶代理合作
　第6章 用戶故事驗(yàn)收測試
第Ⅱ部分 估算和計(jì)劃
　第8章 估算用戶故事
　第9章 發(fā)布計(jì)劃
　第10章 迭代計(jì)劃
　第11章 測量并監(jiān)控速率
第Ⅲ部分 經(jīng)常討論的話題
　第12章 故事不是什么
　第13章 用戶故事的優(yōu)勢
　第14章 用戶故事不良癥兆一覽
　第15章 Scrum與用戶故事
　第16章 其他話題
第Ⅳ部分 一個(gè)完整的實(shí)例
　第17章 用戶角色
　第19章 估算故事
　第20章 發(fā)布計(jì)劃
　第21章 驗(yàn)收測試
第Ⅴ部分 附 錄
　附錄A 極限編程概覽
　附錄B 參考答案

章節(jié)摘錄

插圖：我們需要一種協(xié)同工作的方法，讓雙方都不占絕對主導(dǎo)地位，共同面對感情用事和辦公室政治化的資源分配問題。若資源分配問題完全落在一方，項(xiàng)目必定會(huì)失敗。如果只讓開發(fā)人員來承擔(dān)這些問題（他們通常會(huì)被告知“我不關(guān)心你們怎么做，但請你們在6月份之前完成”），他們可能會(huì)犧牲質(zhì)量來換取額外的特性，也可能只部分實(shí)現(xiàn)一個(gè)特性，或者自行做出一些本該在有客戶和用戶參與情況下才能做出的決定。如果只是客戶和用戶承擔(dān)資源分配的責(zé)任，那么我們通常會(huì)在項(xiàng)目開始時(shí)看到一系列漫長的討論，項(xiàng)目中的特性逐漸減少。之后，在最終發(fā)布軟件時(shí)，只剩下很少的功能，甚至少于被減掉的功能。至此我們已經(jīng)了解到，我們不能完美地預(yù)測軟件開發(fā)項(xiàng)目。當(dāng)用戶看到軟件的早期版本時(shí)，他們會(huì)想出新的點(diǎn)子，從而改變他們的觀點(diǎn)。由于軟件的這種不可控性，大部分開發(fā)人員都會(huì)遇到眾所周知的艱難時(shí)刻，估計(jì)需要多長時(shí)間才能完事兒。因?yàn)檫@些因素及其他一些因素，導(dǎo)致我們無法勾勒出一幅完美的PERT圖①來展示項(xiàng)目中所有必須完成的事情。

編輯推薦

《用戶故事與敏捷方法》：敏捷大師Mike Cohn的軟件需求方法圣經(jīng)，小型團(tuán)隊(duì)(項(xiàng)目)不可或缺的敏捷開發(fā)寶典，亞馬遜五星級(jí)長銷圖書，敏捷社區(qū)重點(diǎn)推薦，結(jié)合精髓和實(shí)例，充分演繹用戶故事的智慧。在敏捷社區(qū)的詳盡評(píng)審和熱切期盼下，  《用戶故事與敏捷方法》不負(fù)眾望.為軟件行業(yè)提供了一種節(jié)省時(shí)間和消除重復(fù)工作的需求管理方法.對開發(fā)更優(yōu)秀的軟件起著積極、高效的推動(dòng)作用。構(gòu)建滿足用戶需求的軟件.最好的方法是從“用戶故事”開始，即簡明扼要、清楚明確地描述對實(shí)際用戶有價(jià)值的功能。在《用戶故事與敏捷方法》中.敏捷大師Mike cohn提供詳盡的藍(lán)圖來指導(dǎo)我們?nèi)绾尉帉懹脩艄适?如何把它們應(yīng)用于軟件開發(fā)生命周期中?！队脩艄适屡c敏捷方法》介紹了如何編寫理想的用戶故事，造成用戶故事不理想的原因有哪些，如何在無法與用戶交流的情況下有效地搜集用戶故事.如何對已經(jīng)寫好的用戶故事進(jìn)行整理、排列優(yōu)先級(jí)及在此基礎(chǔ)上進(jìn)行計(jì)劃、管理和測試?！Ｗ⒂凇坝脩艄适隆边@一靈活、敏捷和實(shí)用的需求方法?！?qiáng)調(diào)如何用更短的時(shí)間開發(fā)更符合用戶需求的軟件應(yīng)用?！そ沂救绾卧诓荒苤苯优c用戶交流的情況下搜集用戶故事?！ぴ忈層脩艄适碌膬?yōu)勢，用戶故事與用例、使用場景和傳統(tǒng)需求方法的不同?！ぞ訇U述如何圍繞著用戶故事進(jìn)行全面的規(guī)劃、進(jìn)度、估算和測試?！O限編程(Extreme Programming)，scrum或其他任何敏捷方法的最佳伴侶。采用XP和scrum等敏捷開發(fā)方法或其他軟件開發(fā)方法的開發(fā)人員、測試人員，分析師和管理人員．可以從《用戶故事與敏捷方法》獲得有價(jià)值的信息，以更少的人員在更少的時(shí)間內(nèi)開發(fā)出更符合用戶需求的軟件應(yīng)用

圖書封面

圖書標(biāo)簽Tags

無

評(píng)論、評(píng)分、閱讀與下載

---

    用戶故事與敏捷方法 PDF格式下載

---