การปิดโครงการในการแย่งชิงกัน

ในสภาพแวดล้อมการพัฒนาซอฟต์แวร์ทั่วไปการปิดโครงการเป็นการสิ้นสุดโครงการ

1. บันทึกโครงการเสร็จสมบูรณ์และถูกเก็บถาวร
2. ทรัพยากรที่ปล่อยออกมา
3. ปัญหาและบทเรียนมีการบันทึกไว้และ
4. งานเลี้ยงอาหารค่ำอย่างเป็นทางการ / จัดขึ้นเพื่อเฉลิมฉลอง

ขั้นตอนสุดท้ายเป็นทางเลือกแม้ว่าจะมีแรงจูงใจมากสำหรับผู้เข้าร่วม :-)

ตัดกันด้วย Scrum ฉันรู้ว่าการต่อสู้วิ่งบนเรื่องราวจาก backlogs ดังนั้นในทางเทคนิคการวนซ้ำทุกครั้งจึงปิดบางเรื่อง ดังนั้นมีสองคำถามที่นี่

1. สำหรับกลุ่มที่ทำงานในหลายโครงการพร้อมกันโครงการปิดได้อย่างไร
2. สำหรับโครงการที่เกี่ยวข้องกับหลายกลุ่มแนวคิดนี้นำไปใช้อย่างไร

หรือเทอมการปิดโครงการใช้ไม่ได้กับโครงการ T&Mเลยหรือไม่?

สำหรับกลุ่มที่ทำงานในหลายโครงการพร้อมกันโครงการปิดได้อย่างไร

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

อย่างไรก็ตามการแย่งชิงกันไม่แตกต่างจากวิธีการที่ไม่คล่องตัว (น้ำตก) เมื่องานในมือลดลงเหลือศูนย์ประมาณคุณก็ยังทำได้ เช่นเดียวกับการทำราวกับว่าคุณมีวิธีน้ำตกแทนวิธีการแบบเปรียว

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

สำหรับโครงการที่เกี่ยวข้องกับหลายกลุ่มแนวคิดนี้นำไปใช้อย่างไร

เช่นเดียวกับโครงการที่ไม่ต่อสู้กับหลายกลุ่ม ไม่มีอะไรเปลี่ยนแปลงเกี่ยวกับผู้คน พวกเขายังคงชอบปาร์ตี้ที่ดี

หรือเทอมการปิดโครงการใช้ไม่ได้กับโครงการ T&M เลยหรือไม่?

เหตุใดการเรียกเก็บเงินจึงเปลี่ยนแปลงทุกอย่างเกี่ยวกับลักษณะของงานหรือพิธีในตอนท้าย

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

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

ฉันทำงานด้านการเงินบางครั้งมีกฎระเบียบใหม่เกิดขึ้นหรือมีการแลกเปลี่ยนใหม่ปรากฏขึ้นและเรามีวันที่ถ่ายทอดสดสำหรับสิ่งที่กำหนดไว้ เรายังคงใช้วิธี Agile สำหรับการจัดส่ง แต่อยู่ในกรอบการบริหารจัดการโครงการ tradtional มากขึ้นเพื่อให้เราได้รับการส่งมอบตรงเวลา

การประเมินหน่วยงานและการเลือกโซลูชันที่ทำได้ในกรอบเวลาที่มีคือสิ่งที่ทำให้เราเป็นนักพัฒนาที่ดี (สิ่งหนึ่งที่ฉันควรพูด)

ใน Scrum เช่นเดียวกับเทคนิค Agile ทั้งหมดโครงการเป็นสิ่งเล็ก ๆ น้อย ๆ ที่มาและไปในขณะที่ทีมอยู่ด้วยกัน ดังนั้นจึงไม่มีพิธีกรรม "โครงการปิดบัง" เช่นนี้ ค่อนข้างโครงการลดลงในขณะที่ไขอื่น การไหลของรายการในมือค่อยๆเปลี่ยนจากที่หนึ่งไปยังอีกที่หนึ่ง ทีมแทบจะไม่ทราบความแตกต่าง

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

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

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