jessewth's blog: 2018/12

2018/12/07

常用 Git Command

### Initialization ``` git clone git@bitbucket.org:jessewth/xxxxx.deployment.git git flow init -f -d git remote add upstream git@bitbucket.org:xxxxxi/nineyi.deployment.git ``` ### Remove remote branch ``` git push origin --delete feature/develop_release feature/master_for_release ``` ### Clean branch cache ``` git remote prune origin git fetch --prune ``` reference: [Git: Remove information on branches that were deleted on origin](https://makandracards.com/makandra/6739-git-remove-information-on-branches-that-were-deleted-on-origin) ### Git tag https://git-scm.com/book/en/v2/Git-Basics-Tagging ### 還原到未修改前的狀態 ``` git reset --hard ``` ### 還原到未修改前的狀態及刪除未 commit 的新檔 ``` git clean -fd ``` ##3 用 command line 看 git log ``` git log --oneline --decorate --all --graph ``` 為了方便使用, 把上述 command 加入 alias, 命名為 git tree, 下次要用的時候, 直接打 git tree 即可 ``` git config --global alias.tree "log --oneline --decorate --all --graph" ``` ### 回復單一個檔案的變更 ``` git checkout HEAD -- ../../ConnectionStrings.config ``` ### Git log search keyword ``` git log -g --grep="vsts28270" ```

2018/12/06

Agile Tour Taipei - 2018 心得

Section 1. 如果重來, 我會這樣導入持續測試

什麼是持續測試?

持續測試是一個過程, 它將自動化測試放進軟體開發之中, 不斷的反覆進行, 以期儘早的業務風險的回饋。
ref: 持续测试与自动化测试的区别是什么？

Automation Test 不是敏捷導入所要做的第一件事

應該先改 Test Flow
縮短回饋時間 Lead time, cycle time
了解流程全貎

在產品設計時就提供實例化規格

Why?

因為每個人對文字的理解力不同
幫助每個人了解求

How?

Example for Spec.
PM/PO/Team 的訓練

讓 User 做測試

這一點是有趣的地方,提到利用金絲雀部署 -> Monitor (建立指標) -> Feedback --> Fix

與其卡在 QA 出不去, 不如讓使用者幫忙測試
金絲雀部署, 5% 的 user 也比整個 QA Team 還多
沒人用的功能, 錯了也沒人知道

用原生的測試框架

測試人員的技術與 Develop 重疊, 彼此能有正向的聯結 (減少 solio)

ATDD

對 Develop Team 的技術及能力要求很高, 不容易做到
目標先不對準 Live Documents, 而是做好 acceptance criteria

Git Branch Flow

Git Flow 的問題是 Long-lived branches, 不利整合
用 tunk branch 可以強迫團隊合併持續整合
導入樂高建構法, 寫完什麼就 commit 什麼, Feature 如果不要發, 就藏在 debug mode 裡

持續測試的週期

<–需求–|--產品設計–|--開發–|--測試–|--監控結果–|--維護–>

需求階段: 測試人員參與討論
產品設計階段: 一起寫 user story, 用 example spec.
開發階段: 與 Developer 用共同語言的測試框架
測試階段: 自動化測試
監控結果: 建立監控指標, 每次發佈都有指標可以比較
維護階段: 建立回饋機制

Section 2. 從工程角度, 挖出產品風險

讓團隊了解指標的意義

先視覺化業務的結果 (report, dashboard 像1111一樣)
建立指標 (了解 dashboard 上的數字高低對系統的意義是什麼)

平常時不監控, 事情發生就無感
做這些事的過程:

經驗流程化 -> 流程工具化 -> 主動發現問題

不要指望明星球員

明星球員離職對團隊影響大
明星球員在場, 團隊會依賴明星球員, 團隊不會成長

我想的是: 如果讓每個人都是備選的明星球員, 隨時都能補位?

吃狗食

自己的東西自己測試

QA 角色定位是指出測試不足之處, 不是幫 Developer 寫測試 code

流程導入的建議

了解大家不用的原因
把門檻降低
大家願意之後, 刻意練習
同步大家的水平, 減少不必要的紛爭

Section 3. Agile UX

設計帶來改變

設計用來協助解決 Fuzzy Problem ===> Innovative Solutions

1. Mind the Gap 全區思考, 留意間隙

有意識的留意 Gap

Business vs User
MVP vs Holistic UX

MVP 也要是 end to end 的體驗
如何消除 Gap?

同理心之旅
溝通要二方都被尊重, 在對意見投票時, 留給 Stakeholder 較大的決策權, 避免被霸凌

辦 Workshop 的方式

為什麼辦?
對象是誰?
辦了之後, 可能會有什麼問題?

辦 Workshop 要成功的關鍵在前期規劃

2. Run with Brian 謀定而後動, 知止而有得

Discover & Define (Sprint 0, 用來探索)
Design & Deliver, 設計與開發像麻花捲, 前後 sprint 滾

3. Close the Loop 反覆打磨, 止於至善

持續得到回饋(讓外部 user 持續來用)
Real retro

jessewth's blog