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

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

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

3
ทำอย่างไรจึงจะเป็นตัวแทนโครงการความคล่องตัวให้กับผู้ที่มุ่งเน้นไปที่น้ำตก [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ทีมงานของเราถูกขอให้เป็นตัวแทนของความพยายามในการพัฒนาของเราในแผนโครงการ ไม่มีใครไม่พอใจกับงานของเราหรือตั้งคำถามกับความสามารถในการส่งมอบของเราเราเพียงแค่เข้าร่วมในการเรียกร้องให้มีการวางแผนโครงการ ปัญหาคือเราเป็นทีมที่คล่องตัวและไม่ได้คิดเกี่ยวกับงานของเราในแง่ของแผนโครงการที่เป็นทางการ ในขณะที่เรามีความคิดทั่วไปเกี่ยวกับสิ่งที่เรากำลังดำเนินการต่อไปเราไม่แน่ใจ 100% จนกว่าเราจะวางแผนการทำซ้ำ จนถึงขณะนี้ทีมงานของเราส่วนใหญ่ทำงานในสุญญากาศและไม่จำเป็นต้องนำเสนอวิธีการหรือตัวชี้วัดของเราแก่บุคคลภายนอก เราปฏิบัติตามมากที่สุดของการปฏิบัติดำเนินการในการเขียนโปรแกรมมาก เราจัดการประชุมวางแผนรายไตรมาสเพื่อให้มีความคิดทั่วไปเกี่ยวกับเรื่องราวที่เรากำลังจะทำในไตรมาส ที่กล่าวว่าเรื่องราวของเรามีการบันทึกไว้ในการ์ด 3x5 และได้รับการประเมินเฉพาะตอนเริ่มต้นของการทำซ้ำที่จะใช้งานได้ หลังจากการประมาณค่าที่เราเอกสารเรื่องราวในทีมมูลนิธิ Sever ในระหว่างการทำซ้ำเราจะแนบโค้ดกับเรื่องราวและทำเครื่องหมายเรื่องราวว่าเสร็จสมบูรณ์เมื่อเสร็จแล้ว จากข้อมูลนี้เราสามารถสร้างแผนภูมิเบิร์นดาวน์และความเร็ว สิ่งสำคัญที่สุดคือเรารู้ความเร็วเฉลี่ยของเราในการวนซ้ำทำให้เราไม่สามารถกัดได้มากกว่าที่เราเคี้ยว ฉันไม่ต้องการปรับเปลี่ยนวิธีการพัฒนา แต่ต้องการนำเสนอกิจกรรมการพัฒนาของเราในรายงานที่มีคนคุ้นเคยกับน้ำตกเท่านั้นที่จะเข้าใจ ในแผนโครงการ Agile ที่มีหน้าตาเป็นอย่างไรเคนแมคโดนัลด์ทำหน้าที่ได้ดีในการวางความแตกต่างระหว่างแผนโครงการความคล่องตัวและน้ำตก เขาระบุความแตกต่างในกระสุนบริโภค: แผนโครงการเปรียวขึ้นอยู่กับคุณสมบัติ จัดทำแผนโครงการ Agile เป็นซ้ำ แผนโครงการ Agile มีรายละเอียดในระดับที่แตกต่างกันขึ้นอยู่กับกรอบเวลา ทีมงานโครงการแผนเปรียวเป็นเจ้าของ ความสามารถในการอธิบายความแตกต่างนั้นยอดเยี่ยม แต่วิธีที่ดีที่สุดในการนำเสนอข้อมูล

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

4
การออกแบบและวางผังสำนักงานเพื่อการพัฒนาที่คล่องตัว
(ย้ายจาก stackoverflow) ฉันได้พบการสนทนามากมายเกี่ยวกับพื้นหลังแป้นพิมพ์โต๊ะแสงหรือสีที่ดีที่สุด - แต่ฉันไม่สามารถหาที่อยู่ในรูปแบบของสำนักงานทั้งหมดได้ เราเป็น บริษัท ที่มีพนักงานประมาณ 20 คนย้ายไปยังสถานที่ใหม่ ๆ มีสองวิธีการพัฒนาหลักที่เกิดขึ้นที่นี่ด้วยการรวมกันเป็นประจำคนที่อยู่ด้านหลังมักจะต้องทำงานกับคนที่ทำงานกับมือถือเพื่อจัดบริการเว็บ มีผู้คนที่มีแบ็คเอนด์ประมาณสองเท่าในฐานะคนที่ใช้มือถือ ประมาณครึ่งหนึ่งของนักพัฒนาซอฟต์แวร์แบ็คเอนด์กำลังทำงานอยู่ในสถานที่ใด ๆ และในขณะที่พวกเขาแทบจะไม่เคยอยู่ในออฟฟิศในเวลาเดียวกันอย่างน้อย 5-10 ช่องว่างที่จะต้องจัดเตรียมไว้ดังนั้นเวลาส่วนใหญ่ของทั้งสองกลุ่มนั้น เรามีโอกาสจัดโต๊ะทำงานพาร์ทิชันและอาจเป็นผนังเพื่อให้พื้นที่ดี จะไม่มีเงินสดสำหรับดอทคอมคอมเมิร์ซเช่นการจัดเลี้ยงหรือการนวด แต่ตอนนี้เป็นเวลาที่จะต้องวางแผนที่จะหลีกเลี่ยงการจบลงด้วยการมีโต๊ะทำงานยาวเป็นแถว Joel on Software ของBionic Officeเป็นบทความที่ฉันจำได้จากทางด้านหลังและมีความคิดที่ดี แต่ฉัน * (และที่สำคัญกว่านั้นคือเจ้าของ บริษัท ) ไม่ได้ขายอย่างสมบูรณ์ในแนวคิดความเป็นส่วนตัวในสภาพแวดล้อมที่เราควรร่วมมือกัน . นี่เป็นลิงค์ที่ยอดเยี่ยมอีกอย่างหนึ่ง - โครงร่างการพัฒนาซอฟต์แวร์ขั้นสูงสุด - ฉันยังจำห้องประชุมที่ปิดไว้ไม่ได้จนกว่าจะอ่านสิ่งนี้ สำนักงานเอกชนยืนหยัดในการพัฒนาที่คล่องตัวหรือไม่? การทะเลาะเบาะแว้งกันอย่างแรงพอที่จะติดต่อและถ้าคุณต้องการที่จะบักใครสักคนคุณควรจะลุกขึ้นยืนและเคาะประตูของพวกเขา? คุณสามารถชี้เลย์เอาท์การออกแบบอะไรและทำไมคุณถึงแนะนำพวกเขา * ฉันไม่ได้ต่อต้านการปิดสำนักงาน แต่จะมีความสุขถ้าโซลูชันอื่นสามารถทำได้เช่นกัน ถ้ามันเป็นไปไม่ได้ ... เอาละนั่นคือคำถามนี้เกี่ยวกับ สองอัปเดต - เมษายน …

5
ข้อผิดพลาดของเวิร์กโฟลว์ในทีม agile / Scrum ของคุณคืออะไร?
ข้อผิดพลาดของเวิร์กโฟลว์ในทีม agile / Scrum ของคุณคืออะไร? นี่คือของเรา: - หากข้อผิดพลาดเกี่ยวข้องกับเรื่องราวในการวิ่งปัจจุบันเราจะแก้ไข - หากบั๊กไม่เกี่ยวข้องกับเรื่องราวใน sprint ปัจจุบันและไม่สำคัญจะถูกส่งไปยังเจ้าของผลิตภัณฑ์เพื่อจัดลำดับความสำคัญ - หากข้อผิดพลาดไม่เกี่ยวข้องกับเรื่องราวในการวิ่งและเป็นสิ่งสำคัญเราจะแก้ไข
9 agile  bug  scrum  workflows 

5
การประเมินสมาชิก Scrum ตามจำนวนเรื่องราวผู้ใช้ที่ประสบความสำเร็จนั้นถูกต้องหรือไม่
เมื่อผู้จัดการของฉันบอกกับทีมว่า " ตอนนี้เป็นต้นไปเรื่องราวของผู้ใช้ที่ประสบความสำเร็จจะได้รับการพิจารณาเพื่อการประเมิน! " เรานั่งที่นั่นในขณะที่ตกใจและนั่นเป็นหนึ่งในหลาย ๆ ช่วงเวลาที่ขากรรไกรหล่นเขา :-) เรารู้สึกว่าเป็นความคิดที่โง่เพราะจะทำลายแนวคิดและเป้าหมายทั้งหมดของวิธีการพัฒนาแบบว่องไว บอกให้ฉันรู้ว่าคุณคิดอย่างไร และเราจะโน้มน้าวเขาได้อย่างไร?

7
ใน Scrum วิธีจัดการกับความขัดแย้ง / ภาระงานเมื่อสิ้นสุดการวิ่ง
ทีมของฉันเริ่มใช้ Scrum เมื่อสองสามปีก่อน โครงการของเราเกี่ยวข้องกับการสร้างซอฟต์แวร์ที่เชื่อมต่อกับอุปกรณ์ทางกายภาพ (คิดว่าโรบอตและเซ็นเซอร์) และผลิตภัณฑ์ที่ค้างทั่วไปของเรามักจะเป็นตัวแทนของการเพิ่มอุปกรณ์ควบคุมในระบบทั้งหมด เราแบ่งลงงานใกล้เคียงกับตัวอย่างที่นี่ คุณลักษณะการรวมอุปกรณ์แต่ละรายการจะแบ่งเป็นรหัสการทดสอบการทดสอบการรวมระบบการตรวจสอบโดยเพื่อน ฯลฯ เห็นได้ชัดว่ามีลำดับตามรายการสินค้าค้างแต่ละรายการ โดยทั่วไปแล้วการวิ่งของเราในช่วง 2 สัปดาห์ที่ผ่านมาและทีมมีสมาชิกระหว่าง 4 ถึง 6 คน เราพบปัญหา 2 ข้อเมื่อสิ้นสุดการวิ่ง: ประการแรกคือการทำให้ทุกคนไม่ว่างในตอนท้ายของการวิ่ง อันที่สอง (ที่เกี่ยวข้อง) คือการแข่งขันในระบบ เราค่อนข้างจะรวมการทำงานในช่วงสองสามวันสุดท้ายของการวิ่ง เรามีระบบการรวมเพียงระบบเดียวดังนั้นผู้คนมักถูกบล็อกไม่ให้ทำงานต่อเนื่องเพราะพวกเขาไม่สามารถเข้าถึงระบบได้ เนื่องจากเป็นจุดสิ้นสุดของการวิ่งจึงไม่มีงานเหลืออีกมากที่ต้องทำในงานค้างการวิ่ง คนเหล่านี้ควรทำงานอะไร การรับไอเท็มจากด้านบนสุดของผลิตภัณฑ์ค้างนั้นยังไม่ได้รับอย่างดีจากเจ้าของผลิตภัณฑ์เนื่องจากรายการปัจจุบันยังไม่เสร็จ การทำงานด้านหนี้สินทางเทคนิคจะช่วยโครงการโดยรวม แต่จะไม่ช่วยให้การดำเนินการเสร็จสิ้น มีแนวปฏิบัติที่ดีที่สุดสำหรับโครงสร้างการวิ่งอย่างใดอย่างหนึ่งเพื่อหลีกเลี่ยงปัญหาเหล่านี้หรือไม่? เคล็ดลับในการเจรจากับเจ้าของผลิตภัณฑ์?
8 agile  scrum 
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.