รอบการเปิดตัวหนึ่งสัปดาห์: ฉันจะทำให้สิ่งนี้เป็นไปได้อย่างไร


12

ที่ บริษัท ของฉัน (การเริ่มต้นอุตสาหกรรมเว็บอายุ 3 ปี) เรามีปัญหาบ่อยครั้งกับทีมผลิตภัณฑ์ที่พูดว่า "aaaah นี่คือการแก้ไขวิกฤติตอนนี้!" (ไม่ใช่ทุกคนเหรอ?)

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

มีผู้พัฒนา 13 คนและผู้ทดสอบนอกชายฝั่ง 6 คน / 9 คน ทฤษฎีคือนักพัฒนาเพียง 4 คน (และผู้ทดสอบทั้งหมด) จะทำงานในรุ่นที่มีเลขคู่เว้นเสียแต่ว่าจะมีชิ้นงานที่ต้องใช้ความเชี่ยวชาญเฉพาะจากนักพัฒนาอื่น ๆ แต่ละรอบจะมีงาน dev สองวันและงาน QA สองวัน (บวก 1 วันของการกำหนดขอบเขต / triage / ... )

คำถามของฉันคือ:

(a) มีใครบ้างที่เคยมีประสบการณ์กับวงจรการเปิดตัวนี้หรือไม่?

(b) มีใครเคยได้ยินเรื่องความยาวของรอบการเปิดตัวนี้ถึงแม้จะพยายามบ้างไหม?

(c) ถ้า (a) หรือ (b) คุณทำมันบนโลกได้อย่างไร? (ข้อผิดพลาดใด ๆ ที่จะหลีกเลี่ยง ฯลฯ ได้รับการชื่นชมด้วย)

(d) เราจะลดความเสียหายได้อย่างไรหากความพยายามนี้ล้มเหลว


คุณหมายถึงอะไรโดย "งานวิกฤติ"?
Wizard79

คำขอที่เราได้รับคำสั่งให้แก้ไขในวันเดียวกันกับที่ได้รับ การแก้ไขคำถามเพื่อให้ชัดเจนขึ้นในไม่ช้า
Arkaaito

คำตอบ:


8

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

สิ่งที่สำคัญคือคุณต้องการเว็บไซต์ของคุณที่ครอบคลุมอย่างยิ่งโดยการทดสอบอัตโนมัติ - ทั้งการทดสอบหน่วยและการทดสอบการยอมรับ / ข้อกำหนดที่สามารถดำเนินการได้แบบ end-to-end หมายความว่างานสร้างของคุณเป็นแบบอัตโนมัติทั้งหมด ในระดับการยอมรับเราใช้Robot Frameworkซึ่งยอดเยี่ยมสำหรับการสร้างชุดทดสอบที่บำรุงรักษาได้อย่างรวดเร็วด้วยวิธีการใช้คำหลัก สำหรับรูปลักษณ์และความรู้สึกทดสอบในสถานที่ของเราจะทำให้การตรวจสอบคร่าวๆบางอย่าง แต่เรายังมีคู่ของผู้ชายในอินเดียที่จะตรวจสอบอย่างละเอียดมากขึ้นเบราว์เซอร์ที่แตกต่างกัน (มีเว็บไซต์ที่ความช่วยเหลือเกี่ยวกับการจัดเรียงของสิ่งนี้โดยการใช้ภาพหน้าจอสำหรับคุณเช่นBrowserLab )

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

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

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


7

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

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

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

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


ถ้าฉันอาจเพิ่มความคิดเห็นของตัวเองในคำตอบที่ยอดเยี่ยมของ @ Wonko ... บริษัท ของเราใช้เวลาหลายปีในการทำสิ่งที่คล้ายกับ OP เติบโตจาก 6 หรือ devs เป็น 16 ประมาณ 2 ปีที่แล้วเราตัดสินใจที่จะไป Agile เราจ้าง Sr. Dev ด้วยประสบการณ์ Agile เปลี่ยนการวนซ้ำ 2 สัปดาห์ดำเนินการผสานรวมอย่างต่อเนื่อง ฯลฯ ... เรายังห่างไกลจากร้านหนังสือเรียนและมันก็เป็นหลุมเป็นบ่อเป็นครั้งคราว แต่เราได้ตัดบริบทจริงๆ การเปลี่ยนซึ่งเป็นชัยชนะครั้งใหญ่
DevSolo

5

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

มี บริษัท ที่ออก 50 ครั้งต่อวัน โพสต์บล็อกนี้จะอธิบายถึงวิธีที่พวกเขาทำมัน


1

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

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

(a) + (b) IMHO ตามขนาดของทีมคุณควรมีขนาดสูงสุดสองสัปดาห์ หนึ่งสัปดาห์จะทำงานให้กับชายคนหนึ่งที่แสดงหรือทีมเล็ก ๆ (เช่น 2 หรือ 3)

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

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

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


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

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