เปรียวเข้าใจง่าย

มีเรื่องตลกเก่าๆ ที่ว่า “ถ้ามีวิกผมดีๆ สักชิ้น ฉันไม่เคยเห็นเลย” ความลับที่เปิดเผยในฮอลลีวูด: นักแสดงนำเช่น Ted Danson และ Burt Reynolds สวมวิก แต่ไม่ใช่พรมแรคคูน ซึ่งมีราคาแพงมาก ผลิตอย่างประณีต ซึ่งไม่มีใครสามารถแยกแยะได้ว่าแตกต่างจากขนธรรมชาติ

Agile แบ่งปันคุณภาพนี้: เมื่อดีคุณจะไม่สังเกตเห็น ในความเป็นจริงแถลงการณ์ Agile ดั้งเดิมยืนยันสิ่งนี้ในหลักการ: “ชอบคนมากกว่ากระบวนการ” แต่บ่อยครั้งที่องค์กรต่างๆ บิดเบือนกระบวนการ Agile เพื่อหลีกเลี่ยงการเปลี่ยนแปลงไดนามิกภายในที่ยากลำบาก สิ่งนี้นำไปสู่สิ่งที่ Kent Beck ผู้ลงนาม Agile manifesto เรียกว่า 'Scrum But' เช่นเดียวกับใน "เราฝึก Scrum *แต่* ... " (Scrum - จะกล่าวถึงในภายหลัง - มีความเกี่ยวข้องอย่างใกล้ชิดกับ Agile จนมักใช้สลับกัน)

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

ส่งมอบคุณสมบัติที่สำคัญที่สุดโดยเร็วที่สุด

ง่ายใช่มั้ย? แน่นอนว่าความเรียบง่ายไม่ใช่เรื่องง่าย! ผู้คนมักทำให้ Agile ซับซ้อนเกินไป เพราะพวกเขาไม่เคยเห็นมันทำออกมาได้ดีเหมือนกับวิกที่ดีเลย

วิธีที่ครอบคลุมที่สุดสำหรับฉันในการแสดงวิธีที่ถูกต้องในการทำ Agile แบบง่ายๆ ก็คือให้คุณเข้าร่วมโปรเจ็กต์ตั้งแต่เริ่มต้น และ "ก้าวต่อไป" ขณะที่เราทำตามขั้นตอนต่างๆ เนื่องจากเป็นไปไม่ได้ในบทความ ฉันจึงต้องอธิบายกระบวนการแทน ด้วยจิตวิญญาณของ Agile ฉันจะทำมันให้ง่ายที่สุดเท่าที่จะเป็นไปได้ แต่เนื่องจากความเรียบง่ายไม่ใช่เรื่องง่าย มันจึงไม่สั้น ขอแบ่งออกเป็นสามส่วน:
1. หลักการพื้นฐาน
2. แบบฝึกหัดประจำวัน
3. ประเด็นเรื่อง: การประมาณการพัฒนาซอฟต์แวร์

หลักการพื้นฐาน

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

เรียบง่ายและซับซ้อนไม่ตรงกันข้าม ความเรียบง่ายเป็นสิ่งที่ตรงกันข้ามกับความซับซ้อน ซับซ้อน หมายถึง ซับซ้อนเกินความจำเป็น.

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

อะไรคือคุณลักษณะที่สำคัญที่สุดของโครงการของคุณ? มีคำพูดที่นักกีฬาบางคนใช้: “อันดับที่สองเป็นเพียง 'ผู้แพ้คนแรก'” เป็นความรู้สึกที่หยาบ แต่ Agile ต้องการการจัดลำดับความสำคัญที่ไร้ความปรานี หากคุณสมบัติที่สำคัญที่สุดของคุณใช้งานไม่ได้ แล้วมีอะไรอีกในโครงการของคุณที่มีคุณค่าหรือไม่?

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

คุณลักษณะที่สำคัญที่สุดในโครงการซอฟต์แวร์ทั้งหมดคือบางสิ่งบางอย่างที่สอดคล้องกับ "จำเป็นต้องทำงาน" หากเว็บไซต์หรือแอปหรือไลบรารีไม่รวบรวมและดำเนินการ คุณสมบัติอื่นๆ ก็จะไม่มีความสำคัญ

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

การทดสอบด้วยตนเองสามารถทำงานได้ในช่วงแรก แต่เมื่อโครงการเติบโตขึ้น การทดสอบก็จะไร้ประสิทธิภาพ นอกจากนี้ แนวทางปฏิบัติที่ดีที่สุดหลายทศวรรษได้แสดงให้เห็นว่าโค้ดที่เขียนเพื่อให้ทดสอบได้ง่ายมีข้อได้เปรียบมากมาย เช่น มีข้อบกพร่องน้อยลงอย่างมาก รองรับฟีเจอร์เพิ่มเติมได้มากขึ้น และอื่นๆ อีกมากมาย การเขียนโค้ดที่ทดสอบได้นั้นเริ่มต้นได้ยากมาก แต่ในที่สุดจะง่ายขึ้น การไม่ทำมันตั้งแต่ต้นนั้นไม่ใช่ทางเลือก เว้นแต่ว่าคุณต้องการ ต้องการ “นรกแห่งการพัฒนา” ในตอนท้ายของโปรเจ็กต์ เมื่อการเปลี่ยนส่วนใดส่วนหนึ่งของโค้ดทำให้เกิดปัญหาที่อื่น

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

เคล็ดลับสำหรับมือโปร: การทดสอบที่ดูเรียบง่ายเล็กน้อยยังคงมีประโยชน์อย่างมาก อย่าตัดสินการทดสอบจากความครอบคลุม :)

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

“ภาพหนึ่งภาพแทนคำพูดได้นับพันคำ” เป็นเรื่องจริง แต่คุณค่าของคำนับพันคำส่วนใหญ่อยู่ที่ว่าการออกแบบควรมีลักษณะอย่างไร เมื่อคุณให้ภาพแก่นักพัฒนาและขอให้พวกเขาคิดค้นวิธีการทำงานของซอฟต์แวร์ คุณกำลังขอให้พวกเขาตัดสินใจทางธุรกิจ นักพัฒนาควรรู้วิธีการเขียนโปรแกรม การขอให้พวกเขาทำงานนอกพื้นที่นั้นไม่มีประสิทธิภาพ

นักพัฒนาบางคนเก่งในการทำความเข้าใจธุรกิจ ตีความข้อกำหนดทางธุรกิจในการออกแบบ UI และอื่นๆ หากคุณมีคนแบบนั้น นับตัวเองโชคดี แต่คุณอาจยังเสี่ยงต่อภัยคุกคามที่ใหญ่กว่า

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

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

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