คำถามติดแท็ก scrum

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

12 scrum  communication  product-owner 

ฉันเป็นส่วนหนึ่งของกลุ่มพัฒนา 5 ทีมรวมนักพัฒนาประมาณ 40 คน เรากำลังติดตามวิธีการแย่งชิงกันโดยใช้เวลา 3 สัปดาห์ เรามีการตั้งค่าการรวมระบบอย่างต่อเนื่อง (เจนกินส์) โดยมีขั้นตอนการสร้างใช้เวลาหลายชั่วโมง (เนื่องจากการทดสอบอัตโนมัติที่กว้างขวาง) โดยทั่วไปกระบวนการพัฒนาทำงานได้ดี อย่างไรก็ตามเราสังเกตว่าหลังจากสองสามวันไปสู่การวิ่งใหม่งานสร้างของเรามักจะไม่เสถียรและยังคงสั่นคลอนจนสิ้นสุดการวิ่ง "หยุดทำ" ผลข้างเคียงของสิ่งนี้คือการสร้างขั้นตอนไกลไปป์ไลน์โดยเฉพาะอย่างยิ่ง UI- / การทดสอบทางเว็บจะไม่ถูกดำเนินการเป็นเวลาหลายวัน ดังนั้นข้อผิดพลาดที่แนะนำใหม่มักตรวจพบได้ช้ามากในการวิ่ง การยืนยันแต่ละครั้งจะถูกตรวจสอบกับชุดการทดสอบพื้นฐาน เมื่อตรวจสอบแล้วการเปลี่ยนแปลงจะถูกส่งไปยังต้นแบบหลังจากตรวจสอบโค้ด (Gerrit) การทดสอบหน่วยพื้นฐานทำงานทุก 30 นาทีระยะเวลาน้อยกว่า 10 นาที การทดสอบการรวมจะทำงานทุก 2 ชั่วโมงและระยะเวลา 1 ชั่วโมง UI- / Webtests ทำงานบนการทดสอบการรวมที่ประสบความสำเร็จใช้เวลาหลายชั่วโมง ขึ้นอยู่กับว่าใครเป็นผู้รับผิดชอบในการสร้างความมั่นคงในระหว่างการวิ่ง (ความรับผิดชอบนั้นจะถูกส่งต่อการวิ่ง) อาจจะมีระดับกลางโฆษณาเฉพาะกิจ "คอมมิชชันหยุด" เพื่อให้ได้งานสร้างกลับมาที่มั่นคง ดังนั้นเราต้องการ: ทีมนักพัฒนาของเราในการพัฒนาและกระทำการเปลี่ยนแปลงในระหว่างการวิ่งไม่ จำกัด กระบวนการสร้างของเราที่จะละทิ้งหากขั้นตอนการสร้างล้มเหลวเนื่องจากผลการสร้างต่อมามีความหมายน้อย กระบวนการสร้างของเราเพื่อให้ข้อเสนอแนะในการพัฒนาคุณภาพแก่นักพัฒนาในเวลาที่เหมาะสม รับ (2) คะแนน …

11 testing  scrum  code-quality  jenkins 

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

11 agile  scrum 

เรื่องราวของผู้ใช้ด้านเทคนิคได้รับอนุญาตในการต่อสู้หรือไม่? ถ้าใช่เทมเพลตมาตรฐานสำหรับการเขียนเรื่องราวผู้ใช้ด้านเทคนิคใน Scrum คืออะไร มันเหมือนกันหรือAs a <user> I want to do <task> so that I can <goal>ไม่? ฉันได้อ่านในบางบล็อกที่เป็นผู้พัฒนาไม่เป็นเรื่องผู้ใช้แต่ฉันได้อ่านด้วยว่า Scrum ไม่ได้บังคับใช้สิ่งเหล่านี้ มีไม่กี่บล็อกที่พวกเขาได้ร่วมกันเป็นเรื่องที่ผู้ใช้กับระบบเป็นผู้ใช้as a <user who is not end user> i want to <system functionality> so that <some techinical thing>เช่นของมัน แล้วอันไหนที่เป็นมาตรฐาน? ตัวอย่างเช่นมีเรื่องราวของผู้ใช้ที่ชอบ: ในฐานะนักวิจารณ์ฉันต้องการอัปโหลดรูปภาพของโรงแรม / อาหารเพื่อให้ผู้ใช้รายอื่นสามารถเห็นและชอบได้ ในฐานะผู้ใช้ฉันต้องการเพิ่มความคิดเห็นเกี่ยวกับรูปภาพเพื่อให้ฉันสามารถอธิบายมุมมองของฉันได้ดียิ่งขึ้น ตอนนี้สำหรับเรื่องราวของผู้ใช้ทั้งสองนี้มีรายการทางเทคนิคที่สำคัญคือการบันทึกและดึงภาพ ดังนั้นฉันสามารถเพิ่มเรื่องทางเทคนิคที่ชื่อว่า "การจัดเก็บและเรียกค้นภาพกลไก" พร้อมคำอธิบายต่อไปนี้ได้หรือไม่ ในฐานะนักพัฒนาฉันต้องการพัฒนากลไกในการจัดเก็บและดึงภาพเพื่อให้ผู้ใช้สามารถเพิ่ม / …

11 project-management  agile  scrum  project  user-story 

ฉันได้เข้าร่วมทีมใหม่ซึ่งใช้ Agile / Scrum และกระบวนการพัฒนาของพวกเขามีดังนี้: 1) นักพัฒนาตรวจสอบแต่ละเรื่องก่อนการวิ่งแต่ละครั้งเพื่อให้แน่ใจว่าจะไม่พลาดสิ่งสำคัญ มีสถานะทางการสำหรับเวิร์กโฟลว์ 2) ในช่วงการแข่งขันสปรินท์ทั้งทีมทำการประเมิน (การวางแผนโป๊กเกอร์) ว่าจะให้คะแนนเรื่องราวกี่เรื่องในแต่ละเรื่อง 3) ในที่สุดทันทีหลังจากเริ่มการวิ่งแต่ละครั้งนักพัฒนาแต่ละคนจะต้องทำการแบ่งเรื่องราวที่ได้รับมอบหมายทั้งหมดออกเป็นงานย่อยโดยมีการประเมินเวลา ข้อโต้แย้งหลักสำหรับขั้นตอนสุดท้ายคือการช่วยในการค้นหาว่าการดำเนินเรื่องจะใช้เวลานานกว่าที่คาดการณ์ไว้หรือไม่และเตือนอาจารย์ต้นแบบเกี่ยวกับความเสี่ยงที่อาจเกิดขึ้นจากกำหนดส่งท้ายที่หายไป แต่ฉันก็พบว่าสิ่งนี้ต่อต้านการผลิตส่วนใหญ่เนื่องจากเหตุผลดังต่อไปนี้: ถ้าเป้าหมายคือการประมาณคร่าว ๆ จุดเรื่องราว (ขั้นตอนที่ 2) คือสิ่งที่ทำงาน มิฉะนั้นทำไมต้องกังวลกับเรื่องราวทั้งหมด - เพียงแค่ทำภารกิจย่อยเร็ว ถ้าจุดมุ่งหมายคือการให้ข้อมูลประมาณการที่ถูกต้องแล้วนี้เป็นตัวอย่างที่ชัดเจนของสิ่งที่อธิบายไว้ในงานของมนุษย์ช์พิจารณาอันตราย ฉันคิดว่านี่เป็นกรณีพิเศษสำหรับนักพัฒนาใหม่ที่เข้าร่วมทีมที่มีอยู่ในโครงการขนาดใหญ่ที่เข้าใจว่าต้องทำอะไรอาจต้องใช้เวลามากถึง 50% คุณจะต้องดูรายละเอียดของเรื่องราว # 1 จากนั้นเล่าเรื่องราวที่ 2, # 3 ฯลฯ ฯลฯ ซึ่งให้ข้อมูลจำนวนมากปั่นป่วน ฉันยังได้รับการบอกว่าการปฏิบัติเช่นนี้เป็น "หนังสือ" และฉันก็ไม่ได้ตั้งใจจะพูดคุยเรื่องนี้ ทุกคนสามารถให้การอ้างอิงถึงการปฏิบัติดังกล่าว - ไม่ว่าจะมีการกำหนดไว้อย่างชัดเจนในพระคัมภีร์ Scrum และ / หรืออาจให้ข้อมูลเชิงลึกเพิ่มเติมหรือไม่?

11 agile  scrum 

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

11 scrum 

ฉันกำลังอ่านเอกสารการต่อสู้และบอกว่างานใน Sprint ควรเป็น "ที่อาจเป็นไปได้" ฉันสับสนกับความหมายของสิ่งนี้ สมมติว่าใน Sprint 1 มีเป้าหมายคือ "แบบฟอร์มลงทะเบียนผู้ใช้" ฉันต้องเพิ่มรายละเอียดมากเท่าใดเพื่อให้พร้อมที่จะส่ง? ตัวอย่างเช่น: ฉันสามารถแสดงฟอร์มที่เรียบง่ายพร้อมฟิลด์โดยไม่ต้องใส่สไตล์แฟนซีใด ๆ และทำเครื่องหมายว่าเสร็จแล้ว ฉันสามารถทำการตรวจสอบฝั่งไคลเอ็นต์เป็นเครื่องหมายว่าทำเสร็จแล้ว แต่ฝั่งเซิร์ฟเวอร์ก็เป็นตัวเลือกหรือทั้งสองอย่าง ฉันยังสามารถเพิ่มเคล็ดลับเครื่องมือแฟนซี jQuery, เลื่อนเมาส์ไปวาง, captcha, สี, ป้ายกำกับสำหรับแบบฟอร์ม จากนั้นมีการจัดแต่งทรงผมมากมายเกี่ยวกับวิธีแสดงข้อความผิดพลาดบนหน้าจอ ฉันสามารถทำได้อย่างไม่มีที่สิ้นสุดในหนึ่งหัวข้อ ดังนั้นเราจะแบ่งมันอย่างไรและเมื่อไหร่ฉันจึงคิดว่ามันเป็นการขนส่งที่พร้อม หรือฉันต้องเขียนสิ่งที่เล็กที่สุดเท่าที่จะเป็นไปได้เช่นการแสดงข้อผิดพลาดป๊อปอัปหรือข้อความกล่องไฟเป็นงานย่อยและทำให้พวกเขาวิ่งได้ สิ่งนี้จะนำไปสู่งาน 1,000 โครงการสำหรับทั้งโครงการ ฉันหมายถึงอีกครั้งถ้าบางคนทำงานกับ Internet Explorer และบางคนสำหรับ Firefox แล้วฉันต้องแบ่งมันเป็นงานด้วย ต้องใช้เวลากับพวกเขาและเมื่อผู้จัดการถามฉันว่าคุณทำอะไรในเวลานั้นฉันจะไม่มีหน้าที่บอกอะไร แต่จริงๆแล้วพวกเขาทั้งหมดเป็นส่วนหนึ่งของการลงทะเบียนผู้ใช้

11 web-development  agile  project-management  scrum 

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

11 scrum  sprint 

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

11 agile  scrum 

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

11 scrum  management 

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

11 agile  scrum  team  spoken-languages  distributed-development 

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

11 scrum  user-story  sprint 

การต่อสู้ที่ดีที่สุดสำหรับทีมที่มีสมาชิก generalists นั่นคือทีมที่อย่างน้อย 2 คนสามารถทำงานเดียวกันได้ ความกังวลหลักของฉันคือการหาทางออกที่ดีในการปรับการทะเลาะกัน (สิ่งที่ต้องรักษาสิ่งที่ต้องกำจัดสิ่งที่ต้องปรับปรุง) สำหรับทีมที่ทำโดยผู้เชี่ยวชาญ สมมติว่าคุณมีทีมนักพัฒนา 5 คน (ไม่ใช่ของจริงสำหรับตัวอย่าง): นักคณิตศาสตร์หนึ่งคนที่มีทักษะสูงใน C; นักพัฒนา DB หนึ่งคน นักพัฒนาเว็บเดียว ผู้พัฒนา UX / GUI หนึ่งราย สถาปนิกซอฟต์แวร์หนึ่งคน ที่นี่ทั้งหมดเป็นผู้เชี่ยวชาญและไม่มีใครสามารถแทนที่คนอื่น (ฉันไม่สนใจเกี่ยวกับความเสี่ยงของการสร้างทีมดังกล่าวฉันต้องการมุ่งเน้นไปที่การต่อสู้) ดังนั้นในบริบทการต่อสู้นี่คือความคิดของฉัน: การวางแผนในฤดูใบไม้ผลิที่ไร้ประโยชน์:แน่นอนเมื่อนักคณิตศาสตร์บอกว่างานที่เฉพาะเจาะจงมีค่า 2 คะแนนไม่มีใครสามารถโหวตเขาได้ การวัดความเร็วของทีมที่ไร้ประโยชน์:เนื่องจากทุกคนสามารถจัดสรรคะแนนจำนวนใดก็ได้ให้กับงานของเขาการคำนวณความเร็วนั้นไม่สมเหตุสมผล แทนที่การประชุมทะเลาะกันประจำวันด้วยการประชุมทะเลาะกันรายสัปดาห์ (อีกต่อไป):เนื่องจากสมาชิกแต่ละคนในทีมกำลังทำงานของตัวเองการประชุมทะเลาะกันประจำวันจึงเป็นสิ่งสำคัญที่จะต้องรักษา "การทำงานเป็นทีม" อย่างไรก็ตามการประชุมการต่อสู้ในชีวิตประจำวันจะใช้เวลาประมาณ 15 นาที ชัดเจนว่าไม่เพียงพอที่จะเข้าใจในสิ่งที่คนอื่นทำและจะทำ ยิ่งไปกว่านั้นนักคณิตศาสตร์ส่วนใหญ่จะตอบในสิ่งเดียวกัน: "ฉันยังคงทำ% & Lo (+? $$ + &)" ... การประชุมประจำสัปดาห์จะให้เวลามากขึ้น เพื่อให้เวลาการประชุมเดียวกันระหว่างการประชุมการประชุม "เริ่มต้น" …

11 agile  scrum 

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

11 scrum  teamwork 

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

11 agile  scrum