เครื่องมือที่คล่องตัว Agile Approach คืออะไร และทำไมธุรกิจถึงต้องการมัน? ระเบียบวิธีแบบ Agile กับการจัดการโครงการแบบดั้งเดิม

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

เอเลนา ทรุสโควาพูดว่า:

สัปดาห์นี้ ฉันเสร็จสิ้นการฝึกอบรม Agile/Scrum สองวัน (ออกเสียงว่า “agile” และ “scrum”) ตามวิธีการพัฒนาแบบเปรียว ซอฟต์แวร์มีการเขียนวรรณกรรมที่ลึกซึ้งและไม่ลึกซึ้งมากนัก ฉันได้อ่านมามากแล้ว แต่หลังจากดื่มด่ำกับหัวข้อนี้เพียงสองวัน ในที่สุดฉันก็รวบรวมความเข้าใจพื้นฐานเกี่ยวกับหัวข้อที่ฉันเขียนบันทึกนี้

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

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

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

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

คล่องตัว

(eng.agile - “คล่องตัว, ว่องไว, มีไหวพริบ”)

แนวคิดเรื่องความยืดหยุ่น:

แทนที่ประเภทกิจกรรมของคุณด้วยคำว่า "การพัฒนา" - แล้วหลักการเหล่านี้จะใกล้เคียงและเข้าใจได้

“ผลิตภัณฑ์ที่ใช้งานได้คือตัวบ่งชี้หลักของความก้าวหน้า” “ความเรียบง่ายเปรียบเสมือนศิลปะแห่งการลดขนาด งานพิเศษ” และ “ผู้คนและการโต้ตอบมีความสำคัญมากกว่ากระบวนการและเครื่องมือ” - นั่นฟังดูสมเหตุสมผลใช่ไหม

สครัม

(การต่อสู้ภาษาอังกฤษ - ความเร่งรีบในการต่อสู้เพื่อลูกบอลในรักบี้)

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

ความเหนียวของ Scrum อยู่ที่โครงสร้าง มีแนวทางบางชุดที่ทำงานร่วมกันได้ดีกว่าแยกจากกัน ฉันหวังว่าจะไม่มีใครห้ามคุณให้ดึงบางสิ่งบางอย่างออกมาและใช้มัน

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

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

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

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

ทีมใน Scrum

ขนาดมาตรฐานของทีม Scrum คือ 7 คนบวกหรือลบ 2 คน นั่นคือตั้งแต่ห้าถึงเก้า การปรับขนาด Scrum เกิดขึ้น: คุณสามารถสร้างระบบการทำงานขนาดใหญ่จาก 25 ทีมได้ แต่หน่วยพื้นฐานของ Scrum คือทีม

แต่ละทีมมี:

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

อุปกรณ์วิ่ง

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

เจ้าของผลิตภัณฑ์มีรายการแนวคิดทางธุรกิจที่จะทำให้ผู้ใช้มีความสุข เรียกว่า Product Backlog รายการไอเดียสินค้า โดยจะจัดเรียงแนวคิดตามความสำคัญและความสำคัญ

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

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

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

โดยปกติแล้วการวิ่งระยะสั้นจะมีไอเดียบวกหรือลบ 2 ไอเดีย หากไอเดียใหญ่เกินไป ทีมจะแยกไอเดียเหล่านั้นออกเพื่อจะได้แสดงสิ่งเล็กๆ น้อยๆ ให้เห็นในการวิ่งแต่ละครั้ง

ใน Scrum แนวคิดต่างๆ เรียกว่าเรื่องราวของผู้ใช้ (เรื่องราวเกี่ยวกับผู้ใช้) และมีการกำหนดไว้ดังนี้: “ในฐานะ (บทบาท?) ฉันต้องการ (อะไร?) เพื่อที่จะ (ทำไม?)” ดังนั้นทีมงานจึงไม่เพียงมองเห็นฟังก์ชันการทำงานเท่านั้น แต่ยังรวมถึงความหมายของการสร้างสรรค์และสำหรับบทบาทเฉพาะ: ผู้ใช้ ลูกค้า ผู้ซื้อ

ผลลัพธ์ของการวิ่งเป็นสิ่งที่แสดงให้เห็นเสมอ ทีมแสดงผลงานของตนในการสาธิตเมื่อสิ้นสุดการวิ่ง

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

โครงสร้างสปรินท์

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

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

ผู้เข้าร่วมแต่ละคนจะตอบคำถามสามข้อตามลำดับ:

• เมื่อวานฉันทำอะไร
• วันนี้ฉันจะทำอะไร
• อะไรที่ทำให้ฉันช้าลง

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

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

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

“ถ้าฉันมีเวลาแปดชั่วโมงในการตัดต้นไม้ ฉันจะใช้เวลาหกชั่วโมงในการลับขวาน” (ประกอบกับคนตัดไม้และประธานาธิบดีอับราฮัม ลินคอล์น)

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

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

วิธี Agile: ความหมายและประวัติโดยย่อ

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

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

ด้วยเหตุนี้ ในช่วงทศวรรษที่ 90 จึงเป็นไปได้ที่จะสร้างชุดวิธีการพัฒนาซอฟต์แวร์ที่ยืดหยุ่นซึ่งสามารถแทนที่วิธีที่ซับซ้อนและใช้เวลานานได้ มันเกิดขึ้นเช่นนี้:

• ในปี 1991 ได้มีการนำวิธีการพัฒนาแอปพลิเคชันแบบรวดเร็วของ RAD มาใช้
• ในปี พ.ศ. 2537 ได้มีการวิธีการพัฒนาเกิดขึ้น ระบบไดนามิกดีเอสดีเอ็ม
• ในปี 1995 แพลตฟอร์ม Scrum (เฟรมเวิร์ก) สำหรับการพัฒนาที่ยืดหยุ่นได้ปรากฏขึ้น
• ในปี 1996 วิธีการพัฒนาแบบ Agile Crystal Clear ปรากฏขึ้น เช่นเดียวกับการเขียนโปรแกรม XP Extreme
• ในปี 1997 วิธีการพัฒนาซอฟต์แวร์แบบวนซ้ำ FDD ปรากฏขึ้น

วิธีการเหล่านี้รวมกันอยู่ภายใต้ชื่อทั่วไปของวิธีการพัฒนาซอฟต์แวร์แบบยืดหยุ่น

สี่ปีต่อมาในปี 2544 นักพัฒนาซอฟต์แวร์ 17 คนมารวมตัวกันที่รีสอร์ท Snowbird ในยูทาห์ (สหรัฐอเมริกา) จากการอภิปรายวิธีการพัฒนาจึงได้มีการเผยแพร่ "Manifesto on Agile Software Development" (แปลจากภาษาอังกฤษ แนวคิด "agile" หมายถึง "agile", "agile" หรือ "fast" แต่ในกรณีส่วนใหญ่จะมีการแปล ได้อย่างแม่นยำว่า "ยืดหยุ่น") เขาเป็นผู้กำหนดจังหวะสำหรับการทำงานเพิ่มเติมทั้งหมดเกี่ยวกับการสร้างซอฟต์แวร์

ประกาศเปรียว

แถลงการณ์ที่สร้างขึ้นโดยโปรแกรมเมอร์ประกอบด้วยแนวคิดพื้นฐาน 4 ประการและหลักการ 12 ประการ การจัดการที่มีประสิทธิภาพโครงการ ระบบการจัดการโครงการแบบ Agile ใดๆ (เราจะพูดถึงระบบในภายหลัง) นั้นมีพื้นฐานมาจากแนวคิดและหลักการเหล่านี้อย่างแม่นยำ แม้ว่าจะใช้ในรูปแบบที่แตกต่างกันก็ตาม

1. ผู้คนและการมีปฏิสัมพันธ์ของพวกเขามีความสำคัญมากกว่ากระบวนการและเครื่องมือ
2. ซอฟต์แวร์ที่ใช้งานได้มีความสำคัญมากกว่าเอกสารประกอบ
3. ลูกค้าและความร่วมมือกับพวกเขามีความสำคัญมากกว่าสัญญาและการเจรจาเงื่อนไข
4. ความเต็มใจที่จะเปลี่ยนแปลงมีความสำคัญมากกว่าแผนเดิม

หลักการเปรียว:

1. สร้างความพึงพอใจให้กับลูกค้าด้วยการส่งมอบซอฟต์แวร์ตั้งแต่เนิ่นๆ และสม่ำเสมอ (ลูกค้ามีความสุขเมื่อซอฟต์แวร์ทำงานมาถึงตามช่วงเวลาปกติ)
2. เปลี่ยนแปลงข้อกำหนดสำหรับผลิตภัณฑ์ขั้นสุดท้ายตลอดวงจรการพัฒนา
3. ส่งมอบซอฟต์แวร์ที่ใช้งานได้บ่อยที่สุดเท่าที่จะเป็นไปได้ (สัปดาห์ละครั้ง ทุกสองสัปดาห์ หนึ่งเดือน ฯลฯ)
4. สนับสนุนการทำงานร่วมกันระหว่างนักพัฒนาและลูกค้าตลอดวงจรการพัฒนา
5. สนับสนุนและจูงใจทุกคนที่เกี่ยวข้องในโครงการ (หากเธอรับมือกับงานได้ดีกว่าทีมที่สมาชิกไม่พอใจกับสภาพการทำงานมาก)
6. ให้ปฏิสัมพันธ์โดยตรงระหว่างนักพัฒนา (ความเป็นไปได้ในการติดต่อโดยตรงช่วยให้การสื่อสารประสบความสำเร็จมากขึ้น)
7. วัดความคืบหน้าผ่านซอฟต์แวร์ที่ใช้งานได้เท่านั้น (ลูกค้าควรได้รับเฉพาะซอฟต์แวร์ที่ใช้งานได้และใช้งานได้เท่านั้น)
8. รักษาความเร็วของการทำงานอย่างต่อเนื่อง (ทีมจะต้องพัฒนาความเร็วในการทำงานที่เหมาะสมและรักษาได้)
9. ใส่ใจกับการออกแบบและรายละเอียดทางเทคนิค (ด้วยทักษะที่มีประสิทธิภาพและการออกแบบที่ดี ทีมงานโครงการจึงสามารถปรับปรุงผลิตภัณฑ์และทำงานเพื่อปรับปรุงผลิตภัณฑ์ได้อย่างต่อเนื่อง)
10. พยายามทำให้เวิร์กโฟลว์เรียบง่ายที่สุดเท่าที่จะเป็นไปได้ และซอฟต์แวร์ก็เรียบง่ายและเข้าใจได้
11. อนุญาตให้สมาชิกในทีม (หากนักพัฒนาสามารถตัดสินใจด้วยตนเอง จัดระเบียบตัวเองและสื่อสารกับสมาชิกในทีมคนอื่น ๆ แลกเปลี่ยนความคิดเห็นกับพวกเขา ความเป็นไปได้ในการสร้างผลิตภัณฑ์ที่มีคุณภาพจะเพิ่มขึ้นอย่างมาก)
12. ปรับให้เข้ากับสภาพแวดล้อมที่เปลี่ยนแปลงตลอดเวลา (ด้วยเหตุนี้ผลิตภัณฑ์สำเร็จรูปจึงมีการแข่งขันมากขึ้น)

ในขณะที่เรียนรู้ Agile นอกเหนือจากภาพรวมของแนวคิดและกฎเกณฑ์แล้ว อย่าลืมดูวิดีโอสั้นนี้ซึ่งผู้เชี่ยวชาญด้านการจัดการโครงการ ที่ปรึกษา และโค้ชธุรกิจ Alexey Tachenkov พูดถึงพื้นฐานของระบบ

หากต้องการนำแนวคิดและหลักการข้างต้นไปปฏิบัติจริง คุณต้องปฏิบัติตามกฎหลายข้อ เมื่อนั้นการจัดการโครงการแบบ Agile จึงจะมีประสิทธิภาพได้

ประเด็นสำคัญในการใช้ Agile

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

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

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

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

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

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

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

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

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

• เมื่อวานฉันทำอะไร?
• วันนี้ฉันจะทำอะไร?
• อะไรขัดขวางไม่ให้ฉันทำงาน?

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

1. มีการระบุความสำคัญของโครงการไว้อย่างชัดเจน
2. ลูกค้ามีส่วนร่วมอย่างแข็งขันในกระบวนการนำไปใช้งาน
3. ขอบเขตของงานทั้งหมดดำเนินการทีละขั้นตอน
4. คุณควรมุ่งเน้นไปที่ผลลัพธ์ที่เฉพาะเจาะจง
5. จำนวนหนึ่งคณะทำงาน: ตั้งแต่ 7 ถึง 9 คน

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

ตัวอย่าง: รัฐบาลนิวซีแลนด์, รัฐบาลไนจีเรีย, กองทุนบำเหน็จบำนาญนอร์เวย์, บริษัท Return Path (ซอฟต์แวร์), บริษัท Oreo (การผลิตคุกกี้), บริษัท Aviasales (เครื่องมือค้นหาตั๋วเครื่องบินที่ใหญ่ที่สุด), บริษัท Hewlett-Packard (บริษัท IT ที่ใหญ่ที่สุดในอเมริกา), Sberbank " (คุณคงรู้ว่านี่คืออะไรJ)

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

วิธีการจัดการโครงการยอดนิยม

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

วิธีการต่อสู้

ในบรรดาวิธีการทั้งหมดของระบบ Agile Scrum มีความแตกต่างตรงที่ให้ความสำคัญกับการควบคุมคุณภาพของกระบวนการทำงานเป็นหลัก ผู้เชี่ยวชาญชาวญี่ปุ่นที่บรรยายเรื่องนี้เป็นคนแรก การจัดการเชิงกลยุทธ์ Hirotaka Takuechi และศาสตราจารย์ด้านวิทยาศาสตร์และเทคโนโลยี Ikujiro Nonaka เรียกวิธีนี้ว่า "แนวทางรักบี้" โดยที่ Scrum "ต่อสู้เพื่อลูกบอล"

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

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

ในกรณีส่วนใหญ่ Scrum จะใช้ในการทำงานกับซอฟต์แวร์ที่ซับซ้อนและสำหรับการพัฒนาผลิตภัณฑ์โดยใช้วิธีการแบบเพิ่มหน่วยและแบบวนซ้ำ ด้วยเหตุนี้ ประสิทธิภาพการทำงานของทีมจึงเพิ่มขึ้นอย่างมาก และเวลาที่ใช้ในการทำงานลดลง

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

วิธีคัมบัง

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

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

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

นี่เป็นเพียงตัวอย่างแนวทางปฏิบัติในการจัดการโครงการขั้นพื้นฐานแบบ Agile แต่คุณไม่ควรละเลยวิธีการอื่นๆ เช่น PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall และอื่นๆ นอกจากนี้ Agile ยังมีข้อดีข้อเสียอยู่บ้างเช่นกัน

ข้อดีและข้อเสียของ Agile

เมื่อเรียนรู้ Agile สิ่งสำคัญคือต้องรู้ทั้งด้านบวกและด้านลบของระเบียบวิธีนี้ เริ่มจากข้อดีกันก่อน

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

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

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

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

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

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

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

การนำ Agile ไปใช้

มีตัวอย่างการนำ Agile มาใช้ในงานของบริษัทต่างๆ มากมาย และเกือบทั้งหมดบอกว่าต้องใช้มาตรการสำคัญหลายประการ

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

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

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

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

บทสรุป

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

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

• การแปล

“ธุรกิจใดๆ ก็ตามใช้เวลานานกว่าที่คาดไว้เสมอ แม้ว่าเราจะคำนึงถึงกฎหมายของ Hofstadter ก็ตาม”
- กฎของฮอฟสตัดเตอร์

วิดีโอที่มีผู้เข้าชมมากที่สุดบน YouTube ในหัวข้อ Agile จำนวนการดู 744,625 ครั้ง ณ เวลาที่เผยแพร่บทความนี้ รูปแบบการนำเสนอที่ง่ายดาย รูปภาพ และใช้เวลาเพียง 15 นาที - ดีที่สุดเท่าที่ฉันเคยเห็นมา TED กำลังหยุดพัก

บทบาท

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

นี้ ผู้มีส่วนได้เสีย- พวกเขาจะใช้ผลิตภัณฑ์ สนับสนุน หรือมีส่วนร่วมในการพัฒนา

นี้ เรื่องราวของผู้ใช้- พวกเขาแสดงความปรารถนาของผู้มีส่วนได้เสีย ตัวอย่างเช่น “ในระบบการจองสายการบิน ผู้ใช้ควรจะสามารถค้นหาตามเที่ยวบินได้”

ผู้มีส่วนได้ส่วนเสียมีไอเดียมากมาย และ Pat ช่วยเปลี่ยนไอเดียให้เป็นเรื่องราวของผู้ใช้

นี้ ทีมพัฒนา- ผู้ที่จะ สร้างระบบการทำงาน

แบนด์วิธ

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

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

ปัญหาคือมีผู้สนใจจำนวนมากและคำขอของพวกเขาก็ไม่สามารถตอบสนองได้ 4-6 เรื่องต่อสัปดาห์

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

จะเกิดอะไรขึ้นถ้าเราทำทุกอย่างที่พวกเขาขอให้เราทำ? เราจะโอเวอร์โหลด

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

Scrum และ XP ในกรณีนี้ใช้วิธี "สภาพอากาศเมื่อวาน" ทีมงานกล่าวว่า: “เมื่อเร็ว ๆ นี้เราได้ทำคุณสมบัติ 4-6 รายการต่อสัปดาห์ เราจะทำคุณสมบัติ 4-6 รายการอะไรบ้างในสัปดาห์หน้า”

หน้าที่ของเจ้าของผลิตภัณฑ์คือการเลือกเรื่องราวของผู้ใช้อย่างชาญฉลาดที่จะนำไปใช้ในสัปดาห์นี้

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

ทั้งสองวิธีทำงานได้ดีและทั้งสองวิธีสร้างคิวงาน ซึ่งใน Scrum เรียกว่า Backlog หรือรายการงานที่จัดลำดับความสำคัญ

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

มีทางเดียวเท่านั้นที่จะควบคุมรายการงานของคุณ - คำว่า "ไม่"

นี่คือคำที่สำคัญที่สุดสำหรับเจ้าของผลิตภัณฑ์ เขาต้องฝึกมันทุกวันหน้ากระจก

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

เพื่อจัดลำดับความสำคัญอย่างถูกต้อง เจ้าของผลิตภัณฑ์จะต้องเข้าใจคุณค่าของแต่ละเรื่องและขอบเขตของมัน

การตัดสินใจ

เรื่องราวบางเรื่องมีความจำเป็นอย่างยิ่ง และบางเรื่องเป็นเพียงฟีเจอร์พิเศษเท่านั้น เรื่องราวบางเรื่องจะใช้เวลาสองสามชั่วโมงในการพัฒนา และบางเรื่องอาจใช้เวลาหลายเดือนในการพัฒนา

ความสัมพันธ์ระหว่างขนาดเรื่องและมูลค่าคืออะไร? ไม่มีทาง.มากกว่าไม่ได้หมายความว่าดีขึ้น คุณค่าและความซับซ้อนของงานคือสิ่งที่ช่วยให้ Pat จัดลำดับความสำคัญ

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

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

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

Pat จัดการประชุมการทำความสะอาด Backlog ทุกวันพุธตั้งแต่เวลา 11.00 น. ถึง 12.00 น. โดยปกติแล้วจะเป็นการรวมทีมทั้งหมดและบางครั้งผู้มีส่วนได้ส่วนเสียหลายคน เนื้อหาการประชุมแตกต่างกันไป เน้นการประเมิน การแบ่งเรื่องราว เกณฑ์การยอมรับ

เจ้าของสินค้าไอทีจะต้องสื่อสารกับทุกคนอย่างต่อเนื่อง

เจ้าของผลิตภัณฑ์ที่มีประสบการณ์ระบุองค์ประกอบสองประการของความสำเร็จ: ความหลงใหลในการทำงานและการสื่อสาร เจ้าของสินค้าแก้ปัญหาอะไรร่วมกับทีมงาน?

สร้างความสมดุลระหว่างความซับซ้อนในการพัฒนาและคุณค่าของเรื่องราวของผู้ใช้

ในช่วงแรก งบดุลถูกคุกคามจากความไม่แน่นอนและความเสี่ยงหลายประการในคราวเดียว

ความเสี่ยง

ความเสี่ยงทางธุรกิจ: “เรากำลังทำสิ่งที่ถูกต้องหรือไม่?”

ความเสี่ยงทางสังคม: “เราสามารถทำสิ่งที่เราจำเป็นต้องทำได้หรือไม่?”

ความเสี่ยงทางเทคนิค: “โครงการจะทำงานบนแพลตฟอร์มนี้หรือไม่”

ความเสี่ยงด้านต้นทุนและเวลาในการดำเนินการ “เราจะทำได้ทันและจะมีเงินเพียงพอหรือไม่”

ความรู้ถือได้ว่าเป็นสิ่งที่ตรงกันข้ามกับความเสี่ยง เมื่อมีความไม่แน่นอนสูง เราจะมุ่งเน้นไปที่การได้รับความรู้ - ต้นแบบอินเทอร์เฟซ การทดลองทางเทคนิค

การแลกเปลี่ยนระหว่างคุณค่าความรู้และคุณค่าของลูกค้า

จากมุมมองของลูกค้า เส้นโค้งมีลักษณะดังนี้:

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

การแลกเปลี่ยนระหว่างการคิดระยะสั้นและระยะยาว

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

ทำสิ่งที่ถูกต้อง ทำสิ่งที่ถูกต้อง หรือทำสิ่งต่าง ๆ อย่างรวดเร็ว?

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

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

เราทำต้นแบบผลิตภัณฑ์อย่างรวดเร็ว ซึ่งก็ไม่เลวสำหรับระยะสั้น ในระยะยาวเรามีความเสี่ยงทางเทคนิค และความเร็วในการพัฒนาจะลดลงเหลือศูนย์

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

มีความตึงเครียดที่ดีระหว่างบทบาทต่างๆ ใน ​​Scrum

เจ้าของผลิตภัณฑ์มุ่งเน้นไปที่การสร้างสิ่งที่ถูกต้อง ทีมงานมุ่งเน้นไปที่การสร้างสิ่งที่ถูกต้อง Scrum Master หรือ Agile Coach มุ่งเน้นไปที่การทำให้วงจรสั้นลง ข้อเสนอแนะ.

นอกจากนี้ยังควรเน้นย้ำถึงความสำคัญของความเร็ว เนื่องจากฟีดแบ็กสั้นๆ จะช่วยเร่งการเรียนรู้ สิ่งนี้ช่วยให้เราเรียนรู้ได้อย่างรวดเร็วว่าสิ่งใดถูกต้องและจะสร้างอย่างไรให้ถูกต้อง

การแลกเปลี่ยนระหว่างการพัฒนาผลิตภัณฑ์ใหม่และการปรับปรุงผลิตภัณฑ์เก่า

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

ตารางการทำลายเรื่องราว

ในบางครั้ง ผู้มีส่วนได้ส่วนเสียจะถาม Pat ว่า “ฟีเจอร์ของฉันจะเผยแพร่เมื่อใด” หรือ “จะมีฟีเจอร์กี่รายการที่จะออกในวันคริสต์มาส” เจ้าของผลิตภัณฑ์จะต้องสามารถจัดการความคาดหวังของผู้ใช้ได้ และบริหารจัดการความคาดหวังได้อย่างสมจริง

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

สมมติว่าผู้สนใจถามว่าจะสร้างฟีเจอร์นี้เมื่อใด

นี่เป็นคำถามที่มีเนื้อหาคงที่และไม่มีกำหนดระยะเวลา แพทใช้เส้นแนวโน้มสองเส้นในการตอบ คำตอบคือในเดือนเมษายนหรือพฤษภาคม

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

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

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

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

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

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

คำถามที่ไม่สะดวก

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

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

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

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

ทำทันที!

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

ขั้นตอนการพัฒนาใน Agile หรือสิ่ง “ครั้งแล้วครั้งเล่า” นี้เรียกว่าการวนซ้ำ การวนซ้ำมีระยะเวลาเท่ากันตลอดทั้งโครงการและเฉลี่ยสองสัปดาห์ ภายในการวนซ้ำครั้งเดียว จะมีการดำเนินการงานเฉพาะ ซึ่งคุณสมบัติหลักคือโซลูชันควรอัปเดตผลิตภัณฑ์ เวอร์ชันใหม่หรือเพิ่มประสิทธิภาพของมัน บนพื้นฐานนี้จึงมีการเลือกงานดังกล่าว

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

องค์กรแนวนอน

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

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

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

แต่มี ความรู้พื้นฐานเกี่ยวกับความเชี่ยวชาญเฉพาะด้านที่เกี่ยวข้องกับการพัฒนาแบบคล่องตัวเป็นสิ่งจำเป็น

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

จะใช้งาน Agile ได้อย่างไร?

การเปลี่ยนจากการพัฒนา Waterfall ซึ่งยังคงพบเห็นได้ทั่วไปในหลายๆ องค์กร มาเป็นวิธีการทำงานในโครงการที่คล่องตัวอาจเป็นเรื่องที่เจ็บปวดทีเดียว

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

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

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

ตามกฎแล้วผลิตภัณฑ์และบริการถูกสร้างขึ้นตามรูปแบบคลาสสิกเดียว สิ่งนี้ใช้กับอุตสาหกรรมไอทีโดยเฉพาะ โครงการนี้เรียกว่าน้ำตกหรือวิธีการพัฒนาแบบวนซ้ำและมา ภาษาอังกฤษ– การพัฒนาน้ำตก (“น้ำตก”) โครงการนี้มีชื่อนี้ด้วยเหตุผลอะไร? ประเด็นก็คือหากคุณได้อนุมัติแผนสำหรับผลิตภัณฑ์ซอฟต์แวร์แล้ว คุณจะไม่สามารถระงับหรือทำการปรับเปลี่ยนก่อนนำไปใช้ได้ มีหลักการที่แตกต่างไปจากเดิมอย่างสิ้นเชิง ระเบียบวิธีแบบเปรียวน้ำตกเป็นแนวคิดที่ใช้ไม่ได้กับมัน นี่เป็นแนวทางใหม่เชิงคุณภาพในการสร้างผลิตภัณฑ์ พื้นฐานของวิธีการคือแนวคิดง่ายๆ - ผู้เข้าร่วมแต่ละคนมีโอกาสที่จะจัดทำข้อเสนอที่เป็นประโยชน์เพื่อเพิ่มประสิทธิภาพกระบวนการ หยุดสายพานลำเลียงเพื่อคิดใหม่เกี่ยวกับงานและสาเหตุทั่วไป

ระเบียบวิธีแบบ Agile มีกรอบการทำงานที่มีลักษณะเฉพาะหลายประการ ในหมู่พวกเขา:

• ตอบสนองต่อการเปลี่ยนแปลงอย่างรวดเร็ว
• องค์กรอิสระกระบวนการผลิต
• ความสามารถในการคาดการณ์
• ความพร้อมใช้งานของการตอบรับอย่างต่อเนื่องและสม่ำเสมอ
• การกำหนดขอบเขตความเสี่ยง

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

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

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

แน่นอนว่าบางบริษัทไม่จำเป็นต้องมีระเบียบวิธีแบบ Agile ตัวอย่างเช่น เรากำลังพูดถึงหน่วยงานของรัฐ เนื่องจากพื้นฐานของกิจกรรมของพวกเขาคือบรรทัดฐานทางกฎหมาย การโต้ตอบกับรัฐเป็นไปไม่ได้หากกฎของเกมเปลี่ยนแปลงเป็นประจำ

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

หลักการพื้นฐานของระเบียบวิธีแบบ Agile

มี Agile manifesto ซึ่งพูดถึงหลักการพื้นฐานของระเบียบวิธี:

1. สิ่งที่สำคัญที่สุดคือการส่งมอบผลิตภัณฑ์ที่มีคุณค่าอย่างสม่ำเสมอและล่วงหน้าจึงจะสนองความต้องการของลูกค้าได้ ตามหลักการของระเบียบวิธีแบบ Agile นี้ ผู้สร้างผลิตภัณฑ์มีหน้าที่ไม่เพียงแต่จะต้องปฏิบัติตามข้อกำหนดที่ระบุไว้ในเอกสารการออกแบบเท่านั้น แต่ยังต้องแจ้งให้ผู้บริโภคทราบโดยเร็วที่สุดเท่าที่จะเป็นไปได้ว่าจะเป็นผลิตภัณฑ์ประเภทใด พร้อมคุณสมบัติและคุณลักษณะใดบ้าง หากสินค้าไม่เป็นที่พอใจของลูกค้า จำเป็นต้องแก้ไขโดยคำนึงถึงความคิดเห็นอย่างเร่งด่วน เนื่องจากเมื่อแนะนำผลิตภัณฑ์ใหม่สู่สภาพแวดล้อมของตลาด มีความเสี่ยงสูงที่จะเกิดข้อผิดพลาด จึงควรใช้อย่างสมเหตุสมผล ข้อกำหนดทางเทคนิคเพื่อสร้างผลิตภัณฑ์ที่มีศักยภาพขั้นต่ำ (MVP) งานหลักคือการตรวจสอบว่าคุณสมบัติหลักที่เป็นที่ต้องการของผู้ซื้อและประเมินระดับความต้องการ
2. ข้อกำหนดสามารถเปลี่ยนแปลงได้และสิ่งนี้จะรับรู้ในเชิงบวกหากเรากำลังพูดถึงการปรับปรุงคุณภาพการแข่งขันของผลิตภัณฑ์ โดยปกติจะมีการเปลี่ยนแปลงเมื่อสิ้นสุดขั้นตอนการพัฒนาขั้นสุดท้าย หลักการของระเบียบวิธี Agile นี้มีความสำคัญมากในปัจจุบันเนื่องจากผลิตภัณฑ์ของพื้นที่ที่มีเทคโนโลยีสูงใน โดยเร็วที่สุดล้าสมัยและหลีกทางให้อันใหม่ คุณสามารถกำหนดข้อกำหนดจำนวนหนึ่งสำหรับผลิตภัณฑ์เมื่อสิ้นสุดการสร้างได้ ซึ่งมักเกิดจากการเปลี่ยนแปลงของตลาดหรือคู่แข่ง โปรดทราบว่าการนำหลักการนี้ไปปฏิบัตินั้นเป็นไปไม่ได้หากเรากำลังพูดถึงรูปแบบการจัดการแบบเรียงซ้อนหรือมันเป็นเรื่องจริง แต่จะทำให้ผู้สนับสนุนต้องเสียค่าใช้จ่ายเป็นจำนวนเงินที่เป็นระเบียบ แต่ยิ่งเทคโนโลยีผสานกันมากขึ้นเท่าไร การเตรียมผลิตภัณฑ์รุ่นต่อไปก็จะยิ่งมีความสำคัญมากขึ้นเท่านั้นเพื่อให้นำหน้าคู่แข่ง
3. ทีมงานและลูกค้าจะต้องมีปฏิสัมพันธ์อย่างต่อเนื่องในทุกขั้นตอนของการสร้างผลิตภัณฑ์ กฎข้อนี้มีลักษณะใกล้เคียงกับความปรารถนาของลูกค้า นี่คือสิ่งที่สำคัญที่สุด หากไม่มีปฏิสัมพันธ์อย่างต่อเนื่อง ก็เป็นเรื่องยากที่จะบรรลุเป้าหมาย
4. ระเบียบวิธีแบบ Agile ระบุว่าโครงการต่างๆ ควรดำเนินการโดยผู้เชี่ยวชาญที่มีแรงบันดาลใจเท่านั้น ดูแลสร้างเงื่อนไขที่เหมาะสมและไว้วางใจผู้เชี่ยวชาญ ในกรณีนี้ความน่าจะเป็นของการดำเนินโครงการคุณภาพสูงนั้นสูงมาก วิทยาศาสตร์สมัยใหม่ชี้ให้เห็นว่างานทางปัญญาเป็นเรื่องยากที่จะกระตุ้นด้วยสิ่งจูงใจทางการเงิน ดังนั้นคุณควรร่วมมือเฉพาะกับผู้เชี่ยวชาญที่มีแรงจูงใจหลักคือตัวโครงการเท่านั้น สิ่งเดียวที่พวกเขาต้องการคือสามารถทำงานในสภาพที่ยอมรับได้และได้รับความไว้วางใจจากลูกค้า
5. วิธีที่ดีที่สุดการสื่อสาร - การติดต่อส่วนตัว- เป็นที่พึงปรารถนาที่ทุกคนที่เกี่ยวข้องในโครงการจะตั้งอยู่ในอาณาเขตร่วมกัน ให้มันเป็นอาคารเดียว ตามหลักการแล้วลูกค้าควรจะอยู่ที่นั่น
6. โครงการจะดำเนินไปหากผลิตภัณฑ์ใช้งานได้ ลูกค้าสนใจ สินค้าสำเร็จรูปมีลักษณะบางอย่าง ขั้นตอนที่สำเร็จอีกขั้นตอนหนึ่งของกระบวนการไม่มีความหมายสำหรับเขาเลย ลูกค้าจะต้องเห็นว่าผลิตภัณฑ์กำลังพัฒนาและที่สำคัญที่สุดคือใช้งานได้และตรงตามข้อกำหนดที่ระบุไว้ หากรูปร่างและเนื้อหาใกล้เคียงกับโมเดลที่ต้องการ แสดงว่านักพัฒนาดำเนินการอย่างมีประสิทธิภาพ
7. ผู้สนับสนุน ลูกค้า และนักพัฒนาจำเป็นต้องกังวลเกี่ยวกับการดำเนินกิจกรรมอย่างต่อเนื่อง หากผู้เข้าร่วมทุกคนในกระบวนการดำเนินการอย่างมั่นคง พวกเขาก็เลิกกังวลเกี่ยวกับโอกาสฉุกเฉินหรือพลาดกำหนดเวลา
8. ควรให้ความสนใจกับความเป็นเลิศด้านเทคนิคและคุณภาพการออกแบบด้วย ระเบียบวิธีแบบ Agile ระบุว่าการพัฒนาโครงการควรมีความยืดหยุ่น โดยไม่กระทบต่อคุณภาพของผลิตภัณฑ์หรือลดความซับซ้อนของคุณลักษณะ โปรดทราบว่ามักใช้วิธีนี้เพื่อเร่งกระบวนการสร้างโครงการและเพิ่มประสิทธิภาพ
9. อย่าลืมหลักความเรียบง่าย เมื่อใช้ คุณจะลดโอกาสในการดำเนินการที่ไม่จำเป็นให้เหลือน้อยที่สุด ประเด็นไม่ได้อยู่ที่การลดความซับซ้อนของคุณลักษณะของผลิตภัณฑ์ แต่เพื่อกำจัดการดำเนินการที่ไม่จำเป็นและไม่รวมถึงสิ่งที่ไม่จำเป็นสำหรับการใช้งานตามวัตถุประสงค์ในการออกแบบ
10. ทีมที่จัดระเบียบตนเองมักจะสร้างขึ้น ความคิดที่ดีที่สุดแผนสถาปัตยกรรม เทคนิค และอื่นๆ ผู้เขียน Agile Manifesto มั่นใจในเรื่องนี้ ดังนั้นสมาชิกในทีมทุกคนจึงต้องพัฒนาข้อกำหนดและตัดสินใจร่วมกัน หากสมาชิกในทีมมีความสนใจและเป้าหมายร่วมกัน การจัดระเบียบตนเองจะมีประสิทธิภาพมากขึ้น
11. สภาวะภายนอกเปลี่ยนแปลงตลอดเวลา ในเรื่องนี้ควรวิเคราะห์และปรับตัวให้เข้ากับสถานการณ์อยู่เสมอ และมองหาวิธีการปรับปรุงประสิทธิภาพการดำเนินงาน วิธีการแบบ Agile มุ่งเน้นไปที่ความยืดหยุ่นของนักพัฒนาโดยเฉพาะ นี่คือสิ่งที่คุณต้องมุ่งมั่นเพื่อ

ความคิดเห็นของผู้เชี่ยวชาญ

อนาคตของระเบียบวิธี Agile ในรัสเซีย

อันเดรย์ โคเชชคอฟ,

หัวหน้านักวิเคราะห์ของสำนักพิมพ์ OJSC Prosveshcheniye

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

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

วิธีการที่ยืดหยุ่น: Agile, Lean, Scrum และอื่นๆ

Agile Manifesto กำหนดหลักการเฉพาะ จากแนวทางดังกล่าว จึงเกิดวิธีการพัฒนาแบบยืดหยุ่นที่เรียกว่า Agile

• การสร้างแบบจำลองเปรียว (AM) ในที่นี้จะใช้ขั้นตอนสำหรับการสร้างแบบจำลอง (รวมถึงการตรวจสอบด้วยรหัสโมเดล) และเอกสารประกอบระหว่างการสร้างซอฟต์แวร์ ให้ความสนใจน้อยลงกับขั้นตอนในการออกแบบและสร้างไดอะแกรมใน UML ไม่มีการเอ่ยถึงในด้านต่างๆ เช่น การพัฒนา การทดสอบ การจัดการโครงการ การใช้งาน และการบำรุงรักษา
• Agile Unified Process (AUP) เป็นเวอร์ชันรวมของระเบียบวิธี RUP (IBM Rational Unified Process) ที่สร้างโดย Scott Ambler AUP กำหนดรูปแบบการพัฒนาซอฟต์แวร์สำหรับการใช้งานทางธุรกิจ
• Agile Data Method (ADM) เป็นวิธีการวนซ้ำสำหรับการพัฒนาซอฟต์แวร์แบบ Agile ที่ซับซ้อนซึ่งเน้นการพัฒนาโซลูชันและข้อกำหนด ทีมงานข้ามสายงานต่างๆ ทำงานร่วมกัน
• วิธีการพัฒนาระบบแบบไดนามิก (DSDM) เป็นวิธีการที่เพิ่มขึ้นและทำซ้ำโดยอาศัยการพัฒนาแอปพลิเคชันอย่างรวดเร็ว (RAD) สิ่งสำคัญอยู่ที่การเพิ่มการมีส่วนร่วมของผู้บริโภคขั้นสุดท้ายในการสร้างสรรค์ผลิตภัณฑ์
• กระบวนการรวมศูนย์ที่สำคัญ (EssUP) ผู้เขียนแนวทางนี้คือ Ivar Jacobson แนวทางนี้มีวิธีการสร้างซอฟต์แวร์แบบวนซ้ำ เน้นที่สถาปัตยกรรมผลิตภัณฑ์และแนวทางปฏิบัติของทีมที่ยืมมาจาก RUP, CMMI และ Agile Development สาระสำคัญของแนวคิดคือการใช้วิธีการและเทคนิคที่ใช้ในบางกรณีเท่านั้น เป็นทางเลือกของพวกเขาที่เป็นพื้นฐานในการกำหนดกระบวนการเป้าหมาย แนวทางนี้แตกต่างจาก RUP โดยมีวิธีการและแนวปฏิบัติที่เกี่ยวข้องกัน นอกจากนี้ยังมีความยืดหยุ่นและความสามารถในการแยกองค์ประกอบที่จำเป็นออกจากทุกสิ่งที่มีอยู่
• Extreme Programming (XP) หรือการเขียนโปรแกรมแบบเอ็กซ์ตรีม สาระสำคัญของวิธีการนี้คือการใช้เทคนิคที่ดีที่สุดที่มีอยู่แล้วในด้านการสร้างซอฟต์แวร์และปรับปรุง แนวทางและแนวปฏิบัติปกตินี้แตกต่างกัน โดยเฉพาะอย่างยิ่งในกรณีหลังนี้โปรแกรมเมอร์จะทำการตรวจสอบโค้ดที่เพื่อนร่วมงานเขียนตามลำดับ การตั้งโปรแกรมขั้นสูงเกี่ยวข้องกับการทดสอบแบบขนาน ซึ่งช่วยให้ปล่อยผลิตภัณฑ์ได้เร็วขึ้น แต่ในขณะเดียวกันก็เพิ่มความเสี่ยง
• การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะ (FDD) ภายในกรอบการใช้วิธีนี้มีข้อห้ามหลักๆ คือ การดำเนินการแต่ละฟังก์ชันควรดำเนินการภายในสองสัปดาห์ และไม่มากไปกว่านั้น ตามหลักการแล้ว การพัฒนาจะเสร็จสิ้นในคราวเดียว หากเป็นไปไม่ได้ ฟังก์ชันนี้จะถูกแบ่งออกเป็นหลายส่วนและใช้งานได้อย่างราบรื่น
• Getting Real (GR) - เมื่อใช้วิธีการนี้ จะไม่หันไปใช้ขั้นตอนของข้อกำหนดคุณสมบัติการทำงานที่ใช้สำหรับแอปพลิเคชันเว็บ การพัฒนาเริ่มต้นด้วย ด้านหลังนั่นคือ อันดับแรกพวกเขาคิดถึงการออกแบบและอินเทอร์เฟซ จากนั้นจึงเกี่ยวกับเนื้อหาที่ใช้งานได้
• OpenUP (OUP) - การพัฒนาแนวทางนี้อิงจาก RUP วิธีการนี้กำหนดวิธีการสร้างซอฟต์แวร์แบบวนซ้ำแบบเพิ่มหน่วย ภายในกรอบของแนวทางที่กล่าวมานั้น วงจรชีวิตการพัฒนา (ขั้นตอนของการเปิดตัว การปรับแต่ง การพัฒนา และการถ่ายโอนไปยังลูกค้า) วิธีการนี้ถูกนำไปใช้ในหลายขั้นตอน โดยตรวจสอบจุดควบคุมบางอย่าง ซึ่งจะช่วยเพิ่มประสิทธิภาพในการควบคุมและติดตามการดำเนินโครงการ การตัดสินใจทั้งหมดเกี่ยวกับโครงการจะต้องตรงเวลา
• การพัฒนาซอฟต์แวร์แบบลีน พื้นฐานของแนวทางนี้คือแนวคิดของการจัดการแบบ Lean ของบริษัทผู้ผลิต (การผลิตแบบ Lean, การผลิตแบบ Lean)
• Scrum เป็นหนึ่งในวิธีที่ได้รับความนิยมมากที่สุดสำหรับการพัฒนาซอฟต์แวร์แบบ Agile และกำหนดกฎเกณฑ์สำหรับการจัดการกระบวนการผลิตโดยใช้วิธีการที่รู้จักกันดี ในกรณีนี้จะเน้นไปที่การมีส่วนร่วมของลูกค้าในการพัฒนา (เมื่อขั้นตอนต่อไปเสร็จสิ้น เป็นไปได้ที่จะเปลี่ยนแปลงหรือชี้แจงข้อกำหนดสำหรับผลิตภัณฑ์ที่กำลังสร้าง) ซึ่งช่วยให้คุณสามารถระบุข้อบกพร่องและปรับเปลี่ยนผลิตภัณฑ์ได้

วิธี Agile Scrum เป็นหนึ่งในเทคโนโลยียอดนิยม

วิธีการแบบ Agile ที่พบบ่อยที่สุดก็คือ Scrum ชื่อนี้มาจากรักบี้ ปัจจุบันนี่คือชื่อของวิธีการพัฒนาแบบยืดหยุ่นที่มีโครงสร้างมากที่สุดอย่าง Agile “ การแย่งชิง” ในสนามกีฬาเป็นการกระทำของทีมที่เข้มข้นโดยมีเป้าหมายเพื่อให้บรรลุเป้าหมาย - รับลูกบอลเพื่อโจมตีศัตรูในภายหลัง

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

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

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

มีขั้นตอนการวางแผนที่จะกำหนดคุณสมบัติการทำงานใหม่ของผลิตภัณฑ์ที่สร้างขึ้นสำหรับการวิ่งครั้งต่อไป หลังจากแก้ไขปัญหาแล้ว จะมีการสร้าง Sprint Backlog มันยังคงไม่เปลี่ยนแปลงตลอดระยะเวลาทั้งหมด

วิธีการยังกำหนดบทบาทที่มีโครงสร้างในโครงการ:

• Scrum Master เป็นตัวกลางระหว่างทีมและลูกค้า
• เจ้าของผลิตภัณฑ์เป็นตัวแทนของลูกค้า จัดทำแบบฟอร์ม จัดลำดับความสำคัญของ Product Backlog และยอมรับผลงานชั่วคราวของงาน
• ทีม – ทีมงานโครงการที่ไม่มีบทบาทแยกกัน เป็นระบบการจัดการตนเองซึ่งรวมถึงผู้เชี่ยวชาญที่มีแรงบันดาลใจและข้ามสายงาน

วิธีการนี้ให้ข้อดีหลายประการแก่นักการเงิน กล่าวคือ:

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

ปัญหาหลักในกรณีนี้คือคำถาม การลงทะเบียนทางกฎหมายกิจกรรมประเภทนี้และการโต้ตอบกับทีมพัฒนาภายนอก

ทำไมคุณถึงต้องมีวิธีการจัดการแบบ Agile?

• ระบบช่วยให้คุณรู้สึกดีในช่วงวิกฤตและในสถานการณ์ที่ไม่แน่นอน สร้างรายได้ ปกป้องธุรกิจของคุณ และใช้ทรัพยากรและโอกาสที่มีอยู่อย่างมีประสิทธิภาพ
• ระเบียบวิธีแบบ Agile เป็นที่ต้องการของทั้งองค์กรขนาดใหญ่ที่เกี่ยวข้องกับการนำวิธีการจัดการแบบยืดหยุ่นไปใช้ และ บริษัทขนาดเล็ก- สำหรับวิธีการแบบ Agile ล่าสุด – ตัวเลือกที่ดีที่สุด- เรากำลังพูดถึงสถานประกอบการจัดเลี้ยงที่นี่ คลินิกทันตกรรมและสำนักงาน โชว์รูมรถยนต์ นอกจากนี้ วิธีการแบบ Agile ยังช่วยให้คุณ “ปรับแต่ง” กระบวนการทางธุรกิจในด้านต่างๆ เช่น องค์กรได้ กิจกรรมทางเศรษฐกิจต่างประเทศ,การสร้างระบบการขายและการจัดการภาวะวิกฤติ
• ระเบียบวิธีแบบ Agile ถูกนำมาใช้ในการจัดการ การตลาด อุตสาหกรรมการเงิน และการบริหารงานบุคคล ด้วยเหตุนี้คุณจึงสามารถดำเนินโครงการได้อย่างรวดเร็วและได้ผลลัพธ์ที่ยอดเยี่ยม
• ระเบียบวิธีแบบ Agile เป็นเรื่องแรกและสำคัญที่สุดเกี่ยวกับการคิดแบบยืดหยุ่น และจากนั้นก็เกี่ยวกับเครื่องมือเท่านั้น หากต้องการใช้ให้สำเร็จคุณต้องป้อน การเปลี่ยนแปลงบางอย่างสู่ความคิดและวัฒนธรรมในการทำงานกับโครงการในองค์กร
• Agile มีหลายวิธี ที่ได้รับความนิยมมากที่สุดในปัจจุบันคือ Scrum และ Kanban
• วิธีการแบบ Agile ช่วยยกระดับธุรกิจของคุณไปอีกระดับ โดยคำนึงถึงความสามารถที่มีอยู่ ทรัพยากร และทักษะการปฏิบัติของพนักงาน
• วิธีการแบบ Agile เหมาะสำหรับองค์กรที่มุ่งเน้นการสร้างรายได้และเพิ่มอิทธิพลในสภาพแวดล้อมของตลาด
• ระเบียบวิธีแบบ Agile ช่วยให้มั่นใจในการค้นหาและการแนะนำเทคโนโลยีใหม่ที่เกี่ยวข้องกับความก้าวหน้าและการพัฒนาภายใน กิจกรรมผู้ประกอบการความคิดสร้างสรรค์ในแนวทางและการคิดในองค์กรขนาดใหญ่

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

ความคิดเห็นของผู้เชี่ยวชาญ

การใช้ระเบียบวิธี Agile เพื่อปรับปรุงประสิทธิภาพของพนักงาน

มาเรีย โอนูชินะ,

ผู้อำนวยการฝ่ายบริหารสินทรัพย์ กลุ่มบริหารสินทรัพย์เบคาร์ กรุงมอสโก

เราได้ปรับเปลี่ยนพื้นที่สำนักงานของเราเพื่อย้ายไปสู่การจัดการแบบ Agile:

ขั้นที่ 1การจัดสถานที่ทำงาน

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

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

เราพยายามจัดพื้นที่ในสำนักงานเพื่อให้พนักงานมีโอกาสเปลี่ยนสถานที่ได้ตลอดเวลา:

• หากจำเป็น ให้อยู่คนเดียว
• เข้าร่วมเป็นกลุ่มย่อย
• จัดประชุมระหว่างหน่วยงานในเรื่องใดเรื่องหนึ่ง

จำนวนโซนดังกล่าวภายในโครงการได้รับอิทธิพลจากส่วนแบ่งของธุรกิจที่กระบวนการเป็นเจ้าของ

ขั้นที่ 2การปรับตัวของคนงาน

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

ด่าน 3การแนะนำวิธีแก้ปัญหาที่ไม่ธรรมดา

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

ออฟฟิศใหม่ไม่ธรรมดาแต่ก็สะดวกสบาย เราตกแต่งด้วยเฟอร์นิเจอร์หลายระดับ: เก้าอี้บาร์ เก้าอี้บีนแบ็ก โซฟาหนังและผ้า โต๊ะกระจก การจัดการแบบ Agile มีรายละเอียดดังนี้

• โซลูชั่นทางวิศวกรรมสมัยใหม่
• โครงสร้างพื้นฐานด้านไอที
• เฟอร์นิเจอร์ที่สะดวกสบาย
• พื้นที่สำหรับบันทึกแนวคิดระหว่างการเจรจา ฯลฯ

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

ผลลัพธ์- การเข้าพักในสำนักงานที่ได้รับการปรับปรุงเป็นเวลาหลายเดือนแสดงให้เห็นว่างานกลายเป็นทีม และการสื่อสารระหว่างผู้เชี่ยวชาญจากแผนกต่างๆ ก็ดีขึ้น จัดการเพื่อประหยัดค่าเช่า โดยเฉลี่ยแล้วสำนักงานขององค์กรขนาดใหญ่จะมีพื้นที่ 12-40 ตร.ม. ต่อคน ก่อนหน้านี้ เรามีพื้นที่ 10 ตร.ม. และตัวเลขนี้ลดลงเหลือ 6 ตร.ม. ซึ่งกระจายงานได้อย่างมีประสิทธิภาพ ระยะเวลาคืนทุนสำหรับโครงการคือ 1.5 ปี

เราได้ติดตั้งห้องประชุมทุกห้องพร้อมอินเทอร์เน็ตไร้สาย (Wi-Fi) และการประชุมทางโทรศัพท์ ทำให้ไม่จำเป็นต้องเช่าห้องประชุมเพื่อจัดการประชุมภายนอก สภาพที่สะดวกสบายดึงดูดพนักงาน ดังนั้นพวกเขาจึงใช้เวลาในการทำงานมากขึ้นและปฏิบัติหน้าที่ได้อย่างมีประสิทธิภาพมากขึ้น

ปัญหาที่อาจเกิดขึ้นเมื่อใช้วิธีการแบบ Agile

ปัญหาที่ 1.เริ่มคุ้นเคยกับบทบาท

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

ปัญหาที่ 2.นิสัยของเอกสาร

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

ปัญหา 3.ทีมใหม่.

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

ปัญหาที่ 4.ปัญหาการสื่อสาร

หน้าที่ของผู้จัดการโครงการคือ ระยะเริ่มแรก– จัดการประชุมกับสมาชิกในทีมเพื่อให้บรรลุกิจกรรมที่มีประสิทธิผลและมีประสิทธิภาพ

ปัญหาที่ 5.แรงกดดันกำหนดเวลา

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

ปัญหาที่ 6.ความคิดสร้างสรรค์

งานโครงการอาจเป็นทั้งที่น่าสนใจและไม่น่าสนใจนัก นักพัฒนามักจะพอใจกับการตัดสินใจที่เป็นอันตรายต่อโครงการแต่ก็มีความน่าสนใจในทางเทคนิค ที่นี่ควรค่าแก่การจดจำหลักการของ KISS (ทำให้มันเรียบง่าย โง่เขลา) และ YAGNI (คุณไม่จำเป็นต้องใช้มัน) ให้ลักษณะสำคัญของโซลูชันการออกแบบมีความเรียบง่าย คุณไม่ควรทำอะไรที่ไม่จำเป็นอย่างยิ่งในขณะนี้

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

ปัญหาที่ 7.การประมาณเวลา

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

ปัญหาที่ 8.ปัญหากับการจัดการ

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

ปัญหาที่ 9.ปัญหาพฤติกรรมไม่ประสานกัน

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

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

วิธีการแบบ Agile โดยไม่มีข้อผิดพลาด

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

เราต้องการความเข้าใจที่ถูกต้องเกี่ยวกับผลลัพธ์ที่เราสนใจ กำหนดเวลาและงบประมาณที่เรามี เป้าหมายที่คลุมเครือและรูปแบบที่สวยงาม เช่น “มาเป็นที่หนึ่งในวงการของคุณ” หรือ “เริ่มทำงานอย่างมีประสิทธิภาพมากขึ้น” นั้นไม่เหมาะสม ให้งานแสดงเป็นตัวเลข ตัวอย่างเช่น: “บรรลุมูลค่าการซื้อขาย 3 พันล้านดอลลาร์ในปี 2561”, “ลดเวลาในการสร้างผลิตภัณฑ์ลงเหลือ 3 เดือน” เป็นต้น

ข้อผิดพลาด 2การวินิจฉัยที่ไม่ถูกต้อง

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

ข้อผิดพลาด 3การแนะนำ Agile ในพื้นที่แยกต่างหากของกระบวนการทางธุรกิจเท่านั้น

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

ข้อผิดพลาด 4เข้าใจถึงความสำคัญของการมีส่วนร่วมของพนักงานบริษัททุกคน

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

ข้อผิดพลาด 5ภาพลวงตาว่าทุกสิ่งเป็นไปได้ด้วยความพยายามของมนุษย์เท่านั้น

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

ข้อผิดพลาด 6ไม่เต็มใจที่จะเปลี่ยนบุคลากร

เกือบ 90% ของความสำเร็จขึ้นอยู่กับทีมงานขององค์กร ควรให้ความสนใจอย่างต่อเนื่องต่อการพัฒนา การฝึกอบรม และแรงจูงใจที่เหมาะสมของพนักงาน ผู้เชี่ยวชาญจำนวนมากไม่พร้อมที่จะดำเนินกิจกรรมโดยใช้วิธี Agile พวกเขาไม่สนใจความรู้และโอกาสใหม่ๆ หรือการเรียนรู้กระบวนการทางธุรกิจ บุคลากรระดับองค์กรประมาณ 25-30% ไม่ต้องการที่จะทุ่มเทอย่างเต็มที่และมุ่งมั่นเพื่อสิ่งนั้น รายได้สูง- เป็นการดีกว่าที่จะกล่าว "ลาก่อน" กับพนักงานดังกล่าว ลิงก์ที่อ่อนแออาจระบุได้ยาก ดังนั้นผู้จัดการฝ่ายทรัพยากรบุคคลจึงมักไม่จัดการกับเรื่องนี้

ข้อผิดพลาด 7การสูญเสียความสนใจและการมีส่วนร่วมของผู้จัดการระดับสูง

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

วิธีการแบบ Agile: ตัวอย่างการใช้งานที่ไม่สำเร็จ

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

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

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

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

ความคิดเห็นของผู้เชี่ยวชาญ

ตัวอย่างการนำไปปฏิบัติที่ประสบความสำเร็จ กการจัดการแบบไจล์

เซอร์เกย์ บูชิค,

ผู้จัดการทั่วไปกลุ่ม NPM, โนโวซีบีสค์

บริษัทรวมทั้งทุกแผนกเปลี่ยนมาทำงานตามระเบียบวิธีแบบ Agile ตลอดระยะเวลา 1.5 ปี ก่อนหน้านี้ แผนกทรัพยากรบุคคลประกอบด้วย: ผู้เชี่ยวชาญด้านทรัพยากรบุคคล ผู้จัดการฝึกอบรม และผู้สรรหาบุคลากร การบริหารแผนกการเลือกสรร พนักงานใหม่หรือขณะจัดอบรมให้กรอกใบสมัครใน จำนวนมาก- ขณะนี้แต่ละแผนกขององค์กรมีทรัพยากรบุคคลของตนเอง ในทีมพัฒนาที่ทำงานตามวิธี Scrum สถานที่นี้ถูกกำหนดให้กับ Scrum Master ผลิตภัณฑ์ที่นี่คือการบริการบุคลากรและสมาชิกในทีมเป็นผู้บริโภคภายใน

รูปแบบการจัดการใหม่ที่ใช้ระเบียบวิธีแบบ Agile มีรากฐานมาจากการคัดเลือกพนักงาน ลูกค้าสามารถวางแผนกิจกรรมโดยคำนึงถึงการออกจากผู้สมัครตามเวลาที่กำหนด ตลอดระยะเวลา 9 รอบระยะเวลา 2 สัปดาห์ เราสามารถลดจำนวนตำแหน่งงานว่างที่เกินกำหนดได้ 2 เท่า ขณะนี้ตำแหน่งงานธรรมดา (เช่น พนักงานโรงหล่อ) จะถูกเติมเต็มใน 20 วัน ตำแหน่งงานโดยเฉลี่ย (สำหรับวิศวกรบริการ) - 32 วัน และตำแหน่งผู้เชี่ยวชาญที่หายาก (วิศวกรกระบวนการฉีดขึ้นรูปพลาสติก) - ใน 51 วัน เมื่อเสร็จสิ้นการวิ่งครั้งแรก ผู้สรรหาก็ชัดเจน: สำหรับการจัดการแผนก สิ่งสำคัญไม่ใช่ความเร็วในการค้นหา แต่เป็นกำหนดเวลาที่โปร่งใสในการเติมตำแหน่งงานว่างและระยะเวลาที่พวกเขาสามารถใช้ในการเลือกพนักงานด้วยการฝึกอบรมที่ตามมา . ในขณะนี้ ผู้จัดการกำลังแจ้งให้ลูกค้าทราบเกี่ยวกับเวลาและขั้นตอนการค้นหาผู้สมัคร ความรับผิดชอบของผู้สรรหายังรวมถึงการพัฒนาความสามารถทางเทคนิคที่จำเป็นในการสรรหางานด้านการผลิตอย่างมีประสิทธิภาพ เช่น การเรียนรู้การอ่านพิมพ์เขียว

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

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

วิธีการจัดการโครงการแบบ Agile: กฎประสิทธิภาพ 6 ข้อ

กฎข้อที่ 1 ทำงานในแผนโครงการและตอบคำถามต่อไปนี้: งานใดที่สำคัญที่สุดในการทำให้สำเร็จ, ทรัพยากรใดที่จำเป็นสำหรับสิ่งนี้, กรอบเวลาใดที่จัดสรรเพื่อให้บรรลุผล?

แผนระยะยาวมีความแม่นยำต่ำ ดังนั้นควรวางแผนเป็นสามมิติ:

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

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

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

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

กฎข้อที่ 5กล่าว “ลา” กับพนักงานที่มีประสิทธิภาพต่ำกว่า หากคุณเห็นว่าวิธีการแบบ Agile นั้นไม่ใกล้เคียงกับพวกเขา

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

1. แอนดรูว์ สเตลแมน, เจนนิเฟอร์ กรีน "ทำความเข้าใจ Agile"

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

หนังสือเล่มนี้เผยให้เห็นสาระสำคัญของระเบียบวิธี Agile ที่ได้รับความนิยมมากที่สุด: Scrum, XP (การเขียนโปรแกรมขั้นสูง), Lean (การเขียนโปรแกรมแบบ Lean) และ Kanban; บอกวิธีใช้เพื่อสร้างโปรแกรมที่มีคุณภาพและบรรลุเป้าหมายของคุณ คู่มือนี้จะอธิบายว่าระเบียบวิธีแบบ Agile ช่วยเปลี่ยนความคิดของผู้เข้าร่วมโครงการ รวมเป็นหนึ่งเดียวกัน และมุ่งมั่นในการปรับปรุงร่วมกันได้อย่างไร วัตถุประสงค์ของการตีพิมพ์คือการพูดคุยเกี่ยวกับวิธีการ ค่านิยม และหลักการของ Agile ซึ่งต้องขอบคุณทีมที่สามารถเปลี่ยนกลยุทธ์ในการทำงานในโครงการและแนวทางที่แตกต่างออกไปได้อย่างสมบูรณ์ คู่มือนี้จะเป็นประโยชน์สำหรับผู้จัดการโครงการ ผู้บริหาร และสำหรับผู้ที่สนใจเกี่ยวกับวิธีการพัฒนาแบบ Agile ที่ยืดหยุ่น

2. Boris Volfson "โครงการ Agile และการจัดการผลิตภัณฑ์"

หนังสือเล่มนี้ผสมผสานทฤษฎีและการปฏิบัติ โดยจะอธิบายแง่มุมต่างๆ ของแนวคิดเกี่ยวกับระเบียบวิธีแบบ Agile การพัฒนาผลิตภัณฑ์ การจัดการ และการวิเคราะห์ ส่วนทางทฤษฎีเกี่ยวกับการจัดการโครงการและผลิตภัณฑ์ประกอบด้วยข้อมูลเกี่ยวกับสถานะปัจจุบันของ Scrum และ Kanban ส่วนที่ใช้งานได้จริงพูดถึงการจัดการข้อกำหนด ทีม ความเสี่ยง การสร้างแบบจำลองธุรกิจ การวิเคราะห์ความต้องการ การประมาณเวลา แนวปฏิบัติทางวิศวกรรมสำหรับการพัฒนาผลิตภัณฑ์ (ส่วนใหญ่เกี่ยวกับการเขียนโปรแกรมขั้นสูง) การควบคุมคุณภาพและการรับประกัน การใช้งานและการปรับขนาดของ Scrum

3. เจฟฟ์ ซูเธอร์แลนด์ สครัม วิธีการปฏิวัติการจัดการโครงการ"

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

Scrum มีมานานกว่า 20 ปีแล้ว และในช่วงเวลานี้ วิธีการดังกล่าวประสบความสำเร็จไม่เพียงแต่โดยนักพัฒนาซอฟต์แวร์เท่านั้น แต่ยังรวมถึงผู้ผลิตรถยนต์ เภสัชกร FBI และ คนธรรมดาการวางแผนเวลาและโอกาสของพวกเขา

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

4. Roman Pichler “การจัดการผลิตภัณฑ์ใน Scrum”

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

5. เคนเนธ เอส. รูบิน "พื้นฐานการต่อสู้"

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

ข้อมูลเกี่ยวกับผู้เชี่ยวชาญ

อันเดรย์ โคเชชคอฟ, หัวหน้านักวิเคราะห์ของสำนักพิมพ์ OJSC Prosveshcheniye "Prosveshchenie" เป็นสำนักพิมพ์เฉพาะด้านด้านการศึกษาและการสอนของโซเวียตและต่อมาในรัสเซีย

มาเรีย โอนูชินะผู้อำนวยการฝ่ายบริหารสิ่งอำนวยความสะดวกของกลุ่มบริหารสินทรัพย์ Becar กรุงมอสโก Becar-Exploitation LLC (กลุ่มบริหารสินทรัพย์ Becar) ขอบเขตของกิจกรรม: การแก้ปัญหาอย่างเป็นระบบของการจัดการอสังหาริมทรัพย์ การบริหารโครงการ และการลงทุน (นายหน้า การประเมินมูลค่า) จำนวนพนักงาน: 5,000 คน อาณาเขต: แผนกต้อนรับ - ในมอสโกและเซนต์ปีเตอร์สเบิร์ก; สำนักงานตัวแทน 3 แห่ง และ 55 แยกแผนก– ในเมืองต่าง ๆ ของรัสเซีย

เซอร์เกย์ บูชิคผู้อำนวยการทั่วไปของกลุ่ม NPM โนโวซีบีสค์ NPM LLC (กลุ่ม NPM) สาขากิจกรรม: การผลิตอุปกรณ์สำหรับอุตสาหกรรมเครื่องดื่ม การพัฒนาโซลูชั่นไอทีเพื่อบูรณาการกับอุปกรณ์ แอปพลิเคชันมือถือ- จำนวนพนักงาน: มากกว่า 300 คน ส่วนแบ่งการตลาด: 95% ของอุปกรณ์สำหรับบรรจุเบียร์และเครื่องดื่มอัดลมในรัสเซีย จำนวนสิทธิบัตรต่อ สินค้าของตัวเอง: มากกว่า 80.