แบ็กเอนด์ devs วางโดยเรื่องราวของผู้ใช้

ฉันวางแผนที่จะแบ่งการพัฒนาแบ็กเอนด์เข้ากับเรื่องราวของผู้ใช้ในแนวตั้ง แต่คนที่แบ็กเอนด์ในทีมของเราเริ่มบ่นว่านี่ทำให้งานของพวกเขาล่องหน

คำตอบของฉันคือ

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

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

เขายังคงยืนยันที่จะมีเรื่องราวเช่น: "ในฐานะนักพัฒนาฉันต้องมีเลเยอร์โดเมนเพื่อให้ฉันสามารถสรุปทางตรรกะทางธุรกิจได้"

ฉันจะแก้ปัญหาก่อนที่ทีมจะสร้างมลพิษได้อย่างไร

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

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

ความจริงที่ว่ากลุ่มบุคคลในทีมรู้สึกว่าไม่ได้รับความรุ่งโรจน์จากการทำงานทำให้ปัญหาที่เป็นไปได้หลายอย่างประสบความสำเร็จ

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

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

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

สิ่งนี้ดูเหมือนจะเป็นปัญหาทางสังคมดังนั้นจึงต้องมีวิธีแก้ปัญหาสังคม

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

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

ทางออกที่ดีที่สุดน่าจะมีการพูดคุยอย่างเงียบ ๆ กับนักพัฒนา (เป็นรายบุคคลหรือเป็นกลุ่ม) และจัดการกับปัญหาพื้นฐานซึ่งน่าจะเป็นเรื่องที่น่าเคารพ ในบางจุดสิ่งนี้อาจจะต้องเลื่อนระดับไปสู่การจัดการ

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

อันที่จริงนี่คือปัญหา เห็นได้ชัดว่าคุณจะไม่ไขปัญหาด้วยเรื่องราว!

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

วิธีการแก้ปัญหาแบบมาตรฐานสำหรับปัญหานี้คือการนำแนวทาง "แนวตั้ง" หรือ "เต็มสแต็ค" มาใช้ในการพัฒนาโดยที่แบ็คเอนด์ของคุณใช้เรื่องราวจากบนลงล่างแทนการทำงานในโซนสบายของชั้นหลัง ส่วนหน้า devs เช่นเดียวกันยืดไปทางแบ็กเอนด์ (*)

กล่าวอีกนัยหนึ่ง: ทำให้ทุกคนสร้างคุณค่าสำหรับผู้ใช้ของคุณ

^{(*) หมายเหตุ: เรื่องราวทั้งหมดไม่จำเป็นต้องมีองค์ประกอบส่วนหน้าหรือองค์ประกอบด้านหลัง องค์ประกอบ UI สามารถลงตัวโดยไม่ต้องทำงาน back-end เพิ่มเติมและประสิทธิภาพการทำงานที่เป็นคุณลักษณะ}

ปัญหาของคุณคือ:

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

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

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

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

และคุณอาจต้องการเตือนว่า dev ที่คนที่พวกเขาต้องกังวลเกี่ยวกับการเป็นเพื่อนของพวกเขาทันทีไม่ใช่คนที่ clueless เกินไปที่จะวางแผนวิ่ง