15. პროგრამების შექმნის პროცესი (agile)

დღეს ვისაუბრებთ იმ ნაბიჯებზე, რომელიც მუშა პროგრამისთვისაა საჭირო. დამატებით, განვიხილავთ პროექტებისა და გუნდების მართვის ყველაზე წარმატებულ მოდელს - Agile და მის პრაქტიკებს. რადგან ეს საკითხი ქართულად რთულად გადმოსათარგმნი ტერმინებითაა დატვირთული, ტექსტის ნაწილი ინგლისურად იქნება. ეს არ ნიშნავს, რომ ლექცია გამოცდაზე არ შედის

Software Development Lifecycle (SDLC)

პროგრამის შესაქმნელად ეს ნაბიჯებია საჭირო:

Requirements - მოთხოვნები დამკვეთისგან

დამკვეთი შეიძლება იყოს გარე კომპანია, კომპანიის სხვა გუნდი. ნებისმიერი პირი, ვინც "უკვეთავს" პროგრამის შექმნას - შეიძლება თვითონ დეველოპერების გუნდი - ფუნქციური - ტექნიკური

დიზაინი

არქიტექტურა (მთავარი მოდულები, ფაილები და ობიექტები, მათი კავშირი ერთმანეთთან)
ინტერფეისი

Coding/Implementation

ტესტირება

ავტომატური - კოდის მეშვეობით. მაგალითად: დავალებებში როგორც გიმოწმებ, ფუნქცია მუშაობს თუ არა.
manual/ხელით - მაგალითად, რასაც სემინარზე ან პროექტზე მუშაობისას აკეთებ

Deployment/Release

კოდის "შეკვრა" პროგრამად (დაკომპაილება ან ფაილების შეკრებვა ერთ ფაილში)
სერვერზე გაშვება პროგრამის

Operation/Maintenance

bugfixes
new features
operation downtime (სერვერი გაფუჭდა, გადასატვირთია, დასამატებელია)

Waterfall

სტანდარტულად, ეს პროცესები წრფივად მიმდინარეობდა, მთლიანი პროგრამისთვის. თითოეულ ნაბიჯს რამდენიმე თვე ქონდა გამოყოფილი, დეველოპმენტს 1-2 წელი.

მთავარი პრობლემები

review/approval only at the end of each stage -
თითოეულ ნაბიჯს თვეები ჭირდება
ტესტირება დიზაინის შემდეგ

უკუკავშირზე რეაგირება რთულია/გვიანია/შეუძლებელია. ტესტირების დროს შეიძლება გამოჩნდეს ფუნდამენტური პრობლემა დიზაინში, და 1-2 წლის მუშაობა ამ არასწორ საძირკველზე იყოს დაშენებული. დამატებით, სანამ პროგრამისტები კოდის წერას დაიწყებენ, შეიძლება არქიტექტორი სხვა პროექტის დიზაინს აკეთებდეს და კითხვებზე პასუხი/დახმარება ვერ შეძლოს. ბოლოს, სატესტო კოდის დაწერა ყოველთვის მარტივი არაა, ხშირად არქიტექტორებმა და დეველოპერებმა შეიძლება ისეთი სისტემა შექმნან, რომელსაც მხოლოდ ხელით თუ დატესტავ.

Agile Principles

Defining Characteristics

Adaptive planning
Evolutionary development
Early delivery
continual improvement
responsiveness to change

Failure

Agile ტრანსფორმაციების 47% წარუმატებლად მთავრდება, მეტწილად ამ მიზეზების გამო - გუნდის წევრებს არ აქვთ საკმარისი ავტონომია (დროის განსაზღვრა, თასქების არჩევა) - გუნდის წევრები არ არიან საკმარისად ძლიერი/ღია ცვლილებისთვის - კონკრეტული პრაქტიკა გუნდს არ შეესაბამება - მთავარ პრინციპებს არ მისდევენ

Developers should thrive for:

სიმარტივე
კომუნიკაცია
უკუკავშირი
ურთიერთპატივისცემა
გამბედაობა

Other Takeaways

Fail Early, Fail Often
Recognising when something is wrong is just as important as knowing how to do something right
Build what is needed, not what was planned

Failure Is Good

if you don't embrace failure, you will not be prepared to deal when it inevitably happens

Scrum

მთავარი კომპონენტები

Product Backlog

გასაკეთებელი თასქები
დახარისხებული სხვადასხვა კატეგორიებით (labels)
თითოეულს time estimate

Sprint

1-4 კვირა

Product Owner

აკონკრეტებს პრიორიტეტულ თასქებს
არ წყვეტს ვინ რას გააკეთებს

Sprint Planning

backlog-დან უნდა აირჩეს maintenance თასქებიც (მაგ. რეფაქტორინგი, სამუშაო გარემოს გაუმჯობესება, ოპტიმიზაცია)
ყველა ირჩევს რა უნდა
სივრცე "გაუთვალისწინებელი" შემთხვევებისთვის
user story-ების ერთად გავლა (რამე დეტალი ხომ არ აკლია)

Daily Stand Up Meeting

არ არის საჭირო scheduling
ყველა ონლაინაა, თუ რამე უფრო დიდი შეხვედრის დაორგანიზებაა საჭირო, 4 საათიანი იმეილ მიმოწერის მაგივრად რამდენიმე წამში დაიგეგმება
პრობლემების/იდეების გაჟღერება/გამოვლენა, უკუკავშირი, მინი ბრეინსტორმინგი

Sprint Review

გადამოწმება, რომ ყველაფერი მუშაობს
კლიენტთან კავშირი

Retrospective

სამუშაო პროცესის ადაპტაცია
feedback