วิธีการวางแผนแบบอไจล์ วิธีการพัฒนาแบบเปรียว

ระบบปฏิบัติการของโรงงานโตโยต้าได้กลายเป็นรูปแบบการจัดการที่คลาสสิกและประสบความสำเร็จไปแล้ว พนักงานแต่ละคนในองค์กรมีโอกาสที่จะหยุดสายพานลำเลียงได้ตลอดเวลาเพื่อขจัดข้อบกพร่อง ปัญหา หรือจัดทำข้อเสนอการหาเหตุผลเข้าข้างตนเองของตนเอง ปรัชญา 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 วิธีการนี้กำหนดวิธีการสร้างซอฟต์แวร์แบบวนซ้ำแบบเพิ่มหน่วย ภายในกรอบของแนวทางที่กล่าวมานั้น วงจรชีวิตการพัฒนา (ขั้นตอนของการเปิดตัว การปรับแต่ง การพัฒนา และการถ่ายโอนไปยังลูกค้า) วิธีการนี้ถูกนำไปใช้ในหลายขั้นตอน โดยตรวจสอบจุดควบคุมบางอย่าง ซึ่งจะช่วยเพิ่มประสิทธิภาพในการควบคุมและติดตามการดำเนินโครงการ การตัดสินใจทั้งหมดเกี่ยวกับโครงการจะต้องตรงเวลา
• การพัฒนาซอฟต์แวร์แบบลีน พื้นฐานของแนวทางนี้คือแนวคิดของการจัดการแบบลีน บริษัท ผู้ผลิต(การผลิตแบบลีน, การผลิตแบบลีน)
• 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 ดึงดูดผู้เชี่ยวชาญจำนวนมาก และจนถึงขณะนี้ มีบริษัทที่มีชื่อเสียงระดับโลกจำนวนหนึ่งได้พยายามนำวิธีนี้ไปใช้ แต่แทบไม่มีใครสามารถบรรลุผลตามที่ต้องการได้

ตัวอย่าง: ในปี 2558 เวลา ตลาดหลักทรัพย์ในนิวยอร์ก มีการซื้อขายกันซึ่งต้องหยุดลงมากถึง 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 "Prosveshcheniye" เป็นสำนักพิมพ์เฉพาะด้านด้านการศึกษาและการสอนของโซเวียตและต่อมาในรัสเซีย

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

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

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

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

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

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

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

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

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

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

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

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

การเปลี่ยนผ่านจากธุรกิจคลาสสิกขนาดใหญ่ (Enterprise) สู่ Agile

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

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

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

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

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

การวางแผนที่ยืดหยุ่น

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

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

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

อ่านเนื้อหา

วันหนึ่ง ผู้จัดการระดับสูงคนหนึ่งเดินทางมาที่โรงงานประกอบรถยนต์ของบริษัทโตโยต้าชื่อดังที่รัสเซีย

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

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

มันเกิดขึ้นดังนี้ ผู้อำนวยการทั่วไปฟังรายงานของหัวหน้าแผนกและจดบันทึกกับตัวเอง

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

มีเรื่องทะเลาะวิวาท ทะเลาะวิวาทกัน ผู้จัดการฝ่ายการตลาดเริ่มโต้เถียงกับผู้จัดการฝ่ายขาย

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

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

ท้ายที่สุดแล้ว ที่โรงงานของเรา พนักงานทุกคนสามารถหยุดสายพานลำเลียงระหว่างการทำงานและทำการปรับเปลี่ยนการทำงานของสายพานลำเลียงได้

ฉันไม่ได้พูดถึงแนวคิดในการวางแผนการประชุมด้วยซ้ำ...” ซึ่งนายพลตอบว่า: "ใช่ นี่ไม่ใช่หลักการแบบ Agile! วิธีการที่ยืดหยุ่นเช่นนี้ใช้ไม่ได้ผลในรัสเซีย!”

คือพวกเขาไม่ได้ทำงาน...

เป็นไปได้มากว่าตอนนี้คำถามกำลังหมุนอยู่ในหัวของคุณ:“ นี่เป็นวลีลึกลับแบบไหน?”

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

โปรแกรมเมอร์จะต้องตำหนิ

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

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

1. ความคิด;
2. งานด้านเทคนิค
3. การสร้างการออกแบบ
4. การเขียนโปรแกรม;
5. การทดสอบ;
6. เปิดตัวรุ่นสุดท้าย

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

ด้วยเหตุนี้ เมื่อสร้างการออกแบบหรือการเขียนโปรแกรม แนวคิดใหม่ๆ จึงต้องถูกละเลย

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

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

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

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

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

เพื่อนำแนวทางการจัดการโครงการทั้งหมด (และเมื่อถึงเวลานั้นก็มีมากกว่าหนึ่งโหลแล้ว) มาสู่ตัวหารร่วมกัน ทีมผู้ก่อตั้งทั้งหมด (17 คน) ผู้พัฒนาและนำ "วิธีการแบบ Agile" ต่างๆ มารวมกัน

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

การพบกันครั้งนี้ที่หมู่บ้านบนภูเขา Snowbird ในเดือนกุมภาพันธ์ พ.ศ. 2544 ถือเป็นการกำเนิดของระเบียบวิธีแบบ Agile (บางคนถึงกับเรียกมันว่าปรัชญา)

เนื่องจากคนเหล่านี้ส่วนใหญ่เป็นโปรแกรมเมอร์ ผลลัพธ์ของการประชุมก็คือการเผยแพร่ “Manifesto of Agile Software Development Methodology” (ในภาษาอังกฤษ Agile Manifesto) และหลักการของ Agile

เนื่องจากความจริงที่ว่าโปรแกรมเมอร์ที่ใช้ปรัชญาและหลักการนี้เริ่มได้รับผลลัพธ์ที่ยอดเยี่ยมมาก องค์กรหลายแห่งจึงเริ่มเปลี่ยนมาใช้แนวทางเหล่านี้

สั้นๆและตรงประเด็น

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

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

หลักการที่กล่าวถึงใน Agile Manifesto อ่านสักนิดก็จะเข้าใจมากขึ้นอีกหน่อย

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

“ ฉันเพิ่งอ่านเรื่องไร้สาระอะไร? ฉันไม่เข้าใจคำศัพท์!” ฉันคิดว่านี่เป็นความคิดของคุณตอนนี้

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

ดังนั้นฉันจะช่วยคุณประหยัดเวลาได้มากและบอกคุณสั้น ๆ และตรงประเด็น

คล่องตัวเป็นชื่อของวิธีการซึ่ง โครงการสำคัญแบ่งออกเป็นส่วนเล็กๆ หลายส่วน โดยแต่ละส่วนจะกำหนดวันที่แล้วเสร็จของตนเอง

แนวทางนี้ทำให้ฉันนึกถึงมาก ยกเว้นสิ่งหนึ่งเท่านั้น การสลายตัวไม่ได้คำนึงถึงการมีส่วนร่วมของทั้งทีม

ทุกอย่างชัดเจนในตัวอย่าง

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

เมื่อต้องการทำเช่นนี้ อันดับแรกฉันจะพูดถึงโรงงานที่ไม่มีระเบียบวิธี และจากนั้นเกี่ยวกับโรงงานที่ใช้วิธีการจัดการนี้ เรามาดูตัวอย่างกันดีกว่า

โรงงานขนมปังธรรมดาในรัสเซีย

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

แต่ตามกฎแล้ว ความคิดดังกล่าวไม่ได้เกิดขึ้นจากความต้องการของผู้บริโภคบนพื้นฐาน วิจัยการตลาดแต่เป็นไปตามความปรารถนาของผู้กำกับเอง

หลังจากการวิจัยแล้ว นักเทคโนโลยีจะพัฒนาขนมปังให้เหมาะกับรสนิยมของคุณแล้วนำไปให้ผู้กำกับ

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

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

นี่เป็นแนวทางทั่วไปในรัสเซีย คนงานเพียงแค่ได้รับคำแนะนำ และการประเมินจะดำเนินการโดยคนเพียงคนเดียว (บางครั้งหลายคน)

โรงงานเบเกอรี่ Agile ในรัสเซีย

CEO เกิดความคิดที่จะพัฒนา ความหลากหลายใหม่ของขนมปัง และนี่คือจุดเริ่มต้นของปาฏิหาริย์

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

จะไม่มีลำดับชั้นเลยในทีมนี้ (ยกเว้น CEO) และผลงานจะไม่ให้รางวัลแก่พนักงานคนใดคนหนึ่งโดยเฉพาะ แต่จะได้รับขนมปังรูปแบบใหม่ที่ลูกค้าจะซื้อ

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

นำไปใช้หรือส่ง

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

ซึ่งส่งผลดีต่อยอดขาย ประหยัดเวลา และป้องกันความผิดพลาดได้มาก

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

แต่นี่เป็นความผิดขั้นพื้นฐาน ในรัสเซียมีการใช้วิธีนี้อย่างแข็งขัน:

• ธนาคารอัลฟ่าธนาคาร;
• เครือร้านพิซซ่า "Dodo Pizza";
• บริการบัญชี “ปุ่ม”

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

ด้วย “Dodo Pizza” และ “Knopka” ทุกอย่างน่าสนใจยิ่งขึ้นมาก เนื่องจากบริษัทมีขนาดเล็ก และในความคิดของฉัน แนวทางนี้เป็นหนึ่งในปัจจัยแห่งความสำเร็จของพวกเขา

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

1. ด้วยการใช้วิธีการ "ยืดหยุ่น" คุณภาพของผลลัพธ์ที่ได้รับจึงเพิ่มขึ้น
2. ผลลัพธ์จะได้เร็วและมีประสิทธิภาพมากขึ้น จึงประหยัดเวลาและต้นทุน
3. บริษัทปรับตัวเข้ากับการเปลี่ยนแปลง (แม้จะไม่คาดฝัน) และการแข่งขันได้ดีขึ้น
4. การสร้างโครงการมีการวางแผนและควบคุมมากขึ้น
5. บริษัทสามารถสร้างผลิตภัณฑ์ที่ผู้บริโภคคาดหวังและซื้อได้

งานภายใน

คำถามเดียวที่ฉันค้นหาคำตอบมานานคือ การทำงานในบริษัทแบบ Agile ทำงานอย่างไร?

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

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

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

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

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

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

ใช่ ตอนนี้ทุกอย่างเรียบร้อยดี

ฉันต้องการมันเพื่อตัวเอง

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

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

จากนั้นฉันจะเตือนคุณทันทีและตอบคำถามหลายข้อที่คุณมี

นี่คือคำถาม 5 อันดับแรกที่เจ้าของทุกคนถามตัวเองเมื่อเห็นวิธีการนี้

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

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

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

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

และนี่หมายถึงการทำงานเป็นทีมโดยเฉพาะและมุมมองที่กว้างขึ้น

ใครควรเป็นเจ้านาย?อาจฟังดูผิดปกติ แต่ไม่มีผู้บังคับบัญชาในบริษัทที่คล่องตัว

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

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

เรามีมากกว่า 29,000 คนแล้ว
เปิด

หินใต้น้ำ

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

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

Agile ไม่ใช่เครื่องมือ

Agile ไม่ใช่ระเบียบวิธีด้วยซ้ำ แม้ว่าฉันมักจะเรียกมันว่าในข้อความก็ตาม นี่คือปรัชญาที่บริษัทตกลงที่จะปฏิบัติตาม

และในการนำปรัชญามาสู่ชีวิต คุณต้องมีกฎเกณฑ์ แม่แบบ และเครื่องมือ พวกมันเรียกว่ากรอบงาน

ซึ่งรวมถึง Scrum (เครื่องมือการจัดการ) แน่นอนว่าเราจะเขียนบทความเกี่ยวกับเครื่องมือแต่ละอย่างในอนาคต แต่คุณต้องเข้าใจว่า ประการแรก Agile คือปรัชญาที่นำมาใช้ในบริษัท

ทีม

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

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

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

จมูกของคนอื่น.

ไม่มีพื้นที่ส่วนตัวในบริษัทอีกต่อไป จากซีรีส์ - ฉันไม่ยุ่งกับคุณและคุณไม่ยุ่งกับฉัน นี่ไม่ใช่กรณีอีกต่อไป

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

นี่เป็นทั้งไม่ดี (ผิดปกติ) และดีเนื่องจากการจ้องมองของคน ๆ หนึ่งมักจะพร่ามัว

การชำระเงิน

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

หากมีเงินเดือนก็มากขึ้นเพื่อให้คนไม่อดอยากตาย ทุกสิ่งทุกอย่างขึ้นอยู่กับผลลัพธ์

มูลค่าการซื้อขาย

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

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

สั้น ๆ เกี่ยวกับสิ่งสำคัญ

วิธีการจัดการโครงการแบบ Agile เหมาะกับใครบ้าง? สำหรับบริษัทขนาดใหญ่หรือบริษัทขนาดเล็ก? ในความเป็นจริงสำหรับทั้งสอง

พวกเขาทำให้บริษัทขนาดใหญ่ “อายุน้อยกว่า” มีความคล่องตัวมากขึ้นและมีระบบราชการน้อยลง ในขณะเดียวกันก็ทำให้บริษัทขนาดเล็กมีความก้าวหน้าอย่างทรงพลัง

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

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

แต่ฉันขอย้ำอีกครั้งโดยมีเงื่อนไขว่าคุณกำลังนำผลิตภัณฑ์หรือโครงการใหม่ไปใช้อย่างต่อเนื่อง

ดูเหมือนว่าความเกี่ยวข้องจะชัดเจน ฉันขอแนะนำให้คุณใช้เส้นทางอื่น อย่าตัดออกจากไหล่

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

หน้าที่ 2 จาก 2

วิธีการจัดการโครงการแบบยืดหยุ่น (Agile)

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

วิธี Agile จะใช้เมื่อมีเงื่อนไขต่อไปนี้:

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

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

สภาพแวดล้อมการจัดการโครงการแบบ Agile

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

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

ส่วนประกอบของวิธี Agile

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

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

ประโยชน์ที่แนะนำของวิธีการจัดการโครงการแบบ Agile

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

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

สามารถใช้วิธีการจัดการโครงการแบบ Agile ได้หรือไม่?

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

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

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

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

ประวัติความเป็นมาของเปรียว

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

ในทศวรรษ 1990 มีการพัฒนาวิธีการพัฒนาซอฟต์แวร์แบบว่องไวจำนวนหนึ่งเพื่อตอบสนองต่อวิธีรุ่นเฮฟวี่เวทที่มีอยู่ทั่วไป ซึ่งรวมถึง: ตั้งแต่ปี 1991 - RAD (การพัฒนาแอปพลิเคชันอย่างรวดเร็ว); ตั้งแต่ปี 1994 - วิธีการพัฒนาระบบแบบไดนามิก (DSDM) ตั้งแต่ปี 1995 - การแย่งชิง; ตั้งแต่ปี 1996 Crystal Clear และ Extreme Programming (XP); และตั้งแต่ปี 1997 - การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะ (FDD) แม้ว่าจะเกิดขึ้นก่อนการเผยแพร่ประกาศการพัฒนาซอฟต์แวร์แบบ Agile แต่ก็เรียกรวมกันว่าวิธีการพัฒนาซอฟต์แวร์แบบ Agile

ในเดือนกุมภาพันธ์ พ.ศ. 2544 นักพัฒนาซอฟต์แวร์ 17 คนพบกันที่รีสอร์ท Snowbird ในรัฐยูทาห์เพื่อหารือเกี่ยวกับวิธีการพัฒนาแบบไลท์เวท พวกเขาช่วยกันเผยแพร่ Manifesto for Agile Software Development

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

Agile Manifesto ประกอบด้วยแนวคิดพื้นฐาน 4 ประการ และหลักการ 12 ประการ วิธีการแบบ Agile แต่ละวิธีใช้แนวคิดเหล่านี้แตกต่างกัน แต่ทั้งหมดอาศัยแนวคิดเหล่านี้ในการจัดการโครงการอย่างมีประสิทธิภาพมากที่สุด

4 แนวคิดที่คล่องตัว

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

หลักการ 12 ประการของความคล่องตัว

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

พื้นฐานของวิธี Agile

พื้นฐานของวิธีการจัดการโครงการแบบ Agile คือองค์ประกอบสำคัญหลายประการ:

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

ดังนั้น การใช้งานวิธี Agile แบบยืดหยุ่นจึงเป็นไปได้ภายใต้เงื่อนไขต่อไปนี้:

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

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

ระบบการจัดการโครงการบนพื้นฐาน Agile

มีหลายวิธีตามแนวคิดของ Agile ซึ่งวิธีที่ได้รับความนิยมมากที่สุดคือ Scrum และ Kanban

สครัม

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

1. การวางแผนปริมาณงานสำหรับการวิ่งหนึ่งครั้ง
2. ประชุมรายวัน 15 นาที เพื่อแก้ไขงานของทีมและสรุปผลระหว่างกาล
3. การสาธิตผลงาน
4. รายการย้อนหลังการวิ่งที่ทบทวนเหตุการณ์ที่ดีและไม่ดีของการวิ่งในอดีต

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

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

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

คัมบัง

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

Kanban มีพื้นฐานมาจากสามหลักการ:

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

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

วิธีการใด ๆ ก็มีข้อดีและข้อเสีย มาดูข้อดีข้อเสียของ Agile กัน

ข้อดี

1. มีความยืดหยุ่นมากกว่าเมื่อเปรียบเทียบกับวิธีการแบบน้ำตก

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

2. มีข้อบกพร่องน้อยลงในผลิตภัณฑ์ขั้นสุดท้าย

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

ข้อบกพร่อง

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

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

2. เอกสารประกอบ

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

3. การประชุมบ่อยครั้ง

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

การดำเนินการ Agile

1. ทางเลือกของวิธีการมีวิธีการแบบ Agile มากมายที่ออกแบบมาสำหรับเงื่อนไขเฉพาะ ขั้นตอนแรกของการทำงานกับ Agile คือการกำหนดเป้าหมายของงาน กำหนดเวลา จำนวนพนักงาน และอื่นๆ อีกมากมาย และเลือกวิธีการจัดการโครงการที่ยืดหยุ่นที่จะตอบสนองความต้องการทั้งหมด
2. การฝึกอบรม.การฝึกอบรมเป็นสิ่งจำเป็นเพื่อให้แน่ใจว่าพนักงานเข้าใจหลักการพื้นฐานของ Agile และรู้วิธีทำงานร่วมกับพวกเขา ในขั้นตอนนี้เองที่มีการระบุข้อผิดพลาดที่อาจลดประสิทธิภาพของ Agile ทีมงานพร้อมรับการเปลี่ยนแปลงหรือยัง? โครงการของบริษัทเหมาะสมกับวิธีการแบบ Agile หรือไม่? โค้ชธุรกิจที่เชี่ยวชาญด้าน Agile มักจะช่วยตอบคำถามเหล่านี้และคำถามอื่นๆ อีกมากมาย เหนือสิ่งอื่นใด รายการการฝึกอบรมและแผนงานจะถูกรวบรวมตามที่ Agile จะถูกนำไปใช้ในบริษัท
3. การสาธิตที่คล่องตัวการทดลองขับแบบ Agile ซึ่งดำเนินการภายใต้การดูแลของผู้เชี่ยวชาญและแสดงการทำงานทุกขั้นตอน อธิบายหน้าที่ของบทบาท ปฏิสัมพันธ์ภายในทีมและระหว่างทีม ฯลฯ
4. การสร้างทีมนอกจากการคัดเลือกพนักงานแล้ว การสร้างทีมยังรวมถึงการกำหนดความรับผิดชอบ การกระจายงาน การสร้างตารางการประชุม เป็นต้น แต่ละวิธีได้รับการออกแบบสำหรับคนจำนวนหนึ่งในทีม
5. การเลือกเครื่องมือที่จำเป็นสำหรับการกระจายงาน การรายงาน การวิเคราะห์ ฯลฯ
6. โครงการแรกกับ Agileในโครงการแรกจะมีข้อผิดพลาด ความไม่สอดคล้องกัน การปฏิเสธเครื่องมือบางอย่าง และการเลือกเครื่องมืออื่นๆ เทคนิคใดๆ จำเป็นต้องมีการปรับเปลี่ยนให้เข้ากับคุณลักษณะของบริษัทที่กำลังดำเนินการอยู่

หากคุณพบข้อผิดพลาด โปรดเน้นข้อความและคลิก Ctrl+ป้อน.