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

ฉันเป็น บริษัท เล็ก ๆ ที่ประกอบไปด้วยนักพัฒนาเพียง 2 คน เรากำลังสร้างแอปพลิเคชันขนาดใหญ่มากสำหรับลูกค้าของเรา การพัฒนาในโครงการนี้ดำเนินต่อไปเป็นเวลา 1.5 ปี ตอนนี้ลูกค้ารายนี้มีหลักประกันสปอนเซอร์ที่สำคัญและพวกเขากำลังจัดกิจกรรมที่เกี่ยวข้องกับโครงการนี้ ดังนั้นตอนนี้เรามีกำหนดส่งภายใน 2 เดือนและเราไม่ควรพลาด เรากำลังคิดที่จะเพิ่มนักพัฒนาใหม่ให้กับทีมและฉันสงสัยว่าเราสามารถทำอะไรได้บ้างเพื่อช่วยให้เขาทำงานร่วมกัน นี่คือสถานการณ์: เรากำลังเข้าใกล้เกณฑ์ของกฎหมายของ Brooks - จุดที่เพิ่มนักพัฒนาใหม่จะเป็นการต่อต้าน แอปพลิเคชันค่อนข้างออกแบบมาอย่างดี แต่การใช้งานนั้นไม่เป็นระเบียบในบางจุด (โดยเฉพาะโค้ดที่เก่ากว่า) มีการทดสอบหน่วยสำหรับรหัสล่าสุดเท่านั้น เมื่อโครงการนี้เริ่มต้นเราไม่ได้ทำการทดสอบเป็นประจำ เอกสารและความคิดเห็นไม่สมบูรณ์ แอปพลิเคชั่นมีทั้งขนาดใหญ่และซับซ้อน ลูกค้าเขียนรายละเอียดเกี่ยวกับโครงการของเขาเกือบทุกอย่างอย่างชัดเจนและ "เป็นมิตรกับโปรแกรมเมอร์" เป็นความคิดที่ดีที่จะเพิ่มคนตอนนี้หรือไม่? ถ้าเป็นเช่นนั้นเราจะทำอะไรได้บ้างเพื่อช่วยให้นักพัฒนาใหม่รวมเข้ากับทีม? แก้ไข: สปอนเซอร์กำลังจัดการแข่งขันกีฬาทางอินเทอร์เน็ตสำหรับฤดูใบไม้ผลิหน้า มันจะต้องเริ่มในวันที่เฉพาะเจาะจงของปี เราไม่สามารถเปลี่ยนได้ สิ่งที่นักพัฒนาของเรา (ฉันเป็นหนึ่งในสองคน) ต้องทำคือ: กรอกใบสมัครที่มีอยู่ให้เสร็จ (ประมาณ 25% ของงานที่ต้องทำ) การสร้างโมดูลใหม่ที่จำเป็นสำหรับองค์กรของเหตุการณ์นี้ (ประมาณ 75% ของงานที่ต้องทำ) โมดูลใหม่นี้ไม่สามารถพัฒนาโดยไม่เข้าใจ API ของโปรแกรมหลัก …

24 project-management  agile  teamwork  estimation  knowledge-transfer 

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

24 agile  requirements  government 

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

24 agile  qa 

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

24 testing  agile  tdd  bdd 

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการถกเถียงอภิปรายโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา ฉันจมน้ำในอีเมลของผู้ใช้และฉันต้องการใช้วิธีที่ดีกว่าในการจัดการคำขอเหล่านี้ทั้งหมดที่ฉันได้รับและทำให้พวกเขาอยู่ในคิวที่ซึ่งคนเหล่านั้นในทีมรวมทั้งผู้ใช้สามารถเข้าถึงพวกเขาได้ บันทึก ฉันกำลังคิดเกี่ยวกับเครื่องมือการจัดการงานที่จะอนุญาตให้สร้างงานหลายอย่างภายใต้โปรเจ็กต์ที่อีเมลความคิดเห็นแนวคิด ฯลฯ สามารถถูกดร็อป / ป้อนและเข้าถึงได้ง่าย ฉันต้องการบางสิ่งที่ทุกฝ่ายสามารถมีส่วนร่วมได้ - ผู้ใช้ผู้จัดการผู้นำทีมนักพัฒนา ฉันกำลังมองหาเครื่องมือที่สามารถอนุญาต: ผู้ใช้เพียงแค่ลาก / วางอีเมลเพื่อส่งคำขอการบำรุงรักษาหรือการปรับปรุง นักพัฒนาซอฟต์แวร์จะเห็นคิวและลำดับความสำคัญที่ถ่วงน้ำหนักของแต่ละงาน / โครงการ ทีมนักพัฒนาซอฟต์แวร์เพื่อดูว่าทุกคนทำงานในแบบเรียลไทม์ การจัดการเพื่อเก็บบันทึกเวลาที่ใช้ในแต่ละงาน ฉันเริ่มมองหาทิศทาง Agile / Scrum มากขึ้นเพื่อแก้ไขปัญหานี้ ผมพบว่ารายชื่อของการต่อสู้เปรียวซอฟต์แวร์การจัดการโครงการเครื่องมือมาเปิด เมื่อฉันถูก จำกัด ในเวลามีใครใช้สิ่งเหล่านี้หรือไม่ ฉันควรทดสอบอันไหนเพื่อดูว่ามันจะตอบสนองความต้องการของฉันหรือไม่? TeamPulseเป็นทิศทางที่ดี แต่คิดว่ามันค่อนข้างอ้วนเกินไป ฉันต้องการสิ่งที่ง่ายสำหรับทุกฝ่าย

24 project-management  agile  scrum  issue-tracking 

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

23 agile 

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

23 project-management  agile  scrum  user-story 

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

23 testing  agile  unit-testing  tdd 

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

23 agile  waterfall 

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

22 agile  scrum 

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

22 agile  team  code-ownership 

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

22 agile  testing  unit-testing  scrum  qa 

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

22 agile  development-process  frameworks  development-methodologies  iterative-development 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 6 ปีที่แล้ว ฉันได้พบกับความท้าทายนี้สองสามครั้งและฉันหวังว่าบางคนสามารถให้การอ้างอิงการฝึกอบรมหรือคำแนะนำเกี่ยวกับวิธีการอธิบายความแตกต่างระหว่างรายการที่ค้างสินค้ากับงานใน TFS ฉันเข้าใจและได้อธิบายว่ารายการสินค้าค้างคือ "อะไร" และภารกิจคือ "อย่างไร" ฉันได้อธิบายด้วยว่า PBI เป็นข้อกำหนดและภารกิจเป็นไปตามข้อกำหนด ฉันได้พบกับจ้องมองที่ว่างเปล่าและรอยขีดข่วนหัวบ่อยครั้งเมื่อฉันอธิบายสิ่งนี้ ดูเหมือนว่าวิศวกรซอฟต์แวร์ที่ฉันอธิบายเรื่องนี้จะไม่สามารถแยกความแตกต่าง มันเหมือนกันทั้งหมดสำหรับพวกเขา ฉันเชื่อว่าความท้าทายอื่น ๆ ของฉันคือฉันไม่สามารถอธิบายได้อย่างมีประสิทธิภาพว่าทำไมจึงเป็นสิ่งสำคัญที่จะทำให้ความแตกต่าง

22 team-foundation-server  scrum  agile 

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

22 agile  scrum  user-story