1.溝通
前期專案需求的溝通可以叫作無紙化辦公,因為客戶不太懂軟體,銷售人員需求獲取不明確
我極力推薦他使用故事方式與我溝通,即使用者故事 user story
拿這個樣板的進銷存系統與客戶對接,這樣的話,使用者大多的反應可能是這樣的:
"嗯嗯,這個功能對"
,"嗯嗯,我們也有這個型別的資料"...等等
銷售或者售前再繼續跟客戶對接比較具象具體的內容.
如你們具體都需要哪些資料管理,大概流程是怎樣的.有什麼特別需要注意的地方.
如果客戶那邊有完整的需求,就不用這些問題了,而是直接拿需求回來即可.
將需求確立下來,比較穩妥的方式是在客戶那邊有相關計算機專業或是對軟體有很長時間使用話語權的人對接,這樣會節省將近200%的時間有木有?
接下來銷售/售前經理需要跟公司對接需求以及具體情況,**之類的不在本篇詳述.
需求評審,大家開個會,是什麼具體需求,用到哪些技術,能不能實現,實現難度大不大?等等,總之就是幾個字 ----
能不能做
確定能做之後,開始分析需求->確認人員->確定任務->**實現->測試交付
很難想象,客戶每次基本都不按自己說的需求來,儘管簽了合同,通知了再加功能可是收費的哦,
其還是沒有覺悟,兀自增加功能或者原功能的調整.那麼整個需求從我們專案初期就要做好打算,我們要持續迭代更新了.
與傳統軟體開發的計畫驅動不同,敏捷開發模型需要的是價值驅動,價值的提交.每個可執行版本就是乙個小的程式精品.
而作為使用者方面,其不確定性的需求導致其從使用者角色變為"使用產品及反饋意見的客戶".而這裡的使用產品,並不是說我們這次
**裡面的alert或者console,或者system.out不刪除,我們的宗旨是每個交付版本即時我們預料的最終版本.只有這樣,才能做到最好.
如上圖所示,傳統開發模式瀑布模式,是要從需求,整個設計文件,一套標準化下來.
敏捷就比較敏捷了,他是每次都給到客戶乙個可執行的版本,之後按新的需求,按照投資的增加,或者技術的發展對整個軟體程式進行更新迭代.
那麼在把"需求","產品計畫","開發計畫","迭代計畫"(還有其它的不一一枚舉了)都制定好之後,我們做的就是將軟體進行持續的迭代測試部署就好了.
2.開發
開發是以打**為主,在產品總監經理pm將產品需求跟專案經理溝通後,專案經理再將整個的開發流程計畫進行部署安排.
常見的專案管理工具有禪道,阿里云云效,ones.ai等.
每個人員適合做什麼,怎麼做,大概會做得如何,這點在團隊中的專案老大是要必須清楚的.
在業務還需要梳理以及人員之間要進行配合時需要進行有效的溝通.
有效溝通包括,當面溝通,文件傳送,以及示意.
在人類的大腦中,在古代原始社會就有了一些圖形圖案記錄人們打獵的場地,部落的規矩等等.
開發伴隨著**的提交,問題的檢出,最終進行程式的測試部署,在測試與開發設計文件進行對比測試後,方可轉由其它人員進行與客戶的交付對接.
而在敏捷開發模型中,這僅僅是剛開始.
3.迭代
這裡的迭代,有的是功能的加強,有的是新的需求,有的是對程式需求完全(差不多)確定後,對程式整體的優化.
迭代有時是固有客戶,那麼迭代的方向一般由客戶決定.
而自有產品一般需要團隊,公司/企業方向來決定.
至於有些更加穩固的系統/產品那麼迭代可能來說就是某部分某功能的更新.
一般在敏捷中,我當時看有位大牛的線上講座,分為3個階段:
階段1:客戶需要什麼我們做什麼
--->即了解客戶需求,將客戶想法及思路用最小可執行版本進行原型製作.
階段2:與客戶溝通,同客戶做朋友,了解真正程式需要
--->即使客戶可能知道大概自己想要什麼系統/程式/軟體,那麼肯定還有他想不到的地方,與其溝通,看看是否可以進行相應的改善.
如果客戶那邊有比本埠團隊更優秀的產品經理,ui設計師,使用者習慣優化的相關人員,那麼可能他們的自己的需求就是最穩妥的.
階段3:需求最終確立,版本最終成型
--->這個版本一般可以看作真正的里程碑,那麼這個版本之後,如果還有其它變動,一般都是基於原有模型來進行更新,
而如果你新增了二手車的銷售板塊及功能,那麼可以說是一次較為大的版本更新.
剛看到印象筆記又進行了空間的版本更新,在我所知道的程式軟體中,印象筆記算是更新最快的了.
每次更新出來的有時只是小的變動,而有時像使用者空間這樣,是比較新穎的功能模組.
4.覆盤
進行整體回顧,哪些開發或需求對接環境有待提高,在以上三個環節中**容易出現紕漏,用什麼辦法可以有效避免.
技術上的改進在**,
管理上的改進在**,
通過這次的開發任務獲得了哪些好的收益,
在團隊提公升,人員技術,還是公司/企業的知名度方面.
通過這次產品發布里程碑的節點上,對使用者市場及銷量的**,是否準確.
等等,也就是說,覆盤是對乙個已有系統/軟體/程式的打分及評價.
就像好的品牌,可能買一件產品後還會買第二件,使用者好評也會5星.
謝謝
敏捷開發概述
敏捷開發是一種以人為核心 迭代 循序漸進的開發方法。在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和 可執行的特徵。換言之，就是把乙個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。敏捷建模 agile modeli...
敏捷開發基本思想
敏捷開發是由一些業界專家針對一些企業現狀提出了一些讓軟體開發團隊具有快速工作 響應變化能力的價值觀和原則，並於2001初成立了敏捷聯盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，他們認為 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 ...
敏捷開發基本要素
1.敏捷是 乙個 過程 敏捷不是乙個過程，是一類過程的統稱，它們有乙個共性，就是符合敏捷價值觀，遵循敏捷的原則。敏捷的價值觀如下 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過 遵循計畫 由價值觀引出的12條敏捷原則 我們最優先要做的是通...