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

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

47 agile  development-methodologies  waterfall 

เป็นไปได้ที่จะเรียกตัวเองอย่างถูกต้อง (หรือทีมของคุณ) "ว่องไว" ถ้าคุณไม่ทำ TDD (การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ)?

45 agile  tdd 

ในฐานะนักพัฒนาเดี่ยวฉันคิดว่าฉันใช้กระบวนการที่คล้ายกับ Agile แต่ฉันต้องการเปรียบเทียบสิ่งที่ฉันทำกับ Agile จริงและดูว่าฉันสามารถปรับปรุงกระบวนการของตัวเองได้หรือไม่ มีหนังสือที่มีมาตรฐาน de-พฤตินัยสำหรับการอธิบายวิธีปฏิบัติที่ดีที่สุดวิธีการและข้อมูลที่เป็นประโยชน์อื่น ๆ เกี่ยวกับ Agile? หนังสือเล่มไหนที่ทำให้มันพิเศษ?

45 agile  books 

Scrum Master ของเรายังคงอ้างถึงข้อบกพร่องเป็นหนี้ทางเทคนิค เขาคิดถูกไหมข้อบกพร่องถือเป็นหนี้ทางเทคนิคในโลกของ Agile หรือไม่?

44 agile  technical-debt 

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

44 agile  programming-practices  waterfall 

ฉันถูกถามโดยองค์กรสาธารณะเพื่อให้การประชุมเชิงปฏิบัติการอย่างไม่เป็นทางการเกี่ยวกับ 101 ของการพัฒนาความคล่องตัวอธิบายคำศัพท์และแนวคิดของ Scrum, Kanban และสิ่งที่คล้ายกัน ตอนนี้ฉันทำงานในสภาพแวดล้อมที่คล่องแคล่วมาประมาณห้าปีแล้ว แต่ฉันไม่คิดว่าฉันเป็นผู้เผยแพร่ศาสนา Scrum หลังจากการประชุมเชิงปฏิบัติการพวกเขาชอบความคิด อย่างไรก็ตามพวกเขาอธิบายว่าวิธีการอาจไม่สามารถใช้ได้กับพวกเขาเนื่องจากพวกเขาต้องการว่าจ้าง บริษัท ซอฟต์แวร์ภายนอกเพื่อพัฒนาซอฟต์แวร์สำหรับพวกเขา (พวกเขามีนักพัฒนาเพียงไม่กี่คนเท่านั้น) กิจกรรมนี้ต้องดำเนินการในกระบวนการประกวดราคาสาธารณะที่อธิบายผลลัพธ์ราคาและกรอบเวลา นี่เป็นข้อกำหนดทางกฎหมายในการใช้งบประมาณสำหรับองค์กรนี้ (สถาบันการวิจัยสาธารณะ) ข้อ จำกัด เหล่านี้ดูเหมือนจะขัดแย้งกับหลักการพื้นฐานของการพัฒนาที่คล่องตัวใช่ไหม? การแย่งชิงกันเพียงในสภาพแวดล้อมดังกล่าวหรือไม่? คุณอยากแนะนำอะไรกับองค์กรนี้

43 agile  project-management  scrum  government 

เพิ่งได้รับการโทรย้อนยุคที่นักพัฒนาแสดงความกังวลเกี่ยวกับการบูรณาการเรื่องราวของพวกเขาในสาขาหลักแต่ละการวิ่ง นักพัฒนารหัสทั้งหมดภายในสาขาของตัวเองและในตอนท้ายของการวิ่งพวกเขาทั้งหมดรวมเป็นหนึ่งสาขาหลัก จากนั้นผู้พัฒนารายหนึ่ง (โดยปกติจะเป็นคนเดียวกัน) จะเหลือหน้าที่ในการทำให้แน่ใจว่าทุกอย่างได้รวมเข้ากับโค้ดของ dev อื่น ๆ (การเปลี่ยนแปลงส่วนใหญ่อยู่ในหน้าเดียวกันตัวอย่างเช่นเรื่องการแสดงข้อมูลเรื่องราวการกรองข้อมูลและ ตัวบ่งชี้ SLA) เราจะลดภาระนี้และทำให้รหัสของเรารวมเข้าด้วยกันได้ง่ายขึ้นได้อย่างไร จากมุมมองของฉันการมี PO หรือ SM จัดลำดับความสำคัญของเรื่องราวด้วยวิธีที่มีประสิทธิภาพมากขึ้นดังนั้นเราจึงไม่มีการพึ่งพาเหล่านี้ในการวิ่งเดียวกันอาจช่วยแก้ปัญหาบางอย่างได้ คนอื่นจะรับมือกับเรื่องนี้อย่างไร หรือนี่เป็นเพียงส่วนหนึ่งของกระบวนการ?

42 agile  scrum  branching  stories 

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

42 design  architecture  agile  scrum  team-leader 

ฉันเคยได้ยินการปีนป่ายที่กล่าวถึงในบริบทของ Agile หรือ Extreme Programming ดูเหมือนจะเป็นส่วนเสริมในการจับคู่ มันคืออะไรกันแน่? ควรใช้เมื่อใด คุณทำได้ดีแค่ไหน?

42 agile  terminology 

มีการจำแนกที่ชัดเจน แต่ง่ายและเข้าใจได้ของความแตกต่างระหว่าง "use case", "User Story" และ "ฉากการใช้งาน" หรือไม่? มีคำอธิบายมากมาย แต่ตอนนี้ฉันไม่เห็นใครอธิบายความแตกต่างในประโยคเดียวหรือสอง ... (เช่นhttp://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparisonนานและยากที่จะได้รับเต็มไปด้วยการอภิปราย)

42 agile  object-oriented 

หนึ่งในหลักการก่อตั้งของการประกาศเปรียวคือ กระบวนการที่คล่องตัวส่งเสริมการพัฒนาที่ยั่งยืน ผู้สนับสนุนนักพัฒนาและผู้ใช้ควรจะสามารถรักษาอัตราการคงที่อย่างต่อเนื่อง ทีมการต่อสู้ใช้คำว่าsprintเพื่ออ้างถึงวัฏจักรการทำงาน (หรือเรียกอีกอย่างว่าการวนซ้ำ) อย่างไรก็ตามสิ่งนี้ไม่สมเหตุสมผลสำหรับฉัน ตามการวิ่งของ Google คือ: วิ่งด้วยความเร็วเต็มพิกัดในระยะทางสั้น ๆ มันไม่ยั่งยืน ทำไมทีมต่อสู้ใช้คำว่าวิ่ง ? ฉันรู้สึกขัดแย้งกับหนึ่งในหลักการพื้นฐานของ Agile

41 agile  terminology  scrum 

ฉันเป็นแฟนตัวยงของการพัฒนาที่คล่องตัวและใช้ XP ในโครงการที่ประสบความสำเร็จอย่างมากไม่กี่ปีที่ผ่านมา ฉันรักทุกอย่างเกี่ยวกับมันแนวทางการพัฒนาแบบวนซ้ำเขียนโค้ดเกี่ยวกับการทดสอบการเขียนโปรแกรมคู่การมีลูกค้าบนไซต์เพื่อดำเนินการต่างๆ มันเป็นสภาพแวดล้อมการทำงานที่มีประสิทธิผลสูงและฉันไม่เคยรู้สึกเหมือนถูกกดดัน อย่างไรก็ตามสถานที่ไม่กี่แห่งสุดท้ายที่ฉันใช้ Scrum ใช้แล้วใช้งานได้ ฉันรู้ว่ามันเป็นเด็กโปสเตอร์เพื่อการพัฒนาที่คล่องตัว แต่ฉันไม่เชื่อ 100% ว่าเป็นคนคล่องแคล่ว ด้านล่างนี้เป็นสาเหตุหลักสองข้อที่ทำให้ฉันไม่รู้สึกว่องไว ผู้จัดการโครงการรักมัน ผู้จัดการโครงการผู้ซึ่งหลงไหลตามกำหนดเวลาของพวกเขาดูเหมือนจะรักสกัล จากประสบการณ์ของฉันพวกเขาดูเหมือนจะใช้ Sprint Backlog เป็นเครื่องมือในการติดตามความต้องการของเวลาและเก็บบันทึกจำนวนเวลาที่ใช้ไปกับภารกิจที่กำหนด แทนที่จะใช้ไวท์บอร์ดพวกเขาทั้งหมดใช้แผ่น excel ซึ่งนักพัฒนาแต่ละคนจะต้องกรอกอย่างเคร่งครัด ในความคิดของฉันนี่เป็นวิธีการติดตามเอกสาร / เวลามากเกินไปสำหรับกระบวนการที่คล่องตัว เหตุใดฉันจึงต้องเสียเวลาในการประเมินว่างานจะใช้เวลานานแค่ไหนเมื่อฉันสามารถทำได้ด้วยตัวเอง หรือในทำนองเดียวกันว่าทำไมฉันถึงต้องเสียเวลาในการจัดทำเอกสารว่าต้องใช้เวลานานแค่ไหนเมื่อฉันสามารถย้ายไปยังงานต่อไปได้ การประชุมที่ยอดเยี่ยม การประชุมที่โดดเด่นในสถานที่ก่อนหน้านี้ที่ฉันทำงานนั้นเป็นฝันร้าย ทุกวันเราต้องอธิบายสิ่งที่เราทำเมื่อวานนี้และสิ่งที่เราจะทำในวันนั้น ถ้าเราไปในเวลา "ประเมิน" ของเราสำหรับงานผู้จัดการโครงการจะเตะเหม็นและอ้างอิง Sprint Backlog เป็นวิธีการแสดงความสามารถที่คุณไม่ได้ปฏิบัติตามระยะเวลา ตอนนี้ฉันเข้าใจความต้องการในการสื่อสาร แต่แน่นอนว่าการประชุมประจำวันควรมีความเบิกบานใจและมุ่งเน้นไปที่การแบ่งปันความรู้ ฉันไม่คิดว่ามันจะกลายเป็นสไตล์การทำการบ้านของคุณ แน่นอนว่าจุดของความคล่องตัวก็คือไทม์ไลน์เปลี่ยนไปพวกเขาไม่ควรถูกวางไว้ในหิน ข้อสรุป แนวคิดของความคล่องตัวคือการทำให้ซอฟต์แวร์ดีขึ้นโดยทำให้นักพัฒนาซอฟต์แวร์มีชีวิตที่ง่าย ดังนั้นในความคิดของฉันกระบวนการใด ๆ เปรียวที่ใช้โดยทีมงานควรเป็นผู้นำ ฉันไม่คิดว่าการมีผู้จัดการโครงการใช้กระบวนการที่พวกเขาระบุว่า "เปรียว" เพื่อติดตามโครงการมีส่วนเกี่ยวข้องกับการพัฒนาที่คล่องตัว คิดว่าทุกคน?

41 agile  scrum 

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

40 agile  scrum  scrum-master 

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

40 agile  scrum  meetings  development-methodologies 

เราเริ่มใช้ Story Points ที่นี่เพื่อการพัฒนาแบบ Agile ของเรา แต่ฉันคิดว่ามันยากที่จะอธิบายและไม่สามารถหาคำตอบที่ชัดเจนสำหรับสิ่งที่พวกเขาเป็น สิ่งที่ดีที่สุดที่ฉันสามารถทำได้คือชี้ไปที่เว็บไซต์อื่น ๆ (เช่นhttp://blog.mountaingoatsoftware.com/tag/story-points ) และให้ลักษณะทั่วไปที่คลุมเครือของสิ่งที่พวกเขาเป็น ฉันกำลังมองหาคำอธิบายที่ดีพร้อมตัวอย่างการใช้งานที่จะเป็นประโยชน์สำหรับผู้อื่นในการใช้งาน มีแหล่งข้อมูลที่ดีสำหรับการอธิบายประเด็นหรือไม่?

36 agile  estimation  planning