功能性軟件需求規範（FSRS）和敏捷開發

Question

我正在學習如何使用敏捷方法學來領導RoR項目的一組開發人員。我發現了一些在線工具，如VersionOne或PivotalTracker，可以幫助您創建迭代，積壓，故事等，這樣您就可以將工作與前端和後端分開，並讓開發人員專注於特定任務。

我的問題是關於在開始使用這個敏捷工具，創建故事和迭代之前的一個步驟，並且您的開發人員開始逐漸增加它。我的疑問是關於技術，功能和非功能軟件需求規格的步驟，所以清楚之後，您可以開始編寫故事：

http://en.wikipedia.org/wiki/Non-functional_requirement。

是否有工具可以指導您如何將web應用程序（或移動應用程序）的想法轉換爲成功方式的故事/迭代列表？某種類型的狀態，特徵或功能（及其關係）的視覺表示，您可以在其中指定功能性，非功能性和技術性規格，因此在此之後您可以創建故事？

非常感謝您的時間和耐心提前。

Answer 1

你必須在這裏改變你的思維過程。

用戶故事是日常生活中的一個或多個句子或捕獲用戶想要實現什麼終端用戶的商業語言。對於例如

作爲前臺的代表，我想很快使房間 預訂。

正如你可以看到他們是

1. 從用戶/角色（前臺代表）的角度
2. 目標導向（使房間預訂迅速）

但他們缺乏諸如各種流程（支付等），驗收標準，非功能性需求的細節（在例如故事中快速意味着什麼？）。 您可以創建子故事來提供更多詳細信息。

什麼使一個好故事？

INVEST：我 ndependent，ñ egotiable，V aluable，ē stimatable，小號商場，牛逼 estable

---

是否有工具可以指導您如何將Web應用程序（或移動應用程序）的想法轉換爲sto列表成功的方式嗎？

工具像拉力賽和JIRA允許你來組織故事，子故事，衝刺/迭代等

某種類型的狀態，特徵或功能（和它的關係）可視化表示你在哪裏可以指定功能性，非功能性和技術性規格，所以在此之後您可以創建故事？

這些工具提供了豐富的文本編輯器，可以幫助我們編寫故事。有時候，你有不適合作爲一個故事

• 用例
• 用戶界面指導原則
• 的業務規則等

然後寫別的東西名單的要求。像JIRA這樣的工具爲附件提供條款。

那麼你可以創建故事？

**故事應該是應該發生的第一個活動。這是整個觀點。這不是後來的想法。故事是迫使你從用戶和目標角度思考的方式，所以你正在編寫軟件來實現用戶目標。 **

故事代表需求，它們不記錄它們。 - 雷切爾 戴維斯

---

敏捷方法鼓勵剛夠建築與持續重構。

衝刺交付團隊通常包括業務分析師，測試人員，架構師，dba，開發人員等所有必要的股東。他們共同負責故事/衝刺的完成，並且在春季結束時，您將擁有一個可立即投入生產的應用程序。想法是逐步添加功能。

正如你可以從團隊組成中看到的，建築師/領導也參與每個衝刺。他在團隊的幫助下將爲當前sprint /迭代的一部分故事（Just enough architecture,Emergent Design）設計和設計。他們爲第一次衝刺選擇的故事要麼是高風險，要麼是具有重要建築意義的故事。

當涉及到設計，主要是頭腦風暴和紙或黑板爲基礎。理念是儘可能多地使用代碼作爲參考文檔，並通過結對編程等方式在整個團隊中建立集體知識。

所以，你最終不會得到質量差的軟件。實際上，您將擁有可以鍛鍊這些故事的最低代碼基數（您不會爲將來的需求積累代碼基礎，也不需要具備功能）。在某處我讀到，只有40％的功能是由客戶使用的。