一個 iPhone App 開發之路要走多久才能結束

開發之路

有衡量過自己從開始一個 iPhone App 開發專案，到最後可以順利上架，中間的路有多長嗎？有試著想過當一個開發計劃進來，到最後預估會何時給 Apple 送審、上架、使用者回饋修正到再改版要多久嗎？這個問題相當的重要，因為我們必須要知道這專案要走多久，當走的時間超出當初預期，開發人員會士氣低落，計劃負責人擔憂與煩惱。如果在預定的時間結束，開發人員會獲得成就感，計劃負責人在對客戶報告時候也才能交出漂亮的成績單。
 

依照我這陣子開發 iPhone App 專案和產品下來，可以漸漸歸納出要走的路有哪些，活動會碰到那些。

1. 專案計畫需求談定

常常會聽到這樣的聲音，『我想要做某某 iPhone App』、『我有個外包案不知道開發商是否有意願接』、『請廠商報價』，這都是在專案計劃起頭時會面臨的難題。身為使命必達、功能不但開發完善、還外加些額外加值服務的開發商而言，只有一個目標，就是結案。把專案 100% 結案，時間不要拖太久為始終目標，在這階段一定要把功能需求條列清楚。哪怕一筆一筆的寫下來會有哪些功能內容，這樣子計畫在協定的時候才能對於整體的範圍才能有個概念。至於之後進行到後面階段，如果要新增任何需求，都要在一開始就把醜話將在前面，會如何處理。很多專案計畫好不好做，在這一開頭就決定勝敗了。有幾個指標可以拿來評估：

• 對於開發的功能明定了嗎？
  這步如果沒走好，會產生需求蔓延的現象。 
• 對於功能之間使用上複雜度高不高？
  如果程式高會深深影響後面開發與測試，因為複雜度高，邏輯上就會難開發，難驗證功能開發正確與否。簡單衡量 iPhone App 程式複雜度可以從 UIViewController 有多少個、程式碼 source code 本身複雜度會不會提高等方向來評估。
• App 的 UI 上有沒有特殊要求？
  如果參與計劃上有搭配 Designer 負責配色、圖案設計對於 iPhone App 本身而言影響多深。這要用來衡量開發人員和 Designer 合作上會面臨那些合作。
• 除了 App 本身開發之外，其餘的加值服務會需要哪些？
  在 iPhone App 方面常常被牽扯進來的加值服務是：社群分享、使用者使用 App 行為追蹤、錯誤回報、幫 App 上 App Store 打分數提醒、push notification、支援 In-App purchase 等等。以上這些跟 App 本身要給使用者的服務不是那麼的相關，但是也影響到整體計劃上的策略應用。貪心的人類一定會說這個我要、那個我也要。這邊會深深影響到日後開發上和測試上所需要的時間，所以這部分要謹慎納入考量。

2. 草稿手繪型的 Paper prototyping

在這階段會把收集來的文件、需求列表開始討論、不論是在黑板上畫出個想法、隨便在張紙上畫出想法。當最後都差不多時候，開發團隊可以用清楚的線條來畫出畫面該有的元件、各個頁面之間會長怎麼樣子。Paper prototyping 對於我們的重要性是：要快、要明確定出畫面長相、要明確瞭解到我們要開發怎麼樣的 App。如果在這個階段可以把 Paper prototyping 跟老闆或是客戶報告是最好的。客戶參與設計是 Aglie 敏捷式開發重要一環。在這階段一定要把功能範圍開始敲定，如果不敲定再往下走會逐漸走向功能蔓延開發之路。

3. 可互動的雛型設計 Prototyping

當 Paper prototyping 畫出了，功能範圍也大致敲定了。開發人員可以開始用互動式雛形工具，或者直接打開 Xcode 開始打造整體框架出來，這個範圍會包含畫面上的種種元素、配合些假的資料 (Mock data)，讓這階段可以產出可以互動的雛形出來。這個階段的重要性是把原來僅有畫面的紙上雛形，逐漸讓它活起來，不但畫面更細緻更精確了，也讓整體 App 動線上呈現出來。任何只要發現不順、怪怪的在這階段都非常歡迎提出來。而如果互動式的雛形可以放到實體 iPhone 裝置上體驗，那個效果會比在電腦上看來的更精確。如果說所有該有的功能在這階段都做出來，才可以估這個專案計畫完成度 20%。

4. 實作開發

當拿到上個階段的產出 Interactive prototyping，開發人員即可依樣畫葫蘆開始實作起來。在這階段開發人員會作：訂定邏輯處理、設計 Domain object、引用各種 library 和 frameworks，接上真實的 Web Service 去呼叫真實的資料，將 Mock data 卸下，放上真實的資料，講功能一一打造出來。如果說在這階段將所有的功能都做出來，也做好了功能測試、單元測試的話，確定功能穩定度沒問題的話，才可以估計這個專案計劃完成度僅有 60%。

5. 功能釋出開始測試

當功能做出來，除了開發人員本身測試品質之外，也會開始請相關人員參與測試，承辦人、設計師、相關同仁確定這樣設計出來是當初計畫要的，而且開發人員在開發認知上，和專案負責人瞭解上是正確的，在這階段這個專案計劃完成度僅有 70%

6. 使用者測試

如果說開發的 iPhone App 已經可以在裝置上測試，且也讓相關負責人員確認過功能就是要這樣子之後，我們需要的是使用者測試。開發人員不能代表使用者，因為開發人員打從一開始就參與這個案子，很多東西都會當成理所當然，功能就是要如此一般使用。但是真正的 end user 他第一次打開這個 App 就是這樣子使用嗎？他會不會困惑呢？會不會有驚喜呢？會不會有卡住無法走下去的呢？在這個階段不是那麼必要性，但是也不能不做，做使用者測試需要成本，只能說能多做一次，能讓 App 本身更好用，這個投資就是值得了。要探索的是是否娛樂性、好記性、容錯性、簡單上手，開發上不會明確知道這些答案，只有使用者能告訴我們客觀的答案。

7. 反覆式設計

根據功能釋出收到的回餽，不論是 Bugs、Improvement、或者任何建議都是在這階段一一做修正做調整，讓 App 可以越來越上軌道，越來越貼近期盼看到的樣子。每當一個階段結束，我們可以返回前面第 5 和第 6 步重複進行，一直進行到大夥們的理想。那麼完成度就可以對照到 80%、85% 或者 90%。

8. 準備提交送審

能走到這個階段要非常恭喜專案中的每一位成員了，因為產品終於要準備問市了。當最後確認功能都沒有問題、 App 本身的 Icon 和歡迎畫面 Default 圖都準備到位，和 App 本身的各種屬性版本等等設定沒問題，就可以 Archive  準備提交給 Apple 送審了。在送審等待問市中間的這個階段，我們可以為下一版的功能開始開發，回到開發人員實作的部分。

9. 上架後的應對措施

當 iPhone App 上架後才是真正見真章的開始，有多少下載量，有多少人購買，有多少人在上面發表個人使用意見，這一切是如此的逼真，因為 iPhone App 才真正的被市場打分數。

10. 更新版的釋出

iPhone App 的 1.0 版問市一定會搜集到很多的回餽，而這些回餽和原本預計開發的一定會影響著下一版本的開發與提交給 Apple 再次送審上架，這個階段也是從活動 4 實作開始。
 

如果我們不想要讓專案 Delay，甚至希望可以提前問市，那麼就要拿出我們的專業度出來，對於一個 iPhone App 開發之路要走多久，我們心裡一定要有譜，有譜我們才能走的順利，才能開發地安心，開心的結案。