วัฒนธรรมมักถูกละเลยและเข้าใจผิด แต่ก็เป็นปัจจัยสำคัญที่รับผิดชอบต่อผลการดำเนินงานของ บริษัท หากเราไม่จัดการวัฒนธรรมของเราเราจะต้องปฏิบัติผิด ๆ ซึ่งจะส่งผลต่อเป้าหมายทางธุรกิจของเราในที่สุด
การทำความเข้าใจวัฒนธรรมปัจจุบันขององค์กร
วัฒนธรรมบอกเราเกี่ยวกับค่านิยมและบรรทัดฐานภายในกลุ่มหรือ บริษัท ระบุว่าอะไรสำคัญตลอดจนวิธีการที่ผู้คนเข้าหาและทำงานร่วมกัน
CULTURE =“ วิธีทำสิ่งต่างๆอย่างชาญฉลาดเพื่อความสำเร็จ”
มาดูตัวอย่างทีมสนับสนุนลูกค้า วัฒนธรรมของทีมนั้นควรเป็นแบบที่พวกเขาได้รับความพึงพอใจของลูกค้า 97-98%
โดยคำนึงถึงความพึงพอใจของลูกค้าก่อนอื่นพวกเขาต้องมีความสุภาพแม้ในสถานการณ์ที่ยากลำบากพวกเขาต้องเป็นผู้ฟังที่ดีเพื่อหลีกเลี่ยงความสับสนพวกเขาต้องจัดลำดับความสำคัญของงานตามข้อกำหนด
ขอหยุดสักครู่และถามคำถามกับตัวเราเอง:
- วัฒนธรรมของ บริษัท ของฉันตอนนี้เป็นอย่างไร?
- วัฒนธรรมนี้สอดคล้องกับเป้าหมายทางธุรกิจหรือ KRA ของฉันได้ดีเพียงใด
- ฉันจะพบปัญหาอะไรเนื่องจากการจัดแนวไม่ตรง?
สำหรับทุกองค์กร 4Cs มีบทบาทสำคัญ
ตอนนี้เรามาดูวัฒนธรรมขององค์กรที่พัฒนาซอฟต์แวร์กัน มีหลายทีมที่เกี่ยวข้องกับการสร้างและบำรุงรักษาซอฟต์แวร์หน่วยเดียว ทีมทั้งหมดนี้มีเป้าหมายแยกกันและวัฒนธรรมที่แยกจากกัน
กระบวนการนี้เริ่มต้นหลังจากที่ลูกค้าได้รับการยืนยันความต้องการแล้ว
นักพัฒนาปฏิบัติตามแนวทางการเข้ารหัสที่กำหนดโดยองค์กรของตนและใช้เครื่องมือการเขียนโปรแกรมเช่นคอมไพเลอร์ล่ามตัวแก้จุดบกพร่อง ฯลฯ เพื่อสร้างรหัส ภาษาโปรแกรมระดับสูงต่างๆเช่น C, C ++, Pascal, Java และ PHP ใช้สำหรับการเขียนโค้ด
พวกเขาแบ่งแพ็กเกจทั้งหมดออกเป็นโฟลเดอร์เล็ก ๆ แล้วพัฒนาโค้ดขนาดเล็กตามนั้น
ด่าน 1 : จากนั้นรหัสหน่วยเล็ก ๆ เหล่านี้จะรวมกันเป็นหน่วยใหญ่ ในขณะที่รวมชิปที่มีขนาดเล็กลงจะต้องมีการทดสอบระดับโครงการที่เรียกว่าการทดสอบการรวม
ด่าน 2 : หลังจากการรวมสำเร็จจะถูกนำไปใช้ในระบบจำลอง ระบบดัมมี่นี้มีการกำหนดค่าคล้ายกับเครื่องไคลเอนต์หรือเครื่องที่ต้องปรับใช้โครงการนี้ในที่สุด
ด่าน 3 : สุดท้ายหลังจากทดสอบคุณสมบัติทั้งหมดในระบบจำลองโปรเจ็กต์จะถูกปรับใช้ในเซิร์ฟเวอร์การผลิตหรือเครื่องไคลเอนต์
แม้ว่ากระบวนการนี้ดูเหมือนจะราบรื่นและง่ายมาก แต่ในแง่เทคนิคก็ยากมากที่จะบรรลุ
มาดูกันว่าเราอาจประสบปัญหาอะไรบ้าง:
เปลี่ยนสตริงเป็นอาร์เรย์ php
ด่าน 1 :
ลูกค้ามักจะค้นหาการเปลี่ยนแปลงเพื่อปรับปรุงคุณภาพของผลิตภัณฑ์ ส่วนใหญ่เมื่อทำการย้ำครั้งแรกลูกค้าจะแนะนำการเปลี่ยนแปลงเล็กน้อย เมื่อนักพัฒนาซอฟต์แวร์ได้รับการเปลี่ยนแปลงพวกเขาจะเริ่มรวมเข้าด้วยกันซึ่งส่งผลต่อการผสานรวมที่นำไปสู่การสร้างที่เสียหาย
ด่าน 2:
โดยส่วนใหญ่ผู้ทดสอบหรือเจ้าหน้าที่ปฏิบัติการอื่น ๆ จะไม่ทราบถึงการเปลี่ยนแปลงใหม่ที่จะเกิดขึ้น ทันทีที่พวกเขาได้รับรหัสจากนักพัฒนาพวกเขาก็เริ่มทดสอบพวกเขา ในขณะที่แบ็คเอนด์นักพัฒนายังคงทำการเปลี่ยนแปลง
เนื่องจากพวกเขาไม่มีเวลาเพียงพอที่จะใช้การเปลี่ยนแปลงใหม่พวกเขาจึงต้องพัฒนารหัสที่ไม่มีประสิทธิภาพซึ่งพวกเขาต้องเผชิญกับปัญหาเครือข่ายและฐานข้อมูลอื่น ๆ ซึ่งทำให้เวลาในการจัดส่งล่าช้าอีกครั้ง
ในที่สุดเมื่อพวกเขาส่งรหัสไปยังทีมปฏิบัติการพวกเขาจะเหลือเวลาน้อยมากในการสร้างและใช้กรณีทดสอบใหม่ ดังนั้นพวกเขาจึงข้ามกรณีทดสอบหลาย ๆ กรณีซึ่งพวกเขารู้ในภายหลังว่าสิ่งเหล่านี้มีความสำคัญสูง
ด่าน 3:
แม้ว่างานสร้างดูเหมือนจะพร้อมสำหรับการผลิต แต่ผลลัพธ์กลับไม่คาดคิด การสร้างล้มเหลวและเกิดข้อบกพร่องจำนวนมาก
จากนั้นทุกข้อบกพร่องที่เกิดขึ้นพวกเขาจะต้องติดตามว่าเหตุใดจึงเกิดขึ้นที่ไหนเกิดขึ้นต้องทำการเปลี่ยนแปลงอะไรเพื่อเอาชนะมันจะมีการเปลี่ยนแปลงในรหัสอื่น ๆ เพื่อให้เข้ากันได้กับรหัสก่อนหน้า สุดท้ายสำหรับข้อบกพร่องเหล่านี้จะต้องมีการสร้างรายงานข้อบกพร่อง
ความล้มเหลวเป็นเพราะข้อผิดพลาดของระบบเนื่องจากผู้พัฒนาฐานข้อมูลไม่รู้ประสิทธิภาพของโค้ดความไม่รู้ของผู้ทดสอบในกรณีทดสอบจำนวนมาก ฯลฯ
เนื่องจากลูกค้ามีกำหนดเวลาที่รัดกุมอยู่เสมอพนักงานที่เกี่ยวข้องในการบรรลุเป้าหมายเฉพาะในรุ่นสุดท้ายแม้ว่าพวกเขาจะต้องลดทอนคุณภาพโดยรวมก็ตาม
แม้ว่านี่จะเป็นปัญหาในการประสานงาน แต่ นี่คือความล้มเหลวของวัฒนธรรมที่นำมาใช้จริง
สิ่งนี้เกิดขึ้นเนื่องจากการพึ่งพากระบวนการด้วยตนเองเป็นจำนวนมาก การวิ่งไปมาในทีมเดียวกันเพราะขาดความรู้ในด้านต่าง ๆ ขาดการเข้าถึงหรืออาจขาดความสนใจเพิ่มภาระและความเจ็บปวดของเราเอง
ถึงเวลาแล้วที่เราต้องมีความหลากหลาย อาจเป็นเรื่องยากที่จะเป็นผู้เชี่ยวชาญในกระบวนการทั้งหมดที่เกี่ยวข้องกับระบบ แต่เราสามารถเป็นจุดเริ่มต้นของทั้งหมดได้ จากนั้นมีเพียงเราเท่านั้นที่สามารถทำให้ระบบของเราเป็นอัตโนมัติหรือทำให้ฉลาดพอที่จะกู้คืนมากกว่าการย้อนกลับ
ตอนนี้คุณอาจกำลังคิดว่าทำไม?
เป็นเพราะคนที่คุณเชี่ยวชาญนั้นต้องพึ่งพาผู้อื่นเป็นอย่างมาก ดังนั้นเพื่อให้ทราบถึงจุดพึ่งพาเราจำเป็นต้องเข้าใจทั้งระบบ
ลองนึกถึงกระบวนการเปลี่ยนแปลงวัฒนธรรมกัน ก่อนหน้านั้นคุณมีคำตอบสำหรับคำถามด้านล่างนี้หรือไม่?
- วัฒนธรรมปัจจุบันของคุณล้มเหลวตรงไหน?
- ทำไมคุณถึงต้องการเปลี่ยนกระบวนการ?
- คุณได้ระบุการเปลี่ยนแปลงที่จำเป็นทั้งหมดอย่างชัดเจนแล้วหรือยัง?
- คุณได้รับข้อเสนอแนะและซื้อจากผู้ถือหุ้นที่ได้รับผลกระทบทั้งหมดหรือไม่?
- คุณได้ตรวจสอบวินัยของกระบวนการข้อมูลและระบบการวัดสำหรับการเปลี่ยนแปลงแล้วหรือยัง
ดังนั้นเมื่อเราได้คำตอบทั้งหมดแล้วเราจึงคิดถึงการปฏิวัติระบบของเรา การปฏิวัตินี้จะเกิดขึ้นอย่างไร? จะสำเร็จได้ก็ต่อเมื่อเราฆ่าสิ่งที่เราเป็นอยู่ตอนนี้ เสียเวลามากในการโยกย้ายรหัสระหว่างทีม เราต้องนำกระบวนการที่เราสามารถผสานรวมอย่างต่อเนื่องและการปรับใช้อย่างต่อเนื่อง
กระบวนการรวมและการปรับใช้อย่างต่อเนื่องนี้ทำให้คล่องตัวมากขึ้น การนำความคล่องตัวนี้ถือเป็นวัฒนธรรม DevOps
DevOps คือการปฏิบัติของวิศวกรฝ่ายปฏิบัติการและการพัฒนาที่มีส่วนร่วมในวงจรชีวิตการบริการทั้งหมดตั้งแต่การออกแบบจนถึงขั้นตอนการพัฒนาไปจนถึงการสนับสนุนการผลิต
อะไรคือความแตกต่างระหว่าง git และ github
ไม่ใช่เรื่องง่ายที่จะเปลี่ยนระบบการทำงานตลอดเวลา การเปลี่ยนแปลงที่ประสบความสำเร็จคือการปรับปรุงระบบแทนที่จะสร้างใหม่
ตอนนี้เรามาดูกันว่าเราจะบรรลุเป้าหมายนี้ได้อย่างไร มีสองวิธีในการเข้าใกล้
1) จากบนลงล่าง
เบราว์เซอร์ sqlite คืออะไร
2) ล่างขึ้น
การดำน้ำลึกลงไปในเทคนิคเหล่านี้เราจะรู้ว่าสิ่งใดเหมาะสมที่สุดสำหรับองค์กรของเรา
ในแนวทางจากบนลงล่างเราสามารถไปที่ผู้บริหารระดับสูงและขอให้พวกเขาทำการเปลี่ยนแปลงในทุกทีม หากฝ่ายบริหารเชื่อมั่นเราสามารถเริ่มดำเนินการได้
แต่ความน่าจะเป็นที่จะได้รับคำตอบว่า“ ไม่” นั้นค่อนข้างสูง เป็นเพราะการเปลี่ยนแปลงระบบสามารถนำองค์กรไปสู่ความไม่มั่นคงได้
พวกเขาต้องพิจารณาโครงสร้างขององค์กรรายได้ระดับความสนใจของลูกค้า ฯลฯ แต่ปัจจัยที่สำคัญที่สุดที่ดึงพวกเขากลับมาจากการเลิกใช้ระบบเดิมคือพวกเขาไม่สามารถมองเห็น ภาพรวมของสิ่งที่สามารถทำได้และวิธีที่จะทำได้อย่างราบรื่นกับสิ่งใหม่กว่า
ในกรณีนี้เราสามารถมองหาแนวทางที่สองเพื่อให้ได้ภาพรวมนี้
แนวทางล่างขึ้นบนเรียกอาสาสมัคร ที่นี่เราต้องใช้ทีมขนาดเล็กและงานขนาดเล็กและดำเนินการใน DevOps Model
เมื่อมองในด้านเทคนิคของรุ่นนี้เรามีชุดเครื่องมือที่ซับซ้อนมากมายที่ทำให้การทำงานมีประสิทธิภาพและรวดเร็วยิ่งขึ้น แต่เครื่องมือเพียงอย่างเดียวไม่สามารถเพียงพอที่จะสร้างสภาพแวดล้อมการทำงานร่วมกันที่เรียกว่า DevOps
การสร้างสภาพแวดล้อมดังกล่าวทำให้คุณต้องคิดนอกกรอบเช่น การประเมินและปรับเปลี่ยนวิธีคิดของผู้คนเกี่ยวกับทีมธุรกิจและลูกค้า
การรวบรวมชุดเครื่องมือใหม่นั้นง่ายกว่าการเปลี่ยนวัฒนธรรมองค์กร ด้วยการส่งเสริมนักพัฒนาต้นแบบที่ต่อต้านสังคมอนุญาตให้รวมโค้ดที่ไม่มีประสิทธิภาพปรับใช้รหัสที่ไม่ได้รับการทดสอบอย่างถูกต้องการกล่าวโทษกันและกันการพิจารณาว่าทีมปฏิบัติงานโง่ไม่ใช่แนวทางปฏิบัติที่ดีที่สุดที่เรากำลังติดตามเพื่อให้สามารถดำเนินธุรกิจได้ และสร้างมูลค่าให้กับลูกค้าของเรา
ไม่ใช่เครื่องมือ แต่เป็นคนที่ใช้มันทำให้กระบวนการซับซ้อน หากต้องการพูดในระดับนามธรรมแทนที่จะรวบรวมความคิดและพฤติกรรมการเปิดใจรับสิ่งเหล่านี้จะพาเราไปสู่เส้นทางที่สดใส
เริ่มต้นด้วยทีมที่มีสมาชิก 6 คนและเรื่องราว 3 จุด อันดับแรกเราต้องแยกทีมที่เราเรียกว่านักพัฒนาปฏิบัติการผู้ทดสอบ ฯลฯ เราถือว่าพวกเขาทั้งหมดเป็นหนึ่งเดียวกันพูดว่า“ DevOps” เมื่อเราได้รับข้อกำหนดเราจำเป็นต้องวิเคราะห์โซนของความเสี่ยง นึกถึงส่วนลึกของทะเล & hellip .. เราเริ่มล่องเรือ
ตอนนี้คุณต้องคิดว่า“ อะไรคือปัจจัย x ของการผสานรวมอย่างต่อเนื่องเหล่านี้และการปรับใช้อย่างต่อเนื่องที่ลดโอกาสที่จะล้มเหลว”
ด้วยวิสัยทัศน์และกระบวนการที่ดีขึ้นเราสามารถเข้าหาผู้บริหารเพื่อให้เห็นภาพที่ชัดเจนของผลลัพธ์เช่นกระบวนการราบรื่นความเสี่ยงของความล้มเหลวลดลงอย่างไรงานเสร็จก่อนไทม์ไลน์ ฯลฯ
ตอนนี้เราสามารถเห็นภาพได้อย่างชัดเจนว่ากระบวนการทั้งหมดได้รับการปรับให้เหมาะสมบนพื้นฐานทางเทคนิคและวัฒนธรรมอย่างไรโดยมีการย้อนหลังหลังจากการทำซ้ำแต่ละครั้ง
Edureka ได้รับการดูแลเป็นพิเศษ ที่ช่วยให้คุณเชี่ยวชาญแนวคิดเกี่ยวกับ Puppet, Jenkins, Ansible, SaltStack, Chef และอื่น ๆ
มีคำถามสำหรับเรา? พูดถึงพวกเขาในส่วนความคิดเห็นแล้วเราจะติดต่อกลับไป
กระทู้ที่เกี่ยวข้อง: