最近翻到一篇文章, 在討論如何變身敏捷企業, 這是由 Scrum 發明人和 竹內弘高 Hirotaka Takeuchi 所寫的文章.
他講述了許多敏捷觀念和誤解, 但是最吸引我的是最後一個表格, 講述什麼狀況合適使用敏捷, 什麼狀況不合適使用.
- Sep 30 Sun 2018 22:13
不適合使用敏捷的世界 ...
- Sep 18 Tue 2018 18:00
寫不寫文件? 要寫又該寫多少呢?
撰寫文件是件人人討厭, 但是沒有時又很痛苦的事. 那我們該怎樣處理呢?
首先, 在討論處理方法前, 可以思考這個現象: 他們不會看文件
TAGRI, They Ain't Gonna Read It.
- Sep 16 Sun 2018 17:24
在敏捷中如何處理需求不明確或是變動的問題
很多人對於不明確的需求, 或者需求變動, 感到十分痛苦. 在 waterfall 中這件事並沒有說明要如何處理, 因為他一旦需求文件 sign 之後, 便鎖定範圍, 之後便不允許再改了. 接下來便是靠各位經理的功力, 自己找尋方法去處理.
因此, 當 agile 出現時, 大家便很期待, 是否這就是銀製子彈, 只要一扣板機 ... 不不, 只要一旦實行 agile, 這個問題就瞬間被消滅, 是這樣嗎? 在回答 agile 如何處理之前, 必須要先各位聊聊他的原理, 要觀念正確, 才不會有錯誤期待.
敏捷並不是要做得比較快, 他是在強調有能力因應改變. 藉由頻繁回饋和改進, 及早讓不確定的部分變成確定.
- Sep 02 Sun 2018 17:51
大音希聲，大象無形的看板方法 ?
看板是一個很模糊的名詞, 不同的人對他常有不同的定義, 今天把之前分享的李小龍說看板, 拿一部份來對看板說文解字.
很多人把看板視為是 Kanban board, 更精準的說是 Scrum board, 也就是一塊白板, 上面有著 story, 以及要完成這個 story 所要進行的 task.
- Aug 29 Wed 2018 22:11
[軟體效能測試] 效能測試常見的迷思
很多人對效能測試的觀念常常不正確, 有些人認為它很單純, 有些人以為這樣做就可以了. 就讓我們來看看, 大家通常有什麼幻想 XD
迷思 1: 效能測試是在系統開發最後時候才做.
效能測試需要早期就開始規劃, 否則等到最後測試無法通過時, 往往是要修改架構才能符合需求, 這時候已經沒有時間讓你這樣的修改, 你不是裝死就交付出去, 要不然就是專案大延遲.
