1. Аgile Төслийн Менежмент бол
Коммуникаци, Энгийн байдал,
Буцах холбоо, Зоригтой байдал
Agile Project
Management
PM304 Төслийн
менежмент
Г.Сайнзаяа PT08D071

2. Агуулга
1. Оршил
2. Аgile Төслийн Менежментийн танилцуулга
I. Agile Төслийн Менежмент
II. Түүх
III. АРМ-ийн 13 зарчим
IV. Agile арга зүйнүүд
V. Аgile Менежментийн ерөнхий бүтцүүд
3. SCRUM
I. SCRUM-ын тухай
II. SCRUM-ын үе шат
4. АРМ-ийн ерөнхий бүтэц
I. Үндсэн зарчим
II. CAS-д суурилсан Төслийн менежментийн бүтэц
5. Дүгнэлт
6. Ашигласан материал
1

3. Оршил
Программ хангамжийг хөгжүүлэх уламжлалт аргууд одоо үед ашиглахад
хэрэгцээг хангаж чадахгүй байна. Уламжлалт арга нь нэгэн төрлийн барилга
барихтай төстэй, байшинг барих хамгийн жижиг хэсэг хүртэлх бүх зүйлийг хэн
нэгэн төлөвлөх шаардлагатай байдаг. Энэ арга урьд нь болдог байсан байж
магадгүй юм, одоо ч зарим байгууллагуудад ашиглаж болдог байх. Гэхдээ л илүү
зардал, төвөгтэй байдлыг үүсгэдэг нь гарцаагүй. Одоо хүртэл энэ аргыг ашигладаг
нэгэн шалтгаан нь “аюулгүй байдал”. Аюулгүй мэт “санагдуулдаг”. Энэ бүх
төлөвлөгөө, үнэлэлт, хэмжилтүүд нь тэгэж санагдуулдаг байх. Нэгэн судалгааны
дүнгээр бүх программ хангамж хөгжүүлэх төслүүдийн 18 хувь нь амжилттай, 31
хувь нь бүтэлгүйтсэн, 53 хувь нь хэрэгжихэд түвэгтэй байгаа гэж дүн гарчээ.
Менежерүүд төслийг хянахын тулд уламжлалт аргуудыг хичээнгүйлэн мөрдөж
байхад, техникийн хэсгийнхэн эцсийн бүтээгдэхүүнд нь хүчтэй нөлөөлж байгаа
уламжлалт аргаас гарахыг хүсэн agile аргыг бий болгосон байна. Agile аргаар бол
менежерийн нөлөө эрс багасах байсан тул хэрэгжүүлэлт маш удаан байлаа.
Ямар арга хэрэглэх нь хамаагүй, уламжлалт төслийн менежер бол шаардлагатай
нөөц, үүрэг даалгаврууд, хараат байдлыг тусгасан мастер төлөвлөгөөг хөгжүүлж,
хянадаг хүн юм. Дараа нь үүрэг даалгавруудын биелэлтийг үнэлэн, төлөвлөгөөг
засдаг. Тиймээс agile арга нь уламжлалт менежерүүдийг цочроож болох юм.
Гэхдээ тэгэх шаардлага байхгүй. Үнэндээ бол зөвхөн agile ч биш, сүүлийн үеийн
төслийн менежментийн хандлагууд удирдлагын болон техникийн багийнхны
хоорондох ойлголцол, харилцааг чухалчлах болсон юм.
2

4. Аgile Төслийн Менежментийн танилцуулга
Шилдэг төслийн менежерүүд зөвхөн зохион байгуулагчид биш. Тэд бизнесийн
алсын хараа, харилцааны чадвар, зөөлөн удирдах чадвар, техник сэтгэлгээ,
төлөвлөж, зохион байгуулж, гүйцэтгэх чадваруудыг багтаасан байдаг. Яг үнэндээ
тэд зөвхөн менежерүүд биш, харин манлайлагчид юм. Хэдийгээр үргэлж ийм
байсаар ирсэн боловч АРМ манлайлах чадварыг юунаас ч өндөр тавьсан юм.
Дээр хэлсэнчлэн agile арга нь менежерийн оролцоог эрс багасгадаг. Одоо үүрэг
даалгавар бүрийг хэлж өгч, биелэлтийг нь хянах хүн хэрэггүй. Тэгвэл менежер
бус, харин манлайлагч хэрэг болж байгаа юм. Алсын харааг тод байлгаж, багийг
идэвхижүүлж, багийн ажиллагаа, хамтын ажиллагааг дэмжин, учрах саад
бэрхшээлийг зайлуулж чадах манлайлагч. АРМ-ийн үе шатууд бусад бүх л
төслийнхтэй адил, гэвч үе шат бүрийг хэрэгжүүлж буй арга барил нь өөр юм.
Agile Төслийн Менежмент
АРМ хэдхэн арга хэрэгсэл, үйл ажиллагаагаар тодорхойлогдохгүй. Харин
өөрчлөлтийг бий болгож, дасан зохицох; уян хатан байдал ба бүтцийг
тэнцвэржүүлэх; төслийн багаас бүтээлч сэтгэлгээ, инновацийг гаргах; мөн
байгууллагыг тогтворгүй болон тодорхойгүй байдлын үед удирдаж чадах
стратегийн чадвараар тодорхойлогдоно.
- АРМ бол Өөрчлөлтийн менежмент.
- АРМ бол хэрэглэгч баримжаат.
- Төслийн менежер бол АРМ-ийн гол дүр биш.
- АРМ бол Коммуникаци, Энгийн байдал, Буцах холбоо, Зоригтой байдал
АРМ-ийн үнэт зүйлс:
- Хүмүүс ба Харилцаа > Үйл явц ба Хэрэгсэл
- Ажиллаж буй программ хангамж > Баримт бичиг
- Өөрчлөлтөнд хариу үйлдэл үзүүэх > Төлөвлөгөөг дагах
- Хэрэглэгчидтэй хамтрах > Гэрээ хэлцэл
Түүх
Түүх ба нөлөөллүүд:
20-р зууны эхэн үе
• Walter Shewhart: Plan-Do-Study-Act, SPC
20-р зууны дунд үе
• Edward Deming: SPC, TQM
• Toyota: Toyota Production System (TPS)
3

5. • Peter Drucker: Knowledge Worker
20-р зууны сүүл үе
• Womack and Jones: Lean Thinking
• Eli Goldratt: Theory of Constraints
• Tom Gilb: Evo
• The Toyota Way
Хөгжил:
1990-ээд оны эхэн үе
• Crystal Methods
• Lean Software Development
• Dynamic Software Development Method (DSDM)
1990-ээд оны дунд үе
• Feature Driven Development (FDD)
• eXtreme Programming (XP)
• Adaptive Software Development
2001: Manifesto for Agile Software Development
• http://www.agilemanifesto.org
2005: Declaration of Interdependence
• http://www.pmdoi.org/
АРМ-ийн 13 зарчим
1. Бидний хамгийн үнэт зүйл бол хэрэглэгчдийг чанартай программ
хангамжаар эрт ба тасралтгүй хангаж, сэтгэл ханамжийг өндөр байлгах.
2. Оройтсон байсан ч хамаагүй өөрчлөгдөж буй шаардлагуудыг хүлээн авах.
Хэрэглэгчдийн хувьд өрсөлдөх давуу талаа хадгалахын тулд өөрчлөлтийг
ямагт хийх.
3. Ажиллаж буй программыг хэрэглэгчдэг тогтмол хүргэж бай. Интервал нь
богино байх тусмаа сайн.
4. Төслийн хугацаанд менежерүүд болон программистууд өдөр бүр хамт
ажиллах жстой.
5. Идэвхитэй гишүүдийг тойруулан төслөө босго. Тэдэнд шаардлагатай
орчин, дэмжлэгийг өгч, ажлаа итгэн даатгаж өг.
6. Төслийн баг доторх мэдээлэл солилцох хамгийн үр ашигтай арга бол нүүр
тулсан ярилцлага юм.
7. Өсөлтийн анхны хэмжүүр бол ажиллаж буй программ юм.
4

6. 8. Аgile үйл ажиллагаанууд тогтвортой хөгжлийг хангадаг.
9. Ивээн тэтгэгчид, хөгжүүлэгчид болон хэрэглэгчид тогтмол эргэлтэнд байх
жстой.
10. Техникийн төгс байдал, сайн загварт тогтмол анхаарлаа хандуулах нь
хурдцыг нэмэгдүүлдэг.
11. Энгийн байдал.
12. Шилдэг санаа, шаардлага, загварууд өөрийгөө удирддаг багуудаас гардаг.
13. Төслийн баг тогтмол уулзалт хийж, хэрхэн илүү үр ашигтай ажиллаж
болохыг үнэлж, хэлэлцэж байх хэрэгтэй.
Agile Арга зүйнүүд
• eXtreme Programming
Kent Beck, Ward Cunningham, Ron Jeffries
• Scrum
Ken Schwaber and Jeff Sutherland
• Crystal Methods
Alistair Cockburn
• Feature Driven Development
Jeff DeLuca
• Dynamic Systems Development Method
DSDM Consortium
Agilе Менежментийн ерөнхий бүтцүүд
• Agile Project Management
Jim Highsmith, Sanjiv Augustine
• Agile Management
David Anderson
• eXtreme Project Management
Rob Thomsett, Doug DeCarlo
5

7. SCRUM
SCRUM-ын тухай
SCRUM энгийн юм шиг боловч ажилд гүн нөлөөлөх дасан зохицох болон хурдан
шаламгай чадваруудыг олгодог. SCRUM-ын бусдаас ялгагдах онцлог нь өөрийгөө
удирддаг багууд, өдөр тутмын багуудын үнэлгээ болон төлөвлөгдсөн үйл
ажиллагаанаас зайлсхийх зэрэгт оршино. SCRUM-ын дадлууд agile-ын зарчмуудад
багтсан байдаг. Зарим гол дадлуудыг дурдвал:
• Өөрийгөө удирдаж, зохион байгуулдаг багууд
• Мөчлөг буюу төлөвлөгөө гарсан тохиолдолд гаднаас нэмэлт ажил авахгүй
• Тодорхой асуудлуудаарх өдөр тутмын босоо уулзалт
• 2-4 долоо хоногийн давталт
• Мөчлөг бүрийн төгсгөлд хувь нийлүүлэгчдэд өгөх тайлан
• Мөчлөг тус бүрт хэрэглэгч-баримжаат, дасан зохицох төлөвлөлт
SCRUM-ын үе шат
Зураг 1. SCRUM-ын үе шат
SCRUM нь бүх ажлаа өсөлттэй, давтагдах цикл маягаар явуулдаг. Үүнийг дээрх
зургаар харуулсан болно. Доод талын дугуй нь ар араасаа үргэлжлэх хөгжлийн
үйл явцын мөчлөг юм. Мөчлөг бүрийн үр дүн бол илүү сайжирсан бүтээгдэхүүн
юм. Дээд талын дугуй бол өдөр бүрийн хяналт шалгалт юм. Үүгээр багийн
6

8. гишүүд бие биенийхээ ажлын явцыг шалган, шаардлагатай өөрчлөлтүүдийг
хийдэг байна. Мөчлөг үргэлжлэх нь зайлшгүй шаардлага бөгөөд хөрөнгө
оруулалт зогстол явагдсаар байх болно.
Цикл дараах маягаар явагдана: мөчлөгийн эхэнд баг юу хийх жстойгоо хэлэлцэнэ.
Дараа нь мөчлөгийн төгсгөлд сайжруулалт, өсөлтийг авчирч чадахуудыг нь
сонгоно. Тэгээд багууд тус тусдаа мөчлөгөө гүйцэтгэхээр үлдэнэ. Мөчлөгийн
төгсгөлд багууд хийсэн сайжруулалтаа хувьцаа эзэмшигчдэд тайлагнана.
7

9. АРМ-ийн ерөнхий бүтэц
Үндсэн зарчим: Төслийн баг бол CAS (Complex Adaptive System)
Фредерик Тэйлорын “Шинжлэх ухааны менежмент” бол 20-р зуунд хөгжингүй
улсуудыг шинэ түвшинд гаргасан “ажиллах хүч”-ийг хөдөлгөх хөшүүрэг болсон.
Гэвч өнөөгийн ертөнцөд “ажиллах хүч” бус, харин мэдлэгтэй ажиллагчид
болсноор заавар-хяналт менежментийг ашиглах боломжгүй болсон. Ялангуяа
программ хангамжийн салбарт программ хангамжийг хөгжүүлэгч нь
менежерээсэ илүү үнэ цэнэтэй байх нь элбэг.
Бидний амьдралын тогтолцоог ажиглаж үзвэл иж бүрэн байдал гол үндэс нь
гэдгийг харж болно:
• Амьдрах системүүд нь иж бүрэн байдаг бөгөөд маш олон төлөөлөгчид
маш олон аргаар хоорондоо харилцаж байдаг.
• Төлөөлөгчдийн хоорондох харилцаа энгийн, суурин дүрмүүдэд
захирагдаж байдаг.
• Харилцаа холбооны баялаг байдалнь эдгээр системийг сайн дурын
өөрөө-зохион байгуулалттай байгуууллага мэт болгодог.
• Орчны нөхцөл байдлаас хамааран өөр өөр хариу үйлдэл үзүүлдэг
учраас эдгээр иж бүрэн, өөрөө-зохион байгуулаллтай системүүд нь
дасан зохицох чадвартай юм.
• Эдгээр системүүд нь динамик тэнцвэрээ олтлоо хүрээлэн буй орчинтой
харилцан үйлчлэлцэж байдаг. Тэрхүү цэг нь тасралтгүй суралцаж,
дасан зохицсон нь тасралтгүй өөрчлөлттэй тэнцвэрээ олох буюу хаосын
ирмэг гэж нэрлэгддэг.
Хэрвээ бид байгууллага болон багуудаа CAS (Иж бүрэн Дасан зохицох чадвартай
Систем) гэж харж чадвал agile аргыг хэрэгжүүлэх үндсэн суурь нь болж чадах юм.
CAS-д суурилсан төслийн менежментийн бүтэц: Agile төслийг удирдах зургаан
дадал
6 АРМ-ийн дадлаас бүрдсэн CAS-д суурилсан төслийн менежментийн ерөнхий
бүтцийг гаргасан байна.
I. Хөтлөгч алсын хараа – Төслийн алсын харааг тодорхойлж, үг болон
үйлдлүүдээр дамжуулан тасралтгүй батжуул.
Алсын хараа бол зүгээр л нэг цаасан дээр харагдах билэг тэмдэг биш, харин
тууштай шийдвэр гаргахад туслаж чадах хөтлөгч хүч болох жстой. Хүчтэй алсын
хараа нь бизнесийн үнэ цэнэ, үнэт зүйлсийн талаарх хүнд шийдвэрүүдийг даван
туулахад туслаж, гол зорилгодоо хүрэхэд нь төвлөрүүлж, зоригжуулж байх жстой.
8

10. Өдөр бүрийн шийдвэр болон
харилцаанууд нь алсын харааг
батжуулж, эерэг энергийг үүсгэх
боломжууд юм.
Урд тал:
- Бүтээгдэхүүний нэр
- Зураг
- 3-4 гол шинж чанар
Ард тал:
- Нарийвчилсан шинж
чанарууд
- Шаардлагууд
Зураг 2. Бүтээгдэхүүний алсын харааны хайрцаг
II. Багийн болон хамтын ажиллагаа – Харилцаа болон хамт олноор
дамжуулан багийн болон хамтын ажиллагааг дэмж.
Багийн гишүүдийн хоорондын сайн харилцаа төслийн менежерийн багийн
гишүүдтэй хэрхэн харьцаж байгаагаас эхэлдэг. Төслийн менежер стандартыг
тогтоож, үлгэр жишээ болдог. Багийн гишүүн тус бүрийг таньж мэдэх
шаардлагатай: юу анхаарлыг нь сааруулдаг, юу идэвхжүүлдэг гэх мэт. Нэмж
хэлэхэд, хүн бүрийг хүндэлж харьцсанаар багийн харилцааны үндсэн загварыг
гаргаж өгдөг.
Хэрэв урьд нь АРМ-ийг ашиглаж байгаагүй бол багийн гишүүд нь дасан зохицох
чадвартай, инноваторууд байвал сайн, гэхдээ цөөн тооны эсэргүүцэгчид байх нь
сайн талтай ч байж мэднэ. Онолын хувьд ХР багт мэргэжилтнүүд байдаггүй, бүх
хөгжүүлэгчид бүх хэсэгт ажилладаг. Гэвч бодит байдал дээр шинэ хэрэгсэл
туршиж үзэж байгаа бол мэргэжилтнүүд хэрэг болдог. Багийн эерэг хамтын
ажиллагааг хангахын тулд мэргэжилтнүүдийн үүргийг оновчтой тодорхойлох
хэрэгтэй.
9

11. Ажиллах орчин хамтран ажиллах боломжийг хангаж байх жстой. Нийтийн болон
хувийн орон зайг хангасан нээлттэй орон зай байх нь хамгийн тохиромжтой. Мөн
гишүүн бүрийн сигналуудыг сайн ажиглаж бай. Жишээлбэл, нэг ажилтан
чихэвчээ аван, ханиалгаж эхлэж ч магад. Энэ бол ямар нэгэн юм хэлмээр
байгаагийн жишээ юм.
III. Энгийн дүрмүүд – Багийн хөтлөгч дадлуудыг тодорхойлж, дэмж.
Багуудыг үр ашигтай ажиллахад нэмэр болох хэд хэдэн энгийн болон дасан
зохицохуйц дүрмүүдийг боловсруулах хэрэгтэй. Жишээлбэл:
Яаж хийх дүрмүүд: Үйл явцын гол шинж чанарууд
• Чөлөөтэй, мөчлөгтэй төлөвлөлт
• Burndown чарт
• Багуудыг багийн өрөөнүүдэд байрлуулсан байх
• Үндсэн баг төсөлд зориулагдсан байх
Хязгаарын дүрмүүд: Зөвшөөрөгдөх үйлдлийг тодорхойлохын тулд
• Төсөвлөлт зөвхөн гүйцэтгэгч нараар хийгдэнэ
• Эрэмбэлэлт, дарааллыг тогтоох зөвхөн бүтээгдэхүүн эзэмшигчдээр
хийгдэнэ
Үнэт зүйлсийн дүрмүүд: Ажлын боломжуудыг эрэмбэлэх
• Эрэмбэлэлт, дарааллыг тогтоох үргэлж Спринтийн төлөвлөлтийн хурлаар
шийдвэрлэгдэнэ
Цаг хугацааны дүрмүүд: Хүргэлтийн хугацааг тодорхойлж, нэг хэмнэлд оруулах
• 3 долоо хоногийн спринт
Гарцын дүрмүүд: Далд зардлуудыг багасгах
• Онцгой нөхцөлд спринтийг дахин эхлүүлэх боломжтой
IV. Нээлттэй мэдээлэл – Мэдээлэл авах боломжийг нээлттэй байлга.
АРМ-ийн багийн хувьд мэдээлэл нээлттэй байх жстой. Мэдээллийг нээлттэй
байлгахын тулд дараах аргуудыг ашиглаж болно.
• Багийн гишүүд аль болох ойр байршуул
• Мэдээллийн самбар ашигла
• Төслийн ивээн тэтгэгчидтэй хаалттай уулзалт хийхийн оронд тэднийг ажил
явагдаж буй төслийн багийн өрөөнд авчирч, нээлттэй ярилцаж болно
• Мэдээлэл солилцооны онлайн программ ашигла
• Мэдээллийн урсгал, солилцоог сайжруулахын төлд өдөр тутмын
уулзалтуудыг зохион байгуул
10

12. • Бизнесийн баг болон хөгжүүлэгчдийн багуудын хоорондох нээлттэй
мэдээлийн солилцоог бий болго
Зураг 3. Мэдээллийн самбар
V. Хөнгөн шүргэ – Наад захын шаардлагатай хяналтыг л тавь.
Уламжлалт менежментэд бүх зүйл хяналтан доор байдаг: өөрчлөлтийн хяналт,
эрсдлийн хяналт, хүний хяналт. Хяналт их байх тусам дэг журам сайн байна гэж
боддог. Гэвч тийм биш. Одоогийн тодорхойгүй, таамаглашгүй байдлаар дүүрэн
ертөнцөд бүх зүйлийг төлөвлөх боломжгүй.
Ямар ч хяналтгүй үед өөрөө-зохион байгуулах чадвар дээр үндэслэн бага зэргийн
дэг журам байдаг. Хяналтын дагуу дэг журам огцом өсч байгаад тодорхой
түвшинд хүрээд огцом буурдаг байна. Тэгтэл уламжлалт менежерүүд хяналт
байхгүй үед ямар ч дэг журамгүй, хяналт өсөхийн хирээр дэг журам шугаман
өссөөр байна гэж үздэг.
VI. Соргог байдал – Тогтмол хянаж, тохируулан зас.
Төслийн менежер ажигч, байнгын буцах холбоотой, мониторинг хийж, нөхцөл
байдалтай тохируулан өөрчлөлтүүдийг хийж байх жстой.
• Боломж бүрийг ашиглан алсын харааг баталгаажуул. Төслийн шийдвэрүүд
алсын хараатай таарч буй эсэхийг шалга.
• Багийн болон хамтын ажиллагааг дэмж.
11

13. • Энгийн дүрмүүд гарга.
• Мэдээлэл солилцооны саад бэрхшээлийг устгахын тулд няцашгүй ажилла.
12

14. Дүгнэлт
АРМ бол бүх хүмүүст, бүх төсөлд зориулсан дэлхийн шилдэг арга биш. АРМ
зөвхөн тодорхой төрлийн асуудлуудад, тодорхой байгууллагад, тодорхой сожлтой
хүмүүст, тодорхой үзэл бодолтой менежерүүдэд л зохицдог.
АРМ-ийг хэрэгжүүлэхдээ эхлээд юу гэдгийг нь сайн ойлгохгүй бол АРМ,
уламжлалт төслийн менежмент хожрын дунд яах жстойгоо мэдэхгүй төөрөх үе
бий. АРМ-д яг таг дүрэм журам гэж байхгүй. Дээрх дадлууд ч амжилтыг авчирна
гэсэн баталгаагүй. Тиймээс дээрх суурь дадал, зарчмууд дээр үндэслэн бүтээлч
байдал, уян хатан байдал, анхаарлыг нэмсэнээр өөрийн онцгой амжилтын жорыг
гаргаж авах хэрэгтэй.
Agile бол арга биш, agile бол сэтгэлгээ юм.
13

15. Ашигласан материал
1. Sanjiv Augustine. Introduction to Agile Project Management: Delivering
Customer Value with Speed, Economy & Quality. LitheSpeed. PMI Northern
Italy Chapter, 2007.
2. Jim Highsmith. Agile Project Management.
3. www.agilemanifesto.org Agile Project Management: Why do we need it?
4. Sanjiv Augustine, Bob Payne, Fred Sencindiver, Susan Woodcock. Agile project
management: steering from the edges.
5. www.ccpace.com Agile Project Management.
6. Abrachan Pudusserry. Agile Project Management Implementation Approach:
CSM, PMP, PRINCE2. Project Management Research Institute.
14