web應用的規劃

標籤：product owner   產品規劃   專案規劃   

第一次翻譯，也有許多沒弄明白，諒解。

原文http://railsapps.github.io/rails-product-planning.html

軟體開發過程

有些人認為軟體開發是從寫代碼開始的。但是事實上，產品的規劃是軟體開發過程的第一階段。

產品規劃，是實行從概念到編碼的核心，是使項目順利開工的關鍵。可以說，你自己開發的簡單

應用，你不需要顧慮很多，也不需要寫說明書，只需要寫寫代碼。但是，儘管你的應用看起來很

簡單，如果你是單獨經營的，產品規劃也是很有用的。軟體項目有一個趨勢,就是越來越複雜，並

且花費的時間超過預期的。至少至少，在你開始寫代碼之前，產品規劃可以協助你專註於你的想

法。如果應用變的複雜了，產品規劃會協助你跟蹤進度和確定方向。

而對於大的項目，當你是該項目團隊的一員時，或者說其他人的時間和金錢處在危險之中時，產品

規劃是一個健壯的軟體開發過程的關鍵因素。如果你打算讓公司成長發展，產品規劃是最基礎的。

花費多少時間在產品規划上由你決定，但是，請考慮做到以下幾點：

* 它能協助你知道需要實施的功能

* 它能協助你給商業夥伴描述和論述產品特徵

* 它具有一份清單，讓你知道要做什麼，還能協助你跟蹤進度

* 它是接受度測試或整合測試的基礎

產品擁有者（product owner）

一個應用中包含哪些特徵和功能是由誰來決定的呢？如果你是項目的發起者或者說你在開發你自己

的項目，顯而易見，你來決定你的應用要做什麼，你是產品擁有者。但是考慮一下其他情況，比如

一個學生被指派了一項作業，一個顧問負責規劃籌建客戶的項目，或公司的一個Team Dev。有人給

你一個開發一個應用的任務，一個是項目的目標比較高，另一個是項目的特徵和功能的執行細節都

處在灰色地帶，你夾在其中。典型地，一個客戶或執行管理不會給你提供一個詳細的產品要求的說

明書。此時，很多開發人員只是想知道開發什麼。此種情況下，產品擁有者是空白的，未知的。

產品擁有者可以是一個技術專家，或是一個商業人士。他的責任是審視這個應用，瞭解使用者的觀點，

決定哪些特徵和功能是必不可少的，哪些又是必須去除的。沒有產品擁有者的話，一個項目可能會

在模稜兩可中崩潰，會在個人突發奇想中位移，最終不能使任何人滿意。

使用者的故事（User Stories）

產品擁有者做產品規劃最主要還是要瞭解使用者。

使用者的故事是一種方法，用來討論和描述軟體應用的要求。這個寫使用者的故事的過程將會協助你確定

應用程式需要的所有特徵。把應用程式的功能分解成單個的使用者故事，能夠協助你組織你的工作並跟

蹤進度，走向終點。

使用者的故事常常被表達成如下格式：

作為<角色>

我想要<什麼>

結果是<什麼>

樣本，下面是應用程式預登陸的使用者故事

*索取邀請*

作為網站的訪問者

我想要一個邀請

結果是網站推出後，我及時得到通知

*看到所有索取*

作為網站的擁有者

我想要看到所有來索取邀請的訪問者清單

結果是我可以知道我提供的服務是否很受歡迎

*發送邀請*

作為網站的擁有者

我想要給那些來索取邀請的訪問者發送邀請

結果是訪問者可以通過邀請嘗試訪問網站

*收集郵箱地址*

作為網站的擁有者

我想要收集郵箱地址列出投郵清單

結果是我可以在網站推出前發送公告

*註冊後在社交網路分享*

作為一個使用者

我想要在我註冊之後，分享到社交網路

結果是我的粉絲將會瞭解這個網站

我們在運行應用時可以將這使用者故事清單作為我們的任務清單

行為驅動開發（Behavior-Driven Development）

行為驅動開發是一種軟體開發方法，它以使用者的故事作為自動化的測試的基礎。使用者的故事演變成測試的情境，

有了自動化的測試，產品擁有者能夠確定開發人員是否把需求的特徵和功能做好了。這個過程叫做接受度測試。

自動化的測試也使開發人員很容易確定在添加了新的特徵、修複bug或重寫代碼後應用程式是否依然正常工作。

這個過程叫做整合測試。

下面是運用Cucumber行為驅動開發怎麼樣把使用者的故事作為基礎的方法

*寫使用者的故事

*使用者的故事變為Cucumber的情境

*依據Cucumber的情境建立接受度測試。

*對每個特徵進行編碼

*每個特徵編碼完成後進行接受度測試

Cucumber情境把使用者的故事轉變為實施產品特徵的一系列的步驟的單純的描述。

當一個團隊裡有非程式員，而他又參與產品需求的定義時，或當需要一份說明書和接受度測試使應用的實現

保持獨立時，Cucumber是很合適的。

不用Cucumber下的行為驅動開發

（Behavior-Driven Development Without Cucumber）

也有Cucumber的可替代品，它們在項目更小或團隊中人想舒適地閱讀軟體代碼時也許更合適。

許多rails開發人員運用Capybara in combination with RSpec建立整合測試，這個在Ryan Bates’s How I Test Railscast

中都有描述。運用RSpec and Capybara的方案使用者的故事仍然能夠成為產品規劃的基礎。不用Cucumber，運用

RSpec and Capybara，應用程式的特徵仍然能夠被測試，而特徵仍是基於使用者的故事的。

線框圖和模型（Wireframes and Mockups）

使用者的故事不是規劃一個web應用的唯一技術。常常在寫使用者的故事之前，產品擁有者會為各種頁面畫草圖，

畫草圖是你將對應用的一些想法可視化的一個階段。畫草圖最後成為線框圖或模型，這兩個說法常常可以互

換使用，但是在意義上有所不同。

一個線框圖能夠展現網頁上的功能元素，它不應該描述提出了的網站的圖形設計，而應只是網頁的簡單示意

圖，沒有顏色，沒有圖形。

模型給線框圖增加了圖形設計，包括商標、顏色、預留位置內容。模型給出一個網站個性以及提出了的功能的

印象。建線框圖最流行的工具之一是Balsamiq Mockups。

平面設計（Graphic Design）

根據需要，平面設計是和應用程式開發分開的一部分。很少的人是平面設計者，同時又是程式員。平面設計

所用的工具不同，平面設計者典型地會使用Adobe Photoshop，儘管有些精通網頁的設計者會直接用html

和css做設計。

如果你幸運，你開發應用的時候從平面設計者那裡獲得了協助。如果你非常幸運，你也許會和一個懂使用者體

驗及互動的設計師合作。

如果你和一個平面設計者一起工作，你也許要合作，通過樣板或簡要設計來定義你的應用程式的外觀及給人

的感覺。如果設計者用photoshop工作，你將面臨挑戰將設計架構從photoshop轉換為HTML和CSS。有這

樣的服務公司收取費用做這個，但是很明顯如果和一個直接用html和css做設計的設計師合作更容易。

當需要整合平面設計和代碼的時候，rails特別具有挑戰性。rails用在view檔案中混合了html標籤和ruby程式

代碼。很少有設計者適應在html中混雜者ruby代碼，那麼只能靠你你自己來整合它們了。

如果你沒有一個平面設計師的協助，你可以用Twitter Bootstrap或其他的前端架構例如Zurb Foundation在你

的應用中快速地添加迷人的設計。