เราควรจัดการกับคุณสมบัติพิเศษของเครื่องสำอางใน Scrum sprints อย่างไร

ฉันกำลังอ่านเอกสารการต่อสู้และบอกว่างานใน Sprint ควรเป็น "ที่อาจเป็นไปได้"

ฉันสับสนกับความหมายของสิ่งนี้ สมมติว่าใน Sprint 1 มีเป้าหมายคือ "แบบฟอร์มลงทะเบียนผู้ใช้"

ฉันต้องเพิ่มรายละเอียดมากเท่าใดเพื่อให้พร้อมที่จะส่ง? ตัวอย่างเช่น:

1. ฉันสามารถแสดงฟอร์มที่เรียบง่ายพร้อมฟิลด์โดยไม่ต้องใส่สไตล์แฟนซีใด ๆ และทำเครื่องหมายว่าเสร็จแล้ว
2. ฉันสามารถทำการตรวจสอบฝั่งไคลเอ็นต์เป็นเครื่องหมายว่าทำเสร็จแล้ว แต่ฝั่งเซิร์ฟเวอร์ก็เป็นตัวเลือกหรือทั้งสองอย่าง
3. ฉันยังสามารถเพิ่มเคล็ดลับเครื่องมือแฟนซี jQuery, เลื่อนเมาส์ไปวาง, captcha, สี, ป้ายกำกับสำหรับแบบฟอร์ม
4. จากนั้นมีการจัดแต่งทรงผมมากมายเกี่ยวกับวิธีแสดงข้อความผิดพลาดบนหน้าจอ

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

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

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

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

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

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

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

ตราบใดที่ทีมทุกคนรู้คำตอบมันก็ไม่เกี่ยวข้องกับคำตอบ

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

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

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

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

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

"อาจเป็นไปได้ shippable" หมายถึง shipp- ไม่จำเป็นต้องเป็นสิ่งที่คุณจัดส่ง ตัวอย่างเช่น:

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

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

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

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

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

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

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

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

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

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

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

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