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

กรอบความคล่องตัวที่เจ้าของผลิตภัณฑ์ (PO), ทีมพัฒนา (DT) ของนักพัฒนา 3-9 คนและ Scrum Master (SM) ทำงานเป็นทีม Scrum (ST) เพื่อสร้างและรักษาผลิตภัณฑ์ที่ซับซ้อนซึ่งมีมูลค่าสูงสุดเท่าที่จะเป็นไปได้ พวกเขาทำงานนี้ภายในกล่องเวลาที่เรียกว่า Sprint Sprints อาจสั้นลง แต่อาจไม่เกิน 30 วัน เหตุการณ์บทบาทและสิ่งประดิษฐ์มีการอธิบายอย่างชัดเจนในคู่มือการต่อสู้อย่างเป็นทางการ: http://scrumguides.org/scrum-guide.html

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

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

7
การแย่งการประเมินค่าสูงเกินไปและการทำซ้ำ
เราอยู่ในช่วงกลางของ Sprint แรกของเราและบางสิ่งบางอย่างที่เกิดขึ้นกับเรา: เราไปประมาณ! เราได้วางแผน 114 ชั่วโมงที่เหมาะสำหรับการทำซ้ำ 2 สัปดาห์นี้และในตอนท้ายของสัปดาห์แรกเราเสร็จ Sprint ทั้งหมด เราจะทำอะไรตอนนี้ "หนังสือ" บอกว่าเราควรและเราจะได้รับรายการลำดับความสำคัญสูงต่อไปจากงานในมือ แม้ว่าเราจะเพิ่มพวกเขาลงในแผนภูมิที่ถูกเผาไหม้ได้อย่างไร เราเขียนมันอีกครั้งเพื่อเล่าเรื่องราวเหล่านั้นราวกับว่าพวกเขาอยู่ที่นั่นตั้งแต่ต้น? หรือเพียงเพิ่มการประมาณของพวกเขาไปยังแกน y ในวันที่เราเริ่มทำงานกับพวกมัน (แสดงการกระโดดมุม 90o)? ข้อเสนอแนะใด ๆ ยินดีต้อนรับ!
10 scrum  planning 

4
การสร้างใหม่ในการออกแบบโดเมนขับเคลื่อน [ปิด]
ปิด คำถามนี้ต้องการรายละเอียดหรือความคมชัด ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ เพิ่มรายละเอียดและชี้แจงปัญหาโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ฉันเพิ่งเริ่มทำงานในโครงการและเรากำลังใช้การออกแบบที่ขับเคลื่อนด้วยโดเมน (ตามที่กำหนดโดย Eric Evans ในการออกแบบที่ขับเคลื่อนด้วยโดเมน: การแก้ปัญหาความซับซ้อนในหัวใจของซอฟต์แวร์ฉันเชื่อว่าโครงการของเราเป็นผู้สมัครสำหรับการออกแบบนี้ แบบที่อีแวนส์อธิบายไว้ในหนังสือของเขา ฉันกำลังดิ้นรนกับความคิดในการปรับโครงสร้างใหม่อย่างต่อเนื่อง ฉันรู้ว่าการปรับโครงสร้างเป็นสิ่งจำเป็นในโครงการใด ๆ และจะเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้เมื่อมีการเปลี่ยนแปลงซอฟต์แวร์ อย่างไรก็ตามจากประสบการณ์ของฉันการเปลี่ยนโครงสร้างเกิดขึ้นเมื่อความต้องการของทีมพัฒนาเปลี่ยนไปไม่ใช่ความเข้าใจในการเปลี่ยนแปลงโดเมน ("การปรับโครงสร้างใหม่เป็นความเข้าใจที่ลึกซึ้งยิ่งขึ้น" ตามที่ Evans เรียกว่า) ฉันกังวลมากที่สุดกับความก้าวหน้าในการทำความเข้าใจโมเดลโดเมน ฉันเข้าใจว่าทำการเปลี่ยนแปลงเล็กน้อย แต่จะเกิดอะไรขึ้นถ้าจำเป็นต้องเปลี่ยนแปลงโมเดลเป็นอย่างมาก เป็นวิธีที่มีประสิทธิภาพในการโน้มน้าวตัวเอง (และอื่น ๆ ) คุณควร refactor หลังจากที่คุณได้รับรูปแบบโดเมนที่ชัดเจนคืออะไร? ท้ายที่สุดการปรับโครงสร้างองค์กรเพื่อปรับปรุงโค้ดหรือประสิทธิภาพอาจแตกต่างอย่างสิ้นเชิงจากวิธีการแสดงออกในแง่ของรหัสภาษาที่แพร่หลาย บางครั้งดูเหมือนว่าไม่มีเวลาพอที่จะสร้างใหม่ โชคดีที่ SCRUM ปล่อยให้ตนเองฟื้นฟู ลักษณะซ้ำของ SCRUM ทำให้ง่ายต่อการสร้างชิ้นเล็ก ๆ และเปลี่ยนแปลงและมัน แต่เมื่อเวลาผ่านไปชิ้นส่วนนั้นจะใหญ่ขึ้นและจะเกิดอะไรขึ้นถ้าคุณมีความก้าวหน้าหลังจากชิ้นส่วนนั้นใหญ่มากจนยากที่จะเปลี่ยน มีใครทำงานในโครงการที่ใช้การออกแบบโดยใช้โดเมนหรือไม่ ถ้าเป็นเช่นนั้นจะเป็นการดีหากได้รับข้อมูลเชิงลึกเกี่ยวกับสิ่งนี้ ฉันต้องการได้ยินเรื่องราวความสำเร็จเป็นพิเศษเนื่องจาก DDD ดูเหมือนจะยากมาก ขอบคุณ!

4
แบ็กเอนด์ devs วางโดยเรื่องราวของผู้ใช้
ฉันวางแผนที่จะแบ่งการพัฒนาแบ็กเอนด์เข้ากับเรื่องราวของผู้ใช้ในแนวตั้ง แต่คนที่แบ็กเอนด์ในทีมของเราเริ่มบ่นว่านี่ทำให้งานของพวกเขาล่องหน คำตอบของฉันคือ ในการวางแผนการวิ่งและทบทวนการประชุมเราหารืองานแบ็กเอนด์ต่อหน้าผู้มีส่วนได้ส่วนเสียเพื่อให้สามารถมองเห็นได้และ การรักษาคุณภาพในระหว่างโครงการจะส่งผลให้เริ่มช้ากว่าทีมอื่น ๆ แต่เราจะมีความเร็วคงที่ในระหว่างโครงการ และความเร็วจะปรากฏแก่ผู้มีส่วนได้เสียอย่างชัดเจน เขายังคงยืนยันที่จะมีเรื่องราวเช่น: "ในฐานะนักพัฒนาฉันต้องมีเลเยอร์โดเมนเพื่อให้ฉันสามารถสรุปทางตรรกะทางธุรกิจได้" ฉันจะแก้ปัญหาก่อนที่ทีมจะสร้างมลพิษได้อย่างไร สาเหตุของปัญหาคือฝ่ายบริหารของเราพิจารณางานแบ็กเอนด์อย่างเป็นระบบโดยมองไม่เห็นและเรียกผู้ปฏิบัติงานที่ได้รับการสนับสนุนหรือเงื่อนไขการดูหมิ่นอื่น ๆ
10 agile  scrum  team  user-story 

6
ขั้นตอนใดของ Agile (SCRUM) ที่เราควรเริ่มสร้างการทดสอบระบบอัตโนมัติ
พื้นหลังเล็กน้อยของฉัน - ฉันเป็นผู้ทดสอบด้วยตนเองเป็นเวลาเกือบ 2 ปีในสภาพแวดล้อม Agile โดยใช้ SCRUM (1-2 สัปดาห์ในการวิ่ง) ดังนั้นฉันต้องการที่จะแนะนำการทดสอบระบบอัตโนมัติในงานของฉันโดยใช้ Selenium WebDriver (กับ Java) คำถามของฉันอยู่ในระหว่างเมื่อฉันควรทดสอบการทำงานด้วยตนเองและเมื่อฉันควรแปลงพวกเขาสำหรับการทดสอบอัตโนมัติ ฉันได้อ่านและรับแนวทางที่แตกต่างเช่น: เมื่อเริ่มการวิ่งใหม่ให้แปลงเรื่องราวของผู้ใช้เป็นสคริปต์อัตโนมัติจากการวิ่งก่อนหน้านี้หรือ; แปลงเรื่องราวของผู้ใช้ภายในการวิ่งเดียวกัน คำแนะนำใด ๆ / s จะได้รับการชื่นชมอย่างมาก ขอบคุณล่วงหน้า.

7
เป็นที่ยอมรับหรือไม่ที่จะมีการอภิปรายที่ไม่เกี่ยวข้องกับการเช็คอินในการประชุม Scrum Daily Standup?
ฉันหวังว่าผู้คนจะดื่มด่ำกับคำถามที่เห็นได้ชัด ฉันทำงานในองค์กรหลายแห่งที่มีการประชุมทะเลาะกันทุกวัน บางองค์กรมีความเข้มงวดอย่างมากเกี่ยวกับการใช้ scrum ในการเช็คอิน ("คำถามสามข้อ" - คุณทำอะไรเมื่อวานนี้คุณทำอะไรวันนี้คุณมีบล็อกเกอร์หรือไม่) แต่องค์กรอื่น ๆ ที่มีแนวโน้มทั่วไป ประกาศหรือการสนทนาทางเทคนิคอย่างละเอียด ฉันเคยได้ยินข้อโต้แย้งเช่นในบทความนี้ว่าการอนุญาตให้มีการอภิปรายที่ไม่เกี่ยวข้องกับการเช็คอินเช่นนี้เป็นความผิดพลาด - การประชุมการต่อสู้ไม่ควรใช้สำหรับการประกาศทั่วไปจาก Scrum Master การสนทนาทางเทคนิค ฯลฯ อันตรายหลักที่ฉันเห็นจากการประชุมครั้งนี้คือการประชุมอาจยาวนานเกินความจำเป็น (และเป็นเรื่องน่ารำคาญที่ถูกบังคับให้ต้องนั่งคุยกันเรื่องรายละเอียดที่ไม่เกี่ยวข้องกับฉัน) ค่อนข้างชัดเจนว่าการอภิปรายที่ไม่เกี่ยวข้องกับทั้งกลุ่มและไม่ได้เป็นส่วนหนึ่งของ "คำถามสามข้อ" ไม่ควรเป็นส่วนหนึ่งของการยืนขึ้น อย่างไรก็ตามหากมีการประกาศอื่น ๆ ที่เกี่ยวข้องกับทั้งกลุ่มและจำเป็นต้องมีการหารือต่อไปมันจะเป็นอันตรายหรือไม่ที่จะพูดถึงสิ่งเหล่านั้น ณ จุดนั้น (แทนที่จะเป็นการประชุมหรืออีเมลแยกต่างหาก)?

6
เกณฑ์การยอมรับสำหรับคดีขอบ
ฉันเป็นเจ้าของผลิตภัณฑ์ในทีมเปรียว ฉันเมื่อทำการทดสอบการยอมรับ PO ฉันมักจะจดบันทึกเพื่อลองกรณีขอบบางอย่าง ไม่ใช่เรื่องแปลกสำหรับฉันที่จะค้นพบบางสิ่งและจากนั้นฉันก็ส่งมันกลับไปที่ผู้พัฒนา ฉันได้รับการผลักดันกลับจากหนึ่งในนักพัฒนาซอฟต์แวร์เมื่อฉันปฏิเสธเรื่องราวของเขา เขาบอกว่ามันไม่ยุติธรรมเพราะฉันไม่ได้ระบุกรณีขอบและวิธีการที่โปรแกรมควรตอบสนองในเกณฑ์การยอมรับในขณะที่เขามักจะเขียนโค้ดเฉพาะสิ่งที่ฉันอธิบายในเรื่อง ฉันสนับสนุนให้เขาถามฉันในขณะที่เขากระแทกเข้ากับเคสที่มีขอบขณะเขียนโค้ด แต่เขาคิดว่าไม่ใช่หน้าที่ของเขาที่จะคิดผ่านเคสที่เป็นขอบฉันและฉันควรทำเรื่องใหม่สำหรับการวิ่งครั้งต่อไป ในการป้องกันของฉันฉันไม่ทราบว่าการออกแบบของเขาสำหรับเรื่องราวจนกระทั่งหลังจากที่เขาใช้มันดังนั้นมันยากที่จะย้ำผ่านความเป็นไปได้ทั้งหมด (การกำหนดค่าจะอยู่ใน DB หรือไฟล์คุณสมบัติ?) เพื่อความเรียบง่ายสมมติว่าเรามีเรื่องราวที่จะเพิ่มการหารลงในแอพเครื่องคิดเลข ในโลก SCRUM ในอุดมคติมันจะเป็นหน้าที่ของฉันที่จะเพิ่ม "จัดการหารด้วยศูนย์สถานการณ์" เพื่อเกณฑ์การยอมรับหรือเขาควรจะทำงานผ่านกรณีเหล่านั้นในขณะที่เขาพัฒนาเพื่อให้แอปไม่ได้แปลในวันที่ 5/0? เพื่อความชัดเจนในกรณีนี้ฉันจะไม่ยอมรับหากแอปขัดข้องอย่างหนักในวันที่ 5/01 แต่ฉันจะผ่านถ้ามันบันทึกพิมพ์ DIV0 หรือวิธีอื่นใดเพื่อจัดการข้อผิดพลาด ... ตราบใดที่มันไม่ทำงาน ไม่ผิดพลาด

8
การต่อรองและเอาชนะความพยายามในการประมาณค่าการแย่งชิงส่วนที่ถูกต้องของกระบวนการหรือไม่
ฉันสังเกตเห็นในการประชุมทะเลาะกันว่านักพัฒนามักจะให้การประเมินที่สมจริงเกี่ยวกับเรื่องราว อย่างไรก็ตามเรื่องราวที่ค่อนข้างเรียบง่ายนั้นต้องใช้ความพยายามอย่างมากในการกำหนดค่าการตั้งค่าส่วนประกอบของบุคคลที่สามการทดสอบและการสร้างขั้นสุดท้ายและระบบได้สะสมหนี้สินทางเทคนิคบางส่วนดังนั้นการประมาณการมักจะปรากฏสูงเกินไปสำหรับเจ้าของผลิตภัณฑ์หรือการจัดการ PO มักจะเอาชนะประมาณการเช่น: "คุณต้องการอะไร 13 เรื่อง [4 วัน] สำหรับเรื่องนี้ไม่เป็น! ฉันไม่สามารถอธิบายสิ่งนี้กับฝ่ายบริหารได้ ด้วย 3 SP [ใน 4 ชั่วโมง]! " เป็นผลให้นักพัฒนาได้รับแขนของพวกเขาบิดที่จะมอบให้กับประมาณ 5 หรือ 8 เรื่องราว [1.5 ถึง 2 วัน] ประมาณการ (การต่อสู้แย่งชิงยังคงเป็นภาระผูกพันไม่ได้เป็นเพียงการคาดการณ์) แน่นอนว่าหากไม่มีแผนใด ๆ ที่จะตัดความคาดหวัง (ส่วนใหญ่เกี่ยวกับการทดสอบและคุณภาพ) การวิ่งเหล่านี้มักล้มเหลว การประเมินของนักพัฒนาซอฟต์แวร์นั้นเป็นสิ่งที่จริงซื่อตรงและเอาชนะการคาดการณ์ไม่ได้ทำให้งานที่แท้จริงต้องทำ หนึ่งสามารถพูดว่า: "คุณไม่ควรมุ่งมั่นที่เป็นไปไม่ได้เพียงเพราะใครบางคนผลักดันให้คุณทำ!" แต่ในความคิดของฉันงานของนักพัฒนาคือการออกแบบและเขียนโปรแกรมซอฟต์แวร์ไม่ใช่การต่อรองหรือยืนหยัดต่อสู้กับความกดดัน! อาจมีแจ็คของการซื้อขายทั้งหมดโดยทั่วไปผู้ที่ติดต่อโดยตรงกับลูกค้าภายนอก แต่นี่ไม่ใช่นักพัฒนาสำนักงานส่วนใหญ่! สำหรับฉันแล้วการฝึกนี้ทำให้โปรแกรมเมอร์ดูเหมือนกระตุกทำให้เกิดความล้มเหลวในการวิ่งอย่างต่อเนื่องและป้องกันการประมาณค่าจริงรวมทั้งมองหาการปรับปรุงที่เกิดขึ้นจริง แนวทางการแย่งชิงกันพูดในหัวข้อนี้หรือพวกเขาพูดอะไรเกี่ยวกับมัน? แก้ไข:แทนที่เวลาด้วยคะแนนเรื่องราว ฉันอ้างถึงขั้นตอนการประมาณค่าเริ่มต้นด้วยการวางแผนโป๊กเกอร์และคะแนนเรื่องราวไม่ใช่การวางแผนรายละเอียดงาน ฉันแค่ใส่วัน / ชั่วโมงเพราะมันเป็นบทสนทนาทั่วไปเช่นนี้บางครั้งก็มีเวลาแทนที่จะเป็นคะแนน ขออภัยในความสับสนใด ๆ ! …

5
การแย่งชิง: มันเป็นการดีสำหรับการออกแบบ / UX ของเรื่องราวของผู้ใช้ที่จะเกิดขึ้นในการวิ่งเช่นเดียวกับการใช้งาน
ขณะนี้ฉันกำลังวิ่ง (สองสัปดาห์) ที่นักออกแบบมอบหมายให้กำหนดข้อกำหนดและ UX ของเรื่องราวผู้ใช้เฉพาะ ในการวิ่งเหมือนกันฉันจะใช้การออกแบบนี้ ในระหว่างการวางแผนการวิ่งฉันต้องเดาอย่างหนักว่าเรื่องราวของผู้ใช้ที่ไม่ได้กำหนดจะต้องใช้เวลานานเท่าใด วันนี้ฉันได้รับการออกแบบในที่สุด น่าเสียดายที่การออกแบบไม่สมบูรณ์ / คลุมเครือและคล้ายกับความต้องการของลูกค้ามากกว่าการออกแบบ อย่างไรก็ตามจากนี้ฉันยังคงเห็นว่าฉันยังไม่ได้ประมาณพอ เพื่อทำให้เรื่องแย่ลงนี่ไม่ใช่ครั้งแรก ในการวิ่งครั้งสุดท้ายสิ่งเดียวกันก็เกิดขึ้นอย่างแน่นอน ฉันตั้งค่าสถานะมันในการหวนกลับของเราและอาจารย์การต่อสู้ไม่มีคำตอบของวิธีการแก้ปัญหานี้แทนที่จะพูดว่า "นั่นเป็นเพียงการพัฒนาสำหรับคุณ" เขากระแทกอย่างน่าขันถ้าการเผาไหม้ไม่ได้อยู่ที่เป้าหมาย ... ตอนนี้ฉันจะต้องถาม / ทำงานกับนักออกแบบเพื่อให้งานของเขาเสร็จ สิ่งนี้จะทำให้ฉันหมดแรงเมื่อฉันทำภารกิจอื่นทั้งหมดของฉันเสร็จแล้ว ดังนั้นคำถามของฉันคือ A) คุณจัดการการพึ่งพาในการวางแผนการวิ่งอย่างไร แก้ไข: มันใช้ได้หรือไม่สำหรับการออกแบบ / UX ของเรื่องราวของผู้ใช้ที่จะเกิดขึ้นในการวิ่งเช่นเดียวกับการใช้งาน B) ฉันจะเข้าใกล้การวิ่งได้อย่างไร? ประเมินเรื่องราวของผู้ใช้ปัจจุบันอีกครั้งและดูการเบิร์นอินกลายเป็นเบิร์นอัพและดูว่าไร้ความสามารถ / ไม่ก่อผล หรือเพิ่มงานใหม่ให้กับการวิ่งปัจจุบันตามแนวของ "ช่วยให้นักออกแบบสร้างการออกแบบที่เหมาะสม"
9 agile  scrum  planning 

5
การต่อสู้รายวันประชุม: ตรงต่อเวลามากกว่าการปรากฏตัวของทีมเต็ม?
ความเข้าใจของฉันคือการประชุมประจำวันการต่อสู้ควรรวดเร็วมากโฮสต์ในลักษณะที่เป็นมิตรและต้องการสมาชิกทุกคนในทีม เพราะมันมีวัตถุประสงค์คือการให้ทุกคนรู้ถึงสิ่งที่คนอื่นกำลังทำอยู่ ฉันชอบการประชุมรายวัน Scrum ที่จัดขึ้นเช่นนั้น ในโครงการล่าสุดของฉัน Scrums รายวันของเราเป็นเหมือนการประชุมอัพเดทสถานะ แม้ว่าตำแหน่งจะอยู่ที่เราถือ Scrums และฝึกฝน Agile ที่เหมาะสม เราเป็นทีมกระจายใน 2 ประเทศที่แตกต่างกันและผู้คนที่อยู่ในประเทศเดียวกันไม่ได้อยู่ในสำนักงานเดียวกัน ดังนั้นเราจึงมี Scrums เสมือน ปัญหาคือว่าการประชุมของเราจะเริ่มตรงเวลาหลายคนโทรมาก่อนเวลาเริ่มต้นจริงดังนั้นพวกเขาจึงเริ่มในวินาทีแรกของการประชุม ไม่มีความอดทนใด ๆ สำหรับความล่าช้าเล็กน้อย ตัวอย่างเช่นครั้งสุดท้ายที่เราอยู่ในโทรศัพท์และผู้ประสานงานการประชุมตรวจสอบว่าทุกคนอยู่ในนั้นและเราบอกว่าหนึ่งในสมาชิกในทีมของเรายังไม่ได้เปิด แต่เขาโทรมา และฉันถูกบอกให้เริ่มแบ่งปันโดยไม่ต้องรอสมาชิกในทีมของฉัน นอกจากนี้ทุกคนมีการประชุมจำนวนมากและบางครั้งพวกเขาก็กลับมาพร้อมการประชุมการต่อสู้ดังนั้นจึงเป็นเรื่องที่เข้าใจได้หากพวกเขามาถึงในช่วงนาทีแรกหรือที่สองของการประชุม เป็นเรื่องปกติสำหรับทีมที่ฝึก Daily Scrums หรือไม่? มันเป็นครั้งแรกที่เกิดขึ้นกับฉัน ฉันไม่สามารถหาบรรณานุกรมใด ๆ ได้โดยตรงเกี่ยวกับเรื่องนี้ แม้ว่าการปรากฏตัวของสมาชิกในทีมทุกคนจะเน้น แต่ก็เน้นว่าการประชุมควรเริ่มในเวลาเดียวกัน แต่ฉันคิดว่าอาจมีความทนทานต่อความล่าช้าเล็กน้อย ฉันยังอ่านในบล็อกที่มีคนแนะนำว่า Scrum Master สามารถลงโทษได้หากมีคนมาถึง "5 วินาที" ฉันคิดว่า Scrums ควรจะเป็นมิตรและมีโทษเช่นนั้นดูเหมือนจะเป็นประโยชน์ อะไรคือแนวทางที่แนะนำในสถานการณ์เช่นนี้?
9 agile  scrum 

4
การใช้การต่อสู้ในโครงการขนาดเล็กที่เจ้าของไม่ต้องการมีส่วนร่วม
เมื่อเร็ว ๆ นี้ฉันได้อ่านและเรียนรู้มากมายเกี่ยวกับการต่อสู้และฉันชอบมันมาก อย่างไรก็ตามฉันมีบางสถานการณ์ที่เป็นไปได้ในหัวซึ่งฉันไม่ทราบวิธีแก้ปัญหา ดังนั้นสมมติว่าฉันอาจต้องการจัดระเบียบทีมงานที่คล่องแคล่วของ (เช่น) นักพัฒนาเว็บสี่คน (หนึ่งในนั้นคือนักออกแบบ UI / UX) ทีมนี้จะทำงานในหลักการทะเลาะกัน เริ่มแรกเราอาจจะทำงานในโครงการต่าง ๆ เช่นหน้า Landing Page สำหรับธุรกิจขนาดเล็กของคนธรรมดาเช่นการให้เช่าอพาร์ทเมนท์ขายคุกกี้ ... ลูกค้าเหล่านี้ไม่สามารถกำหนดบทบาทของเจ้าของผลิตภัณฑ์ (IMHO) ได้เพราะพวกเขาคาดหวังว่าจะจ้าง บริษัท ให้รายละเอียดบางอย่างกับเป้าหมายโครงการโดยรวมแล้วคาดหวังว่างานที่จะทำ (รวมถึงการตัดสินใจจำนวนมาก) โดยมีส่วนร่วมน้อยที่สุดเท่าที่จะเป็นไปได้ (ในความเห็นของพวกเขาพวกเขามีสิ่งที่สำคัญกว่า) สมมติว่าฉันต้องการมีส่วนร่วมในบทบาทนักพัฒนา / ทะเลาะเบาะแว้ง (ฉันรู้ว่าแม้จะเป็นที่ถกเถียงกันในการเป็นสมาชิกในทีมและอาจารย์ทะเลาะกันในครั้งเดียว) ดังนั้นฉันก็ไม่ควรรับบทบาทของเจ้าของผลิตภัณฑ์เป็น ดี. ดังนั้นสำหรับคำถามของฉัน: หากฉันเป็นเจ้าของธุรกิจของ บริษัท ฉันต้องเป็นเจ้าของผลิตภัณฑ์ด้วยหรือไม่ (บทบาทเหล่านี้รวมถึงกันและกัน) ฉันสามารถจ้างพนักงานขายที่อาจมีบทบาทเป็นเจ้าของผลิตภัณฑ์ได้หรือไม่ มันจะดีกว่าไหมถ้าเป็นนักพัฒนาที่มีประสบการณ์แทนที่จะเป็นพนักงานขาย นี่คือการเคลื่อนไหวที่ชาญฉลาดหรือไม่? ท้ายที่สุดมีวิธีอื่นที่เหมาะสมกับตำแหน่งของฉันหรือไม่ แก้ไข:ขอบคุณทุกคนสำหรับปัจจัยการผลิตที่ดี ฉันได้เพิ่มความคิดเห็นข้อมูล aditional จะได้รับการชื่นชมอย่างมาก
9 agile  scrum 

5
การแบ่งเรื่องราวที่ซับซ้อนตั้งแต่เริ่มโครงการ
ฉันกำลังพยายามที่จะจับกับการจัดการโครงการเปรียว (กับ Pivotal Tracker) แต่พบว่าตัวเองวิ่งเข้าไปในกำแพงเมื่อพยายามที่จะกำหนดเรื่องราวสองสามเรื่องแรกของโครงการ ยกตัวอย่างเรื่องง่าย ๆ นี้: "ผู้ใช้ควรแท็กผลิตภัณฑ์" สมมติว่าฉันได้กำหนด "ผลิตภัณฑ์" ไว้ที่อื่นแล้วเรื่องราวนี้อาจเกี่ยวข้องกับการเขียนระบบการติดแท็กแบบ polymorphic ภายใต้ประทุนเมื่อการเสร็จสมบูรณ์ของรหัสระบบนั้นจะสามารถเพิ่มความสามารถในการติดแท็กผลิตภัณฑ์ในที่สุด ปัญหาของฉันคือปริมาณงานที่ซ่อนอยู่ในเรื่องนี้ ฉันสามารถกำหนดภารกิจเพื่อให้เรื่องราวสำเร็จ แต่เรื่องราวโดยรวมควรจะใช้งานได้ 1-2 วันหรือไม่ ฉันรู้สึกไม่ถูกต้องเกี่ยวกับเรื่องราวที่เพิ่งเปิดเผยปลายภูเขาน้ำแข็ง แต่นั่นเป็นเพียงส่วนเดียวที่เกี่ยวข้องกับผู้ใช้ คุณจะเอาชนะสิ่งนี้ได้อย่างไร อะไรคือการปฏิบัติที่ดีที่สุด? อัปเดต 25/08ขอบคุณทุกคนสำหรับคำแนะนำของคุณฉันได้รับคำแนะนำทั้งหมดเกี่ยวกับวิธีการกำหนดเรื่องราว ตอนนี้ฉันกำลังเปลี่ยนไปใช้ Jira Grasshopper ซึ่งได้รับการสนับสนุนที่ดีกว่าสำหรับงานในเรื่อง (การมอบหมายประมาณการและอื่น ๆ ) และการติดตามงานพัฒนาเมื่อเริ่มการวิ่ง
9 scrum 

4
เมื่อใดที่เหมาะสมที่จะเริ่มใช้การแก้ไขครั้งต่อไปของเครื่องมือเมื่อทำการทดลองอาหาร
โดยเฉพาะฉันกำลังทำงานกับเครื่องมือที่รวม DVCS และระบบการสร้าง แต่ฉันนึกภาพความท้าทายที่ฉันกำลังเผชิญจะเกิดขึ้นสำหรับทุกคนที่พัฒนาเครื่องมือ "เมตา" (คอมไพเลอร์ VCS ระบบสร้างตัวทดสอบวิ่ง ฯลฯ ) ต้องการพัฒนาผ่านการ"ทดลองใช้" คำถามของฉันคือในกระบวนการปล่อยรูปแบบการต่อสู้โดยใช้เวิร์กโฟลว์การแยกที่จุดใดฉันจะเริ่มใช้เครื่องมือรุ่นที่ใหม่กว่าในวงจรการพัฒนาของเครื่องมือได้หรือไม่ ฉันกำลังมองหากระบวนการสร้างความสมดุลระหว่าง: ใช้developเวอร์ชันของเครื่องมืออย่างต่อเนื่อง: ฉันพบว่าฉันเลิกพัฒนาตนเองเมื่อมีการเปลี่ยนแปลงเกิดขึ้น ใช้masterเวอร์ชันของเครื่องมืออย่างต่อเนื่อง: ปัญหาใด ๆ ที่ฉันค้นพบผ่านการทดลองใช้สุนัขเป็นปัญหาที่ได้รับการเผยแพร่แล้ว

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.