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

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

12 design  agile  specifications 

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

12 agile  code-reviews  pragmatism 

ที่ บริษัท ของฉัน (การเริ่มต้นอุตสาหกรรมเว็บอายุ 3 ปี) เรามีปัญหาบ่อยครั้งกับทีมผลิตภัณฑ์ที่พูดว่า "aaaah นี่คือการแก้ไขวิกฤติตอนนี้!" (ไม่ใช่ทุกคนเหรอ?) สิ่งนี้มีผลกระทบต่อความสามารถในการผลิต (และขวัญกำลังใจ) ของเจ้าหน้าที่วิศวกรรมรวมอยู่ด้วยตนเอง ฝ่ายบริหารใช้เวลาคิดเกี่ยวกับวิธีลดความถี่ของการร้องขอในวันเดียวกันและเกิดขึ้นกับวิธีแก้ปัญหาที่เรากำลังจะออกวางจำหน่ายทุกสัปดาห์ (ก่อนหน้านี้เราได้ทำทุกสองสัปดาห์ซึ่งโดยปกติจะลดลงภายในสองสามวันหรือมากกว่านั้น) มีผู้พัฒนา 13 คนและผู้ทดสอบนอกชายฝั่ง 6 คน / 9 คน ทฤษฎีคือนักพัฒนาเพียง 4 คน (และผู้ทดสอบทั้งหมด) จะทำงานในรุ่นที่มีเลขคู่เว้นเสียแต่ว่าจะมีชิ้นงานที่ต้องใช้ความเชี่ยวชาญเฉพาะจากนักพัฒนาอื่น ๆ แต่ละรอบจะมีงาน dev สองวันและงาน QA สองวัน (บวก 1 วันของการกำหนดขอบเขต / triage / ... ) คำถามของฉันคือ: (a) มีใครบ้างที่เคยมีประสบการณ์กับวงจรการเปิดตัวนี้หรือไม่? (b) มีใครเคยได้ยินเรื่องความยาวของรอบการเปิดตัวนี้ถึงแม้จะพยายามบ้างไหม? (c) ถ้า (a) …

12 agile  quality  release-management 

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

12 agile  scrum 

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

12 agile  version-control  development-process  branching  release-management 

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

12 agile 

ฉันอยู่ในทีมโปรเจคที่มี 4 devs ฉันรวมอยู่ด้วย เราได้มีการพูดคุยกันอย่างยาวนานเกี่ยวกับวิธีจัดการกับงานพิเศษที่เกิดขึ้นในรายการงานชิ้นเดียว งานพิเศษนี้มักจะเป็นสิ่งที่เกี่ยวข้องกับงานเล็กน้อย แต่ไม่จำเป็นเสมอไปที่จะบรรลุเป้าหมายของรายการ (อาจเป็นความเห็น) ตัวอย่างรวมถึง แต่ไม่ จำกัด เฉพาะ: refactoring ของรหัสการเปลี่ยนแปลงโดยรายการงาน refactoring code ที่อยู่ใกล้เคียงรหัสที่ถูกเปลี่ยนแปลงโดยรายการ ออกแบบพื้นที่โค้ดขนาดใหญ่รอบตั๋วอีกครั้ง ตัวอย่างเช่นหากรายการที่คุณเปลี่ยนฟังก์ชั่นเดียวคุณรู้ว่าตอนนี้ทั้งคลาสสามารถทำซ้ำได้เพื่อให้รองรับการเปลี่ยนแปลงนี้ได้ดียิ่งขึ้น ปรับปรุง UI บนแบบฟอร์มที่คุณเพิ่งแก้ไข เมื่องานพิเศษนี้เล็กเราไม่รังเกียจ ปัญหาคือเมื่องานพิเศษนี้ทำให้ส่วนขยายของรายการเกินกว่าการประมาณจุดคุณลักษณะดั้งเดิม บางครั้งรายการ 5 คะแนนจะใช้เวลา 13 คะแนน ในกรณีหนึ่งเรามีรายการ 13 จุดที่ในการหวนกลับอาจมี 80 คะแนนหรือมากกว่า ในการสนทนาของเรามีสองทางเลือกสำหรับวิธีจัดการกับปัญหานี้ เราสามารถรับงานพิเศษในรายการงานเดียวกันและเขียนออกเป็นการประเมินที่ผิดพลาด อาร์กิวเมนต์สำหรับสิ่งนี้ได้รวม: เราวางแผนสำหรับ "การเติมเต็ม" ในตอนท้ายของการวิ่งเพื่ออธิบายสิ่งนี้ ปล่อยให้รหัสอยู่ในรูปที่ดีกว่าที่คุณพบเสมอ อย่าเช็คอินงานครึ่งทาง หากเราออกจากการปรับโครงสร้างใหม่ในภายหลังมันยากที่จะกำหนดเวลาและอาจไม่เสร็จสิ้น คุณอยู่ใน "บริบท" ทางจิตใจที่ดีที่สุดในการจัดการงานนี้ในขณะนี้เนื่องจากคุณอยู่ลึกเข้าไปในรหัสแล้ว ดีกว่าที่จะนำมันออกไปให้พ้นทางและมีประสิทธิภาพมากกว่าที่จะเสียบริบทนั้นไปเมื่อคุณกลับมาในภายหลัง เราวาดเส้นสำหรับไอเท็มงานปัจจุบันและบอกว่างานพิเศษเข้าสู่ตั๋วแยกต่างหาก ข้อโต้แย้งรวมถึง: การมีตั๋วแยกต่างหากช่วยให้การประเมินใหม่ดังนั้นเราจึงไม่โกหกตัวเองเกี่ยวกับจำนวนของสิ่งที่เป็นจริงหรือต้องยอมรับว่าการประเมินทั้งหมดของเรานั้นแย่มาก …

12 agile  refactoring  estimation  sprint 

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

11 agile  estimation 

ทีมการต่อสู้ของเราประกอบด้วยบทบาทการต่อสู้ปกติ เราไม่มีผู้ออกแบบ 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 

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

11 programming-practices  agile  clean-code 

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

11 web-development  agile  project-management  scrum 

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

11 agile  tools 

ในกระบวนการพัฒนาแบบ Agile โดยปกติจะเน้นที่เรื่องของผู้ใช้ แต่บางครั้งความต้องการเดียวอาจครอบคลุมเรื่องราวของผู้ใช้หลายคน ตัวอย่างเช่นลูกค้าอาจขอหน้าค้นหาสำหรับผู้ใช้ทั้งหมดในฟอรัมและมีการดำเนินการหลายอย่างที่อาจเกิดขึ้นกับผู้ใช้แต่ละรายเช่นผู้ใช้แบนผู้ใช้ลบผู้ใช้รีเซ็ตรหัสผ่าน ฯลฯ เราอาจแบ่งคุณลักษณะนี้ออกเป็นเรื่องราวของผู้ใช้อย่างน้อย 4 เรื่อง: ค้นหาผู้ใช้ แบนผู้ใช้ ลบผู้ใช้ รีเซ็ตรหัสผ่าน ผู้ออกแบบส่วนต่อประสานผู้ใช้จะใช้ส่วนต่อประสานกับผู้ใช้ได้อย่างไร? เขา / เธอควรทำงานกับเรื่องราวของผู้ใช้คนแรกแล้วเริ่มเพิ่มคุณสมบัติเพิ่มเติมให้กับ UI หรือไม่ อย่างไรก็ตามฉันคิดว่า UI ขั้นสุดท้ายจะเลอะ! หากเขาตัดสินใจที่จะทำงานกับคุณลักษณะทั้งหมด (การค้นหา + การกระทำ) จะเกิดอะไรขึ้นถ้าการกระทำที่มีลำดับความสำคัญต่ำและจะต้องดำเนินการซ้ำหลายครั้งหลังจากฟังก์ชั่นการค้นหาเสร็จสิ้นแล้ว

11 web-development  agile  user-interface  user-story  user-experience