[บันทึกเด็กข้างห้อง] เปลี่ยนรูปแบบการทำงาน ให้ Deliver OUTCOME early and often #LearningWithSCK

Disclaimer: ถ้าอ่านแล้วคิดถึงชื่อบริษัทไหนแวบขึ้นมา ก็ปล่อยผ่านมันไปนะ 555

ที่มาที่ไป: บริษัท ABC มีความตั้งใจที่อยากจะปรับ Process การทำงาน สำหรับ SCK น่าจะเป็นปีที่สาม แต่จริงๆ ABC มีความพยายามจะปรับเป็นรอบการทำงานสั้นๆ ที่เรียกว่า Sprint มาอย่างน้อยสองปีแล้ว

ซึ่ง Sprint ไม่ได้เกี่ยวอะไรกับ Agile ก่อนที่ SCK เข้ามา เป็น Sprint แบบ Waterfall คือ Testing ไม่จบในรอบ นั่นไม่ใช่ Scrum ด้วยซ้ำ หรือ Dev แล้ว Test คนละ Sprint ก็ไม่ใช่ Scrum

Agile ไม่ได้มีนัยยะอะไรเลย

ต้องการเปลี่ยนรูปแบบการทำงาน ให้ Deliver OUTCOME early and often

เทียบง่ายๆ สำหรับคนที่ต้องการเสี่ยงโชค เอาเงิน 80 บาท ให้แม่ค้าล็อตเตอรี่ กระดาษที่ได้มา 1 แผ่น เป็น OUTPUT มันจะเป็น OUTCOME ก็ต่อเมื่อ ถูกรางวัล

• สิ่งที่ PO ป้อนเข้ามา (Needs หรือ ที่อยากได้) ให้ทีมพัฒนา (โรงงาน) ได้ออกมาเป็น Features/Functions เป็น OUTPUT
• เอาขึ้น Production เป็น OUTPUT
• เอาของไปให้ User(s) ทดลองใช้ เป็น OUTPUT

จะเป็น OUTCOME ก็ต่อเมื่อ End User(s) บอกได้ว่า มันมีประโยชน์กับเขามากขึ้น (หรือบางที อาจจะแย่ลงก็ได้นะ T_T) เช่น

• ทำงานได้มากขึ้น ในเวลาเท่าเดิม จากเดิม 1 ชั่วโมง ทำได้ 3 Orders แต่พอมีโปรแกรมเรา สามารถทำได้ 5 Orders
• Error จากเดิม 0 แต่พอมีโปรแกรมเรา กลับมี Errors เป็น 2
• อ้าว แล้วจะวัดผลยังไงว่า ตกลงที่เราทำไป มันดีขึ้น หรือแย่ลง

UX มีการทำ Usability Testing แล้ว UX Lead เจอโครงการหนึ่ง ก็เจอผลจริงๆ ว่า การทำงานของผู้ใช้งานนั้นใช้เวลามากขึ้น เพราะต้องเปลี่ยนพฤติกรรม จาก Windows App → Web Browser (แต่ใดๆ ก็ตาม มีหลายอย่างที่ดีขึ้น ก็ต้องหาให้เจอ เพื่อเอามาเปรียบเทียบกันว่า ภาพรวมของ OUTCOME เป็นเช่นไร)

to reduce DELIVERY LEAD TIME to 2–3 Days

พอเห็นภาพปุ๊บ ที่เรียนกับ อ.เอส มาเมื่อสัปดาห์ที่แล้วก็ลอยวาบ ทาบทับเข้ามาในหัว

• หาให้เจอก่อนว่า จุดไหนที่ทำให้ใช้เวลานาน
• การลดเวลา คือ ลดเวลาคอย และ ตรงไหนที่เป็นการทำงานซ้ำๆ เอาคนออก ใส่เครื่องมือเข้าไปแทน
• Automation Test (เอาเครื่องมือเข้ามาแทน) จะมีประโยชน์สูงสุด เมื่อทีมทุกคนสามารถทำ Arrange ได้ Provision เครื่องตัวเองขึ้นมาได้
• Rollout and Rollback ที่เห็นส่วนมากตอนนี้ เป็น Script Auto แค่ฝั่ง Rollout (ไปข้างหน้า) ก็อย่าลืมคิดถึง Rollback กันไว้ด้วย
• Backlog = ไอเดียจากทุกคน ไม่ใช่แค่ PO แล้วดูว่า จะลงทุนทำอะไรก่อนที่มันคุ้นทุนที่สุด

การเรียง Priority มี 2 มิติ

1. PO คิดว่า ลงทุนไปแล้ว ได้ผลตอบแทนการลงทุนเท่าไหร่ ลูกค้าพอใจมากขึ้น เงินเพิ่มขึ้น หรืออื่นๆ
2. ข้อมูลในทางเทคนิค มาจากทีมพัฒนา ถ้าจะต้องทำมันขึ้นมา ต้องใช้เวลากี่ชั่วโมง กี่วัน กี่เดือน ในการสร้างมันขึ้นมา (หรืออาจจะประมาณการไม่ได้ ไม่เคยทำ ต้องขอเวลาไปศึกษาก่อน ก็บอกมา)

การ Rework ของ ในชีวิตจริง ไม่ได้มีเวลาหลักเดือนในการปรับแก้ แต่เหลือเพียงแค่หลักวัน แล้วมันก็จะทรมานจิตใจ

ตัวอย่างการบริหารจัดการ Backlog ที่พี่หนุ่มบอก คือ Cryptocurrency หรือ หวยใต้ดิน ที่มีรายการ และ การวิเคราะห์อย่างจริงจัง ลงทุนเท่าไหร่ และ “น่าจะ” ได้ผลตอบแทนเท่าไหร่

เวลาคุย ให้คุยเป็น Features

• สิ่งใหม่ที่เรากำลังจะทำ ไปกระทบโดนกับสิ่งใดที่มีอยู่ (As-is) แล้วหน้าตาที่มันจะไปโผล่อยู่ที่ใด (To-be)
• การเอา Test Scenarios มาไว้ด้วยกันตั้งแต่แรก เป็นยาขมในไทย เพราะตั้งแต่เราเรียน และทำงาน มันไม่เคยมีเรื่องพวกนี้เลย
• มันไม่ใช่เรื่องใหม่ เป็นเรื่อง REQs Engineering เป็นสิ่งที่มีมานาน ต่างประเทศมีสอน ซึ่ง REQs ไม่ได้มีแค่ Functional แต่ต้องมีเรื่องของ Non-Functional ด้วย
• ถ้า Non-Functional ไม่วางมาก่อน เวลาบึ้มทีก็สวัสดี ลาก่อน เช่น โดนยิง Server หลักร่วง ซึ่งถ้ามี Backup Server ข้อมูลสองที่ต้องเท่ากัน ทั้งตัวหลักและตัวสำรอง ถ้าข้อมูลวิ่งตลอดวัน ทำยังไงให้ข้อมูลเท่ากัน ก็แปลว่า ต้องมีการหยุดเพื่อ Sync หรือไม่ เรื่องพวกนี้ ต้องคุยกันก่อน เพราะถ้าต้องซ่อม​ ซ่อมระดับโครงสร้าง
• ตัวอย่าง Non-Functional List ที่พี่หนุ่มเปิดให้ดู เป็น Technical Design ทั้งหมด

หลังจาก Software Go-Live ไปแล้วนั้น

• การทำงานเป็น Sprint อาจไม่ได้ช่วยอะไร เพราะเราจะเจอทั้ง CR, Incident, Support Production ใดๆ
• Incident ส่วนมาก มันต้องแก้เสร็จภายในหลักชั่วโมง
• พอขึ้นไปแล้ว ให้เริ่มเก็บว่า CR หรือ Incident อะไรมีมากกว่ากัน

ใน Product Backlog Refinement ที่ SCK พาทำ

และได้ออกมาเป็น User Stories ในรูปแบบของ XP

ให้เอา Test Scenarios (เฉลยการบ้าน) ประกบไปกับ Functional, Non-functional Requirements ตั้งแต่ต้น ก่อนไปทำการเขียน Code

• Small Release = ทุก Sprint มีของออก ไปอยู่บน UAT หรือ Pre-Prod เพื่อให้ PO เอาไปเช็คระยะกับ User(s) ได้เรื่อยๆ ว่าที่ทำไป มันใช่ที่อยากได้ไหม
• Change Request (CR) = ตีเวลาแล้ว จะแก้เลย หรือรอเข้ารอบ Sprint ไหน ถ้า User เสียงไม่ดัง รอได้ ก็รอก่อน หรือ ถ้า User รอไม่ได้ ต้องเอาเข้า ใช้กี่วัน ก็ต้องมาจัดแผนใหม่
• แต่ถ้าเป็น Incident Level 1 หรือ 2 ต้องแก้ทันที (ก็ต้องระบุกันว่าภายในกี่ชั่วโมง)

คนเรามีเวลาทำงานแบบโฟกัสจริงๆ มากสุด 6 ชั่วโมงต่อวัน (แม้ในเชิงทฤษฎีจะ 8 ชั่วโมงต่อวันก็ตาม)

คำถาม: เรายอมให้เวลาเสียเปล่าได้เท่าไหร่

ว่าทำไปแล้ว มันไม่ใช่ ทำแล้วทิ้ง ต้องกลับมาทำใหม่ เช่น ตีความผิด หรือ User บอกผิดตั้งแต่แรก หรือ คนบอกไม่ได้ใช้ คนใช้ไม่ได้บอก

• Change ไม่มีทางหายไป แต่เราจะจัดการ Change ยังไงต่างหาก
• ของอยู่ในมือ User เร็วเท่าไหร่ Change ก็มาเร็วเท่านั้น
• ยิ่งไปถึงมือ User ช้าเท่าไหร่ จำนวน Change ก็มากขึ้นเท่านั้น
• Waterfall ที่เอา UAT ไปอยู่ช่วงท้าย Change มหาศาล และจะมีเวลาอันน้อยนิดในการปรับแก้ เพราะมันจะต้องขึ้นแล้ว

การคำนวณ Sprint ว่ามีเวลาทำงานเท่าไหร่จริงๆ กันแน่

• Backlog Item ชิ้นนี้ ใช้เวลา สร้าง พร้อมขาย อยู่ที่กี่วัน
• คนที่มีหน้าที่ในการผลิต ตรวจสอบ แพ็คของ เป็นคนที่รู้ดีที่สุดว่าต้องใช้เวลาเท่าไหร่
• ถ้าใครมาสั่งว่า “ของชิ้นนี้ต้องเสร็จภายใน Sprint นี้” ถ้าทีมยังไม่รู้รายละเอียดอะไรเลย ก็บอกคนสั่งคนนั้น “มาทำให้ดูหน่อยว่าทำอย่างไรถึงเสร็จได้ตามเวลาที่บอกมา”
• ถ้าเรามีเวลาทำงาน 10 วัน (Sprint 1 รอบ) หักลบวันแรก วันสุดท้าย การทำ PBR อีกประมาณ 8 ชั่วโมง จะเหลือทำงานจริง คือ 7 วัน และ Buffer อีก 1 วัน
• ถ้ามาสายนี้ ของไม่มีเร่ง ไม่มีรีบ ทุกอย่างต้องรอ มีคิว ต้องสร้างพฤติกรรมให้ User รอให้เป็น

Scrum กับ Toyota

คนคิด Scrum ปรับประยุกต์ขั้นตอน และกระบวนการมาจาก ไลน์ผลิตรถยนต์ของ Toyota (TPS)

• ดังนั้น Product Backlog ของ Scrum = คิวผลิตรถยนต์ของ Toyota
• Scrum Team (Development Team) ไม่มีตำแหน่ง แต่ละคนเป็น Multi-Skills (U-cell) = ไลน์ผลิตรถยนต์
• Squad ถูกใช้ในวงการกีฬา (ทีมกีฬา) ที่มีเป้าหมายเดียวกัน ทุกครั้งที่ลงสนามจะต้องชนะ
• ตอนนี้ที่เราเรียกชื่อทีมว่า Squad กัน ก็คือมาแค่ชื่อ แต่ไม่ได้เอา หัวใจ ของมันมา

เป็น Product มีการวางแผน Release

• มีแผนการเติบโตของ Product มี Version ต่างๆ ไม่เกี่ยวกับ Agile เป็นเรื่องของ Software Management เช่น https://wiki.ubuntu.com/Releases
• ตัวอย่างการรันเลข Major.Minor.Patch
• การ Deploy แต่ละครั้ง ควรมี Release Note แนบไปด้วย เช่น https://www.mozilla.org/en-US/firefox/releases/
• Product Backlog ของ Scrum ถ้าไม่รู้จะจำแบบไหน ให้ดูที่ https://www.majorcineplex.com/movie

ถ้ามีสิ่งที่ไม่เคยทำ เช่น อยากใส่ ML เข้าไป

• ก่อนจะทำเคลียร์ก่อน ว่า ML ที่ต้องการคืออะไร
• จากนั้น จะ Build หรือ Buy หรือ Joint Ventures (Partner)
• ตั้งหมุดหมาย อยากได้สิ่งนี้เมื่อไหร่ แล้วถอยแผน
• อย่าทำงานพวกนี้ใน Sprint ให้แตกเป็นทีม (หรือคน) เพื่อทำ R&D ออกมา
• Spike = มาจาก XP แปลว่า ใช้เวลาน้อยๆ แป๊บๆ ต้องได้ผลออกมา
• Experiment = ผลการทดลอง ไปศึกษา ไปลองทำ แล้วเอาผลมาบอก
• Research = ให้ความรู้สึกแบบไปอ่าน แต่ไม่รู้ได้ผลอะไรออกมา
• ให้เวลาทีม Experiment เท่าไหร่ วันไหนเช็คระยะ เพื่อที่ PO จะได้ตัดสินใจว่า จะเดินตามแผนงานที่วางไว้ หรือ เปลี่ยนแผน

กลับมาที่ Development Team (Dev+QA)

How to translate the DORA metrics to systems-level calculations

https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance

• เชียร์ให้ขยับออกจากการทำงานระดับ Sprint เพราะเราทำ Product เพื่อตอบสนองลูกค้า
• ในอดีต พี่หนุ่มมี major 10 ครั้ง release ทุกเดือน ยกเว้น ม.ค. และ ธ.ค. วันที่ขึ้นเป็นวัน Fix (week ที่สามของทุกเดือน)
• ระหว่าง major จะเก็บไว้ 2 sprints เผื่อมีอะไรต้อง support ต้องแก้ หรือต้องมีอะไรปรับ ก็จะเป็น minor หรือ patch

LEAD TIME for changes หรือ restore service ไม่ได้เร็วขึ้นด้วยการทำงานแบบ Scrum

Scrum เป็นเอกสาร ที่เป็นตัวอักษรล้วน ที่เห็นเป็นรูปภาพก็คือ ตีความกันเอง ขนาดคนคิดสองคน คุณลุง Ken และ คุณลุง Jeff ก็ยังวาดภาพไม่เหมือนกัน ที่พี่หนุ่มวาดภาพออกมา ก็เกิดจากการตีความของพี่หนุ่มนั่นแหละ

ถ้าทำงานเป็น Sprint หัวใจสำคัญจริงๆ คือประโยคนี้ ไม่ใช่ Events อะไรใดๆ

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf

• Sprint Review ไม่ใช่การเอา User มาทำการทดสอบ มันคือการสรุปผลว่า ผลประกอบการใน Sprint นั้นเป็นอย่างไร คือ การอวดของ โชว์ของกับ Stakeholders หรือผู้บริหารที่เกี่ยวข้อง ว่าจะมี Version แบบนี้ให้ใช้แล้วนะ
• Sprint Retrospective คือ Kaizen หรือ Continuous Improvement เอาปัญหามาคุยกัน แล้วค่อยๆ แก้ไปทีละเรื่อง

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf

• ส่วนมากที่ทำกันตอนนี้ และหายไปคือ Sprint Goal ที่มีตัวชี้วัด เช่น ลดเวลาการทำงาน ลดขั้นตอนการทำงาน เพิ่มรายได้
• การเขียนว่า จะมี PBI ไหนเสร็จ ไม่ใช่ Sprint Goal
• การทำงานเป็น Sprint ของ Scrum เป็น ‘Framework’ เป็นกรอบเวลา ต้อง Fix ไม่ยืดไม่หด กิจกรรมไม่ต้องใช้ทั้งหมด ที่ SCK ให้ความสำคัญคือ Product Backlog Refinement (PBR)

Product Backlog Refinement (PBR)

• PBR ของ Scrum ให้เตรียมล่วงหน้า ไม่ได้ต่างจาก Waterfall ที่เตรียม REQs ทำ Solutions ก่อน
• Just In Time (JIT) ผลิตของเท่าที่มีออเดอร์ (ก็ได้ไอเดียจาก Toyota มาเช่นกัน)
• การเตรียมของล่วงหน้า เป็น Waste (เปลืองทรัพยากร)
• การตัดของเข้า Sprint เป็นการตัดล็อต เพื่อส่งเข้าโรงงานผลิต (โดยทีมพัฒนา ตรวจสอบ ทดสอบ)
• การทำงานในรูปแบบของ SCK เมื่อจบ PBR จะตอบได้แล้วว่า Sprint ถัดไปจะทำอะไรได้ (เพราะมี Estimation มาแล้ว)
• ถ้าทำ PBR ล่วงหน้าได้นาน (อย่างน้อย 2 Sprints) PO ก็จะมีเวลาในการต่อรองกับ Stakeholders ต่างๆ ได้มากขึ้น ในกรณีที่ทีม Estimate มาแล้ว ไม่เป็นตามแผนที่ตกลงไว้
• ตัวอย่างการตัด PBI ด้วย Test Scenarios ทั้ง Success และ Alternatives ที่มีข้อมูลจริง นอกจากจะช่วย Dev ในการมี Expected Results (เฉลยข้อสอบ) แล้ว ยังช่วยเป็นสารตั้งต้น เรื่องการออกแบบ Database หรือ Technical Spec อะไรอื่นๆ ได้อีกในการทำ PBR ด้วย
• พยายามย่อยให้เป็น Flow ที่เล็กที่สุด เพื่อจะได้ประมาณการได้ (เกือบ) แม่นที่สุด
• คำนิยามของ Error vs. Fault vs. Bug vs. Defect vs. Failure จะใช้อะไร แต่ละคำหมายถึงแบบไหน เคลียร์กันเองในทีมก่อนนะ
• ใน Waterfall มีระดับ High/Med/Low ของ Bugs เพราะเอาไปให้ User ทดสอบตอนท้าย เจอ Change แล้วมันแก้ไม่ทัน ก็เลยเรียงคิว แต่ถ้าเป็นการทำงานเป็นรอบแล้ว จะยอมให้มีการสะกดผิด (ที่ถูกตีว่าเป็น Low) ออกไปให้ลูกค้าดูเหรอ? ลองถามใจตัวเองดู

Daily Plan ตั้งเป้าหมายยามเช้า — Daily Review เอาผลงานมาดู เสร็จ/ไม่เสร็จ ติดปัญหาอะไรไหม

• การทำงาน 8 ชั่วโมงต่อวัน มาจากยุคปฏิวัติอุตสาหกรรม ที่เน้นงานใช้แรง ไม่ได้เน้นทักษะ แต่งานที่เราทำในวงการ Software มันคืองานเน้นทักษะ ไม่มีใคร Focus ได้เต็ม 8 ชั่วโมงหรอก
• พี่หนุ่มผู้เจอบทความใน HBR และส่งมาให้ข้าพเจ้าแปลออกมา > How to จัดการพลังงานให้มีมากพอในการเอาชีวิตรอดในแต่ละวัน (Manage Your Energy)

การทำงานเร็วหรือช้า ไม่ได้อยู่ที่ Process มันอยู่ที่ทักษะคนทำงาน

1. Weekly Cycle
2. Informative Workspace
3. Incremental Design
4. Shared Code (Collective Code Ownership) — Production Code, Test Code
5. Code and Tests by Test-Driven Development (TDD)
6. Root-Cause Analysis
7. Continuous Integration (CI)
8. Test-First Programming
9. Real Customer Involvement

“ในชีวิตจริง มีงาน Support Production มี Incident มีเรื่องต่างๆ มันไม่ได้จบลงแค่ Sprint”