เหตุใดฉันจึงต้องใช้ SCRUM กับกระบวนการที่เป็นทางการน้อยลงและมีน้ำหนักเบากว่าสำหรับทีมของฉัน

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

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

• บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ
• ซอฟต์แวร์ที่ทำงานผ่านเอกสารที่ครอบคลุม
• การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา
• ตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน

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

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

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

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

เนื่องจาก Scrum ไม่ได้พูดอะไรเกี่ยวกับวิธีการพัฒนาซอฟต์แวร์ที่ควรทำมันยังทำให้ทีมมีอิสระในการตัดสินใจด้วยตัวเอง (เช่นคุณยังสามารถวิ่งได้โดยใช้วิธีน้ำตกที่อนุรักษ์นิยมตราบใดที่คุณทำที่ สิ้นสุดการวิ่ง)

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

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

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

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

เชื่อหรือไม่ว่ามีทีมซอฟต์แวร์ที่ดีอยู่ก่อนที่ Scrum จะเข้ามา การต่อสู้ช่วยให้คนเลวดีขึ้น

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

ดังนั้นฉันอยากจะพูดในสิ่งที่คนอื่นพูดแล้ว แต่ในภาษาที่ตรงกว่า: เป้าหมายหลักของ SCRUM ไม่ใช่เพื่อจัดการการพัฒนาซอฟต์แวร์เป้าหมายหลักของ SCRUM คือการวัดการพัฒนาซอฟต์แวร์

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

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

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

เป็นต้น

คุณอาจสังเกตเห็นว่าสิ่งต่าง ๆ ข้างต้นส่วนใหญ่ทำสองสิ่ง:

1. พวกเขาวัดงาน ทั้งงานที่ต้องทำหรืองานที่กำลังทำหรืองานเสร็จสมบูรณ์
2. พวกเขาพยายามอย่างหนักเพื่อหลีกเลี่ยงปัญหาของโปรแกรมเมอร์ overoptimistic ที่จะได้รับการประเมินที่ดีขึ้นและสมจริง

ยิ่งคุณใช้ SCRUM นานเท่าไรคุณก็ยิ่งคาดการณ์ได้แม่นยำมากขึ้นเท่านั้น ในความเป็นจริงฉันเองเชื่อว่าการรัน sprints + a backlog + แผนภูมิการเผาไหม้เพียงอย่างเดียวก็เพียงพอที่จะรักษาโปรแกรมเมอร์ส่วนใหญ่ในการทำประมาณการที่ไม่ดีเกี่ยวกับระยะเวลาในการทำบางสิ่งบางอย่าง

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

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

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

PS: การต่อสู้ไม่ได้บังคับว่าการวิ่งของคุณจะต้องมีความยาวสองสัปดาห์ มันอาจเป็นเวลานานหนึ่งเดือน (กรณีของคุณ)

โปรดดูความเห็นของฉันกับคำถามก่อน

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

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

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

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

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

เพียง ... อยู่อย่างคล่องแคล่ว ;-)

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

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

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

เยี่ยมมาก แต่ทั้งหมดดูเหมือนว่าเป็นเรื่องธรรมดาสำหรับฉัน ทำไมถึงต้องมีการประมวลผล?

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

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

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

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

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

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

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

เราไม่ได้ใช้การต่อสู้ในที่ทำงาน เราใช้วิธีการที่ก่อตั้งขึ้นใน Agile และ Lean ซึ่งคล้ายกันในหลายประการ ฉันใช้กระบวนการนี้ในทีมที่มีขนาดต่างกันระหว่าง 3-5 คนรวมถึงผู้นำ แม้ว่าจะมีความแตกต่างฉันคิดว่าคุณอาจจะสามารถช่วยคุณคิดว่าการแย่งชิงเป็นประโยชน์สำหรับสถานการณ์ของคุณ

ทำให้วิธีการสำรวจ

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

เข้าสู่ระบบปิด

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

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

ชิ้นส่วนแนวตั้ง

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

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

การยอมรับ TDD

เราใช้ประโยชน์จากกรอบการทดสอบหน่วยสำหรับการยอมรับ tdd สิ่งนี้ทำให้เราได้รับประโยชน์มากมาย

• การปรับโครงสร้างขนาดใหญ่นั้นไม่ต้องเสียเวลาในการทดสอบซ้ำ
• เรารับรองการทำงานของลูกค้า
• เราครอบคลุมการรวมรหัส
• สนับสนุนการฝึกการพัฒนาในแนวดิ่ง

Build เป็น releasable เสมอ

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

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

บูรณาการอย่างต่อเนื่อง

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

การประมาณแต้มสำหรับการ์ด

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

ความเร็ว

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

การปรับปรุงและออกแบบเพิ่มเติม

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

ส่วนใหญ่เป็นกฎที่เราปฏิบัติตามและทำไมเราจึงปฏิบัติตามกฎเหล่านั้น

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

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

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

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