1、如何看待aspice
aspice 幾乎涵蓋了軟件開發的方方面面，在軟件開發過程中，有疑惑的地方都可以去aspice里去尋找靈感。對于初創公司，應該以人為本。結合人的長處，來發揮每個人的主動性和熱情，而不必因崗招人。aspice 中要求輸出很多工作產品，也就是文檔。把握不好就成了形式主義。我對待這些的態度，就是注重實際作用。比如系統需求文檔。可以后期補文檔，那基本上就屬于形式主義，最多有個備忘的作用了。做任何事情都是有成本的，任何事情只有收益大于成本才值得去做。
2、aspice的價值
那么有一個文檔，為什么值得我們投入精力呢？我主要看中一下幾點：切實為下一個階段的工作提供輸入，下一階段工作以此為輸入開展工作，就讓工作有章法可循。比如系統需求為軟件需求提供輸入。顯性明確隱藏在各人腦海中的想法，把內容寫下來，為討論交流，提供一個基線。各利益相關方可以以此討論，達成共識的會確定下來，以此減少對共識部分的重復討論，將注意力集中在尚待解決的部分。文檔還起到追溯到作用，這就要求變更時，保證是從源頭開始變更。只有清晰的需求，才能盡量減少由于討論不足帶來的盲目變更。變更就是成本。文檔應該方便以后迅速回憶起當時工作的一些信息，起到備份工作成果的作用。文檔一定不是目的，文檔的目的一定要是方便內外部溝通、減少重復和浪費、減少歧義、減少因溝通不徹底帶來的浪費，并且可以基于不同時間持續推進一件事情。如果文檔不能帶來收益，那就需要調整記錄文檔的方式。
沒有工具支撐下的探索
工欲善其事，必先利其器。沒有工具支撐，很多事情就會淪為最原始的低效模式。結合目前行業在用的jira等工具，我有意探索如何更好的貫徹一些理念，并且有一些自身的認識。很多小公司或者個人，傾向于口頭分配任務或溝通的的方式，這是因為簡單，也就是最原始的方式，人人生而得之，這種方式沒有太多探索的價值，受制于以下方面：1.重復溝通現象多，意味著重復部分是浪費；2.口頭說完，往往遺忘，重要的事情無法被跟蹤和追溯，無法為全局的狀況提供查看視角。3.有分歧，事情的推進變得困難。溝通記錄往往是開辟道路的有效手段，達成共識的部分可以在文檔中逐漸積累。但是口頭溝通，就會存在信息同步和遺忘，理解歧義等帶來的成本。4.口頭溝通，無法固化有價值的工作成果，也就無法有效重用以往優秀的成果。5.口頭溝通應該配合有價值的記錄，當然，這依然是最原始的方式。6.口頭溝通，也應以終為始，正如寫文檔，在寫之前，就應該有文檔最終的樣子，應該要給誰看，想表現出什么，怎么樣更好的呈現。
3、aspice實踐
我在實踐中，結合jira和借鑒互聯網敏捷開發的經驗。將一級需求作為epic，二級需求作為story。這兩個層次的需求，從PRD中拆分而來，在描述中，指明對應章節。期間與產品經理反復溝通，達到什么目的，做到什么樣子。
互聯網團隊的feature 作為epic，function作為story，我們在需求拆分時的顆粒度，以及工作的實質（指具體開發該功能還是集成供應商的代碼）對需求結構化的顆粒度做了適當的調整，以在達到追溯目的和追溯的成本之間取得平衡。在二級需求之下，我們開發團隊結合軟件架構文檔，在每個需求之下，創建RTM subtask，將完成某個需求的工作，拆分成多個便于開發執行的任務。測試團隊，在二級需求之下建測試的任務，這個任務對應軟件集成測試。二級需求可能分不到不同的開發模塊。這里其實和aspice 軟件需求由軟件集成測試來測并雙向可追溯有些對應關系。做這些期望達成的目的：
-
從需求拆分到任務拆分，可以由上自下拆分，并結合由下自上發現需求的遺漏。由上自下，提起來，可以從需求提到各個任務，像一顆倒置的樹
-
jira 需求可以對應到prd，產品經理可以追溯，開發人員可以順著這棵樹向上追溯到prd
-
需求變更，可以順著樹，來傳遞影響。變更需要在jira上發起變更申請，以追溯
-
開發者的任務一目了然，開發的節奏以此來把控，實事求是，以最小成本來做最大成果
-
開發者的工作透明化，讓管理者知道大家做的成果，避免開發者做了許多，管理者一無所知的情況。
-
讓開發過程更順暢，有規可循，減少浪費。
-
更關注做正確的事，“要做對的事”
轉載汽車電子相關文章
轉自汽車電子與軟件
