คำถามติดแท็ก project-management

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

15 project-management  git  workflows  forking 

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

15 web-development  project-management  agile  development-process  management 

ในกระบวนการ Agile ของเราเรามี Sprints 2 สัปดาห์ งานจะถูกส่งเป็นรายวัน (งานสร้างรายวัน) และทีมทดสอบจะทำการทดสอบเสร็จในวันถัดไปหรือในวันเดียวกัน นอกจากนี้เรายังมีบทวิจารณ์รหัส Dev ซึ่งต้องใช้เวลา (1-2 ชั่วโมง) ดังนั้นจึงมีกำหนด 3 ครั้งต่อสัปดาห์: จันทร์ - ศุกร์ นักพัฒนามารวมกันและแนะนำวิธีปรับปรุง / สร้างรหัสใหม่ ปัญหาของเราคือเมื่อรายการการดำเนินการเกิดขึ้นหลังจากการตรวจสอบโค้ดงานส่วนใหญ่ได้รับการทดสอบแล้ว ผู้ทดสอบไม่ต้องการทดสอบสิ่งที่ผ่านการทดสอบแล้ว พวกเขาไม่สนใจเกี่ยวกับการเปลี่ยนแปลง dev ภายใน เราเข้าใจผิดเกี่ยวกับกระบวนการเปรียวหรือไม่? การตรวจสอบโค้ดไม่เข้ากันกับรอบการเปิดตัว / ทดสอบรายวันหรือไม่ เราไม่สามารถตรวจสอบโค้ดได้ทุกวันเนื่องจากใช้เวลาของทุกคน

14 project-management  agile  teamwork  code-reviews  sdlc 

ที่ บริษัท ที่ฉันทำงานอยู่ตอนนี้เราก็เริ่มทำโครงการสrum ไม่ยากนักที่จะโน้มน้าวให้ผู้จัดการย้ายจากน้ำตกไปยังสrum เรากำลังทำโครงการที่เราสร้างแพลตฟอร์มขึ้นใหม่จากศูนย์ ดังนั้นฟังก์ชั่น (ส่วนใหญ่) จึงเป็นที่รู้จักและการปรับปรุงส่วนใหญ่ค่อนข้างใช้เทคนิค ในเรื่องนี้มันอาจเป็นเหตุผลที่จะมีงานด้านเทคนิคมากกว่าเรื่องราวของผู้ใช้ งานในมือของเรามีงานด้านเทคนิคทุกประเภทเช่น: เขียนคลาส DB ใหม่จาก MySQL เป็น PostgreSQL ใช้การบันทึกระบบ เขียนแคชวัตถุใหม่ สิ่งต่าง ๆ ที่เกิดขึ้นระหว่างการยืนรวมถึงความต้องการ "งานวิจัย" ที่ยาวนาน แต่พวกเขาไม่เคยทำ นอกจากนี้สมาชิกในทีมเรียกร้องในช่วงกลางของการวิ่งที่ต้องเพิ่มงานที่ไม่ได้วางแผนไว้ Scrum Master ควรจัดการกับสิ่งนี้อย่างไร เป็นไปได้ไหมว่าสำหรับโครงการประเภทนี้การแย่งชิงกันไม่ใช่ทางที่จะไป?

14 project-management  scrum  user-story  product-backlog 

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

14 project-management  programming-practices  team  project  legacy-code 

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

14 project-management  software  knowledge-transfer 

ในโครงการที่มีข้อกำหนดที่ไม่สามารถใช้งานได้ซึ่งระบุเวลาดำเนินการสูงสุดสำหรับการดำเนินการที่เฉพาะเจาะจง QA จะต้องตรวจสอบประสิทธิภาพของการกระทำนี้บนเครื่องเฉพาะโดยใช้ฮาร์ดแวร์ที่แม่นยำภายใต้ภาระที่แม่นยำทั้งฮาร์ดแวร์และโหลดที่ระบุไว้ในข้อกำหนด ในทางกลับกันการเปลี่ยนแปลงซอร์สโค้ดที่ผิดพลาดบางอย่างอาจส่งผลกระทบอย่างรุนแรงต่อประสิทธิภาพ สังเกตเห็นผลกระทบเชิงลบนี้ในช่วงต้น , ก่อนรหัสที่มาถึงการควบคุมแหล่งที่มาและได้รับการยืนยันโดยแผนก QA, อาจจะเป็นประโยชน์ในแง่ของเวลาที่หายไปโดยแผนก QA รายงานปัญหาและโดยนักพัฒนาแก้ไขมันหลายกระทำในภายหลัง หากต้องการทำสิ่งนี้เป็นความคิดที่ดี: ในการใช้การทดสอบหน่วยเพื่อให้ทราบถึงเวลาที่ใช้ในการดำเนินการแอ็คชั่นเดียวกัน² nครั้ง หากต้องการใช้การหมดเวลาทดสอบต่อหนึ่งครั้งผ่าน[TestMethod, Timeout(200)]แอตทริบิวต์ใน C # ฉันคาดว่าจะมีปัญหาหลายอย่างเกี่ยวกับวิธีการนี้: ตามหลักการแล้วการทดสอบหน่วยไม่ได้สำหรับสิ่งนั้นจริง ๆ พวกเขาคาดหวังว่าจะทดสอบโค้ดเพียงส่วนเล็ก ๆ ไม่มีอะไรเพิ่มเติม: ทั้งการตรวจสอบข้อกำหนดการใช้งานหรือการทดสอบการรวมเข้าด้วยกันหรือการทดสอบประสิทธิภาพ การทดสอบหน่วยหมดเวลาใน Visual Studio วัดจริง ๆ ว่าจะวัดได้หรือไม่โดยคำนึงถึงว่าการเตรียมใช้งานและการล้างข้อมูลนั้นไม่มีอยู่สำหรับการทดสอบเหล่านั้นหรือสั้นเกินไปที่จะส่งผลกระทบต่อผลลัพธ์หรือไม่ การวัดประสิทธิภาพด้วยวิธีนี้น่าเกลียด การใช้เบนช์มาร์กบนเครื่องใด ๆ โดยไม่ขึ้นกับฮาร์ดแวร์โหลด ฯลฯ ก็เหมือนกับการทำเบนช์มาร์กที่แสดงว่าผลิตภัณฑ์ฐานข้อมูลหนึ่งจะเร็วกว่าผลิตภัณฑ์อื่นเสมอ บนมืออื่น ๆ ที่ผมไม่ได้คาดหวังว่าผู้ทดสอบหน่วยที่จะเป็นผลที่ชัดเจนหรือสิ่งที่ถูกใช้โดยแผนก QA การทดสอบหน่วยเหล่านั้นจะถูกนำมาใช้เพียงเพื่อให้ความคิดทั่วไปเกี่ยวกับประสิทธิภาพที่คาดหวังและเป็นหลักในการแจ้งเตือนนักพัฒนาว่าการปรับเปลี่ยนครั้งสุดท้ายของเขายากจนบางสิ่งบางอย่างอย่างรุนแรงส่งผลกระทบต่อประสิทธิภาพการทำงาน การทดสอบการพัฒนาแบบขับเคลื่อน (TDD)เป็นไปไม่ได้สำหรับการทดสอบ ในตอนแรกมันจะล้มเหลวอย่างไรก่อนที่จะเริ่มใช้โค้ด การทดสอบประสิทธิภาพมากเกินไปจะส่งผลต่อเวลาที่ต้องใช้ในการทดสอบดังนั้นวิธีนี้ จำกัด เฉพาะการกระทำสั้น ๆ เท่านั้น …

14 project-management  unit-testing  performance  requirements 

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

14 project-management  refactoring 

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

14 project-management  internship  legacy 

เราเริ่มใช้ Agile / Scrum ในทีมนักพัฒนา 4 คน เราทำการประมาณค่าเรื่องราวของเราและสั่งซื้อเรื่องราว Primed ในการค้างสินค้า เราเริ่มต้นด้วยการประมาณตามจุดบนความซับซ้อนจาก 1 ถึง 5 แทนที่จะเป็นปกติ 1,2,3,5,8,13 .... และอื่น ๆ หลังจากทำงานสองสามเรื่องเรารู้สึกว่าบางเรื่องที่ประเมินที่ 4 จุดควรเป็น 2 เท่านั้นในขณะที่อีกเรื่องที่ประมาณ 2 มีความซับซ้อนมากขึ้นและควรได้รับการประเมินเป็น 5 ฉันต้องการ ทราบ: ตกลงไหมที่จะเปลี่ยนการประมาณเรื่องราวของเราในระหว่างการทำซ้ำ? มันโอเคไหมที่จะใช้คะแนนการประเมินปัจจุบันจาก 1 ถึง 5 แทนที่จะเป็นปกติ 1,2,3,5,8,13 .... และอื่น ๆ แม้ว่าโดยส่วนตัวแล้วฉันรู้สึกว่ามันไม่ควรจะเป็นสำหรับทั้งสองกรณี แต่ฉันต้องสำรองตัวเองเพราะความเข้าใจของตัวเองยังไม่ชัดเจน (วัสดุอ้างอิงที่ดีจะดีมาก!)

14 project-management  agile  estimation 

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

14 project-management  client-relations 

ปัญหาที่ฉันกำลังเผชิญ: สมาชิกในทีมของฉันเริ่มทำงานในโครงการที่ไม่มีเอกสารการทำงาน / เทคนิคพร้อมแม้ว่ากระบวนการของ บริษัท ของเราจะกำหนดสิ่งเหล่านี้ก่อนที่จะเริ่ม สมาชิกในทีมของฉันยอมรับราคาถูก, การแก้ปัญหาที่ไม่มีโครงสร้างและจะดำเนินการจริงๆแฮ็กที่ไม่ดีเป็นซอฟต์แวร์โดยไม่ต้องคิดสองครั้งเมื่อบันทึกการบริหารจัดการโครงการที่พวกเขามี 'เวลา จำกัด' สมาชิกในทีมของฉันเริ่มทำงานในโครงการที่ทำงานร่วมกับโครงการที่ยังไม่เสร็จจากทีมอื่นซึ่งยังไม่ได้ทดสอบและยังไม่เสร็จ (ก่อให้เกิดงานพิเศษมากมาย) การปรับปรุงและขั้นตอนทั้งหมดของซอฟต์แวร์ไม่ได้รับการวางแผนอย่างเหมาะสมและมักส่งผลให้ front-end / design ไม่เสร็จสิ้นเมื่อผู้พัฒนา back-end ต้องเริ่มทำงาน ปัญหาเหล่านี้ได้รับการพูดถึงอย่างไม่รู้จบมาหลายครั้งแล้วตั้งแต่ฉันเริ่มทำงานที่นี่ ทุกคนเห็นด้วยและข้อสรุปก็คือเราต้องบังคับใช้กระบวนการซึ่งหมายความว่านักพัฒนาส่วนหลังจะไม่เริ่มจนกว่าทุกอย่างจะได้รับการดูแล ปัญหาเหล่านี้ยังคงเกิดขึ้น - และฉันได้รับแรงจูงใจจริงๆจนถึงจุดที่ฉันรำคาญกับการทำงานของตัวเองและเพื่อนร่วมงานของฉัน สมาชิกในทีมของฉันบ่นมาก - แต่ต่อกันเท่านั้น They keep on going - whatever the situation is. ผลลัพธ์? ฉันเติบโตไม่มั่นคงบางทีฉันเอง นี่เป็นสิ่งที่ควรจะเป็นใช่ไหม คำถามของฉัน? How can I say no against work ignoring the process …

14 project-management  teamwork 

ฉันแนะนำ Mercurial กับแผนกของฉัน ฉันรักมัน แต่มันเป็นประสบการณ์การควบคุมเวอร์ชันแรกของฉัน ฉันใช้กับ NetBeans PHP เพื่อการพัฒนาเว็บ นักพัฒนาอื่นที่ทำงานกับแอปพลิเคชันภายใน บริษัท ชอบใช้ Visual Source Safe และไม่ต้องการเปลี่ยน เขาทำงานในสภาพแวดล้อม Visual Studio ผู้พัฒนารายอื่นทั้งหมดได้ซื้อเข้าสู่ Mercurial ยกเว้นอันนี้ ส่วนใหญ่เราทำงานค่อนข้างอิสระ ฉันกำลังพยายามย้ายแผนกนี้ไปในทิศทางที่ถูกต้องฉันได้ตั้งค่าทุกคนด้วยบัญชีใน Kiln ฉันหวังว่าจะให้ทุกคนใช้ Fogbugz ตามถนนด้วย (เนื่องจากปัจจุบันยังไม่มีฐานข้อมูลบั๊กที่ถูกดูแล) ไม่เคยใช้ VSS แต่ฉันได้ยินสิ่งเลวร้ายมากเกี่ยวกับเรื่องนี้ จะดีกว่าไหมถ้าให้เขาใช้ VSS ต่อไปถ้านั่นคือสิ่งที่เขาต้องการหรือจะเป็นประโยชน์กับเขามากที่สุดถ้าได้ Mercurial?

14 project-management  version-control  team  visual-studio  mercurial 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา ในฐานะที่เป็นHaskell Wiki ระบุว่า : มีไลบรารี GUI จำนวนมากสำหรับ Haskell น่าเสียดายที่ไม่มีมาตรฐานใด ๆ เลยและทั้งหมดนั้นไม่สมบูรณ์ไม่มากก็น้อย โดยทั่วไปแล้วแผ่นไม้อัดระดับต่ำจะทำได้ดี แต่ก็มีระดับต่ำ abstractions ระดับสูงเป็นการทดลองที่ค่อนข้างดี ไม่จำเป็นต้องมีไลบรารี GUI ระดับกลางที่รองรับ อาจารย์ที่วิทยาลัยของฉันขอให้ฉันและวิชาเอกวิทยาการคอมพิวเตอร์อีกสามคนพิจารณาที่จะทำงานในห้องสมุด GUI สำหรับ Haskell ความคิดเริ่มต้นของเขาสำหรับโครงการคือการเขียนเลเยอร์บน OpenGL ที่เลียนแบบมอร์ฟิคไลบรารีที่พบใน Smalltalk ; อย่างไรก็ตามนี่เป็นเพียงข้อเสนอแนะและระบบอื่น ๆ ก็เป็นสิ่งที่ควรค่าแก่การพิจารณา นี่นำเราไปสู่คำถามที่เกิดขึ้นจริงและมีหลายส่วน ห้องสมุดของเรามุ่งมั่นในระดับใด Haskell Wiki ดูเหมือนจะบ่งบอกอย่างชัดเจนว่าต้องการ GUI ไลบรารีระดับกลาง อย่างไรก็ตามยินดีต้อนรับสู่ห้องสมุดระดับสูง ห้องสมุดของเราควรสร้างอะไร …

14 project-management  gui  haskell  project-structure  opengl 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ทีมงานของเรากำลังคิดที่จะทำ "Project In A Week" (bootcamp) และฉันสนใจที่จะรู้ว่าถ้าใครมีประสบการณ์ในการทำเช่นนี้หรือมีคำแนะนำใด ๆ ? แนวคิดเบื้องหลังคือการหลีกหนีจากสิ่งรบกวนของสำนักงานกระตุ้นซึ่งกันและกันและสร้างความผูกพันในทีมเพื่อสร้างผลิตภัณฑ์ที่เป็นนวัตกรรมและสร้างผลกำไรภายในระยะเวลาอันสั้น แผนการนี้จะทำให้ทีม dev ทั้งหมด (ประมาณ 5 devs), นักออกแบบ, ผู้จัดการโครงการ, พนักงานขายและการตลาดสองคนพักในศูนย์การประชุม / โรงแรมในช่วงสัปดาห์ทำงาน เราจะมุ่งเน้นอย่างสมบูรณ์ในการสร้างแอปพลิเคชันเว็บหนึ่งรายการ (วางแผนล่วงหน้า) และเผยแพร่สดและในตลาดภายในหนึ่งสัปดาห์ เราจะทำงานได้นานหลายวัน แต่ในตอนเย็นเราจะได้สนุกด้วยกันเป็นทีม จะมีสมาชิกของทีมสองคนที่เหลืออยู่ในสำนักงานเพื่อให้แน่ใจว่าเราจะไม่เสียสมาธิในการสนับสนุนลูกค้าแบบวันต่อวัน วิธีการ 'ดื่มด่ำ' ที่คล้ายกันนั้นใช้โดย บริษัท ฝึกอบรมเช่น Firebrand ความคิดที่ดี? ความคิดแย่ ๆ เราควรทำอย่างไรเพื่อสร้างแรงจูงใจให้ทีม? ความคิด / ประสบการณ์ / คำแนะนำใด ๆ …

14 project-management  project  motivation  teamwork  team-building