Agile Sixty-Six Rotating Header Image

Project Management

Blogs about Agile stuff focusing on project management

นิยาย Agile-66 : เร็วไปก็เท่านั้น (ตอน 1)

คำเตือน : บทความต่อไปนี้ เป็นเหตุการ์ณสมมุติเพื่อใช้ยกตัวอย่างประกอบการอธิบายเรื่อง Optimize The Whole ของ Lean อย่าพยายามเอาไปคิดว่ามันหมายถึงใครหรืออะไรในชีวิตจริง

ในบริษัทสมมุติแห่งหนึ่ง ทีมได้รับมอบหมายมาให้ทำโปรโจคสุดยอดสำคัญให้เสร็จภายใน 3 เดือน ทุกคนพากันสงสัยว่าจะทำได้ทันจริงหรือ แต่ estimate ก็ออกมาบอกว่าทำได้ ถึงแม้ velocity จะเป็นสองเท่าของโปรเจคที่เพิ่งทำมาเมื่อเดือนที่แล้วก็ตาม ผ่านไปครึ่งทาง burn-down chart ของทีม DEV และ ทีม TEST ซึ่งต่างก็มี velocity และ estimate เป็นของตัวเองออกมาประมาณนี้

(more…)

T = N/v

ก่อนจะอ่าน post นี้ ให้ไปอ่าน comment ของพี่ Korn4D ใน เอกลักษณ์ Agile แป๊บนะคะ บางส่วนจะตอบที่ QA ไม่ตกงาน
ตอบด้วยคำถาม
- อยู่ดึกเข้ามาทำวันเสาร์ ยังถือว่า time boxed iteration ได้หรือไม่?
- ถ้า unit testing เป็นของ developer และดีพอแล้ว จะมี QA ทำไม?
- ถ้า developer ทำ test แล้วยังต้อง มี QA ทำไมไม่ให้ QA เป็นคนทำ test อย่างเดียว, developer จะได้มีเวลาโค้ดเพื่อสร้าง value ได้มากขึ้น
- ถ้า developer อู้ ทำน้อยแต่โหวตมากๆ จะทำอย่างไร?
- ทำทั้งหมดนี้แล้วจะ commit ได้หรือไม่ว่าทั้งหมดเสร็จเืมื่อไหร่?
หลายข้อที่พี่ถามมา ตอบได้ด้วยสมการนี้ค่ะ
N = ปริมาณ Story Points ทั้งหมดใน Release
v = velocity หรือ average ของจำนวน Story Points ในแต่ละ iteration ที่ผ่านมา
T = จำนวณ iteration ที่จะใช้ในการทำ Release นี้
T = N/v
และ แน่นอน ค่าทั้งหมดนี้ เปลี่ยนแปลงทุก iteration ซึ่งเราต้องยอมรับให้ได้ก่อนว่านี่เป็น เรื่องปกติ

Agile กับ Organizational Behavior

สืบเนื่องมาจากบทความ Playing the Devil’s Advocate ที่ผมได้เข้าไปก่อกวนมา :)

บทความนั้นเริ่มมาจาก status ใน facebook ของพี่ @sinapam ที่กล่าวว่าเราไม่ควรนำเอา story point หรือจำนวน story ที่นักพัฒนาทำได้ มาเป็นตัวชี้วัดผลงาน ผมทำงานในสายพัฒนาซอฟต์แวร์มาตลอด จึงไม่แปลกที่จะเห็นด้วยกับความคิดนี้ แต่พอลองสวมหมวกใบอื่นดูบ้าง หรือ นึกถึงหัวหน้าที่ต้องพิจารณาผลงานของผู้ใต้บังคับบัญชา กลับนึกไม่ออกว่าจะเอาอะไรมาเป็นตัวชี้วัดดี?

ผมตั้งข้อสงสัยไว้อย่างหนึ่ง ว่าทีมอื่นๆทั่วโลกที่ใช้ Agile เขาใช้อะไรเป็นตัวชี้วัด… แหม มันต้องมีสักอย่างสิ! ให้ตายเถิด!!
(more…)

Scrum Alliance — Ask the Coach

อันนี้เป็นบทสัมภาษณ์ ที่ Manoj สัมภาษณ์ Alan Atlas ซึ่งเป็น Agile coach จาก Rally Software นะครับ แล้วผมมาแปลให้อีกที เริ่มกันเลยดีกว่า…

เร็วๆนี้ผมมีโอกาสได้คุยกับ Alan Atlas (Certified Scrum Trainer และ Certified Scrum Coach จาก Rally Software) ในบทสัมภาษณ์ Alan ได้แบ่งปันวิสัยทัศน์เกี่ยวกับสถานะของ Agile และ Scrum นอกจากนี้ Alan ยังได้ลองคาดการณ์อนาคตไว้ด้วย บทสัมภาษณ์นี้ยังมีข้อแนะนำสำหรับการให้คำปรึกษาด้าน agile ทั้งระดับบุคคลจนถึงองค์กรด้วย

Manoj: agile ดังมาได้ซักพักละ ตอนนี้แพร่กระจายไปทั่ว ทั้งในองค์กรระดับเล็ก, ระดับใหญ่, องค์กรข้ามชาติ, ฯลฯ agile มีอะไรใหม่? แล้ว agile กำลังเติบโตไปทิศทางไหน?

(more…)

รอยแยกของโลกของ Architects กับ Agilists

เก็บมาฝากครับ เมื่อวันศุกร์ที่ผ่านมา (23 เมษายน) ตอนเที่ยงคืนถึงตีหนึ่งผมได้เข้าฟัง Webinar ของ Software Engineering Institute (SEI) เรื่อง Agile Development & Software Architecture – Crossing the Great Divide

ถ้าท่านติดตามทุกๆ blog ใน Agile66 จะเห็นประเด็นโต้แย้งระหว่าง architect กับ agilist ว่า software architecture เราควรจะ design มัน หรือเราควรจะปล่อยให้มัน evolve ของมันเอง (ผ่านการ refactor ซ้ำแล้วซ้ำเล่า)? ถ้าจะ design ก่อน เมื่อไหร่ถึงจะเรียกว่า over design? ถ้าไม่ design ก่อน ผลที่ตามมาจะเป็นอย่างไร? (more…)

Plugin from the creators of Brindes :: More at Plulz Wordpress Plugins