AngryTask - 基於僞 scrum 的我的項目開發產品

關於

去年年底的時候同事分享了一下 scrum 工做模型, 之後公司按照這種方式來執行產品開發.
聯想本身在阿里的兩年的工做方式和大學課程講述的項目協同敏捷開發的一些知識.
因此本文想就開發工做流模型作一個簡單的探討, 並將 scrum 模型應用到 我的項目開發中的作一個嘗試性產品 AngryTask 的討論.

誰優誰劣是僞命題，解決問題纔是王道

當在進行這種討論的時候, 總會陷入討論孰優孰劣的結局, 大學裏邊的課程給人的結論就是敏捷開發碾壓瀑布流, 但到實際工做的時候發現其實忽略了上下文條件.

什麼樣的公司

1. 技術外包公司

2. 傳統IT企業

3. 互聯網公司

4. 創業公司

5. 我的開發者

不一樣公司對產品開發模式和對產品的需求相差很大, 所謂有人的地方就有江湖, 真實環境的開發實質是圍繞不一樣的利益在討論.

• 技術外包的公司目的是知足客戶需求, 因此對客戶必須以瀑布的方式, 需求就是合同

• 傳統 IT 企業, 老闆纔是開發的客戶, 不錯出能知足需求的產品纔是核心價值

• 對互聯網公司和創業公司來講要求的就是快速迭代

• 我的開發者須要錢, 須要實現理想, 須要完成一些工具也差別很大

什麼樣的團隊

1. 技術人員佔比大團隊

2. 產品人員佔比大團隊

3. 我的開發

不一樣人員結構的團隊致使不一樣的協做方式, 有可能老闆主導, 產品主導, 設計主導, 開發主導. 工做協做方式也會由於主導的人發生變化.

什麼樣的產品

1. 視覺爲主

2. 銷售爲主

3. 後臺程序

4. 2B 產品

5. 2C 產品

開發核心價值是

1. 時間爲主

2. 質量爲主

3. 須要用戶參與反饋的迭代開發

沒有哪一種開發模型可以知足這些條件, 因此不談場景只談模式都是扯淡, 在真實開發環境中生產高質量高效率的產品必須找到適合本身的 pattern .

scrum 工做模型

scrum wiki

嚴格上的 scrum 是比較嚴肅的, 設計人限定了不少規則, 如:

1. product backlog 的每一個需求都是一個基於用戶場景的用例或者用戶故事

2. 角色設定, 強調自我組織, 分爲 "豬"組(產品負責人, scrum 主管, 5-9名全棧開發人員), "雞"組(用戶, 利益相關者, 經理)

3. 每日站立會議

對於團隊來講, 大可能是應用僞 scrum 到團隊中, 沒有嚴格的遵循標準 scrum 的規則.

說說做爲我的開發者的問題

幾乎每一個 coder 的某個文件夾裏邊都放着一些本身的我的項目, 可是大多數項目爛尾而終止, 緣由不少如:

1. 有新的更棒的 idea , 興趣轉移

2. 工做上加班變多, 無力分心來開發我的項目

3. 情緒左右着項目的投入時間, 每月總有那麼幾天

4. 被某一個問題卡死, 陷入細節, 太複製
   ....

能成功的完成的項目而且推向終端用戶的產品是極少數的, 這些我的開發者要麼是極度有經驗, 要麼是頗有毅力, 要麼是小團隊做戰.

因此可否也將我的項目像團隊項目同樣標準化, 經過某種工做模式讓我的項目可以持續的投入並最終產出推向市場?

不要太聰明, 像豬同樣笨的執行

我的項目沒能完成每每不是由於開發者技術能力作不到, 不夠聰明, 也不是由於項目 idea 不夠好, 最主要的緣由是由於開發者太"聰明", 對於公司的項目咱們可以即使不加班的狀況, 即使討厭的狀況, 也可以順利完成, 由於有人要求咱們去執行並完成上線. 因此總的來講就是我的約束沒作到位

下面這張圖是我根據 PPT 裏邊 scrum 的介紹畫的

若是我的開發者也以這種工做方式來開展的話, 是否是就能解決問題了呢?

AngryTask - 爲我的項目開發而生的任務管理工具

這也是我爲何要作如今的這個項目, 並用它來約束自身開發, 我取了一個不太好聽的名字 叫 AngryTask

先上個正面圖

固然如今正在開發中, 尚未正式推出來, 先把話放在這裏, 我會用上面的工做方式應用到這個產品的開發中, 並將這種開發模式整合到產品中 .....

轉載自個人博客： http://6174.github.io/articles/scrum.html