นักพัฒนา (รุ่นน้อง) ควรพยายามผลักดันกระบวนการและแนวทางปฏิบัติที่ดีขึ้นในการพัฒนา / ทีมไอทีหรือไม่

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

ทีมของฉันค่อนข้างเล็กและค่อนข้างใหม่ (<3 ปี) พวกเขาขาด:

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

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

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

คำตอบที่ดีจนถึงตอนนี้ แต่พวกเขาไม่ครอบคลุมฐานทั้งหมด

จากประสบการณ์ของฉันคนจำนวนมากที่เพิ่งออกจากมหาวิทยาลัยมีความรู้ทางทฤษฎีที่ยอดเยี่ยม - ดีกว่าฉันหรือผู้อาวุโสอื่น ๆ ที่มีซอฟต์แวร์สร้างชีวิตเป็นเวลาหลายสิบปี

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

ในกรณี: แอปพลิเคชันที่ฉันทำงานเมื่อนานมาแล้วได้รับการออกแบบโดยนักทฤษฎี OO ที่ยอดเยี่ยมได้รับการออกแบบมาเพื่อให้เป็นไปตามหลักการและทฤษฎีของ OO กับ T โดยมีรูปแบบมากมายที่ใช้ทุกที่

มันเป็นการออกแบบซอฟต์แวร์ที่ยอดเยี่ยม

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

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

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

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

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

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

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

ใช่ แต่ด้วยความใส่ใจมากมาย!

ผมขอชี้แจงว่า

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

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

ปัญหา

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

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

ทางข้างหน้า

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

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

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

ตอนนี้มีสามสิ่งที่เกิดขึ้น:

• คุณได้ปรับปรุงระบบ
• คุณได้รับประสบการณ์เกี่ยวกับวิธีการเปลี่ยนระบบ
• ทีมเห็นว่าคุณเปลี่ยนระบบสำเร็จแล้ว

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

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

ใช่คุณสามารถ. แต่...

คุณจะต้องระมัดระวัง.

ที่จุดเริ่มต้นของอาชีพของฉัน (นานมาแล้ว) ฉันโชคดี / โชคไม่ดีที่ได้เข้าร่วมโปรเจคอายุสองสามเดือนในฐานะ "จูเนียร์"

อย่างแรกที่ฉันสังเกตเห็นมี (OMG) ไม่มีที่เก็บรหัส! การรวมรหัสทั้งหมดทำได้ด้วยตนเองโดยการส่งไฟล์ซิปให้กันทางไปรษณีย์

ดังนั้นฉันไปที่ผู้จัดการ (ใหม่) ของฉันและแนะนำว่าเราควรมีที่เก็บ คำตอบคือ: ตกลงจัดการมัน ....

ดังนั้นการจัดระเบียบที่เก็บรหัสโดยไม่มีความช่วยเหลือเป็นเรื่องใหม่ใน บริษัท ตอนนี้นั่นเป็นประสบการณ์ที่ไม่ดี

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

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

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

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

ทั้งทีมจะต้องสอดคล้องกัน

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

เช่นเดียวกับด้วยรหัสสิ่งเดียวกันสำหรับกระบวนการพัฒนา: จำเป็นต้องมีการปรับปรุงอย่างต่อเนื่อง

ใช่คุณควรพยายามปรับปรุงซึ่งเป็นไปได้ที่จะปรับปรุง

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

มันคุ้มค่ากับความพยายามของนักพัฒนา (รุ่นน้อง) ที่จะลองและผลักดันสิ่งที่กล่าวมาข้างต้นเมื่อเวลาผ่านไปหรือไม่?

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

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

เพราะในที่สุดถ้าคุณไม่ได้เป็นส่วนหนึ่งของการแก้ปัญหาคุณเป็นส่วนหนึ่งของปัญหา

ใช่. แต่การเปลี่ยนแปลงขององค์กรนั้นยากสำหรับผู้อาวุโสดังนั้นหากคุณต้องการสร้างความแตกต่างให้ทำในสิ่งที่ถูกต้อง:

• ไม่ใช่ในช่วงสัปดาห์แรก:ใช้เวลานี้เพื่อ:

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

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

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

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

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

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

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

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

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

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

ใช่. แต่ไม่ใช่สิ่งที่คุณแนะนำ

การทดสอบหน่วย / การรวมเข้าด้วยกันเป็นรายการเดียวที่คุณสามารถดำเนินการต่อได้

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

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

ฉันจะแนะนำสิ่งต่าง ๆ เช่นการตั้งค่า CI ไปป์ไลน์การปรับใช้แบบอัตโนมัติการกำหนดเวอร์ชันไลบรารี่บรรจุภัณฑ์และสิ่งที่ดีสำหรับการโจมตี

ขึ้นอยู่กับ:

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

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

อย่าเริ่มต้นด้วยสิ่งที่ซับซ้อนที่สุดเช่นการต่อสู้ เริ่มต้นด้วยขั้นตอนที่ง่ายที่สุดเท่าที่จะทำได้

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

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

สำหรับการต่อสู้ควรอ่านเกี่ยวกับ "Extreme Programming" (XP) Scrum ขึ้นอยู่กับแนวคิดหลายประการของ XP และเพิ่มกระบวนการที่เป็นทางการรอบตัวพวกเขา - แนวคิดของ XP ยังคงสามารถใช้งานได้หากไม่มีกระบวนการนั้น

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

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

ในการเริ่มต้นถามคำถาม

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

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

แทนที่สิ่งต่าง ๆ ใน [วงเล็บ] ตามความเหมาะสมเพื่อทำให้คำถามเหมาะสมหรือจัดลำดับความสำคัญของคุณ พิจารณาการเขียนใหม่หากข้อความของฉันไม่ตรงกับสไตล์ของคุณ

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

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

หลังจากนั้นทำตามขั้นตอน

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

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

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

ขอให้เจ้าของผลิตภัณฑ์ (ที่คุณระบุ) เขียนคำอธิบายว่าพวกเขาคิดว่าผลิตภัณฑ์ของพวกเขาควรจะทำงานได้อย่างไรในตอนนี้และในอนาคต

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

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

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

ในที่สุดคุณจะอาวุโส

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

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

ทางออกที่นำเสนอ :

1) เมื่อใดก็ตามที่คุณเห็นบางสิ่งที่คุณรู้สึกว่าควรปรับปรุงให้จดบันทึกไว้! (ในโน้ตบุ๊กในบันทึกดิจิทัล ... )

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

ตอบช้าและยอมรับเนื้อหาที่ดีมากมายในคำตอบอื่น ๆ

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

• การสร้างการเปลี่ยนแปลงทางวัฒนธรรมเป็นเรื่องยาก
• มากกว่าดังนั้นถ้าคุณเห็นว่าเป็น "จูเนียร์"

ทุกสิ่งทุกอย่างสามารถปฏิบัติตามหากมีวิธีการในการบรรลุการพัฒนาอย่างต่อเนื่อง

แนวทางของฉันในการบรรลุเป้าหมายนั่นคือ:

• กระบวนการและขั้นตอนที่ทำเป็นเอกสาร
• Retrospectives กับทีมที่มีการดำเนินการเปลี่ยนแปลงเอกสารกระบวนการ

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

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

บางทีคุณอาจเริ่มด้วยบทสนทนาแบบเฉพาะกิจแล้วแนะนำพิธีกรรมปกติ

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

ข้อควรพิจารณาบางประการ:

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