กำจัดความว่องไวที่แท้จริงจาก buzzword agile ในการสัมภาษณ์ [ปิด]

ฉันได้สัมภาษณ์ co-ops (ฝึกงานที่ได้รับค่าจ้าง) เมื่อเร็ว ๆ นี้และ บริษัท จำนวนมากที่ฉันสัมภาษณ์ด้วยบอกว่าพวกเขาใช้ Scrum หรือวิธีการแบบเปรียวอื่น ๆ (การต่อสู้ที่ได้รับความนิยมมากที่สุด) ฉันรู้ว่ามีร้านค้าเปรียวที่แท้จริงและมีสถานที่ที่บอกว่าพวกเขาใช้วิธีการเปรียว แต่จริงๆแล้วก็ทำอย่างอื่นและใช้เปรียวเป็นคำศัพท์

คำถามของฉันคือคำถามอะไรบ้างที่ฉันสามารถถามในการสัมภาษณ์ซึ่งจะแยกร้านค้าเหล่านี้ออก?

แก้ไข: ในขณะที่ฉันกำลังมองหาการฝึกงานฉันรู้สึกว่าคำถามเหล่านี้เกี่ยวข้องกับทุกคน ส่วนการฝึกงานเป็นบริบท

ฉันมักจะเริ่มต้นด้วยการถามคำถามนี้:

ระยะเวลาของการทำซ้ำของคุณคืออะไร?

ให้คะแนนคำตอบ:

1 สัปดาห์ยอดเยี่ยม 2 สัปดาห์ยอดเยี่ยม 3 ใช้ได้และ 4 ปานกลาง นานกว่านั้นบ่งบอกว่าพวกเขากำลังดิ้นรนและมากกว่านั้น 8 สัปดาห์ก็แปลก หากคำตอบมันขึ้นอยู่กับว่าคุณรู้ว่าพวกเขาไม่มีเงื่อนงำใด ๆ

ตามด้วย:

คุณปล่อยบ่อยแค่ไหน?

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

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

ถามพวกเขาว่าทำไมพวกเขาใช้มัน

คุณจะรู้ทันที

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

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

วิธีที่ฉันใช้จริง ๆ แล้วเกี่ยวข้องกับ buzzwords ที่คล่องแคล่วเพียงเล็กน้อย แต่ก็เกี่ยวข้องกับการปฏิบัติที่คล่องตัว หนึ่งใน commonalities ในทีมเปรียวทั้งหมดคือการทำซ้ำสั้น ๆ คนส่วนใหญ่ได้รับส่วนนั้น (เป็นหนึ่งใน12 หลักการที่อยู่เบื้องหลังเปรียวบนเว็บไซต์http://agilemanifesto.org ) จุดประสงค์ของการทำซ้ำสั้น ๆ คือการรับข้อเสนอแนะก่อนหน้าเกี่ยวกับคุณภาพของซอฟต์แวร์ที่พัฒนาขึ้น นี่คือที่ฉันเริ่มต้น

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

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

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

มีหลายสิ่งที่แยกผู้ที่ "กำลังทำ" เปรียวจากผู้ที่เปรียว:

• ถามเกี่ยวกับการรวมอย่างต่อเนื่องหากพวกเขาไม่ได้ใช้ CI หักคะแนน เพิ่มจุดถ้าพวกเขาเป็น คะแนนพิเศษ:
  1. เพิ่ม 1 หากพวกเขาใช้การส่งสองเฟส (รหัสจะต้องสร้างสำเร็จก่อนที่นักพัฒนาจะสามารถเช็คอินได้)
  2. เพิ่ม 1 หากสคริปต์การสร้างรวมถึงการเรียกใช้ชุดทดสอบ
  3. เพิ่ม 1 หากบิลด์ล้มเหลวหากรหัสครอบคลุมต่ำกว่าเกณฑ์ที่กำหนด
  4. เพิ่ม 2 หากเป็นไปได้ที่จะปรับใช้แอปพลิเคชันเพื่อให้พร้อมใช้งานในคลิกเดียว
• ถามเกี่ยวกับ TDD (การพัฒนาที่ทดสอบด้วยการทดสอบ) ลบ 2 คะแนนถ้าพวกเขาไม่ใช้ TDD เพิ่ม 1 ถ้าพวกเขาทำ
• ถามเกี่ยวกับการทำซ้ำพวกเขานานแค่ไหน (ลบ 2 คะแนนหากพวกเขาไม่ได้ทำซ้ำการพัฒนาลบ 1 ถ้าการทำซ้ำนานกว่าเดือนหรือน้อยกว่าสองสัปดาห์เพิ่ม 1 ถ้า 2 สัปดาห์)
• ถามว่าการประเมินเสร็จสิ้นแล้วเพิ่ม 1 หากพวกเขาใช้คะแนนเรื่องราวเพิ่ม 2 ถ้าพวกเขาวางแผนโป๊กเกอร์หรือสิ่งที่คล้ายกันลบหนึ่งถ้าพวกเขาใช้การประมาณเวลาสัมบูรณ์ลบ 2 หากนักพัฒนาไม่ได้มีส่วนร่วมในกระบวนการประเมิน
• ถามว่าสร้างฟีเจอร์ได้อย่างไรเพิ่ม 1 หากนักพัฒนารับผิดชอบต่อคุณสมบัติจากบนลงล่าง (เสี้ยวแนวตั้ง) ลบ 1 หากผู้พัฒนารับผิดชอบเลเยอร์เฉพาะ (ฝานแนวนอน)

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

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

ดังนั้นคุณขอพูดคุยกับนักพัฒนาที่แท้จริงและถามสิ่งต่าง ๆ เช่น:

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

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

ไม่ยอมรับทฤษฎีไม่ยอมรับโครงการของผู้อื่นมีเพียงสิ่งที่พวกเขาทำงานและสามารถพูดคุยเกี่ยวกับประสบการณ์มือแรก

พวกเขาจะต้องเป็นคนโกหกที่น่าทึ่งอย่างน่าทึ่งเพื่อให้สามารถทำสิ่งต่าง ๆ มูลค่า 10 - 15 นาทีที่จะผ่านคุณไปหากคุณรู้จักสิ่งของของคุณ

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

ใครเป็นผู้รับผิดชอบในการเขียนข้อกำหนด / ข้อกำหนดสำหรับโครงการซอฟต์แวร์ของคุณ

ฉันเคยเห็น บริษัท หลายแห่งที่อ้างว่าคล่องแคล่วและต้องการใบรับรอง Scrum Master อธิบายถึงกระบวนการออกแบบขนาดใหญ่ด้านหน้าเมื่อคุณถามเกี่ยวกับกระบวนการรวบรวมความต้องการ

สิ่งที่ชัดเจนสำหรับฉันคือคุณกำลังมองหาการฝึกงานซึ่งทำให้ฉันสงสัยว่าจุดประสงค์ของคุณคืออะไรในการถามคำถามเหล่านี้ คุณพยายามถามคำถามเกี่ยวกับความคล่องตัวเพื่อให้การสัมภาษณ์เป็นไปด้วยดีหรือไม่หรือคุณจะปฏิเสธข้อเสนอจาก บริษัท ที่ใช้ buzzword agile หรือไม่? หากคุณกำลังมองหาสภาพแวดล้อมที่คล่องตัวให้เลือกคำถาม (ทำไมคุณถึงใช้ความคล่องตัวเวลาที่ยอดเยี่ยมของคุณเวลาทำซ้ำอะไรก็ตาม) และถามทางโทรศัพท์หรืออีเมลโดยไม่ต้องเสียเวลา สัมภาษณ์. หากคุณกำลังมองหารายได้รอการสัมภาษณ์และถามคำถามที่แสดงความรู้ / ความตื่นเต้นของคุณเกี่ยวกับวิธีการที่คล่องตัว (บอกฉันเกี่ยวกับระยะเวลาการพัฒนาซอฟต์แวร์ของคุณ) โดยไม่ต้องอายผู้สัมภาษณ์หากพวกเขาใช้สิ่งที่น่ารังเกียจแบบกึ่งคล่องแคล่ว

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

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

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

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

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

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

• ให้สถานการณ์แก่พวกเขาและขอให้พวกเขาแก้ปัญหาด้วยความคล่องตัว
• ถามพวกเขาเกี่ยวกับวิธีปฏิบัติที่พวกเขาชอบเปรียว (วางแผนโป๊กเกอร์, เขียนโปรแกรมคู่, bdd / tdd, kanban);
• ถามพวกเขาว่าทำไมพวกเขาถึงไม่เลือกหรือย้ายจากที่อื่นวิธีการ (น้ำตกแร็พ ฯลฯ )
• คนที่รู้จักมากที่สุดในโลกของวิธีการแบบเปรียวคือใครเป็นคนบัญญัติศัพท์และเขียนหนังสือยอดนิยมมากที่สุดเกี่ยวกับเรื่องนี้

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

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

ถามพวกเขาว่าพวกเขาจัดการกับการออกแบบอย่างไร หากพวกเขาบอกคุณว่าไม่มีการออกแบบที่คล่องตัวพวกเขาจะไม่ได้รับมัน

ถามพวกเขาว่าพวกเขาจัดการข้อกำหนดที่เปลี่ยนแปลงได้อย่างไร หากดูเหมือนว่าข้อกำหนดที่เปลี่ยนแปลงนั้นมีกระบวนการของตัวเองพวกเขาอาจไม่ได้รับมัน

หากพวกเขาอ้างว่าใช้ Scrum ให้ดูว่าพวกเขาเขียนมันอย่างไร ร้านค้าที่ทำในการต่อสู้แย่งชิงกันมักจะรู้ดีพอที่จะเขียนมัน คำแนะนำ: มันไม่ใช่ SCRUM

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

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

ถาม: "ให้ตั๋วกองไว้ในตอนต้นของการวิ่งอธิบายขั้นตอนการทำงานของคุณจากที่นี่"

ประเด็นสำคัญที่ควรฟังที่นี่:

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

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