#priwreadarticles วิธีแตกโครงการ สู่ Tasks (งาน) เป็นทักษะและต้องฝึกฝน
บทความนี้แปลและสรุปจาก Estimating Software Projects: Breaking Down Tasks และ Timebox hard-to-estimate work
ในบทความจะมีตัวอย่าง เป็นโจทย์นี้
ฉันกำลังสร้างเครื่องติดตามสถิติส่วนตัว ติดตามวันที่ฉันทำกิจกรรมกลางแจ้ง บางประเภท ฉันต้องการสิ่งที่คล้ายกับแอป Streaks ยกเว้นตัวเลือกที่แตกต่างกันสำหรับกิจกรรมกลางแจ้ง (วิ่ง ขี่จักรยาน เล่นสกี ฯลฯ) และฉันต้องการฟีเจอร์ “streak freeze” ของ Duolingo
// “streak freeze” จาก Duolingo คือ ฟีเจอร์หนึ่ง (ที่ต้องเสียเงิน) เพื่อให้แน่ใจว่าคุณจะไม่เสีย streak เมื่อลืมฝึกซ้อมเข้าสักวัน
รอบการทำงานที่ 1
เริ่มต้นด้วยภาพจำลองของสิ่งที่ฉันกำลังจะสร้าง เป็นจุดเริ่มต้นที่ดี แม้ผลลัพธ์สุดท้ายจะไม่ค่อยได้ออกมาเป็นแบบนี้ แต่เป็นวิธีที่ดีในการอธิบายคุณสมบัติทั้งหมดที่ฉันต้องการในรูปแบบที่เข้าใจง่าย
ถ้าเป็นแค่โปรเจ็กต์ส่วนตัว ก็น่าจะ Breakdown Tasks พอแล้ว ฉันจะนั่งลงและเริ่มเขียนโค้ดทันที แต่หากว่า ฉันจะมอบหมายงานนี้บางส่วน หรือหากฉันต้องประเมินว่าจะใช้เวลานานแค่ไหน ฉันก็จำเป็นต้องมีรายละเอียดมากกว่านี้
รอบการทำงานที่ 2
คิดทบทวนและวางแผนขั้นตอนต่างๆ ที่ต้องดำเนินการเพื่อทำสิ่งนี้ให้สำเร็จ ฉันจะพยายามคำนึงถึงความเกี่ยวเนื่องกัน (dependencies) งานไหนที่ต้องมาก่อนงานอื่น แต่ฉันยังไม่กังวลเกี่ยวกับขนาดหรือขอบเขตของขั้นตอน
เป็นเพียงรายการคร่าวๆ เท่านั้น
- สร้างโมเดลข้อมูล
- สร้างมุมมองปฏิทิน แสดงวันในสัปดาห์ปัจจุบัน
- สร้างปฏิทินแบบโต้ตอบได้ คลิกที่ไอคอนเพื่อบันทึกกิจกรรม และทำเครื่องหมายวันที่ “เสร็จสิ้น” เพื่อติดตาม
- คำนวณและแสดงความยาวของ streak ปัจจุบัน
- สร้าง streak freeze
** หมายเหตุ การแตกงานด้านบน ไม่สนใจการ integration และขั้นตอนการปฏิบัติงานอื่นๆ เช่น การตั้งค่าฐานข้อมูล รวมไปถึง ยังไม่ได้ลงรายละเอียด deployment และไม่ได้แยกงาน front/backend (ถ้ามีคนทำหลายคน ก็จะแยกอีก) แต่แค่ไม่แยกในตัวอย่างนี้
สำหรับบางงานด้านบน ฉันอาจประมาณเวลาในแต่ละขั้นตอนได้อย่างแม่นยำและเพียงพอ แต่ก็ยังมีความไม่แน่นอนอยู่มาก เช่น
- ไม่ชัดเจนว่า streak freeze จะคิดวันสะสมและติดตามการคงค้างอย่างไร
- ฉันไม่มีอะไรเกี่ยวกับประวัติที่นี่
- การเพิ่ม/ลบประเภทกิจกรรม
และช่องโหว่อื่นๆ ที่อาจเกิดขึ้น
สิ่งเหล่านี้ทำให้การประมาณการมีความไม่แน่นอน และหมายความว่าหากฉันมอบหมายงานให้คนอื่นทำ ฉันอาจไม่ได้ผลลัพธ์ตามที่ฉันจินตนาการไว้
รอบการทำงานที่ 3
จากข้อใหญ่ๆ ในรอบการทำงานที่ 2 จะถูกแบ่งย่อยลงอีก (ในบทความต้นทางจะลงรายละเอียดทั้ง 5 หัวข้อ แต่นี่ขอหยิบมาบางข้อ)
สร้างมุมมองปฏิทิน แสดงวันในสัปดาห์ปัจจุบัน
- มุมมองรายสัปดาห์: แสดงวันในสัปดาห์ปัจจุบัน กิจกรรมที่บันทึกไว้ หรืออะไรที่ขอใช้สิทธิ์ Freeze ในวันนั้น
- มุมมองหน้าแรก: แสดงสัปดาห์ปัจจุบัน
- มุมมองรายเดือน: แสดงทั้งเดือน ไม่มีกิจกรรมแต่ละประเภท เป็นเพียง การบันทึก/ไม่ได้บันทึก
- การเรียกดู: เรียกดูย้อนกลับ/ไปข้างหน้า ในมุมมองสัปดาห์และเดือน และอนุญาตให้สลับระหว่างสัปดาห์และเดือน
- ช่องป้อนข้อมูลด่วน “ไปที่วันที่” ไม่มีการป้อนวันที่ที่ไม่ชัดเจน สามารถใช้วิดเจ็ตวันที่ของ html5 ได้ในตอนนี้
สร้าง streak freeze
- เมื่อทำการคำนวณ streak X วัน (ไม่มีการหยุดนิ่ง) สามารถฮาร์ดโค้ด X ได้
- “ทบยอด”: หากสะสม streak freeze 3 ครั้ง ระหว่างการทำ streak A ใช้ไป 1 ครั้ง และสิ้นสุดลง คุณยังคงมี streak freeze อีก 2 ครั้งสำหรับใช้กับ streak B
- ป้องกัน “การสะสมสองเท่า” หากคุณย้อนเวลากลับไปและอัปเดตกิจกรรม ซึ่งทำให้เกิดการคำนวณใหม่ คุณจะไม่ได้รับ streak ซ้ำ
- เพิ่มการค้างให้กับ UI: แสดงวันที่ใช้ไปกับการ freeze ขยายวันต่อเนื่อง และแสดงจำนวนการ freeze สะสมใน UI
มาถึงตรงนี้ Tasks งานย่อยพอหรือยัง?
สำหรับทีมนักพัฒนาส่วนใหญ่ เราเห็นขั้นตอนที่ชัดเจน คำจำกัดความที่ชัดเจนของการทำเสร็จแล้ว และหลีกเลี่ยงช่องโหว่ที่อาจเกิดขึ้นทั้งหมดอย่างรอบคอบเท่าที่ฉันนึกได้
แต่ฉันสามารถจินตนาการถึงสถานการณ์ต่างๆ ได้อีก เช่น นักพัฒนารุ่นเยาว์ โครงการที่มีภารกิจสำคัญที่มีการกำกับดูแล/ตรวจสอบอย่างเข้มงวด ที่อาจจำเป็นต้องมีรายละเอียดเพิ่มเติม
แต่สำหรับจุดประสงค์ของตัวอย่างนี้ เรามาเรียกสิ่งนี้ว่า “เสร็จสิ้น” กันดีกว่า
กระบวนการแบ่ง/แตก Task (งาน)
- เริ่มต้นด้วย โครงการใหญ่ หรือ List รายการจำนวนหนึ่งก็ได้
- คิดถึงขั้นตอนต่างๆ ที่คุณต้องทำ เพื่อทำงานนั้นให้สำเร็จ แล้วจดบันทึกไว้ ไม่ต้องกังวลกับความสมบูรณ์แบบ ความแม่นยำ หรือความละเอียดยิบ แต่ละรอบการทำงานที่เพิ่มขึ้น รายละเอียดจะถูกขยายจากรอบก่อนหน้า แม้จะเล็กน้อยก็ตาม
- ทุกงานในรายการใหม่ของคุณมีการระบุไว้อย่างเพียงพอหรือไม่ ถ้าไม่ ให้ไปที่ 1.
บริบทในบทความนี้คือ บุคคลที่ไม่เคยทำสิ่งนี้มาก่อน และค่อนข้างใหม่ต่อการพัฒนาซอฟต์แวร์โดยรวม ดังนั้นเราจะมารู้จักนิยามคำศัพท์ต่อกัน
Task (งาน) คืออะไร?
- ถูกระบุไว้อย่างเพียงพอ เนื่องจากงานต้องมีโครงร่างที่ชัดเจนของสิ่งที่จำเป็นต้องทำ
- เสร็จสมบูรณ์ เนื่องจากงานต้องครอบคลุมงานทั้งหมดที่จำเป็น งาน “ตัดต้นไม้” จะไม่เสร็จสมบูรณ์ หากคุณเอามาแค่เลื่อยไฟฟ้า
- ทำให้เกิดการเปลี่ยนแปลง Task (งาน) จะ “สำคัญ” หากมีบางอย่างแตกต่างออกไปเนื่องจากการทำสิ่งนี้
เพื่อจุดประสงค์ในการประมาณค่า เราต้องเจาะลึกลงไปอีกเล็กน้อยว่า คำจำกัดความ เป็นอย่างไร
Task (งาน) ที่ “ถูกระบุไว้อย่างเพียงพอ”
คำจำกัดความของ “เพียงพอ” จะแตกต่างกันไปตามบริบท ตามตัวอย่างด้านบนหากทำงานคนเดียว ภาพร่างง่ายๆ ก็ “เพียงพอ” แต่ในบริบทอื่น เราต้องการรายละเอียดเพิ่มเติม
แม้ว่าจะไม่มีคำจำกัดความที่ใช้ได้ทั่วโลกของคำว่า “เพียงพอ” แต่ฉันคิดว่ามีคำจำกัดความทั่วไป ที่เพียงพอที่จะเป็นประโยชน์ เป็นจุดเริ่มต้น
Task (งาน) จะได้รับการบอกว่า “ถูกระบุไว้อย่างเพียงพอ” หากบุคคลที่ทำงาน สามารถตอบ “ใช่” สำหรับคำถามเหล่านี้ได้
- ฉันเข้าใจหรือไม่ว่าต้องการเปลี่ยนแปลงอะไร
- ฉันเข้าใจหรือไม่ว่า “เสร็จสิ้น” จะเป็นอย่างไร
- ฉันสามารถกำหนดขั้นตอนทั้งหมดที่ต้องทำเพื่อให้ “เสร็จสิ้น” ได้หรือไม่ เช่น ฉันสามารถเขียนรายการสิ่งที่ต้องทำสำหรับงานนี้ได้หรือไม่ และจะเสร็จสมบูรณ์หรือไม่
- สมมติว่าไม่มี blockers หรือ dependencies ฉันมีข้อมูลทั้งหมดที่จำเป็นต้องใช้เพื่อเริ่มงานนี้หรือไม่
หากบุคคลที่ทำงานตามบริบทของสถานที่ทำงานและชุดทักษะไม่สามารถตอบ “ใช่” สำหรับคำถามเหล่านี้ทั้งหมดได้ แสดงว่างานนั้นไม่ได้แบ่งย่อยเพียงพอ และคุณควรทำซ้ำการแยกย่อยจนกว่า คุณสามารถตอบ “ใช่” สำหรับคำถามเหล่านี้สำหรับงานทั้งหมดในรายการ
มันจะมีบางงานที่ยาก แม้คุณรู้ว่าการเปลี่ยนแปลงคืออะไร คุณรู้ว่า “เสร็จสิ้น” เป็นอย่างไร แต่คุณก็ยังไม่สามารถทราบขั้นตอนทั้งหมดได้อยู่ดี เช่น migrating a legacy codebase มันแทบจะเป็นไปไม่ได้เลยที่จะทราบล่วงหน้าอย่างแน่ชัดว่างานใดบ้างที่จำเป็นต้องทำ
ในที่นี่จะแนะนำเทคนิค Timeboxing
- เลือกกรอบระยะเวลาตามใจชอบ โดยปกติแล้ว คือหนึ่งหรือสองสัปดาห์ แล้วดูว่าเราไปได้ไกลแค่ไหน
- ในตอนท้ายของกรอบเวลา เราจะมีความรู้เกี่ยวกับงานมากขึ้น
- เราสามารถตรวจสอบความคืบหน้าของเรา และตัดสินใจโดยมีข้อมูลดีขึ้นว่าจะดำเนินการต่ออย่างไร
แทนที่จะถามว่า “X จะใช้เวลานานแค่ไหน” ไทม์บ็อกซ์จะถามคำถามเช่น “เราจะทำอะไรได้บ้างภายในสองสัปดาห์”
Timeboxing ยังมีประโยชน์มากสำหรับโปรเจ็กต์ที่ไม่สามารถทำให้เสร็จภายในเวลาอันสมควรได้อย่างชัดเจน เช่น ทีมที่มีรายงานข้อผิดพลาดค้างอยู่จำนวนมาก อาจเป็นเรื่องยากที่จะใช้เวลาที่จำเป็น ในการทำให้คิวข้อผิดพลาดที่คงค้างอยู่เป็นศูนย์ แต่การใช้เวลา หนึ่งวันต่อสัปดาห์ ในการทำให้คิวข้อผิดพลาดที่คงค้างลดลง ก็อาจเป็นเรื่องปกติ
Timeboxing เป็นวิธีที่ดีในการสร้างความก้าวหน้า สำหรับทีมที่มีงานมากมาย หรือไม่ทราบแน่ชัด
การแตกงาน เป็นทักษะและต้องฝึกฝน
เรื่องราวต่างๆ ที่ฉันได้ทำงานหรือเห็นมา รวมถึงประสบการณ์เป็นสิบปีนั้น ทำให้ฉันเข้าใจขั้นตอนตามลำดับที่ถูกต้อง ซึ่งหมายความว่า หากคุณไม่เคยเห็นโปรเจ็กต์แบบนี้มาก่อน ก็เป็นเรื่องยากมากที่จะรู้ว่าจะเริ่มจากตรงไหน
หากคุณยังใหม่ต่อการทำสิ่งนี้ คุณอาจพบว่ามันไม่ได้เกิดขึ้นง่ายนัก และนั่นเป็นเรื่องปกติ
ไม่มีทางลัดที่นี่ วิธีเดียวที่จะเรียนรู้คือการลงมือทำ
- สิ่งที่ดีที่สุดที่ผู้จัดการ หรือหัวหน้า หรือผู้ที่มีประสบการณ์มากกว่า สามารถทำได้เพื่อช่วยให้ทีมดีขึ้น คือ การให้โอกาสที่ปลอดภัยแก่พวกเขาในการทดลองทำ
- ขอแผนโครงการจากพวกเขา ช่วยพวกเขาแบ่งงาน แยกงานให้ย่อยลง ให้ข้อเสนอแนะ แต่อย่าลงโทษเมื่อพวกเขาทำผิด
- ในสภาพแวดล้อมการเรียนรู้ที่ปลอดภัย ข้อผิดพลาดเหล่านั้นจะกลายเป็นข้อมูลในครั้งถัดไป และมันจะดีขึ้นเรื่อยๆ
พออ่านบทความจบ ความรู้สึกก็คือ ใช่ นี่มัน ใช่มากๆ สำหรับวิธีปฏิบัติที่ SCK ที่เราได้มาเรียนรู้และฝึกพลังลมปราณเพิ่ม ผ่านการสอนน้องๆ WLB (โดนบังคับให้สอนแหละ จุ๊ๆ 555+)
อันที่จริงมันก็มีศาสตร์นี้อยู่แล้วในสายวิชา Project Management เรียกว่า WBS
- Work package = งานที่วางแผนไว้และอยู่ระดับล่างสุดของ WBS ช่วยในการประมาณต้นทุนและระยะเวลาสําหรับขอบเขตของงาน
- Activities = 1 Work package สามารถประกอบด้วยกิจกรรมมากมาย ที่สมาชิกในทีมโครงการตั้งแต่หนึ่งคนขึ้นไปจะต้องดําเนินการ เป็นหน่วยงานเล็กๆ ที่ต้องดําเนินการ เพื่อให้บรรลุขอบเขตของโครงการ (ถ้าให้เทียบ เราจะเรียกตัวนี้ว่า Tasks)
โดยปกตินิสัยส่วนตัวของข้าพเจ้าก็เป็นมนุษย์ทำอะไรเป็นขั้นตอน มีจุดเช็คระยะอยู่แล้ว ขนาดชีวิตประจำวัน เช่น วันหยุดที่ต้องทำงานบ้าน ยังมีขั้นตอนต่างๆ ในหัวอยู่ตลอด พร้อมเวลาที่คิดว่าจะทำ อะไรที่ต้องทำก่อนหลัง อะไรที่ทำพร้อมกันได้ (ฮืออ ทำไมเป็นคนแบบนี้)
คนเรามันจะแตกงานใหญ่ให้เป็นงานย่อยได้ มันก็ต้องเคยทำมาก่อน มันถึงจะมีของอยู่ในหัว ถ้าไม่เคยทำ ก็แปลว่า ต้องไปขอคำปรึกษาคนที่เคยทำ แต่สุดท้ายแล้ว ก็ต้องไปทดลองทำเองอยู่ดี ถึงจะรู้ว่า มันต้องทำอะไรบ้าง และใช้เวลาเท่าไหร่
คนไม่เคยทำเลย กับคนที่ทำสิ่งนี้มาเป็นสิบปี มันย่อมใช้เวลาไม่เท่ากันอยู่แล้ว
(ประสบการณ์ตรง) ณ 5 Days Workshop หลายๆ รุ่น ที่ Site ของลูกค้า พี่พฤทธิ์ได้เคยกล่าวสิ่งเหล่านี้ไว้กับทีมงาน (อาจจะไม่ได้ตามนี้ แต่เนื้อหาแบบนี้แหละ)
- ถ้ามันมีงานที่เราไม่รู้ว่ามันต้องทำยังไง มันก็คือ Task หนึ่งที่เราต้องเขียนว่า ไปศึกษาหาความรู้ แต่ผลของการศึกษานั้นคืออะไร? ใช้เวลาเท่าไหร่ถึงจะได้ผลนั้น?
- ถ้ามันต้องแก้บั๊ก (ที่ยังหาทาง Reproduce ไม่ได้ แต่ User เป็นคนแจ้งมา) ถ้าทีมงานใส่มาจัดเต็ม 3 ชั่วโมง เพื่อหาทางแก้บั๊กนั้น (ที่ไม่รู้หนทางจะสร้างบั๊กนั้นด้วยซ้ำ!) พี่พฤทธิ์ก็จะให้ลองแบ่งย่อยอีกว่า ถ้าเป็นทีละ 1 ชั่วโมงแล้วเช็คระยะกับ PO จะดีไหม >> อันนี้เราคิดเอง: สุดท้ายแล้ว ถ้ามันหาไม่เจอจริงๆ อาจจะต้องเก็บไว้ในใจว่ามันไม่หายไปไหน แต่มันหาไม่เจอ ถ้าสร้างบั๊กเองไม่ได้ มันจะหาทางแก้ได้ยังไง แต่รอบหน้าที่ User แจ้งมา เราจะต้องลงรายละเอียดมากกว่านี้ว่าเขาทำอะไรลงไป ด้วยเครื่องแบบใด Server แบบใด เป็นต้น
ถามว่าอยู่ๆ จะขยันอ่าน แปล สรุป ไหม ก็ไม่หรอกนะ โดนฝากมาแหละ
ว่าแต่ เสพ นี่มันใช้กับบทความได้ด้วยเหรอ ทำไมให้ความรู้สึกเหมือน เสพยา 555+
