TLDR; เมื่อฉันบอกว่าฉันไม่ใช่แฟนของโมเดล Feature Teams บางคนอาจคิดว่ามันเป็นผลมาจากการขาดการมอบหมายงาน หรือแม้แต่ความอนุรักษ์นิยมในองค์กร มันไม่ใช่สิ่งนี้ เพื่อประโยชน์ด้านประสิทธิภาพเป็นหลัก ฉันชอบทีม (เช่น ทีมอิสระที่เชี่ยวชาญตามหัวข้อธุรกิจ / บริบทที่มีขอบเขต) แต่ใช้ร่วมกับเทคนิค Swarming เมื่อจำเป็น คำเตือน: โพสต์นี้ยังมีการพูดจาโผงผางเล็กน้อยเกี่ยวกับ Inverse Conway Maneuver ที่น่าอับอาย ;-)

บทความนี้ต่อจากโพสต์ก่อนหน้าของฉัน ( DDD right-wing? )ซึ่งพูดถึงการออกแบบที่ขับเคลื่อนด้วยโดเมนและข้อกังวลต่างๆ ขององค์กร บทความที่ฉันกล่าวถึงสั้น ๆ ว่าฉันไม่ใช่แฟนของ Feature Teams ฉันจะอธิบายที่นี่ว่าทำไม

โลกที่หายไปของ Feature Teams

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

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

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

แต่ปัญหาก็เกิดขึ้นเมื่อ...

ในองค์กรดังกล่าว เราอาจมีทีมฟีเจอร์หลายทีมที่ทำงานพร้อมกันในฟีเจอร์ต่างๆ แต่ทั้งหมดอยู่บนแพลตฟอร์ม/ซอฟต์แวร์เดียวกัน การได้เห็นสิ่งนี้ที่นี่และที่นั่นในประสบการณ์เก่า ๆ หรือกับลูกค้า (เมื่อฉันเป็นที่ปรึกษา) สิ่งนี้สามารถก่อให้เกิด:

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

แท้จริงแล้ว การจัดการกับโดเมนที่ซับซ้อนอาจเป็นเรื่องยุ่งยากหรือนำไปสู่รหัสโดเมนที่ไม่ชัดเจนจำนวนมากด้วย Feature Teams

ดังนั้น. เราจะเผชิญกับความยากลำบากทั้งหมดนี้ได้อย่างไร?

โมเดล “ทีม” ของ Spotify

ไม่แปลกใจเลยที่โมเดลที่เปิดตัวในปีต่อๆ มาคือโมเดล “squads” ของ Spotify สิ่งนี้เริ่มต้นจากแนวคิดของทีมสหสาขาวิชาชีพและมั่นคง (เช่นทีมฟีเจอร์) แต่คนของ Spotify ไปไกลกว่านั้นในแง่มุมของความเป็นอิสระ

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

และอย่าเข้าใจฉันผิด: “ทีม” ไม่ใช่แค่คำศัพท์ที่ “เจ๋ง” เพื่อพูดถึงทีม ทีมคือทีมอัตโนมัติ เราให้ภารกิจแก่พวกเขาที่จะคงอยู่ตลอดไป และเราจะขอให้พวกเขาเป็นเจ้าของโดเมนธุรกิจของพวกเขาด้วยตัวเอง

โดเมนที่ทีมทำงานอยู่ต้องอยู่ในหัวของทุกคน

Team Topologies (โดยMatthew Skelton & Manuel Pais ) เกิดขึ้นไม่กี่ปีหลังจากนั้นพร้อมกับคำว่า "Stream-aligned team" แต่ในขณะที่ฉันพบว่าข้อเสนอของพวกเขาในการลดภาระทางความคิดในทีมนั้นน่าสนใจ โดยการวางขอบเขตบนที่เข้มงวดกับขนาดทีม (“โดเมนที่ทีมทำงานต้องอยู่ในหัวของทุกคน”) ฉันยังคงเลือกใช้ชื่อ “ทีม” เพื่อเป็นตัวแทน เอกราช

หมายเหตุ: การทำงานเกี่ยวกับความเป็นอิสระสำหรับทีมเป็นหนึ่งในความหลงใหลของฉันเมื่อฉันได้พูดคุยเมื่อเร็ว ๆ นี้ที่นี่กับวิธีป้องกันไม่ให้การแสวงหาความเป็นอิสระของทีมกลายเป็นความโกลาหล...

Squads & DDD: คู่หูที่ยอดเยี่ยมในการจัดการกับความซับซ้อนของธุรกิจ

ความเป็นอิสระเป็นพื้นฐานทั่วไประหว่างโมเดล "Squads" และ Domain Driven Design (DDD) แท้จริงแล้ว ข้อหลังนี้แนะนำให้เราจัดซอฟต์แวร์ของเราให้สอดคล้องกับความต้องการของโดเมน และแบ่งผลิตภัณฑ์ของเราออกเป็น "ขอบเขต" ที่เป็นอิสระแต่เชื่อมโยงกันซึ่งเรียกว่า Bounded Contexts (เช่น การบัญชี การขาย การค้นหา ฯลฯ) ขอบเขต/บริบทที่มีขอบเขตเหล่านี้ควรจะให้อิสระและอิสระแก่เรามากขึ้นในการส่งมอบคุณค่า (เช่น เราไม่จำเป็นต้องสร้างผลกระทบและขอความเห็นจากทีมการตลาดโดยเฉพาะเมื่อเราเปลี่ยนแปลงส่วนที่เกี่ยวข้องกับการบัญชี) สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับ DDD คืออะไร คุณสามารถดูสิ่งนี้ ( อธิบายการออกแบบที่ขับเคลื่อนด้วยโดเมนใน 3 นาที )

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

เหนือสิ่งอื่นใด เราต้องการเวลาที่ดีในการทำตลาดและทีมอิสระในการตัดสินใจ ดังนั้นเราจึงปรับสถาปัตยกรรมของเราตามขอบเขตของโดเมนของเรา การมีเจ้าของทีมหลายคนจากบริบทที่มีขอบเขตเดียวกันจะทำให้การตัดสินใจทุกอย่างซับซ้อน BTW Domain Driven Design ตั้งชื่อให้กับสถานการณ์ที่หลายทีมจะแบ่งปันรหัส: เคอร์เนลที่ใช้ร่วมกัน

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

กล่าวโดยย่อ: โดยทั่วไปเราต้องการหลีกเลี่ยงสถานการณ์ที่มีทีมต่างๆ ที่ดูแลส่วนธุรกิจเดียวกันของผลิตภัณฑ์ของเรา

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

ที่เอจิแคป

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

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

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

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

ไม่ว่าคุณจะคิดอย่างไรกับเรื่องนี้ ก็ดูเหมือนจะไม่ใช่ความคิดที่ดีสำหรับฉัน

เราไม่ใช่ "ทรัพยากร" เพื่อผลประโยชน์!

ความปรารถนาของฉันที่จะส่งเสริมทีมอิสระเริ่มต้นขึ้นตั้งแต่กลางปี ​​2000 เมื่อฉันค้นพบ XP (eXtreme Programming) ในที่ทำงาน ฉันสามารถสัมผัสพลังและประสิทธิภาพในท้องถิ่นของทีม XP ที่เป็นอิสระในโครงการนำร่องในวาณิชธนกิจขนาดใหญ่ ประสบการณ์อันน่าทึ่งในหลายระดับ หลายปีหลังจากนั้น ฉันก็สัมผัสได้ถึงความยุ่งยากในการทำงานในองค์กรขนาดใหญ่ที่ไม่เข้าใจไดนามิกของทีมพัฒนาและDynamic Reteaming องค์กรที่ใช้เวลาทำลายทีมของเราครั้งแล้วครั้งเล่าตามโครงการต่างๆ

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

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

(

วงเล็บเล็ก: Inverse Conway Maneuver (ICM)

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

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

บางคนอย่างJohn CUTLERหรือMathias VERRAES ( กฎของคอนเวย์ใช้ไม่ได้กับการออกแบบที่เข้มงวด ) ได้เข้าใจแล้วว่าแนวคิดเช่นการซ้อมรบแบบผกผันของ Conway อาจมีความทะเยอทะยานเกินไปเนื่องจากภาระหน้าที่และทางเทคนิคของสถาปัตยกรรมบางอย่าง:

« สุดท้ายนี้ เป็นเรื่องง่ายที่จะพูดว่า “เพียงแค่เพิ่มพลังให้กับทีมของคุณ!” แม้จะมีเจตนาดีที่สุด แต่นั่นอาจไม่ใช่เรื่องง่าย สถาปัตยกรรมและโครงสร้างองค์กรปัจจุบันของคุณอาจจำกัดตัวเลือกของคุณ » ( John CUTLER — TBM 27/52: ระดับอาณัติ )

พวกเราบางคนยังบอกด้วยว่ากลอุบายนี้ทั้งผิดจรรยาบรรณและไร้เดียงสา เหตุผลที่ฉันพูดถึงการหลอกลวงสำหรับ ICM

ผิดจรรยาบรรณก่อน เพราะเราไม่เล่นแบบนั้นกับผู้คน มนุษย์จริงๆ ในองค์กรของเรา คุณไม่ "ปรับโครงสร้าง" คน คุณไม่ได้เล่นกับคนอื่นเมื่อคุณเล่นกับรหัส

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

)

วงเล็บในฝั่งมนุษย์กำลังทำเสร็จแล้ว กลับมาที่หัวข้อหลักของเรา: สิ่งที่ Swarming สามารถนำมาสู่ทีมที่มีเสถียรภาพและเป็นอิสระ (เช่น Squad)

Swarming: สิ่งพิเศษเล็กน้อยที่เราต้องการสำหรับองค์กร DDD ที่มีประสิทธิภาพ

ไม่เป็นอะไร. ขั้นแรก: มาอธิบายว่า Swarming คืออะไร Swarming เป็นเหมือน Task Force (ดังนั้นเป็นการชั่วคราว) แต่ภายในนั้นเราจะกำหนดไว้ตั้งแต่เริ่มต้นว่าใครจะรับผิดชอบในการสนับสนุนการผลิตของซอฟต์แวร์ที่เป็นผลลัพธ์ (ประเด็นสำคัญยิ่งกว่าถ้าคุณอยู่ใน "คุณสร้าง" เช่นเดียวกับเรา มัน คุณเรียกใช้มัน!” โหมด) มันให้ความกระจ่างเกี่ยวกับการตัดสินใจออกแบบร่วมกันจำนวนมาก และหลีกเลี่ยงสถานการณ์ที่เป็นที่รู้จักกันดีเมื่อยุติกองงาน: “BTW: ใครดูแลการสนับสนุนสำหรับสิ่งนี้ที่เราเพิ่งทำร่วมกัน?!?” (เงียบไปนาน ;-) สำหรับหน่วยเฉพาะกิจ สมาชิกของ Swarming มาจากหลายทีมและจะต้องทำงานร่วมกันเพื่อแก้ปัญหาระยะสั้น (ก่อนที่จะกลับไปที่หน่วยของพวกเขาในตอนท้ายของวัน)

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

ทำไมเราถึงต้องการ Swarming?

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

ฉันเคยเห็นคนจำนวนมากตกหลุมพรางของการหยุดคิดถึงผู้อื่นและมุ่งความสนใจไปที่บริบทที่มีขอบเขตของตนเองเท่านั้น ในทีมของพวกเขาเอง อาจเป็นเรื่องง่ายที่จะลืมว่าเราเป็นส่วนหนึ่งของระบบนิเวศที่แต่ละส่วนมีบทบาทในการเล่นและการโต้ตอบต้องถูกจำกัด (แน่นอน-) (ในแง่ของพื้นผิวรับแสง) แต่ไม่ถูกเพิกเฉย งานของเราต้องมีประโยชน์และนำไปใช้ ทุกคน (PM, devs) ฝันถึงสถานการณ์ที่เราไม่ต้องการให้ทีม/BC อื่นก้าวไปข้างหน้าและสร้างคุณค่า แต่ทุกคนก็ฝัน…

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

Swarming เข้ามาแทรกแซงอย่างแม่นยำในบางกรณีเหล่านี้ ซึ่งเราจำเป็นต้องทำงานเกี่ยวกับการซิงโครไนซ์และการโต้ตอบระหว่างบริบทที่มีขอบเขตตั้งแต่ 2 รายการขึ้นไป

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

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

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

สรุป: ฝูง FTW!

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

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

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

ขั้นตอนถัดไป

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

ฉันต้องการให้เราเริ่มพิจารณาเพลงคู่ของ Continuous Discovery / Continuous Delivery ซึ่งเป็นที่รักของ Marty Cagan และ Jeff Patton การดำเนินการนี้จะช่วยให้เราสามารถทุ่มเทกำลังด้านพลังงานและวิศวกรรมเฉพาะกับแนวคิดที่ผ่านการตรวจสอบโดยลูกค้าของเราได้มากขึ้นเท่านั้น เพื่อปรับปรุงอัตราส่วนต้นทุน/ผลประโยชน์จากการกระทำของเราให้ดียิ่งขึ้น

« เพิ่มมูลค่าสูงสุด ลดความพยายามให้น้อยที่สุด » (เจฟฟ์ แพตตัน)

แต่นั่นจะเป็นเรื่องของโพสต์ในอนาคตฉันเดา

หากต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับ Agicap:

• แสดงโดเมนของคุณให้ฉันเห็น ( เซสชันการมอนิเตอร์กระแสเงินสด & การคาดการณ์แผนที่บริบท )
• https://agicap.com/
• https://career.agicap.com/