თავდაპირველად ვაპირებდი დამეწერა სტატია იმის შესახებ, თუ როგორ უნდა მოვაწყოთ სწორად და ეფექტურად Development პროცესი Agile მეთოდოლოგიების გამოყენებით. თუმცა, სტატიაზე მუშაობის დროს, გამახსენდა Agile-ის დანერგვის რამდენიმე ტიპური შეცდომა, რომლებიც თუ არ გაანადგურებენ, გარანტირებულად გააფუჭებენ შედეგს. ამიტომ, უკუპრინციპის თანახმად, გადავწყვიტე დამეწერა მათ შესახებ.
გადააქციე ფორმალობად
დავუშვათ, რომ ვიღაც ხელმძღვანელმა წაიკითხა ბევრი ლიტერატურა Agile-ზე და ახლა იწვის სურვილით გამოიყენოს ეს ცოდნა პრაქტიკაში.
დღეიდან ჩვენ ვიწყებთ მუშაობას 100% Agile-ით. ჩვენ გვექნება ყოველდღიური, შუალედური, შემაჯამებელი, რეტროსპექტული, ყოველკვირეული და ყოველთვიური სავალდებულო შეხვედრები. ყოველი დავალება უნდა იყოს 46 დამტკიცებული სტატუსიდან ერთ-ერთში, რომლებიც ითვალისწინებენ ყველა შესაძლო ვარიანტს, მათ შორის დეველოპერის ყოფნას სიგარეტის მოსაწევად.
მაგრამ ყველაფერი ასე მარტივად არ არის. თითოეულ Agile მეთოდიკას აქვს თავისი გარკვეული გამოყენების სფერო და სრულიად არ არის ფაქტი, რომ ეს მოთხოვნადი იქნება კონკრეტულ გუნდში კონკრეტულ პროექტზე.
ახალი მეთოდიკის მიღებისას მნიშვნელოვანია დავინახოთ არა მისი ფორმალური, არამედ პრაქტიკული მხარე: რა არის მისი დანიშნულება, როგორ მუშაობს და რა ეფექტებს იძლევა. გარდა ამისა, არ უნდა დაგვავიწყდეს მუდმივი ანალიზი: მუშაობს თუ არა ის კიდევ, ხომ არ საჭიროებს რაიმე ცვლილებებს, როგორ შეიძლება გავაძლიეროთ მისი დადებითი და მოვაშოროთ უარყოფითი ეფექტები?
იმედი გქონდეს, რომ ყველაფერი თავისით წავა
აი, ასეთი აზრები უჩნდებათ ხოლმე ადამიანებს, რომლებმაც დაჟინებით გადაწყვიტეს Agile-ით მუშაობა.
დასაწყისში - კი, ბატონო, ჩვენ გვაქვს Agile და ახლა კი ავშენდით
ერთი თვის შემდეგ - კიდევ ცოტა უნდა მოვიცადოთ, ახლა კი ნამდვილად ყველაფერი წავა.
ორი თვის შემდეგ - ჯანდაბას ეს Agile, ვცადეთ - არაფერი მუშაობს. ეს ყველაფერი კონსულტანტებმა მოიგონეს.
ნებისმიერ მეთოდოლოგიას ახორციელებენ ადამიანები. ნუ ელოდები, რომ Agile იმუშავებს მხოლოდ იმიტომ, რომ გადაწყვიტე მისი გამოყენება. Agile-ის მხარდაჭერაც კი მოითხოვს გარკვეულ ძალისხმევას, არაფერს ვამბობთ დანერგვაზე. გუნდის თითოეული წევრისგან, და განსაკუთრებით ხელმძღვანელებისგან, საჭიროა აქტიური მონაწილეობა პროცესების მომზადებასა და ორგანიზებაში.
გუნდის არასრული ჩართულობა პროცესში
ტიპიური სიტუაცია. გვყავს მაგარი და გამოცდილი პროგრამისტი პაატა. მას არ სცალია ამ მოდურ სისულელეებით თამაშისთვის ( Agile-ს ვგულისხმობ) - ის წერს კოდს. კოლეგებთან კომუნიკაციაც არც ისე უყვარს - მაინც ვერ გაიგებენ მისი კოდის მთელ გენიალურობას. ამიტომ პაატას არ აწუხებენ, დაე, კვლავაც იმუშაოს თავისთვის, მით უმეტეს, ის სამსახურში შუადღისას მოდის. პაატა გამოცდილი პროგრამისტია, თვითონ იცის, რა და როგორ უნდა გაკეთდეს სწორად.
თუმცა, Agile გუნდური თამაშია და როდესაც ერთი მოთამაშე არ თამაშობს წესებით, ეს აისახება მთელი გუნდის შედეგზე. საბოლოოდ, პროგრამისტ-მარტოხელას მოჩვენებითი მაღალი ინდივიდუალური ეფექტურობა შეიძლება სრულად გაბათილდეს უარყოფითი ეფექტით, რომელსაც ის ახდენს მთელ გუნდზე.
შერჩევითი გამოყენება
ზოგჯერ ხელმძღვანელებისგან შეიძლება მოისმინოთ რაღაც მსგავსი: კარგი, ძმებო, დამკვეთი ახლა ჩვენგან მოითხოვს სასწრაფო რელიზს, ამიტომ ვივიწყებთ ცოტა ხანი ყველა მეთოდოლოგიას და ვიწყებთ გაძლიერებულ კოდირებას და მერე, როცა უფრო მშვიდად გახდება, ისევ გავაგრძელებთ.
და მერე არ ხდება მშვიდად. ჯერ საჭირო ხდება სასწრაფოდ შეკეთდეს ის, რაც დაზიანდა ნაჩქარევი რელიზით, შემდეგ ის, რაც დაზიანდა ნაჩქარევი შეკეთებით, შემდეგ მიდის შეკეთების შეკეთება და ა.შ.
არასწორია ფიქრი, რომ Agile არის მეთოდოლოგია მშვიდი დეველოპმენტის პერიოდისთვის, როდესაც არის ბევრი დრო ყველანაირი არასავალდებულო აქტივობებისთვის (თუმცა, რა თქმა უნდა, მისი დანერგვა უმჯობესია სწორედ ასეთ პერიოდში). პირიქით - Agile-ის მთავარი დანიშნულებაა გახადოს დეველოპმენტი კონტროლირებადი და ეფექტური ნებისმიერ დროს, რაც განსაკუთრებით აქტუალურია რთულ პერიოდებში.
ალექსი გიჯაშვილი, AgileSchool-ის აღმასრულებელი დირექტორი;
