งานในมือของงานที่“ กัดขนาด” ขนานไปกับงานในมือของ“ main” หรือไม่?


16

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

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

ด้วยวิธีการพื้นฐานแบบ Agile SCRUM การปรับแต่งเหล่านี้อาจถูกบันทึกว่าเป็นข้อบกพร่อง (เราไม่ตอบสนองความต้องการที่ระบุไว้ในเรื่องที่เคยใช้มาก่อน) หรือเรื่องเล็ก ๆ ใหม่ (เราปฏิบัติตามข้อกำหนดที่ระบุทั้งหมด แต่ข้อกำหนดเหล่านั้นไม่สมบูรณ์ หรือพวกเขาเปลี่ยนหลังจากจัดส่งเมื่อผู้ใช้เห็นคุณลักษณะใหม่) ทั้งสองวิธีนี้ส่วนใหญ่จะเป็นหนึ่งในตัวชี้ที่ส่วนใหญ่ถ้าไม่ zeroes และมีความสำคัญค่อนข้างต่ำ (ระบบสามารถใช้งานได้ในสถานะปัจจุบันของมัน แต่มันจะเป็นเช่นนั้นเย็นมากถ้า ... ) ทำให้พวกเขาไม่น่าจะเป็น นำมาในการวิ่งเมื่อทำงานแบ็คล็อกจากบนลงล่าง

ความเป็นไปได้นี้ถูกยกขึ้นในที่ประชุมผู้พัฒนาว่าเป็นแหล่งที่มาของการต่อต้านกระบวนการ Agile ของเราโดยหน่วยงานอื่นซึ่งจะเห็นว่าเป็น "เปรียว" น้อยกว่าความสามารถในปัจจุบันของเราในการปรับแต่งเล็กน้อยตามคำร้องขอ เป็นข้อกังวลที่ถูกต้องของ IMO; ผู้มีส่วนได้ส่วนเสียที่อยู่เบื้องหลัง PO มักไม่เห็นด้วยกับสิ่งที่สำคัญที่สุดเพราะพวกเขาทุกคนไม่ได้มีมุมมองที่เหมือนกัน แต่โดยทั่วไปแล้วก็เป็นเพียงผู้จัดการที่ตัดสินใจขั้นสุดท้ายเท่านั้นดังนั้นอคติของพวกเขาจึงเป็นสิ่งที่ แสดงในผลิตภัณฑ์ที่ค้าง

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

สิ่งนี้ก่อให้เกิดปฏิกิริยาในหมู่พวกเราด้วยการฝึกอบรม ScrumMaster "uh-uh" มีงานค้างหนึ่งงาน สอง backlogs แนะนำคำถามที่ # 1 รายการคือจริงๆที่สำคัญที่สุดซึ่งรายชื่อของรายการตรวจสอบจริงความเร็วและที่ของทั้งสอง backlogs เป็นเรื่องจริงเป็นใน (แบ่งเขตที่มีขนาดใด / ซับซ้อนจะมีบางกรณีที่ตกค่อนข้าง ไปข้างใดข้างหนึ่งโดยพลการ) "ให้กระบวนการทำงาน" เราพูด หากการเปลี่ยนแปลงมีความสำคัญอย่างยิ่งต่อผู้ใช้งานพวกเขาจะส่งเสียงดังพอที่จะทำให้หัวหน้าแผนกทำการตัดสินใจด้านเวลา / เงินบนกระดานและมันจะกระทบกระเทือนต่อจิตสำนึกของทีมพัฒนาไปสู่ด้านบนสุดของงานในมือ

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


5
รูปแบบการพัฒนาโรงอาหารในปัจจุบันนั้นใช้งานได้ดีเพียงใด หากทุกคนมีความสุขกับมันและสามารถอยู่กับความไม่แน่นอนของกำหนดเวลาที่เคลื่อนไหวอย่างต่อเนื่องได้ นี่ไม่ใช่แค่คำถามเชิงโวหาร เหตุผลหลักที่คุณต้องการใช้การต่อสู้คือการกำจัดอย่างแม่นยำว่าคุณภาพของรูปแบบการพัฒนาในปัจจุบันของคุณที่ผู้มีส่วนได้เสียของคุณดูเหมือนจะให้คุณค่า คุณจะต้องพิจารณาการต่อสู้เพราะคุณรับรู้ปัญหาที่การต่อสู้จะแก้ปัญหา; ปัญหาดังกล่าวได้รับการสื่อสารอย่างเพียงพอและน่าเชื่อถือแก่ผู้มีส่วนได้เสีย?
Robert Harvey

เรามีปัญหาหลายอย่างกับระบบปัจจุบัน; ก่อนอื่นผู้ที่ "เป็นเจ้าของ" โค้ดเบสของแอพต่างๆในบ้านจะถูกฝังโดย "drive-bys" เพื่อขอคุณสมบัติเพิ่มเติม เป็นเรื่องยากหรือเป็นไปไม่ได้ที่จะเดินหน้าและมุ่งเน้นไปที่สิ่งอื่น ในทางกลับกันทำให้นักพัฒนาแต่ละคน "กูรู" สำหรับรหัสที่พวกเขาเขียนแทนที่จะเป็นแต่ละแอปพลิเคชันเป็นความพยายามของทีมที่นักพัฒนาซอฟต์แวร์ทุกคนอย่างน้อยคุ้นเคย ไม่ได้บอกว่าการเป็นเจ้าของรหัสไม่ดี แต่เป็นเจ้าของรหัสที่แข็งแกร่งใช่เราต้องการหยุดมัน
KeithS

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

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

โอ้และสุดท้าย - สุดท้าย; ระบบการส่งมอบความต้องการในปัจจุบันเป็นหลัก "ไดรฟ์ bys" เหล่านี้ ถ้าฉันมีข้อศอกลึกลงไปใน codebase ที่แตกต่างกันโดยสิ้นเชิงและฉันไม่ได้เขียนสิ่งที่คุณต้องการในรายละเอียดมากพอที่จะจดจำสิ่งที่คุณต้องการจริง ๆ เมื่อคุณมาที่คิวบ์ของฉันเพื่อถามฉัน รอยแตกอย่างสิ้นเชิง การรวบรวมความต้องการสำหรับโครงการขนาดใหญ่นั้นมีการจัดระเบียบมากขึ้น แต่ก็มีอีกอย่างหนึ่งเสมอและในปัจจุบันยังไม่มีที่เก็บข้อมูลส่วนกลางสำหรับสิ่งเหล่านี้
KeithS

คำตอบ:


10

ฉันจะพูดถึงบางประเด็นซึ่งหวังว่าจะช่วยคุณค้นหาเส้นทางของคุณ:

  1. " SCRUM " นั้นเกี่ยวกับความคล่องตัว จำเป็นต้องมีสามัญสำนึก หากการเปลี่ยนแปลงนั้นเปลี่ยนไปไม่กี่นาทีฉันไม่คิดว่าคุณจะต้องมีงานในมือ ถ้ามากกว่า 2 ชั่วโมงฉันคิดว่าคุณควรคิดใหม่ ไม่ใช่ทุกสิ่งที่ควรจะเป็น "easy-win" ใน SCRUM คุณทำงานตามลำดับความสำคัญ ฉันคิดว่า PO ต้องได้รับข้อมูลเกี่ยวกับสิ่งที่คุณได้รับจากการเพิ่มและความพยายาม ใบสั่งซื้อสามารถตัดสินใจได้ว่าสำคัญหรือไม่ การย้ายมาที่ SCRUM บางครั้งมาพร้อมกับคำถามมากมายและนักพัฒนามักจะพูดว่า "แต่นั่นจะใช้เวลาเพียงไม่กี่ชั่วโมง" แล้วอะไรล่ะ ไม่กี่ชั่วโมงคือเวลาไม่ใช่ทุกสิ่งที่จำเป็นต้องมีในระยะสั้น
  2. ผมเคยทำงานในโครงการที่เรามี"วิศวกรรมค้าง" ยอดคงค้างนี้มีรายการที่ผู้พัฒนาแนะนำสำหรับการปรับปรุงผลิตภัณฑ์ รายการเหล่านั้นไม่มีค่าผู้ใช้อย่างชัดเจน (แต่มีค่าผู้ใช้โดยนัย) ตัวอย่างเช่น: refactoring องค์ประกอบในรหัส เราได้อธิบายถึงการเปลี่ยนแปลงความพยายามและผลประโยชน์ (ในกรณีนี้คุณไม่สามารถแสดงอะไรให้ผู้ใช้ได้ แต่ถ้าการปรับโครงสร้างดังกล่าวทำให้เกิดการพัฒนาความสามารถใหม่ได้เร็วขึ้นก็จะเป็นประโยชน์ต่อผู้ใช้อย่างแน่นอน) ใบสั่งซื้อของเราตัดสินใจว่าระหว่างรุ่นเราควรลงทุน 10% ของการวิ่งแต่ละครั้ง (โดยเฉลี่ย) ไปยังรายการดังกล่าว ก่อนการวิ่งแต่ละครั้งเมื่อ PO ตัดสินใจเกี่ยวกับ Backlog ของการวิ่งที่กำลังจะมาเขาตรวจสอบให้แน่ใจว่าเรามี 10% ของรายการที่ค้างอยู่ที่แกะสลัก ดังนั้นค้าง 2 รุ่น -> 1 ค้างค้างวิ่ง
  3. บัฟเฟอร์ - เมื่อเริ่มทำงานในผู้คนที่ SCRUM มักจะลืมไปว่าในฐานะวิศวกรซอฟต์แวร์เราจะทิ้งโลกแห่งความไม่แน่นอน มันก็โอเคที่จะนับ 1 วันทำงานเป็น 6 ชั่วโมงแทน 8 สมมติว่าคุณมีการวิ่ง 15 วันนั่นหมายความว่าคุณมีเวลาเพิ่มอีก 30 ชั่วโมงสำหรับการประชุมสิ่งต่าง ๆ ที่ใช้เวลานานเกินไปและใช่ - เช่นกัน สิ่งที่เกินกว่าจะจำได้ แต่เป็นส่วนหนึ่งของงานประจำวันของเรา 2 วัน
  4. จดจ่ออยู่กับสิ่งที่ต้องทำ - สุดท้าย แต่ไม่ท้ายสุดใน SCRUM สิ่งสำคัญคือคุณต้องมีสมาธิ ตัดสินใจว่าความพยายามทั้งหมดของคุณมีความสำคัญเพียงใดในการลงทุนในงานดังกล่าวและอย่าลืมลงทุนในช่วงเวลานี้ อย่าล่องลอยเพื่อทำงานกับ "สิ่งเล็ก ๆ น้อย ๆ " เพียงเพราะพวกเขามีน้อย คุณมีใบสั่งซื้อเพื่อช่วยในการตัดสินใจและคุณมีสามัญสำนึก
  5. Stay Agile - และท้ายที่สุดอย่าลืมลองวิธีการต่าง ๆ ในการแก้ไขปัญหาถามตัวคุณเองว่าเป็นวิธีที่ดีที่สุด ปรับปรุงทาง

โชคดี :)


1
+1 สำหรับงานในมือ นอกจากนี้ยังสามารถใช้สำหรับคำขอของผู้ใช้ที่ไม่ได้ทำการตัด
Bart van Ingen Schenau

3

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

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

Btw เราเรียกว่า "ความเจ๋งของโครงการ" ของเราและมันก็เป็นแหล่งของความคิดและการปรับปรุงที่ดีมากมายที่ บริษัท นั้น


3

คุณควรเก็บเรื่องราวเล็ก ๆ ไว้ใน backlog หลัก

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

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

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

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

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

สิ่งที่มักเกิดขึ้นกับฉันก็คือผู้มีส่วนได้เสียร้องขอ LargeImportantProject และ SmallLessImportantTask ขึ้นเขียงคือ SmallLessImportantTask ควรรอ LargeImportantProject ให้เสร็จสิ้น (หรือมีสิ่งกีดขวางบนถนน) หรือไม่ มีการแลกเปลี่ยนและประสบการณ์ของฉันก็คือเจ้าของผลิตภัณฑ์ต้องตัดสินใจ (หากเจ้าของผลิตภัณฑ์ไม่ได้ตัดสินใจทีมพัฒนาจะต้องเดา)

เป้าหมายหนึ่งของการต่อสู้ (และการจัดการโครงการโดยทั่วไป) คือการหลีกเลี่ยงสิ่งกีดขวางบนถนนสำหรับงานที่มีลำดับความสำคัญสูงสุด เมื่อคุณมีประสิทธิภาพมากขึ้นมีที่ว่างน้อยลงที่จะบีบงานพิเศษ "ดีที่มี"

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

  1. เมื่อคุณมีประสิทธิภาพมากขึ้นคุณจะเพิ่มความสามารถของทีมในการทำงานที่มีคุณค่าซึ่งรวมถึงคำขอ "ยินดีที่มี"
  2. หากคำขอเป็น "ดีที่มี" อย่างแท้จริงอาจเป็นเรื่องที่ถูกต้องตามกฎหมายสำหรับคำขอที่จะรอจนกว่าจะให้ความสำคัญกับธุรกิจที่สำคัญกว่านั้น

จุดที่ดี ตรงกันข้ามกับฉันทามติ แต่นั่นเป็นเหตุผลที่ฉันถามคำถาม; เพื่อรับมุมมองทั้งหมด
KeithS

ทุกสิ่งที่แอรอนพูดนั้นเป็นเรื่องจริง แต่ทั้งหมดนำไปสู่การเปลี่ยนแปลง "บริษัท ใหญ่" มีห่วงมากเกินไปที่จะต้องข้ามไปยังผู้ใช้เพื่อรับสิ่งที่ต้องการ ดังนั้นในที่สุดพวกเขาก็จะหยุดด้วยการเสนอ tweaks เล็กน้อยที่ท้ายด้วยพวกเขาได้รับเครื่องมือที่ดีและเพียงแค่ใช้เครื่องมือ "crummy" ตามที่เป็นอยู่
Dunk

2

ในความเห็นของฉัน; ปัญหาของคุณคือวิธีการจัดลำดับความสำคัญงานใน backlog ตัวอย่างเช่น "ลำดับความสำคัญ" อาจคำนึงถึงทั้งความสำคัญและความรวดเร็วในการดำเนินการ สิ่งที่ไม่สำคัญ แต่สามารถทำให้เสร็จได้ภายใน 10 นาทีอาจมีลำดับความสำคัญสูงกว่าสิ่งที่สำคัญกว่าซึ่งจะใช้เวลาหลายสัปดาห์กว่าจะสำเร็จ


1
นี่เป็นจุดที่ดี ควรพิจารณา "ROI" เมื่อตั้งค่าลำดับความสำคัญ ทำสิ่งที่ช่วยให้คุณปรับปรุงได้เร็วที่สุด สิ่งนี้สามารถได้รับการสนับสนุนเมื่อตั้งค่า Backlog (เรากำลังจะเริ่มต้นในการยอมรับ Agile ของเราจริงๆ )
KeithS

2

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

อย่างที่ Avi กล่าวไว้ข้างต้น - "SCRUM" นั้นเกี่ยวกับความคล่องตัว จำเป็นต้องมีสามัญสำนึก หากการเปลี่ยนแปลงนั้นเปลี่ยนไปไม่กี่นาทีฉันไม่คิดว่าคุณจะต้องมีงานในมือ

หากการเปลี่ยนแปลงต้องใช้เวลานั่นหมายความว่าไม่ใช่ทั้งหมดที่ "ไม่เป็นอันตราย" และควรมีการบันทึกไว้อย่างดี


0

ตามคำถามเริ่มต้นของคุณและการชี้แจงที่ตามมานี่คือสิ่งที่ฉันได้รับรู้ว่าจุดปวดของคุณ

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

การต่อสู้ถ้าเริ่มแรกที่ปฏิบัติตามอย่างถูกต้องควรแก้ไขปัญหาเหล่านี้จำนวนมากและที่สำคัญกว่านั้นนำปัญหาอื่น ๆ ไปสู่ส่วนที่ควรได้รับการแก้ไข

- ข้อกำหนดที่เปลี่ยนแปลงตลอดเวลา

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

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

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

- แนวทางที่แตกต่างสำหรับสถาปัตยกรรมโซลูชั่นกรอบที่ใช้

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

- กระบวนการรวบรวมความต้องการ

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

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.