Удаан хугацааны дараа сүүлийн үед ажил дээрээ судалж хэрэгжүүлэхээр зорьсон зүйлийнхээ тухай бичихээр шийдлээ.
Миний хувьд agile-аар ажилласан туршлага тодорхой хэмжээнд бий боловч компаниудын хооронд agile гэрээ байгуулж ажилласан туршлага байхгүй учир багагүй материал уншиж судлах шаардлагатай байлаа.
Гэхдээ мэдээж өөрийн туршлага дээр үндэслэсэн санаануудаа тусгахыг хичээлээ.
Програм хангамж хөгжүүлэлтэд Agile аргачлал маш үр дүнтэй гэдэгтэй олон хүн санал нэгдэх байх.
“Яагаад agile үр дүнтэй вэ” гэж бодож байвал өмнө бичиж байсан програм хангамж хөгжүүлэх аргачлалуудын талаар бичиж байсныг минь уншаад үзээрэй.
Захиалгаар өөр компанийн системийг хөгжүүлдэг (SDAAS) бол хэрхэн agile-аар ажиллах вэ?
Ихэнхдээ компаниуд “Ажил гүйцэтгэх гэрээ” байгуулж үүндээ хийх ажлын жагсаалтаа гаргаад ажил тус бүр дээр хүн цагаа төлөвлөн гэрээний үнээ гаргадаг буюу waterfall аргачлал дээр үндэслэн гэрээгээ байгуулдаг.
Ингэснээр хөгжүүлэлтийн багийг agile-аар ажиллах боломжгүй болгоно гэсэн үг. Учир нь гэрээнд тодорхой үр дүнд, тодорхой хугацаанд, тодорхой төлбөр төлөхөөр заагдчихсан байгаа. Гэтэл Agile нь төлөвлөгөөг дагахаас илүү өөрчлөлтөд хариу үзүүлэх нь чухал шүү дээ. Урт хугацаанд хөгжүүлэлт хийгдэх явцад ажлын гүйцэтгэх хугацааг буруу тооцох, тооцоогүй алдаа асуудлууд гарах, амьдрал дээрх шаардлага өөрчлөгдөх гэх мэтээр маневр хийх шаардлагатай асуудал олон гардаг. Гэтэл мөнгө гэдэг зүйл дээр очоод гэрээгээ дагахаас өөр аргагүйд хүрнэ. Захиалагч компани гэрээг л үндэслэн төлбөрөө шилжүүлэхийг хүсэх нь зүй ёсных. Үүнээс болж өмнөх хугацаа хэтэрч алдагдал хүлээсэн хөгжүүлэлтийн зардлаа нөхөхийн тулд дараагийн жижиг ажил дээр илүү өндөр үнийн санал өгөх, захиалагчид тулгарсан өөрчлөлтийг ажлын дунд тусгахаас зайлсхийх, ажлын үр дүн болон төлбөр мөнгөө тохиролцохын тулд хугацаа алдах гээд маш олон асуудлууд гарна. Үүний үр дүнд харилцан итгэлцэл багасах ба хамгийн гол нь хоёр компанид хоёуланд нь ашиггүй нөхцөл байдлууд үүсэх билээ.
Энэ асуудлыг шийдэхийн тулд гэрээ маань ч agile гэрээ байх хэрэгтэй. Agile гэрээ байгуулснаар ажлын хугацаа болон зардлын эрсдэл болон үр дүнгээ харилцан хуваах боломжтой болж гүйцэтгэх багт ажлыг амжилттай шийдвэрлэх эрх мэдэл ирэх болно. Баг уян хатан ажиллах боломжтой болсноор үр дүн сайжрах болно.
Agile гэрээ байгуулахад дараах асуудлуудын талаар ярилцах хэрэгтэй болно. Энэ нь Agile-аар хийгдэх ажлууд бүрэн тодорхой биш учир үнээ хэрхэн тохирох вэ?
Алсын хараагаа харан ажлын төлөвлөгөөний өөрчлөлтөд шийдвэр гаргаж чиглүүлж байх Product Owner оо аль талаасаа томилох вэ?
Эхлээд төлбөрийн асуудлын талаар авч үзье.
Agile гэрээнд гурван төрлийн төлбөр шийдэх арга байгаа. Тус бүрдээ давуу сул талтай учир хийгдэх ажил, харилцагч компаниудын онцлогоос хамаарч сонгох хэрэгтэй.
- Хугацаа болон материал
Ерөнхийдөө уламжлалт загвартай төстэй боловч ажлын жагсаалтыг уян хатан болгосноор гүйцэтгэлийн хариуцлагыг хуваалцах боломжтой болно. Энэ нь гүйцэтгэгчийн хүн цаг болон ажлыг гүйцэтгэх үед гарсан бусад материалын зардлыг төлөх юм. Хийгдэх ажлыг захиалагч хүссэнээрээ өөрчилж байх боломж бүрдэхээс гадна зардлаа тодорхой хэмжээнд урьдчилан төсөвлөх боломжтой.
Гүйцэтгэгч захиалагчид зарцуулалтын тайлангаа дэлгэрэнгүй тайлагнаж байх хэрэгтэй болно.
Товчхондоо гүйцэтгэгчийн ажиллах хүч ур чадварыг захиалагч тал түрээслэн ажиллуулж байгаа гэсэн үг.
Ажлын шаардлага өөрчлөгдөх магадлал их бөгөөд захиалагч нь гүйцэтгэгчийн ур чадвар болон найдвартай байдалд итгэдэг ба хяналт тавих боломжтой үед энэ төрлийг сонгох хэрэгтэй.
2. Тогтсон зардал
Захиалагч бүтээгдэхүүний зорилт хүрэх үр дүнгээ гарган талууд түүнд хүрэх өртгөө тодорхойлж, түүндээ үндэслэн гэрээ байгуулна. Энд тодорхойлсон өртөг нь аль аль талууд хүлээн зөвшөөрөхүйц бодитой байх хэрэгтэй. Үүний зорилго нь аль болох бага зардлаар хүссэн үр дүндээ хүрэхэд оршино. Үүний тулд талууд эрсдээ адил хуваах хэрэгтэй. Хэрэв бага зардлаар буюу хугацаанаас өмнө үр дүндээ хүрчихвэл үүнээс гарах зардлын хэмнэлтийг талууд хуваан хүртэнэ. Харин тогтсон зардлаас илүү зардал гарахаар бол мөн л нэмэлт зардлыг хоёр тал хувааж даахаар тусгана. Энэ нь бага зардлаар илүү үр дүн бүтээх санхүүгийн хөшүүрэг болох юм.
Хэрэв анх гаргасан өртөг хэт бодитой биш байвал гэрээ амжилгүй болох эрсдэлтэй юм.
Гүйцэтгэгч тал зорилгыг биелүүлэхийн тулд гарах нэмэлт ажил өөрчлөлтийг нэмэлт төлбөргүй хийхээр болох учир энэ өөрчлөлтийг өөрсдөө зохицуулан шийдэх боломжтой байх хэрэгтэй.
3. Хүрэх үр дүн
Энэ төрлийн гол зорилго нь бүтээгдэхүүний чанар дээр төвлөрнө.
Энэ тохиолдолд хүрэх үр дүнгээ хэд хэдэн milestones буюу дэд зорилгуудад хуваасан байна. Дэд зорилтуудын үр дүндээ дүн шинжилгээ хийж сайжруулан өөрчлөх, үргэлжлүүлэх, эсвэл гэрээгээ зогсоох эсэхээ шийдэх боломжтой. Төлбөрийг хүрэх үр дүндээ үндэслэн тохиролцох ба хүн цаг яригдахгүй. Бүтээгдэхүүний чанар үр дүн сайжрахын хэрээр гүйцэтгэгч ахиу төлбөр авах байдлаар зохицуулах хэрэгтэй.
Эцсийн хэрэглэгчийн тоо, борлуулалтын ашиг, эсвэл зардал хэмнэсэн байдал гэдэг ч юм уу бүтээгдэхүүний чанарыг хэмжигдэхүйцээр нарийн тодорхойлох боломжтой үед энэ төрлийг сонгох хэрэгтэй.
Product Owner сонгох тухайд
Бүтээгдэхүүний үндсэн зорилгод хүрэхийн тулд хийгдэх ажил, төлөвлөгөөнд өөрчлөлт орох боломжтой болох учир энэ шийдвэрийг гаргаж чиглүүлж явах Product owner нь хэн байх вэ гэдэг нь чухал юм.
Product owner-ийн үүрэг бол
- Бүтээгдэхүүний алсын харааг тодорхойлох
- Хэрэглэгчдийн түүх, хийгдэх ажлын жагсаалтыг гаргах
- Зардал, хугацаа, хийгдэх ажил зэргийг эрэмбэлэх
- Хөгжүүлэлтийн үе шатыг хянах
- Хэрэглэгчийн хэрэгцээг урьдчилан харах
- Оролцогч талууд болон багийн харилцааг холбох
- Хөгжүүлэлтийн цикл бүрд үнэлгээ хийх
Энэ үүргүүд харилцагч компанийн хүмүүст хуваагдах боломжтой учир аль талын хүнийг сонгох вэ гэдэг нь шийдвэрлэх шаардлагатай асуудал болж байгаа юм.
Жишээ нь захиалагч тал бүтээгдэхүүний алсын хараа, зах зээлээ илүү сайн тодорхойлж чиглүүлэх боломжтой байлаа гэхэд гүйцэтгэгч тал хөгжүүлэлтийн багтаа эрэмбэ зорилгоо илүү сайн тусгаж, хөгжүүлэлтийн явцаа үнэлж чадах гэдэг ч юм уу.
Мөн гэрээний төлбөрийн төрлөө аль төрлийг сонгосонтой бас уялдах болно. Хэрэв “Тогтсон зардал”-аар гэрээ байгуулж байгаа тохиолдолд нэмэлт ажил өөрчлөлтийг гүйцэтгэгч тал төлбөргүйгээр хийж гүйцэтгэх учир гүйцэтгэгч талаас Product Owner-оо сонгоно.
Доорх асуултуудад хариулан ярилцаж Product Owner-оо сонгох хэрэгтэй.
- Захиалагч болон гүйцэтгэгчийн харилцаа ямар төвшинд байгаа вэ? Хэн энэ харилцааг илүү сайжруулж чадах вэ?
- Захиалагч талаас Product Owner сонгохоор бол тэр хөгжүүлэлтийн багтай ойр ажиллах боломжтой юу?
- Баг нь Product Owner болон түүний зарчимд итгэдэг үү?
- Хэн оролцогч талуудын талаар зохих мэдлэгтэй, тэдний хэрэгцээг зөв ойлгож чадах вэ?
- Хэн зах зээлийн талаар зохих мэдлэгтэй вэ?
- Хэн хөгжүүлэлтийн багийн талаар зохих мэдлэгтэй, тэдний аргыг ойлгодог вэ?
- Гүйцэтгэл эсвэл нэвтрүүлэлтийн үед захиалагч болон хэрэглэгчийн шаардлагыг хэн тодорхойлж, эрэмбэлж чадах вэ?
- Мөн маш чухал нь Product Owner хийж байсан туршлагатай хүн байна уу?
Үнэхээр аль нэг талаас сонгох хүн олдохгүй бол үүргүүдийг нь талуудад хуваан гэрээнд нарийн зааж өгч шийдэх хэрэгтэй.
Ямар ч тохиолдолд Agile-аар ажиллаж л байгаа бол захиалагч талын оролцоо маш чухал юм. Захиалагч талыг төлөөлөх хүн заавал байх хэрэгтэй.
Proxy Product Owner гэдэг ойлголт байдаг. Талууд Product Owner-ийн үүргүүдийг хуваан гэрээнд зааж өгсөн тохиолдолд энэ ойлголт хэрэглэгдэнэ. Талуудаас сонгосон хүмүүс хамтарч Product Owner хийнэ гэсэн санаа юм.
Нэг хүн биш хоёр өөр хүн л учир санал зөрөх үл ойлголцол үүсэх, хөгжүүлэлтийн баг самгардах асуудал үүсэж болзошгүй болохоор аль болох нэг хүн сонгох нь зүйтэй ч нөхцөл байдлаас шалтгаалан энэ нь байж болохуйц шийдэл юм.
Agile нь ажлын процессыг сайжруулах үр дүнтэй арга билээ. Үүнийг хөгжүүлэхэд талуудын итгэлцэл маш чухал юм. Итгэлцэл гэдэг зүйл нээлттэй ил тод харилцааны явцад бага багаар нэмэгдсээр сайжирдаг зүйл учир байнга нээлттэй ил тод байдлыг хангах нь харилцан ашигтай, амжилттай урт удаан харилцааг бий болгоно.
Хамтын Agile соёлоо хөгжүүлэн, дундын ил тод төлөвлөлт болон харилцааны хэрэгсэл ашиглах нь үр дүнтэй.
За энэ хүртэл уншсанд баярлалаа. Энэ бичвэр маань эхэнд жишээгээр дурдагдсан шиг асуудлуудтай тулгарсан хүмүүс тус болох байхаа гэж найдаж байна.
Маш олон ном, нийтлэл, гэрээний ноорог зэргийг харьцуулан уншсан тул хамгийн чухал гэсэн ашигласан материалуудаа хуваалцъя
- “Agile Contracts Primer”
by Tom Arbogast, Craig Larman, and Bas Vodde
- “Ten Agile Contracts — Getting Beyond Fixed-Price, Fixed-Scope”
by Peter B. Stevens
- “Scrum: The Art of Doing Twice the Work in Half the Time”
by Jeff Sutherland
