ฉันจะติดตามคุณสมบัติที่มีคุณภาพใน Kanban ของทีมของฉันได้อย่างไร

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

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

ฉันจะติดตามความคืบหน้าเกี่ยวกับคุณลักษณะด้านคุณภาพ (หรือการตัดสินใจอื่น ๆ ที่เกี่ยวข้องกับสถาปัตยกรรม) ด้วยการใช้ Kanban ของทีมได้อย่างไร

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

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

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

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

แอตทริบิวต์คุณภาพที่รู้จักนั้นสามารถแสดงเป็น:

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

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

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

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

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

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

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

ตอนนี้มาถึงคำถามที่สอง: เราจะรู้ได้อย่างไรว่าสถาปัตยกรรมยังดี

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

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

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

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

การรักษา "การตัดสินใจโดยปริยายออกมาโดยปริยาย" เป็นส่วนหนึ่งของ Kanban สำหรับแต่ละสถานการณ์อาจช่วยได้

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

วิกรม

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

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

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

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

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

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

PS ตามข้อกำหนดฉันหมายถึงข้อกำหนดสถาปัตยกรรมระดับระบบและไม่จำเป็นต้องเป็นข้อกำหนดระดับแอปพลิเคชันชั่วคราวที่สามารถรองรับได้โดยไม่มีการเปลี่ยนแปลงสถาปัตยกรรมอย่างมาก หวังว่ามันจะช่วย