เราดำเนินโครงการแบบ Agile อย่างไรในฐานะทีมขยายแบบกระจายของลูกค้า

รายงานล่าสุดโดย Computereconomics พบว่าในช่วงปี 2018/19 กระบวนการพัฒนาแอปพลิเคชันได้กลายเป็นช่องทางเดียวที่มองเห็นโอกาสในการเอาท์ซอร์สสูงสุด โดย 56% ขององค์กรทั่วโลกเอาต์ซอร์สตามข้อกำหนดในการพัฒนา

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

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

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

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

เราหมายถึงอะไรโดย Distributed Agile Team  

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

เหตุใดธุรกิจต่างๆ จึงลงทุนในทีมกระจายการพัฒนาแอพมือถือ

มีเหตุผลหลายประการที่ผลักดันธุรกิจให้ลงทุนในทีมแบบกระจาย เหตุผลหลายประการตั้งแต่:

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

ด้วยคำจำกัดความและความต้องการในตอนนี้ ให้เรามาดูว่าทีม Appinventiv ทำงานเป็นทีมแบบกระจายของลูกค้าของเราอย่างไร แต่ก่อนที่เราจะข้ามไปที่นั่น ให้เราดูอย่างรวดเร็วว่า โครงสร้างทีมแบบ Agile แบบกระจาย ทั่วไปของเรา มีหน้าตาเป็นอย่างไร -

Appinventiv Approach เพื่อกระจายการพัฒนา Agile  

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

วิธีที่เรารับประกันการส่งมอบทันเวลาโดยไม่มีขอบเขตของการสื่อสารล่าช้าและความเข้าใจผิดเป็นคำถามที่คำตอบอยู่ใน Distributed Agile Methodology

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

ให้เราดูวิธีการพัฒนาแบบ Agile แบบกระจายที่เรานำไปใช้ในกระบวนการพัฒนาแอพมือถือของเรา

หลังจากที่เราแนะนำสมาชิกในทีมทั้งหมดและทำงานร่วมกันกับซอฟต์แวร์การจัดการโครงการแล้ว งานจริงก็เริ่มขึ้น

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

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

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

อีกแนวทางหนึ่งที่เราปฏิบัติตามสำหรับ กระบวนการ Agile และ scrum ในแต่ละวัน คือสำหรับ scrum ที่แตกต่างกันทุกตัว เราจะแต่งตั้ง scrum master หนึ่งคน ดังนั้น การทำงานเป็นทีมของแต่ละคนในฐานะทีม scrum ที่แยกจากกันโดยมี scrum master และเจ้าของผลิตภัณฑ์ - กระบวนการที่เรียกว่า Scrum of Scrums

ในการนี้ ตัวแทนการต่อสู้ทุกคนให้คำตอบสำหรับคำถามต่อไปนี้ในการต่อสู้ –

• งานที่ทีมทำเสร็จตั้งแต่ Scrum of Scrums ครั้งล่าสุด
• ทีมงานกำลังวางแผนที่จะทำก่อนการประชุม Scrum of Scrums ครั้งต่อไป
• ตัวบล็อคปัจจุบันที่ทีมกำลังเผชิญอยู่
• ตัวบล็อกที่สามารถนำไปสู่ทีม Scrum อื่นได้

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

การเรียนรู้ที่เราวาดโดยการทำงานในกระบวนการพัฒนาแบบ Agile แบบกระจาย

1. การสร้างทีมแบบกระจายคือการสร้างวัฒนธรรมไม่ใช่กระบวนการ

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

2. เฉพาะโครงการ SMART ที่ประสบความสำเร็จ

เมื่อโครงการต้องทำให้เสร็จโดยทีมที่ไม่ได้อยู่ในประเทศเดียวกันนับประสาสำนักงาน เป็นสิ่งสำคัญมากที่เป้าหมายที่คุณตั้งไว้สำหรับโครงการจะต้องเป็นไปตาม SMART – Specific, Measurable, Achievable, Realistic และเวลา -กรอบแนวคิดถึงที

3. ไม่มีเครื่องมือทดแทนสำหรับการทำงานร่วมกันแบบออนไลน์

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

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

ความท้าทายด้วยแนวทาง การพัฒนาแบบ Agile แบบกระจาย และวิธีที่เราแก้ไข

1. ความแตกต่างในวัฒนธรรม

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

2. ความแตกต่างในเขตเวลา

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

3. ขาดแนวคิดทั่วไปเกี่ยวกับ 'ภาพใหญ่'

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

4. การขาดความเป็นเจ้าของรหัส

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

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