agile

Speaker: odd-e 柴叔(柴鋒) (P.S. 本文演講消化後心得，加入部分我自己觀點) 歷史脈絡 開發、維運，分分合合 柴叔從開發歷史的脈絡娓娓道來，從服務或應用簡單的年代，開發（Development)與維運(Operation)可以一起包辦，但隨著複雜度的提高，逐漸將開發（Development) 與維運(Operation)獨立成兩個團隊。久而久之，雙方的溝通本成增加，合作程度低下，最終造成總體效能下降(開發與測試的關聯，但這邊不詳細敘述)。人們開始思考需要一個穿針引線的角色，他/她需打通開發與維運流程，增進溝通效率，共同協作完成任務，目前當紅的 DevOps的一種解釋。 你以為過去沒有 DevOps? 在遠古開發時代(?)，沒有 Docker 或 Ansible 這類工具。但別忘了其實底層絕大多數的工作，都可以用 shell script 完成，可見 shell script 這類基本功有多重要。時代在改變，但要完成的工作並沒有改變，大多是變複雜，解決問題的觀念類似。 再者，microservice 這類型的觀念，其實也早在 Unix 哲學(Unix philosophy)中被提及，差異是在不同系統層級實作( Do One Thing and Do It Well. 可以對照到 microservice)，當代有更方便工具，抽象化細節與簡化操作流程。 框架工具之於觀念 工具只是溝通工具，而不是溝通的本身 舉例：Jenkins只是CI的工具，CI的關鍵是CI觀念本身，不管用任何方式達成都好 框架工具之於基本功 框架不會幫你解決產品的問題，幾乎與你的產品無關 基礎不紮實，只花時間在學習框架或工具，遭遇的狀況牽扯底層或基本面，也是無法處理 舉例：Java 工程師 v.s Ops 維運工程師 上圖比較 Java 工程師與 Ops 工程師的技能對照，一目了然自己缺少哪個技能。一般前段或後端工程師的 skill set 從 bottom-up 到 top-down 大家都很清楚，但提到 DevOps 大家似乎被 Top-down 工具給迷惑住了！這算是一張check list，提醒自己是否還缺少哪個部分。...

序言 User Story 不只是一張卡片，是說故事與溝通需求的載體 從這篇文章得到 此篇是 User Story 實戰篇的階議題 心得 有使用過 User Story 經驗的人，能夠討論出真實問題，彼此切磋，討論氣氛活絡 (有一點像是 Planning Poker 分享大會) Alway observe and find bottleneck in team ( or system or problem ) 經常思考事情的dependency與前置準備，在真正要動工的時候，把需要的資源都在手上 What is User Story ? User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability,> usually a user or customer of the system. from Mountain Goat Software 另一個定義 A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement. from TechTarget Mountain Goat Software, User Stories TechTarget, User Story 簡短需求小卡( Card ) 交談 ( Conversation ) 確認 ( Confirmation ) 特性 作為基底、high level 注重在價值 不要 帶入 Spec. 或 過多功能描述 在其中 (會限制 Solution的可能性) ...

序言 找到缺少的拼圖就是Impact Mapping 你將可以從這篇文章得到 開發產品簡易全貌 (著重需求探索) 影響地圖 Impact Mapping 概念與操作 探訪基礎 敏捷概述 敏捷開發的精神，可以由最就代表性 “敏捷宣言” 說起，原文如下： We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Source: Manifesto for Agile Software Development 核心精神： 自主管理 持續改進 我自己的理解是： 以人的出發思考，每個人願意發表想法、當面溝通比起工具、方法論，更能深入問題的根本(因為軟體是人在開發) 軟體是我們打造的產品，產品本身品質(可讀性、可測試性)，可以更根本解決問題，因為維護文件也是成本 回歸人的本質，客戶也是人，溝通合作，取得共識，取得雙贏。最為合作底謝的合約白紙黑字必須要有， 但互相合作更為愉快。(有點類似道德和法律的感覺) 最後，接受現實，計畫永遠敢不上變化，用開放的態度適時做出調整。 ...

Fail Fast─為什麼閃退是好事 (Undone) Speaker: 雷亞 Co-founder 楊善詠 挑戰 技術人才培育 跨平台架構 事實上是救火雷亞 員工人數遽增 2011 , 16人 2016, >100人 死亡行軍：規格變更 Reference: SE系統工程師 種下惡因？ 效能問題？ 為了方便？用最簡單方式測試 BUG？ 自己的BUG自己修？那別人的呢？ 來自game engine 的問題 無法修正問題？ => “改變規格”，讓玩家看不到 遊戲前端很難測試 可能的解法 避開錯誤（X） => 盡可能提早發現錯誤 => fail fast 簡單Example Defensive Programming 防禦性程式設計(避免software crash為目的） 接到 null 是正常的現象嗎？ 淺在造成bug，卻可能造成無法找出問題 ** NullPointerException ** Debug assert Check input value ( use assertion too!) Add up the diagnosis info for future...

關鍵因素 人 環境(core) 文化(core) 方法 工具 How to Open? 工廠 vs 創意 product-driven customer-driven 敏捷的文化 增進彼此之間的溝通 多一點『引導』，少一點『管理』 用團隊取代英雄 管理：高階領導必須要思考是『如何在讓每一個人在環境中發揮實力』 常見的方式 scrum kanban water-fall PM 為溝通的角色 溝通 應用對方可以理解的話語，把訊息傳達進去 如何建立人與人的連結？ 持之以行的舉辦 讓彼此知道彼此 如何提升資訊透明度 目標清楚 過程 成果; 成果狀態(白板) ，即是 kanban 自動化測試使工作有效 Jenkins