PHPConf.tw 2016 Day 1

# PHPConf.tw 2016 Day 1 ## Note Curators: * [Afu Tseng](https://www.facebook.com/afutseng) * [Ray Chang](https://www.facebook.com/ray20204) * [陳政謙](https://www.facebook.com/profile.php?id=100000356577940) * [蘇永哲](https://www.facebook.com/profile.php?id=100001497054617) ---- ## More Than Code - Become a Better Developer Josh Lockhart * 經常被問如何成為一位資深的 PHP 工程師 * 他覺得有些事比 Code 更值得分享我分享一些生涯中比程式碼更重要的經驗給你希望有幫助我寫了一本書 Modern PHP Slim Framework ; 微框架可以打造小型 API、service 其它框架例如 Symfony, Codeigniter Ruby, Sinatra Slim v3 可以更容易與 ZendFramework 整合 PHP The Right Way 你應該看看有許多社群分享的資訊關於 Testing 你可以關注像是 PHPUnit 之父的分享為什麼要聽我分享？ 2000 年開始學 PHP 2003 Freelance 2007 join NMC 2011 Slim Framework Today Author & Team Leader 但今天我不太談 PHP 你可以參考這些我的著作：Modern PHP、PHP The Right Way 我要談談關於你 - 開發者你有經驗、書籍、時間我常聽到的問題是：我如何成為資深開發者？知識？也許？也許是年齡？也許是職稱頭銜？我不知道但我可以分享一些幫助我成為資深開發者的課題一、PHP is only a tool - 只是個工具二、Work smart, not hard 三、People are your best asset - 你的團隊是你最好的資產四、Keept it simple - 五、Share your knowledge - 分享你的知識 ## Lesson 1 - Use the right tool for the job * Do not devote yourself to a single PHP framework - 不要只投注心力在單一特定框架 * One size dot NOT fit all 單一規模的框架無法應付所有需求如果你只想要打造一個小東西，可以試試看 Slim 這類微框架 different tool to different jobs 選對的工具應用於對的工作 * Macro frameworks * Micro frameworks * Indiviual components ## PHP is only one language * PHP may not be the best language for the job * Bash may be easier and faster for repetitive or async tasks * PHP can run one the CLI with STDIN, STDOUT, STDERR # Lesson 2 - Don't reinvernt the wheel - 不要重造輪子 * Do not be afraid of "off-the-shelf" solutions * Headless CMS makes a graat CRUD dashboard 沒有 UI 的 CMS 讓你能容易打造很棒的 CRUD 管理後台 Drupal, 匯出 JSON 給前端網站運用 * Search Packagist for PHP components I DO NOT work because I love PHP I work to make money so I can 9am - 5pm Maintain a work / life balance ## I do not know everthing * i dont't always have the answer. Many in this audience know more than me * Humility is an important trait * I don't know is a valid answer * as a senior developer, your job is to facilty ... ## Delegate when appropriate - use your team 適當的把任務委派給你的團隊成員 * take advantage of your team's specialization. regardless of seniority or job title. * Improve efficiency by using team's comparative adventage * Give new/junior team members investment in the project ## Avoid burnout - Trust your team 避免職業倦怠，要相信你的團隊 * Open source is exhausting and time consuming * i was nearing burnout working on the Slim Framework. * I trusted SLim developemnt to Andrew Smith and ooo * Trust your team. your are only one person # Lesson 3: Give Praise A little bit goes a LONG way! Do not punish mistakes 別懲罰錯誤 Anticipate them and learn from them 它們犯錯是預期的，從中學習較重要 ## Encourage good practices 鼓勵良好的 coding 實踐 * Lead by example 以身作則給好的範例 * PSR 1 and PSR2 follow coding style * Gradually increase enforcement with CI tools * weekly team demos It is NOT obvious (Obviously) ## Support continuous learning - 支持持續學習 * Encourage your team to always learn something new. * Books, conferences, user group sponsorship * Nomad PHP use group 找找這個社群，他在世界各地許多地方都有辦 Welcome feedback There is always room for improvement Write simple code Easy to understand and debug choosing tool 1. Boring 2. Predictable 3. Reliable use boring & reliable for client projects use new & shiny for internal projects ## "Don't Let Architecture Astronauts Scare You" By Joel Spoisky * Start simple * Do not abstract, optimize, or scale until they are needed 別過早抽象化、最佳化或延展，直到它們真的需要 * Do you need design patterns? ## Docker or Vagrant? Developement at NMC * Docker changes too quicky * Docker is difficult to manage in ## Capistrano * at NMC, 我們用 Capistrano 管理 deployment * 他是一個老的 Ruby 工具, 透過 SSH 指令 * 堪用 * 容易學習 * 簡單可靠可復原 * ``` git commit git push origin master cap staging deploy ``` # Lesson 5 - Share your knowldge ## With your team 幫助你的同事進步 indivi.. Nomadphp twitter ``` You will never find the perfect Sr. Dev for your proj. You can however, hire a Jr and train them to be the perfect Sr. Dev. :) ``` https://twitter.com/nomadphp/status/783720937464197120 twitter @codeguy Do you need to extract ... sed -n '101p;203p;300p' < input > output ``` Do you need to extract certain lines from a text file? To get lines 101, 203, adn 300: sed -n '101p;203p;300p' < input.csv > output.csv ``` https://twitter.com/codeguy/status/785476315570905089 ## With Open Source So. remember! 1. PHP is only a tool 2. Work smart, not hard 3. welcome always always feedback 4 保持簡單 5 分享知識 ## Lately in PHP(Unit) Sebastian Bergmann 德國人 38 歲 26 年前開始寫程式跟其他兩人一起開公司 thePHP.cc 最近寫了一本書 PHP7explained.com € 39.00 (~$1300 TWD) DISCOUNT: PHPCONF2016 PHPUnit 3.7 於 2012/09 釋出第一個可以被 Composer 安裝的版本 PHPUnit 4 於 2014/03 釋出第一個不再提供 PEAR 套件的版本 PHPUNIT 釋出流程 1. follow SEMVER (major.minor.patch) 2. 每兩個月釋出新功能 PHPUnit 4.8 support in PHP 5.3+ PHPUnit 4.8 不支援 PHP7 PHPUnit 5 於 2015/10 釋出 * 支援 PHP 5.6, PHP 7+ ## 四個在 PHP 7 的主要變更 * refactoring * cleanup * performance * type system PHP 7 變革快速理解 * Executor：速度快、記憶體耗用少 * 編譯器：產出更好的 bytecode * Parser: 目前基於抽象語法樹 (AST) * Lexer: context-sensitive lexer perf stat php7-binary ../phpunit blahblahba PHPUnit 有 450k 個測試案例、710k 個斷言, no I/o - 無檔案讀寫速度改良顯著 ## 幾個業界升級 PHP7 的 case study * https://twitter.com/andygrunwald/status/735515546033262592 * techblog.baddo.com ## Backward Compatibility Breaks UNIFORM VARIABLE SYNTAX 差異對照： PHP 5 v.s PHP 7 $$foo['bar']['baz'] blah blah blah 請不要這樣寫（雙錢號語法）如果看某段code超過10秒鐘無法理解，代表你該刪除它。 ## PHP 7 新的保留字略 PHP 7 被棄用的功能 * ext/mysql - use mysqli instead of * ext/ereg - use preg_* instead of * PHP 4 風格建構子 * preg_replace (/e) modifier ## PHP 7 的 FATAL ERROR 可以被 try catch 捕捉 PHP 7 的 type-hint 支援 scalar (string, int, float, etc.) PHP 7 嚴格模式 ``` declare(strict_types=1); ``` 啟用後，傳入的 scalar 如果型別不對就會噴 FATAL ERROR PHP 7 return type declaration 可標明function return的資料型態 PHP 7 Null coalescing operator example: ``` $username = $_GET['user'] ?? 'nobody'; ``` 與下面是一樣的 ``` $username = isset($_GET['user']) ? $_GET['user'] : 'nobody'; ``` 即有$_GET['user']的話就取值，沒有就回傳??後面的值。 PHP 5: 97.2% PHP 7: 1.7% 數據來源：https://w3techs.com/technologies/details/pl-php/all/all PHPUnit 5.1 於 2015/12 釋出 PHPUnit 5.2 於 2016/02 釋出 PHPUnit 5.2: 測試例外 * 以前要用 annotation 的方式測 (寫在註解) * 現在提供 expectExeception() 測例外 https://thephp.cc/news/2016/02/questioning-phpunit-best-practices ## new warnings * 如果對一個 mock class 模擬一個實體類別不存在的 method, 會丟警告 ## forward compatibility layer PHPUnit\Framework\TestCase is now an alias for PHPUnit_Framework_TestCase ## PHPUnit 5.4 createMock() ``` $this->createMock(Foo::class); ``` 等效於以前的 ``` $this->getMockBuilder(Foo::class) ->disable() ... .. ->getMock() ``` PHPUnit5.5 2016/08 release partialMock PHPUnit5.6 2016/10 release ## PHP 7.1: VOID RETURN TYPE ``` fucntion m(): void { return 'foo'; } ``` FATAL ERROR! ## PHP 7.1 nullable types ``` function f (?int $x) { } ``` f(null) // ok f(1) // ok f() // 爆炸 return type也可以為nullable type，ex: ``` function answer(): ?int { return null; //ok } function answer(): ?int { return 42; // ok } function answer(): ?int { return new stdclass(); // error } ``` ## PHP 7.1 ITERABLE super-type ## PHP 7.1: catch multiple exception types ``` try { ... } catch (FooExcepton|BarException $e) { ... } ``` PHP 7.1: async signal 處理 ``` <?php pcntl_signal( SIGALRM, function () { ...}, true ); ``` ## PHPUnit 對 PHP 5.6 的支援只到 2016 年底 ##PHPUnit 5.7 的支援只到 2018/02 ---- # Rebuild flyingV with Laravel ## 講者資訊 Karl flyingV 擔任技術長 flyingV 為台灣最大群眾募資平台 ## 內容 Envoyer為Laravel官方做deployment用的。 ### 公司產品 flingV --> 早期用Java的play framework做，後來打掉重練，變成Laravel vEvent --> 建立活動，讓大家參加活動的服務 vDeomocracy --> 為社運做的網站，學運之後沒在維護，沒再上架。 vSHOP --> 購物平台，已收掉 vStory --> 用wordpress做，最大問題，他的資料庫很雜亂，要直接從資料庫取資料不容易。工具: Corcel ### 伺服器架構以前伺服器架構主要在AWS上面，很貴。搬離AWS，目前伺服器架構在linode上，原因: 便宜用Laravel的seeder來搬資料庫。使用chunk匯入可以避免記憶體炸掉 Capistrano用ruby寫的自動化從Jenkins移到GitLab的CI上，原因: 覺得Jenkins設定複雜。用rollbar來做error monitoring Matryoshka是一個可以幫view logic提供Russian-Doll caching的laravel的package flyingV 幾乎所有的專案都是Laravel 用php7，效能好很多從memcache轉到redis上 ---- # 使用 Slim 為 Legacy Code 重構 [Slide](https://docs.google.com/presentation/d/1k8YKDHQb6cO_zOWdo0JW3-JP7Z5TjTSl9h_n1ItYMp4/) ## Speaker * Miles * 104 人力銀行 ## Intro * 大家最怕巴格王 * 開發人員效率越來越差 * 各種創意堆疊 * 改A壞B一直發生 * 開發人員：「老闆，我想重構... 」老闆：「功能先上！」 Legacy code：沒有測試的程式目標：為重構想一個方法用健康的心態面對問題 * 舊系統需要維護 * 就算重寫也需要理解 * 不管技術上再怎麼糟，在商模上，它是有價值的 * 重構或多或少會有副作用 * 重複回報，開發人員的羞恥心作祟會把程式越修越好 * 技術債必須要還 * 還法通常需要時間，極端的就是砍掉重寫 * 要嘛一次還（砍掉重練），要嘛慢慢還（慢慢重構） * 放下各自成見一起解決問題 ## 開始講重構概念參考 [Nginx Blog](https://www.nginx.com/?p=28286) * 單體式架構如何重構成微服務 * 單體式架構如同 Legacy code 難以變動 * 單體式架構不要再加入新程式 * 先用 route 處理 legacy code * 完成重構後轉向新的 route Client -> legacy code 類似 Proxy pattern > Miles: 會覺得是 Proxy Pattern 是因為 Router 預期的行為 (interface)，會跟 Legacy code 的行為一樣，我個人覺得這跟 Proxy Pattern 的 UML 比較像 ### Reference - from 12 Factors 參考 [The Twelve-Factor App: 1. Codebase](https://12factor.net/codebase) * 多個 branch deploy 到多種類型機器 (或多種環境) ### Reference - from Martin Fowler 參考 [FeatureToggle](http://martinfowler.com/bliki/FeatureToggle.html) ### Latest Summary * 新功能盡量不要寫在 legacy code * 實作 proxy patttern * bracnh 太多可以改用 feature toggle，避免 merge 時太多衝突 * 程式碼放在同個 branch 使用 feature toggle 切換 Client -> Proxy -> Legacy Code Test -> -> Refactoring 1.Test -> Proxy -> Legacy Code 2.Test -> Proxy -> Refactoring 3.Client -> Proxy -> Refactoring 4.remove Legacy Code, Proxy ## 實務作法 ### Process 1. 準備環境 2. Composer 3. Testing 4. Refactoring 5. Removing legacy code ### 準備環境 * 困難的原因是「找到依賴，並重現」，例如 MySQL, Redis, Memcached * 推薦用 Docker 解決問題，因為實務上常遇到多 DB、多個 service * 但 Docker 跑在 Windows 不太順利，可以再配合 Vagrant #### DB 遷移工具 * [Phinx](https://phinx.org/) * [Propel](http://propelorm.org/) * [Doctrine](http://www.doctrine-project.org/) #### Route setting * NGINX * Apache .htaccess ### Composer * composer init * composer require slim/slim 利用 Slim routing 載入 legacy code (require SomeOldFile.php) ZF (或其他有 entrypoint 的 framework ) 也可以這樣使用 ### 測試我個人最推的就是 [Codeception](http://codeception.com/) * 提供 BDD 風格的 e2e test 範例 ```php // 我是驗收測試人員 $I = new AcceptanceTester($scenario); // 我想要測管理頁面順便測登入功能 $I->wantTo('test admin page and test login'); // 我打開了管理頁面 $I->amOnPage('/admin'); // 我看到了 Password 的字 $I->see('Password'); // 我把我的密碼填入 input field $I->fillField('password', '0000'); // 我按下登入 $I->click('登入'); // 我看到登出的字 $I->see('Logout'); ``` 若有測 JS 的需求就改搭配 Selenium (預設是 PhpBrowser) > Miles: 我對前端不熟，我記得 JS 會產生 DOM ，這些是 PHPBrowser 測不到的，所以需要有能 run JS 的 driver 如 Selenium ## CI server * [GitlabCI](https://about.gitlab.com/gitlab-ci/) * [CircleCI](https://circleci.com/) * [TravisCI](https://travis-ci.org/) ## Refactoring * TDD 三循環: 紅綠重構 ## feature toggle 實作方式： usage 1 ``` $toggle = false; define('ENABLE_REFACTORING', $toggle); ENABLE_REFACTORING and $app->get( routing ) { ... } ``` usage 2 ``` $toggle = getenv('enable_refactoring'); ``` ``` // print something true AND print('true line'); // do nothing false AND print('true line'); ``` ## Deploys review * Slim + Legacy Code 執行環境 (production) * Test + Slim + Legacy Code 執行環境 (development) * CI server 執行環境 (testing) ## CI 要領即早整合即早發現與治療很久才 merge 一次的話容易採到多個問題不容易追到根源 > Miles: 我後來忘了說「用 feature toggle 的好處？」，我覺得它可以強迫提早整合。當然這是雙面刃，但 feature toggle 跟 Git 的用法都很自由，大家都可以針對自己的需求去做調整，只是要記得 CI 「即早發現即早治療」的概念是不變的。 ## 優點導入後可以用 Composer，例如用 monolog 、等等套件 PSR 4 autoloading, etc. 導入後開始寫測試，實踐 CI ## 缺點 * 環境建置困難 * 這是應該要做的任務 * 開發、維運與業務團隊配合困難 * ... * 效能因為多一層 proxy 而受影響 * 考慮用 phalcon 等 C extension 寫的框架快快樂樂重構平平安安上線 thanks ---- # Refactoring to Collections - 從陣列重構談物件導向程式設計 ## 講者資訊閃亮亮 KKbox 工程師 ## 演講重點如何把PHP寫得跟SQL一樣簡潔好懂 ## 程式碼簡潔易讀重點我不想知道我不需要的事情，在PHP上使用OOP實作封裝+抽象化物件的基礎：資料 + 行為 -> 職責利用closure來封裝可多多利用Laravel的map, filter，使得程式碼便簡潔(也可使用php的array_map, array_filter) 使用Collection和OOP-Fluent style composer require illuminate/support ---- # Test or Not Test, That's the question. ## 講者資訊 * Recca * 已開發出數個知名的 Laravel Package，包括：Laravel Tracy、Laravel Terminal、Laravel Payum 及 PHP 版 twzipcode ## 全程 live coding .. XD # 用 Laravel + Vue.js 打造即時資訊看板 ## 講者資訊大澤木小鐵 KKbox工程師 ## 內容網頁即時資訊的定義: 系統資料更新時，不用重整頁面就可以獲得更新的資料 ###即時資訊的做法它戳你你戳它它戳你一分鐘或數秒鐘去戳api(當然要帶api token) 用Laravel的queue和jobs Queue driver使用redis 你戳它以google calendar為例 ### pub/sub機制如何將資料傳給客戶？ * 你訂閱，我推播 Laravel本身不支援pub/sub機制有提供Pusher可使用，但是要$$$$ 有什麼不要錢的? Redis pub/sub server + laravel echo server Laravel-echo-server適用node寫的套件，故要用npm安裝 laravel-echo-server init 會要你輸入server的host名稱 port預設6001，但是可以改會問你要用什麼db ---- # 敏捷估算模型-變化當下最佳化策略以燃盡圖舉例如何在有限時間內講完投影片 ## 以 Michael Wolfe 在 QUora 撰寫的走路的故事作為開場 http://blog.jobbole.com/45756/ 走了兩小時後... 變化 * 有沙子、海水、海獅速率時程延至下下週日走了十二小時後變化無法正常休息第二天睡過頭工時今天只能先走10小時明天再走14小時承諾還在控制範圍內不用改期士氣無奈幾個小時候變化腳鈕到須花費45分鐘繞到村莊治療速率 (24 英哩 x) 今天只走六英哩承諾還是不必說趕路要緊士氣狀態逃避現實第三天變化風路、此路不通速率 (24 x) 找路繞路迷路兩次大半天只前進一英哩工時決定不睡覺走到大半夜承諾不再打電話士氣燃燒生命第四天變化過度加班的返效果速率 (24 英哩 x) 完全無法行動今天進度為 0 第五天重新檢視進度速率四天只走40英哩一天只有10英哩範圍 (400英哩) 至少 600 英哩時程原本的時程太天真保守要七十天提議只要一天16小時舊可補進度第六天士氣沉沒最後團隊成員就會跳槽 ## 你的預估永遠都是不準的實務上怎麼幹？ * buffer * 灌水 * 乘以三或多少其實就是灌水你會灌水 PM 就會砍你所有的預估都是在畫芭樂票預估就是用你個人的經驗去猜預估跟推估是不一樣的推估是用一些科學根據的方法去推算預估通常都找資深的來判斷其它的層級就跟著乘拳王泰森每個人都有一個計畫直到他被貓了一全就沒用 ## 講師簡介 * 暱稱 91 * 東森信息科技 * 開過 TDD 課 * 微軟 MVP * 寫過書 ASP.NET、敏捷開發實踐今天要講兩個重點第一個重點相對估算 Dog point 第二個重點估算模型（範圍 = 速度 x 時間) 好的估算方式：SPA 三大特徵 1. Simple 簡單 2. Pulic 公開 3. Agreeable 共識 ## 如何避免有人老媽突然早產 * 來來哩來 * 然後他老嗎就早產了 When: 決定誰做之前就估算 ## 如何避免 PM 剝削 ## 如何避免 RD 灌水 Who: 做事的人一起估 Team - 8.0 / 7.5 / 5.5 / 10.0 PM 大家一起估就有開會成本、溝通成本所以估算方法要簡單 ### 雞跟豬的故事雞跟豬說我們來賣火腿蛋三明治吧雞只要生蛋豬卻要割肉豬當然不要啊！ ## SPA 範例 - Dog Point * 吉娃娃 * 問現場牠有多大？會得到很多答案不大 30cm 很小 28.5cm 估算牠是不容易的換個問法哪一支狗比較大？吉娃娃 v.s. 哈士奇一旦兩隻放一起比你要知道哪個比較大是簡單的這個基本概念就叫做 **相關估算** 我不管你有多大我只管他是他的幾倍大 ## 準則一相關比較比絕對估算簡單大家想折一架紙飛機你要多久時間做？大家通常不會超過 30 分鐘合理吧？可是一架戰鬥機你要做多久？通常誤差就會很大而且不知道從何估起哪一個估算你比較有信心老闆問，怎麼答？ 1分鐘？兩年？為什麼？因為兩年後你還會不會在不知道！正常人都覺得一分鐘比較準 ## 準則二粒度小比粒度大精準你看到了什麼？ * 石頭很大 * 縫隙很大 1. 容器=資源 2. 石頭=任務 3. ? (沒記到) 怎麼減少浪費？挪資源 ## why dog point * 遊戲是最好的學習方式 * 簡單公開共識 * planning poker 得陌生感 ## Dog Point 練習 ### part 1 排大小由左至右夠簡單吧？比較大的狗放右邊 ## 排大小每個人輪流 pm 除外一次移動一張狗的圖片吉娃娃在最左邊右邊得狗要比左邊得大可挪動既存得狗圖片右邊仍要比較大該狗無法比較時請放到最右邊覺得不需要調整時可以 pass ## Roles 四個人 peter 是 PO ## Dog Cards Peter 先把吉娃娃放上來 Alice 問這一支臘腸狗幾歲？回：三歲成犬我覺得臘腸狗比吉娃娃大 Bob 我覺得西施犬比臘腸狗大 cindy: 是一支還兩隻？是兩隻大單 cindy: 光一支就比其他的大了 David 西施只是毛長應該比臘腸小 ok 每個人都有權力去決定順序主持人很重要有可能每個人吵不停當今天每個人都 ALL PASS 就進入下一階段 ## PART 2 排數字 1 2 5 8 13 吉娃娃為 1 按照狗大小比例每個人放一張撲克牌可以挪動既有的撲克牌 ## why 費氏數列 0 0.5 1 2 3 5 8 13 20 40 100 ? 實際估算我們會抓出來團隊假設四個人一起估我覺得這個任務是吉娃娃三倍大他覺得五倍他覺得五倍他覺得十三最小的是三最大的是十三兩者差兩倍以上合理嘛 OK 所以請兩個人說出為什麼會差兩倍以上例如我比較菜他比較熟這是一種另外一種是資訊落差我知道什麼細節但他不知道團隊在討論過程中會發掘很多你不知道得東西或他不知道得東西例如有個 open source project, plugin 所以他估算的時間短不管誰做我們都獲得資訊你的資訊才會透通也有可能是這些人都很天真例如申請憑證機器所以我的假設是這樣才會估這麼大他可能把 code review, automate testing 都算進去了但其它人沒有就我的經驗沒有第四輪以上的可是我希望每個人的想法都被尊重 e.g. 我是菜鳥耶所以我估 13 不需要因為別人來改變就算倒楣估算最多的你最後真的領到任務你也知道要去找誰求助例如估算最短的人一支大單應該有二十被了兩隻就是四十被 ## PART 3 定義吉娃娃假設一要花 0.5 小時二大概就是一小時 ... 以此類推把全部的狗加完就得出推估時間這個叫推估重點永遠不是放在準不準相關估算 recap SPA 三特徵估算兩準則 * 相對比較定義吉娃娃是什麼 ## why 相對估算 NBA 一場打多久一場比賽有四節一節12分鐘每節休息5分鐘 60秒暫停中場20分鐘 ... ## 一場比賽約2小時 - 因為經驗法則 ## 實際教訓 - 士氣殺手？ ### 一天只估四小時？一開始沒經驗大家達成共識一天只估四小時就好工程師覺得開心 PM 覺得有點賭懶老闆不開心這件事情發生在最一開始的時候大家要磨和有插件要研究很多東西要溝通原本估要做 200 story point 結果兩週後只做了 105 個 story point 沒有人說得出為什麼影響評估範圍速率時程三循環 ## 面對變化你為 PO 做了什麼？一旦你推 PM 去死，PM 就讓你去死因為你沒有提供足夠的資訊給 PM 他就只能非 0 即 1 他就只能 fit 老闆的需求 PM 有足夠的資訊才能保護 team 爸我想當工程師喔那你先做100人份的餅乾為什麼？我一個人怎麼做？這應該很簡單吧二十分鐘要搞定時間也太短了吧！還有不要餅乾了改蛋糕你還剩下5分鐘要求也變化太多了吧！兒子啊我看妳不是當工程師的料 ## 插件 ## 可能有時程調整 * 1/1 要上我們不能落後在這邊否則就是妳的問題需求異動作法異動 * 本來打算用磚頭蓋房子最後用倒草蓋人員異動軟體業的特色你沒有辦法阻止這個事情發生實際成果 2015 Q1 Q2 * 只剩一半的人 4 -> 2 * 一位三月離職 * 一位五月離職六個月完成八個月的專案插件兩個月專案其中一個專案提前一個月上線其它專案準時上線不加班 code coverage > 75% 時時 review 調整決策持續改善不是廢話嘛？我們來這邊聽一小時範圍 = 180 pts 怎麼來？我們用 t-shit size 去估轉換成 story points 因為 pm/po 根本就不懂怎麼做所以他估不出來所以他需要簡單方式讓他自己比較出來分成 S L M 三種大小讓團隊挑 S = 10 個 pts 之類的數字基準設定經過試驗後 blabhalh 時程 = 3 sprints 不是 run 了敏捷就沒有時程這件事假設 1 sprint = 2 week 期望速率 = 60 共 180 pts 斜率 180 / 3 = 60 ## 速率是測量出來的不是估算你一定要有實際數字不是算芭樂票用上次完成的數字參考來算你的資料越多他會越來越準假設實際速率=50 代表你要延後到 6/24 改 due date 實際要花 3.6 sprints 預估時程 = 3 sprints 推估 = 3.6 當你希望時程不變你只能修正範圍團隊的開發能量就是那樣不會一夜加速經過 Spkie 試驗後 L 為 40 ,M 為 20, S 為 10 PM 說不行這個某功能很重要一定要在某時間點內做完這時候他就有足夠資訊來做優先權如果沒有足夠資訊他就會跟你說都很重要都要在時間內做完 e.g. 出貨跑檔可以先做嘛？可以多給我兩天再砍其它的假設你是 po / team lead 有個案子需求你們要花多少時間只有你講得出來就是妳做得不錯老闆期望佑可以插件佑不影響時程 ## 友善提醒要快要便宜要好是不可能的怎麼辦呢？加班這張圖講技術債會變怎麼辦加快斜率就可以那塊面積就是技術債如果沒清掉未來加班就會更多開快車分兩種拼得過快兩分鐘回家拼不過晚七天回家個人經驗治標- 檢視優先權有些東西真的沒那麼重要一開始估就是 7-11跟全家都要做哪個重要？都很重要！預計做六個月有個計畫插件所以決定先做全家延後 7-11 優先權六月做完之後 7-11沒做因為在其它專案的優先權比較之下他就沒那麼重要了所謂的優先權會不斷改變的他會隨著時間空間變化如果你一開始不管他就先做他就是浪費所以為什麼軟體有很多功能都沒啥用治標 - 調整作法鋼鐵人例子你要評估 must have 是什麼只有挺你的 PO 讓他可以交差才有談判籌碼治標 - 有計劃的欠債覺得不能有技術債 - 初階專業的工程人員是有計畫的欠債還得掉經驗是拆兩段 must have, nice have 專業的價值在於有計劃性的欠債治標 - MVP 做車子 NOT LIKE THIS (X) 先做輪子 .... blah LIKE THIS (O) 先做滑板車再做腳踏車 .. 機車汽車對老闆來講商業價值完全不一樣三天就拿到一版可以 work 的很重要的概念, 十三天的專案第五天可以第一版就可以賺錢如果第五天發現做了一個垃圾後面就不用做了所以啊我還沒有做到這台車子過！是因為我有更多的前面 (滑板車/腳踏車) 要做！治標 - 提昇硬體效能與人員士氣與其找顧問還不如升級工程師的硬碟為 SSD (舉例) 治本 - 持續改善循環是持續 review 設 check point 持續的取得 feedback 持續的改善比較空泛一點最後做個 demo 我可以再五分鐘吧？ ## Esxxx model T-shirt size 的平均 story points 持續更新: 加權平均數 PBI 推估範圍交給我這個團隊做大概要多久多少時間就算不準 , PO 也比較好跟老闆吵平均 Velocity 平均 sprint 產出 79 123 98 ... ## 範圍時程速率的三維度推估第一條 - 延長時程第二條 - 縮減範圍如果老闆還是要走第三條調整類型 - 增加生產力記得跟他說加人力是沒有用的記得孕婦的故事吧介紹 excel 表格示範被要求一定要完成某幾個功能需要多加幾天 ## 最後用一個三角形來 recap 速率 -> 持續改善優先權 MVP 範圍時程很多東西都是可以調整的範圍最糟糕的是 PO 無法取捨或是他只是個 302 PM 老闆講什麼就喂 ... blahbalh .. ## 都不能談就只能欠債最糟糕的就是加班你要他加班他隔天就請假了因為他壞掉了人不是機器結論依據變化調整決策 > 艾森豪的名言：“Planning is everything. Plans are nothing!” ### 補充 - 團隊轉型方針我們通常不用改變這個字眼我們在意的只有改善 * 改善 > 改變 * 演進 > 革命 * 做好 > 做完 * 自動 > 手動 * 實務上最有價值的叫做半自動 * 溝通 > 文件 * 團隊 > 個人 * 沒有個人英雄 * 成效 > 規範 ## 總歸就是兩句話：持續改善、自主管理補充 sprint commitment 有人預計請假開會生病失戀電腦壞掉 ## 今天的分享不是讓你估準而是至少不要用猜的 ## Q & A Q: 時程跟 MVP 可以多講一些嘛？ A: 時程通常都是最難僑的因為有可能是對外記者會發表會等那怕只是 workaound 讓他看起來是正常的區分哪些東西是 demo 過程中一定用的到的你會聽到敏捷講到一些名詞例如延遲最佳化還是有最佳化 MVP 不是永遠交付個爛貨你要去橋例如多給我三天我可以多給你什麼東西只要到非不得已你才要以卡借卡也就是欠技術債