เอกสารที่คล่องตัว: การปรับสมดุลความเร็วและการเก็บรักษาความรู้

เอกสาร สิ่งประดิษฐ์ และกระบวนการต่างๆ ที่เกี่ยวข้องกับการสร้างเป็นสัญลักษณ์หลักของแบบจำลองน้ำตก การยืมจาก Lean ทำให้ Agile ถือว่าเอกสารจำนวนมากเป็น "ขยะ" ที่ต้องกำจัดให้หมด เพื่อปรับปรุงวงจรชีวิตการพัฒนา

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

แนวทางดั้งเดิมในการจัดทำเอกสารกำลังถูกท้าทาย

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

จุดเน้นของ Agile คือการทำสิ่งต่างๆ ให้สำเร็จและเพิ่มมูลค่าให้กับผู้มีส่วนได้ส่วนเสีย มันถูกสร้างขึ้นในลักษณะที่โมเดลไม่สนับสนุนการทำงานกับอุปกรณ์ต่อพ่วงและกิจกรรมที่ไม่ได้เพิ่มมูลค่าให้กับลูกค้าโดยตรงและทันที

เอกสารใน Waterfall vs. Agile

แต่ละบริษัทมีระดับเอกสารที่แตกต่างกัน ซึ่งสามารถแตกต่างกันได้แม้กระทั่งในระดับโครงการ แต่นี่คือสิ่งที่ขั้นตอนเอกสารทั่วไปดูเหมือนในโครงการ Waterfall และ Agile:

กรณีเอกสาร

Waterfall ส่งเสริมแนวทางการจัดทำเอกสารที่เข้มงวดมากขึ้น ซึ่งอาจดูมากเกินไป แต่ก่อนที่เราจะมองข้ามสิ่งนี้ว่าเป็น "ขยะ" ข้อดีหลายประการคือการมีขั้นตอนเอกสารที่เข้มงวด

โอกาสในการคิดเชิงกลยุทธ์

คนที่ล้มเหลวในการวางแผน วางแผนที่จะล้มเหลว เอกสารบังคับให้ผู้จัดการโครงการต้องนั่งลงและคิดทบทวนสิ่งต่างๆ เพื่อหาทางออกที่ดีที่สุด บางครั้งผู้คนตีความค่า Agile ของซอฟต์แวร์ที่ใช้งานได้ผิดไปจากเอกสารที่ครอบคลุม ซึ่งหมายความว่าไม่จำเป็นต้องมีเอกสารประกอบ จากนั้นพวกเขาก็รีบไปที่ตลาด Paul Adams รองประธานฝ่ายผลิตภัณฑ์ของ Intercom อธิบายว่ากำลังขว้างสิ่งของไปที่ผนังและดูว่ามีอะไรติดอยู่ การออกแบบโซลูชัน การสร้างแผน การไตร่ตรองการกระทำ—กิจกรรมเหล่านี้สร้างคุณค่าด้วยการประหยัดเวลาในการไม่พัฒนาแนวคิดคุณลักษณะทุกอย่างที่อยู่ในใจ

UX และการทำงานที่สม่ำเสมอ

ในขณะที่บริษัทต่างๆ เติบโตจากผู้ก่อตั้งไม่กี่คนเป็นพนักงานหลายร้อยหรือหลายพันคน ทีมต่างๆ จำนวนมากเริ่มทำงานในผลิตภัณฑ์เดียวกันหรือผลิตภัณฑ์ที่เกี่ยวข้องกัน ทีม A อาจคิดว่าสิ่งที่พวกเขากำลังทำอยู่นั้นไม่เกี่ยวข้องกับสิ่งที่ทีม B กำลังทำอยู่ แต่สำหรับผู้ใช้ปลายทาง มันคือผลิตภัณฑ์เดียวกันทั้งหมด แทนที่จะให้ทีมข้ามสายงานทำสิ่งต่าง ๆ ด้วยตนเอง เอกสารที่ชัดเจนเกี่ยวกับประสบการณ์ผู้ใช้และระดับการทำงานจะช่วยหลีกเลี่ยงการไหลของผู้ใช้ที่ไม่ปะติดปะต่อกัน

เอกสารสามารถแปลงเป็นคู่มือผู้ใช้

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

วิธีที่ Agile ลดความต้องการด้านเอกสาร

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

ความหวังคือเอกสารที่ดีจะทำให้พนักงานใหม่ซึ่งทำงานโดยอิสระเป็นส่วนใหญ่ได้อย่างรวดเร็วและรวดเร็ว อย่างไรก็ตาม Agile ช่วยลดความจำเป็นในการจัดทำเอกสารโดยใช้เทคนิคการทำงานร่วมกัน ซึ่งในขณะเดียวกันก็ช่วยลดเวลาในการเริ่มต้นใช้งาน ต่อไปนี้คือวิธีที่ Agile ช่วยลดความจำเป็นในการจัดทำเอกสาร

ปฏิสัมพันธ์ปกติระหว่างทีมผลิตภัณฑ์และสมาชิกทีม Agile

Agile Manifesto ส่งเสริม "บุคคลและปฏิสัมพันธ์ผ่านกระบวนการและเครื่องมือ" เนื่องจากความต้องการมีแนวโน้มที่จะเปลี่ยนแปลงในระหว่างโครงการและมีแนวคิดใหม่ๆ เกิดขึ้น Agile จึงรับประกันความกระจ่างของข้อกำหนดโดยตรงจากแหล่งที่มา แทนที่จะขึ้นอยู่กับสิ่งประดิษฐ์ที่เป็นลายลักษณ์อักษรซึ่งจำเป็นต้องมีการอัปเดตอย่างต่อเนื่อง

การดูแลและการวางแผนช่วยแบ่งเบาภาระงาน

การเตรียมงานค้างและการวางแผนการวิ่งจะแบ่งคุณลักษณะออกเป็นส่วนๆ ที่นำไปใช้ได้เฉพาะเจาะจงที่เข้าใจได้ง่ายและสามารถทำงานได้โดยอิสระ สิ่งนี้จะสร้างโอกาสให้พนักงานใหม่สามารถทำงานได้ตั้งแต่เนิ่นๆ ในขณะที่ยังไม่เข้าใจภาพรวมของโครงการทั้งหมดอย่างถ่องแท้

เรื่องราวของผู้ใช้ให้เอกสารที่มีประสิทธิภาพ

รูปแบบที่เรียบง่ายของเรื่องราวของผู้ใช้ช่วยให้ผู้จัดการโครงการสามารถบันทึกข้อกำหนดขั้นต่ำที่สร้างความเข้าใจร่วมกันระหว่างสมาชิกในทีมทั้งหมด แม้ว่าเรื่องราวของผู้ใช้จะไม่ได้ทำให้เป็น Sprint แต่การสร้างสิ่งประดิษฐ์ของเอกสารนี้มีน้อยมาก เมื่อเรื่องราวของผู้ใช้เคลื่อนเข้าสู่ sprints พวกเขาสามารถถูกทำให้สมบูรณ์และเสริมด้วยข้อมูลที่จำเป็นอื่น ๆ เช่น โครงลวด การออกแบบ เกณฑ์การยอมรับ ฯลฯ กระบวนการนี้ให้การจัดส่งเอกสารที่มีประสิทธิภาพมากซึ่งใช้แล้วทิ้งอย่างสูงและผลิตในขั้นตอนการพัฒนาที่เหมาะสมที่สุด

ลดความต้องการเอกสารรหัส

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

พิธีการเปรียว

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

ทั้งหมดที่กล่าวมาข้างต้นช่วยลดเอกสารและจัดลำดับความสำคัญของการส่งมอบเป้าหมายของโครงการในขณะที่ทำให้แน่ใจว่าไม่มีอะไรสูญหายไปจากการขาดเอกสาร

แนวทางไฮบริดในการจัดทำเอกสาร

บางบริษัทยังคงต้องการมีเอกสารประกอบ แม้จะอยู่ในสภาพแวดล้อมแบบ Agile Agile ไม่ได้กำหนดไว้ล่วงหน้า เนื่องจากแต่ละโครงการมีความแตกต่างกันและมีสถานการณ์เฉพาะที่จำเป็นต้องได้รับการแก้ไข

ด้านล่างนี้คือตัวอย่างบางส่วนของวิธีที่ Agile สามารถใช้ร่วมกับวิธีการจัดทำเอกสารที่ใช้เวลามาก

การรวม UML และ Agile

พิจารณาใช้ภาษาการสร้างแบบจำลองมาตรฐาน เช่น Unified Modeling Language (UML) ซึ่งมีโครงสร้างที่ดีและได้กำหนดเอนทิตีเพื่อให้เห็นภาพระบบ ซึ่งช่วยให้เนื้อหาเรียบง่ายและเน้นสิ่งที่จำเป็น และทำให้ใช้ภาษาเขียนน้อยที่สุด เครื่องมือต่างๆ เช่น StarUML และ Draw.io เป็นตัวเลือกที่สะดวกสบาย

ตัวสร้างเอกสารรหัส

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

การออกแบบโดยละเอียดและเอกสาร UX

การกำหนดข้อกำหนดโดยใช้โครงลวด แบบจำลอง แผนภาพการไหลของผู้ใช้ แผนภาพลำดับ ฯลฯ ช่วยลดความซับซ้อนของขั้นตอนของโครงการ รวมทั้งทำให้ทีมเทคนิคเห็นชัดเจนว่าต้องพัฒนาอะไร เอกสารการออกแบบเป็นวิธีที่ยอดเยี่ยมในการมีเอกสารที่เข้มงวดมากขึ้นในระดับต่างๆ มีเครื่องมือ Wireframing และ UX ให้เลือกสำหรับงานเหล่านี้

เครื่องมือการจัดการโครงการ จัดทำเอกสารโดยอัตโนมัติ

การจัดการโปรเจ็กต์ที่ทรงพลังยิ่งขึ้นและเครื่องมือที่เกี่ยวข้อง เช่น JIRA, Confluence, Asana และ Basecamp มอบวิธีในการเก็บข้อมูลที่เกี่ยวข้องกับโปรเจ็กต์ทั้งหมดไว้ในที่เดียว งานสามารถเชื่อมโยง แท็ก ซ้อน และมอบหมายให้กับสมาชิกในทีมที่แตกต่างกัน ซึ่งสามารถแสดงความคิดเห็นและรายงานปัญหาต่างๆ ได้ การดำเนินการทั้งหมดเหล่านี้ควบคู่ไปกับความยืดหยุ่นในการปรับเครื่องมือเหล่านั้น สามารถสร้างเอกสารจำนวนมากได้โดยไม่ต้องใช้ความพยายามเพียงเล็กน้อยหรือไม่ต้องใช้ความพยายามใดๆ

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

การจัดการเอกสารเป็นพระราชบัญญัติที่สมดุล

ผู้สร้าง Agile Manifesto เขียนว่าพวกเขาให้ความสำคัญกับ "ซอฟต์แวร์ที่ใช้งานได้มากกว่าเอกสารที่ครอบคลุม" อย่างไรก็ตาม พวกเขายังเพิ่มข้อจำกัดความรับผิดชอบว่า “ในขณะที่รายการทางด้านขวามีมูลค่า [พวกเขา] ให้ความสำคัญกับรายการทางด้านซ้ายมากกว่า” Agile ไม่แนะนำให้ลบเอกสาร ทั้งหมด เนื่องจากเอกสารบางฉบับให้คุณค่าอย่างชัดเจน มันเพียงแต่แนะนำว่าลำดับความสำคัญควรอยู่ที่ซอฟต์แวร์ที่ใช้งานได้ และเพิ่มเอกสารเฉพาะเท่าที่จำเป็นโดยขึ้นอยู่กับสถานการณ์ของโครงการและโดยไม่ขัดขวางความก้าวหน้าของการพัฒนาอย่างมาก

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