หากคุณไม่เข้าใจว่า DevOps คืออะไร นี่คือเอกสารสรุปสั้นๆ DevOps คือชุดของแนวทางปฏิบัติที่ ลดความกลัวของวิศวกร และลดจำนวนความล้มเหลวในการผลิตซอฟต์แวร์ ตามกฎแล้วพวกเขาจะเหมือนกัน ลดเวลาในการทำตลาด — ระยะเวลาตั้งแต่แนวคิดไปจนถึงการส่งมอบผลิตภัณฑ์ขั้นสุดท้ายให้กับลูกค้า ซึ่งช่วยให้คุณดำเนินการได้อย่างรวดเร็ว การทดลองทางธุรกิจ.
จะเริ่มการแปลง DevOps ได้อย่างไร กล่าวโดยย่อ: เราเลือกบริการที่จะเริ่มกระบวนการ ระบุผู้ที่เกี่ยวข้องกับบริการ สร้าง Value Stream Map สร้างทีมชั่วคราวที่จะจัดการกับการเปลี่ยนแปลงเป็นครั้งแรก และกำหนดงานสำหรับการเปลี่ยนแปลง เราทำซ้ำวงจรตามจำนวนครั้งที่ต้องการ
แผนการเปลี่ยนแปลง DevOps โดยละเอียดพร้อมตัวอย่างและคำแนะนำภายใต้การตัด - ในการถอดเสียง อันเดรย์ อเล็กซานดรอฟ - วิศวกรที่ Express42 ซึ่งให้คำแนะนำเกี่ยวกับการงอกของ DevOps โดยเร่งกระบวนการนี้ให้เร็วขึ้นเพราะเธอได้สร้างแผนที่คราดไว้แล้ว หากดูเหมือนว่าคุณไม่จำเป็นต้องเปลี่ยนแปลง หรือข้อมูลเฉพาะของคุณทำให้แนวทางปฏิบัติ DevOps ไม่เหมาะสม ให้ใช้รายงานเป็นคำแนะนำในการค้นหาและขจัดข้อจำกัด
หากคุณกังวลเกี่ยวกับปัญหาการเปลี่ยนแปลง DevOps แสดงว่าคุณมีบริษัทขนาดใหญ่ และคุณต้องค่อยๆ ปรับขนาดกระบวนการนี้ทั่วทั้งโครงสร้างทั้งหมด ตราบใดที่จำเป็นต้องแปลงคำสั่งหรือกำจัดข้อจำกัดบางประการ ก็สามารถทำซ้ำอัลกอริทึมด้านล่างได้
การเลือกบริการ
เราได้ร่างแผนมาเริ่มกันที่ขั้นตอนแรก - การเลือกบริการ เกณฑ์แรกคือตลอดชีวิต: มีบริการเก่า - ดั้งเดิมและบริการใหม่ คุณสามารถเริ่มต้นด้วยทั้งสองอย่าง
การเลือกบริการแบบเด็กเป็นเรื่องสมเหตุสมผล. ยังสดอยู่ ยังไม่มีกระบวนการทำงานเป็นทีมที่เกี่ยวข้องกับเรื่องนี้ ไม่มีหนี้ด้านเทคนิคมากมาย คุณไม่จำเป็นต้องแก้ไขตลอดเวลา เราสามารถทำทุกอย่างที่เราต้องการได้
ในส่วนของบริการแบบเก่าก็มีปัญหาตามมาว่า การเปลี่ยนแปลงนั้นยากเสมอ. มีข้อ จำกัด ร้ายแรงบางประการอยู่แล้ว แต่บางทีผู้ที่พร้อมจะตักตวงทุกสิ่งกำลังจัดการกับพวกเขา - พวกเขาเหนื่อยและต้องการทำสิ่งที่แตกต่างออกไปเพราะพวกเขาเจ็บปวด
การทำงานกับบริการแบบเก่าถือเป็นแบบอย่างอันทรงพลัง ในบริษัทของคุณ - คุณสามารถเปลี่ยนแปลงบางสิ่งได้ หากคุณเปลี่ยนบริการใหม่ บริการจะล่ม 100 ครั้งต่อชั่วโมง และทุกอย่างเรียบร้อยดี ผู้คนในบริษัทของคุณอาจพูดว่า:
- นี่คือบริการใหม่! ทุกอย่างเรียบง่ายที่นั่น พยายามทำอะไรบางอย่างกับซากเรือของเรา
การใช้บริการ Legacy เพื่อการเปลี่ยนแปลงเมื่อคุณทำร่วมกับผู้อื่น เช่น หากคุณเชิญที่ปรึกษาภายนอกก็สมเหตุสมผล บอกตามตรงว่าการเปลี่ยนแปลงจะทำให้ทุกอย่างสั่นคลอน. คุณกำลังทดลองและไม่รู้ว่าสุดท้ายจะไปอยู่ที่ไหน คุณจะใช้เทคโนโลยีอะไร และทำไม ที่ไหนและข้อผิดพลาดอะไรจะเกิดขึ้นในกระบวนการนี้ ดังนั้นจึงง่ายต่อการเปลี่ยนใหม่
หากคุณทำทุกอย่างด้วยตัวเองและบริษัทไม่มีความสามารถจริงจัง เราก็รับบริการใหม่ หากคุณรู้จักที่ปรึกษาภายนอกและมีเงินทุน ให้เลือกที่ปรึกษาเก่า
มีบริการต่างๆ ที่เป็นเพียงอินเทอร์เฟซสำหรับผู้ใช้ เช่น เว็บไซต์ธรรมดาหรือแอปพลิเคชันบนมือถือ แต่มีเรื่องร้ายแรงในจิตวิญญาณของการเรียกเก็บเงิน หากมีสิ่งผิดปกติเกิดขึ้นกับการเรียกเก็บเงิน จะเป็นการยากที่จะเข้าใจ ที่นี่เราก็มีทางเลือกเช่นกัน
เราก็ทำงานเช่นกัน ด้วยบริการที่สำคัญแต่เราทนทุกข์เพราะมันสร้างข้อจำกัดหรือเราทำงาน ด้วยอินเทอร์เฟซ. นี่คือเกณฑ์การคัดเลือกที่สอง ในทำนองเดียวกัน คุณสามารถดึงดูดที่ปรึกษาที่มีประสบการณ์ได้ - เราทำงานกับตัวเลือกที่ยาก
แต่แม้ในกรณีนี้ ผมไม่แนะนำให้ทำเช่นนี้ เพราะจนกว่าจะมีความเข้าใจว่าควรทำงานอย่างไรและจะเปลี่ยนแปลงไปในทิศทางใด การเอาเรื่องสำคัญมาเขย่าก็ไม่ใช่ความคิดที่ดีนัก ดังนั้น ในกรณีนี้ เราต้องการทำงานกับอินเทอร์เฟซที่ความล้มเหลวไม่สำคัญ
มาดูกันต่อ ทีมบริการ. เราจะต้องทำงานอย่างต่อเนื่องและมีปฏิสัมพันธ์อย่างใกล้ชิดกับผู้ให้บริการนี้
คนในทีมแบ่งออกเป็นสองประเภท: อนุรักษ์นิยม — อยู่ในโลกเก่า หรือแค่ไม่รู้อะไรเกี่ยวกับ DevOps และ นักประดิษฐ์ซึ่งลากแนวทางปฏิบัติที่ทันสมัยทั้งหมด หลังไม่เข้าใจหัวข้อเสมอไป แต่อย่างน้อยพวกเขาก็พร้อมสำหรับมัน
ประการหนึ่ง พวกอนุรักษ์นิยมคือคนที่มีประสบการณ์ พวกเขาอยู่ในบริษัทมาเป็นเวลานาน พวกเขาเข้าใจทั้งภายในและภายนอก แต่พวกเขาไม่รู้แน่ชัดเกี่ยวกับหลักปฏิบัติ ในทางกลับกัน มีนักประดิษฐ์ที่เคยได้ยินอะไรบางอย่างแต่ส่วนใหญ่ไม่ได้ทำงานในบริษัทมานานนัก อันไหนดีกว่าที่จะทำงานร่วมกับ?
คุณจะต้องโต้ตอบกับฝ่ายอนุรักษ์นิยมไม่ว่าในกรณีใด เนื่องจากนี่คือบริการของพวกเขา คุณจะต้องสื่อสารกับพวกเขา ค้นหาข้อมูลเฉพาะของบริการ สิ่งที่สามารถทำได้ด้วยวิธีนี้ และอะไรอีก เราขึ้นอยู่กับคำแนะนำของพวกเขา คุณอาจต้องมอบความไว้วางใจให้พวกเขาในเรื่องบางอย่าง เพราะพวกเขารู้จักบริการของตนดีกว่า ดังนั้นจึงเป็นเรื่องสำคัญที่เราจะติดต่อกับทีมใด
มีเหตุผลที่จะเลือกผู้สร้างนวัตกรรมให้กับทีมเพราะพรรคอนุรักษ์นิยมสามารถใส่หมูเข้าไปได้
ในทางปฏิบัติมักเกิดขึ้นที่คนอนุรักษ์นิยมมีประสบการณ์สำคัญ แต่ไม่มีความเข้าใจว่าจะใช้ชีวิตต่อไปอย่างไร พวกเขาเพียงกลัวว่าหลังจากการเปลี่ยนแปลงและการออกแบบบริการใหม่ พวกเขาจะถูกไล่ออกโดยไม่จำเป็น บางครั้งเพียงเพราะพวกเขาไม่เข้าใจสิ่งที่เกิดขึ้น พวกเขาจึงทำลายงานนี้
ฉันมีกรณีที่ผู้ชายในทีมซ่อมแซมทุกอย่าง เพราะมันควรจะสำคัญกว่าที่เรากำลังทำอยู่ตอนนี้ เรากำหนดภารกิจ: ใช้งานชิ้นส่วนนี้วันนี้ - ไม่ มีไฟอยู่ที่อีกซีกโลกหนึ่ง เราจะแก้ไขมัน เป็นการยากที่จะทำงานร่วมกับคนประเภทนี้
คนจากทีมอนุรักษ์นิยมมักจะลืมงานหรือเลื่อนงานออกไปจนนาทีสุดท้าย และหาก John Willis ห้ามคุณทำผิดพลาดและกำหนด KPI ให้พวกเขาตามจำนวนงานที่เสร็จสิ้น และด้วยเหตุผลบางอย่าง บางส่วนไม่รวมอยู่ใน KPI พวกเขาจะไม่ทำอะไรเลย โดยทั่วไปแล้วพวกเขาจะถูกต้องเพราะจากนั้นพวกเขาจะเสียโบนัส
ง่ายขึ้นสำหรับนักสร้างสรรค์นวัตกรรม - พวกเขามีความภักดีมากกว่า. พวกเขาได้ยินอะไรบางอย่างแล้ว พวกเขาต้องการไปที่ไหนสักแห่งจึงจะช่วย เราต้องการคนที่พร้อมจะทนทุกข์เป็นครั้งแรก: หากบริการมีการเปลี่ยนแปลง นักประดิษฐ์จะรับมืออุปสรรคและคราดทั้งหมดในฐานะผู้บุกเบิก นักประดิษฐ์ต้องการทุกสิ่งที่ใหม่และทันสมัยและต้องทนทุกข์ทรมาน
พรรคอนุรักษ์นิยมสามารถแปลงได้ในภายหลัง เมื่อคุณแสดงให้เห็นว่าคุณเปลี่ยนชิ้นส่วนและทุกอย่างทำงานได้ดี เป็นไปได้มากว่าพวกเขาจะอยากลองเช่นกันและจะยอมรับศาสนา DevOps ใหม่
มาสรุปกัน หากเราทำการเปลี่ยนแปลงทั้งหมดในบริษัทของเราเอง เราก็จะเลือก: บริการใหม่ ควรมีอินเทอร์เฟซที่เรียบง่ายเพื่อไม่ให้เกิดปัญหามากเกินไป และทีมผู้สร้างนวัตกรรม
หากเป็นไปได้ที่จะโทรหาที่ปรึกษาภายนอก แทนที่จะเป็นที่ปรึกษาใหม่ เราก็ใช้บริการเก่า เพราะเหตุนี้เราจึงประสบปัญหาอยู่แล้ว คนที่มีส่วนร่วมในการเปลี่ยนแปลงมาเป็นเวลานานในบริษัทต่างๆ ได้พบเห็นกรณีต่างๆ กัน และเข้าใจแล้วว่าต้องทำอย่างไรให้ถูกต้อง และโดยทั่วไปจะต้องไปในทิศทางใด
ใครบ้างที่เกี่ยวข้อง?
เราจำเป็นต้องค้นหาทุกคนที่มีความเกี่ยวข้องกับบริการเป็นอย่างน้อย: นักพัฒนา ผู้ทดสอบ ผู้ดูแลระบบ ผู้เชี่ยวชาญด้านความปลอดภัย ผู้จัดการ และอาจรวมถึงเจ้าของผลิตภัณฑ์ แม้ว่าเจ้าของผลิตภัณฑ์จะไม่ใช่ผู้เชี่ยวชาญด้านเทคนิค แต่พวกเขาก็เกี่ยวข้องกับบริการ: พวกเขาตัดสินใจ กำหนดงาน
ทุกคนที่ตัดสินใจอย่างน้อยและมีอิทธิพลต่อสิ่งที่เกิดขึ้นกับบริการ จะต้องถูกพบ พบปะ และสื่อสาร
เราต้องการพวกมันเพื่ออะไร? เพื่อให้รู้ว่าจะเจรจากับใคร. ในระหว่างการเปลี่ยนแปลง เมื่อหลักการทำงานตามปกติกับบริการเปลี่ยนไป ก็จะยังคงสั่นคลอน จะมีข้อผิดพลาดอยู่ระยะหนึ่งในขณะที่เราทดสอบแนวทางใหม่ๆ ประชาชนต้องพร้อมและเห็นด้วยกับเรื่องนี้
ถัดไป คุณจะต้องสร้าง Value Stream Map และหากไม่มีคนเหล่านี้ คุณจะไม่สามารถสร้างมันขึ้นมาได้ เพราะมีเพียงพวกเขาเท่านั้นที่รู้ภาพรวมของสิ่งที่เกิดขึ้น คนหนึ่งไม่เคยรู้ทุกสิ่งที่เกิดขึ้นกับบริการนี้
พวกเขาจะแนะนำคนให้กับทีม หลังจากนั้น เราจะหารือกันว่าทำไมจึงต้องแยกทีมออกจากกัน ก็จะต้องรับคนจากแผนกที่มีอยู่ ผู้ที่เกี่ยวข้องกับการบริการจะสามารถแนะนำเพื่อนร่วมงานที่คิดไปในทิศทางของเรา ซึ่งสามารถช่วยเราได้และมีความสามารถในสิ่งที่เราต้องการ
ต่อไป เราจะรวบรวมคนเหล่านี้จากแผนกต่างๆ มาไว้ในห้องเดียว และเริ่มสร้าง Value Stream Map
การสร้างแผนที่สายธารคุณค่า
Value Stream Map เป็นไดอะแกรมหรือแผนที่ที่แสดงการไหลของค่าไปยังไคลเอนต์. นี่คือกระบวนการทั้งหมดตั้งแต่การคิดไอเดียไปจนถึงการนำไปปฏิบัติ รวมถึงขั้นตอนระหว่างกลางทั้งหมด และวิธีที่มูลค่าจะไปถึงลูกค้าของเราในท้ายที่สุด
จำเป็นต้องมีแผนที่สตรีมคุณค่าเพื่อ เห็นภาพการพัฒนาทุกขั้นตอนระบุปัญหาผ่านการวัดที่มีอยู่ในกระบวนการปัจจุบัน และเริ่มขจัดปัญหาเหล่านี้ และ ตั้งเป้าหมายเบื้องต้น. นี่คือจุดที่เราเริ่มทำอะไรบางอย่างจริงๆ
เมตริก
มีตัวชี้วัดที่แตกต่างกันมากมายที่อธิบายไว้ในเอกสาร Value Stream Map แต่เพียงสามตัวชี้วัดก็เพียงพอที่จะเริ่มต้นได้
ระยะเวลาดำเนินการ - ล่าช้า/รอ - เวลาที่เรากำลังรอบางสิ่งบางอย่าง ตัวอย่างเช่น ผู้ทดสอบจะรอจนกว่าแท่นทดสอบจะว่าง และไม่สามารถดำเนินการใดๆ ได้ในระหว่างนี้
เวลามูลค่าเพิ่ม - เวลาทำงานที่มีประโยชน์ - สิ่งที่เราใช้จ่ายไปในขั้นตอนดังกล่าวและขั้นตอนดังกล่าวเพื่อสร้างมูลค่าสุดท้ายให้กับผู้ใช้ ตัวอย่างเช่น ผู้ทดสอบเริ่มการทดสอบและเริ่มตรวจสอบบางอย่าง นี่คือช่วงเวลาแห่งการทำงานที่เป็นประโยชน์ เมื่อเราทำอะไรสักอย่างเพื่อผลิตภัณฑ์จริงๆ นี่คือสิ่งที่ลูกค้าจ่าย - ซอฟต์แวร์คุณภาพ
%C/A คือเปอร์เซ็นต์ของงานที่ยอมรับ เรามีขั้นตอนหนึ่งคือการพัฒนา ขั้นตอนที่สองคือการทดสอบ จำนวนผู้ทดสอบคุณสมบัติที่ยอมรับจากนักพัฒนาคือเปอร์เซ็นต์นี้
แผนที่ของเราก็จะประมาณนี้ครับ
อาจมีลักษณะแตกต่างกันไปขึ้นอยู่กับโครงสร้างองค์กร จำนวนแผนก และสิ่งที่คุณทำ แต่โดยทั่วไปจะมีสองขั้นตอนบนแผนที่: ความคิด и аналитика. ในขั้นตอนนี้ ข้อมูลที่คาดหวัง เช่น Lead Time 2 สัปดาห์ และ Value Added Time 2 วัน
เราครอบคลุมทุกขั้นตอนด้วยการวัดผล
สิ่งที่ค้าง — มีปัญหามากแค่ไหนหลังจากที่นักวิเคราะห์เข้ามาหาพวกเขา
ออกแบบ - นักพัฒนารอคำชี้แจงเกี่ยวกับงาน อัฒจันทร์ หรืออุปกรณ์มากี่สัปดาห์แล้ว - ไม่สำคัญ แต่พวกเขากำลังรออะไรบางอย่าง เช่น พวกเขาใช้เวลา 4 วันในการติดตั้งฟีเจอร์ นี่คือที่มาของเมตริก %C/A นักพัฒนารับงานเพียง 80% จาก Backlog พวกเขาเชื่อว่าส่วนที่เหลืออีก 20% ไม่มีข้อกำหนดทางเทคนิคที่ชัดเจนเพียงพอจึงส่งไปแก้ไข
การทดสอบ. แผนภาพ LT ถูกตั้งค่าเป็น 4 วัน ตัวอย่างเช่น ผู้ทดสอบกำลังรอให้ม้านั่งทดสอบว่าง จริงๆ แล้ว VA พวกเขากำลังทดสอบบางอย่างเป็นเวลา 2 วัน และ %C/A = 40% — เพียง 40% ของโค้ดหรือฟีเจอร์ที่นักพัฒนาส่งมานั้นถือว่าเพียงพอโดยผู้ทดสอบ พวกเขาไม่ชอบอย่างอื่นด้วยเหตุผลบางอย่าง
ฉันจะไม่กล่าวถึงรายละเอียดเกี่ยวกับวิธีการวัดเหล่านี้ในตอนท้ายของบทความฉันจะแนะนำวรรณกรรมที่คุณสามารถเรียนรู้เกี่ยวกับพวกเขาได้
สิ่งเดียวที่ฉันแนะนำได้คือคุณไม่ไว้ใจคนที่จะรวบรวม Value Stream Map กับคุณ จะให้แนวคิดว่ากระบวนการต่างๆ ใช้เวลานานเท่าใด แต่การประมาณค่าเหล่านี้อาจไม่ถูกต้องเสมอไป ดังนั้นจึงควรวัดผลด้วยตนเอง
เรามีกรณีหนึ่งเมื่อเรามาที่แผนกปฏิบัติการและถามว่าต้องใช้เวลานานแค่ไหนในการส่งมอบฟีเจอร์ใหม่สู่การใช้งานจริง พวกเขาบอกเราว่าอีก 10 นาที เราก็คิดว่า ทำไมเราถึงมาที่บริษัทนี้ด้วย? ปรากฎว่า 10 นาทีคือเวลารันของสคริปต์ที่รับโค้ดและส่งไปยังเซิร์ฟเวอร์ แต่ก่อนหน้านี้ การเปิดตัวจะอยู่บนเซิร์ฟเวอร์เป็นเวลาสามวันและเป็นเพียงการรวบรวมฝุ่น - มีงานใน Backlog ที่จำเป็นต้องปรับใช้ ปรากฎว่าก่อนขั้นตอนการปรับใช้จะมีขั้นตอนการรอ เมื่อโปรเจ็กต์ตั้งอยู่ตรงนั้น หากเราไม่ได้พกกระดาษจดไปด้วย ไม่ได้จับตาดูงานใน Jira และเริ่มติดตามมันทีละขั้นตอน เราคงคิดว่าทุกอย่างเยี่ยมยอดและไม่มีปัญหา
ดังนั้นคุณยังคงต้องทำการวัดด้วยตนเอง ควรทำมากกว่าหนึ่งครั้ง เพื่อให้มีแนวคิดที่ใกล้เคียงกับความเป็นจริง ขึ้นอยู่กับ Value Stream Map คุณจะต้องตัดสินใจว่าจะเริ่มจากตรงไหนและต้องแก้ไขอะไรก่อน
ทีมงานชั่วคราว
บริษัทหลายแห่งที่ตัดสินใจใช้ DevOps จะสร้างทีมขึ้นมา แต่ไม่ใช่ทีมชั่วคราว แต่เป็นทีมที่อยู่มาหลายปีแล้ว หากคุณไปที่บริการขอโทษ DevOps ซึ่งอธิบายรูปแบบต่างๆ สำหรับการสร้างโครงสร้างองค์กรใน DevOps คุณจะเข้าใจว่านี่เป็นรูปแบบที่ต่อต้าน
เมื่อทีม DevOps ดำรงอยู่อย่างต่อเนื่องเป็นเวลาหลายปี นี่ถือเป็นข้อผิดพลาดครั้งใหญ่ เนื่องจาก DevOps เป็นเรื่องเกี่ยวกับการสื่อสารระหว่างแผนก เกี่ยวกับความเร็วและประสิทธิภาพ
หากทีมอยู่ระหว่างแผนกเพียงเพื่อทำอย่างอื่นแยกจากกันและดำรงอยู่มาเป็นเวลานาน ก็จะสร้างอุปสรรคที่ไม่จำเป็น ตอนนี้โปรแกรมเมอร์ แทนที่จะไปหาผู้ดูแลระบบทันทีเพื่อแก้ไขปัญหา จะต้องติดต่อแผนก DevOps ก่อน แล้วเขาจะดำเนินการต่อไป
ดังนั้น ในการเริ่มต้น คุณต้องสร้างทีมชั่วคราว. มันจะคงอยู่อย่างมีเงื่อนไขเป็นเวลาหกเดือน สูงสุดหนึ่งปี ขึ้นอยู่กับงานที่ทำอยู่ เพียงเพื่อขจัดข้อจำกัดเดียวที่เราเลือกไว้ แล้วเธอก็จะตาย ถ้าเราเลือกจุดต่อไปที่เรามีความเจ็บปวดมากมาย และตระหนักว่าเราต้องการทีมที่แยกจากกันสำหรับเรื่องนั้น เราก็จะสร้างมันขึ้นมาใหม่ แต่ทีมดังกล่าวไม่ควรมีอยู่ "ถาวร" - จากนั้นพวกเขาจะรบกวนการสื่อสารเท่านั้น และโดยทั่วไปจะแยกงานกันเพื่อทำบางสิ่งบางอย่างให้สำเร็จ งานเหล่านี้อาจไม่เกี่ยวข้องกับ DevOps หรือการเปลี่ยนแปลงเลย ทำไมเราไม่มอบหมายงานนี้ให้กับแผนกที่มีอยู่ล่ะ?
เหตุใดจึงต้องมีทีมงานชั่วคราว?
ขัดแย้งกับกระบวนการปัจจุบัน. การเปลี่ยนแปลง DevOps ไม่ใช่แค่การเปลี่ยนแปลงในเทคโนโลยีและเครื่องมือที่เราใช้ แต่เป็นการเปลี่ยนแปลงในกระบวนการทำงาน ความคิด และค่านิยมด้วย หากทีมทำงานแบบเดิมก็จะไม่สามารถลองใช้วิธีอื่นได้
คนเหล่านี้ต้องดำเนินชีวิตตามกฎเกณฑ์ที่แตกต่างกัน: เพิกเฉยต่อ KPI ทั้งหมดในบริษัทเพราะพวกเขาพยายามทำงานแตกต่างออกไป ทีมชั่วคราวจะไม่กรอกใบสมัครเพื่อรับเซิร์ฟเวอร์ แต่จะตรงไปยังแผนกที่จัดการพวกเขา โดยเรียกร้องให้พวกเขาได้รับสิ่งที่ต้องการก่อน เพราะมันเป็นสิ่งสำคัญ และเพราะพวกเขาพยายามใช้ชีวิตที่แตกต่างออกไป ทีมงานขัดแย้งกับกระบวนการปัจจุบันทั้งหมดโดยสิ้นเชิง เพื่อให้แน่ใจว่าแนวทางการทำงานที่มีอยู่จะไม่รบกวนพวกเขาในตอนนี้ และพวกเขาจะไม่รบกวนผู้อื่น เราจึงแยกบุคคลเหล่านี้ออกเป็นทีมแยกต่างหาก
หลีกเลี่ยงระบบราชการในการทดลอง. ทีมชั่วคราวไม่มีระบบราชการ พวกเขาไม่ยื่นรายงานเวลา พวกเขาไม่ได้รายงานต่อผู้จัดการ นี่คือโลกที่แยกจากกันอย่างสิ้นเชิง ซึ่งผู้คนใช้ชีวิตและคิดแตกต่างและทำสิ่งที่แตกต่างอย่างสิ้นเชิง ไม่จำเป็นต้องรบกวนพวกเขาอีก
การทำงานไม่หยุดนิ่งในการให้บริการ. ในจุดแรก เราเลือกสิ่งที่เราจะทดลองด้วย การทดลองและค้นหาวิธีทำงานได้ดีขึ้นเป็นสิ่งที่ดี แต่เราก็อยากสร้างฟีเจอร์ด้วย หากทั้งทีมมุ่งเน้นไปที่การเปลี่ยนแปลงแทนที่จะเป็นฟีเจอร์ เราจะเริ่มสูญเสียรายได้ แมลงจะวนเวียนอยู่นาน - เราไม่ต้องการสิ่งนี้ การสร้างทีมชั่วคราวทำให้คุณสามารถทดลองได้โดยไม่ต้องหยุดทำงานกับผลิตภัณฑ์
ไม่ต้องเสียเวลากับงาน. เป็นเรื่องเกี่ยวกับผลิตภัณฑ์อีกครั้ง ทีมต้องใช้เวลามากในการลองใช้เครื่องมือและสิ่งอื่นๆ ต้องใช้เวลาอย่างน้อยหกเดือนกว่าที่ผู้คนจะเชี่ยวชาญเครื่องมือ เริ่มใช้งานและใช้งานตามปกติ หากพวกเขามุ่งเน้นไปที่ผลิตภัณฑ์ด้วย หกเดือนก็จะขยายออกไปอย่างจักรวาล หากผู้คนทำงานกับผลิตภัณฑ์ พวกเขาก็จะทำงานกับกระบวนการเก่าอีกครั้ง - เราไม่ต้องการสิ่งนั้น
ดังนั้นเราจึงมอบหมายบุคคลจากแผนกต่างๆ ให้กับทีมที่แยกจากกันซึ่งจะเปลี่ยนแปลงบริการ เป็นผลให้บริการใช้งานได้มีการพัฒนาอย่างต่อเนื่องและในขณะเดียวกันเราก็ทำการทดลองบางอย่างด้วย
ทีมงานชั่วคราวทุ่มเทให้กับการเปลี่ยนแปลง DevOps เท่านั้น โดยขจัดข้อจำกัดที่เราพบ และไม่มีอะไรเพิ่มเติม
ทีมงานประกอบด้วยบุคลากรที่หลากหลาย. ซึ่งหมายความว่าเราไม่ได้จ้างเฉพาะนักพัฒนาเท่านั้น เราไม่ได้มาที่ศูนย์บริการแล้วรับทีมไปครึ่งหนึ่ง - ไม่ เรารับ คนจากแผนกต่างๆ. เมื่อไม่กี่จุดที่ผ่านมา เราพบว่ามีแผนกต่างๆ และพนักงานที่แตกต่างกันที่เกี่ยวข้องกับบริการที่ได้รับการเปลี่ยนแปลง เรากำลังรับสมัครทีมงานจากพวกเขา เนื่องจากต้องเป็นสากล - เราจะเปลี่ยนกระบวนการทดสอบ กระบวนการพัฒนา และกระบวนการบำรุงรักษาบริการ จำเป็นต้องมีความสามารถที่แตกต่างกัน
โดยปกติแล้วเราจะจ้างนักพัฒนา ผู้ทดสอบ และวิศวกร ทีละคน และเมื่อร่วมมือกับพวกเขา เราก็จะคิดวิธีแก้ปัญหาที่ช่วยให้เราสามารถใช้ชีวิตที่แตกต่างออกไปได้
เป็นที่พึงปรารถนาที่คนเหล่านี้มีอำนาจในองค์กร. คุณอาจต้องใช้แบบอนุรักษ์นิยมแม้ว่าคุณจะไม่ต้องการก็ตาม หากเรามีบริษัทขนาดใหญ่ ไม่ใช่ทุกคนที่จะเชื่อในแนวคิดของเรา และบางคนอาจล้อเลียนเรา เช่น โดยการไม่จัดเตรียมจุดยืน ที่นี่คุณจะต้องมี "ผู้มีอำนาจ" ซึ่งเป็นบุคคลที่น่าเคารพและมีประสบการณ์มากมายซึ่งได้รับทัศนคติที่ดีจากเพื่อนร่วมงาน อำนาจของพนักงานในทีมจะทำให้งานและการทำงานของทีมชั่วคราวง่ายขึ้น ผู้คนจะคิดว่า:
- ใช่แล้ว เพื่อนเจ๋งๆ ที่เราทุกคนรู้จักและชื่นชอบเข้ากันได้พอดี - เห็นได้ชัดว่ามีบางสิ่งที่ควรค่าแก่การดูใน DevOps!
การตั้งเป้าหมาย
เรารวบรวมผู้คน เลือกบริการ ดูข้อจำกัด และตัดสินใจว่าเราจะมีอิทธิพลต่อใคร ตอนนี้คุณต้องตั้งเป้าหมายและควรจะตรงไปตรงมา โดยสมาร์ท - ทุกสิ่งที่เรารัก
เฉพาะเจาะจง - เฉพาะเจาะจง.
วัดได้ - วัดได้. นี่เป็นจุด SMART ที่สำคัญมาก หากคุณไม่สามารถวัดบางสิ่งบางอย่างได้ คุณจะไม่สามารถเปลี่ยนแปลงมันได้และเข้าใจว่าคุณทำอะไรดีขึ้นหรือแย่ลงได้อย่างไร
ทำได้ - ทำได้. ทำการปรับเปลี่ยนให้เหมาะกับความต้องการเฉพาะของคุณ หากคุณเป็นบริษัทองค์กรที่มีประวัติอันยาวนานและมีความรับผิดชอบมากมาย ซึ่งเปิดตัวเวอร์ชันของผลิตภัณฑ์ปีละครั้ง คุณจะไม่สามารถเปิดตัวผลิตภัณฑ์เวอร์ชันใหม่ได้ทุกชั่วโมงในหกเดือน มันจะไม่ทำงานอย่างนั้น ดังนั้นควรตั้งเป้าหมายที่สมจริงซึ่งสามารถทำได้ภายในกรอบเวลาที่ยอมรับได้
เกี่ยวข้อง - เกี่ยวข้อง เราลบเฉพาะข้อจำกัดที่ตอบสนองเป้าหมายปัจจุบันของเราเท่านั้น
เวลา จำกัด - จำกัด ในเวลา. หากไม่มีกำหนดเวลา ทีมงานจะพยายามทำทุกอย่างที่ต้องการ: ลองใช้เทคโนโลยี 15 รายการแทน 3 รายการ เขียนรายงานขนาดใหญ่ ดำเนินการวิจัยที่ไร้ประโยชน์ ขัดเกลาการใช้งานจนกว่าจะโดดเด่นเมื่อบรรลุเป้าหมายแล้ว
เราบรรลุเป้าหมายโดยใช้ Value Stream Map - เรารวบรวมผู้คนทั้งหมดอีกครั้งและวาดพวกเขา แต่ตอนนี้เท่านั้น ตาม Value Stream Map ก่อนหน้านี้ เราจึงวาดสิ่งที่เราต้องการได้
เราเน้นย้ำข้อจำกัดประการหนึ่งที่เราจะกำจัดออกไปในตอนนี้ - นี่คือสิ่งที่ทีมจะทำ ตามตัวอย่าง ฉันใช้เวลารอตั้งแต่การเปิดตัวที่เสร็จสมบูรณ์ไปจนถึงการใช้งานจริง นี่เป็นข้อจำกัดที่พบบ่อยที่สุดที่ผู้คนหันไปหาที่ปรึกษา
ตามนี้ เราได้กำหนดงาน: เราต้องการให้รอระหว่างการเปิดตัวที่เสร็จสิ้นแล้วและเข้าสู่การรบสูงสุดหนึ่งชั่วโมง
ตัวอย่างงาน
- ลดระยะเวลาการทดสอบจาก 4 วันเหลือ 1 ชั่วโมง
- ลดเวลามูลค่าเพิ่มสำหรับการทดสอบจาก 2 วันเหลือ 3 ชั่วโมง
- ลดระยะเวลาในการปรับใช้จาก 5 ชั่วโมงเหลือ 10 นาที
- เพิ่ม C/A จาก 50% เป็น 95% กล่าวคือ เพิ่มจำนวนฟีเจอร์ที่ผู้ทดสอบยอมรับ กล่าวคือ ปรับปรุงคุณภาพงานของนักพัฒนา
ตัวอย่างของงานไม่ได้ถูกพรากไปจากหัวของเรา แต่ขึ้นอยู่กับการวัดผลที่เราทำเมื่อพัฒนา Value Stream Map
เรากำหนดงานที่คล้ายกันสำหรับทีมของเราและกำหนดเวลา คุณกำหนดกำหนดเวลาที่แตกต่างกันออกไป ขึ้นอยู่กับว่าบริษัทของคุณทำงานได้ดีเพียงใด โดยเฉลี่ยแล้วจะใช้เวลาหกเดือนในการกำจัดข้อจำกัด หากผู้คนทำเช่นนี้เป็นครั้งแรกแต่ยังไม่รู้ว่าเทคโนโลยีใดและพวกเขาจะแก้ไขปัญหาได้อย่างไร
การวางแผนระยะสั้น
ทีมของเราจึงถูกสร้างขึ้น มีเป้าหมาย ผู้คนเริ่มทำงาน จุดสำคัญคือการวางแผนงานระยะสั้น: วิ่งหนึ่งถึงสองสัปดาห์และไม่มีอีกแล้ว การปรับปรุงที่วัดผลได้ ทุกสัปดาห์และ การแก้ไขหลักสูตร.
เช่น เรามักจะใช้วิธีนี้ การเคลื่อนย้ายการเคลื่อนย้ายเมื่อทั้งทีมมารวมตัวกันในช่วงต้นสัปดาห์ พวกเขาจะจดบันทึกสิ่งที่ทุกคนจะทำในไฟล์ หลังจากผ่านไปหนึ่งสัปดาห์ เราจะจดบันทึกสิ่งที่ทำไปแล้วและสิ่งที่ยังไม่ได้ทำ ถ้าไม่ แล้วทำไม และเราคิดว่าจะทำอย่างไรต่อไป
Sprints ช่วยให้คุณสามารถแก้ไขหลักสูตรได้ทันเวลา
เป็นเวลาหนึ่งหรือสองสัปดาห์ที่คุณลองบางอย่าง: เทคโนโลยี วิธีการ วิธีการทำงาน หลังจากนั้นคุณวัดผลอีกครั้งและดูว่าแนวทางนี้จะดีขึ้นหรือแย่ลงหรือไม่ หากแย่กว่านั้น แสดงว่าเรากำลังเดินไปผิดทาง เราต้องแก้ไขแนวทาง: กำหนดงานอื่น ใช้เทคโนโลยีอื่น หรือทำอย่างอื่น การวิ่งระยะสั้น 1-2 สัปดาห์ช่วยให้คุณสามารถควบคุมและหลีกเลี่ยงการตัดสินใจที่ผิดพลาดได้ทันเวลา
แบ่งปันความสำเร็จ
ทีมประสบความสำเร็จ ไม่ว่าจะเล็กหรือใหญ่ ไม่สำคัญ ย่อมมีผลลัพธ์อยู่เสมอ ทุกคนควรรู้เกี่ยวกับผลลัพธ์นี้ ทั้งที่เกี่ยวข้องกับ DevOps และแผนกใกล้เคียง ในโลกอุดมคติ ย่อมเป็นที่พึงปรารถนาที่สิ่งนี้จะเกิดขึ้น ให้กับทุกคนในบริษัท.
เพื่ออะไร? หากเราต้องการเปลี่ยนแปลงไม่ใช่แค่ส่วนหนึ่งของบริษัท ขจัดข้อจำกัดไม่ใช่แค่ข้อเดียว แต่รวมถึงทุกอย่างโดยทั่วไป เพื่อให้บริษัทมีความยืดหยุ่น รหัสเข้าถึงลูกค้าได้อย่างรวดเร็ว และไม่มีอะไรเสียหาย เราต้องการให้ทุกคนภักดีต่อแนวคิดนี้ ของ DevOps คุณจะไม่สามารถใช้แนวทางนี้กับบริการและทีมที่ต่อต้านอย่างแข็งขันได้
เพื่อให้ความภักดีปรากฏขึ้น เราต้องบอกทุกคนว่าเราลองทำสิ่งนี้แล้ว - เราได้ผลลัพธ์แล้ว ลองด้วย! สิ่งนี้จะเพิ่มความน่าสนใจและความภักดีต่อสิ่งที่เราทำ ผู้คนจะเริ่มพยายามทำอะไรบางอย่างในตอนนี้ ตามที่แสดงให้เห็นจากการฝึกซ้อม เมื่อเราบอกคุณว่าเราพยายามทำอะไรและประสบความสำเร็จ ทีมอื่นๆ จะเริ่มถามว่าเราทำอะไรและอย่างไร พวกเขาดูที่การใช้งาน โค้ด เอกสารประกอบ ตั้งคำถาม และพยายามเปลี่ยนแปลงบางสิ่งในตัวเอง
การพูดถึงสิ่งที่คุณทำเป็นสิ่งสำคัญ ด้วยวิธีนี้ คุณจะโน้มน้าวกลุ่มอนุรักษ์นิยมที่ต้องการทำทุกอย่างด้วยวิธีเดิมๆ เพื่อเข้าร่วมค่ายของคุณและเปลี่ยนพวกเขาให้เป็นนักสร้างสรรค์
เบ็ดเสร็จ
การเลือกบริการเพื่อเป็นจุดเริ่มต้น - สถานที่ที่เราจะเริ่มต้นการเปลี่ยนแปลงในบริษัท เราระบุทุกคนที่มีส่วนเกี่ยวข้องกับบริการ และกับพวกเขา การสร้างแผนที่สายธารคุณค่าเราวัดผลและดูว่ามีข้อจำกัดอยู่ที่ไหนและอย่างไร
การสร้างทีมชั่วคราวใหม่ซึ่งจะแก้ปัญหาได้ ขึ้นอยู่กับการวัดและแผนที่สตรีมคุณค่า เราวาดแผนที่ใหม่โดยเน้นย้ำข้อจำกัดที่เราจะแก้ไข. ขึ้นอยู่กับข้อจำกัดนี้ กำหนดงานซึ่งทางทีมงานจะจัดการด้วย หน้าที่ควรจะเป็น จำเป็นต้องฉลาด - เฉพาะเจาะจง วัดได้ เกี่ยวข้องกับงานปัจจุบัน และมีเวลาจำกัด
ทำซ้ำขั้นตอนนี้จนกว่าเราจะเปลี่ยนแปลงบริการทั้งหมดของเราให้อยู่ในรูปแบบที่ต้องการและขจัดข้อจำกัดทั้งหมด
โบนัส. วัสดุที่มีประโยชน์
สำหรับผู้ที่ตัดสินใจทำ DevOps ด้วยตัวเอง
โครงการฟีนิกซ์
ชื่อดั้งเดิมคือ “The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win” นี่คือนวนิยายเกี่ยวกับ DevOps - เรื่องราวเกี่ยวกับการที่พนักงานคนหนึ่งได้รับตำแหน่งหัวหน้าแผนกที่ลุกเป็นไฟอยู่เสมอ เจ้านายคนใหม่ได้รับมอบหมายงาน:
“คุณมีเวลาสองสามปีในการทำให้ทุกอย่างถูกต้อง เพื่อที่เราจะสามารถส่งมอบผลิตภัณฑ์ของเราให้กับลูกค้าได้อย่างรวดเร็วและมีประสิทธิภาพในที่สุด”
“โครงการฟีนิกซ์” นวนิยายเกี่ยวกับวิธีที่ DevOps เปลี่ยนแปลงชีวิตให้ดีขึ้น” เป็นหนังสือสำหรับผู้จัดการทุกคน เพราะคนเหล่านี้คือผู้ที่ตัดสินใจเกี่ยวกับสิ่งที่เกิดขึ้นในบริษัท หากคุณเป็นวิศวกรหรือโปรแกรมเมอร์และต้องการให้ความเคลื่อนไหวและการเปลี่ยนแปลงเริ่มต้นในบริษัทของคุณ ให้ซื้อหนังสือและมอบให้ฝ่ายบริหาร นวนิยายเรื่องนี้อธิบายทุกอย่างและอ่านง่ายและรวดเร็ว
คู่มือ DevOps
หนังสือเล่มนี้มีความซับซ้อนมากขึ้น ได้รับการตีพิมพ์เป็นภาษาอังกฤษเมื่อหลายปีก่อนภายใต้ชื่อ “คู่มือ DevOps วิธีสร้างความคล่องตัว ความน่าเชื่อถือ และความปลอดภัยระดับโลกในองค์กรเทคโนโลยี” แต่ตอนนี้มีให้บริการในภาษารัสเซียแล้ว นี่คือเรื่องจริง คู่มือ - คู่มือปฏิบัติ: วิธีดำเนินการวัดค่า Value Stream Map คืออะไร และเหตุใดจึงจำเป็น ควรไปที่ไหน เรียงลำดับอย่างไร หนังสือเล่มนี้มีไว้สำหรับผู้ที่ต้องการทำทุกอย่างด้วยตัวเอง ที่สำคัญที่สุดคือประกอบด้วยตัวอย่างประสบการณ์ของบริษัทอื่นๆ
ตัวอย่างเช่น ระบุว่าบริษัทแห่งหนึ่งสร้าง Value Stream Map ได้อย่างไร และตระหนักว่าข้อจำกัดไม่ได้อยู่ที่ตัวผลิตภัณฑ์ แต่ในความเป็นจริงแล้วแคชเชียร์เดินจากร้านค้าไปยังสำนักงานถัดไปเพื่อใช้ผลิตภัณฑ์นี้ แทนที่จะแก้ไขปัญหาด้วยโปรแกรม พวกเขาเพียงแต่ซื้อแท็บเล็ตให้กับพนักงานขาย และตอนนี้ไม่มีใครไปไหนเลย และการดำเนินการทั้งหมดจะดำเนินการในที่ทำงานของพวกเขา สรุป: Value Stream Map สามารถขยายได้ไม่เพียงแค่ซอฟต์แวร์เท่านั้น แต่ยังรวมถึงกระบวนการทั้งหมดในองค์กรด้วย
เร่งความเร็ว
ชื่อเต็ม: “เร่งความเร็ว: ศาสตร์แห่งซอฟต์แวร์แบบลีนและ DevOps: การสร้างและปรับขนาดองค์กรเทคโนโลยีที่มีประสิทธิภาพสูง” นี่คือระดับต่อไป - ฮาร์ดคอร์ หนังสือเล่มนี้ตีพิมพ์เมื่อปีที่แล้ว จนถึงขณะนี้มีเพียงภาษาอังกฤษเท่านั้นและเป็นเนื้อหาเกี่ยวกับการวิจัย ผู้เขียน ได้แก่ Nicole Forsgren, Jez Humble และ Gene Kim ได้ใช้แนวทางปฏิบัติที่แตกต่างกันในบริษัทต่างๆ มาเป็นเวลาหลายปี และค้นคว้าว่าแนวทางปฏิบัติใดส่งผลต่ออะไรและอย่างไร
บทที่สองเกี่ยวกับการวัด กล่าวถึง Value Stream Map, เมตริกที่ฉันกล่าวถึง และอื่นๆ อีกมากมาย และยังอธิบายกระบวนการวัดโดยละเอียดอีกด้วย ผู้เขียนวัดโดยใช้แบบสอบถามและงานติดตามตนเอง โดยจะอธิบายรายละเอียดว่าหน่วยเมตริกใดถูกต้องในการวัด ตัวใดไม่ควรวัด และข้อผิดพลาดของมนุษย์ในการวัด หากคุณประสบปัญหาในการวัด โปรดดูบทที่สองของหนังสือ "เร่งความเร็ว" หากทีมของคุณมีแนวทางปฏิบัติมากมาย แต่ไม่ชัดเจนว่าจะใช้แนวทางปฏิบัติใดในตอนนี้ วิธีใดในภายหลัง วิธีใดได้ผลจริง และวิธีใดไม่ได้อ่าน หนังสือเล่มนี้จะอธิบายทุกอย่าง
การเปลี่ยนแปลงเป็นปัญหาที่จุดบรรจบระหว่าง DevOps และการจัดการ ที่ไหนสักแห่งในพื้นที่เดียวกันของจุดตัดของการพัฒนา การดำเนินงาน และการทดสอบ เป็นหัวข้อที่เราพยายามจะพูดคุยกัน จำเป็นต้องมีการบูรณาการแบบเดียวกันเพื่อสร้างผลิตภัณฑ์ที่มีคุณภาพ - หัวข้อหลัก . การจัดการเทศกาล ส่ง - นั่นหมายความว่าทุกคนพร้อมสำหรับแนวคิดในการเปลี่ยนแปลง เข้าร่วมกับเราในวันที่ 27 และ 28 พฤษภาคม เราจะบูรณาการและเปลี่ยนแปลง
ที่มา: will.com
