อะไรที่ทำให้การพัฒนาซอฟต์แวร์ Agile น่าดึงดูด

การพัฒนาซอฟต์แวร์ Agile กลายเป็นคำศัพท์ที่สนุกมากในทุกวันนี้

ในฐานะนักพัฒนาฉันเข้าใจถึงคุณค่าในทางปฏิบัติของการพัฒนาซ้ำ ๆ แต่บ่อยครั้งที่มันไม่ใช่ตัวเลือกของนักพัฒนาที่จะยอมรับแนวทาง Agile ในการพัฒนาซอฟต์แวร์ มันเป็นตัวเลือกการจัดการจากบนลงล่าง! ไม่ว่าจะเป็นคริสตัลวิธีการว่องไว dsdm, rup, xp, scrum, fdd, tdd คุณตั้งชื่อมัน มันไม่ใช่ตัวเลือกสำหรับนักพัฒนา

สำหรับผู้จัดการทุกคนที่นั่นอะไรคือเหตุผลที่ดีที่สุดสำหรับการเลือกที่จะพัฒนา Agileเมื่อผู้จัดการของฉันส่วนใหญ่ไม่ได้สัมผัสกับรหัสในชีวิตของพวกเขา (ในประสบการณ์ของฉัน)

ความต้องการแบบเลื่อนส่งเร็ว

Agile ดึงดูดความสนใจเนื่องจากมีความเป็นไปได้ที่จะปรับตัวเข้ากับความต้องการที่เปลี่ยนแปลงได้เร็วขึ้น (หรือเลย) และส่งมอบการเปลี่ยนแปลงเหล่านั้นให้กับลูกค้าได้เร็วขึ้น

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

พวกเขาต้องการพลังของทั้งคู่

ติดตามแนวโน้ม

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

"เกิดอะไรขึ้น Macrojam กำลังทำเปรียวทำไมเราไม่เราไม่ช้าพวกเราว่องไวบ้าบิ่น!"

บางคนไม่ได้ให้คำแปลดีๆ มันเป็นเพียงวิธีการที่จะพิสูจน์การมีอยู่ของพวกเขา Sheeple, เพียร์ดัน, ฯลฯ

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

หากการทำงานที่ดูเหมือนสำคัญเมื่อเริ่มโครงการสามารถยกเลิก midproject และแทนที่ด้วยข้อกำหนดใหม่ที่เกี่ยวข้องมากกว่านั่นคือข้อได้เปรียบที่สำคัญ

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

หวังว่านี่จะช่วยได้

เพิ่มการมองเห็นสิ่งที่เกิดขึ้นและเพิ่มผลผลิต

1. ผู้จัดการมักจะสนใจโดยการนำทัศนวิสัยเปรียวโดยเฉพาะอย่างยิ่งกับการต่อสู้ มันเป็นหนึ่งในจุดขายที่ใช้มากที่สุดในการสัมมนาที่กำหนดเป้าหมายผู้จัดการ

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

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

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

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

คำตอบสำหรับคำถามนั้นสามารถเติมหนังสือได้

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

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

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

ดังนั้นการฝึกฝนที่คล่องแคล่วทำให้ความจริงชัดเจนขึ้นเร็วกว่ามาก

และสุดท้ายทีมเปรียวมักจะใช้แนวทางปฏิบัติที่สร้างคุณภาพรหัสที่ดีกว่าเช่นการพัฒนาด้วยการทดสอบการปรับโครงสร้างบ่อยครั้งการรวมอย่างต่อเนื่องการทบทวนโค้ดคู่ / การเขียนโปรแกรมคู่ ฯลฯ ไม่ว่าโครงการซอฟต์แวร์แบบดั้งเดิมจะห้ามการปฏิบัติเหล่านี้ ไม่มากนัก

ผู้จัดการส่วนใหญ่ยังไม่ได้สัมผัสแม้แต่รหัสในชีวิตของพวกเขา!

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

อะไรคือเหตุผลสำคัญที่สุดในการเลือกที่จะพัฒนาแบบ Agile

• การมองเห็นหรือประสบความสำเร็จอย่างรวดเร็ว / ล้มเหลวอย่างรวดเร็ว - เราเป็นร้านพัฒนาผลิตภัณฑ์ที่มีรอบ 6 เดือนถึง 24 เดือน การพัฒนาซ้ำกับการทำงานคุณสมบัติการทดสอบได้ผลดีกว่าในการสะท้อนสถานะของโครงการ
• การเปลี่ยนแปลง - ในสภาพแวดล้อมของเราความต้องการและเวลามีแนวโน้มที่จะได้รับการแก้ไข แต่ธุรกิจเป็นประจำเกินไปไปอย่างรวดเร็วผ่านการเปลี่ยนแปลงในทิศทางที่สั่นสะเทือน การทำซ้ำการพัฒนาที่มองเห็นได้ทำให้โครงการเปลี่ยนทิศทางได้ง่ายขึ้น
• เรื่องราวตามข้อกำหนดพร้อมการพัฒนาแบบวนซ้ำทำให้ง่ายต่อการทำงานกับธุรกิจที่ไม่เคยเข้าใจแง่มุมทางเทคนิคของข้อกำหนดหรือเข้าใจไดรเวอร์ของธุรกิจอย่างละเอียด ในความพยายามที่ผ่านมาของเราข้อกำหนดระดับสูงหรือเอกสารข้อกำหนดทางการตลาดนั้นไม่เพียงพอเสมอไป ขณะนี้โครงการต่าง ๆ วิวัฒนาการอาจมีตลาดคู่ขนานและการวิจัยลูกค้า
• การเปลี่ยนแปลงกระบวนการมาพร้อมกับคุณลักษณะการพัฒนาอื่น ๆ มากมายเช่น TDD การทดสอบแบบอัตโนมัติและการทดสอบด้วยตนเองรอบการทดสอบที่เข้มงวดมากขึ้น (เราไม่มีกลุ่ม QC อีกต่อไปเพียงกลุ่ม QA) และความซาบซึ้งและความพยายามที่สูงขึ้นเกี่ยวกับคุณภาพ เครื่องมือและตัวชี้วัดอื่น ๆ อีกมากมาย)

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

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

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

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

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

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

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

ฝ่ายบริหารไม่ได้ผลักดันสิ่งเหล่านี้กับนักพัฒนา นักพัฒนาและทีมควรมีความคิดริเริ่มและมุ่งมั่นที่จะทำงานของพวกเขาให้ดีขึ้น งานของฝ่ายบริหารคือการให้การสนับสนุนสำหรับความคิดริเริ่มเหล่านี้

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

ฉันคิดว่าคุณไม่ควรยุ่งกับกระบวนการ Agile และการเขียนโปรแกรม / การพัฒนา ตัวอย่างเช่น Scrum ไม่ได้บอกคุณว่าคุณควรพัฒนารหัสของคุณอย่างไรทุกอย่างเกี่ยวกับกระบวนการที่ยินดีรับการเปลี่ยนแปลง

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