คำถามติดแท็ก agile

ฉันหวังว่านี่ไม่ใช่คำถามทั่วไปเกินไป ฉันสามารถใช้คำแนะนำที่ปรุงรสได้จริงๆ ฉันเพิ่งได้รับการว่าจ้างให้เป็น "SW Engineer" แต่เพียงผู้เดียวในร้านค้าเล็ก ๆ ของนักวิทยาศาสตร์ที่ใช้เวลา 10-20 ปีที่ผ่านมาในการปูก้อนกรวดด้วยกันเป็นฐานรหัสที่กว้างใหญ่ (มันถูกเขียนในภาษาที่ล้าสมัยจริง: G2 - คิดว่า Pascal ด้วยกราฟิก) ตัวโปรแกรมเองเป็นแบบจำลองทางกายภาพของโรงงานแปรรูปสารเคมีที่ซับซ้อน ทีมที่เขียนมันมีความรู้เกี่ยวกับโดเมนอย่างไม่น่าเชื่อ แต่มีการฝึกอบรมอย่างเป็นทางการเพียงเล็กน้อยในการเขียนโปรแกรมพื้นฐาน พวกเขาเพิ่งเรียนรู้บทเรียนที่ยากลำบากเกี่ยวกับผลที่ตามมาของการจัดการการกำหนดค่าที่ไม่มีอยู่จริง ความพยายามในการบำรุงรักษาของพวกเขายังถูกขัดขวางอย่างมากจากการสะสม "ตะกอน" ที่ไม่มีเอกสารในรหัสด้วย ฉันจะให้คุณ "การเมือง" ของสถานการณ์ (มีเสมอ การเมือง!) แต่ก็เพียงพอที่จะบอกว่าไม่มีความเห็นเป็นเอกฉันท์เกี่ยวกับสิ่งที่จำเป็นสำหรับเส้นทางข้างหน้า พวกเขาขอให้ฉันเริ่มนำเสนอหลักการบางประการของการพัฒนาซอฟต์แวร์ที่ทันสมัยให้กับทีม พวกเขาต้องการให้ฉันแนะนำวิธีปฏิบัติและกลยุทธ์มาตรฐานอุตสาหกรรมบางประการเกี่ยวกับข้อกำหนดการเข้ารหัสการจัดการวงจรชีวิตรูปแบบการออกแบบระดับสูงและการควบคุมแหล่งที่มา ตรงไปตรงมามันเป็นงานที่ค่อนข้างน่ากลัวและฉันไม่แน่ใจว่าจะเริ่มต้นที่ไหน ในตอนแรกฉันมีแนวโน้มที่จะสอนพวกเขาในบางแนวคิดหลักของThe Pragmatic ProgrammerหรือRefactoringของ Fowler ("Code Smells" ฯลฯ ) ฉันหวังว่าจะแนะนำวิธีการแบบ Agile จำนวนมาก แต่ท้ายที่สุดเพื่อให้มีประสิทธิภาพฉันคิดว่าฉันจะต้องฝึกฝนพื้นฐาน 5-7 หลัก กล่าวอีกนัยหนึ่งอะไรคือหลักการหรือวิธีปฏิบัติที่สำคัญที่สุดที่พวกเขาสามารถเริ่มใช้งานได้อย่างแนบเนียน นั่นคือคำถามของฉัน: สิ่งที่คุณจะรวมไว้ในรายการกลยุทธ์ที่มีประสิทธิภาพที่สุดเพื่อช่วยยืดเส้นสปาเก็ตตี้ออกไป (และป้องกันไม่ให้เกิดขึ้นในอนาคต)

470 project-management  agile  development-process  maintenance  sdlc 

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

133 agile  solo-development 

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

132 agile  scrum  estimation  user-story 

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

111 agile  terminology 

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

110 testing  agile  tdd 

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

109 agile  scrum  scrum-master 

ฉันเป็นนักพัฒนาใหม่ที่ค่อนข้างใหม่จากวิทยาลัย ในขณะที่อยู่ในวิทยาลัยและในระหว่างการหางานฉันพบว่ามีวิธีการพัฒนาซอฟต์แวร์ที่ "ทันสมัย" จำนวนมากที่การศึกษาของฉันขาด: การทดสอบหน่วยการบันทึกการทำฐานข้อมูลให้เป็นมาตรฐานการพัฒนาแบบเปรียว (เทียบกับแนวคิดแบบเปรียวทั่วไป) คู่มือ, การเปลี่ยนโครงสร้าง, การตรวจสอบโค้ด, ไม่มีวิธีการเอกสารที่เป็นมาตรฐาน (หรือแม้กระทั่งข้อกำหนด), ฯลฯ โดยรวมแล้วฉันไม่เห็นว่านี่เป็นปัญหา ฉันคาดว่างานแรกของฉันที่จะโอบกอดความคิดเหล่านี้ทั้งหมดและเพื่อสอนพวกเขาให้ฉันในงาน จากนั้นผมได้งานแรกของฉัน (การพัฒนาเว็บแบบเต็มสแต็ค) ที่เป็น บริษัท ขนาดใหญ่และฉันรู้ว่าเราทำไม่มีสิ่งเหล่านี้ ในความเป็นจริงฉันเป็นคนที่มีประสบการณ์น้อยที่สุดในทีมเป็นคนที่พยายามเป็นหัวหอกในการนำทีมของฉันให้เร็วขึ้นด้วยเทคนิคการเขียนโปรแกรม "ทันสมัย" เพราะฉันกังวลว่าการไม่ทำเช่นนั้นคือการฆ่าตัวตายอย่างมืออาชีพ ก่อนอื่นฉันเริ่มด้วยซอฟต์แวร์การบันทึก (log4J) แต่จากนั้นฉันก็รีบเขียนการแนะนำสไตล์ของตัวเองแล้วละทิ้งมันไปสู่การแนะนำสไตล์ Google - จากนั้นฉันก็รู้ว่าการพัฒนาเว็บ Java ของเราใช้ตัวควบคุมด้านหน้าเขียนด้วยมือ การยอมรับสปริงของเรา - แต่จากนั้นฉันก็รู้ว่าเราไม่ได้ทำการทดสอบหน่วย แต่ฉันก็เรียนรู้ฤดูใบไม้ผลิแล้วและอย่างที่คุณเห็นมันจะท่วมท้นเร็วเกินไปโดยเฉพาะเมื่อจับคู่กับงานพัฒนาปกติ ยิ่งไปกว่านั้นมันยากสำหรับฉันที่จะกลายเป็น "ผู้เชี่ยวชาญ" เพียงพอในวิธีการเหล่านี้ในการสอนคนอื่นในพวกเขาโดยไม่ต้องสละเวลามากเกินไปให้กับพวกเขาคนเดียว จากเทคนิคเหล่านี้ทั้งหมดที่ฉันเห็นว่า "คาดหวัง" ในโลกการพัฒนาซอฟต์แวร์ในปัจจุบันฉันจะรวมพวกเขาเข้ากับทีมในฐานะผู้เล่นใหม่โดยไม่ครอบงำทั้งตัวฉันและทีมได้อย่างไร ฉันจะทำให้ทีมของฉันมีความคล่องตัวมากขึ้นได้อย่างไร มีความเกี่ยวข้อง แต่ฉันไม่ได้เป็นนักพัฒนาแบบ Agile อย่างผู้ถามที่นี่และฉันกำลังดูชุดวิธีการที่กว้างกว่า Agile

106 agile  teamwork 

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

103 agile  self-improvement  scrum 

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

100 agile 

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

89 agile  scrum 

หนังสือและบทความการต่อสู้จำนวนมากบอกว่าการวิ่งล้มเหลว (เมื่อทีมไม่สามารถทำคุณสมบัติบางอย่างจาก Sprint Backlog) ไม่ใช่สิ่งที่เลวร้ายมันเกิดขึ้นเป็นครั้งคราวและมันจะมีประโยชน์จริง ๆ ถ้าทีมเรียนรู้จากความผิดพลาดของพวกเขา และปรับปรุงบางสิ่งบางอย่างในการวิ่งดังต่อไปนี้ และทีมงานไม่ควรถูกลงโทษเนื่องจากไม่ได้ทำงานให้สำเร็จ สิ่งนี้ดูดีมากจากมุมมองของนักพัฒนา แต่สมมุติว่าเรามี บริษัท ซอฟต์แวร์ " Scrum-Addicts LLC " กำลังพัฒนาบางสิ่งสำหรับลูกค้าที่จริงจัง (" Money-Bags Corporation "): ผู้จัดการของ Scrum-Addicts แนะนำให้สร้างชิ้นส่วนของซอฟต์แวร์สำหรับ Money-Bags พวกเขาตกลงในรายการคุณสมบัติและ Money-Bags ขอให้ระบุวันที่จัดส่ง ผู้จัดการ Scrum-Addicts ปรึกษาทีมการต่อสู้ของพวกเขาและทีมบอกว่าจะใช้เวลา 3 สัปดาห์ในการเร่งความเร็วเพื่อให้คุณสมบัติทั้งหมดเสร็จสมบูรณ์ ผู้จัดการ Scrum-Addicts เพิ่ม 1 สัปดาห์เพื่อความปลอดภัยสัญญาส่งซอฟต์แวร์ใน 1 เดือนและเซ็นสัญญากับ Money-Bags หลังจาก 4 sprints (กำหนดส่งพัสดุ) ทีมการต่อสู้สามารถส่งมอบคุณลักษณะ 80% เท่านั้น (เนื่องจากไม่มีประสบการณ์กับระบบใหม่จำเป็นต้องแก้ไขข้อบกพร่องที่สำคัญในคุณลักษณะก่อนหน้านี้ในสภาพแวดล้อมการผลิต …

80 agile  scrum  sprint 

คำถามนี้ได้ทำในหัวของฉันในขณะที่ดังนั้นฉันต้องการถามผู้ที่ปฏิบัติตามเปรียว / ต่อสู้ในสภาพแวดล้อมการพัฒนาของพวกเขา ในที่สุด บริษัท ของฉันได้เริ่มต้นในการผสมผสานการปฏิบัติที่คล่องตัวและเริ่มต้นด้วยทีมนักพัฒนา 4 คนในกลุ่มเปรียวบนพื้นฐานการทดลอง เป็นเวลา 4 เดือนกับการทำซ้ำ 3 ครั้งและพวกเขายังคงทำต่อไปโดยไม่ต้องทำตัวให้คล่องสำหรับพวกเราที่เหลือ เนื่องจากความเชื่อมั่นของผู้บริหารที่จะตอบสนองความต้องการทางธุรกิจด้วยคำขอประเภทแอดฮอพเล็กน้อยจากด้านบน เมื่อเร็ว ๆ นี้ฉันได้พูดคุยกับนักพัฒนาที่เป็นส่วนหนึ่งของความคิดริเริ่มนี้ พวกเขาบอกฉันว่ามันไม่สนุก พวกเขาไม่ได้รับอนุญาตให้พูดคุยกับนักพัฒนาคนอื่นโดย Scrum master ของพวกเขาและไม่ได้รับอนุญาตให้รับสายโทรศัพท์ใด ๆ ในพื้นที่ทำงาน (ซึ่งอาจใช้ได้ในระดับหนึ่ง) ตัวอย่างเช่นถ้าฉันต้องการพูดคุยกับเพื่อนเพื่อเตะที่อยู่ในทีมเปรียวฉันไม่ได้รับอนุญาตหากไม่ได้รับการอนุมัติจากอาจารย์ Scrum; ใครกำลังนั่งถัดจากทีมเปรียว แนวคิดทั้งหมดนี้หรือความคล่องตัวคือการจัดหาสูญญากาศที่สมบูรณ์แบบสำหรับนักพัฒนาที่คล่องตัวจากการหยุดชะงักใด ๆ และเพื่อให้พวกเขาใช้เวลา 6 ชั่วโมงในการผลิตที่ดี เอ่อพวกฉันไม่ใช่กูรูที่คล่องแคล่ว แต่สิ่งที่ฉันได้อ่านเอกสารการเปิดตัวของ Yahoo เปรียวและคล้ายกับองค์กรอื่น ๆ มันทำให้ฉันรู้สึกว่าเปรียวนั้นไม่ถูก ต้องใช้ทรัพยากรและงบประมาณเพื่อปลูกฝังความคล่องตัวในทีมและแก้ไขปัญหาเมื่อพวกเขามาถึงเพื่อนำพวกเขากลับมาในการติดตาม สำหรับผู้เริ่มต้นนั้นจะต้องมีการฝึกอบรมสำหรับนักพัฒนาและผู้ฝึกสอนให้กับผู้จัดการและอื่น ๆ เป็นต้น ... Scrum master ปัจจุบันเป็นผู้จัดการที่ใช้เวลาสองวันในการฝึกอบรมที่ได้รับการจัดการโดยผู้บริหาร ฉันเคยได้ยินในการประชุมว่าแถลงการณ์เปรียวไม่ได้บอกว่าเปรียวไม่ได้ตั้งอยู่ในหินและมีการปรับแต่งแตกต่างกันไปในแต่ละ บริษัท ทุกอย่างฟังดูดีและมีเหตุผล …

80 agile  scrum  methodology 

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

73 agile  cowboy-coding 

ทุกสิ่งที่ฉันได้อ่านและค้นคว้ามาจนถึงจุดนี้อธิบายว่า Agile / Scrum ทำงานได้ดีกับทีมประมาณ 4 ถึง 6 คนอาจจะมากกว่านี้ ในร้านค้าปัจจุบันของฉันเรามีนักพัฒนาประมาณ 8 คนหรือมากกว่านั้น แต่ด้วยลักษณะของปริมาณโครงการและจำนวนแผนกที่เราให้การสนับสนุนเราไม่เคยมีคนมากกว่า 1 หรือ 2 คนที่มอบหมายให้กับโครงการที่กำหนด ฉันยังสามารถใช้ Agile / Scrum กับทีมนักพัฒนา 1 หรือ 2 คนได้หรือไม่? ฉันกำลังพยายามทำให้ผู้จัดการของฉันเริ่มทำงานกับวิธีการนี้ แต่ฉันต้องสามารถอธิบายวิธีลดขนาดสำหรับทีมนักพัฒนาขนาดเล็กหรือโน้มน้าวพวกเขาเพื่อให้แน่ใจว่าเราได้สมาชิกเพิ่มขึ้น โครงการ.

63 scrum  methodology  agile 

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

61 agile  project-management  scrum  requirements