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

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

17 project-management  agile  management  project  scrum 

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

17 agile  scrum  embedded-systems 

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

16 agile  product-owner 

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

16 agile  feature-requests  product-backlog 

Wikipedia บอกว่า Agile เป็น "RAD" ประเภทหนึ่งซึ่งฉันเดาว่าไม่ถูกต้อง จากสิ่งที่ฉันรู้ Agile ได้รับการพัฒนาเนื่องจาก RAD เองนั้นไม่เพียงพอใน 90'S (เข้มงวดเกินไปสำหรับการเปลี่ยนแปลง) หรือฉันผิด (หมายเหตุ: เห็นได้ชัดว่าบทความ Wikipedia เกี่ยวกับการพัฒนาซอฟต์แวร์ Agileได้รับการปรับปรุงในระหว่างนั้นเพียงแค่ระบุว่าRADเป็นผู้บุกเบิกของ Agile ไม่ใช่เป็น superset) การอ้างอิงจากหนังสือ Radical Project Management (Thomsett) ".. แฟชั่นใหม่ของการพัฒนาเช่น RAD, Agile, Object oriented ... " ผู้สอบบัญชีระบบข้อมูลรับรอง CISA: .. ตระหนักถึงซอฟต์แวร์ตัวเลือกสองตัว วิธีการ: การพัฒนาแอพพลิเคชั่นที่คล่องตัวและรวดเร็ว การจัดการแบบว่องไวสำหรับซอฟต์แวร์: วิธีการแบบว่องไวส่วนใหญ่มาจากวิธี RAD ที่มีน้ำหนักเบา แนวทางปฏิบัติที่ดีที่สุดในการประเมินซอฟต์แวร์: วิธีการหลักของ sw dev สามารถสรุปได้ดังนี้: …

16 agile  development-process  rad 

จากประสบการณ์ของคุณการประชุม Sprint Planning ควรจะนานเท่าไร 8 ชั่วโมง? หรือควรสั้นลง (กระชับ) และควรมีการวางแผนการสนทนาเพิ่มเติมในฐานะส่วนหนึ่งของการวิ่ง Sprints ของเรามีความยาว 10 วัน

16 agile  scrum  planning 

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

16 agile  testing  unit-testing  tdd  sdlc 

พิจารณา บริษัท ที่ได้รับการรับรองอย่างภาคภูมิใจสำหรับวิธีการที่ไม่ใช่แบบ Agile ใช้เป็นจุดขายให้กับลูกค้าเพื่อแสดงความรับผิดชอบ คุณจะไปเกี่ยวกับวิธีการแนะนำ Kanban หรือการแย่งชิงกันมีความก้าวหน้าโดยไม่ทำลายทั้งระบบของพวกเขาและยังคงทำให้พวกเขามีความมั่นใจว่ามันยังคงสามารถเช่นเดียวกับความรับผิดชอบ / ตรวจสอบ ? ฉันรู้ว่าสิ่งนี้อาจเกี่ยวข้องกับ " คุณจะแนะนำวิธีการแบบเปรียวเช่น Scrum " ได้อย่างไร แต่ที่นี่ฉันสงสัยว่าจะหลีกเลี่ยง / หลีกเลี่ยงความจริงที่ว่า บริษัท กำหนดวิธีการจัดการ SDLC ภายใต้ข้ออ้างที่ผิด ๆ วิธีเดียวที่จะมีหลักฐานการตรวจสอบ

16 project-management  agile  development-process  sdlc 

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

16 project-management  agile 

นักวิเคราะห์ธุรกิจและหัวหน้าโครงการของเราบอกเราถึงความต้องการของลูกค้าในเรื่อง การวางแผน Sprint ทุกครั้งเรา (ผู้พัฒนา) จะถูกขอให้เล่นการวางแผนโป๊กเกอร์ พวกเขาขอให้พวกเราทุกคนพิจารณา 'ความซับซ้อน' มากกว่า 'ความพยายาม' เราสับสนจริง ๆ และเรากำลังเสียเวลาในการประชุม นักพัฒนาคนหนึ่งตั้งคำถามว่า 'เราควรพิจารณาอะไรจริง ๆ มันเกี่ยวกับการเปลี่ยนรหัส / DDL ที่เราต้องทำในข้อกำหนดนี้ (ประมาณเวลา) หรือว่าเราเข้าใจข้อกำหนดหรือไม่? ' แต่พวกเขา (นักวิเคราะห์ธุรกิจและผู้นำโครงการ) หมายถึงอะไรโดย 'เข้าใจข้อกำหนด' และ 'ยกบัตร' นอกจากนี้เรายังมีการประชุมย่อยสำหรับทีมการต่อสู้แต่ละทีมซึ่งนักพัฒนาแต่ละคนจะให้เวลาโดยประมาณสำหรับงานที่กำหนดสำหรับแต่ละทีมการต่อสู้ ดังนั้นสิ่งที่พวกเขาพูดถึงในการวางแผนโป๊กเกอร์จริง ๆ ? ใครสามารถอธิบายสิ่งนี้โดยใช้ตัวอย่าง? พยายามแยกแยะสิ่งที่พวกเขาพูดถึงจริงๆเมื่อพวกเขาพูดว่า 'ความซับซ้อน' และ 'ความพยายาม'

15 agile  scrum  planning 

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

15 agile  scrum 

ฉันชอบ XP (การเขียนโปรแกรมขั้นสูง) โดยเฉพาะอย่างยิ่งส่วนที่มีโปรแกรมเมอร์ 2 คนที่หน้าจอเดียวกันเนื่องจากวิธีแก้ปัญหามักจะพบได้เร็วขึ้นหากคุณเพียงอธิบายว่าคุณกำลังทำอะไรและจับคู่การเขียนโปรแกรมบังคับให้คุณอธิบายสิ่งที่คุณ การทำ ในช่วง 10 ปีที่ผ่านมารูปแบบการทำงานของ XP ดูเหมือนจะล้าสมัยไปแล้วเนื่องจากวิธีการทำงาน: Agile และ / หรือ Kanban ทำไม? ตั้งแต่ XP ดูเหมือนว่าฉันจะเป็นวิธีที่ดีมากในการทำงานและเป็นจำนวนมากเกี่ยวกับการเขียนโปรแกรมในขณะที่ Agile และ Kanban เป็นมากกว่าเกี่ยวกับกระบวนการ

15 agile  extreme-programming  kanban 

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

15 design  agile 

ปัจจุบันฉันทำงานร่วมกับอาจารย์ที่มหาวิทยาลัยของฉันเพื่อพัฒนาหลักสูตรใหม่สำหรับหลักสูตรวิศวกรรมซอฟต์แวร์และการออกแบบ Capstone ที่เปิดสอนในวิทยาลัยของฉัน จนกระทั่งเมื่อไม่นานมานี้ทั้งสองหลักสูตรใช้โมเดลน้ำตกโดยเฉพาะและทำให้นักเรียนใช้เวลาส่วนใหญ่ในการเขียนรายงานยาว ๆ หลังจากแรงกดดันจากฉันมากอาจารย์ของฉันตัดสินใจที่จะรวม Scrum ในหลักสูตรวิศวกรรมซอฟต์แวร์ภาคการศึกษาที่ผ่านมานี้ ครึ่งแรกของภาคการศึกษายังคงเป็นน้ำตกมีนักเรียนเขียนรายงานการออกแบบ 40 หน้าและเอกสารข้อกำหนดซอฟต์แวร์ กลางภาคเรียนทุกทีมจะต้องปล่อยตัวอย่างของแอปพลิเคชัน เมื่อถึงจุดนั้นเส้นทางก็เปลี่ยนไปเป็น Scrum พร้อมกับการวิ่ง 3 สัปดาห์สองครั้ง ตอนนี้เรากำลังพยายามหาวิธีกำจัดน้ำตกทั้งหมดและสร้างหลักสูตรที่ใช้การแย่งชิงกันโดยเฉพาะ น่าเสียดายที่เราพบความไม่ลงรอยกันระหว่าง Scrum และนักเรียน: การประชุมการต่อสู้รายวันแทบเป็นไปไม่ได้สำหรับนักเรียน แม้ในระหว่างชั้นเรียนมันไม่สะดวกสำหรับนักเรียนที่จะจัดการประชุม Scrum เนื่องจากอาจารย์มักจะบรรยาย การประมาณคะแนน / ชั่วโมงนั้นยากเนื่องจากนักเรียนไม่มีประสบการณ์ดังนั้นจึงไม่สามารถทำนายได้อย่างแม่นยำว่าจะต้องใช้เวลานานแค่ไหน การต่อสู้ทำงานได้ดีที่สุดกับนักพัฒนาแบบเต็มเวลาที่ทำงานร่วมกัน แต่นักเรียนไม่ใช่ ส่วนใหญ่นักเรียนใช้เวลา 15-20 ชั่วโมงต่อสัปดาห์ในการจัดหลักสูตรและการจัดงานประชุมอาจเป็นเรื่องยากมาก ทีมสามารถมีนักเรียนได้มากถึง 10 คน (และจะมีคนขี้เกียจหนึ่งหรือสองคน) อาจารย์ต้องการเอกสาร! ฉันไม่เคยได้ยินรายงานการแย่งชิงใด ๆ - เพียงแบ็คล็อกและชาร์ตการเผาไหม้ (ซึ่งฉันไม่แน่ใจว่าจะเพียงพอที่จะเอาใจนักวิชาการ) นักเรียนมักคิดว่าเปรียวหมายถึง "กระโดดเข้าและเริ่มเขียนโค้ดโดยไม่หันกลับมามอง" สิ่งนี้นำไปสู่โค้ดที่น่ากลัวที่สุดที่จินตนาการได้ ดังนั้นฉันกำลังมองหาวิธีในการบังคับใช้การออกแบบที่เหมาะสมโดยไม่ต้องใช้เอกสาร 50 หน้าหรือกองของไดอะแกรม UML …

15 agile  scrum  documentation 

ข้อเสียเปรียบที่ใหญ่ที่สุดของการพัฒนาแบบเปรียวที่ฉันเคยพบคือคนที่ไม่ได้มีส่วนร่วมในการพัฒนามุ่งเน้นไปที่มนต์ที่เรื่องราวของผู้ใช้ (3-10 วันในอุดมคติของคน) ไม่ควรมีมากกว่า 1-3 ประโยคเช่น: ในฐานะลูกค้าฉันสามารถใช้การค้นหาข้อความอิสระเพื่อหาผลิตภัณฑ์ที่ฉันกำลังมองหา ให้ประโยคนี้ผู้จัดการโครงการคาดหวังว่าฉันในฐานะนักพัฒนาเพื่อมอบความไว้วางใจในการประเมินและพัฒนาเรื่องราว พวกเขาคิดว่าการพัฒนาที่คล่องตัวหมายถึงประโยคเช่นนี้คือทั้งหมดที่พวกเขาต้องจัดหาให้นักพัฒนา ฉันจะไม่โทษพวกเขาเพราะวรรณกรรมที่รู้จักกันดีเกี่ยวกับการพัฒนาที่คล่องตัวสร้างความประทับใจว่าสิ่งนี้จะได้ผลจริง ฉันได้อ่านบางอย่างเช่น 2 หน้าในภาษาธรรมชาติต่อเรื่องใน "Planning XP" แต่นั่นคือ เนื่องจาก "ซอฟต์แวร์ที่ใช้ในการทำงาน" ได้รับการสนับสนุนมากกว่า "เอกสารที่ครอบคลุม" หัวข้อนี้จึงดูเหมือนจะหลีกเลี่ยงโดยทั่วไป แน่นอนว่าในความเป็นจริงแล้วหากผู้พัฒนาได้รับโอกาสให้ทำเช่นนั้นการสัมภาษณ์กับลูกค้าจะนำเสนอรายการข้อกำหนดจำนวนมากที่ลูกค้ามีเกี่ยวกับเรื่องราว: เราต้องการตัวดำเนินการบูลีนเช่น AND และ OR เราต้องการคำทั้งหมดคลุมเครือ เราจำเป็นต้องค้นหาด้วยคำเดียวเช่นเดียวกับวลี เราไม่ต้องการค้นหาผลิตภัณฑ์ที่ตรงตามเกณฑ์ X, Y และ Z เราต้องการเรียงลำดับผลลัพธ์ ผู้ใช้สามารถเลือกเกณฑ์การเรียงในกล่องคำสั่งผสมพร้อมตัวเลือก a, b และ c ดังนั้นคุณจะเห็นว่าฉันไม่ได้พูดถึงรายละเอียดทางเทคนิคหรือการออกแบบซอฟต์แวร์หรือแม้แต่รายละเอียดการใช้งาน มันเป็นข้อกำหนดที่บริสุทธิ์ ยิ่งเราคุยกันนานเท่าไหร่ลูกค้าก็ยิ่งตระหนักว่ามีอะไรมากมายที่จะพูดเกี่ยวกับสิ่งที่พวกเขาต้องการ แต่บ่อยครั้งที่ฉันพบว่าตัวเองอยู่ในสถานการณ์ที่ข้อมูลดังกล่าวไม่ได้รับการจัดเตรียมไว้ให้ เป็นไปได้หรือไม่ที่ฉันจะทำการสัมภาษณ์และบุคคลที่จะอยู่ในตำแหน่งที่จะทำการสัมภาษณ์ไม่ได้ให้ผลลัพธ์กับฉัน บางครั้งผู้จัดการอาจหารายละเอียดทางเทคนิคเช่น "เราต้องการค้นหา Lucene" แต่พวกเขาไม่ต้องการคิดว่าพวกเขาต้องการค้นหาเฉพาะชื่อผลิตภัณฑ์หรือคำอธิบายผลิตภัณฑ์ บางครั้งฉันคิดว่าพวกเขาขี้เกียจ;) สำหรับฉันนี่เป็นปัญหาอันดับต้น …

15 agile  requirements