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

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

ตอนนี้ฉันเริ่มต้น บริษัท ซอฟต์แวร์ที่ไม่มีความต้องการด้านนวัตกรรมที่รุนแรงของกราฟิก 3 มิติฉันต้องการสร้างแนวทางแบบองค์รวมเพื่อการพัฒนามากขึ้น

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

สิ่งนี้ไม่ได้เกี่ยวข้องกับ Agile มากนักหรือแม้แต่กับ Software Engineering มันเป็นเรื่องจริงของ บริษัท ใด ๆ ในธุรกิจใด ๆ : คุณต้องจัดสรรเวลาสำหรับการฝึกอบรม ระยะเวลา

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

แต่นี่ไม่เกี่ยวอะไรกับ Agile นั่นเป็นเพียงแค่สามัญสำนึกและคณิตศาสตร์ระดับประถม

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

นอกจากนี้ยังมีวิธีปฏิบัติแบบ Agile ที่ช่วยในการถ่ายโอนความรู้เช่นเพื่อลดความแตกต่างของระดับความรู้ในทีม:

• Retrospectives รายวัน
• ย้อนหลังต่อการวิ่ง
• ย้อนหลังต่อโครงการ
• การเขียนโปรแกรมคู่
• การจับคู่ ping-pong (การสลับไดรเวอร์และเนวิเกเตอร์หลังจากทุกรอบของวงจรสีแดง - เขียว - refactor)
• จับคู่ promiscuous (ไม่มีคู่คงที่คู่ที่ได้รับมอบหมายแบบสุ่มและเปลี่ยนแปลงทุกเช้าและกลางวัน)
• จำนวนสมาชิกในทีมคี่ (ถ้าคุณจับคู่การเขียนโปรแกรมปล่อยให้สมาชิกในทีมหนึ่งคนสามารถเรียนรู้ได้)
• การเขียนโปรแกรมม็อบ (ตัวแปรในการเขียนโปรแกรมคู่ที่ทั้งทีมใช้คอมพิวเตอร์เครื่องเดียวและหน้าจอสมาชิกในทีมที่กำหนดเป็นเพียง "พิมพ์ดีด" และคนอื่น ๆ บอกเขาว่าจะเขียนอะไร)
• ทีมงานที่หลากหลาย (ผู้พัฒนาจะสุ่มให้กับทีมทุกวัน / ทุกการวิ่ง)

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

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

ฉันจะเห็นด้วยกับสิ่งที่Jörg W Mittag พูดแต่ไม่ใช่ด้วยคำพูดที่ว่า "นี่ไม่ได้เกี่ยวข้องกับ Agile" เทคนิค Agile จำนวนมากสนับสนุนการเรียนรู้และการพัฒนาบุคคลและทีม

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

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

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

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

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

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

ในทางปฏิบัติฉันพบว่ามันเป็นวิธีที่ดีในการจัดการการฝึกอบรมขนาดเล็กอย่างน้อย - เพียงพอที่จะรับ devs ได้เร็วขึ้นด้วยระบบใหม่หรือกรอบงานใหม่ในขณะที่ยังคงรับผิดชอบต่อตาราง

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

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

บางคนพูดถึงแง่มุมต่าง ๆ แล้ว แต่ฉันแค่อยากจะแบ่งปันว่าฉันเหมาะสมกับการพัฒนาส่วนบุคคลในสภาพแวดล้อมที่คล่องตัวอย่างไร

1. การพัฒนาอย่างต่อเนื่อง

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

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

2. ความพยายามมากขึ้นในระหว่างการวิ่ง

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

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

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

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

ขัดขวางเป็นงานวิจัยเกี่ยวกับการวิ่งที่เกี่ยวข้องกับการประเมินความเป็นไปได้ของสิ่งที่มักจะผ่านการเรียนรู้

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

หากต้องการอ้างอิงจากAgile Manifestoเอง:

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

เน้นเป็นของฉันเน้นชิ้นส่วนที่อาจเหมาะสมกับคุณมากที่สุด

ผู้พัฒนาแบบเปรียวที่ผ่านการฝึกอบรมอย่างดีสามารถตอบสนองต่อสภาพแวดล้อมที่เปลี่ยนแปลงได้ดีกว่าผู้ที่ปล่อยให้ทักษะของพวกเขากลายเป็นหิน

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