個人軟體過程3 需求分析

來源:互聯網
上載者:User

   一間私募基金,希望開發軟體實現他們自己的一種分析思路,這是一個小項目,我們隱去他們的分析思路,僅就行情更新和顯示K線圖這部分內容作為具體的例子,示範需求分析、階段劃分、任務劃分、問題和Bug處理、原始碼版本管理的全過程。這個項目由我個人承擔全部工作,三個月的業餘時間完成,本系列描述的是前兩個月的工作內容。

     我們首先需要確定項目的目標。簡單的表述為:查看股票的K線圖。這意味著我們需要每天更新當天的股市行情、除權除息資料,同時能夠按照他們習慣的方式繪製K線圖。    

     第二步則是列出功能清單: 所謂需求,是圍繞著項目目標來定的。 既然要分析股票的走勢,那麼股票每天交易的行情資料,顯然要儲存,所以有“更新日線”,而除權除息,會影響到收盤價和成交量,為了讓行情變化更精確,需要匯入兩個市場的權息資料。這些東西未必是使用者能單方面寫好交給你的。使用者能夠解釋清楚他做這個項目的意圖,你能夠理解,最終用上面簡單的文字表達,使用者能夠認可,這就是需求分析的過程。

     我們也要注意一點,項目目標和功能清單是使用者要看的,必須使用使用者的語言,不要有任何電腦專業的術語。我們的思考是在"要做什麼“的層次,而不是”怎麼去做"的層次,所以這個過程中完全不需要做技術細節方面的考量。

     同時,功能這個詞,有許多別名:用例、使用者故事、情景、使用者情境等等,各自都號稱自己有所不同。但我的看法是,你能夠輕鬆的告訴使用者,“我們已經完成了三項功能”,但你不能對使用者這麼說“我們完成了三項使用者情境”,聽起來真的挺二的。作為專案經理很多年,我在團隊中強調最多的,不是那些不靠譜的勤奮、專心之類的東西,而是“要說人話,不要說鬼話”。再複雜的東西,有辦法用大白話給多數人講清楚,這就說明你自己是真明白了。

    每項功能,請大家注意文法:動賓結構,大致是“做”“什麼”。比如“更新”是動詞,更新什麼,更新日線。主謂賓大家是知道的,這裡忽略了“誰”來做什麼,這個主語。比如查看K線圖,一些程式員很容易寫成“產生K線圖”,這裡的區別是立場問題,查看是使用者在查看,產生是機器在產生。功能的名稱應該體現使用者要做的事情,站在使用者的角度思考,而不是機器或者程式員要做什麼。

    不要試圖在需求中列出所有的業務細節,我的理解,需求更側重於闡述使用者目標,“他們希望幹什麼”,而不是“怎麼幹”,文字工作才不會太多。許多大公司動不動幾百頁的文字,我很懷疑使用者和程式員是否有精力去看,那隻是招投標的形式主義罷了。至於“怎麼幹”,在下一節我用“更新日線”這項功能具體來說明,如何用較少的文字清晰的說清楚“怎麼幹”。

   功能清單的順序和大小比較重要,我們按照先做什麼後做什麼這樣的方式列出功能清單。那麼順序如何確定?一般的原則是"使用者能儘快看到結果",其次的原則是"高風險優先"。比如正常的排列,我們應該先用類比資料實現"顯示K線圖"功能,然後更新日線,然後處理複權。不過慮到對VC完全沒有接觸過,更新日線這項功能涉及到介面處理體系、檔案操作、資料庫操作、多線程編程等多個方面的內容,覆蓋的知識範圍更廣,從學習VC編程的角度來說,更為合適。所以我按照更新日線、查看K線圖、複權這樣的順序來排列。對於功能相對大小的評估,我們可以看到,複權應該是最簡單的,定為2,更新日線大約需要2倍的時間,定為4。查看K線圖也定為4,至於單位,有的體系叫做故事點、情景點或者理想工作時,無所謂,我們只需要一個大概的工作量評估。功能清單簡單的羅列如下:

     1、更新日線 4

     2、查看K線圖 4

     3、複權 2

 

    第三步,評估風險因素:

     1、因為要做成案頭系統,基金成員各自的電腦作業系統不一,同時這個項目是海量計算的項目,所以最好的選擇是使用VC開發。這個我從來沒用過,需要在項目過程中邊學邊做。這也是很有意思的事情,多年前我的母校,武漢大學,電腦編程入門的課程是Pascal,老師當時還給大家解釋Basic是如何不肖、用C語言入門如何不好,然後李衛華教授因為自己以人工智慧為主要的研究領域,給我們開了Lisp和Prolog兩門課程,出來工作後,主要用foxpro做過應用、然後是turbo Pascal,即使是組合語言也玩弄得精熟(因為當時無聊的去分析漢化Dos的原始碼),然後從.net平台推出開始,就一直停留下Asp.net和Wpf,整個職業經曆居然與程式設計語言熱門排行榜中的頭兩位無緣:java和C++。

     2、時間和人員方面:因為公司技術人員忙於另外一個企業專案,出於對證券行業的興趣,接下這個項目。我本人大約每天能夠有3到5個小時的時間、周六周日的部分時間。

      簡單的說:用從來沒有用過的語言,在從未接觸過的領域,花費三個月的業餘時間,完成具有相當演算法複雜性的項目。

      當然最後的結果肯定是皆大歡喜的,否則我不會拿出來顯擺。這也說明興趣和自信對工作效率的影響,你喜歡做的事情,必然會全力投入。至於VC,傳說中複雜的C++文法、需要多少年才能精通的MFC,在我看來也就是窗戶紙罷了-----對於類似MFC這類東西,我一向的原則是,你完全沒必要學會製造電視、製造裡面的每一塊電路板,你只要會使用電視就行了,能有多複雜?至於文法,有C#的底子,反過來C++估計也不會困難。

     風險因素是列給Team Dev看的,對項目的時間安排是有意義的。當然,也是和使用者在價格、時間方面討價還價的依據。比如上述風險因素中,你沒有用過VC是不能說的,否則使用者很可能懷疑你能否勝任。自動劃分趨勢的複雜性可以強調,這樣有助於在不能如期完成時,預先找到拖延的借口。所以風險因素羅列如下:

     1、VC完全沒有接觸過

     2、人員和時間不足。

 

    第四步,劃分階段

    我們按照功能清單的順序、每項功能的相對大小、風險這三個方面的考慮,來劃分階段,每個階段為四周的時間,要"徹底實現"羅列的功能,這也是Scrum、Rup之類過程同樣注重的反覆式開發法、小版本發布的觀念。簡單的說:這個階段完成的功能,通常就是使用者最後見到的樣子,傷其十指不如斷其一指。之所以稱作"階段"而不是"迭代",這也是考慮到和使用者交流方面的問題,仍然是那個原則:說人話。

    那麼第一個階段,我們實現第一項功能;第二個階段,我們實現第2、3兩項功能。

     對於工期緊張的項目,我一般以兩周為一個階段來安排時間。這個項目因為是業餘時間工作,同時VC的學習有著不可預測的因素,因此按照每個階段四周時間安排。

 

    最後略微總結一下:通過和使用者約兩個小時的交流,我們知道了使用者啟動這個項目的目標,列出了功能清單,並用簡單的文字描述,取得使用者的認可。然後工作兩個小時,列出風險因素、劃分階段。接下來我們將為第一個階段第一項功能,劃分開發工作單位、提出問題,這個過程大約也需要2小時左右。也就是說,對於這類小型項目,專案經理大約在一個工作日之內,就能夠做好前期準備工作,第二天每個開發人員都能夠在Team Fundation Server中看到自己的工作任務。即使是比較複雜的項目,這個過程也不用太長時間,我的極限是一周,任何情況下,從使用者決定啟動項目開始,最多一周之內Team Dev的程式員就應該能夠開始工作。

    接下來的一節,我們將介紹第一項功能的概要說明、使用者體驗設計和任務劃分。

 

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.