วิธีการได้รับการฝึกฝนส่วนบุคคลที่วิธีการพัฒนาหนา?

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

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

นอกจากเพียงอยู่ในงานเป็นเวลาหลายเดือน / ปีนั่นคือ

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

ดูเหมือนจะเป็นไปไม่ได้ที่จะทำเดี่ยว มีวิธีที่คนจำนวนน้อยสามารถจำลองวิศวกรรมโครงการขนาดใหญ่ทั้งหมดในขนาดเล็กในระยะเวลาอันสั้น (หนึ่งวัน) หรือไม่?

มีวิธีที่คนจำนวนน้อยสามารถจำลองวิศวกรรมโครงการขนาดใหญ่ทั้งหมดในขนาดเล็กในระยะเวลาอันสั้น (หนึ่งวัน) หรือไม่?

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

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

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

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

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

เลือกโปรแกรมตัวอย่างเพื่อทำงาน หากคุณไม่สามารถทำสิ่งใดสิ่งหนึ่งได้ให้ google "code katas" หรือตรวจสอบการเก็บถาวร codejam ของ Google หรือเพียงแค่สร้างเครื่องคิดเลข :-)

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

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

หลังจากที่คุณวนซ้ำผ่านวงจรการออกแบบ / สร้าง / ทดสอบ / ทำซ้ำหลายครั้งคุณจะได้สร้างทักษะและประสบการณ์ในองค์ประกอบ "เฮฟวี่เวท" ที่คุณกังวลในตอนนี้ การทำซ้ำจะแสดงการเชื่อมต่อระหว่างคุณกับขั้นตอนต่างๆและเอกสารที่สร้างขึ้น บทเรียนที่มีค่าที่แสดงให้เห็นว่าการเปลี่ยนแปลงรหัส 5 นาทีสามารถมีผลกระทบระลอกหลายชั่วโมงที่อื่นเนื่องจากการปรับปรุงเอกสารและข้อกำหนดในการทดสอบ

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

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

โดยทั่วไปการเปลี่ยนแปลงและการจัดการความเสี่ยงนั้นมีรูปร่างที่แตกต่างกันไปในแต่ละองค์กร ทางออกที่ดีที่สุดของคุณคือให้ใจที่เปิดกว้าง แต่อย่าตั้งสมมติฐานมากเกินไปจากทีมหนึ่งไปอีกทีม