บทนำขั้นสูงสุดสำหรับการจัดการโครงการแบบ Agile

บทสรุป

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

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

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

จัดฉาก

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

การพัฒนาซอฟต์แวร์แบบ Agile และการจัดการโปรเจ็กต์แบบ Agile เกิดจากความไม่เพียงพอของ Waterfall และประโยชน์ของแนวทางการทำซ้ำเพื่อส่งมอบซอฟต์แวร์ พวกเขาสามารถติดตามรากเหง้าของพวกเขาจนถึงปี 1950 ความเป็นผู้นำทางความคิดในยุค 70 วุฒิภาวะใน 90 และการรับเลี้ยงบุตรบุญธรรมจนถึงยุค 00 ในปี 2544 กลุ่มผู้ปฏิบัติงานและผู้เชี่ยวชาญได้สร้างคำประกาศ Agile โดยมุ่งเป้าไปที่การกำหนดค่า 4 ประการและ 12 หลักการชี้นำที่พยายามรวบรวมจิตวิญญาณของการพัฒนาซอฟต์แวร์ Agile และเพื่อส่งเสริมวิวัฒนาการ และมีวิวัฒนาการอย่างแน่นอน

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

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

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

มีวิธีการพัฒนาซอฟต์แวร์ Agile มากมาย เช่น Scrum, Kanban, XP และ Lean Software Development แต่เช่นเดียวกับเกมรักบี้ที่เป็นมากกว่าการต่อสู้ ความคล่องตัวก็เช่นกัน กระบวนทัศน์แบบ Agile เหล่านี้ไม่ได้กล่าวถึงวงจรชีวิตที่สมบูรณ์ของการจัดการโครงการที่จำเป็นในโครงการที่ซับซ้อน เช่น การกำกับดูแล การจัดหาทรัพยากร การเงิน การจัดการความเสี่ยงอย่างชัดเจน และแนวคิดการจัดการโครงการที่สำคัญอื่นๆ อีกมากมาย สำหรับสิ่งเหล่านี้ คุณอาจต้องการพิจารณา PMI Agile หรือ PRINCE2 Agile—ให้มองว่าเป็น “Governed Agility”

ทำไมเราต้องมีความคล่องตัว?

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

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

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

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

รายการต่อไปนี้แสดงถึงประโยชน์บางประการที่คุณคาดหวังได้:

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

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

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

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

ความเป็นไปได้

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

วิสัยทัศน์

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

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

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

เป็นไปได้หรือไม่?

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

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

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

  “ความรู้ที่ดีที่สุดบางอย่างที่ทีมของฉันได้รับในการทำความเข้าใจความเป็นไปได้ทางเทคนิคนั้นมาจากการพุ่งทะยาน และบ่อยครั้งที่มันเป็นทางออกที่ง่ายที่สุดที่จะชนะ!”

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

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

เหตุผล

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

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

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

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

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

เมื่อคุณมีเหตุผลของคุณและผู้มีส่วนได้ส่วนเสียทั้งหมดของคุณพร้อมแล้ว คุณจะอยู่ในกองไฟ

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

การเริ่มต้น

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

ทีมงาน

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

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

มีหลายวิธีในการรวบรวมทีมเพื่อส่งมอบซอฟต์แวร์

สรุปโครงการ

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

• เครื่องมือที่ยอดเยี่ยมสำหรับการห่อหุ้มและดูแลบทสรุปโครงการของคุณคือสิ่งที่ Jonathan Rasmusson เรียกว่า "inception deck" ในหนังสือของเขา The Agile Samurai ที่นี่ คุณจะพบคำแนะนำที่ดีเพื่อให้แน่ใจว่าทุกคนที่สนใจ ได้รับผลกระทบ หรือเกี่ยวข้องกับโครงการของคุณมีความเข้าใจตรงกัน
• ศัตรูที่ยิ่งใหญ่ที่สุดในการดำเนินโครงการคือการมีความเข้าใจที่ไม่ชัดเจน ไม่สอดคล้องกัน หรือแตกต่างกันอย่างชัดเจนว่าโครงการคืออะไร และ "ข้อกำหนด" ใดที่ต้องได้รับการตอบสนอง หากผู้มีส่วนได้ส่วนเสียที่สำคัญแม้แต่คนเดียวมีความเข้าใจหรือมุมมองที่แตกต่างกันเกี่ยวกับสิ่งที่คุณกำลังทำอยู่ ผลที่ตามมาก็อาจมีมากมาย
• สรุปโครงการที่ดีสื่อสาร:
  1. ความคาดหวังร่วมกันและตกลงกันระหว่างผู้มีส่วนได้ส่วนเสียและสมาชิกในทีม
  2. ความเข้าใจในโครงการด้วยความเข้าใจเดียวกันในทุกฝ่าย
  3. เป้าหมาย วิสัยทัศน์ วัตถุประสงค์ ขอบเขต และบริบทของโครงการ
• คุณจะมีข้อมูลดีๆ มากมายสำหรับบทสรุปที่รวบรวมได้จากความเป็นไปได้ สรุปโครงการจะช่วยคุณกำหนดและค้นหาคำตอบสำหรับคำถามค้นหา มันจะรวบรวมผู้มีส่วนได้ส่วนเสีย เหตุผล ของคุณ ขอบเขตระดับสูง ความเสี่ยง โซลูชันเป้าหมาย งบประมาณ ไทม์ไลน์ ความคาดหวัง และลำดับความสำคัญเข้าด้วยกัน

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

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

วัฒนธรรมและวิธีการทำงาน

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

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

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

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

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

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

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

Backlog

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

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

สิ่งที่จำเป็นหรือต้องการ หรือสิ่งที่บังคับ เงื่อนไขที่จำเป็น

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

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

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

การประมาณค่าและการจัดลำดับความสำคัญระดับสูง

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

• เรื่องราวที่อยู่ด้านบนถือว่ามีค่ามากที่สุด เราต้องการส่งมอบสิ่งของที่มีค่าที่สุดให้เร็วที่สุด
• มีเทคนิคมากมายในการปรับขนาดและการประมาณค่า แต่ ณ จุดนี้ คุณแค่ต้องการทราบความรู้สึกที่ดีเกี่ยวกับขนาดของเรื่องราว
  • ใช้ขนาดเสื้อยืด ขนาดสัมพันธ์ วันที่ในอุดมคติ หรือประเด็นเรื่อง
• คุณจะไม่มีข้อมูลทั้งหมดในตอนนี้ และก็ไม่เป็นไร แค่วิ่งไปกับมัน
• มีส่วนร่วมกับผู้มีส่วนได้ส่วนเสียทางธุรกิจหรือผู้จัดการผลิตภัณฑ์ หากคุณมี และทีมที่จะทำงาน
• เราต้องการผู้ที่จะออกแบบ พัฒนา และทดสอบงานเพื่อกำหนดขนาด เพราะคนที่ประเมินได้ดีที่สุดคือผู้เชี่ยวชาญ
• ทีมงานอาจเริ่มแบ่งเรื่องราวออกเป็นส่วนย่อยๆ หากเกิดเหตุการณ์นี้ขึ้น ให้เขียนเรื่องราวที่ละเอียดยิ่งขึ้นแต่ไม่ต่อเนื่องกัน
• ทีมงานอาจเริ่มจัดอันดับเรื่องราวบางเรื่อง เนื่องจากบางอย่างต้องได้รับการส่งมอบก่อนคนอื่น ๆ เพื่อสนับสนุนเทคโนโลยีหรือเส้นทางของผู้ใช้ที่กำหนด
• ระหว่างคุณและทีม คุณอาจเริ่มพบช่องว่างใน Backlog ที่ต้องเติมเต็ม เพียงเติมเรื่องราวใหม่ๆ ลงในช่องเหล่านั้น ประเมินและจัดลำดับความสำคัญตามความเหมาะสม
• การจัดลำดับความสำคัญทำได้ง่ายที่สุดโดยใช้การวิเคราะห์ MoSCoW MoSCoW เป็นเทคนิคง่ายๆ ที่ช่วยให้คุณตัดสินใจว่าเรื่องราวใด "ต้องมี" เพื่อให้ผลิตภัณฑ์ของคุณประสบความสำเร็จ
• คุณอาจผ่านการจัดลำดับความสำคัญก่อนที่การประมาณจะเริ่มขึ้น อย่างไรก็ตาม ขนาดขององค์ประกอบบางอย่างอาจเป็นตัวกำหนดการตัดสินใจเกี่ยวกับลำดับความสำคัญและมูลค่าทางธุรกิจที่แท้จริง ดังนั้น ให้ลองประมาณและจัดลำดับความสำคัญของกันและกัน แต่อย่าทะเลาะกัน!
• ไม่มีสองเรื่องใดจะมีความสำคัญเท่าอีกเรื่องหนึ่ง เรื่องที่ 1 สำคัญหรือมีค่ากว่าเรื่องที่ 2
• วิธีที่ยอดเยี่ยมในการแสดงความสำคัญหรือคุณค่าของเรื่องราวคือการเพิ่มมูลค่าทางการเงินให้กับเรื่องราว ตัวอย่างเช่น หากเรื่องราว A คิดว่าจะสร้างรายได้เสริม 5,000 ดอลลาร์ และเรื่องราว B อาจดึงดูดเงินได้ 100 ดอลลาร์ เรื่องราว A นั้นมีค่ามากกว่า เช่นเดียวกัน หากเรื่องราว C ช่วยธุรกิจมากกว่าเรื่องราว D เรื่องราว C ก็มีค่ามากกว่า
• เมื่อคุณกำหนดขนาดงานในมือแล้ว คุณจะเหลือตัวเลข When we come to release planning, that number will help us understand how much can be delivered by our team within a given timeframe.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• การทำงานทีละน้อยได้ประโยชน์มหาศาล หมายความว่าคุณมุ่งความสนใจไปที่การส่งมอบในอนาคตอันใกล้เท่านั้น และด้วยข้อมูลใหม่ คำติชม และการเรียนรู้ คุณจะสามารถตอบสนองต่อการเปลี่ยนแปลงได้ภายในวงจรการทำซ้ำสั้นๆ
• ในช่วงเริ่มต้นของการเปิดตัว ให้ดำเนินการ sprint 0 ซึ่งจะทำให้ทีม ธุรกิจ และการเปิดตัวโครงการของคุณได้รับการเตรียมพร้อมและกำหนดกรอบความคิดสำหรับการส่งมอบที่ประสบความสำเร็จ วาดกรอบทางเทคนิคและสถาปัตยกรรมพื้นฐานที่จะสนับสนุนพื้นฐานสำหรับการเปิดตัว ตั้งค่าสภาพแวดล้อม บัญชี และเครื่องมือ ดำเนินการแหลมเพื่อทำความเข้าใจปัญหาที่ยากหรือไม่ทราบ อธิบายเรื่องราวของผู้ใช้อย่างละเอียดเพื่อเตรียมพร้อมสำหรับการวิ่ง 1 Sprint 0 คือการเตรียมการ
• ระหว่างการเปิดตัว ให้ปรับปรุงงานในมือต่อไป เมื่อคุณเข้าใจมากขึ้นหรือเรียนรู้สิ่งใหม่ ลำดับความสำคัญของคุณอาจเปลี่ยนไป ข้อกำหนดใหม่อาจเกิดขึ้น และสิ่งที่คุณเคยคิดว่าเป็นคุณลักษณะที่ยอดเยี่ยมอาจถูกลบออกทั้งหมด
• อย่าเริ่มทำงานที่ไม่มีโอกาสสำเร็จภายในระยะเวลาอันรวดเร็ว ถ้าทำไม่ได้ ให้หั่นเป็นชิ้นเล็กๆ และอย่าเริ่มงานใหม่เมื่องานที่เริ่มก่อนหน้านี้ยังไม่แล้วเสร็จ คุณไม่สร้างคุณค่าโดยเริ่มต้นหลายสิ่งหลายอย่างที่ไม่ถือว่าสมบูรณ์ นอกจากนี้ ให้หลีกเลี่ยงการสลับบริบท นี่คือกิจกรรมของการเริ่มงานหนึ่ง การถูกรบกวน การเริ่มงานอื่น และที่มีปัญหามากที่สุด ไม่สำเร็จอย่างใดอย่างหนึ่ง
• จำกัดจำนวนงานที่ทีมงานดำเนินการในแต่ละครั้ง ตัวอย่างเช่น หากคุณมีนักพัฒนาสามคนและผู้ทดสอบหนึ่งคน คุณอาจกำหนดขีดจำกัด WIP ให้กับนักพัฒนาและผู้ทดสอบ
• อย่าเพิ่มงานในการวิ่งหลังจากที่มีการวางแผนแล้ว อย่าหยุดวิ่งระหว่างทาง ข้อยกเว้นคือ:
  • หากคุณดำเนินการได้เร็วกว่าที่คาดไว้ ให้พิจารณานำเรื่องต่อไปจากยอดค้างที่ค้างอยู่ ตราบใดที่มีการจัดเตรียมอย่างเหมาะสม
  • ถ้าวิ่งได้ไม่ดีจนวิ่งไม่ครบ ซึ่งมักจะเกิดขึ้นเฉพาะเมื่อเกิดภัยพิบัติขึ้นจากคำอธิบายบางอย่างเท่านั้น
  • หากไม่สามารถรองรับวัตถุประสงค์การวิ่งได้อีกต่อไปเนื่องจากความต้องการที่เปลี่ยนแปลงไปของธุรกิจในทันที
• หากคุณยกเลิกการวิ่ง ให้ทำอย่างสง่างาม ใช้เวลาในการโฟกัสใหม่ และเริ่มการวิ่งใหม่เหมือนที่ทำอย่างอื่น
• เมื่อถึงจุดสิ้นสุดของการปล่อย ให้พิจารณาการวิ่งขั้นสุดท้าย ไม่มีการเขียนคุณลักษณะใหม่ สามารถล้างข้อบกพร่องบางอย่างได้ และเตรียมการเพื่อเผยแพร่ผลิตภัณฑ์เวอร์ชันใหม่ให้กับลูกค้าของคุณได้จริง ไม่ได้หมายความว่าคุณไม่สามารถเผยแพร่ลูกค้าแบบเพิ่มจำนวนได้ในระหว่างนี้—เป็นเพียงกลไกการปลดปล่อยที่มีการควบคุม วัดผล และยั่งยืนเท่านั้น
• ในตอนท้ายของการเปิดตัว คุณอาจพิจารณาวิ่งหนึ่งสัปดาห์ ในการวิ่งครั้งนี้ คุณอาจทำงานร่วมกับทีมเพื่อแจกแจงแนวคิดใหม่ๆ หรือคิดหาเทคโนโลยีใหม่ๆ สิ่งเหล่านี้เป็นเครื่องมือที่ยอดเยี่ยมที่เป็นประโยชน์ต่อธุรกิจ และช่วยให้ทีมมีพื้นที่ในการสรุปข้อมูลในการคิดและสร้างสรรค์ ไม่ใช่เพื่อการหลอกลวงและยังคงสร้างมูลค่า ทุกคนต้องการการพักผ่อนอย่างเท่าเทียมกัน การพักร้อนในช่วงเวลานี้ช่วยรักษาจังหวะและความเร็วของคุณให้อยู่ในเกณฑ์ที่ดีเมื่อคุณปล่อยตัวกลางคัน

กำหนดเสร็จสิ้น

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

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

การวัดอย่างต่อเนื่อง

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

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

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

นี่คือเครื่องมืออื่นๆ:

• สแตนด์อัพประจำวัน: พิธีนี้มีรูปแบบต่างๆ เล็กน้อย แต่สิ่งสำคัญคือการให้สมาชิกในทีมพูดคุยกันแบบเห็นหน้ากัน: พูดให้สั้น จดจ่อ และทำให้เป็นประเด็น หากมีสิ่งใดที่จำเป็นต้องพูดคุยกันอย่างยาวไกล ให้พักไว้สำหรับการสนทนาที่ยาวขึ้นระหว่างคนเหล่านั้นที่จำเป็นหลังจากการลุกขึ้นยืน หากมีสิ่งกีดขวาง ให้เขียนราวกับเป็นเรื่องราว เพิ่มเข้าไปใน Backlog ของคุณและแก้ไขปัญหาโดยเร็วที่สุด สิ่งใดก็ตามที่ขัดขวางทีมของคุณจะทำให้ความคืบหน้าช้าลงและจะแสดงให้เห็นได้ในความเร็วที่ลดลงและซอฟต์แวร์ที่ไม่เป็นไปตามความคาดหวัง
• ความเร็ว: เป็นเครื่องมือทางประวัติศาสตร์ คล้ายกับคำเตือนทางการเงินที่คุณได้รับซึ่งระบุว่าประสิทธิภาพในอดีตไม่รับประกันประสิทธิภาพในอนาคต แต่ในกรณีของ Agile เราหวังว่าจะบรรลุความเร็วของทีมที่ราบรื่นเป็นส่วนใหญ่ ความเร็วที่ช่วยให้เราสามารถคาดการณ์ประสิทธิภาพในอนาคตและความมั่นใจในแผนของเราได้ อาจมีอิทธิพลนอกการควบคุมของคุณซึ่งอาจลดจำนวนจุดเรื่องราวสำหรับการวิ่งที่กำหนด หากเกิดเหตุการณ์นี้ขึ้น คุณอาจจะสามารถกู้คืนได้ อย่าใช้ความเร็วเป็นเครื่องมือในการเอาชนะทีมของคุณ มันจะไม่ได้รับความโปรดปรานจากคุณ สิ่งหนึ่งที่แน่นอนคือความเร็วจะไม่แน่นอนสำหรับการวิ่ง 2-4 ครั้งแรก อย่างไรก็ตาม ในช่วงระยะเวลาหนึ่ง คุณควรเริ่มเห็นความสม่ำเสมอและความมั่นคง หากความเร็วของคุณผันผวนจากจุดหนึ่งไปยังอีกจุดหนึ่ง คุณมีปัญหาซึ่งคุณจะต้องแก้ไขกับทีมของคุณ
• แผนภูมิการเผาไหม้: ตอนนี้การวัดความก้าวหน้านี้เป็นสิ่งที่มีหนาม ด้วยเหตุผลดังกล่าว ฉันจึงไม่ได้ให้ลิงก์เพื่อไปหาข้อมูลเพิ่มเติม คุณจะต้องค้นคว้าด้วยตนเองและตกลงกันเป็นทีมและธุรกิจที่เหมาะกับคุณ เหตุผลที่มันมีหนาม? ไม่มีแหล่งข้อมูลใดที่บอกเล่าเรื่องราวเดียวกัน! สิ่งหนึ่งที่ตกลงกันคือมันจะแสดงให้คุณเห็นว่าคุณมีประสิทธิภาพเป็นอย่างไรกับกล่องเวลาของคุณภายในการวิ่งระยะสั้นหรือช่วงปล่อยตัว หากดูแลทุกวัน แสดงว่าคุณกำลังอยู่ในเส้นทางหรือเบี่ยงเบน บางทีมใช้เพื่อแสดงมูลค่าที่เหลืออยู่ที่จะสร้าง บ่อยกว่าไม่ คนอื่นใช้เพื่อแสดงว่างานที่เหลือจะต้องทำให้เสร็จ แบบแรกเป็นการเฉลิมฉลองความสำเร็จและการสร้างคุณค่า ส่วนแบบหลังมีแรงบันดาลใจและแรงจูงใจน้อยกว่า
• แผนภูมิการเบิร์น: หากคุณต้องแสดงอัตราความสำเร็จของงาน ให้ใช้แผนภูมิเบิร์นดาวน์สำหรับสิ่งนั้น แต่การใช้แผนภูมิการเบิร์นอัพทำให้คุณสามารถแสดงมูลค่าที่ถูกสร้างขึ้นและมูลค่าที่คุณวางแผนที่จะสร้างเมื่อสิ้นสุดการวิ่ง เครื่องมือที่จูงใจมากขึ้นสำหรับทีมในการแสดงให้ธุรกิจเห็นถึงสิ่งที่ได้ทำไปแล้ว (หรือเพียงเล็กน้อยหากสิ่งต่างๆ ไปไม่เป็นไปด้วยดี...) และสิ่งที่พวกเขายังคงตั้งเป้าไว้ ไม่ว่าในกรณีใด ให้ใช้แผนภูมิเพื่อระบุจุดที่ความคืบหน้าไม่ได้ติดตามตามที่คาดไว้ และมองหารูปแบบหรือการเบี่ยงเบน และจัดการเพื่อแก้ไขปัญหาพื้นฐานโดยเร็วที่สุด อัปเดตทุกวันสำหรับ sprints และหนึ่งครั้งเมื่อสิ้นสุด sprint สำหรับแผนภูมิเวอร์ชันที่เผยแพร่
• กระดานงาน: เหล่านี้เป็นตัวแสดงภาพที่ยอดเยี่ยมสำหรับการแสดงคุณค่าที่ถูกสร้างขึ้น เมื่ออัพเดททุกวันหรือ ณ จุดใด ๆ ของวัน จะแสดงความคืบหน้าทันที หากใช้ร่วมกับ Kanban ก็ยังเป็นเครื่องมือที่ยอดเยี่ยมสำหรับการแสดงภาพการไหลและการอุดตันในระบบ หากคุณเห็นว่ามีการพัฒนาจำนวนมากเสร็จแล้ว แต่การทดสอบไม่ได้ผล คุณจะสามารถเห็นปัญหาที่เกิดขึ้นและตอบสนองอย่างเหมาะสมและรวดเร็ว

เครื่องมืออื่นๆ ที่ควรพิจารณา ได้แก่ มูลค่าที่ได้รับจาก Agile รอบเวลา และแผนภาพการไหลสะสม (CFD's)

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

พัฒนาอย่างต่อเนื่อง

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

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

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

นอกเหนือจากการจัดการโครงการที่คล่องตัว

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

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

กรอบการกำกับดูแลหรือรูปแบบการกำกับดูแลแบบ Agile ใช้ร่วมกับกระบวนการ Agile มาตรฐาน เช่น Scrum พวกเขาทำงานในสองวิธีเฉพาะ:

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

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

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

เพลิดเพลินไปกับการเดินทาง