Beyond Sprint 0: ทางเลือกในการบูรณาการทีม

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

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

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

คำจำกัดความสั้นๆ สองสามข้อก่อนที่เราจะเริ่มต้น:

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

ทำไม Sprint 0 และ Design Sprint จึงมีอยู่

เป็นเรื่องที่ดีและดีที่จะพูดว่า "Sprint 0 ไม่ใช่ sprint ที่แท้จริง อย่าทำอย่างนั้น" แต่การดัดแปลงแบบ sprint-ish เหล่านี้มีอยู่ด้วยเหตุผล หลายทีมนำพวกเขาไปใช้เนื่องจากโครงการของพวกเขามีความต้องการที่ไม่ได้รับการตอบสนองซึ่งอยู่นอกเหนือขอบเขตของ Scrum การสังเกตของฉันคือ Sprint 0 และ Design sprints มักใช้เพื่อจัดการกับสถานการณ์ต่อไปนี้:

1. ขาดวิสัยทัศน์ที่ชัดเจน
2. ขาดการบูรณาการการออกแบบเข้ากับขั้นตอนการพัฒนา

กระบวนการ Scrum ถือว่าวิสัยทัศน์ที่ชัดเจนได้รับการพัฒนาและสื่อสารโดยเจ้าของผลิตภัณฑ์ แต่ยกมือขึ้นหากคุณเคยทำงานในโครงการที่มีวิสัยทัศน์อ่อนแอ ผิดพลาด หรือมองไม่เห็น ฉันด้วย! Sprint 0 เป็นความพยายามของทีมพัฒนาเพื่อเติมเต็มช่องว่างด้านการมองเห็น ไม่ใช่ความคิดที่แย่ที่สุด แล้วปัญหาคืออะไร? จากมุมมองที่คล่องตัว Sprint 0 จะไม่ทำซ้ำ ไม่ใช้ความสามารถของทั้งทีม และให้ผลลัพธ์ที่คลุมเครือ และก่อนที่คุณจะชี้ให้เห็นว่า “นี่ ปัญหาจริงๆ ของที่นี่คือทีม scrum ไม่ควรจะต้องทำงานของเจ้าของผลิตภัณฑ์” จริงๆ แล้ว ผมเชื่อว่าทีม Agile แบบข้ามสายงานเป็นหนึ่งในสภาพแวดล้อมที่ดีที่สุดในการพัฒนาให้แข็งแกร่งและสมจริง วิสัยทัศน์และเป้าหมาย

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

วิสัยทัศน์และต้นแบบ Sprint

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

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

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

ทางเลือกที่ดีกว่าคือการวิ่งแบบต้นแบบ: การวิ่งครั้งแรกที่มีส่วนร่วมกับทั้งทีมในขณะที่สร้างต้นแบบเริ่มต้นขึ้นมาเอง

กระบวนการต้นแบบ Sprint Vision

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

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

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

ตัวอย่าง

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

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

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

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

ปัญหาอื่นๆ สองสามข้อปรากฏขึ้นอย่างรวดเร็วในระหว่างการวิ่งต้นแบบนี้:

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

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

การออกแบบและต้นแบบ Sprint

ในสถานการณ์ที่สอง — การขาดการผสมผสานระหว่างการออกแบบกับการพัฒนา — มักจะเป็นกรณีที่คุณจะเห็นการใช้ "design sprint" ฉันพบว่าทิศทางนี้ต่อต้านการผลิตมากกว่า Sprint 0 ความท้าทายของการบูรณาการการออกแบบเข้ากับกระบวนการพัฒนาที่ซับซ้อนนั้นเป็นเรื่องจริง แต่การออกแบบ sprint เป็นแนวทางในการเอาชนะตนเอง Design Sprint เป็นอุปสรรคสำหรับอาการ — ความท้าทายในการสร้างทีมแบบบูรณาการ — แต่ไม่ได้กล่าวถึงปัญหาพื้นฐาน — ความท้าทายในการทำความเข้าใจและตอบสนองความต้องการของผู้ใช้ การออกแบบแบบ Front-loading ในการวิ่งครั้งเดียวช่วยหลีกเลี่ยงความท้าทายในการผสานรวม แต่ประโยชน์ของกระบวนการออกแบบแบบบูรณาการและแบบเพิ่มส่วนเพิ่มและหน้าต่างที่เปิดขึ้นเพื่อความเข้าใจและการเข้าถึงผู้ใช้นั้นสูญเสียไปโดยสิ้นเชิง

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

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

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

กระบวนการออกแบบต้นแบบ Sprint

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

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

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

ตัวอย่าง

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

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

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

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

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

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

เมื่อใดที่ต้นแบบ Sprint จะเสร็จสมบูรณ์

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

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

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

ปัญหาทั่วไปบางประการที่ต้องระวังในระหว่างการวิ่งต้นแบบ Sprint

ปัญหาทั่วไปบางประการที่ต้องระวังเมื่อใช้งานต้นแบบ sprint ได้แก่:

• ยอมรับคุณค่าของความเที่ยงตรงต่ำ และหลีกเลี่ยงการเน้นที่ภาพ ระมัดระวังในประเด็นนี้เนื่องจากทีมที่ยังใหม่ต่อแนวทางนี้อาจต้องการความช่วยเหลือและความมั่นใจเมื่อพวกเขาก้าวไปไกลกว่า "โลโก้อยู่ที่ไหน" และให้ความสำคัญกับคำถามที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับการทำงานและลำดับชั้น
• แง่มุมที่ต่างออกไปจากด้านบน ให้ระมัดระวังในการไม่ยึดติด กับแนวคิดการออกแบบ/เลย์เอาต์ของคุณเอง จำไว้ระหว่างการวิ่งต้นแบบว่าไม่มีอะไรมีค่าถูกสร้างขึ้นและยังคงแยกออกจากผลลัพธ์สุดท้าย นอกจากนี้ยังเป็นอีกเหตุผลหนึ่งที่ทำให้ต้นแบบมีความเรียบง่ายและค่อนข้างน่าเกลียด มีจุดประสงค์เพื่อแยกผู้ใช้ออกจากกัน
• กระบวนการซื้อจากความเป็นผู้นำในช่วงต้นเป็นสิ่งสำคัญ เนื่องจากทีมงานทั้งหมดเกี่ยวข้องกับลูกค้าของคุณ เจ้านายของคุณ และนักพัฒนาทั้งหมดจำเป็นต้องสนับสนุนและดูแลกระบวนการด้วยการมีส่วนร่วม ความคิดสร้างสรรค์ และเวลา อย่าเป็นเชียร์ลีดเดอร์คนเดียว ทั้งทีมของคุณต้องโบกปอมปอม!
• การสื่อสารที่ไม่ดีเป็นจุดอ่อนของการทำงานเป็นทีมทั้งหมด การวิ่งแบบต้นแบบไม่สามารถแก้ปัญหาด้านการสื่อสารที่คงอยู่ได้ แต่จะนำปัญหาเหล่านั้นมาสู่จุดเดิมได้เร็วกว่าเมื่อทั้งทีมดำดิ่งสู่เวิร์กโฟลว์การทำงานร่วมกันเกือบจะในทันที ปัญหาด้านการสื่อสารที่มีอยู่แล้วจะเกิดขึ้นเร็วและมักเกิดขึ้นในช่วงต้นแบบในขณะที่คุณทำงานเพื่อบรรลุฉันทามติและส่วนที่เพิ่มขึ้นครั้งแรกของคุณ เปิดรับโอกาสในการปรับปรุงการสื่อสารและมีส่วนร่วมกับทั้งทีมในการหาแนวทางแก้ไข
• เลือก front-end framework ที่ เหมาะสม หากคุณยังไม่มี คุณอาจต้องลองใช้เฟรมเวิร์กส่วนหน้าต่างๆ ก่อนที่คุณจะพบเฟรมเวิร์กที่คลิกกับเวิร์กโฟลว์ของทีมคุณ ฉันแนะนำให้มองหาเฟรมเวิร์กขั้นต่ำเช่น Fomantic หรือ Bulma และไม่จมอยู่กับเสียงระฆังและเสียงนกหวีด อย่างไรก็ตาม กรอบงานที่เหมาะสมมักเป็นกรอบงานที่เหมาะกับทีมของคุณ
• ทีม UI/UX จำเป็นต้อง พัฒนาระดับความสะดวกสบาย และเข้าถึงเฟรมเวิร์กส่วนหน้า ตามหลักการแล้ว พวกเขาจะทำงานกับต้นแบบโดยตรง หลีกเลี่ยงการส่งต่อที่ไม่จำเป็นและความจำเป็นในการแปลจากสื่อหนึ่งไปยังอีกสื่อหนึ่ง (เช่น จาก Sketch ไปยังต้นแบบ) หากทีมส่วนหน้าของคุณไม่มีความคุ้นเคยกับ CSS และ HTML วิธีการจับคู่ (โดยนักออกแบบและโปรแกรมเมอร์หนึ่งคนทำงานร่วมกันในกรอบงาน) ก็ใช้ได้ดีเช่นกัน
• สุดท้ายแต่ไม่ท้ายสุด จำไว้ว่าคุณจะ เป็นทีมที่ดีขึ้นและเร็วขึ้น ! การวิ่งต้นแบบอย่างมีประสิทธิผลเป็นทักษะที่เติบโตไปพร้อมกับการฝึกฝน

จะเกิดอะไรขึ้นต่อไป

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

การวิ่งต้นแบบเป็นการเริ่มต้นที่ดีในกระบวนการต่อสู้ใดๆ แต่ในโครงการของฉัน ขั้นตอนต่อไปของเราคือการย้ายไปยังเวิร์กโฟลว์แบบติดตามคู่ โดยที่ UI/UX ทำงานครึ่งหรือทั้งหมดก่อนการพัฒนา เพื่อค้นหาและอัปเดตต้นแบบเป็นภาพ สะท้อนข้อมูลเชิงลึกใหม่ๆ

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

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

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

หมายเหตุเกี่ยวกับการตั้งค่าหน่วยงาน

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

บทสรุป

Sprint 0 และ Design sprints จัดการกับความท้าทายที่แท้จริงที่ทีม scrum เผชิญอยู่: ขาดวิสัยทัศน์ ขาดการออกแบบแบบบูรณาการ หรือทั้งสองอย่าง เป็นคำตอบที่เข้าใจได้และมีเหตุผล แต่ไม่ได้ให้คุณค่าสูงหรือมีส่วนสนับสนุนทีมที่คล่องตัว

การแทนที่ด้วย Sprint ต้นแบบเป็นวิธีที่ใช้ได้จริงในการแก้ไขข้อบกพร่องของ Sprint 0 และ Design sprints ในขณะเดียวกันก็เป็นการวางรากฐานสำหรับการทำงานร่วมกันที่คล่องตัวยิ่งขึ้นในระหว่างการวิ่งในอนาคต

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

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag:

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