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

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

ขอบคุณ!

ในฐานะที่ปรึกษาฉันเข้าใจกฎง่ายๆในการให้คำปรึกษา:

• คุณไม่สามารถช่วยคนที่ไม่ต้องการได้รับความช่วยเหลือ

คุณไม่สามารถทำให้ใครทำอะไรก็ได้ที่พวกเขาไม่ต้องการทำยกเว้นด้วยอำนาจที่คุณไม่มี

ในฐานะโค้ชฉันแนะนำ Agile ด้วยกฎสามข้อ:

1. เป็นไปไม่ได้ที่จะรวบรวมความต้องการทั้งหมดในช่วงเริ่มต้นของโครงการ

2. สิ่งที่ต้องการของคุณจะรวบรวมมีการรับประกันการเปลี่ยนแปลง

3. จะต้องทำมากกว่าเวลาและเงินจะอนุญาต

และหนึ่งเป้าหมาย:

• มอบของมีค่าทุกสัปดาห์

นั่นคือทั้งหมดที่คุณต้องเริ่มต้น

การโน้มน้าวใจผู้จัดการของคุณเป็นอีกเรื่องหนึ่ง

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

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

คุณทำไม่ได้

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

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

หากเขาคิดว่าเป็นการตัดสินใจของเขาเขาจะบ่อนทำลายอำนาจของผู้จัดการฝ่าย IT, ผู้จัดการโครงการ, สถาปนิกด้าน IT, ผู้นำทีมและทีมพัฒนา ดังนั้นเขาควรเขียนซอฟต์แวร์ @ # $% ด้วยตัวเองหรือ STFU และปล่อยให้มืออาชีพทำหน้าที่สมองของพวกเขาโดยไม่มีสมอง

ฉันไม่ได้ล้อเล่น. ถ้าเขาไม่สามารถไว้วางใจให้คุณทำงานของเขาควรจะทำมันเองและคุณควรจะวิ่งหนีไปกรีดร้อง

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

จากนั้นอีกครั้งเขาเป็นผู้จัดการดังนั้นในคำพูดของเขา:

"เราจำเป็นต้องใช้ความยืดหยุ่นในการทำงานร่วมกันเพื่อสร้างโซลูชันการบริการเต็มรูปแบบทันเวลา"

ใช้คำพูดแบบเก่า: คุณสามารถนำม้าขึ้นไปในน้ำได้ แต่คุณไม่สามารถดื่มได้

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

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

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

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

สถานที่ที่ง่ายอาจจะมีประกาศสำหรับการพัฒนาซอฟต์แวร์เปรียว

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

นั่นคือ

• บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ
• ซอฟต์แวร์ทำงานผ่านเอกสารที่ครอบคลุม
• ความร่วมมือกับลูกค้าในการเจรจาต่อรองสัญญา
• ตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน

แต่โปรดดูรายละเอียดในหน้านี้เพื่อรับความตั้งใจอย่างเต็มที่

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

นี่อาจเป็นประโยชน์ - http://www.youtube.com/watch?v=4u5N00ApR_k

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