คำถามติดแท็ก development-process

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

9 agile  development-process 

ฉันสงสัยว่ามีการศึกษาใด ๆ ที่ตรวจสอบประสิทธิภาพของโครงการซอฟต์แวร์ในองค์กรที่มุ่งเน้น CMMI ตัวอย่างเช่นองค์กร CMMI มีแนวโน้มที่จะเสร็จสิ้นโครงการตามกำหนดเวลาและ / หรืองบประมาณมากกว่าองค์กรที่ไม่ใช่ CMMI หรือไม่ CMMI ย่อมาจาก "Capability Maturity Model Integration" พัฒนาโดยสถาบันวิศวกรรมซอฟต์แวร์ที่ Carnegie-Mellon University (SEI-CMU) มันไม่ใช่การรับรองแต่มีหลาย บริษัท ที่จะ "ประเมิน" องค์กรของคุณในระดับต่าง ๆ ของ CMMI เช่นระดับ 2 และระดับ 3 (ฉันเชื่อว่า CMMI ระดับ 1 เป็นสัตว์ที่มีความเชี่ยวชาญและไม่มีค่าใช้จ่ายใด ๆ ในคำอื่น ๆ ทุกคนเป็นอย่างน้อย CMMI ระดับ 1 แม้ว่าคุณไม่เคยได้ยิน CMMI มาก่อน) ฉันไม่ใช่ผู้เชี่ยวชาญ แต่ฉันเชื่อว่าองค์กรสามารถประเมินระดับ …

9 development-process  cmmi 

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

9 project-management  development-process  issue-tracking 

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

9 web-development  self-improvement  development-process  offshore 

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

9 design  development-process  coding  waterfall 

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา เรามีห้องสมุดรูปโค้งที่สวยงามที่สถานที่ทำงานของฉันและเราพัฒนาเว็บไซต์ที่กำหนดเองตามอัตราที่ดีจนกระทั่งตะกร้าสินค้ามาถึงเราเพื่อให้กระบวนการทำงานช้าลง ฉันใช้ตะกร้าสินค้าหลากหลาย ( Magento, Opencart, Zencart ) ในโครงการที่แตกต่างกันซึ่งเราต้องรวมเข้ากับแอปพลิเคชั่นหลักของเรา ความต้องการที่กำหนดเองโดยปกติมากทำให้รถเข็นช็อปปิ้งที่ไม่เลื่อนและใช้เวลามาก ฉันกำลังคิดที่จะสร้างตะกร้าสินค้าของเราเอง ( ค่อนข้างธรรมดาในปัจจุบันและเราจะขยายออกไปเมื่อเราดำเนินการต่อ ) ตั้งแต่เริ่มต้นเพื่อให้สามารถปรับเปลี่ยนข้อกำหนดที่กำหนดเองได้อย่างง่ายดาย มันคุ้มค่าที่จะทำ? อัปเดต 24 ส.ค. - 11 ก.ย. ฉันพัฒนาตะกร้าสินค้าของเราอย่างต่อเนื่อง นี่คือประสบการณ์ของฉันที่ฉันต้องการแบ่งปันกับพวกคุณ ประโยชน์ที่ได้รับ รถเข็นใหม่ง่ายต่อการเปลี่ยนแปลงและขยาย มันช่วยประหยัดเวลาเมื่อเรามีข้อกำหนดที่คลุมเครือหรือกำหนดเองและทำให้เราสามารถนำเข้าโมดูลจากไลบรารีรหัสที่มีอยู่ของเราโดยตรง ไม่จำเป็นต้องมีการใช้เทมเพลตคู่สำหรับรถเข็นและเว็บไซต์กำหนด แผงผู้ดูแลระบบเดียวสำหรับตะกร้าสินค้าและเว็บไซต์ที่กำหนดเองของเรา ข้อ จำกัด ยังไม่โตพอที่จะซื้อเกวียนอื่น ๆ ในตลาด ความกังวลด้านความปลอดภัย เราส่วนใหญ่พึ่งพาความปลอดภัยของ CakePHP ขาดฟังก์ชั่น ประสบปัญหา การพัฒนาเกตเวย์การจัดส่ง / การชำระเงินเป็นความเจ็บปวดที่แท้จริง ในฐานะที่เป็น@davidhaskinsชี้ให้เห็น …

9 productivity  programming-practices  development-process  cakephp 

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

9 web-development  project-management  development-process  workflows 

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

9 development-process  cross-platform