การสร้างต้นแบบอย่างรวดเร็วนั้นเข้ากับวิธีการแบบเปรียวได้อย่างไร?

ฉันทำงานให้กับ บริษัท ขนาดใหญ่ซึ่งสั่งให้ใช้กระบวนการที่คล่องตัว ตัวอย่างเช่นสำหรับโครงการของเราเราใช้บริการบนคลาวด์ที่มีเป้าหมายเฉพาะในการจัดการการพัฒนาที่คล่องตัว

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

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

อย่างไรก็ตามการสร้างต้นแบบของ Python จะทำให้เรามีข้อบกพร่องมากมายในการทำให้เราสามารถให้ผลลัพธ์ที่แท้จริงได้อย่างรวดเร็ว

คุณสามารถรวมต้นแบบอย่างรวดเร็ว - หวังว่าใน Python เข้ากับเวิร์กโฟลว์ที่คล่องตัวในสภาพแวดล้อมขององค์กรหรือไม่

แนวคิดของ"การสร้างต้นแบบ" ตามที่กำหนดไว้ใน RADนั้นต่างจากการพัฒนาที่คล่องตัว นี่ไม่ได้หมายความว่ามันทำไม่ได้ แต่มันผิดปกติ

มีหลายกรณีที่ต้องสำรวจ:

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

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

3. ต้นแบบเป็นรุ่น 0.x หรือไม่ ผลิตภัณฑ์ที่ทำงาน mininimum ? จากนั้นใช้กระบวนการที่คล่องตัวที่คุณเลือก หากคุณต้องการสร้างมันใหม่ในภาษาอื่นคุณมีแนวโน้มที่จะดีขึ้นถ้าคุณปฏิบัติต่อผลิตภัณฑ์อื่น โปรดทราบว่าบางครั้งสิ่งนี้ถือเป็นวิธีการทางลัดในการเขียนข้อมูลจำเพาะ ("ควรทำเหมือนกับต้นแบบ!") นั่นเป็นวิธีที่ไม่ดีของการจัดทำเอกสารผลิตภัณฑ์ แต่นี่อาจอธิบายได้ดีกว่าว่าเป็นคำถามและคำตอบที่แยกต่างหาก :-)

ไม่ได้สร้างต้นแบบอย่างรวดเร็ว (เช่นซ้ำและการพัฒนาที่เพิ่มขึ้น) การเรียงลำดับของจุดรวมของเปรียว?

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

และ Python ไม่ใช่ภาษาของเล่น นาซ่าและผู้รับเหมาใช้ Pythonและถ้ามันดีพอสำหรับพวกเขามันก็ดีพอสำหรับฉัน

มีการปฏิบัติ stablished ค่อนข้างเป็นมาก Programingเรียกว่าเข็ม ซึ่งหมายความว่ามันเป็นรหัสการทิ้ง ไม่มีอะไรพิเศษอยู่ในนั้น มันเป็นเพียง Sprint ที่ผลลัพธ์ที่คาดหวังคือความรู้เกี่ยวกับรหัสการทิ้ง

ลิงค์ด้านบนมีข้อมูลเพียงพอเกี่ยวกับแนวทางปฏิบัติที่ดีข้อผิดพลาดที่เกิดขึ้น

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

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

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

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

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

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

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

1) ช่วยเหลือการสื่อสาร

2) ให้ผู้ใช้เข้าสัมภาษณ์การแก้ปัญหาและรับข้อเสนอแนะก่อน

ข้อแม้:

การสื่อสารโดยตรงระหว่าง UX และวิศวกรไม่ควรถูกแทนที่ด้วยสิ่งประดิษฐ์ต้นแบบใด ๆ หากเป็นไปได้การจับคู่กับวิศวกรจะทำงานได้ดีกว่าการสื่อสารผ่านตัวกลาง (ต้นแบบ)

คนอื่น ๆ พูดถึงจุดประสงค์การเรียนรู้ของ spikes แล้ว อะไรคือสิ่งที่ขาดหายไปคือพื้นฐานหลักการเปรียวของมันซึ่งเป็นความล้มเหลวอย่างรวดเร็ว

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

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