Scrum เปลี่ยนนักพัฒนาที่ใช้งานเป็นนักพัฒนาที่แฝงอยู่หรือไม่?


103

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

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

มีความแตกต่างใหญ่ระหว่างคุณก็คือการตัดสินใจว่าจะทำหรือได้รับการบอกว่าจะทำอย่างไร

ก่อนที่จะทะเลาะกันผมก็รู้สึกว่าเหมือนมีอิสระมากขึ้นในการตัดสินใจที่เกี่ยวข้องกับการพัฒนา, การวิเคราะห์การจัดลำดับความสำคัญการดำเนินการอื่น ๆ ผมมีความรู้สึกมากขึ้นเช่นฉันตัดสินใจสิ่งที่ฉันทำ

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

  1. ฉันมักจะค้นหาน้อยลงเพื่อหาทางออกวิธีหรือเทคนิคที่ดีกว่า
  2. ฉันไม่ตื่นนอนตอนเช้าโดยหวังว่าจะได้งานที่สนุกสนาน แต่ฉันรู้สึกว่าถูกบังคับให้ทำงานเพื่อให้มีชีวิต
  3. ฉันมีความหิวมากขึ้นในการทำงานในโครงการงานอดิเรกของตัวเองหลังเลิกงาน
  4. ฉันจะไม่ผลักดันทีมอีกต่อไปเพื่อก้าวสู่ระดับเทคโนโลยีที่สูงขึ้น
  5. ตอนนี้ฉันใช้เวลากับอาหารเย็นหรือดื่มชามากขึ้นและมีความกระตือรือร้นน้อยลงเพื่อกลับไปทำงาน
  6. ตอนนี้ฉันยินดีมากขึ้นสำหรับการทำงานให้เสร็จเร็วขึ้นเพื่อที่ฉันจะได้กลับบ้าน

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


4
คุณแน่ใจหรือว่าคุณไม่เคยทำผิดปกติมาก่อนเลย?
Donal Fellows

27
โพสต์บล็อกที่ดี
Robert S.

20
สิ่งที่คุณกำลังอธิบายไม่ใช่

4
@Chad สิ่งที่ฉันพูดถึงที่นี่ไม่ใช่การร้องเรียนเกี่ยวกับสถานการณ์การทำงานของฉัน ฉันแค่สงสัยว่าอารมณ์นี้เป็นผลมาจากการต่อสู้? และไม่ว่านักพัฒนาซอฟต์แวร์รายอื่นจะประสบกับสิ่งเดียวกันหรือไม่?
Saeed Neamati

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

คำตอบ:


51

อย่างไรก็ตามตอนนี้ฉันรู้สึกเหมือนได้รับคำสั่งให้ทำบางสิ่งเสมอแทนที่จะตัดสินใจทำอะไรสักอย่าง

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

คุณกำลังทำ "ทะเลาะกัน แต่"? นั่นคือส่วนหนึ่งต่อสู้ส่วนอื่น ๆ (เช่น: "เรากำลังทะเลาะกัน แต่เรื่องราวทั้งหมดของเราต้องมาจาก PMO ของเราไม่ใช่เจ้าของผลิตภัณฑ์") อึบ้าจำนวนมากถูกเรียกว่า Scrum ในทุกวันนี้

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

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


10
+1 การแย่งชิง (ตามวิธีการทั้งหมดของ Agile) จะหนักกว่าการสนทนามากกว่าทิศทาง PO ควรจะอธิบายสิ่งที่ผลลัพธ์สุดท้ายต้องการให้สำเร็จจากนั้นให้นักออกแบบและนักพัฒนามีส่วนร่วมในวิธีที่จะไปถึงที่นั่น
StevenV

5
"ผู้คนเหนือกระบวนการ": ตลกแล้วทำไมกำหนดกระบวนการ SCRUM แทนที่จะปล่อยให้คนใช้ของตัวเอง? และทำไมมาตรการเหล่านี้ (การเขียนโปรแกรมคู่, การทบทวนความคืบหน้าบ่อยครั้ง) ที่ในนามของความโปร่งใสอนุญาตให้ตรวจสอบการทำงานของนักพัฒนาอย่างใกล้ชิดมากขึ้น?
Giorgio

3
@Giorgio: เนื่องจากการพัฒนาที่มีโครงสร้างช่วยให้ทีมทำงานร่วมกันได้โดยไม่ต้องเหยียบนิ้วเท้าของกันและกันตลอดเวลา เรายังไม่ได้คิดวิธีที่จะทำได้อย่างสมบูรณ์แบบ
Phoshi

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

62

ปัญหาของคุณไม่ได้แย่งชิงกัน (และเป็น Jarrod Roberson กล่าวถึงในความคิดเห็นก็ไม่ได้ทะเลาะกันสิ่งที่คุณอธิบาย) - เป็นเจ้าของผลิตภัณฑ์ของmicromanagementและคุณ (และทีม) ขาดความอหังการ

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

คุณเข้าใจผิด เพียงแค่ดูสั้น ๆ ที่หน้าวิกิพีเดียสำหรับ Scrumหนึ่งจะเห็นว่า: "ทีมกลุ่มข้ามสายงานที่ทำการวิเคราะห์ที่แท้จริงการออกแบบการใช้งานการทดสอบและอื่น ๆ " ดู? เจ้าของผลิตภัณฑ์จะบอกคุณในสิ่งที่จะทำ แต่ก็ขึ้นอยู่กับทีมที่จะตัดสินใจว่าจะทำอย่างนั้น

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

BTW micromanagement ไม่เปิดใช้งานนักพัฒนาเข้าไปพัฒนาเรื่อย ๆ


38
สาธุกับบรรทัดสุดท้ายนั้น
Wivani

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

1
1 @Lukas เพราะของความแตกต่างระหว่างสิ่งที่และวิธีการ ขอบคุณเพื่อน.
Saeed Neamati

5
"เจ้าของผลิตภัณฑ์บอกคุณว่าต้องทำอะไร" - ฉันไม่ค่อยเห็นด้วย พวกเขาควรจะบอกคุณว่าพวกเขาต้องการอะไร ความแตกต่างเล็กน้อย แต่สำคัญ ในคำอื่น ๆ : พวกเขาอธิบายปัญหา / ปัญหาคุณให้การแก้ปัญหา
DanMan

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

29

สิ่งที่คุณอธิบายไม่ได้เป็นขยะ

เจ้าของผลิตภัณฑ์ของคุณกำลังก้าวเกินขอบเขตหากเขาบอกคุณเกี่ยวกับวิธีการทำงานของคุณในทางเทคนิคนั่นไม่ใช่สิ่งที่ SCRUM เกี่ยวข้อง

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

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

ใช่เจ้าของผลิตภัณฑ์ควรจัดลำดับความสำคัญของคุณสมบัติสิ่งที่ต้องส่งก่อนตามความต้องการของลูกค้า แต่นักพัฒนาควรทำวิศวกรรมและการออกแบบไม่ใช่เจ้าของผลิตภัณฑ์

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

SCRUM เป็นเรื่องเกี่ยวกับการวางกระบวนการน้ำหนักเบาที่สามารถคาดการณ์และทำซ้ำได้ในรายการที่คล่องตัว

มันทำให้ฉันเศร้าที่ได้ยินเรื่องราวว่าสิ่งที่ดี ๆ กำลังถูกบิดเบือนเช่นนี้


3
ธรรมชาติของมนุษย์มักจะหาวิธีที่จะเอาชนะความพ่ายแพ้จากกรามแห่งชัยชนะ
Warren P

2
มีสิ่งที่ SCRUM ควรจะเป็นและมีสิ่งที่จะกลายเป็นอย่างน้อยที่สุด บริษัท ส่วนใหญ่ SCRUM ไม่ใช่สิ่งชั่วร้ายในตัวมันเอง แต่เป็นเครื่องมือที่ใช้ในการจัดการความชั่วได้ง่ายมาก
AresAvatar

11

ฉันคาดเดาก่อนที่จะแย่งชิงกันทุกคนเพียงแค่ทำในสิ่งที่ต้องการ: ไชโย ki-yay mf'er ผู้ใช้ของคุณคือผู้มีพระคุณและพวกเขาขับเรื่องราวและชำระค่าใช้จ่าย เจ้าของผลิตภัณฑ์ทำให้แน่ใจว่าเรื่องราวนั้นจะเสร็จสิ้น กลุ่มของคุณได้ข้อสรุปว่าเจ้าของผลิตภัณฑ์ควรบอกวิธีการตั้งโปรแกรม

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

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


10

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

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

ดังนั้นเปลี่ยนมัน นำมันขึ้นมาพร้อมกับการจัดการและบอกว่ามันเป็นขั้นตอนถอยหลังเข้าคลองซึ่งผลผลิตของคุณน้อยกว่าที่เคยเป็นมาและคุณทุกคนไม่มีความสุขกับวิธีการทำงานของมัน แสดงAgile Manifesto (และแฝดที่ชั่วร้าย ) และแสดงให้เห็นว่าคุณไม่เพียง แต่ได้เรียนรู้บทเรียนจากการทดลองนี้ แต่ต้องการที่จะพัฒนาบิตที่ดีจากมันให้เป็นระบบที่ดีขึ้น (อย่างที่คุณเคยเป็นมา สำหรับคุณ).


6
ฉัน? ใช่ - เราเคยทำงานได้ดีจากนั้นผู้บริหารก็ตัดสินใจว่า Agile เป็นอนาคตและกำหนดการต่อสู้ซึ่ง จำกัด เราอย่างมาก สิ่งที่เราเคยทำอย่างง่ายดายจมอยู่ในกระบวนการและระบบราชการ ฉันเคยเอาไพ่ 3 ใบจากกระดานต่อสู้ !! ไฟกระพริบและไซเรน wailed สำหรับการละเมิดของ 'วิธีการต่อสู้' นี้และผมเคยเอาการ์ดกลับไปที่โต๊ะทำงานของฉัน ตำรวจจัดการโครงการเข้ามาหาฉัน และฉันเคยนั่งลงในการต่อสู้ในชีวิตประจำวันที่ไม่ได้ลงไปด้วย เรื่องไร้สาระทั้งหมด IMHO แต่ถูกทำให้เป็นภูเขา
gbjbaanb

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

3
@ ian31: ใช่โครงการนั้นเลวร้ายเป็นพิเศษ แต่ Scrum สนใจต่อผู้จัดการประเภทนั้น คุณไม่เคยเห็นพวกเขาเลือก Kanban หรือ Crystal เลย การต่อสู้อย่างง่ายดายเกินไปเปลี่ยนเป็น "การต่อสู้ แต่" เมื่อคนเหล่านี้ได้รับมัน สงสาร
gbjbaanb

1
ฉันคิดว่ามันเป็นเรื่องตลกที่ บริษัท ใด ๆ จะเปลี่ยนสกัมเป็นพิธีทางศาสนา เฮ้! ยืนระหว่างพิธีนี้ที่เราแสร้งทำเป็นเปรียว! เฮ้! ยิ้มในขณะที่เราแสร้งฟังคุณและจากนั้นทำสิ่งที่เราอยากทำต่อไปอย่างสนุกสนาน!
Warren P

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

8

ฉันคิดว่าเพียงแค่พวกคุณคุ้นเคยกับการเป็นเจ้าของมากขึ้น - และทุกคนที่ฉันคิดว่าชอบธรรมชาติของมนุษย์

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

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


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

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

@Andomar - มันเป็นความสมดุล แต่ละด้านมีอุดมคติสมมติฐานและความผิดพลาด ไม่สนใจสิ่งเหล่านี้ทำให้เกิดอันตราย
Jonno

5

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


4
ในฐานะนักพัฒนาฉันไม่ต้องการเห็นเรื่องราวผู้ใช้แบบนี้อีกเลยดังนั้นฉันจึงไม่ต้องคร่ำครวญถึงความบ้าคลั่งของมัน
Warren P

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

4

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

จากประกาศเปรียว:

ลำดับความสำคัญสูงสุดของเราคือการสร้างความพึงพอใจให้กับลูกค้าผ่านการส่งมอบซอฟต์แวร์ที่มีคุณค่าก่อนและต่อเนื่อง

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

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

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


3

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


3

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

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

และเรามีการจัดการแบบไมโครบางครั้ง แต่นั่นเป็นปัญหาที่แตกต่าง


3

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

ถาม: วิธีการกำหนด x แต่ x ทำงานได้ไม่ดี เราควรทำอย่างไร

ตอบ: ปรับปรุงการปรับใช้ x อาจหยุดทำมันโดยสิ้นเชิง ระเบียบวิธีไม่ใช่เจ้านายของคุณ!

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


2

ฉันไม่ได้สอดคล้องกับสิ่งที่ทะเลาะกันเหมือนน้ำตกอีกซักพัก

แต่ตามความจริงแล้วสิ่งนี้ฟังดูคล้ายกับปัญหาการจัดการบุคลากรมากกว่าปัญหาเทคนิคการจัดการโครงการ ในขณะที่มันเป็นคนมากกว่าตามเทคนิค


ไม่ @temptar ความสัมพันธ์ของเราดีจริงๆ ไม่มีความผิดไม่มีความเกลียดชังไม่มีอะไรเลย ทุกอย่างเรียบร้อยทุกอย่างยกเว้นความรู้สึกที่มีต่องาน
Saeed Neamati

2

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


2

ฉันมีประสบการณ์แบบเดียวกันกับ Scrum และชอบเรียกมันว่า "ทรราชของเรื่อง"

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

วิธีเดียวที่ฉันค้นพบในตอนนี้ก็คือทั้งคูคลอง - ไม่สามารถทำได้และ / หรือเหมาะสมเพราะหลังจากนั้นก็มีข้อดี - หรือจะแนะนำอะไรบางอย่างเช่นเวลา 20% ของ Google เพื่อให้นักพัฒนามีทางออกที่สร้างสรรค์นอกเหนือจาก "คุณ" ฟรีในการเลือกวิธีการใช้หน้าเข้าสู่ระบบ "เพราะในความเป็นจริงคุณไม่ได้เป็นเพราะการใช้งานของคุณถูก จำกัด ด้วยรหัสที่มีอยู่และสถาปัตยกรรมระบบ - นั่นคือถ้าไม่มีใครคิดว่าอิสระในการเลือกระหว่าง 'a for a and a while loop' a เสรีภาพ


1

มีความแตกต่างใหญ่ระหว่างคุณก็คือการตัดสินใจว่าจะทำหรือได้รับการบอกว่าจะทำอย่างไร

จากประสบการณ์ของผมมีเพียงวิธีที่ค่อนข้างยาวจากได้รับการบอกว่าจะทำอย่างไรที่จะตัดสินใจว่าจะทำอย่างไร

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

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


1

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


1

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


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

น่าอัศจรรย์ที่บางคนรู้น้อยเกี่ยวกับการต่อสู้หรือว่องไวและวิธีการโพสต์เช่นเจ้าหน้าที่ หนึ่งได้รับความประทับใจว่าบุคคลที่ทำงานเป็นเวลาสองสามสัปดาห์ในกลุ่มที่ผิดปกติที่พวกเขากล่าวว่าพวกเขา "ทำทะเลาะกัน" และสรุปว่าเป็นวิธีการต่อสู้ที่ควรจะเป็น ในกรณีนี้เป็นคนที่ไม่ระบุชื่ออย่างสมบูรณ์โดยมีเพียงโพสต์เดียวหรือแสดงความคิดเห็นใน 4 ปีและไม่มีหลักฐานความเชี่ยวชาญในเรื่องนี้ นี่คือเหตุผลที่เราไม่สามารถแสดงความคิดเห็นเหล่านี้ได้อย่างจริงจัง
Curtis Reed
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.