# Agile Tour 2020 learning point ###### tags: `Agile Tour-2020`, `Agile` >以下內容是本次Agile Tour所學習到的重點,不過只有我上到的部分,做個分享因為有很多課是在同時段但在不同Track ## 擦傷學習精神: - 強調在實作中修正錯誤和學習 這位講師很強調實作,他以目前他開發的歐洲訂票的APP做舉例,歐洲有太多鐵路的大公司,各自都有APP,但其實太少接觸實際客戶的需求,各自的APP彼此之間只會提供自己的資訊,**但對使用者來說,重要的是他可能想法國巴黎到義大利的米蘭。** 因此他認為這些,或許直接當公司的客服,或者從APP的反饋反而就更快能蒐集到這些資訊。 因此他提供了整合這些列車資訊的APP,滿足了使用者這個服務,目前也不斷地deliver蒐集著客戶的反饋資訊。 - 內捲化 他本身也是Aglie coach,但也有相當多豐富的實務經驗,但他看到現在太多人有一些各種的**certificate**,因為這些機構都會提出他們的等級階梯,而這些人一直往上爬,但卻漸漸的被這些方法綁得太深,反而無法跳脫,也太少接觸或者離實際面太遠。 因此他建議大家,不要過度的依賴這個東西,有certificate也要搭配實際的經驗,這樣才有更加分的效果。 EX:其中一個舉例,有一位對輪胎非常了解的專家,但當輪胎壞了他卻不會換輪胎。 - 乾貨問題 現在代人很喜歡看這些乾貨,意思是專家們幫你濃縮的精華,初期對初學者確實有快速大幅度的成長,但到一定的程度時,你就會停住,因為讀完這些東西仍只有紙上談兵,是無法發現或徹底理解這些專家所遇到的問題的。 - 不求甚解 雖然以現代的用法多為貶義,但以陶淵明當年的文義,應非貶義。指的是看全貌,不糾結於其中每個字每個字的詳細意思。 >講師認為你能抓住不同知識的重點,並將其拚湊出一些方法去實作,但也並非說當你需要技能時就可以什麼都不學。 **書讀百遍 其義自見** :::info 擦傷學習法的重點,就是很講求實作,這樣你能從中發現各種困難,並且你會在你有需要時,去找出方法去解決問題。 ::: ## Outcome-driven development 狀況: 某個專案可能又收到新的需求,已經有很多backlog items,那我該怎麼做了?從Quality, Time, Cost分析: | 犧牲的項目 | 作法 | 結果 | |--------- | --------- | -------------- | | Cost | 增加人 | 只會讓時間變更長 | | Time | 延長時間 | 趕不上市場需求 | | Quality | 開發完就好 | 不測了 | :::danger 綜合分析都無解,是不是可能是源頭就錯了?** ::: ## 把Requirement 換成 Opportunities 講師認為需求這個字換成機會對整個團隊會合適,**我們現在有了這些機會,哪些是我們現在做的會有什麼樣的效益**,而且寫成需求,其實需求字面上會讓人覺得應該是很明確的東西,但實際上往往不是如此。 ## Ehnance development work with PPO key concept ### Discovery & Learn - analyze opportunity and create hypothesis - Conduct Test to learn/validate - :star: Fast & Cheap Tests :star: 1. Interview 2. Paper prototype 3. Prototype with fake data 4. **Prototype with real data !!!** 5. Implementation and Release?  >從這裡分析後,才決定是否要放到Backlog。 >並且透過Discovery & Learn明確找出"Safe Zone" and "Stupid Zone" >**這個概念我認為有發揮了Aglie的精神,為了不想跟Waterfall一樣,要到最後deliver才一翻兩瞪眼,何不在初期要投入時,就使用這種方式逐步的試水溫,保持在SAFE ZONE。** ### think about a "smaller" step, and also considered the bias. :bulb:There's a Common Pattern to follow to help as tell it's a bias or a fact? - Do people have a problem? - Do they want our solution? - Can we build it? - Can they use(see) it ? - Will they keep using it, adapt it, say good things about it?  >如果認為假資料的prototype就直接跳到要實作導入這段仍太過大歩的話,仍然可以再將中間切入一個小的step,以降低結果不符預期的風險 ## 固定成本之下,如何選擇要優化的項目? 狀況:講師的團隊面臨要更新內部的大型系統,但需求非常的多,因此要將這些需求整理,去篩選出這些重要的部份放進backlog裡 - 真正的使用者發聲 - 向end-user收集痛點清單:將近 400 個痛點。 - 辦workshop初步訪問需求:確認需求是stakeholder/end user真正需要的。 - 價值排序,成本框定 - PO(Product Owner) 定義需求的價值 - 量化因子(e.g. 痛點數、重要性、急迫性) - 專業評估(交由BU評估、需求商業價值排序) - 大主管和PO挺身協調歧見 :::warning :question:**面臨的問題** 1. 如何對不同單位的人、不同的思維,**有效溝通**? 2. 如何盡可能貼近大家的需求? ::: **面對不同的使用者,是無法全部透過文字溝通進行的,肯定會弄得很混亂? 那怎麼辦呢?** - 功能畫面 - 面對面、具像化(儘量不要透過文件溝通。用視覺化、可操作的畫面來溝通) - Paper Proto => Prototype, PowerPoint - 業務流程 - 面對面、具像化 - 簡化版VSM:五個步驟引導。重點不是精美,而是能夠用共同的語言具象化出流程,並標出痛點。 - 重點不是畫押背書,而是確切了解需求。 - :star: IT 的工作是引導 BU 把真正的流程、需求說出來 :star: - 提煉出業務流程   >這個講師的團隊,也採舉了類似的作法,避免在團隊開發了,或是已經開發了一部份的prototype出來,才發現這個結果與真正的user想像上差距很遠,因此他們也先畫出了紙本版的prototype來解決這樣的問題,目的都是不希望到最後又面臨了需求上的改變,所帶來的衝擊。 ### 講師所認為的敏捷 - 真正的使用者發聲(要有人用、能賺錢) - 有效溝通 - 自訂團隊遊戲規則:譬如讓團隊都知道如何處理「插件」。 - 透明 :arrow_right: 信任 :arrow_right: 當責與自管理 - 因為是大家的共同看見,所以大家能夠一起遵守和信任。 - 檢視、調整 :arrow_right: 回應變化 - 團隊之間不應該是敵對,而要互相反應與調適。 - 解決問題的心態 >**其中透明,檢視,調整**,**也符合Agile的3個核心精神**,透明的進度,定期的檢視狀況,並對當前的狀況作相對應的調整與變化。 ## Start small, Learn fast 另一位講師,在歐洲銀行開發產品其中也提到他們的一些作法 * How we can deliver faster ? * Smaller scope * What can be removed ? * Deliver key value * How can we go live quicker ? * Feature toggle: 有哪些功能要給 end user 用?還是等更穩定一點再開放。 * Continuous delivery * How to reduce effort? * Automation ## Data driven 有些事情有沒有效,在開發時確實不容易知道,怎麼樣能佐證? 透過數據來反映事實。 * 讓數據說話 * A / B Testing * Netflix案例 * 首頁註冊畫面的Case * 影片封面圖的Case 這兩個Case,都是希望提出與原先不同的做法,希望能達到更好的效果,但是在沒有做出來實際run,根本沒有人說得準哪個好。 在首頁的Case,Netflix,就曾經做了2版的首頁,並透過A/B Testing來分析數據,來來回回了5次,最後發現原版本比較好。 >為了讓後續的版本,使用一個正確且有效的結果,因此使用A/B testing,並且經過了統計分析,再將有效的結果release到產品中。 影片封面圖也是,他們試過了多次A/B testing,發現了一些用戶的習慣,與偏好。 - 用戶喜歡複雜的比情  - 各國的用戶喜好不同 因不同的文化背景,儘管是同一部影集,各國的用戶的喜好也不同 - 少即是多 雖然很多用戶都是透過電視螢幕來觀賞Netflix,但也有不少是透過智能手機等螢幕較小的裝置來觀看,Netflix 認為「少即是多」的設計原能吸引用戶的注意力。  >以上是這次在Agile Tour學習到的一些重點,將其整理出來分享給大家,其實這些課程裡面討論的都不會是Scrum或Aglie的流程,而是講師認定學員都懂這些東西,並將他們實際的應用case做分享,他們是怎麼用到這些Agile的精神的,希望我的這個整理分享,對Agile有興趣的你能提供一些啟發。
×
Sign in
Email
Password
Forgot password
or
By clicking below, you agree to our
terms of service
.
Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
New to HackMD?
Sign up