การต่อสู้ทำให้รู้สึกเมื่อใช้แบ็กเอนด์คอมไพเลอร์ใหม่หรือไม่?

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

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

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

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

ฉันวางแผนที่จะพยายามติดตามการต่อสู้ แต่ฉันเพิ่งผ่านการเคลื่อนไหวหรือไม่

มีแนวทางปฏิบัติที่แนะนำสำหรับโครงการประเภทนี้หรือไม่?

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

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

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

แน่นอนการต่อสู้มีประโยชน์ มันเป็นวิธีการที่ทำสองสิ่งให้คุณ:

1. ช่วยให้โครงการของคุณปรับตัวเข้ากับการเปลี่ยนแปลงและ
2. ช่วยให้คุณสามารถติดตามความคืบหน้าและได้รับแนวคิดเมื่อมันจะเสร็จสิ้น

ดังนั้นจึงมีค่าในการใช้มัน

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

ฉันไม่เห็นว่าแต่ละเรื่องสามารถเจรจาต่อรองได้ - พวกเขาทั้งหมดจำเป็นสำหรับคอมไพเลอร์ที่ใช้งานได้

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

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

เรื่องราวต่าง ๆ มีลำดับความสำคัญเท่ากันและไม่สำคัญว่าฉันจะส่งพวกเขาออกไปเป็นอย่างไร

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

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

นอกจากนี้ยังมีตัวเลือกอื่น ๆ ถ้าคุณได้รับการรวบรวม C-เช่นภาษาพูดอย่างเคร่งครัดคุณต้องการเพียงifและgotoห่วงที่จะมี (แทบจะ) ภาษาการทำงานและคุณสามารถใช้while, forและrepeatเป็นแมโคร สมมติว่าเป็นเรื่องง่ายพอที่จะเขียนใช้ precompiler คุณสามารถมีโซลูชัน stopgap ราคาถูก (เฮ้เรากำลังเจรจาต่อรองหรือไม่ :-)

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

โดยสรุปเพื่อตอบคำถามของคุณโดยตรง: คุณต้องการกระบวนการที่คล่องตัวเมื่อความต้องการของคุณไม่สามารถเปลี่ยนแปลงได้หรือไม่? ไม่อย่างแน่นอน! พวกมันใช้ได้หรือเปล่า อาจจะใช่! พวกเขาคุ้มค่ากับเวลาของคุณหรือไม่ อาจไม่ใช่ - แต่ความต้องการของคุณเปลี่ยนไม่ได้ใช่ไหม จากประสบการณ์ที่ผ่านมา "ข้อกำหนดที่ไม่สามารถเปลี่ยนแปลงได้" => "เจ้าของผลิตภัณฑ์ขี้เกียจ" - ไม่ใช่กฎ แต่ควรคำนึงถึง

TL; DR

การควบคุมการจัดการโครงการทั้งหมดเพิ่มค่าใช้จ่าย อย่าเพิ่มค่าใช้จ่ายที่คุณไม่ต้องการ

การแย่งชิงกันว่าเป็นค้อนที่ผิด (อย่าเป็นเล็บ)

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

นอกจากนี้เมื่อคุณพูดว่า:

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

คุณหมายถึงสองสิ่ง:

1. โครงการมีค่าเป็นศูนย์เว้นแต่เรื่องราวทั้งหมดจะเสร็จสมบูรณ์ 100%
2. เรื่องราวไม่ได้ขึ้นอยู่กับกันและกัน

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

ทางเลือกที่แนะนำ

โครงการพัฒนาใด ๆ ที่อาจได้รับประโยชน์จากการปฏิบัติที่คล่องตัว โดยเฉพาะอย่างยิ่งในกรณีเฉพาะของคุณฉันอยากจะแนะนำ:

1. ตรวจสอบให้แน่ใจว่าเรื่องราวทั้งหมดของคุณมี "คำจำกัดความของการทำ" ซึ่งรวมถึงการทดสอบหน่วยและการยอมรับ
2. บูรณาการและ refactor บ่อยครั้ง; อย่าปล่อยให้ตัวเองเป็นภารกิจการรวมตัวครั้งใหญ่เมื่อสิ้นสุดโครงการ

นอกจากนี้แม้ว่าผลิตภัณฑ์ของคุณจะมีค่าเป็นศูนย์อย่างแท้จริงเว้นแต่เรื่องทั้งหมดจะเสร็จสิ้นฉันจะใช้เวลาในการจัดกลุ่มเรื่องราวเป็นธีมที่คุณสามารถปฏิบัติตามเหตุการณ์สำคัญที่เสร็จสมบูรณ์ ความสามารถในการพูดว่า "ฉันได้ทำคุณสมบัติ foo เสร็จแล้ว" มักจะมีประโยชน์มากกว่าการพูดว่า "ฉันทำเสร็จแล้ว 23/117 เรื่อง" YMMV

ฉันเข้าใจความกังวลของคุณ แต่ฉันเชื่อว่ายังคงมีค่าสำหรับคุณในการใช้การต่อสู้

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

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

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

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

(โปรดทราบว่าฉันไม่เคยทะเลาะกันในโครงการคอมไพเลอร์ใช้คำแนะนำของฉันกับเกลือเม็ด)

ใช่ตราบใดที่คุณจำได้ว่าการแย่งชิงกันไม่ใช่ชุดของกฎที่เข้มงวดในการปฏิบัติตาม คุณสามารถปรับเป็นโครงการของคุณ Sprints, standups, scrums รายสัปดาห์จะยังคงมีประโยชน์เพื่อส่งเสริมการสื่อสารที่ดีระหว่างสมาชิกในทีมและเพื่อให้แน่ใจว่าโครงการจะดำเนินต่อไปในทิศทางที่ตั้งใจไว้

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