การควบคุมเวอร์ชันและค่าใช้จ่ายในการติดตามบั๊กต่อการเปลี่ยนแปลงมากเกินไปหรือไม่

ฉันทำงานในสถานที่ที่มี CVS-crazy และ Bugzilla-nuts

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

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

สถานการณ์ตัวอย่าง:

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

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

ที่งานอื่น ๆ ฉันจะเข้าไปแก้ไขข้อบกพร่อง ผมแทบจะไม่ได้จำใช้ SCM แม้ว่างานที่ฉันได้มีทุกคนได้ใช้มัน: นั่นเป็นเพราะที่งานอื่น ๆ ทุกคนเขาก็เก็บมันออกจากทาง

มีจุดที่กระบวนการได้รับในทางและกลายเป็นจุดสิ้นสุดแก่ตัวเอง? นั่นคือวิศวกรรมแม้แต่เหรอ?

มีจุดที่กระบวนการได้รับในทางและกลายเป็นจุดสิ้นสุดแก่ตัวเอง?

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

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

• Apple (Apple ฉันถูกสร้างขึ้นโดยวิศวกร1คนมี บริษัท 3 คนในตอนนั้น)
• Google (สร้างโดยโปรแกรมเมอร์2 คน )
• Facebook ( 1 -man พยายามเดิม)
• Microsoft ( บริษัท2 -man ในปี 1975)

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

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

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

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

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

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

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

ในสถานการณ์อื่น ๆ ค่าใช้จ่ายจะทำให้ธุรกิจ เวลาที่จะไปต่อ

คำถามนี้มีคำถามสองข้อจริง ๆ ซึ่งต้องแยกต่างหาก:

ทำไมบางทีมมีกระบวนการพัฒนาที่เข้มงวด?

คำตอบง่ายๆก็คือถ้าพวกเขาไม่ทำผิดก็เกิดขึ้น ข้อผิดพลาดราคาแพง สิ่งนี้เป็นจริงสำหรับการพัฒนาและเป็นจริงสำหรับส่วนที่เหลือของฟิลด์ไอทีเช่นกัน (sysadmins, DBAs ฯลฯ )

นี่เป็นเรื่องยากมากสำหรับนักพัฒนาและพนักงานไอทีที่จะเข้าใจเพราะพวกเราส่วนใหญ่เคยทำงานใน "สุดขั้ว" - บริษัท ใหญ่ที่มีสไตล์ฟอร์จูนอย่างน้อยหนึ่งโหลนักพัฒนาและกระบวนการที่เข้มงวดในการติดตามหรือ ขนาดเล็ก, micro-ISV หรือแม้กระทั่งงานอิสระที่ผู้คนไม่พลาดอย่างรุนแรงหรือค่าใช้จ่ายในการสกรูต่ำ

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

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

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

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

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

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

ดังนั้นคุณมีตัวเลือกสามตัวเลือก: (a) สร้างมาตรฐานฮาร์ดแวร์และ จำกัด การใช้งานไลบรารีของบุคคลที่สามอย่างรุนแรงซึ่งมีค่าใช้จ่ายสูงและอาจกระทบต่อประสิทธิภาพการผลิตอย่างมากหรือ (b) ตั้งค่าเซิร์ฟเวอร์สร้างซึ่งต้องใช้ความร่วมมือจากกลุ่มดูแลระบบ นักพัฒนาเต็มเวลาเพื่อรักษามันหรือ (c) ให้นักพัฒนาทำเองด้วยการแจกจ่ายเครื่องเสมือนมาตรฐานและบอกให้นักพัฒนาสร้างต่อไป ชัดเจน (b) เป็นทางออกระยะยาวที่ดีที่สุด แต่ (c) มีความสมดุลของความน่าเชื่อถือและความรวดเร็วในระยะสั้นที่ดีกว่า

รอบต่อไปเรื่อย ๆ "นโยบาย" ทุกครั้งที่คุณเห็นมักได้รับการจัดตั้งขึ้นเพื่อแก้ไขปัญหาจริง ดังที่ Joel Spolsky เขียนมาตั้งแต่ปี 2000 (ในหัวข้อที่แตกต่างไปจากเดิมอย่างสิ้นเชิง แต่เป็นประเด็นที่เกี่ยวข้อง):

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

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

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

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

นั่นอธิบายว่าทำไมกระบวนการถึงอยู่ตรงนั้น แต่มันไม่ได้เป็นเรื่องราวทั้งหมด อีกครึ่งหนึ่งคือ:

ทำไมกระบวนการจึงยากที่จะติดตาม

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

ตัวอย่างเช่นในคำถามเดิมฉันเห็นปัญหาต่าง ๆ :

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

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

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

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

• การย้ายจาก Bugzilla ไปเป็นระบบติดตามบั๊กที่ใหม่กว่านั้นจะทำให้ส่วนหนึ่งของประสบการณ์นั้นเจ็บปวดน้อยลง

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

หากนักพัฒนาใช้เวลาหนึ่งสัปดาห์ในการติดตามเวลาของพวกเขาเกี่ยวกับงานที่ไม่ได้เข้ารหัสคุณสามารถเพิ่มได้อย่างง่ายดายแสดงการจัดการที่ (เช่น) การลงทุนที่ไม่มีเงินทุนศูนย์การลงทุน 100 ชั่วโมงต่อชั่วโมงในการอัพเกรดเป็น Mercurial ลดชั่วโมงการทำงานสูงสุดถึง 10 ชั่วโมงต่อสัปดาห์ในการแก้ไขข้อขัดแย้งการรวมกันนั่นคือผลตอบแทน 10 สัปดาห์และแน่นอนว่าพวกเขาจะเห็นด้วย แนวคิดเดียวกันกับ build servers (CI) หรือการติดตามบั๊กที่ดีขึ้น

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

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

ส่วนด้านบนดูเหมือนจะคุ้มค่าต่อการขยายตัว

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

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

ฉันต้องการที่จะทราบว่า บริษัท ที่เรา (นักพัฒนา) ต้องหันมาใช้วิธีDIYแบบนี้ยังไม่บรรลุนิติภาวะด้านไอที ที่ผู้จำหน่ายซอฟต์แวร์ที่มีประสบการณ์มากขึ้นฉันเห็นสิ่งต่าง ๆ เช่นที่ผู้จัดการส่วนใหญ่ทำเอง และตามกฎแล้วพวกเขามีประสิทธิผลมากกว่าที่โปรแกรมเมอร์ของเรา มีประสิทธิภาพมากขึ้น

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

ดังนั้นมันอาจเป็นความชั่วร้ายที่จำเป็น

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

ไม่มีใครในใจถูกต้องที่ปฏิเสธกระบวนการที่รวดเร็วและดีกว่าหากมีการอธิบายอย่างถูกต้อง

แต่พร้อมที่จะปกป้องการโต้แย้งของคุณเพื่อปรับการเปลี่ยนแปลง

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

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

วินัยของวิศวกรรมซอฟต์แวร์นั้นมีอยู่โดยกำเนิด "ทั้งหมดเกี่ยวกับกระบวนการ" ดังนั้นจึงสงสัยว่า "เป็น" หรือไม่

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

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

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

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

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

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

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

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

คุณอาจทำงานในบริษัท ที่มุ่งเน้นกระบวนการ ฉันจะพยายามหาบริษัท ที่มุ่งเน้นผลลัพธ์แทนซึ่งมันสำคัญกับสิ่งที่คุณทำไม่ใช่วิธีที่คุณทำ

ใน บริษัท ของฉันเรามี "กระบวนการ" ด้วย (แต่มันง่ายมาก) .. แต่เมื่อได้รับในทางที่ฉันผิดกฎและข้ามขั้นตอน ไม่มีใครจะพูดอะไรกับฉันตราบใดที่ฉันไม่ทำลายอะไรโดยใช้ทางลัดเพราะฉันได้รับผลลัพธ์

มีจุดที่กระบวนการได้รับในทางและกลายเป็นจุดสิ้นสุดแก่ตัวเอง? นั่นคือวิศวกรรมแม้แต่เหรอ?

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

1. ดูเหมือนว่าคุณจะได้รับมอบหมายให้ทำงานแก้ไขข้อบกพร่องไม่ใช่งานสถาปัตยกรรมหรือออกแบบ
2. เพื่อนร่วมงานของคุณดูเหมือนจะมีวิธีการแก้ไขที่ จำกัด (รวมการแก้ไขข้อบกพร่อง VM) เพื่อให้มีประสิทธิภาพมากขึ้นคุณดูเหมือนจะไม่ทำตามตัวอย่างที่เหมาะสม

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

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

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

• ในการแก้ไขข้อบกพร่องครั้งแรกฉันต้องได้รับเครื่องเสมือนใหม่ที่สะอาดและใหม่ สภาพแวดล้อมการทดสอบ
• จากนั้นฉันก็สร้างสาขาสำหรับการแก้ไขข้อบกพร่องเพียงครั้งเดียวตามสาขาอื่นที่อธิบายไว้ในรายงาน Bugzilla - คุณทำซ้ำสภาพแวดล้อมที่พบข้อผิดพลาดใน ... วิธีนี้ไม่มีเหตุผล?
• ฉันติดตั้งสาขาบนเครื่องตั้งค่าที่ ฉันแก้ไขข้อผิดพลาด ฉันเช็คอิน - กระบวนการ dev พื้นฐาน
• ... ปล่อยให้มันและเครื่องให้ผู้อื่นทดสอบด้วย - ทีมผสานของคุณอาจต้องการให้สิ่งนี้สามารถยืนยันการแก้ไขได้หากการรวมไปทางทิศใต้
• ถ้าอย่างนั้นฉันต้องเข้าไปในซอฟต์แวร์ควบคุมบั๊กและอธิบายสิ่งที่ฉันทำ - ถ้าคุณอยู่ในร้านที่ไม่ทำแบบนี้ ... ทำไมคุณถึงติดตามบั๊กเลย?
• และเขียนกรณีทดสอบพร้อมทุกขั้นตอน - ฉันอาจจะผิด แต่ดูเหมือนว่าจะเป็นทิศทางของ 'เด็กสุดเจ๋ง' ทุกอย่างกำลังดำเนินอยู่
• ในที่สุดคนอื่นก็รวมมันกับการเปิดตัว - และหลายขั้นตอนข้างต้นมีไว้เพื่อให้งานของพวกเขาง่ายขึ้น

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

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

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

สำหรับข้อบกพร่องในการทำงานเช่นเดียวกับที่คุณกำลังอธิบายกระบวนการของเราจะเป็นดังนี้:

1. ฉันทดสอบข้อบกพร่องใน VM (รายงานโดยลูกค้าหรือระหว่างการทดสอบเชิงสำรวจของฉันหรือ w / e)
2. พบข้อบกพร่อง / ทำซ้ำ
3. ฉันสร้างข้อผิดพลาด ข้อบกพร่องรวมถึง:
   • repro เต็มรูปแบบจากจุดของการติดตั้งไปยังจุดที่เห็นข้อบกพร่อง
   • ลิงก์ไปยังสแน็ปช็อตของ VM (ถ้าฉันคิดว่าผู้พัฒนาต้องการมัน ... ฉันจะสแนปชอตของมันในกรณีที่พวกเขาขอมัน)
   • ข้อมูลระบบการตั้งค่าพิเศษใด ๆ ที่ฉันต้องการ
4. ข้อผิดพลาดนั้นได้รับมอบหมายให้ dev ขณะที่พวกเขากำลังแก้ไขปัญหาฉัน:
   • สร้างกรณีทดสอบ
   • เขียน (หรือแปลง) การทดสอบด้วยตนเองลงในการทดสอบอัตโนมัติ

จากนั้นฉันรอการแก้ปัญหาและช่วยเหลือผู้พัฒนาในวิธีที่พวกเขาต้องการ เมื่อกลับมาได้รับการแก้ไขฉัน:

1. เรียกใช้กรณีทดสอบอัตโนมัติและรุ่นด้วยตนเอง (บางครั้ง) เพื่อยืนยันการแก้ไข
2. ปิดบั๊ก

TL; DR: ถ้าคุณไม่มีผู้ทดสอบคุณก็ต้องใช้บ้าง หากคุณมีบางอย่างพวกเขาจะไม่ 'ทำส่วนของพวกเขา'

Tom DeMarco:

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

... ยิ่งคุณมุ่งเน้นไปที่การควบคุมยิ่งมีโอกาสมากขึ้นที่คุณจะทำงานในโครงการที่พยายามส่งมอบสิ่งที่มีมูลค่าค่อนข้างน้อย

ในใจของฉันคำถามที่สำคัญกว่าการควบคุมโครงการซอฟต์แวร์คือทำไมเราทำโครงการมากมายที่ให้คุณค่าส่วนเพิ่มเช่นนี้ ...

วิศวกรรมซอฟต์แวร์: เวลาที่ความคิดมาถึงแล้ว

"จากนั้นฉันจะสร้างสาขาสำหรับการแก้ไขข้อบกพร่องครั้งเดียว"

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

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

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

ดังนั้นฉันคิดว่ากระบวนการอาจจะ“ เหนือกว่า” แต่ปัญหาที่แท้จริงคือการขาดเครื่องมืออัตโนมัติที่กำหนดเองเพื่อรองรับกระบวนการ

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

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

CVS หรือระบบการจัดการการกำหนดค่าใด ๆ ก็ไม่เลว น่าเสียดายที่วิธีการใช้งานโดยไม่ทราบว่ามันมีจุดประสงค์อะไรทำให้เกิดอาการปวดร้าวใน! @ # $ สำหรับทั้งองค์กร

หากต้องการทำความเข้าใจอย่างรวดเร็วเกี่ยวกับสิ่งที่ Agile เป็นจริงเกี่ยวกับการอ่านหนังสือ "การปฏิบัติของนักพัฒนา Agile" โดย Venkata Subramaniam มันเขียนเป็นภาษาที่เข้าใจได้ง่าย

ขอให้คุณโชคดี!