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

ตอนนี้ฉันกำลังจัดการทีมงานของนักพัฒนาประมาณ 15 คนและเราติดอยู่ที่จุดหนึ่งในการเลือกเทคโนโลยีซึ่งทีมถูกแบ่งออกเป็นสองทีมตรงข้ามกันโดยสิ้นเชิงโต้วาทีการใช้ WCF กับเว็บ API ทีม A ที่รองรับการใช้งาน Web API นำมาซึ่งเหตุผลเหล่านี้: Web API เป็นวิธีการบริการการเขียนที่ทันสมัย ​​( Wikipedia ) WCF เป็นโอเวอร์เฮดสำหรับ HTTP มันเป็นทางออกสำหรับ TCP และ Net Pipes และโปรโตคอลอื่น ๆ รุ่น WCF ไม่ใช่ POCO เนื่องจาก [DataContract] & [DataMember] และแอตทริบิวต์เหล่านั้น SOAP ไม่สามารถอ่านได้และมีประโยชน์เท่ากับ JSON SOAP เป็นค่าใช้จ่ายสำหรับเครือข่ายเมื่อเทียบกับ JSON (การส่งผ่าน HTTP) ไม่มีวิธีการมากไป ทีม B ที่รองรับการใช้ WCF …

49 wcf  decisions  web-api 

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

37 methodology  time-management  problem-solving  decisions 

ฉันมีเวลา 2 วันในการตัดสินใจอย่างจริงจังเกี่ยวกับเครื่องมือและแพลตฟอร์มที่ บริษัท ของฉันกำลังจะใช้เพื่อพอร์ตแอปพลิเคชัน WPF ไปยัง Linux / Android / iOS เห็นได้ชัดว่าฉันสามารถชี้ไปที่รุ่นพี่ของฉันว่า 2 วันนั้นแทบจะไม่เพียงพอสำหรับการอ่านเกี่ยวกับตัวเลือกที่เป็นไปได้ทั้งหมดและสิ่งที่เกี่ยวกับความพยายามทำต้นแบบเป็นต้นฉันสามารถบอกได้ว่ามันจะไม่ช่วยฉันสักหน่อย หลังจาก 2 วันจะมีการตัดสินใจ ระยะเวลา จากด้านหนึ่งที่ฉันรู้สึกท้อแท้จากอีกด้านฉันคิดว่ามีความจริงในวิธีนี้ไม่อย่างนั้นฉันสามารถหาตัวเองได้อย่างง่ายดายภายใต้ SDK ที่ดาวน์โหลดกรอบงาน APIs บล็อกบทความ ฯลฯ และอื่น ๆ และลืมในสิ่งที่มันมีไว้สำหรับ แต่ฉันก็ยังกลัวว่าการตัดสินใจที่ผิดจะทำให้ บริษัท เสียค่าใช้จ่าย คุณคิดว่าเป็นกระบวนการ "อุดมคติ" ในการตัดสินใจเช่นนี้หรือไม่?

36 development-process  time-management  decisions 

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

23 management  decisions  risk 

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

14 project-management  decisions 

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

12 design  project-management  requirements  decisions 

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

11 testing  refactoring  decisions  maintainability  scope 

ฉันกำลังเลือกระหว่างการออกแบบ / การแก้ปัญหาซอฟต์แวร์ที่ทำงานได้สองแบบ โซลูชันที่ 1 ใช้งานง่าย แต่จะล็อคข้อมูลบางอย่างในรูปแบบที่เป็นกรรมสิทธิ์และจะยากที่จะเปลี่ยนแปลงในภายหลัง โซลูชันที่ 2 นั้นยากที่จะนำไปใช้ แต่จะเปลี่ยนได้ง่ายขึ้นในภายหลัง ฉันควรจะไป YAGNI ในเรื่องนี้หรือฉันควรรวมต้นทุนการออกในการตัดสินใจ? หรือถามต่างกันค่าใช้จ่ายในการออกเป็นส่วนหนึ่งของ TCO หรือไม่ ฉันกำลังคิดว่าจะกลับไปหาลูกค้าด้วยสิ่งนี้เพื่อถามว่าเขาคิดว่าต้นทุนการออกมีความเกี่ยวข้องหรือไม่ แต่ฉันอยากจะรู้ว่าชุมชนคิดอย่างไรก่อน PS ต้นทุนการออกเป็นคำที่ถูกต้องหรือไม่

10 design  architecture  terminology  decisions