BA / SE

SE#3.1 პროგრამული პროდუქტების შექმნის წრფივი და იტერაციული მეთოდები (WaterFall and Agile Software Development)

Reference: Sommerville, Software Engineering, 10 ed., Chapter 3

  • Business Analyst 1: “How do I know this is Heaven?”
  • Business Analyst 2: “Well… I haven’t heard any talk about how Agile fixes everything (#)

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

დინამიურ ციფრულ სამყაროში კი თავის მხრივ მნიშვნელოვანი ხდება, პროგრამული პროდუქტების, მის საბოლოო მომხმარების რეალურ საჭიროებებთან შესაბამისობის უზრუნველყოფა (User Needs), მისი პრობლემების, მოთხოვნების, სურვილების (User Wants, Wish Lists) შესწავლით ანალიზით და მიწოდების თანმიმდევრობის დაცვით.

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

პროგრამული პროდუქტების შექმნის წრფივი და იტერაციული მეთოდები – Plan-driven და Agile system development

გეგმიური – წრფივი  (Plan-driven იგივე Water Fall) შემუშავების მეთოდოლოგია ეფუძნება, სისტემის შექმნის ინიცირების, შესრულების გეგმის შემუშავების, შესრულების, შესრულებული ამოცანის ტესტირების და დანერგვის მკაცრად განსაზღვრული ფაზების შემუშავებას, შესრულების თანმიმდევრობის ჩამოყალიბებას და განხორციელებას. ამ პროცესში, თვითეული ფაზის შედეგი და შემდეგ ფაზისთვის გადაცემის ხერხი, წინასწარ არის დაგეგმილი. მომდევნო ფაზა ვერ დაიწყება (იშვიათიგამონაკლისის გარდა) თუ არ არის დასრულებული წინა ფაზა.  ამ მეთოდით მუშაობის დროს, ძალიან რთულია განხორცილების გეგმაში ცვლილებების შეტანა, რადგან საჭიროებს მაღალი დონის მენეჯმენტის  ავტორიზაციას, რადგან ცვლილებამ შეიძლება რადიკალური გავლენა მოახდინოს, შესრულების  გეგმაზე და ორგანიზაციული რესურსების განაწილებაზე.

application1

Plan Driven მეთოდით სისტემის შემუშავება

სისტემების იტერაციული – ციკლური  მეთოდით შემუშავების დროს, ანალიზის, შესწავლის, შესრულების და დანერგვის ფაზები შესაძლებელია მიმდინარეობდეს პარალელურად.  სისტემა იშლება კომპონენტებად და კომპონენტების შესრულების თანმიმდევრობა, თანხმდება სამუშაო ჯგუფის წევრების მიერ. სისტემა იქმნება მუდმივი იტერაციებით.

IncrementalyvsAll

შესრულების გეგმაში ცვლილებების განხორციელება ადვილია, რადგან ამისთვის საკმარისია სამუშაო გუნდში შეთანხმება. იტერაციული – ციკლური მეთოდის კერძო შემთხვევას Agile მეთოდოლოგია. უნდა აღინიშნოს, რომ ყველა იტერაციული მეთოდი არაა Agile მეთოდი. მეთოდზე შეიძლება ვთქვათ რომ ის არის Agile, თუ  მას მოაქვს ახალი ღირებულებები (Value) თვითეული იტერაციის/ციკლის დროს.

Image result for Agile Software Development

Image result for plan driven vs agile process

WaterFall და Agile მეთოდებს შორის შედარებითი განსხვავება

იტერაციული Agile მეთოდის მუშაობის იდეოლოგია

მნიშვნელოვანია ვიცოდეთ, რომ სისტემების შემუშავების იტერაციული Agile მეთოდი, თვითონ არ წარმოადგენს მეთოდოლოგიას. საინიატივო ჯგუფის მიერ მიღებული მანიფესტით (Agile Manifesto 2001),  იგი წარმოადგენს, პროგრამული სისტემების შექმნის იდეოლოგიას, რომელიც ეფუძნება შემდეგ ღირებულებებს:

“ჩვენ ვიღწვით პროგრამული უზრუნველყოფის შექმნის უკეთესი გზების აღმოსაჩენად, ვქმნით თავად პროგრამულ უზრუნველყოფას და ვეხმარებით ამაში სხვებს. ამ მოღვაწეობის შედეგად მივედით ღირებულებების შემდეგ სისტემამდე:

  1. პიროვნებებსა და ურთიერთქმედებებს ვამჯობინებთ პროცესებსა და ინსტრუმენტებს;
  2. მომუშავე პროგრამულ უზრუნველყოფას ვამჯობინებთ ამომწურავ დოკუმენტაციას;
  3. დამკვეთთან თანამშრომლობას ვამჯობინებთ კონტრაქტის პირობების შეთანხმებას;
  4. ცვლილებაზე რეაგირებას ვამჯობინებთ გეგმის ზედმიწევნით დაცვას.

ამიტომ, მიუხედავად იმისა, რომ ვაფასებთ მარჯვენა მხარეს მდგომ ღირებულებებს, უპირატესობას ვანიჭებთ მარცხნივ მდგომებს”. (ღირებულებების და 12 პრონციპის წყარო ქართულად)

Related image

Agile მეთოდს ეფუძნება შემდეგი მეთოდოლოგიები: Scrum, XP, Crystal, FDD, and DSDM. (მოაგვიანებით დაემატა Lean),  თვითეულ მათგანს გააჩნია უნიკალური მახასიათებლები. თუმცა გარკვეული პროექტში შესაძლებელია მოხდეს მათი კომბინირება, რასაც განსაზღვრავს  სამუშაო გუნდის წევრების გამოცდილება, კვალიფიკაცია და ორგანიზაციული შესაძლებლობები რადგან Agile მეთოდის ძირითადი მიზანია,  ბიზნესის საჭიროების (Business Need) საფუძველზე შექმნას ღირებულება ბიზნესისთვის (Business Value).

Image result for Agile Software Development

Agile მეთოდით მუშაობის დროს, სისტემის მომხმარებელი, ხანგრძლივი პერიოდის განმავლობაში, არ ელოდება სისტემაზე შექმნაზე მომუშავე გუნდის მიერ სამუშაოს სრულად დასრულებას. შესრულებული სამუშაოების ფუნქციონალის და ხარისხის შემოწმება დროის მოკლე მონკვეთებში ხდება. აღნიშნული მიდგომა ამცირებს არასწორის პროდუქტების შექნის ალბათობას, ზრდის სამუშაოების შესრულების ეფექტურობას და სისტემის შესაბამისობას ახლად გამოვლენილ გამოწვევებთან და შესაძლებლობებთან. (#1)

Scrum – Agle მეთოდოლოგიის გარემო

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

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development.0

Its focus is on “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” #1

Agil Scrum – მეთოდოლოგიით, სისტემის შექმნა წარმოებს განმეორებადი (Iterative) სერიებით, რომლებსაც ჰქვია სპრინტი (Sprint), მისი ხანგრძლივობაა 2 დან 4 კვირამდე.

Agil Scrum – მეთოდოლოგიით, სამუშაო ჯგუფში განსაზღვრულია შემდეგი როლები:

  1. Product Owner – სისტემის მფლობელი. განსაზღვრავს სისტემის ფუნქციონალს, წარმოადგენს პროდუქტის კომპონენტებს (Product Backlog) და Sprint-ებში მათი შესრულების პრიორიტეტებს და თანმიმდევრობას.
  2. Development Team – სისტემის შემქმნელების ჯგუფი –  მონაწილეობს ამოცანის შესრულების გზების შემუშავებაშ იდა პასუხსმგებელია სამუსაო ჯგუფში შეთანხმებული სამუშაოების, შეთანხმებული თანმიმდევრობით წარმართვაზე და შესრულებული პროდუქტის ხარისხზე;
  3. Scrum Master – Scrum-ის მმართველი. პასუხისმგებელია სამუშაოების შეთთანხმებული თანმიმდევრობით წარმართვის ორგანიზებაზე, ჯგუფის  შეხვედრების დაგეგმვაზე და წარმართვაზე. იგი  იცავს ჯგუფს გარე შემაფერხებელი ფაქტორებისგან (დამატებითი სამუშაო სხვა წყაროებიდან, ხანგრძლივი დროით  მიწვევა სხვადასხვა შეხვედრებზე, სხვა სახის სამუსაოებში ჩართვა …).
  1. Product Owner: The product owner provides the overall vision and direction of the product. They are responsible for defining the product backlog and perform backlog prioritization according to customer value.
  2. Scrum Master: The scrum master ensures the team’s Scrum processes are followed and the team functions well through collaboration and facilitation. They manage any impediments that may prevent the team from accomplishing work and shield the team from external interferences.
  3. The Team: The team is responsible for developing and delivering the product. They collaborate with the product owner to determine what user stories will be delivered in a sprint and commit to delivery of the user stories. #1

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

Agile Scrum-ის მიმდინარეობის დროს, ადგილი აქვს სამუშაო ჯგუფის 4 ტიპის შეხვედრას (Ceremonies):

  1. Sprint planning – სპრინტის 2 დან 4 კვირიანი გეგმა;
  2. The daily scrum (or stand‐up) – სამუსაო ჯგუფის წევრებს შორის, ყოველდღიური 15 წუთიანი შეხვედრა, განხორციელებული სამუშაოების შეფასებისთვის,  ინდენტიფიცირებული კორექტივების შეთანხმებისთვის  და ახალი შესაძლებლობების შემდეგი განხილვისთვის დაფიქსირებისთვის;
  3. Sprint reviews – სპრინტის შედეგების განხილვა სისტემის მფლობელთან, მისი შენიშვნების განხილვა და შესაძლო კორექტივების მომზადება შემდეგი სპრინტისთვის;
  4. Sprint retrospectives (lessons Learned) – სამუშაო ჯგუფის მიერ, სპრინტის შედეგების განხილვა, როგორც პროდუქტის, ასევე პროცესების მიმდინარეობის თვალსაზრისით და შესაძლო კორექტივების მომზადება შემდეგი სპრინტისთვის;

 

scrum development

Agile Scrum პროცესი

 

The product backlog – პროდუქტის კომპონენტები

პროდუქტის კომპონენტები (The product backlog), წარმოადგენს სისტემის მოთხოვნების შესახებ წარმოებული მოკვლევის და ანალიზის შედეგს, აღწერს სისტემაში არსებულ პრობლემებს, ახალ შესაძლებლობებს და მათი მიღწევის გზებს. ამ ინფორმაციაზე დაყრდნობით ხდება სისტემის მოდელირება,  სისტემის ფუნქციონირების სცენარების (Use Cases) შემუშავება და მათი დაჯგუფება სისტემის კომპონენტებად,  რის საფუძველზეც, (როგორც ზემოთ აღინიშნა) ხდება შემდეგი სპრინტების დაგეგმვა და მათი შესრულების თანმიმდევრობის შემუშავება, შემკვეთის პრიორიტეტების მიხდვით;

The product backlog is built through a combination of enterprise analysis work (identifying gaps and new capabilities required to accomplish organizational goals and defining their value to the organization) and solution assessment and validation (identifying ways in which the existing solution can be enhanced to better deliver business value).

Within a sprint, business analysis activities focus on eliciting the requirements for the sprint backlog items being worked and the acceptance criteria for those items. This approach is frequently referred to as just‐in‐time requirements elicitation; developing only what is required for the current sprint and only done to the level of detail required to enable the team to build the product and acceptance criteria. #1

საკითხავი მასალა:

  1. IIBA BABOK® Guide v3 #1, #2
  2. Agile Extension to the BABOK Guide – Agile Alliance,
  3. Waterfall, Iterative Waterfall, Scrum and Lean Software Development differences #1, #2, #3, #4,
  4. How to choose between Agile and Lean, Scrum and Kanban — which methodology is the best? #1
  5. The 5 Biggest Project Management Trends Shaping 2017,  #1
  6. Agile Project Management Methodology: 10 Reasons Why It Works #1
  7. Agile methods #1, #2
  8. Agile software development methodologies and how to apply them #1
  9. Agile Manifesto  Values and 12 Principles  (ქართულად ).

დავალება:

  1. ჩამოთვალეთ იტერაციული (Iterative / განმეორებადი) მეთოდები.
  2. როდის ვიტყვით იტერაციულ მოდელზე რომ ის არის Agile მეთოდი? რატომ?
  3. რატომ არის არაიტერაციული Waterfall მეთოდით სისტემის შემუშავების დროს, ცვლილებების განხორციელება რთული?  ამ კუთხით რა შესაძლებლობებს იძლევა Agile მეთოდოლოგიები?
  4. დაასახელეთ 3 Agile მეთოდოლოგია, აღწერეთ ისინი, და მოახდინეთ მათ განსხვავებების ანალიზი (თვითეულის დაადებითი და უარყოფითი მხარე და მათი შედარება).
  5. დაასახელეთ თქვენს მიერ დასახელებული 3 Agile მეთოდოლოგიების გამოყენების რეკომენდირებული და არა რეკომენდირებული სფეროები.
Advertisements

7 thoughts on “SE#3.1 პროგრამული პროდუქტების შექმნის წრფივი და იტერაციული მეთოდები (WaterFall and Agile Software Development)

  1. Pingback: SE#8.1 Software Testing – სისტემის ტესტირება | The Digital Times

  2. Pingback: SE#9.1 Software evolution | The Digital Times

  3. Pingback: SE#1.1 Introduction to Software Engineering | IN@TIMES

  4. Pingback: SE#4.2 საინფორმაციო სისტემის მოთხოვნების შექმნის პროცესი (Requirements Engineering process) | IN@TIMES

  5. Pingback: DT#1.1 იდეების მოდელირება (Design Thinking) | IN@TIMES

  6. Pingback: DT#1.1 შემოქმედებითი აზროვნება (Design Thinking) | IN@TIMES

  7. Pingback: DT#1.2 შემოქმედებითი აზროვნების პროცესი (Design Thinking Process) | IN@TIMES

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s