จะเกิดอะไรขึ้นหากคุณลักษณะที่รวมเข้ากับการพัฒนาถูกเลื่อนออกไปโดยผู้บริหาร?


53

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

ปัญหาคือฟังก์ชั่นนี้ได้รับการผสานเข้ากับการพัฒนาเมื่อเสร็จสิ้นพร้อมกับคุณสมบัติอื่น ๆ ทั้งหมดที่เราคาดว่าจะมีการถ่ายทอดสดในรุ่นถัดไปดังนั้นเราจึงไม่สามารถผสาน dev -> test -> master เหมือนที่เราทำ

เราจะหลีกเลี่ยงปัญหานี้ได้อย่างไร?


ขึ้นอยู่กับมุมมองของคุณเกี่ยวกับวิธีที่คุณต้องการแก้ไขคำถามนี้เหมาะสำหรับสถานที่ทำงานหากคุณไม่ได้มองหาวิธีแก้ไขปัญหาทางเทคนิค
Malavos

คำตอบ:


74

วิธีหนึ่งคือการตั้งค่าสถานะคุณลักษณะ มันสามารถอยู่ในฐานรหัส แต่ถูกปิดใช้งานโดยการกำหนดค่า

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


9
การตั้งค่าสถานะไม่ได้หมายความว่าเพิ่มความพยายามในการทดสอบรหัสสองเท่าหรือไม่ คุณต้องทดสอบทั้งสองเส้นทาง

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

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

3
เรามีฟีเจอร์ที่กำลังพัฒนาเป็นเวลา 6 เดือนขึ้นไปซึ่งถูกซ่อนไว้โดยFeature TogglingDoc Brown เรียกมันว่า สิ่งนี้ยังช่วยให้เราสามารถทดสอบคุณสมบัติ (หรือไม่ใช้) ในสภาพแวดล้อมที่ไม่ใช่การผลิต บางครั้งคุณสมบัติเหล่านี้จะเพิ่มไปยังคุณสมบัติที่มีอยู่ซึ่งในกรณีนี้เราควรมีการทดสอบหน่วยสำหรับทั้งชุดคุณลักษณะเก่าและใหม่ การทดสอบหน่วยแต่ละครั้งจะตั้งค่าสถานะเป็นสิ่งที่จำเป็นต้องทำการทดสอบปัจจุบัน
ps2goat

25

เราจะหลีกเลี่ยงปัญหานี้ได้อย่างไร?

จากมุมมองกระบวนการคิดออก:

  • ใครเป็นผู้ตัดสินใจว่าจะเริ่มงานนี้?
  • เหตุใดการตัดสินใจปล่อยคุณลักษณะนี้จึงเปลี่ยนไป
    • พลาดความคาดหวัง?
    • miscommunication?
    • การสนับสนุนทางธุรกิจไม่เพียงพอ?
    • ไม่มีส่วนร่วมของลูกค้า?

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


9
+10 ทันทีที่ฝ่ายจัดการเริ่มสงสัยว่าจะมีการเปิดตัวคุณลักษณะดังกล่าวพวกเขาควรแจ้งให้ผู้พัฒนาทราบเพื่อให้คำนึงถึงการลบที่เป็นไปได้เมื่อตัดสินใจที่จะผสานคุณสมบัติเข้ากับการพัฒนา
Bart van Ingen Schenau

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

11
หากมีคนในองค์กรของคุณที่มีพลังเพียงพอที่จะปฏิเสธที่จะยอมรับความผิดและเด็กที่ไม่ต้องการหลีกเลี่ยงความผิดพลาดอย่างเพียงพอคุณควรยังคงมีปัญหาหลังการตายสำหรับข้อมูลของคุณเอง คุณไม่ต้องการบอกพวกเขา (หรือเขียนลงอย่างชัดเจนเกินไป) ที่กล่าวว่า enderland ไม่ได้ใช้คำว่า "ตำหนิ" และหากองค์กรตีความคำแนะนำนี้ว่า "ค้นหาว่าใครควรตำหนิ" นั่นก็เป็นปัญหาสำหรับองค์กรในการทำงาน ทั้งหมดนี้บอกว่า "เข้าใจว่าทำไมปัญหาเกิดขึ้น" ซึ่งจำเป็นต่อการหลีกเลี่ยงในอนาคต
Steve Jessop

2
ฉันเห็นด้วยอย่างสมบูรณ์นี่เป็นความผิดพลาดของการจัดการไม่ใช่นักพัฒนา
durron597

3
@enderland จุดของฉันคือคุณไม่สามารถหลีกเลี่ยงปัญหาบางอย่างดังนั้นคุณต้องพิจารณาวิธีการแก้ไขสถานการณ์ หวังว่าคุณจะไม่ได้ไปไกลขนาดนั้นบ่อยนัก แต่มันต้องเกิดขึ้นไม่ช้าก็เร็วดังนั้นจงวางแผนให้เหมาะสม
gbjbaanb

19

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

ฉันเดาว่าคุณจะประกาศ "ปิดใช้งานการสมัครสมาชิกโดยอัตโนมัติด้วยการกำหนดค่า" เพียงแค่เป็นคุณสมบัติเพิ่มเติม (เป็นเพียงรูปแบบของคุณสมบัติการสลับ ) ดังนั้นสิ่งนี้จะรวมเข้ากับเวิร์กโฟลว์ของคุณได้อย่างราบรื่น คุณสามารถประเมินความพยายามถ้าคุณชอบคุณสามารถใช้สาขาฟีเจอร์สำหรับมัน (หรือไม่ถ้าคุณไม่ได้ใช้สาขาฟีเจอร์สำหรับปัญหาดังกล่าว) และคุณสามารถใช้โฟลว์ "ผสาน dev -> test -> master" ที่คุณอธิบายได้

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


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

@Gusdor: ดูการแก้ไขของฉัน
Doc Brown

1

นี่เป็นปัญหาที่แน่นอนที่ฉันมีกับ gitflow และ GitHub flow และดูเหมือนว่าเมื่อมีแอปพลิเคชันบนเว็บเกิดขึ้นบ่อยครั้ง - หรือมากกว่าปกติ ดูเหมือนว่าคุณจะแก้ไขปัญหานี้ย้อนหลัง (ดังกล่าวข้างต้น) หรือเชิงรุก (ตัวอย่างด้านล่าง)

ฉันได้สร้าง 'กลุ่มบันเดิล' นอกเหนือจากสาขา gitflow มาตรฐานแล้ว บันเดิลประกอบด้วยคุณลักษณะทั้งหมดที่พร้อมสำหรับ uat / qa รายการคุณลักษณะของ uat / qa ถูกสร้างขึ้น สิ่งเหล่านี้ถูกรวมเข้าในบันเดิลชั่วคราวและบันเดิลนั้นจะถูกปรับใช้กับ uat / qa การแก้ไขข้อผิดพลาดใด ๆ ที่เกิดขึ้นในสาขาฟีเจอร์ดั้งเดิมและที่ได้รับการ remerged กลับเข้าไปในมัดและปรับใช้ สิ่งนี้แยกการปล่อยที่กำลังจะมารวมถึงการทดสอบคุณลักษณะเหล่านั้นด้วยกันก่อนที่พวกเขาจะหาทางไปยังสาขาการพัฒนา สาขาที่ได้รับการอนุมัติจะได้รับคำขอดึงเข้าสู่การพัฒนา - ปฏิบัติตามกระบวนการ gitflow คุณสมบัติการทดสอบที่พร้อมใช้งานสามารถเพิ่มหรือลบออกจากสาขาชุดรวมชั่วคราวและปรับใช้ใหม่

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

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

ด้วยส่วนเสริมของ GUI อาจเป็นการดีที่สุดที่จะเลือกกิ่งคุณลักษณะต่อการปรับใช้กลุ่ม - โดยคำนึงถึงระบบอัตโนมัติ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.