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

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

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

8
จะทำอย่างไรกับ“ การพัฒนาที่ล้มเหลว”
ที่ร้านของเราเรามุ่งมั่นที่จะคล่องตัว และฉันจะบอกว่าเรากำลังก้าวหน้าอย่างมาก ที่กล่าวว่าเราสองสามคนได้เห็นรูปแบบที่เราได้เริ่มเรียกว่า "การพัฒนาที่ขับเคลื่อนด้วยความล้มเหลว" การพัฒนาที่ขับเคลื่อนด้วยความล้มเหลวนั้นสามารถถูกปลดปล่อยออกมาเป็นวงจรปล่อย / วนซ้ำแบบเปรียวซึ่งข้อบกพร่อง / คุณสมบัติไม่ได้ถูกชี้นำโดยงานและเรื่องราวที่มีเกณฑ์การยอมรับ แต่มีข้อบกพร่องที่ป้อนในซอฟต์แวร์ติดตามข้อบกพร่อง ทีมงานของเรามีผู้จัดการโครงการที่ยอดเยี่ยมที่มุ่งมั่นที่จะได้รับเกณฑ์การยอมรับจากลูกค้า แต่ไม่สามารถทำได้ จากเก้าอี้การพัฒนาของฉันนี่เป็นเพราะลูกค้าไม่ทราบว่าสิ่งที่พวกเขาต้องการหรือ (และนี่คือนักเตะ) สอง "ค่าย" ที่แตกต่างกันที่สำนักงานใหญ่ของลูกค้าขัดแย้งกับเรื่องที่ควรนำมาใช้ แคมป์คับจะบอกว่าผลงานสารคดี X เช่นนี้แล้วค่าย B จะล้มเหลวเนื่องจากไม่สามารถทำงานได้เหมือนที่ ดังนั้นคำว่า "FDD" กระบวนการนี้ขับเคลื่อนด้วย "ความล้มเหลว" สิ่งนี้นำไปสู่คำถามของฉัน: มีใครพบกับสิ่งนี้อีกหรือไม่และหากเป็นเช่นนั้น แน่นอนว่าเราได้พยายามให้ Camp A และ B ยอมรับก่อน แต่ทุกคนรู้ว่านี่ไม่ใช่กรณี ขอบคุณ

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

6
เปรียวโดยไม่ต้องทดสอบหน่วย
มันสมเหตุสมผลหรือไม่ที่จะพูดถึง "การพัฒนาที่คล่องตัว" หรืออ้างว่าคุณกำลังใช้ "วิธีการที่คล่องตัว" ถ้ารหัสฐานที่คุณกำลังทำงานอยู่มีการครอบคลุมการทดสอบหน่วย 0% (และคุณในฐานะทีมไม่ได้ทำอะไรเกี่ยวกับเรื่องนี้) เพื่อให้ชัดเจน: สำหรับฉันมันไม่สมเหตุสมผล จากประสบการณ์ส่วนตัวของฉันฉันพบว่าการทดสอบหน่วยเป็นเครื่องมือเดียวที่ช่วยให้คุณ "คล่องแคล่ว" (เช่นตอบสนองต่อการเปลี่ยนแปลงปรับปรุงการออกแบบของคุณแบ่งปันความรู้ ฯลฯ ) และ TDD เป็นวิธีปฏิบัติเดียวที่จะพาคุณไปที่นั่น . อาจมีวิธีอื่นบ้าง แต่ฉันก็ยังไม่เห็นว่าพวกเขาจะทำงานได้อย่างไร


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


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

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

4
ความแตกต่างระหว่างเรื่องราวของผู้ใช้กับฟีเจอร์ต่าง ๆ คืออะไร?
คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 8 ปีที่แล้ว เล่นกับicescrumฉันรู้ว่าฉันไม่เข้าใจความแตกต่างระหว่างเรื่องราวของผู้ใช้และคุณลักษณะของผู้ใช้ มีคนอธิบายความแตกต่างได้ไหม
25 agile  scrum  features 

12
Agile บังคับให้นักพัฒนาใช้เวลาทำงานจริงหรือไม่?
เมื่อดูที่การปฏิบัติทั่วไปของ Agile ดูเหมือนว่าฉัน (โดยเจตนาหรือไม่ตั้งใจ?) บังคับให้นักพัฒนาใช้เวลาทำงานจริงมากกว่าที่จะอ่านบล็อก / บทความการสนทนาการพักดื่มกาแฟและการผัดวันประกันพรุ่งธรรมดา โดยเฉพาะอย่างยิ่ง: 1) การเขียนโปรแกรมคู่ - ผู้ทำงานที่ใหญ่ที่สุดเพียงเพราะมันไม่สะดวกที่จะทำทุกสิ่งที่ผัดวันประกันพรุ่งเมื่อคุณสองคนนั่งด้วยกัน 2) เรื่องสั้น - เมื่อคุณมีงานจำนวนมากที่ต้องทำเช่นหนึ่งเดือนมันเป็นเรื่องธรรมดาที่จะหย่อนในช่วงสามสัปดาห์แรกและเปลี่ยนไปใช้โหมด OMG DEADLINE สำหรับช่วงสุดท้าย และด้วยชิ้นเล็ก ๆ (ที่ต้องทำในหนึ่งวันหรือน้อยกว่า) มันเป็นสิ่งที่ตรงกันข้าม - คุณรู้สึกว่าเวลานั้นแน่นไม่มีที่ว่างสำหรับการซ้อมรบและคุณจะต้องรับผิดชอบงานนี้ในไม่ช้าดังนั้นคุณจึงเริ่ม ทำงานได้ทันที 3) การสื่อสารและการทำงานร่วมกันเป็นทีม - เมื่อคุณมีประสิทธิภาพต่ำกว่าในสภาพแวดล้อมที่ห่างไกลและเงียบสงบมันอาจจะโอเค แต่เมื่อสิ้นสุดการประชุมที่การต่อสู้กับทุกคนที่ได้ทำและคุณไม่มีอะไรจะพูดว่าคุณอาจรู้สึก ละอายใจ 4) การทดสอบและข้อเสนอแนะ - อีกครั้งจะป้องกันไม่ให้คุณทำงาน "พร้อม 99%" (เมื่อจริงประมาณ 20%) จนกว่าจะถึงกำหนดเส้นตาย คุณรู้สึกว่าภายใต้ Agile คุณทำงานมากกว่าภายใต้วิธีการ "ธรรมดา" หรือไม่? ความกดดันนี้ถูกชดเชยโดยสภาพแวดล้อมที่สะดวกสบายมากขึ้นและความรู้สึกของการได้สิ่งที่ถูกต้องทำได้อย่างรวดเร็วจริงหรือ
25 agile 

5
การทดสอบเป็นส่วนที่จำเป็นของระเบียบวิธี Agile หรือไม่?
ฉันอยู่กับหลายทีมที่พยายามฝึกวิธีการแบบ Agile และบ่อยครั้งที่ทีมเหล่านี้เป็นศูนย์กลางการทดสอบ การทดสอบเป็นส่วนที่จำเป็นในการฝึกวิธีการ Agile หรือเป็นเพียงการฝึกหัด XP ที่ได้รับการฝึกฝนมาหลายปีหรือไม่?

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

1
อนาธิปไตยนักพัฒนาคืออะไร
ฉันได้อ่านเกี่ยวกับผู้พัฒนา (หรือโปรแกรมเมอร์) อนาธิปไตยซึ่งดูเหมือนว่าจะเรียกเก็บเงินเป็นวิธีการพัฒนาโพสต์เปรียว ฉันพบทรัพยากรน้อย ( 1 , 2 ) แต่ดูเหมือนจะไม่ค่อยมีอะไรมากมาย ฉันสงสัยว่าใครมีทรัพยากรที่ดีที่ฉันสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับมัน _ วิธีการใช้มันข้อดีข้อเสียเปรียบเทียบกับวิธีการอื่น ๆ เป็นต้น

4
ไม่สามารถเข้าใจถึงจุดหนึ่งในหลักการของ Agile Manifesto
ผมอ่านเปรียวหลักการ ทุกอย่างดูเหมือนชัดเจนและสมเหตุสมผลยกเว้นเพียงจุดเดียว: ความเรียบง่าย - ศิลปะของการเพิ่มปริมาณงานที่ไม่ได้ทำเป็นสิ่งจำเป็น ฉันไม่เข้าใจสิ่งนี้ นี่หมายความว่างานที่ไม่ได้ทำควรจะพูดเกินจริงหรือไม่? ถ้าเป็นเช่นนั้นก็ไม่ได้ทำให้รู้สึกจริง
24 agile  management 

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