วิธีสร้าง“ ลัทธิคุณภาพ” [ปิด]


21

DeMarco และ Lister (Peopleware) แนะนำให้คุณสร้าง "ลัทธิคุณภาพ" ภายในทีมการเขียนโปรแกรมของคุณ เฉื่อยชาพวกเขาไม่แนะนำให้คุณทำอย่างนั้น!

ใครมีความคิดเห็นเกี่ยวกับวิธีการทำสิ่งนี้ให้สำเร็จ


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

1
@WesleyWerner: จุดดี แต่ฉันคิดว่า 'ลัทธิของคุณภาพ' ควรโอบกอดการดูแลหนี้สินทางเทคนิคซึ่ง (ในที่สุด) จะแก้ปัญหาเจ้านายที่คุณพูดถึง
talonx

@invert: โดยปกติแล้วฉันจะตอบกลับในกรณีเช่นนี้ว่าเรามีสถานการณ์ที่คล้ายคลึงกับทฤษฎีบท CAP ที่นี่ เรามีคุณภาพความเร็วและกำลังคนและเขาสามารถเลือกได้สองแบบ
JensG

คำตอบ:


37

ประสบการณ์ของฉันคือทีมพัฒนา (แต่โดยทั่วไปแล้วทีมใด ๆ ) ประกอบด้วย 3 คน:

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

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

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

[Update2]สะท้อนคำตอบของ Alb : IMO ไม่จำเป็นที่นักพัฒนาคุณภาพจะต้องเป็นคนส่วนใหญ่ในทีม (แม้ว่ามันจะไม่เจ็บ :-) มี"เกณฑ์การตั้งค่าแนวโน้ม"ด้านบนซึ่งมุมมองและพฤติกรรมของกลุ่มย่อยสามารถกลายเป็น "กระแสหลัก" ในชุมชนได้อย่างรวดเร็วดังนั้นคนอื่นจะสังเกตเห็นและเริ่มติดตาม คุณสามารถเห็นสิ่งนี้ในการทำงานในสังคมขนาดใหญ่ตลอดเวลา (เช่น (ไม่)) นิสัยการสูบบุหรี่, สุขภาพและอาหาร, ป๊อปแฟชั่น, อาหารออร์แกนิก) การประมาณคร่าวๆของฉันคือมันสามารถอยู่ที่ไหนสักแห่งประมาณ 25-30% แต่ขึ้นอยู่กับปัจจัยหลายอย่าง นี่คือที่คนเลวสามารถทำร้ายได้มาก แม้แต่คนไม่ดีสองคนในทีมของคุณก็สามารถเพิ่มขีด จำกัด นั้นได้อย่างมาก [/ Update2]

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

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

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

  • สิ่งนี้นำไปสู่ประเด็นต่อไป: ในการสร้าง "ลัทธิของคุณภาพ" การจัดการต้องเข้าใจอย่างถ่องแท้ว่านักพัฒนาที่มีประสบการณ์ส่วนใหญ่รู้อยู่แล้ว: คุณภาพนั้นไม่ได้เป็นสิ่งที่ต้องทำในภายหลัง ดังนั้นทุกคนควรจะได้รับการสนับสนุน (และได้รับรางวัลสำหรับ!) คิดเกี่ยวกับการบำรุงรักษาระยะยาวที่มุ่งมั่นในการที่ดีการแก้ปัญหาแทนการอย่างรวดเร็วคน

ปรับปรุง

@Machado ในความคิดเห็นของเขาให้บิดใหม่กับคำถาม (กับฉันอย่างน้อย):

ฉันในฐานะสมาชิกในทีมไม่ใช่ผู้จัดการสามารถปรับปรุงคุณภาพรหัสของทีมได้อย่างไร

ความคิดเล็กน้อย:

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

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

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


4
คำแนะนำที่เป็นอันตราย เกิดอะไรขึ้นถ้า OP อยู่ในกลุ่มที่ 2/3? ;)

1
คำตอบที่ดีฉันไม่เคยคิดเกี่ยวกับมันเช่นนี้ แต่มันสมเหตุสมผลมาก
Alb

9
@ นักพัฒนาถ้าพวกเขาพวกเขาจะไม่อ่าน DeMarco และ Lister หรือถามคำถามที่นี่
Alb

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

1
@ Thorbjørnคำถามยอดเยี่ยม! ฉันยอมรับว่าฉันพลาดงานนี้ไปเกือบทุกที่แล้ว ฉันไม่ได้ดูถูกตนเองเกินไปฉันมักจะมองหาเพื่อนร่วมทีมเพื่อค้นหาและเรียนรู้จาก แต่ฉันไม่ค่อยพบพวกเขา ดังนั้นฉันจึงหันไปหาหนังสือและอินเทอร์เน็ต มากที่สุดเท่าที่เป็นไปได้ฉันได้พบนางแบบใน Martin Fowler ลุง Bob Martin และคณะ และเมื่อเร็ว ๆ นี้ในชุมชน SO! มันเป็นสถานที่ที่ยอดเยี่ยมในการเรียนรู้ "ผู้ให้บริการการตรวจสอบความจริง" ที่มีศักยภาพ ประสบการณ์การถ่อมตนเปิดเผยขอบเขตและความรู้ของคน ๆ หนึ่งอาจทำได้ยาก แต่ดีต่อสุขภาพของฉันมาก
PéterTörök

2

คำตอบที่ยอดเยี่ยมโดยPéterTörökเพื่อเน้นว่าคุณจะจัดการสิ่งนี้กับคนดีส่วนใหญ่เท่านั้น เมื่อคุณมีคนดีแล้วคุณต้องตั้งเป้าหมายแครอทให้มากกว่าที่จะทำ ให้อำนาจผู้พัฒนาปล่อยให้พวกเขาเป็นเจ้าของโครงการ / งานและส่งเสริมการแข่งขันในด้านคุณภาพบางทีอาจมีคนเสนองานสั้น ๆ เกี่ยวกับวิธีที่พวกเขาปรับปรุงคุณภาพในโครงการ นักพัฒนาที่ดีจะมีแรงจูงใจในการสร้างความประทับใจให้กับเพื่อนร่วมงาน


+1 คะแนนที่ดีเกี่ยวกับแรงจูงใจ เห็นได้ชัดว่าฉันเข้าใจผิดเกี่ยวกับคนส่วนใหญ่; ฉันอัปเดตคำตอบเพื่อชี้แจง
PéterTörök

2

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

โดยเฉพาะอย่างยิ่ง:

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

1

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

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

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

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

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