เกิดอะไรขึ้นกับ“ ทีมศัลยกรรม” จาก“ ตำนานคนเดือน”?

หลายปีก่อนเมื่อฉันอ่าน The Mythical Man-Month ฉันพบสิ่งต่าง ๆ มากมายที่ฉันรู้จักจากแหล่งอื่น ๆ อย่างไรก็ตามมีสิ่งใหม่ ๆ อยู่ในนั้นแม้จะเป็นหนังสือจากปี 1975 หนึ่งในนั้นคือ:

ทีมผ่าตัด

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

นี่เป็นรูปแบบที่น่าสนใจมากสำหรับการจัดทีมพัฒนาซอฟต์แวร์ แต่ฉันไม่เคยพบมันมาอธิบายไว้ในหนังสือวิศวกรรมซอฟต์แวร์เล่มอื่น ๆ

ทำไมถึงเป็นอย่างนั้น?

• "ทีมศัลยกรรม" เป็นเรื่องที่ผิดปกติหรือเปล่า
• หรือว่ามีการลองและล้มเหลว
  • ถ้าเป็นเช่นนั้นมันล้มเหลวได้อย่างไร?
  • ถ้าไม่ทำไมเราไม่เห็นรูปแบบนั้นถูกนำไปใช้ในโครงการซอฟต์แวร์ในปัจจุบัน

"The Mythical Man-Month" ออกมาในปีที่ฉันเริ่มเรียนมหาวิทยาลัยและเคยใช้ภาษา UUUGE ในปัจจุบัน! :-) สิ่งที่คุณต้องเข้าใจคือความแตกต่างในการพัฒนาซอฟต์แวร์จากนั้นเทียบกับตอนนี้ ย้อนกลับไปในวัน (tm) เกือบทั้งหมดเขียนโค้ดลงบนกระดาษก่อนจากนั้นก็ทำการกดรหัสลงบน (คุณเดา) การ์ดที่ถูกเจาะจากนั้นถูกอ่านรวบรวมเรียบเรียงเชื่อมโยงประมวลผลผลลัพธ์และกระบวนการซ้ำแล้วซ้ำอีก เวลาซีพียูมีราคาแพงและทรัพยากรที่ จำกัด และคุณไม่ต้องการเสีย เหมือนกันและพื้นที่ดิสก์เวลาเทปไดรฟ์ ฯลฯ blah การเสียเวลา CPU ที่ดีอย่างสมบูรณ์ในการคอมไพล์ซึ่งส่งผลให้เกิดข้อผิดพลาด (ตกใจและสยองขวัญ!) คือ ... เอาละเสียเวลา CPU ที่ดีอย่างสมบูรณ์ และนี่คือในปี 1975 ในเวลาที่ Fred Brooks กำลังพัฒนาความคิดของเขาซึ่งเป็นช่วงเวลาซีพียูยุคกลางถึงปลายปี 1960 มีมากขึ้นราคาแพง, หน่วยความจำ / ดิสก์ / อะไรก็ตามที่มี จำกัด มากขึ้น ฯลฯ ฯลฯ แนวคิดเบื้องหลังทีมผ่าตัดคือเพื่อให้แน่ใจว่า One Super Great Rockstar Developer ไม่ต้องเสียเวลา HIS ในงานทางโลกเช่นรหัสตรวจสอบโต๊ะทำงาน, การคีย์การ์ด, ส่งงานรอประมาณ (บางครั้งชั่วโมง) สำหรับผลลัพธ์ Rockstar Dude Developer Man ต้องเขียนโค้ด กองทัพของเขาในกลุ่ม / เสมียน / นักพัฒนาจูเนียร์ควรทำสิ่งต่าง ๆ ที่เป็นเรื่องธรรมดา

ปัญหาคือว่าภายใน 2 ปีของหนังสือของบรูกส์ที่ถูกตีพิมพ์ความคิดพื้นฐานที่อยู่เบื้องหลังทีมผ่าตัดก็พัง:

1. เทอร์มินัล CRT และไฟล์ดิสก์เริ่มแทนที่ปุ่มกดและสำรับไพ่ เวลาคอมพิวเตอร์เริ่มมีราคาถูกลงคอมพิวเตอร์หลายเครื่องก็มีให้ใช้และเวลาตอบสนองงานลดลงอย่างมาก เมื่อฉันไปถึงวิทยาลัย (มหาวิทยาลัยไมอามี, อ๊อกซฟอร์ด, โอไฮโอ, ชั้นเรียน '79, ขอบคุณสำหรับการถาม) ดีการฟื้นตัวของงานประมาณหนึ่งชั่วโมง ในช่วงสัปดาห์สุดท้าย - สี่ชั่วโมงบางทีบางครั้งอาจหกโมง (เราแข่งขันกันเพื่อหาเวลาซีพียูกับ บริษัท เชิงพาณิชย์และมหาวิทยาลัยหลายแห่ง - และผู้ใช้ในเชิงพาณิชย์ได้รับความสำคัญอันดับแรก) ในช่วงปีสุดท้ายของฉันที่ไมอามีจุดออกจากการจัด "คอมพิวเตอร์ที่ใช้ร่วมกัน" ของพวกเขามี IBM 370/145 ของตัวเองติดตั้งในมหาวิทยาลัยและมี HP mini ที่ดีที่ฉันทำงานในเรื่องนั้นทำหน้าที่เป็นสถานี RJE งานประมาณห้านาทีหรือน้อยกว่า ตอนนี้ก็คุ้มที่จะปังรหัสของคุณบน HP ส่งจาก HP ไปยังเมนเฟรมบิดนิ้วโป้ง / สูบบุหรี่และเอาท์พุทของคุณให้ยาวก่อนที่คุณจะสามารถตรวจสอบรหัสของคุณได้

2. ทีมผ่าตัดมีความคิดพื้นฐานที่ว่าคุณ (หรือ "การจัดการ" พระเจ้าช่วยพวกเราทุกคน) สามารถระบุ The Dude Developer Rockstar ได้ ในความเป็นจริงฉันสงสัยว่าเป็นไปได้ มีเป็นนักพัฒนา Rockstar ทุกคนรู้ว่ามัน - การศึกษาได้แสดงให้เห็นความแตกต่างในการผลิตระหว่างพัฒนาที่ดีที่สุดและเลวร้ายที่สุดเท่าที่ 2000% - แต่ระบุว่าคนที่ได้โดยไม่ต้องให้พวกเขาเขียนโค้ดในระยะเวลานานของเวลาเป็นไปไม่ได้มากที่สุด วิธีเดียวที่จะรู้ว่าใครบางคนเป็นนักพัฒนา rockstar คือการให้พวกเขาพัฒนารหัสจริง ๆ แต่ถ้าพวกเขาไม่ใช่ Rockstar Surgical Developer Dude พวกเขาจะทำสิ่งที่น่าตื่นเต้นเช่นโต๊ะตรวจสอบรหัสของเขากดรหัสลงบนการ์ดและ schlepping box ของการ์ดที่ถูกเจาะลงไปที่แผนก Job Entry จากนั้นยืนรอผลการสอบเพื่อให้พวกเขาสามารถ schlep กลับไปหานาย Rockstar Surgical Developer Dude แทนการเรียนรู้ที่จะเขียนโค้ดวิธีเดียวที่ใช้งานได้จริง - โดยการเขียนโค้ด และอื่น ๆ Back In The Day (tm) ไม่มีการแข่งขันการเขียนโปรแกรมไม่มี Stack Overflow คุณไม่มีพีซีที่คุณสามารถเขียนโค้ดได้ทุกเมื่อที่คุณรู้สึกว่ามัน ไม่มีอัลกอริทึมสำหรับหนังสือ Idiots วิธีเดียวที่จะเรียนรู้การเขียนโปรแกรมคือไปโรงเรียนและวิชาเอกในสิ่งที่คุณต้องทำการเขียนโปรแกรมสักเล็กน้อย แต่การเขียนโปรแกรมSE ต่อไม่ได้ดำเนินการอย่างจริงจังและมันก็ถือว่าเป็นสิ่งที่คนไม่ต้องการที่จะทำ ในหลักสูตรวิทยาลัยครั้งแรกของฉัน (SAN151 - รู้เบื้องต้นเกี่ยวกับการวิเคราะห์ระบบดร. ทอม Schaber - ขอบคุณทอม :-) เราได้รับการบอกเล่าจากอาจารย์ผู้สอนว่า "... เราต้องเผชิญกับความจริงที่ว่าเราจะต้องใช้เวลา สองสามปีในฐานะโปรแกรมเมอร์ก่อนที่เราจะกลายเป็นนักวิเคราะห์ระบบ " "สองปีเหรอ?" ฉันคิด "ฉันจะทำอย่างนี้ได้แค่สองปี?!?" ฉันถูกกระแทกอย่างแรง โชคดีที่เขาผิดและฉันได้รับรหัสมานานแล้วตั้งแต่ :-)

3. ทีมศัลยกรรมสันนิษฐานว่าโปรแกรมเมอร์เป็นทรัพยากรที่ค่อนข้างหายาก จริงๆแล้วมันใช้เวลาอีกไม่กี่ปี แต่ด้วยการกำเนิดของพีซีในช่วงต้นยุค 80 ของการเขียนโปรแกรมกลายเป็นสิ่งที่เกินบรรยายใด ๆ ที่จะเข้ามาเกี่ยวข้องราคาของคอมพิวเตอร์เริ่มลดลงราคาของเครื่องมือในการพัฒนาเริ่มลดลง ลูกเห็บ Turbo Pascal - ตามมาตรฐานของวันนี้มันไม่มาก แต่ในเวลานั้นมันเป็น Pascal IDE ที่สมบูรณ์สำหรับประมาณ 40 bucks ซึ่งเป็นถั่วอย่างแน่นอน! ตอนนี้ทุกคนสามารถเข้าสู่การเขียนโปรแกรม - ถ้าคุณสามารถซื้อคอมพิวเตอร์ได้และเมื่อ IBM ตัดสินใจที่จะวาง PCjr (ใช่แล้วพีซีเครื่องแรกของฉันคือหนึ่งในข้อผิดพลาดที่ใหญ่ที่สุดของ IBM :-) ลดราคา 500 เหรียญเพื่อกำจัดไก่งวง geeks ที่ติดฉลากทุกที่ข้ามการชำระเงินค่าเช่าเป็นเวลาหนึ่งเดือน ("ใช่เอ่อฉันรู้ แต่ฉันเอ่อ ... ทำลาย uuvula ของฉันและต้องผ่าตัดและ .. .uh ... ใช่อาทิตย์หน้าไม่มีปัญหาขอบคุณคน ... ) และดูดพวกเขาในราคาขายไฟ จากนั้นใช้เวลามากกว่าที่เราจ่ายให้กับคอมพิวเตอร์เป็นส่วนเสริมเพื่อให้สามารถใช้งานได้ ("ใช่มนุษย์สัปดาห์หน้าแน่นอนอาจ ... " :-)

สิ่งที่ทำให้ฉันเศร้าจริงๆก็คือแม้กระทั่งทุกวันนี้ถ้าคุณถามคนอื่นว่าพวกเขาเคยอ่าน "The Mythical Man-Month" หรือเข้าใจบทเรียนหลักของมัน ("การเพิ่มทรัพยากรให้กับโครงการที่ล่าช้าทำให้ในภายหลัง") จ้องมอง - และจากนั้นทำข้อผิดพลาดเดียวกันกับที่ทำไว้ตลอดหลายปีที่ผ่านมาในระหว่างการพัฒนา OS / 360 ทุกอย่างเก่าเป็นของใหม่อีกครั้ง ... : -}

มีบางแง่มุมของแนวความคิดที่มีกำลังบางครั้งการดำเนินการวันนี้มีแง่มุมอื่น ๆ ที่มีการหลีกเลี่ยง

การทำให้ทีมเล็กเป็นหนึ่งในคุณสมบัติพื้นฐานของวิธีการ Agile แต่ก็มีการฝึกฝนนอก Agile

ทีมงานข้ามสายงานยังเป็นวัตถุดิบของ Agile แต่ก็พบได้ทั่วไปนอก Agile เช่นกัน

บทบาทของ Program Clerk นั้นส่วนใหญ่เป็นระบบคอมพิวเตอร์เช่น Version Control Systems, Software Configuration Management Systems, ระบบการจัดการการเปลี่ยนแปลง, ระบบการจัดการเอกสาร, Wikis, ระบบ Build ต่อเนื่องที่มีคลังเก็บสิ่งประดิษฐ์และอื่น ๆ ฉันหมายความว่าคุณลองจินตนาการถึงการจ่ายพนักงานเต็มเวลาเพื่อพิมพ์ซอร์สโค้ดและสร้างดัชนีและจัดทำด้วยตนเองหรือไม่

ในทำนองเดียวกันบทบาทของผู้ดูแลระบบ (ไม่ใช่ส่วนหนึ่งของทีมผ่าตัดของ Mills แต่เป็นส่วนหนึ่งของทีมข้ามหน้าที่ในช่วงปีที่ผ่านมา) ถูกเลิกใช้งานโดยแนวคิดเช่น DevOps (ดูดซับบทบาทของ Sysadmin ในบทบาทของวิศวกรซอฟต์แวร์) , Platform-as-a-Service, Infrastructure-as-a-Service และ Utility Computing (ทำให้บทบาทของ Sysadmin "ปัญหาของคนอื่น") หรือ Infrastructure-as-Code (เปลี่ยนการบริหารระบบเป็นวิศวกรรมซอฟต์แวร์)

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

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

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

การศึกษาระดับวิทยาลัยเป็นสิ่งที่แปลกใหม่และวิศวกรก็เป็นหนึ่งในไม่กี่คนที่เลือก คอมพิวเตอร์มีราคาแพงและทีมทำงานในโครงการที่มีธุรกิจ RoI ที่กำหนดไว้ สิ่งเหล่านี้ไม่ธรรมดามาก

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

เศรษฐศาสตร์ของการสนับสนุน 8: 2: อัตราส่วนวิศวกรไม่สมเหตุสมผลอีกต่อไป วิศวกรต้องได้รับการสนับสนุนด้วยตนเอง มนุษย์สมัยใหม่ที่มีการศึกษาและทักษะเพียงพอที่จะยึดติดกับทีมพัฒนาได้อย่างมีประสิทธิภาพนั้นแพงเกินไปที่จะไม่พัฒนาตนเองในบางประเภท

(ศัพท์เศรษฐศาสตร์ที่เกี่ยวข้องคือ "โรคต้นทุนของภาคบริการ")

รูปแบบนี้ฟังดูมากสำหรับฉันเช่นการเขียนโปรแกรม Mob:

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

จากhttp://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

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

ดูการทำงานได้ที่นี่: https://www.youtube.com/watch?v=dVqUcNKVbYg

โมเดลทีมนี้ถูกกล่าวถึงอีกครั้งในการพัฒนาอย่างรวดเร็ว - การฝึกฝน Taming Wild Software Schedules โดย Steve McConnell ในหน้า 305 มีชื่อทีมหัวหน้าโปรแกรมเมอร์

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

การอ้างอิงอื่น ๆ :

Baker, F. Terry "หัวหน้าโปรแกรมเมอร์ของทีมการเขียนโปรแกรมการผลิต," IBM Systems Journal, vol. หมายเลข 11 1, 1972, pp. 56-73

Baker, F. Terry และ Harlan D. Mills "หัวหน้าทีมโปรแกรมเมอร์" ข้อมูล, เล่มที่ 19, หมายเลข 12 (ธันวาคม 2516), หน้า 58-61

ฉันเดาว่าทีมเล็ก ๆ ที่จัดระเบียบตัวเองส่วนใหญ่จะมีแนวโน้มที่จะปรับตัวให้เข้ากับรูปแบบทีมการผ่าตัดแบบพฤตินัย

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

คิดถึงกฎสองพิซซ่าของ Bezos นั่นคือทีมผ่าตัดที่จัดระเบียบตัวเองของคุณที่นั่น

มีกระดาษจาก HP ที่แนะนำสิ่งที่คล้ายกัน:

• วิศวกรซอฟต์แวร์แต่ละคนจะต้องการผู้จัดการหลายคนและหลายคนสนับสนุน
• ควรมีนักเขียนนักทดสอบผู้สร้างและผู้ผลิตเครื่องมือสำหรับวิศวกรแต่ละคน

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

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

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

• ศัลยแพทย์: โปรแกรมเมอร์
• ผู้ร่วมนักบิน: โปรแกรมเมอร์คู่ผู้ร่วมงานชุมชนออนไลน์เช่น StackExchange หรือ IRC
• ผู้ดูแลระบบ: บทบาทที่ดำเนินการโดยผู้จัดการโครงการซอฟต์แวร์
• Editor: IDEs ที่รวมเครื่องกำเนิดเอกสารเช่น Javadoc หรือ Doxygen; เอกสารประกอบจากชุดพัฒนาซอฟต์แวร์
• เลขานุการ: ไคลเอนต์อีเมลเครื่องมือการจัดการโครงการเช่นตัวติดตามปัญหาและคำขอดึงห้องแชทของ บริษัท และรายชื่ออีเมล
• เสมียนโปรแกรม: IDE เก็บข้อมูลเกี่ยวกับการออกแบบโครงการที่มีความสามารถเพิ่มรหัส refactor; เอกสารและตัวอย่างจากชุดพัฒนาซอฟต์แวร์
• Toolsmith: ชุมชนโอเพนซอร์สทั้งหมด
• ผู้ทดสอบ: ในทันทีชุดทดสอบและห้องสมุดทดสอบ แต่แน่นอนกระบวนการ QA แยกต่างหากเป็นสิ่งจำเป็นสำหรับรหัสการผลิต
• ทนายความภาษา: เอกสารออนไลน์, StackExchange

ฉันคิดว่าคุณต้องดูหลักฐานของ The Mythical Man Month การว่าจ้างโปรแกรมเมอร์มากขึ้นจะทำให้โครงการซอฟต์แวร์ที่มีปัญหา / เกินกำหนดแย่ลง ปัญหาคือในการสื่อสารและการเพิ่มโปรแกรมเมอร์ใหม่ให้เร็วขึ้นในโครงการ (ต้องใช้เวลาจากการพัฒนาที่มีอยู่) เทคโนโลยีและบางครั้งโดเมนเอง

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

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

ฉันจะเถียงว่ายิ่งเราแยกการออกแบบการใช้งานการทดสอบเอกสารการสร้างการใช้งานการดำเนินการและอื่น ๆ ในบทบาทเฉพาะที่ทำโดยผู้เชี่ยวชาญยิ่งเราทำตามปรัชญา "ทีมศัลยกรรม" (แม้ว่าอาจจะไม่ตรงตามที่อธิบายไว้) )

จากประสบการณ์ของฉันปรัชญา devOps ที่ทุกคนควรมีความสามารถในทุกงานคือการกลับไปสู่รูปแบบการฆ่าฟัน (ไม่ได้บอกว่ามันไม่ดีแตกต่างกัน)

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

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

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

ใช่ฉันคิดว่าบทนี้ยังมีชีวิตอยู่มากในวันนี้แม้ว่าจะยอมรับว่ามันมีวิวัฒนาการมาจากสิ่งที่เกิดขึ้นในตอนนั้น