การรับมือกับโครงการที่ไม่รู้จบ

เรามีเว็บไซต์ขนาดใหญ่ (1200+ ชั่วโมง) ที่มีหนี้สินทางเทคนิคจำนวนมาก สาเหตุส่วนใหญ่เกิดจากสาเหตุ (ตามปกติ) ต่อไปนี้

1. โปรแกรมเมอร์หลายคนที่เดินทางมาระหว่างการพัฒนา
2. การเปลี่ยนแปลงข้อกำหนดในระหว่างการพัฒนา
3. เพิ่มฟังก์ชันการทำงานจำนวนมากเข้ามา (ในช่วงเวลาสั้น ๆ )

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

เนื่องจากหนี้ทางเทคนิคที่เราใช้จ่ายมากชั่วโมงการแก้ไขหรือตรวจสอบปัญหาที่มักพบต้นกำเนิดของพวกเขาในหนึ่งดังต่อไปนี้:

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

เรามีปัญหาทุกวันและเราได้ลองทำสิ่งต่าง ๆ เพื่อให้หยุดชะงัก:

1. สร้างเอกสารทางเทคนิคเกี่ยวกับการนำเข้าการชำระเงินและการทำงานทั่วไปของเว็บไซต์
2. มีการประชุมในช่วงเริ่มต้นของสัปดาห์ - พูดคุยเกี่ยวกับปัญหาในปัจจุบันหรือการปรับปรุงและวิธีที่พวกเขาควรได้รับการแก้ไข
3. มีแผนการทดสอบ โปรแกรมเมอร์ A การทดสอบ B, B ทดสอบ C และ C การทดสอบ A. จากนั้น Project Manager ของเราจะทำการทดสอบ เกี่ยวกับผลกระทบของคุณลักษณะที่เราใช้งานในสภาพแวดล้อมการจัดเตรียมและให้ลูกค้าตรวจสอบด้วยตัวเอง

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

ฉันคิดว่ามีโปรแกรมเมอร์จำนวนมากทำงานในโครงการขนาดใหญ่แล้วสิ่งนี้ นั่นคือเหตุผลที่ฉันมาที่คำถามของฉัน:

เราจะทำอะไรได้บ้างหรือคุณจะทำอย่างไรเพื่อหลีกเลี่ยงปัญหาเหล่านี้ในโครงการขนาดใหญ่

แก้ไขเล็กน้อยข้อมูลเพิ่มเติม:

1. เราใช้การควบคุมเวอร์ชัน (SVN)
2. เรามีกระบวนการพัฒนา DTAP

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

ฉันพนันว่ามันใหญ่เกินไปที่จะเริ่มเขียนบททดสอบเพราะมันไม่มีใครรู้วิธีทดสอบหน่วยก่อนหน้าคุณ (และด้วยความโชคดีที่คนอื่นในทีมของคุณ) และเป็นไปไม่ได้ที่จะรู้ว่าจะเริ่มต้นที่ไหนและอาจเป็นไปไม่ได้ ทดสอบเพราะอาศัยการใช้งานที่แน่นอนและข้อมูลที่เป็นรูปธรรมดังนั้นจึงใช้เวลานานเกินไปในการตัดเอาสิ่งเหล่านั้นออกไปยังส่วนต่อประสาน, mocks, stubs และสิ่งที่คล้ายกันเพื่อให้สามารถทดสอบได้ตั้งแต่แรก ฉันพนันได้เลยว่าคุณไม่สามารถไปและปรับโครงสร้างสิ่งที่ต้องได้รับการปรับสภาพใหม่เพราะมันแน่นเกินไปและเนื่องจากไม่มีการทดสอบใครจะรู้ว่าอะไรจะเกิดความเสียหายโดยการแก้ไขโค้ดที่ไม่ดี ในระยะสั้นอาจเป็นมะเร็งเกินไปที่จะแก้ไขอย่างจริงจัง แต่แน่นอนว่ามันไม่สามารถถูกตัดออกและเริ่มใหม่ได้

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

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

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

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

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

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

ฉันขอแนะนำให้คุณเพิ่มการทดสอบที่ใช้ CI บางส่วนโดยพื้นฐานแล้วในส่วนที่ผิดพลาดบ่อยที่สุด ที่จะช่วยให้คุณเพิ่มคุณภาพในขณะที่ทำงานในโครงการ

นอกจากนี้ยังมีความชัดเจนมากขึ้นว่าพื้นที่ / ฟังก์ชันการทำงานแตกหักบ่อยขึ้นและทำให้ง่ายต่อการตัดสินใจว่าส่วนใดที่ต้องมีการปรับโครงสร้างใหม่หรือการทดสอบเพิ่มขึ้นอย่างน้อย

การเพิ่มความเสี่ยงในการทดสอบด้วยตนเองมากขึ้นทำให้โครงการมีความผิดพลาดในแง่ของ $$$ & เวลาที่ต้องการต่อการเพิ่มคุณสมบัติ

การตรวจสอบโค้ดบางอย่างนั้นดี แต่อาจเป็นส่วนหนึ่งของ A-> B-> C-> รูปแบบการทดสอบ (อาจจะรีวิวรหัสในทิศทางอื่น?)

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

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

1) โดยทั่วไปแล้วพวกเขาจะไม่ขัดขวางการเมืองในสำนักงานและความสมดุลของอำนาจ 2) พวกเขาประสบความสำเร็จในการสร้างภาพลวงตาของการควบคุมโดยผู้บริหารแทนที่จะตีหัวใจของปัญหา

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

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

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

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

เมื่อก่อนฉันเคยอยู่ในจุดเดิม ฉันไม่ได้ต้องขอบคุณกฎง่าย ๆ สองข้อ:

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

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

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

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

กระบวนการไม่ดีเมื่อมีการใช้งานน้อยหรือมากเกินไป ฉันคิดว่าคุณอยู่ในสถานะเดิม

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

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

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

ไชโย Jas

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

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

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

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

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

ทำให้การสร้างและปรับใช้รหัสของคุณเป็นเรื่องง่าย พยายามทำให้เวลาในการก่อสร้างสั้นลง ยิ่งสร้างได้ง่ายเท่าไหร่มันก็ยิ่งสร้างได้เร็วเท่าไหร่ก็ยิ่งสร้างได้เร็วเท่านั้น

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

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

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

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

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