ร่วมทำ Product Discovery กับทีม PO; Part I

สวัสดีครับ วันที่ 9 พ.ย. 2558

ร่วมทำ Product Discovery กับทีม PO; Part I

       วันนี้เป็นวันแรกของการทำ Product Discovery ครับ ซึ่งคนที่เข้าร่วมนั้นก็มีดังนี้ Product Owner (PO), Stockholder หรือ User, Development Team(Developer, Tester, SA), Scrum Master

      โดยปกติคนที่จะพาทำกิจกรรมต่างๆของการทำ Product Discovery นั้นต้องเป็น PO ครับ แต่ถ้า PO ยังใหม่กับการทำแบบนี้ Scrum Master ก็เข้ามามีบทบาทได้ เพื่อช่วย PO ทำงาน

      เริ่มกันเลย SM แนะนำให้ทุกคนรู้จักการทำ Product Discovery ก่อนว่าคืออะไร มีไว้เพื่ออะไร เพื่อความเข้าใจให้ตรงกันว่า วันนี้เราจะมาทำอะไรกัน เพื่อเป้าหมายอะไรกัน จะได้ไปในทิศทางเดียวกัน

      SM บอก Rule การทำงานวันนี้ว่ามีอะไรบ้าง ซึ่งทุกคนต้องทำตาม เพื่อให้ได้เกิดประโยชน์สูงสุด แต่ Rule นี้ก็เป็นที่ยอมรับของทุกคนเหมือนกันครับ เช่น ห้ามใช้ notebook เพื่อให้ตั้งใจทำงานตรงนี้

      SM ถามถึง Business Requirement คืออะไรบ้าง และ Software Requirement คืออะไรบ้าง ให้ทุกคนช่วยเสนอออกมา ถ้าคนเยอะให้แบ่งเป็นกลุ่มๆ เพื่อลดการโต้เถียงที่ยาวนาน เมื่อทุกกลุ่มได้ออกมาแล้วก็พูดออกมาว่ามีอะไรบ้าง ถ้ากลุ่มไหนมีเหมือนกันก็เสริมกันได้เลย แต่ถ้าแตกต่างก็ discuss ได้แต่อย่านานเกินไป เนื่องจากพอได้ตรงนี้มาแล้ว เราจะหันมาถาม Development Team ว่า Business Requirement เพียงพอที่จะเอาไป develop ได้หรือไม่ เมื่อไม่พอต้องเพิ่มอะไรมาบ้างตรงนี้ละที่สำคัญเลย

      Business Requirement เช่น

• Flow Business
• Condition
• User
• User Interface
• Test Case + Data Test

      Software Requirement เช่น

• Performance
• Response Time
• Non-Functional

      SM เริ่มโดยการถามทุกคนว่า

• PROBLEM ปัญหาที่ทำให้เกิด Product นี้คืออะไร
• GOAL เป้าหมายเพื่อให้ Product นี้สำเร็จได้คืออะไร อันนี้ควรจะตอบโจทย์ปัญหาน่ะ และควรเป็น GOAL ที่ชัดเจน และเรียง PRIORITY ด้วย
• MAXIMIZE OUTCOME ผลที่อยากให้เกิดขึ้นเมื่อ PRODUCT นี้ได้เอาไปใช้แล้ว เช่นมีคนใช้งานมากขึ้นเรื่อย, ลดขั้นตอนการทำงานจาก PRODUCT เก่า เป็นต้น

      หลังจากได้ PROBLEM, GOAL, OUTCOME มาแล้ว เราก็เริ่มแก้ปัญหาทีละเรื่อง (Flow Business)

      โดยให้ช่วยกันเขียนว่าเรามี Flow Business อะไรบ้างออกมาให้หมด

• PO มาเรียง PRIORITY ว่าต้องการ flow ไหนก่อนหลัง
• ถ้า Fix Time ให้ PO บอกว่า Flow ต้องได้อย่างน้อยเท่าไร
• Dev Team บอก PO ว่าจะทำได้อย่างที่ PO ขอหรือไม่ ถ้าไม่ ได้แค่ไหน พร้อมเหตุผล

      ใส่ People และ Step workflow ที่เกี่ยวข้องกับ Flow Business นี้ลงไปแต่ละ Flow เลยว่า ใครทำอะไร มี step การทำงานอย่างไรลงไป ตรงนี้ถ้าเกิด flow ใหม่มาก็เพิ่มได้เลย (แต่จะเน้นให้ทำเฉพาะส่วนที่ Dev Team บอกว่าทำได้ก่อน)

• PO มาเรียง PRIORITY ว่าต้องการ flow ไหนก่อนหลัง
• ถ้า Fix Time ให้ PO บอกว่า Flow ต้องได้อย่างน้อยเท่าไร
• Dev Team บอก PO ว่าจะทำได้อย่างที่ PO ขอหรือไม่ ถ้าไม่ ได้แค่ไหน พร้อมเหตุผล

     เราจะเห็นว่ามีการปรับ PRIORITY ได้ตลอดเวลา และการ Estimate ว่าทำได้แค่ไหนนั้น คือการเดาล้วนๆเลยครับ แต่ถ้าเรา ลงรายละเอียดของแต่ละ Flow Business ได้มากแค่ไหนก็ยิ่งง่ายต่อการพัฒนา ครับ

     การทำกิจกรรมของวันแรกนี้คือ

• ทุกคนเห็นปัญหาเดียวกัน
• ทุกคนมีเป้าหมายเดียวกัน
• ตอบโจทย์ผู้ใช้งานและผู้ที่เกี่ยวข้องมากที่สุด
• พาทุกคนให้เสนอแนะ แสดงความคิดเห็น พูดออกมาให้มากที่สุด (การถาม ตั้งคำถาม พูดให้ฉุกคิด)
• ควบคุมให้ทุกคนอยู่ในเป้าหมายตลอดเวลา ไม่ให้ออกนอกเรื่อง (ถามถึงเรื่องที่เรากำลังทำ)
• วาง Agenda ของแต่ละช่วงเพื่อให้งานต่อเนื่องไปยังเป้าหมายได้อย่างถูกต้องมากที่สุด
• ควบคุม ป้องกันไม่ให้เกิดปัญหาระหว่างคน (การยับยั้งการพูดจาที่อาจจะสุ่มเสี่ยง)

     จบวันแรกละ เนื่องจากใช้เวลากับการลงรายละเอียดแต่ละ flow เยอะ และการอธิบายเนื้อของแต่ละ Flow พรุ่งนี้มาต่อน่ะครับ

Rally Day (21/10/2015)

สวัสดีครับ เนื่องจากมีโอกาสได้ไปร่วมกิจกรรมของงาน Rally Day (SAFe Big Room Planing) มาเมื่อวันที่ 21 ตุลาคม 2015 ที่ โรงแรมปทุมวันปริ้นเซส

หัวข้อที่จะมาทำกิจกรรมนั้นก็คือ Big Room Planning โดยเราจะใช้ Lego มาสร้างเมืองกัน

ก่อนอื่นเลยทาง Rally แนะนำให้เราฟังก่อนว่าเจ้า Big Room Planning นี้คืออะไรกัน

Big Room Planning คือการประชุมเพื่อเตรียมแผนการทำงานของผลิต Product ตัวนึง เป็นการวางแผนภาพใหญ่ ซึ่งเป็นการประชุมที่ทุกๆคนต้องเข้ามา คนที่เข้ามาก็มี
Executive เพื่อเข้ามาให้ Vision กับทุกคน ทุกคนจะได้เห็นภาพ เข้าใจเป้าหมายที่เหมือนกัน
Release Train Engineer (RTE) คนที่คอยดูภาพใหญ่ทั้งหมด เพื่อให้เป็นไปตามแผนงาน
UX/Architect คนที่ดูเรื่องการวางโครงสร้างของการทำงาน
Product Manager คนที่เป็นเจ้าของ Product และดูแล Product ภาพใหญ่(Roadmap)
Product Owners คนที่เป็นทีมเดียวกับ Product Manager เพื่อช่วยแบ่งงาน module ไปทำงาน
Scrum Masters คนที่ดูแลทีม
Develop Team ทีมงานพัฒนา

จบทฤษฎีก็มา workshop กันดีกว่า

มีการแบ่งทีม 5 ทีม
ทีม 1 - 4 เป็นทีมที่สร้าง บ้าน คอนโด โรงเรียน ลานกีฬา อื่นๆ
ทีม 5 สร้างผังเมือง ถนน (มีทีมนี้ตั้งแต่ภาพใหญ่มาจะทำให้เกิดคุณภาพถึง 25%)

Product Owner ของแต่ละทีมไปรับงานจาก Product Manager มาให้ โดยมี Scrum Master เป็นคนกำกับการทำงาน แล้วมาวางแผนของทีมกัน ซึ่งต้องมีเรื่อง Objective, Story, Risk จะเหมือนกันกับการที่เราทำ Sprint Part I ซึ่งตรงนี้เราจะได้บอร์ดภาพใหญ่ออกมา

ส่วนที่มีการ Dependency กัน
การวางแผนของทีม ก็จะมีส่วนที่ทีมต้องไปคุยกันกับทีม 5 ที่จะมีหน้าที่สร้างผังเมือง
เรื่องของขนาดโครงสร้างอาคารที่กำหนดไว้ว่าต้องใหญ่กว่าบ้าน 3 เท่า จึงทำให้ต้องมีการคุยกันกับ
ทีมที่รับผิดชอบในการสร้างบ้าน ซึ่งตรงนี้จะมีเส้นที่ลากผูกสัมพันธ์กันที่บอร์ดใหญ่

เมื่อทุกๆคนเริ่ม Clear ภาพของการทำงานทั้งของตัวเองและที่ Dependency กันแล้วก็ Commit งานกัน
แยกย้ายกันไปทำงาน ซึ่งทุกทีมจะมีบอร์ดการทำงานของตัวเอง และสัมพันธ์กับบอร์ดใหญ่ด้วย

รอบการทำงานของทุกๆทีมจะเหมือนกัน เมื่อถึงรอบการ Integrate กัน ก็จะมาวางพร้อมกัน
แต่เมื่อไรที่ติด และสัมพันธกันกับทีมอื่นก็จะต้องวางแผนเพื่อขยับไปด้วยกัน

ข้อดีจากการทำ BRP นี้ทำให้ทกุๆคนได้เห็นแผนที่ชัดเจน เห็นปัญหาได้ชัดเจนมากขึ้น

Rally มี Software ที่ทำให้เราเห็นภาพบอร์ด และอัพเดทได้ทันที ทำให้ทุกคนเห็นภาพใหญ่ได้ดีขึ้น
https://www.rallydev.com/blog/product/got-big-room-planning

ผู้จัดงาน
Rally https://www.rallydev.com/
CA http://www.ca.com/
V-Link http://www.vlink.co.th
Lean In Consulting http://lean-in.co/

ข้อมูลที่ต้องศึกษาเพิ่มเติม
http://scaledagileframework.com/

DevOps

DevOps

Development and Operations ที่จะทำให้กระบวนพัฒนา Software ทำงานได้รวดเร็ว คล่องตัวขึ้น

ทำไมถึงรวดเร็วได้ละ ทำไมถึงคล่องตัวละ แล้ว DevOps นี้คืออะไรกันหน่อ

DevOps คือการมีเครื่องมือต่างๆ ที่จะเข้ามาช่วยให้การทำงานที่ต้องทำซ้ำซ้อนลดลงไป เช่น

Case 1

การที่เราต้องการ server ตัวนึงเพื่อที่จะทดสอบ software ตัวนึงที่เรากำลังพัฒนามาได้นั้น

มีหลายขั้นตอนมากมาย เช่น ต้องทำเอกสารแจ้งไปยังทีม ITO เพื่อขอ server ตาม spec ที่เราบอก

เมื่อ ITO ได้ข้อมูล spec ไปก็ต้องตรวจสอบว่า มี resource พอหรือไม่ ถ้าพอก็ต้องไปขอ IP จากทีม

Network เมื่อได้ IP มาแล้วก็ deploy server มาให้เราได้

Case 2

การที่เราต้องการให้ config Middleware บน production ได้นั้นเราต้องทำเอกสารส่งไปให้ ITO ทำ

ITO ก็ต้องมานั่ง config ตามเอกสารอีกที มีโอกาส Human Error สูง

อย่างที่เราเห็นนี้ ขั้นตอนมากมาย ข้อมูลส่งต่อหลายต่อ ปัญหา Human Error นั้นก็มีโอกาส 

จะดีกว่าไหมที่เราสร้าง script ต่างๆเหล่านี้ให้อยู่บน tools ที่จะช่วยให้เราแค่กรอกข้อมูลไป

แล้ว ITO ก็ดู monitor ว่ามีพอหรือไม่พอ ถ้าพอก็กด approve ไป ทุกอย่างก็จะ auto install config ให้

เราอย่างที่เราต้องการได้เลย ถ้าผิดก็ผิดที่เรากรอกข้อมูลลงใน tools เองแล้วละ

เราจะพอได้เห็นว่า การจะได้ Server Middleware นั้นจะง่ายขึ้นละ

Software ที่เราพัฒนาละ ถ้าเราพัฒนา feature ออกมาได้บ่อยๆ ทุกๆสัปดาห์ ทุกๆเดือน

แล้วเราต้อง deploy ลง Develop Environment => QC Environment => UAT Environment => Production Environment ตามลำดับแบบนี้บ่อยๆ จะยุ่งยากขนาดได้ ต้องใช้คนเท่าไรกัน

คนทำงานที่ต้องมาทำอะไรที่ซ้ำๆ มันน่าเบื่อไหม จะได้ไปพัฒนาตนเองได้เรื่องอื่นๆไหม

แล้ว Test ที่ต้องมา Regression Test ละ เยอะขนาดไหนกันเชี่ยว

DevOps แก้เรื่องเหล่านี้ได้น่ะ แต่ๆๆๆ คนที่จะมาทำให้เกิดนั้น ต้องเข้าใจ flow การทำงานในแต่ละ
ขั้นตอนโดยละเอียด รู้ว่าจุดไหนของการทำงานต้องการให้นำมาช่วยได้บ้างนี้ก่อนน่ะ

แล้วถึงจะต้องมาทำ script หรือมี tools ที่จะช่วยให้เขียน script น้อยลง ซึ่ง script นี้ก็จะประกอบ

ไปด้วยเรื่องของการใช้ tools มาทำ unit test, automate test flow งานตาม business , deploy ลง

แต่ละ environment เมื่อผ่าน environment นึงละต้องการให้ไปต่อก็ทำให้เกิดแค่ปุ่มกด approve

เพื่อยืนยันว่า software ผ่าน environment นี้ละต้องไป step ต่อไปได้ละ รวดเร็วไหมละ แค่ปุ่มเดียว

DevOps ต้องใช้ทักษะหลายๆอย่าง เพื่อที่จะต้องเขียน script ให้ support ทุกกระบวนการทำงาน

ถึงแม้ว่า เราจะหา Tools DevOps มาก็ตามที ก็มักจะมีจุดที่เราต้องมาทำ script เองอยู่ดีครับ

Script นี้มีภาษา เช่น shell command สำหรับ OS, Middleware, Database เป็นต้น ขึ้นอยู่กับว่าเราจะ

ช่วยให้ขั้นตอนไหน auto ได้  หรือต้องมา manual ได้ง่ายที่สุด

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

สุดท้ายแล้ว script นี้ก็ทำแค่ครั้งแรกครั้งเดียว และก็เอาไปใช้ต่อได้ใน software ถัดๆไป 

เว้นแต่ว่ามีอะไรที่แตกต่างเพิ่มมา

Refactoring - Composing Methods

 จากหนังสือ Refactoring Improving Design Existing Code

บทที่ 6 Composing Methods

Extract Method

การแยก code ส่วนนึงออก โดยพิจารณาจาก

• มี code ส่วนนี้เป็นเนื้อหาย่อยของชื่อ method หรือไม่
• มี comment ที่บอกว่า code ส่วนนี้เป็นอีกเรื่องนึงที่ทำงาน

เราก็ลอง extract method ออกไป แต่ให่เราคำนึงถึงชื่อที่ตั้งให้ method ด้วยน่ะว่า

• ชื่อต้องสื่อถึงการทำงานของ code ที่ extract ออกไป

Example

Example: No Local Variables

Example: Using Local Variables

Example: Reassigning a Local Variable

แล้ว rename outstanding => result เพื่อให้เข้าใจง่ายของการทำงานใน method นี้

Next Example

Inline Method

การยุบ Method ที่ไม่จำเป็นต้องมี อาจจะพิจารณาได้จาก

• เรียกจากที่เดียว
• method ทำงานแค่ 1 บรรทัด

Example

Inline Temp

การยุบ Object Temp ที่เรียกใช้งานเพียงครั้งเดียว

Example

Replace Temp with Query

การยุบ Object ที่เป็นการคิด หรือทำอะไรเพียงเล็กน้อย แล้ว Extract Method ออกไป

Example

Example

ใส่ final ไว้เพื่อให้มั่นใจว่าจะได้รับการ assign value เพียงครั้งเดียว

Introduce Explaining Variable

ค่าที่มีที่มาเพียงอย่างเดียวหรือเงื่อนไขชัดเจนสามารถแยกออกไปได้

Example

Example

Example with Extract Method

Split Temporary Variable

ค่าของ temp เป็นคนละเรื่องกัน ก็ควรแยกชื่อกัน เพื่อความเข้าใจที่ง่ายกว่า

Example

การใช้ object มาเป็น temp กับ loop ก็อาจจะมีปัญหาได้

Example

Remove Assignments to Parameters

ไม่ใช้ Object ที่ส่งมาโดยตรง

Example

Replace Method with Method Object

Example

 

Substitute Algorithm

Example

การติดตั้ง Robot Framework

การติดตั้ง Robot Framework

สิ่งที่ต้องลงตามลำดับ

1. Install Python

2. Install PIP

3. Install Robot Framework

1. วิธี Install Python

1. ไปที่ URL: https://www.python.org/
2. ไปที่เมนู Download เลือก Python 2.x.x (แนะนำให้ใช้ version 2 ก่อนครับ)

3. ดับเบิ้ลคลิกไฟล์ python-2.x.x.msi เพื่อทำการติดตั้ง Python

4. กดปุ่ม Next 

5. ให้เลือก dive C:\Python27\ เนื่องจากหลังจากนี้เราจะได้เช้าถึงได้ง่าย (เปลี่ยนได้ตามใจชอบน่ะครับ) กดปุ่ม Next

6. ให้เลื่อนช่อง Feature ไปล่างสุด

7. เลือก Add python.exe to Path  แล้วเลือก Will be installed on local hard drive

8. กดปุ่ม Next

9. รอโปรแกรม install จนเสร็จ

10. กดปุ่ม Finish ก็เป็นอันเรียบร้อย

วิธีตรวจสอบว่าเรียบร้อยหรือไม่

1. เปิด Command Line ขึ้นมา
2. พิมพ์คำว่า python แล้ว Enter ถ้าได้แบบรูปเป็นอันว่าเรียบร้อย

2. วิธี Install PIP

ลง PIP ไว้สำหรับ install library ต่างๆที่ Robot Framework ต้องใช้
1. ไปที่ URL: https://pip.pypa.io/en/latest/installing.html
2. ให้ download file get-pip.py

3. ให้คลิกขวา => บันทึกลิงค์เป็น

4. save ไว้ drive C:\

5. เปิด Command Line ขึ้นมา แล้วพิมพ์ cd \ เพื่อไปยัง drive C:\

6. พิมพ์ python get-pip.py แล้ว enter

7. เราก็ลง PIP เรียบร้อย

วิธีตรวจสอบว่าเรียบร้อยหรือไม่

1. เปิด Command Line ขึ้นมา
2. พิมพ์คำว่า pip แล้ว Enter ถ้าได้แบบรูปเป็นอันว่าเรียบร้อย

3. วิธี Install Robot Framework

1. เปิด Command Line ขึ้นมา
2. พิมพ์คำว่า pip install robotframework แล้ว Enter

วิธีตรวจสอบว่าเรียบร้อยหรือไม่

1. เปิด Command Line ขึ้นมา
2. พิมพ์คำว่า pybot แล้ว Enter ถ้าได้แบบรูปเป็นอันว่าเรียบร้อย