ამ სტატიაში მოგიყვები ერთ-ერთი ყველაზე მნიშვნელოვანი და ფართოდ გავრცელებული ტერმინის "Technical Debt"-ის შესახებ, ასევე წარმოშობის მიზეზებსა და მათი მართვის მიდგომებზე.
რას ნიშნავს Technical Debt Agile-ში?
Technical Debt არის კონცეფცია პროგრამული უზრუნველყოფის შემუშავებაში პროცესში, რომელიც ასახავს შედეგებს, როდესაც გუნდი პროდუქტის სწრაფად დასრულების მოტივაციით, ნაცვლად სწორი არქიტექტურული მიდგომების არჩევისა, გააზრებულად ირჩევს შედარებით "მარტივ" მიდგომას სამომავლო Refactoring-ის იმედად.
რა შედეგები მოყვება Technical Debt-ს
არაპროგნოზირებადობის გაზრდა
Technical debt-ის ერთ-ერთი მახასიათებელი არის ის, რომ იზრდება არაპროგნოზირებადი, არაწრფივი გზით, ხოლო ყოველი ახალი ველის დამატებამ შეიძლება იმოქმედოს ბიზნეს უწყვეტობაზე. რაღაც მომენტში, ტექნიკური ვალი აღწევს ერთგვარ „კრიტიკულობის მასას“, სადაც პროდუქტი ხდება უმართავი ან ქაოტური. გარდამტეხ მომენტში, პროდუქტში მცირე ცვლილებებიც კი ხდება შეუძლებელი ან/და საჭიროებს ძალიან დიდ დროს.
გაზრდილი Time to market
რაც უფრო დიდია ტექნიკური ვალი დღეს, მით უფრო ნელი იქნება გუნდი სიჩქარე ხვალ. რაც უფრო შენელდება გუნდი, მით უფრო შენელდება მომხმარებლისთვის ახალი პროდუქტის მიწოდება. ამიტომ მიუხედავად იმისა, რომ გუნდი მოკლე ვადაში ტექნიკური ვალის აღებით სწრაფად მიდის წინ, ამან შეიძლება გუნდი ძალიან მალე შეანელოს და მეტიც, დაკარგოს კონკურენტული უპირატესობა.
გაზრდილი Development-ისა და Support-ის ხარჯები ტექნიკური ვალის ზრდასთან ერთად, Development-ისა და Support-ის ხარჯები იზრდება. ის, რაც ადრე მარტივი და იაფი იყო, ახლა რთული და ძვირია. ტექნიკური ვალების მზარდი რაოდენობის არსებობისას, მცირე ცვლილებებიც კი ძალიან ძვირი ხდება.
პროდუქტის ატროფია როდესაც ტექნიკური ვალის გამოსწორების მიზნით ორგანიზაცია წყვეტს ახალი ფუნქციების დამატებას ან დეფექტების გამოსწორებას, მაშინ არსებული პროდუქტი სულ უფრო ნაკლებად მიმზიდველი ხდება პოტენციური მომხმარებლებისთვის. შედეგად, პროდუქტი იწყებს ატროფიას და უბრალოდ აღარ არის საინტერესო
რა იწვევს ტექნიკურ Technical Debt-ს?
მჭიდრო Deadline-ები და ზეწოლა ბიზნესისგან ტექნიკური ვალი, უმეტესწილად გამოწვეულია ბიზნესის ზეწოლით, რათა დაიცვან მნიშვნელოვანი Deadline-ები გუნდის წარმადობის ხელოვნრულად ზრდა მდგომარეობა, როდესაც გუნდს აქვს დასახული მიზანი, რომელიც უნდა შესრულდეს X თარიღში. გუნდი ამბობს, რომ აღნიშნულ თარიღში მოცემული მიზნის მიღწევა შეუძლებალია.
ბიზნესი არ იხევს უკან, ამიტომ გუნდი იძულებულია ხელოვნურად/უსაფუძვლოდ გაზარდოს სიჩქარე და ამ პროცესში თვალი დახუჭონ ტექნიკური ვალის დაგროვებაზე.
ტესტირების პროცესის ამოგდება
ზოგჯერ ითვლება, რომ თუ SDLC-დან ამოიღებ ტესტირების პროცესს, ამით უფრო აჩქარდები. რა თქმა უნდა ეს არის მითი. ერთის მხრივ გუნდი უნდა მუშაობდეს Built in quality მიდგომით, მაგრამ ხარისხის უზრუნველყოფის გარეშე ტექნიკური ვალი კიდევ უფრო მეტად გაიზრდება.
ახალი ტექნიკური ვალი "დაშენებულია" ძველ ვალზე
ცხადია ტექნიკური ვალი გავლენას ახდენს კოდის მაშტაბირებაზეც. შესაბამისად, ნებისმიერი ახალი არასწორი მიდგომა, რომელიც დაფუძნებულია ან/და იყენებს ძველ ტექნიკურ ვალს ემსგავსება "ბანქოს სახლს", რომელიც ნებისმიერ დროს შეიძლება ჩამოიშალოს.
როგორ უნდა მართო Technical Debt
პირველი, რაც უნდა იცოდე არის ის, რომ ტექნიკური ვალის მართვა და მასზე პასუხისმგებლობა მთლიანად Development team-ის მხარეს არის. გაგიზიარებ რამდენიმე ტექნიკას, ტექნიკური ვალის სამართავად:
იყავი გამჭვირვალე ტექნიკური ვალის მიმართ. მოახდინე ტექნიკური ვალის ვიზუალიზაცია ისე, რომ ყველას ნებისმიერ დროს შეეძლოს ამ ინფორმაციაზე წვდომა. ასევე, რეგულარულად განიხილე ტექნიკური ვალი Sprint Review ცერემონიაზე, რათა დაინტერესებულმა მხარეებმა იცოდნენ ვალის არსებობის შესახებ. ამათ გაგიმარტივდება დაინტერესებული მხარეების მოლოდინებისა და რისკებისა მართვა.
გამოიყენე საზომი ინსტრუმენტები. ეს შეიძლება იყოს DORA, SQALE, Unit Test-ებისა და ტესტირების ავტომატიზაციის დაფარვის საზომი. ამას თუ ვერ ახერხებ მინიმუმ დეფექტების რაოდენობა დათვალე.
აუცილებლად შეიტანე Sprint Backlog-ში ტექნიკური ვალის ამოცანები და გუნდის Capacity-ის 15-20% დაუთმე ასეთი ტიპის ამოცანებს.