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

การพัฒนาซอฟต์แวร์แบบ Agile เป็นกลุ่มของวิธีการพัฒนาซอฟต์แวร์บนพื้นฐานของการพัฒนาแบบวนซ้ำและแบบเพิ่มขึ้นซึ่งความต้องการและการแก้ปัญหามีวิวัฒนาการผ่านการทำงานร่วมกันระหว่างทีมที่จัดระเบียบเองและข้ามสายงาน

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

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

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

6
การรักษาความคล่องตัวด้วยนโยบาย zero-bug / defect
ในโครงการของเราเราทำงานในวิธีการ zero-bug (aka ศูนย์บกพร่อง) แนวคิดพื้นฐานคือข้อบกพร่องมักจะมีความสำคัญสูงกว่าคุณสมบัติ หากคุณกำลังทำงานกับเรื่องราวและมีข้อบกพร่องจะต้องได้รับการแก้ไขเพื่อให้เรื่องราวได้รับการยอมรับ หากพบข้อผิดพลาดในระหว่างการวิ่งเพื่อเล่าเรื่องราวที่เก่ากว่าเราต้องใส่มันไว้ใน Backlog ของเราและแก้ไขมัน - ลำดับความสำคัญสูงสุด เหตุผลที่ฉันพูดแก้ไขคือเราไม่ได้แก้ไขข้อผิดพลาด บางครั้งเราเพิ่งประกาศว่า "จะไม่แก้ไข" เนื่องจากไม่ใช่สิ่งสำคัญ ทั้งหมดมันฟังดูดี เรากำลังจัดส่งผลิตภัณฑ์คุณภาพสูงและอย่าพก "a hump" ในรูปของ backlog ขนาดใหญ่ แต่ฉันไม่แน่ใจว่าวิธีนี้ถูกต้อง ฉันมักจะเห็นด้วยว่าเราต้องแก้ไขข้อผิดพลาดที่ร้ายแรงโดยเร็วและเราจำเป็นต้องทิ้งข้อบกพร่องที่ไม่น่าสนใจออกไป แต่สิ่งที่เกี่ยวกับข้อบกพร่องที่มีความสำคัญ แต่ไม่สำคัญเท่ากับคุณลักษณะใหม่ ฉันมักจะคิดว่าพวกเขาควรจะยื่นใน backlog ด้วยความสำคัญที่เหมาะสม ฉันจะยกตัวอย่างเพื่อให้ชัดเจน - ในโครงการของฉันเราทำงานกับ UI ที่เขียนด้วยเฟล็ก เรามีหน้าจอตัวช่วยสร้างที่เปิดขนาดเดียวกันสำหรับทุกความละเอียดหน้าจอ ปรากฎว่าเมื่อเราขยายหน้าต่างตัวช่วยสร้างหน้าใดหน้าหนึ่งดูไม่ดี (มีแถบเลื่อนแนวตั้งที่ไม่หายไปแม้ว่าตัวช่วยสร้างจะสามารถแสดงทุกอย่างได้ในขณะนี้และไม่ต้องการแถบเลื่อน) ฉันคิดว่าข้อผิดพลาดนี้น่าเกลียด ฉันแน่ใจว่าจะต้องแก้ไข แต่เราอยู่ในช่วงเวลาที่ จำกัด และเรามีฟีเจอร์มากมายที่เรากลัวว่าจะไม่ทำให้ถูกตัดและเข้าสู่รุ่น ฉันรู้สึกว่าเราสามารถมีชีวิตอยู่กับข้อผิดพลาดดังกล่าว จำเป็นต้องได้รับการแก้ไข แต่มีลำดับความสำคัญต่ำกว่าคุณลักษณะอื่น ๆ (ดังนั้นในกรณีที่เราไม่สามารถดำเนินการให้เสร็จได้อย่างน้อยเราก็ไม่ได้ทิ้งคุณลักษณะที่สำคัญอื่น ๆ ไว้) แต่, …
18 agile  scrum  bug  backlog 

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

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

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

5
"ทีมข้ามสายงาน" คืออะไร? [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ความหมายทั่วไปของ "cross-functional team" เป็นทีมที่รวมผู้เชี่ยวชาญในสาขาต่าง ๆ ที่จำเป็นเพื่อให้บรรลุเป้าหมาย แต่ดูเหมือนว่าในฟังก์ชั่นไขว้ของ Agile ไม่เพียง แต่หมายรวมผู้เชี่ยวชาญที่แตกต่างกันเท่านั้น Henrik Kniberg กำหนดทีมข้ามสายงานด้วยวิธีนี้: "Cross-functional เพียงหมายความว่าทีมโดยรวมมีทักษะทั้งหมดที่จำเป็นในการสร้างผลิตภัณฑ์และสมาชิกในทีมแต่ละคนเต็มใจที่จะทำมากกว่าสิ่งที่ตัวเองทำ" แต่สายลากอยู่ที่ไหน เป็นเรื่องปกติหรือไม่ที่จะขอให้ผู้พัฒนาทำการทดสอบซ้ำถ้าจำเป็น?

6
นักแปลอิสระสามารถใช้การพัฒนาที่คล่องตัวได้หรือไม่?
ฉันต้องการปรับปรุงวิธีการพัฒนาซอฟต์แวร์ ฉันต้องการที่จะพัฒนาเร็วขึ้นและเป็นรหัสที่ยอดเยี่ยม! วันนี้ฉันใช้วิธีน้ำตกเป็นอิสระเขียนเนื้อหาเว็บ (เว็บไซต์ระบบ ฯลฯ ) มีวิธีใช้การพัฒนาแบบว่องไว (XP, SCRUM และอื่น ๆ ) ทำงานด้วยวิธีนี้หรือไม่? ฉันไม่รู้อะไรเลยเกี่ยวกับการพัฒนาที่คล่องตัวฉันควรเริ่มจากที่ไหน ขอบคุณมาก.
18 agile  freelancing  scrum  web 

9
ควรรวมเวลาของผู้ทดสอบเมื่อประเมินตั๋วหรือไม่
เมื่อสร้างการประมาณเวลาสำหรับตั๋วควรรวมเวลาที่ใช้สำหรับผู้ทดสอบ (QAs) ไว้ในการประมาณตั๋วหรือไม่ ก่อนหน้านี้เราได้ประเมินไว้เสมอโดยไม่มีเวลาทดสอบ แต่เรากำลังพูดถึงรวมถึงมันเสมอ มันสมเหตุสมผลแล้วสำหรับการวิ่งในปัจจุบันของเราล่าสุดก่อนการเปิดตัวเนื่องจากเราจำเป็นต้องรู้ว่าเวลาทั้งหมดจะใช้เวลาหนึ่งสัปดาห์ ฉันเข้าใจเสมอว่าการประเมินนั้นใช้สำหรับนักพัฒนาเท่านั้นเพราะมันมีแนวโน้มว่าจะเป็นทรัพยากรที่ จำกัด ในทีม เพื่อนร่วมงานคนหนึ่งบอกว่าไม่ว่าพวกเขาจะทำงานที่ไหนมาก่อนเวลาทดสอบ เพื่อความชัดเจนนี่เป็นกระบวนการที่นักพัฒนากำลังเขียนหน่วยการรวมและการทดสอบ UI ที่มีความครอบคลุมที่ดี
17 agile  scrum  estimation  qa 

4
Dilemma ของ QA เทียบกับการวนซ้ำ
ใน บริษัท ของฉันเราประสบความสำเร็จในการปฏิบัติงานด้วยความคล่องตัว - แต่ไม่ต้องใช้การทำซ้ำ เหตุผลหลักคือเราไม่สามารถหาวิธีที่สะอาดเพื่อให้เหมาะสมใน QA ในรอบการวนซ้ำ เราเข้าใจว่า QA เป็นบิตของการตรวจสอบเพิ่มเติมสำหรับบิวด์บางตัว (รีลีสผู้สมัคร) ก่อนที่บิลด์นี้จะนำไปใช้กับลูกค้า จุดประสงค์คือเพื่อหลีกเลี่ยงการกระทำที่มุ่งร้ายเพียงอย่างเดียวที่สร้างความเสียหายต่อการเปิดตัวทั้งหมด เนื่องจากคุณไม่เคยรู้ว่าที่หนึ่งมันเป็น QA ต้องรอจนกว่าทุกคุณลักษณะ / กระทำสำหรับการเปิดตัวอยู่ในการสร้าง (ไม่มีคำพูดสุดท้ายที่มีชื่อเสียง "อนุญาตให้เปลี่ยนแปลงเพียงเล็กน้อย") หาก QA พบข้อบกพร่องในตัวเลือกการเปิดตัวนักพัฒนาแก้ไขข้อบกพร่องเหล่านี้ในสาขาการเปิดตัวที่เกี่ยวข้อง (และผสานเข้ากับลำตัว) เมื่อแก้ไขบั๊กทั้งหมดแล้วบิลด์ใหม่จะถูกปรับใช้เพื่อให้ QA ทำการทดสอบอีกครั้ง เฉพาะเมื่อไม่พบข้อบกพร่องในตัวเลือกการเปิดตัวบางอย่างมันจะถูกเสนอให้กับลูกค้าเพื่อการตรวจสอบ โดยปกติจะใช้เวลาประมาณสองถึงสามผู้สมัครประมาณหนึ่งสัปดาห์ต่อการเปิดตัว เวลาในการเขียนการแก้ไขนั้นปกติแล้วจะต่ำกว่าความพยายามในการทดสอบ ดังนั้นเพื่อให้นักพัฒนาไม่ว่างพวกเขาทำงานในการเปิดตัว N + 1 ในขณะที่ QA ทำงานบน N หากไม่มีการใช้การวนซ้ำนี่จะไม่มีปัญหาเพราะเราสามารถซ้อนทับงานสำหรับการปล่อย N และ N + 1 อย่างไรก็ตามจากสิ่งที่ฉันเข้าใจว่าสิ่งนี้ไม่เข้ากันกับวิธีการทำซ้ำเช่น Scrum หรือ XP พวกเขาต้องการให้ทำซ้ำได้ในตอนท้ายด้วยความพยายามในการทดสอบทั้งหมดเพื่อรวมไว้ในการทำซ้ำ …
17 agile  teamwork  qa  sdlc 

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

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

11
การแก้ไขข้อบกพร่องที่ทำโดยคนอื่นเป็นวิธีที่ดีหรือไม่?
สมมติว่าสถานการณ์ที่ทีมสี่นักพัฒนากำลังสร้างแอปพลิเคชัน ในระหว่างขั้นตอนการทดสอบผู้ใช้จะรายงานข้อบกพร่อง ใครควรแก้ไขพวกเขา คนที่ทำรหัสผิดพลาดหรือใครก็ตามที่ว่าง? อะไรคือวิธีการที่ต้องการในการพัฒนาแบบเปรียว (scrum)?
17 agile  debugging 

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.