ใน Scrum งานต่างๆเช่นการตั้งค่าสภาพแวดล้อมการพัฒนาและการพัฒนาความสามารถควรได้รับการจัดการเป็นงานย่อยภายในเรื่องราวของผู้ใช้จริงหรือไม่?

บางครั้งในโครงการเราจำเป็นต้องใช้เวลากับงานเช่น:

1. สำรวจกรอบและเครื่องมือสำรอง
2. การเรียนรู้กรอบและเครื่องมือที่เลือกสำหรับโครงการ
3. การตั้งค่าเซิร์ฟเวอร์และโครงสร้างพื้นฐานของโครงการ (การควบคุมเวอร์ชันการสร้างสภาพแวดล้อมฐานข้อมูล ฯลฯ )

หากเราใช้เรื่องราวของผู้ใช้งานนี้ควรจะไปที่ไหน

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

เราคิดเกี่ยวกับปัญหานี้ค่อนข้างมากในปีที่ผ่านมา

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

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

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

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

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

เรายังกำหนดคะแนนเรื่องราวให้กับงานและบางครั้งก็ทำงานกับพวกเขาเช่นเดียวกับที่เราทำกับเรื่องราว

ในที่สุดฉันจะไปแก้ปัญหานี้ในกรณีของคุณ (ซึ่งสามารถนำไปใช้โดยทั่วไปเช่นกัน):

1. แยก "การตั้งค่า" และเนื้อหาทางเทคนิคออกเป็นงาน (สิ่งที่ไม่ได้สร้างคุณค่าทางธุรกิจโดยตรงสำหรับเจ้าของผลิตภัณฑ์)
2. อาจทำข้อเสียก่อนที่จะติดตั้งโครงการเพื่อให้ได้เครื่องมือที่สำคัญที่สุดเข้ามา (SCM, เครื่องมือ dev, การกำหนดกระบวนการ, มาตรฐานการเข้ารหัสเป็นต้น)
3. ยอมรับว่างานเหล่านี้ปรากฏขึ้นในช่วงระยะเวลาของโครงการและวางแผนสำหรับสิ่งนี้โดยแยกกิจกรรมประเภทอื่นที่ไม่ใช่เรื่อง

ทำสิ่งที่สมเหตุสมผลที่สุดใน บริษัท ของคุณ อย่าปล่อยให้คนอื่นทำในสิ่งที่เป็นอุปสรรคต่อสามัญสำนึก

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

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

การถ่ายโอนความรู้เป็นกระบวนการที่ต่อเนื่องซึ่งควรจัดการนอกความเร็วการพัฒนาทั่วไป

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

ทางเลือกหนึ่งคือทำให้พวกเขาเป็นส่วนหนึ่งของเรื่องราวผู้ใช้ครั้งแรกเช่นสร้างโฮมเพจสำหรับแอปพลิเคชัน

แบ่ง "เรื่องราวของผู้ใช้" เป็นแนวคิด ผู้ใช้คนนี้มีส่วนเกี่ยวข้องกับเรื่องนี้? ไม่มี. นี่เป็นงานที่คุณควรทำไปแล้ว

อีกทางเลือกหนึ่งคือทำขัดขวางสำหรับสิ่งนี้

ไม่เลว.

ตัวเลือกที่สามคือการทำให้งานเป็นส่วนหนึ่งของปัญหา (เช่นยังไม่ได้เลือกสภาพแวดล้อมการพัฒนา) แทนที่จะเป็นเรื่องราวของผู้ใช้

ประมาณเดียวกับการขัดขวางเท่าที่การวางแผนและค่าใช้จ่ายมีความกังวล

การตั้งค่าไม่ใช่เรื่องของผู้ใช้

มันเป็นสิ่งที่คุณควรมีก่อนที่คุณจะเริ่มโครงการนี้

คุณไม่สามารถเริ่มโครงการจริง ๆ ได้เว้นแต่คุณจะมีกรอบ / เครื่องมือและการตั้งค่าเซิร์ฟเวอร์และพร้อมที่จะไป

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

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

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

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

ฉันคิดว่าคุณกำลังผสมสองสิ่งที่เป็นอิสระ เรื่องราวของผู้ใช้ไม่ควรมีรายละเอียดทางเทคนิคใด ๆ

ทางเลือกของเฟรมเวิร์กการตั้งค่าที่เก็บและเซิร์ฟเวอร์และงานอื่น ๆ ควรเข้าสู่การวนซ้ำเริ่มต้น

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

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

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

เกี่ยวกับการสำรวจ 2-3 เฟรมเวิร์ก / เครื่องมือ

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

จากนั้นในการเรียนรู้กรอบที่เราเลือกสำหรับโครงการ

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

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

แน่นอนฉันไม่ได้หมายถึงสถานการณ์ที่คุณต้องมองหาปัญหาใหม่บางอย่างในกรอบงานที่คุณใช้หลายครั้ง ฉันหมายถึงสถานการณ์ที่คุณเริ่มใช้ API หรือเฟรมเวิร์กใหม่โดยไม่ใช้เวลาอย่างมีนัยสำคัญ (นอกโครงการ) เพื่อการเรียนรู้

หากคุณละเมิดสิ่งนี้จะปรากฏในความเร็วของคุณต่อไปเพราะคุณจะส่งมอบมูลค่าทางธุรกิจจำนวนน้อยมากต่อการวนซ้ำ หากลูกค้าไม่ทราบเหตุผลเขาอาจยกเลิกโครงการได้

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

ในการตั้งค่าเซิร์ฟเวอร์ (SVN, ฐานข้อมูล ฯลฯ )

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