Use Ubuntu Server 16.04 for Example
For C++ need build-essential, OpenGL need libgl1-mesa-dev
and install Qt 5.7 binary from PPA
sudo add-apt-repository -y ppa:beineri/opt-qt57-xenial
sudo apt update
sudo apt install -y build-essential libgl1-mesa-dev qt-latest
. "/opt/qt57/bin/qt57-env.sh"
For env setting, add bashrc command
echo . "/opt/qt57/bin/qt57-env.sh" >> .bashrc
=== Ref
Install Qt 5 on Ubuntu
https://wiki.qt.io/Install_Qt_5_on_Ubuntu
Stephan Binner
https://launchpad.net/~beineri
2016年8月29日 星期一
2016年8月6日 星期六
開發團隊 - We are Not Scrum
目前在開發團隊中,進行每日「例」會、利用便條貼整理需求,造成有人經過時會以為團隊正在進行敏捷開發,或者說我們在跑 Scrum。這時候我一定會回答,不,不是的,We are Not Scrum。
先說說目前的情況,
一、每日例會
進行於下午四點半,雖然幾乎是全員站立的,其實不是強制性,時間大概是 20~45 分鐘,目標會希望在 30 分鐘內結束,主要目的是同步資訊,無論是市場變動、系統維運狀態、需求或時程變更、系統架構說明、個人任務說明……等等。
其實上述同時也說明為什麼會進行每日例會,為了解決下例情況
# 開發成員對市場狀況不明白,不懂為何而戰
# 系統可能永遠在某些情況當掉,但是開發人員不知道
# 需求變動可能只有部份開發人員收到通知
# 新進工程師、維運、測試人員對系統不了解 (可能沒機會了解)
# 每個角色遇到的問題也許其它人可以協助,像是維運或測試人員需要工具支援
二、便條貼需求
目前的需求會寫成便條紙,單純是因為需求的優先序變化太快了,白板改來改去太累人,所以才改用便條紙的。另一方面是將除了需求之外,維運及優化問題也都寫上去,方便團隊成員全盤了解產品的狀態。
同樣整理一下便條紙需求解決什麼問題
# 需求優先序變化時,不用擦掉重寫 (尤其是字寫很醜的時候
# 將維運及優化項目列上去,可以讓成員明白有哪些技術債需償還 (尤其是主管或 PO
# 成員想到什麼想法時,可以隨手寫張便利貼上去
為什麼會說不是 Scrum (敏捷開發)
一、真的不是
# 每日「例」會,不是每日「立」會,站立不是重點,想快點結束會議才是共識
# 時間不會限制在十五分鐘內結束,需要討論的事情講完了自然會結束,沒有人喜歡開會
# 主要是資訊分享,鼓勵發言,但是不會強制每個人說三件事
# 便利貼是為了便利,不會特別貼成 Todo, In Progress, Done
二、條件不滿足
# 沒有固定 Sprint 週期,DeadLine 沒有彈性
# 開發人員所作決定得到認可,像是決定實作哪些需求、品質、上線時間
三、避免誤用
# 把 Scrum 的點數當作工時,把預估時程當作承諾
# 誤以為都不用寫文件
最後,要說明我不是在反對 Scrum,Scrum 是個好的方法,但是就好像吃藥一樣,正確的服用才能有好的成果。要先明白要解決的問題,才決定用什麼方法。我也不是反對敏捷,相反的,敏捷正是團隊的目標之一,當宣稱不是使用敏捷開發時,只是避免別人誤以為我們正在進行「某種」工作流程。
資料來源:
敏捷開發
http://wiki.mbalib.com/zh-tw/敏捷开发
敏捷軟體開發
https://zh.wikipedia.org/wiki/敏捷軟體開發
Scrum
https://zh.wikipedia.org/wiki/Scrum
先說說目前的情況,
一、每日例會
進行於下午四點半,雖然幾乎是全員站立的,其實不是強制性,時間大概是 20~45 分鐘,目標會希望在 30 分鐘內結束,主要目的是同步資訊,無論是市場變動、系統維運狀態、需求或時程變更、系統架構說明、個人任務說明……等等。
其實上述同時也說明為什麼會進行每日例會,為了解決下例情況
# 開發成員對市場狀況不明白,不懂為何而戰
# 系統可能永遠在某些情況當掉,但是開發人員不知道
# 需求變動可能只有部份開發人員收到通知
# 新進工程師、維運、測試人員對系統不了解 (可能沒機會了解)
# 每個角色遇到的問題也許其它人可以協助,像是維運或測試人員需要工具支援
二、便條貼需求
目前的需求會寫成便條紙,單純是因為需求的優先序變化太快了,白板改來改去太累人,所以才改用便條紙的。另一方面是將除了需求之外,維運及優化問題也都寫上去,方便團隊成員全盤了解產品的狀態。
同樣整理一下便條紙需求解決什麼問題
# 需求優先序變化時,不用擦掉重寫 (尤其是字寫很醜的時候
# 將維運及優化項目列上去,可以讓成員明白有哪些技術債需償還 (尤其是主管或 PO
# 成員想到什麼想法時,可以隨手寫張便利貼上去
為什麼會說不是 Scrum (敏捷開發)
一、真的不是
# 每日「例」會,不是每日「立」會,站立不是重點,想快點結束會議才是共識
# 時間不會限制在十五分鐘內結束,需要討論的事情講完了自然會結束,沒有人喜歡開會
# 主要是資訊分享,鼓勵發言,但是不會強制每個人說三件事
# 便利貼是為了便利,不會特別貼成 Todo, In Progress, Done
二、條件不滿足
# 沒有固定 Sprint 週期,DeadLine 沒有彈性
# 開發人員所作決定得到認可,像是決定實作哪些需求、品質、上線時間
三、避免誤用
# 把 Scrum 的點數當作工時,把預估時程當作承諾
# 誤以為都不用寫文件
最後,要說明我不是在反對 Scrum,Scrum 是個好的方法,但是就好像吃藥一樣,正確的服用才能有好的成果。要先明白要解決的問題,才決定用什麼方法。我也不是反對敏捷,相反的,敏捷正是團隊的目標之一,當宣稱不是使用敏捷開發時,只是避免別人誤以為我們正在進行「某種」工作流程。
資料來源:
敏捷開發
http://wiki.mbalib.com/zh-tw/敏捷开发
敏捷軟體開發
https://zh.wikipedia.org/wiki/敏捷軟體開發
Scrum
https://zh.wikipedia.org/wiki/Scrum
訂閱:
文章 (Atom)