วิธีการเขียนโปรแกรมใดจะเหมาะกับเรา

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

เราเป็นทีมขนาดเล็กมาก - นักพัฒนาสองคนหนึ่ง DBA หนึ่งคนนักออกแบบหนึ่งคน บริษัท ที่ฉันทำงานเพื่อสร้างรายได้เป็นจำนวนมากเมื่อเทียบกับขนาดของมันและเกือบ 95% ของยอดขายออนไลน์นั้นบริสุทธิ์

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

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

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

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

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

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

พูดกับพวกเขาโอเคเราจะคล่องแคล่วว่องไวเหนือสิ่งอื่นใด: -

• การแยกการพัฒนาและการสนับสนุน
• กระบวนการรวบรวมข้อกำหนดอย่างเป็นทางการ - อยู่ภายใต้การควบคุมของทีมไอที "เรื่อง" ฯลฯ ฟังดูคลุมเครือมาก ๆ - แต่จริงๆแล้วมันเป็นวิธี "ทางการ" ที่แต่งขึ้นเพื่อดูเป็นทางการ
• การตั้งเวลาอยู่ภายใต้การควบคุมของทีมไอที

หากพวกเขาไม่ยอมรับสิ่งนี้บอกพวกเขาว่าคุณไม่สามารถไปได้อย่างคล่องตัว

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

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

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

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

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

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

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

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

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

ดูextremeprogramming.org - XP เป็นรูปแบบของ Agile ที่เข้าใจง่ายซึ่งคุณสามารถเลือกและเลือกรถเข็น เป็นจุดเริ่มต้นที่ดีมาก

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

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

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

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

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

ตอนนี้เพื่อตอบคำถามของคุณเพิ่มเติมโดยตรง:

จากภาพรวมของสภาพแวดล้อมของคุณฉันขอแนะนำให้คุณเลือกใช้ Agile (เช่น Scrum, XP และอื่น ๆ ) ก่อนอื่น จากนั้นปรับแต่งวิธีการเพื่อให้เหมาะกับสภาพแวดล้อมของคุณกำหนดกระบวนการที่ชัดเจนว่าทีมของคุณจะทำงานได้อย่างไรเช่น:

• รับคำขอจากผู้ใช้;

• จัดลำดับความสำคัญคำขอของผู้ใช้

• ประกันผลกระทบของการปรับปรุงในระบบที่มีอยู่ (อาจในระหว่างการประชุมรายวัน / รายสัปดาห์)

• ประเมินเวลาการพัฒนาของการปรับปรุงแต่ละครั้ง - และสื่อสารกลับไปยังผู้ใช้ที่ร้องขอที่หลากหลาย

• ดำเนินการปรับปรุงจริงบนระบบที่มีอยู่ (เช่นการเข้ารหัส)

• ทำการทดสอบผู้ใช้ - และรับภาระผูกพันจากผู้ใช้ (เช่นผ่านอีเมล) ว่าการเปลี่ยนแปลงที่ร้องขอได้ถูกนำไปใช้เรียบร้อยแล้ว

สิ่งนี้ควรจัดเตรียมโครงสร้าง (และลำดับ) บางส่วนในขณะที่ยังคงรักษารูปร่างหน้าตาของวิธีการแบบเปรียว

จากที่กล่าวมาข้างต้นโปรดจำไว้ว่าคำพูดภาษาอังกฤษแบบเก่าที่พูดว่า "ในฐานะที่เปรียวเหมือนลิง" ก็ไม่ได้ประกาศเกียรติคุณโดยไม่มีเหตุผล!

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

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

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

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

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

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

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

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

ขอให้โชคดี

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

ฝ่ายบริหารของคุณระบุว่าพวกเขาสนใจคำใหม่ของ Buzz ส่วนใหญ่มีแนวโน้มว่าพวกเขาจะต้องการใช้เพื่อโฆษณาผลิตภัณฑ์ของคุณ นี่ไม่ใช่สิ่งเลวร้าย แต่จะต้องได้รับการจัดการอย่างระมัดระวังหากคุณต้องการให้วิธี Agile ใช้งานได้สำหรับคุณ

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

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

ฉันขอแนะนำอย่างน้อยที่สุดในการอ่านต่อไปนี้:

• การพัฒนาซอฟต์แวร์แบบลีน - Mary & Tom Poppendieck
• การพัฒนาซอฟต์แวร์แบบว่องไว - Robert C. Martin

และสำหรับเครดิตพิเศษ (เพราะฉันคิดว่ามันเป็นคู่หูที่ยอดเยี่ยมสำหรับหนังสือเล่มอื่น ๆ ที่ฉันพูดถึง):

• ทำความสะอาดรหัส - Robert C. Martin