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

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

40 project-management  time-management 

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

38 project-management  teamwork  team 

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

37 project-management  estimation  project 

เมื่อฉันเริ่มโครงการใหม่ฉันมักจะเริ่มคิดเกี่ยวกับรายละเอียดของการดำเนินการทันที "ฉันจะวาง DataBaseHandler ไว้ที่ไหนฉันควรใช้มันอย่างไรคลาสที่ต้องการใช้มันขยายจาก Abstractclass superclass บางส่วน .. ฉันควรใช้อินเทอร์เฟซหรือไม่ฉันจะใช้อินเทอร์เฟซในระดับใด วิธีในการส่งคำขอและการแยกวิเคราะห์ข้อมูล " ฉันสิ้นสุดการถ่วงเวลานานเพราะฉันต้องการรหัสสำหรับความสามารถในการขยายและการนำกลับมาใช้ใหม่ แต่ฉันรู้สึกว่าแทบจะเป็นไปไม่ได้เลยที่จะคิดถึงอดีตเกี่ยวกับวิธีการนำไปใช้อย่างสมบูรณ์ แล้วถ้าฉันพยายามจะพูดว่า "ขันมันให้เสร็จแล้ว!" ฉันก็ชนกำแพงอิฐอย่างรวดเร็วเพราะรหัสของฉันไม่ได้จัดระเบียบฉันผสมระดับนามธรรมต่าง ๆ เป็นต้น คุณมีเทคนิค / วิธีการอะไรบ้างในการเปิดตัวโครงการใหม่ในขณะที่ตั้งค่าโครงสร้างแบบลอจิคัล / แบบแยกส่วนที่จะขยายได้ดี - -แก้ไข - - นี่เป็นประเภทของคำถามที่ตอบรับยากแล้ว แต่ต้องการได้รับคำติชมเพิ่มเติมดูว่ามีฉันทามติบ้างไหม TDD ฟังดูเจ๋งจริงๆและตรงไปตรงมาฉันหมายถึงการเพิ่มความเร็วในการใช้ JUnit ฯลฯ ในเวลาเดียวกันแฟน ๆ ของ TDD คิดอย่างไรเกี่ยวกับความจริงที่ว่าจุดที่ถูกต้องตามกฎหมายที่เกี่ยวข้องกับการแก้ไข TDD ของฉัน ปัญหาเฉพาะคือ TDD ไม่ได้ตอบคำถามการออกแบบ แน่นอนว่าฉันเห็นด้วยกับ TDD จะช่วยฉันกำหนดสิ่งที่ฉันต้องการจะทำและจากนั้นฉันสามารถค่อยๆทำตามวิธีได้ แต่มีรูปแบบ / โครงสร้างการออกแบบโดยรวมที่แตกต่างกันมากมายที่ทุกคนสามารถผ่านการทดสอบหน่วยได้ นั่นเป็นเพียงแค่มันทดสอบหน่วยเดียว …

37 project-management  design-patterns  code-quality  paradigms  code-reuse 

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

36 project-management 

จากมุมมองระดับสูงมากสำหรับฉันดูเหมือนว่ามีเครื่องมือการจัดการโครงการ 2 ประเภท: ตัวติดตามปัญหาแบบดั้งเดิมเช่น Fogbugz, JIRA, BugZilla, Trac, Redmine เป็นต้น บอร์ดเสมือนจริง / เครื่องมือการจัดการโครงการที่คล่องตัวเช่น Pivotal Tracker, GreenHopper, AgileZen, Trello เป็นต้น แน่นอนว่าพวกเขาทับซ้อนกันไม่ทางใดก็ทางหนึ่งเช่นงาน Pivotal Tracker สามารถนำเข้าสู่ JIRA ได้ GreenHopper นั้นถูกนำไปใช้กับฐานปัญหา JIRA เป็นต้น แต่ฉันคิดว่ายังคงเห็นความแตกต่างของการวางแนวระหว่างเครื่องมือทั้งสองประเภทนี้ ดูเหมือนว่าปัญหาการติดตามแบบดั้งเดิมจะถูกนำมาใช้แม้ใน บริษัท อื่น ๆ ที่ดำเนินการจัดการโครงการแบบว่องไว คำถามของฉันคือทำไมพวกเขาทำอย่างนั้น? ฉันรู้สึกว่าเราควรใช้ตัวติดตามปัญหาใน บริษัท ของฉันด้วย แต่เมื่อฉันคิดถึงมันฉันไม่แน่ใจว่าทำไมเราถึงต้องการมัน ตัวอย่างเช่นการพัฒนา Trello ดูเหมือนว่าจะได้รับการจัดการโดยใช้ Trello เอง (ดูกำแพงเสมือนจริง ) แม้ว่าพวกเขาจะสามารถเข้าถึง Fogbugz ซึ่งเป็นหนึ่งในตัวติดตามปัญหาที่ดีที่สุด …

35 project-management  issue-tracking  kanban 

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

34 project-management  project 

ใน บริษัท ของเราเราต้องทำสิ่งที่ดูเหมือนไม่ซับซ้อนหลายอย่างเช่นพัฒนา UI มือถือ สมมติว่าโปรแกรมเมอร์ผู้มีประสบการณ์ต้องเสียค่าใช้จ่าย 4x เท่าผู้เริ่มต้น โดยพื้นฐานแล้วทั้งคู่สามารถทำสิ่งที่ดูเหมือนง่ายให้เสร็จภายในเวลาเท่ากัน ความแตกต่างคือโปรแกรมเมอร์ที่มีประสบการณ์สร้างข้อผิดพลาดน้อยลงและรหัสของพวกเขามีเสถียรภาพมากขึ้น ฯลฯ โปรแกรมเมอร์เริ่มต้นเสียเวลามากสำหรับคนอื่น ๆ (PM ลูกค้าและอื่น ๆ ) แต่ราคาถูกกว่ามาก อาร์กิวเมนต์ตัวนับคือต้องใช้ประสบการณ์และเริ่มต้นใช้เวลาในการสร้างตารางเป็น HTML ดังนั้นจึงเป็นเรื่องหรูหราที่จะจ้างโปรแกรมเมอร์ผู้มีประสบการณ์ให้ทำสิ่งที่โปรแกรมเมอร์มือใหม่อาจจะประสบความสำเร็จได้เช่นกัน เราควรลงทุนในโปรแกรมเมอร์มากขึ้นและดีขึ้นหรือมากขึ้นและดีกว่า PM เนื่องจากความแตกต่างระหว่างโปรแกรมเมอร์ที่มีประสบการณ์และใหม่ในสาขาของเราสามารถเป็น 4x

33 project-management 

ฉันอ่านบทความบนเว็บเพื่อค้นหาว่า Agile, XP, Scrum, การเขียนโปรแกรมคู่แตกต่างกันอย่างไร / เกี่ยวข้องกันและฉันได้รับบรรทัดต่อไปนี้: Scrum และ XP เกือบจะเหมือนกัน XP มีระยะเวลาเผยแพร่สั้นกว่า Scrum การเขียนโปรแกรมคู่ใช้ทั้งวิธี Agile และ XP แต่ฉันไม่สามารถระบุได้ว่า Agile นั้นแตกต่างจาก XP อย่างไร มากกว่าให้ URL ฉันยินดีที่จะอ่านประสบการณ์และความคิดของคุณเกี่ยวกับเรื่องนี้

32 project-management  agile  scrum  pair-programming  extreme-programming 

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

31 project-management  issue-tracking 

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

31 project-management  team  team-leader 

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

31 web-development  project-management  team 

ฉันอยากรู้ว่ามันเหมาะสมหรือไม่ที่จะแบ่งโครงการที่ฉันทำงานในที่เก็บสองแห่งแทนที่จะเป็นหนึ่งโครงการ จากสิ่งที่ฉันสามารถพูดได้: ส่วนหน้าจะถูกเขียนเป็น html + js แบ็กเอนด์ใน. net แบ็กเอนด์ไม่ได้ขึ้นอยู่กับส่วนหน้าและส่วนหน้าไม่ได้ขึ้นอยู่กับส่วนแบ็คเอนด์ ส่วนหน้าจะใช้ API พักผ่อนหย่อนใจดำเนินการในแบ็กเอนด์ ส่วนหน้าสามารถโฮสต์บนเซิร์ฟเวอร์ HTTP ใด ๆ คงที่ ณ ตอนนี้ที่เก็บมีโครงสร้างนี้: ราก: ส่วนหน้า / * แบ็กเอนด์ / * ฉันคิดว่ามันเป็นความผิดพลาดที่ทำให้โครงการทั้งสองอยู่ในที่เก็บเดียวกัน เนื่องจากโปรเจ็กต์ทั้งสองไม่มีการขึ้นต่อกันระหว่างกันดังนั้นจึงควรอยู่ในที่เก็บแต่ละรายการและหากจำเป็นต้องมีที่เก็บพาเรนต์ที่มีซับโดเลชัน ฉันได้รับแจ้งว่าไม่มีประโยชน์และเราจะไม่ได้รับประโยชน์ใด ๆ จากการทำเช่นนั้น นี่คือข้อโต้แย้งของฉัน: เรามีสองโมดูลที่ไม่ได้พึ่งพากัน การมีประวัติแหล่งที่มาของทั้งสองโครงการในระยะยาวอาจทำให้สิ่งต่าง ๆ ซับซ้อน (ลองค้นหาในประวัติของบางสิ่งในส่วนหน้าในขณะที่คุณมีครึ่งหนึ่งของข้อผูกพันที่ไม่เกี่ยวข้องกับข้อบกพร่องที่คุณกำลังมองหา) ความขัดแย้งและการรวม (สิ่งนี้ไม่ควรเกิดขึ้น แต่การมีคนกดไปที่แบ็กเอนด์จะบังคับให้ผู้พัฒนารายอื่นดึงการเปลี่ยนแปลงด้านหลังเพื่อผลักดันการเปลี่ยนแปลงส่วนหน้า) นักพัฒนาซอฟต์แวร์หนึ่งรายอาจใช้งานได้เฉพาะในแบ็กเอนด์ แต่จะต้องดึงส่วนหน้าหรือวิธีอื่น ๆ เสมอ ในระยะยาวเมื่อถึงเวลาต้องปรับใช้ ในบางวิธีส่วนหน้าสามารถปรับใช้กับเซิร์ฟเวอร์แบบคงที่หลายตัวในขณะที่มีเซิร์ฟเวอร์ส่วนหลังหนึ่งตัว ในทุกกรณีผู้คนจะถูกบังคับให้โคลนทั้งแบ็กเอนด์ด้วยหรือเพื่อให้สคริปต์ที่กำหนดเองเพื่อผลักดันให้เซิร์ฟเวอร์ทั้งหมดส่วนหน้าเท่านั้นหรือเพื่อลบแบ็กเอนด์ ง่ายกว่าเพียงแค่กด / ดึงเฉพาะส่วนหน้าหรือส่วนหลังกว่าทั้งสองอย่างหากจำเป็นต้องใช้เพียงส่วนเดียว …

30 project-management  version-control  git  mercurial  organization 

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

30 project-management  failure 

ฉันอ่านScrum - คู่มือพ็อกเก็ตโดย Gunther Verheyenและมันบอกว่า: รายงานความโกลาหลของปี 2011 โดยกลุ่ม Standish ถือเป็นจุดเปลี่ยน มีการวิจัยอย่างกว้างขวางในการเปรียบเทียบโครงการแบบดั้งเดิมกับโครงการที่ใช้วิธีแบบ Agile รายงานแสดงให้เห็นว่าวิธีการแบบ Agile เพื่อการพัฒนาซอฟต์แวร์นั้นให้ผลตอบแทนที่สูงกว่ามากถึงแม้จะเป็นความคาดหวังแบบเก่าที่ต้องส่งมอบซอฟต์แวร์ตรงเวลาตามงบประมาณและขอบเขตทั้งหมดที่สัญญาไว้ รายงานแสดงว่าโครงการ Agile ประสบความสำเร็จสามครั้งและมีโครงการ Agile ที่ล้มเหลวน้อยลงสามเท่าเมื่อเทียบกับโครงการดั้งเดิม ดังนั้นฉันจึงทะเลาะกับเพื่อนร่วมงานคนหนึ่งของฉันที่บอกว่าสำหรับบางโครงการ (เช่นยา / การทหารที่ความต้องการไม่เปลี่ยนแปลง) Agile (และโดยเฉพาะ Scrum) มีค่าใช้จ่ายในการประชุมทั้งหมด ฯลฯ และมันมีเหตุผลมากกว่า ตัวอย่างเช่นใช้น้ำตก มุมมองของฉันคือ Scrum ที่ควรนำมาใช้ในโครงการดังกล่าวเพราะมันจะทำให้กระบวนการโปร่งใสมากขึ้นและเพิ่มผลผลิตของทีม ฉันยังคิดว่ากิจกรรมการแย่งชิงกันจะไม่ใช้เวลามากถ้ามันไม่จำเป็นเพราะเราไม่จำเป็นต้องนั่งทั้ง 8 ชั่วโมงใน Sprint Planning เป็นเวลา 1 เดือน เราสามารถสำรอง 5 นาทีเพื่อให้แน่ใจว่าเราทุกคนอยู่ในหน้าเดียวกันและเริ่มทำงาน ดังนั้น Scrum จะสร้างค่าใช้จ่ายเพิ่มเติมสำหรับโครงการที่ความต้องการไม่เปลี่ยนแปลงหรือไม่

29 agile  project-management  scrum  methodology