วิศวกรรมซอฟต์แวร์

ถาม - ตอบสำหรับมืออาชีพนักวิชาการและนักเรียนที่ทำงานในวงจรการพัฒนาระบบ

1
สิทธิ์ / รูปแบบ / รูปแบบที่ถูกต้องสำหรับ. NET application
ฉันจำเป็นต้องใช้ความยืดหยุ่นและเรียบง่าย (ถ้ามีอยู่) และในเวลาเดียวกันก็ใช้วิธีการที่เป็นไปได้ จนถึงตอนนี้ฉันได้นำ MembershipProvider และ RoleProviders มาใช้ นี่เจ๋ง แต่ฉันจะไปไหนต่อ ฉันรู้สึกว่าฉันต้องการเพิ่มคำว่า "Priviledge" และมากกว่า hardcode ที่อยู่ในแอปพลิเคชัน ผู้ใช้จะกำหนดค่าบทบาทเพื่อเพิ่มสิทธิ์ให้กับบทบาทและกำหนดบทบาทให้กับผู้ใช้ เสียงนั้นเป็นแบบอย่างที่ดีหรือไม่? ฉันควรคิดถึงการเพิ่มสิทธิพิเศษระดับผู้ใช้ด้านบนของการเพิ่มพวกเขาลงในบทบาทหรือไม่ ฉันอาจ แต่ฉันนึกภาพปัญหาเกี่ยวกับการตั้งค่า (ทำให้สับสน) และการติดตามต่อไป หากฉันไม่ทำเช่นนั้นและผู้ใช้บางรายจะต้องมีสิทธิ์น้อยกว่า - ผู้ดูแลระบบจะต้องสร้างบทบาทอื่นเป็นต้น กระสุนเงินสำหรับระบบเช่นนี้? และทำไม Microsoft ไม่ไปไกลกว่านี้เพียงแค่ผู้ให้บริการสมาชิกและบทบาท? ความคิดอื่น: ปล่อยให้บทบาทเป็นผู้ถือ "priviledge" และ hardcode พวกเขา จากนั้นฉันสามารถโค้ดไปยังบทบาทเหล่านั้นภายในแอปโดยใช้มาร์กอัพ / คุณลักษณะที่มีอยู่ทั้งหมด - Microsoft ทั้งหมด เพิ่มเอนทิตีใหม่ "กลุ่ม" และสร้างความสัมพันธ์เช่นนี้ ผู้ใช้ กลุ่มผู้ใช้ กลุ่ม RoleGroups บทบาท วิธีนี้ฉันสามารถรวบรวมบทบาทเป็นกลุ่มและกำหนดกลุ่มเหล่านั้นให้กับผู้ใช้ …

5
โดยทั่วไปเราควรใช้การทดสอบหน่วยการเขียนสำหรับคุณสมบัติใหม่หรือการแก้ไขข้อบกพร่อง?
เมื่อฉันต้องใช้คุณสมบัติใหม่หรือแก้ไขข้อบกพร่องฉันมักจะพยายามสร้างสถานการณ์ใหม่ด้วยการทดสอบ บางครั้งฉันใช้เวลาประมาณ 3 ชั่วโมงในการติดตั้งและเขียนข้อสอบ การใช้งานคุณสมบัติจริงหรือการแก้ไขข้อผิดพลาดใช้เวลาน้อยกว่า 1 ชั่วโมง มีใครอีกบ้างที่ใช้เวลาอย่างน้อย 3 ครั้งในการเขียนการทดสอบเปรียบเทียบกับการใช้งานคุณสมบัติจริงหรือแก้ไขข้อบกพร่อง อัตราส่วนที่ยอมรับได้ของเวลาที่ใช้ในการทดสอบการเขียนกับการเขียนโค้ดคืออะไร?

8
โปรแกรมเมอร์ส่วนตัวองค์กรพัฒนา [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน6 ปีที่ผ่านมา คุณใช้เครื่องมือ / วิธีการ / กลยุทธ์ใดเพื่อจัดระเบียบในการทำงานในฐานะนักพัฒนา คุณให้รายละเอียดได้ไหม

5
มันเป็นการดีหรือไม่ที่จะต้องใช้เครื่องหมายทับซ้ายสุดในชื่อไดเรกทอรี?
ฉันต้องการขอให้ผู้ใช้ของสคริปต์ทุบตีของฉันผ่านเส้นทางไดเรกทอรีเป็นอาร์กิวเมนต์ ข้อใดต่อไปนี้เป็นแบบฝึกหัดการเขียนโปรแกรมที่ดี? ต้องการให้ผู้ใช้ป้อน / (เครื่องหมายสแลช) ต้องการให้ผู้ใช้ไม่ได้ป้อน / ต่อท้าย (เครื่องหมายสแลช)

2
GUI, BLL, DAL Organization ในโครงการ
ฉันกำลังอ่านเกี่ยวกับเลเยอร์แอปพลิเคชันและต้องการใช้การออกแบบนี้ในโครงการถัดไปของฉัน (c #, .Net) บางคำถาม: การแยกเลเยอร์ทำได้ผ่านเนมสเปซหรือไม่ โครงการ. BLL. สิ่งที่โครงการ. Dal. สิ่งที่ มันเหมาะสมกว่าที่จะแยกโดยเลเยอร์แล้วส่วนประกอบ (Project.BLL.Component1) หรือโดยส่วนประกอบแล้วเลเยอร์ (Project.Component1.BLL) สำหรับ DAL ของฉันเลเยอร์นี้มีการจัดระเบียบเพิ่มเติมโดยใช้คลาสอื่นหรือไม่ ถ้าการเรียกฐานข้อมูลทั้งหมดถูกใส่ในคลาสเดียวก็จะไม่มีองค์กรใด มันจะดีกว่าไหมที่จะแยกมันออกเป็นคลาสหรือเนมสเปซที่ต่างกัน? คลาส DAL เป็นแบบสแตติกหรือไม่ ดูเหมือนว่ายุ่งยากในการยกตัวอย่างวัตถุ DAL ก่อนที่จะเรียกใช้หนึ่งในวิธีการในแต่ละครั้ง เคล็ดลับอื่น ๆ สำหรับการทำสิ่งต่าง ๆ ด้วยวิธีที่ถูกต้องกับเลเยอร์เหล่านี้จะได้รับการชื่นชม

3
วิธีการถ่ายโอนไฟล์ไปยังการผลิต?
เราเป็นกลุ่มที่เริ่มทำงานกับเว็บไซต์ที่มีขนาดใหญ่พอสมควรโดยมี codebase อยู่ เรามีการทดสอบและเซิร์ฟเวอร์การผลิต ความคิดของเราคือการมีพื้นที่เก็บข้อมูลทดสอบที่มีจำนวนของ devs ที่มีการเข้าถึงแบบพุช; และพื้นที่เก็บข้อมูลที่จำเริญที่มีเพียงไม่กี่คนที่สามารถผลักดันให้ repo ที่ได้รับพรควรจะมีความเสถียรอยู่เสมอและแสดงถึงเวอร์ชั่นการผลิตล่าสุด ฉันจะทำให้กระบวนการถ่ายโอนไฟล์ไปสู่การผลิตเป็นแบบอัตโนมัติได้อย่างไร มันจะไม่ดีที่จะมีไฟล์การผลิตภายใต้การควบคุมเวอร์ชัน? ด้วยวิธีดังกล่าวการผลักดันไปยังที่เก็บข้อมูลที่มีความสุขจะหมายถึงการปรับใช้ แต่จะเกิดอะไรขึ้นเมื่อมีการรวมความขัดแย้งกัน เซิร์ฟเวอร์ที่ใช้งานจริงจะหยุดจนกว่าจะได้รับการแก้ไขหรือไม่
9 git  workflows 

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

5
คุณสมบัติพื้นฐานสำหรับภาษาพื้นฐาน? ข้อเสนอแนะ DSL
ในที่สุดฉันก็เริ่มเข้าใจความซับซ้อนที่อยู่เบื้องหลังการสร้างล่ามและคอมไพเลอร์ ฉันสร้าง TinyBasic หลายรุ่นรุ่นพื้นฐานปี 1964 (ดาร์ทเมาท์) และการขยายภาษาของฉันเองก่อนที่จะถึงจุดนี้ โครงการล่าสุดคือโครงการที่ฉันเรียกว่าโอเพนซอร์ซพื้นฐาน ... เพราะฉันนึกไม่ออกว่าจะมีฟีเจอร์อื่น ๆ ของภาษาที่น่าสนใจสำหรับผู้คน เพื่อให้สามารถเปิดแหล่งที่มาของภาษาและเข้าใจวิธีการทำสิ่งที่ซับซ้อนบางอย่าง (การสแกนการแยกวิเคราะห์การแปลและการรวบรวม) Open Source Basic ถูกแปลเป็นภาษาสแต็กเป็นครั้งแรก ภาษาที่ใช้สแต็กนั้นจะถูกตีความและดำเนินการทันทีหรือเปลี่ยนเป็นปฏิบัติการ CLR คำถามของฉันทั้งหมดต้มลงไปที่นี้: อะไรคือคุณสมบัติพื้นฐาน / โครงสร้างของภาษาพื้นฐาน? ฉันมีโครงสร้างพื้นฐานเหล่านี้อยู่แล้ว: การมอบหมาย, นิพจน์, ตัวแปร, ฟังก์ชั่นบางอย่าง (สุ่ม, ToUpper, ToLower), วนรอบ (สำหรับและทำในขณะที่ / จนกว่า), ถ้า (บล็อกและบรรทัดเดียว) การตัดสินใจอื่น ) และเอาท์พุท (พิมพ์) และรูทีนย่อย (โดยไม่มีพารามิเตอร์) เมื่อฉัน 'เสร็จสิ้น' การเพิ่มโครงสร้างพื้นฐานในภาษาของฉัน - ฉันจะแยกออกได้อย่างไร เป็นโดเมนอะไร …

1
สิทธิ์การใช้งาน MSDN สามารถถ่ายโอนได้หรือไม่ ถ้าพวกเขาหมดอายุแล้วล่ะ
ฉันมีเพื่อนร่วมงานที่อาจจะลาออกจาก บริษัท ในไม่ช้า สมัครสมาชิก msdn (Premium ฉันเชื่อว่า) ซื้อให้เขา - แต่ฉันเชื่อว่ามันมากกว่า 1 ปีที่แล้ว ใบอนุญาตนี้สามารถถ่ายโอนให้ฉันเมื่อเขาออกจาก บริษัท หรือไม่
9 msdn 

2
พัฒนาอย่างมืออาชีพสำหรับ iOS, Android และเว็บ - ข้อมูลเชิงลึก
นี่ไม่ใช่คำถามเกี่ยวกับการพัฒนาทั้งสามฉันรู้วิธีข้ามแพลตฟอร์มที่หลากหลายและอื่น ๆ แต่ฉันอยากรู้เพิ่มเติมจากมุมมองของนักพัฒนาว่าการพัฒนา iOS, Android และเว็บแอพเป็นเรื่องยากแค่ไหน? ขณะนี้ฉันอยู่ในงานแรกของฉันในฐานะนักพัฒนามือถือ / เว็บ ฉันได้พัฒนาแอพ iPhone / iPad เครื่องแรกของฉันไปแล้วและตอนนี้ฉันต้องพัฒนาแอพสำหรับ Android เพราะเวอร์ชั่นเว็บที่ฉันพยายามทำได้ไม่ดีเท่าที่จำเป็นและฐานข้อมูลบนเว็บดูเหมือนจะไม่ได้ถูกตัดออก แต่ฉันไม่แน่ใจว่ามันเป็นไปได้ที่จะพัฒนาทั้ง 3 อย่างในแง่ของการจดจำ api ทั้งหมดและอื่น ๆ ฉันจะไม่พูดว่าฉันมีปัญหากับภาษาการเขียนโปรแกรมเพียงวิธีการใช้ api สำหรับแพลตฟอร์มที่หลากหลาย นอกจากนี้ภาษาอื่น ๆ ทั้งหมดที่ฉันดูในเวลาว่างของฉันเพียงแค่รู้สึกว่าฉันกำลังแพร่กระจายตัวเองให้ผอม เป็นไปได้หรือไม่ที่คน ๆ หนึ่งจะพัฒนา ios, android และ web apps? ฉันควรคิดถึงการลดให้เป็น iOS และแอพที่ทำงานบนเว็บหรือไม่ ฉันพัฒนาทุกอย่างด้วยตัวเองดังนั้นฉันจึงไม่มีใครพูดถึงทางออกที่ดีที่สุดสำหรับทุกสิ่งและฉันแค่พยายามออกกำลังกายตามที่ฉันไปด้วย ดังนั้นนักพัฒนาข้ามแพลตฟอร์มใด ๆ ออกมี? บริษัท มีทีมต่าง ๆ สำหรับแพลตฟอร์มที่แตกต่างกันหรือไม่? ข้อมูลเชิงลึกใด ๆ ที่จะช่วยให้ฉันได้รับหัวของฉันด้วยกัน …
9 android  web  mobile  ios 

2
การอ้างอิงการอ้างอิงที่สงบ - ​​การเชื่อมโยงความหมายกับ uri
เรากำลังออกแบบ RESTful API เพื่อเปิดข้อมูลบัญชีลูกค้าของเรา เรามีตัวแทนที่มีการอ้างอิงถึงทรัพยากรอื่น ๆ ที่เกี่ยวข้องกับทรัพยากรปัจจุบัน นี่เป็นวิธีปฏิบัติที่ดีที่สุดหลายประการที่เราพบได้ใน API สาธารณะและวัสดุที่เผยแพร่ การเป็นตัวแทนสามารถเป็น XML หรือ JSON ตัวอย่างเช่นสำหรับทรัพยากรบัญชีเราจะมีการอ้างอิงไปยังที่อยู่ของบัญชีและสำหรับรายการทรัพยากรที่มีเลขหน้าเราจะมีการอ้างอิงไปยังหน้าแรกหน้าถัดไปและหน้าก่อนหน้า API ได้รับการออกแบบครั้งแรกโดยใช้ลิงก์ความหมาย<link title="" rel="" href="" />ตามที่อธิบายไว้ในหนังสือ O'Reilly และใช้ใน APIs โดย Netflix และ Google เมื่อถึงเวลาสำหรับวิศวกรควบคุมคุณภาพของเราที่จะเขียนชุดระบบอัตโนมัติพวกเขามีปัญหาในการยกเลิกการเชื่อมโยง ตอนนี้เราได้แนะนำองค์ประกอบสตริง uri ที่เรียบง่ายซึ่งใช้ใน API โดย Facebook และ Twitter ผู้ชำนาญการควบคุมคุณภาพของเราได้แก้ไขปัญหา deserialization ของพวกเขาแล้ว แต่ฉันยังคงมีความกังวลเกี่ยวกับความง่ายในการใช้งานของข้อมูลจำเพาะ API ปัจจุบันที่มีการเชื่อมโยงความหมาย API ของเราส่วนใหญ่จะถูกใช้โดยลูกค้าของเราและพันธมิตรบุคคลที่สามบางส่วนและเราได้ไปที่ REST เนื่องจาก XML-RPC API ก่อนหน้านี้เป็นเรื่องยากสำหรับผู้บริโภคของเรา …
9 rest  semantics 

2
คลังเก็บ Mercurial ขนาดใหญ่ต้องทนทุกข์ทรมานจาก“ การแข่งขันแบบผลัก” หรือไม่?
อ่าน "ทำไม DVCS ถึงดีกว่า" ตอบคำถามหลายข้อเกี่ยวกับโปรแกรมเมอร์พวกเขาดูเหมือนจะบอกว่าโดยทั่วไปแล้ว DVCS จะดีกว่าเนื่องจากคุณไม่มีการแข่งขันในโครงการขนาดใหญ่ IE ยอมรับล้าสมัยดังนั้น อัปเดตส่งมอบล้าสมัยอีกครั้งส่งมอบยังคงล้าสมัยเป็นต้น DVCS จำกัด สิ่งนี้ด้วยแนวคิดของการผลักดัน อย่างไรก็ตามในโครงการขนาดใหญ่มากจะไม่มี "การแข่งขันแบบผลัก" โดยเฉพาะอย่างยิ่งในตอนท้ายของวัน? ฉันรู้ว่าใน Git สิ่งนี้ได้รับการแก้ไขโดยการแตกแขนงอย่างต่อเนื่องสำหรับทุกสิ่ง แต่ใน Mercurial คุณไม่ได้แยกคุณสร้างหัวใหม่ ปัญหาที่ฉันเห็น ผู้ใช้พยายามที่จะผลักดัน ล้าสมัย (mercurial จะไม่ยอมให้คุณผลักถ้า repo ในพื้นที่ของคุณล้าสมัย) ดังนั้นคุณจึงดึงและรวมการเปลี่ยนแปลงในท้องถิ่นของคุณ ผู้ใช้พยายามที่จะผลักดันอีกครั้ง แต่ในขณะที่พวกเขากำลังรวมคนอื่นผลักดังนั้นพวกเขาล้าสมัยอีกครั้ง ดึงแล้วผสานอีกครั้ง ยังล้าสมัย ทำซ้ำ ฟังดูคุ้น ๆ ไหม? นี่เป็นปัญหาที่เกิดขึ้นจริงกับ repos mercurial ขนาดใหญ่และเป็นที่นิยมหรือไม่? สิ่งที่เกี่ยวกับภายใน บริษัท เมื่อทุกคนผลักดันขั้นสุดท้ายของวัน
9 mercurial  dvcs 

3
การรวม jQuery ในปลั๊กอิน jQuery ตกลงหรือไม่
คำถามปลั๊กอินไฟล์ jQuery รวมถึงไลบรารี jQueryขึ้นมาในวันนี้ด้วย stackoverflow และฉันขอแนะนำอย่างยิ่งให้รวม jQuery ในปลั๊กอิน ฉันไม่ได้รับการสนับสนุนใด ๆ จากผู้อื่นในเรื่องนี้ ในความเป็นจริงมีการสนับสนุนให้รวม jQuery มากกว่าไม่ สิ่งนี้ใช้ได้หรือมีเหตุผลที่ดีที่จะไม่ทำเช่นนี้? ฉันคิดว่ามันเป็นความคิดที่ไม่ดีจริง ๆ เพราะฉันคิดว่ามันควรจะขึ้นอยู่กับนักพัฒนาที่ใช้ปลั๊กอินสำหรับรุ่น jQuery ที่ใช้งานอยู่
9 jquery  plugins 

7
ฉันสามารถใช้“ เรื่องราวของผู้ใช้” สำหรับงานปรับปรุงกระบวนการได้หรือไม่
ขณะนี้เราใช้ JIRA เพื่อติดตามงานพัฒนาของเรา ฝ่ายบริหารของฉันต้องการจัดรูปแบบและจัดหมวดหมู่ทุกอย่างเป็น "เรื่องราวของผู้ใช้" รวมถึงงานที่ไม่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์ ตัวอย่างเช่น: "ในฐานะผู้จัดการทดสอบฉันสามารถทำการทดสอบแอปพลิเคชันโดยใช้การทดสอบอัตโนมัติเท่านั้นและไม่มีการทดสอบด้วยตนเองเพื่อให้ฉันสามารถทดสอบแอปพลิเคชันได้อย่างมีประสิทธิภาพที่สุด เกณฑ์การยอมรับ: 1. แปลงการทดสอบด้วยตนเอง 50 รายการเป็นการทดสอบอัตโนมัติทั้งหมด 2. การทดสอบจะต้องดำเนินการในเวลาน้อยกว่า 1 ชั่วโมง " ฉันต้องการความรู้สึกจากชุมชนหากใช้ "เรื่องราวของผู้ใช้" สำหรับงานที่สนับสนุนกระบวนการพัฒนาซอฟต์แวร์ไม่ได้ทำโดยโปรแกรมเมอร์และไม่ส่งผลลัพธ์โดยตรงในรหัสที่ส่งมอบ หรือสิ่งนี้ควรจัดการ / จำแนกแตกต่างกัน (ตัวอย่างเช่นใน JIRA) หรือไม่ อัปเดตเมื่อวันที่ 6/7/2554 - คำถามที่นำมาใช้ใหม่เพื่อเน้นคำว่า "เรื่องราวของผู้ใช้"
9 agile  stories 

7
ควรกระจายความสามารถผ่านทีมอย่างไร
หลังจากอ่านบทความนี้ฉันเห็นว่าดูเหมือนจะมีความขัดแย้งมากมายเกี่ยวกับวิธีการจัดโครงสร้างทีมที่คล่องตัวภายในกลุ่มนักพัฒนาที่มีความสามารถที่แตกต่างกัน (aka เกือบทุกทีม) นักพัฒนาที่ดีที่สุดควรวางทีมของตัวเองและให้ความสำคัญสูงสุดหรือไม่ สิ่งนี้จะช่วยให้มั่นใจได้ว่างานที่สำคัญที่สุดจะเสร็จสิ้น ในเวลาเดียวกันคุณจะถูกทิ้งให้อยู่กับทีม "น้อยกว่าที่สมบูรณ์แบบ" ที่อื่นเพื่อจัดการหนี้สินทางเทคนิคแม้ว่าจะเป็นงานที่มีลำดับความสำคัญต่ำเท่านั้น ในอีกทางหนึ่งทีมที่มีการกระจายอย่างสม่ำเสมอจะได้รับประโยชน์จากการทำให้นักพัฒนาที่ล้าหลังของคุณดีขึ้นเล็กน้อย แต่มีศักยภาพที่จะลดระดับ Hitters ที่หนักที่สุดของคุณ นอกจากนี้หากคุณผสมลวดลายการออกแบบที่ดีกับการต่อต้านลวดลายที่น่ากลัวจำนวนมากคุณสามารถจบลงด้วยสิ่งที่อาจเป็นรูปแบบการต่อต้านแบบต่างๆ
9 agile  team  teamwork 

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