Cyber Monday Sale 40% off unlimited courses & creative assets! 40% off unlimited assets! Save Now
Advertisement
  1. Code
  2. General

Принципи активного розвитку

by
Read Time:11 minsLanguages:

Ukrainian (українська мова) translation by Tanya Ira (you can also view the original English article)

 Гнучкою або гнучкої розробки – ми чуємо ці слова все частіше і частіше. Але ми дійсно знаємо, що це все про? Як це може допомогти нам стати більш ефективними, при цьому маючи багато веселощів розробки програмного забезпечення? Як ми можемо використовувати його, щоб спілкуватися з діловими людьми і робити це спілкування легким і конструктивним для обох сторін?


Що таке гнучка розробка?

 Там була купа дуже талановиті і досвідчені хлопці розробляють серйозні програми.  Ці розробники спостерігається інших компаній і команд розробників, і як процеси полегшувало їх роботу. Вони склали свої спостереження для створення Agile-маніфест. І вони сказали:

Ми відкриваємо кращі способи розробки ПО, робити це і допомагати іншим робити це. Завдяки цій роботі ми прийшли до значення:

  • Індивіди і взаємодію, чому процеси та інструменти
  • Робоча програма всебічної документації
  •  Взаємодія з клієнтами по веденню переговорів про укладення контракту
  •  Реагування на зміну протягом наступних план

 Тобто, поки є сенс в предмети праворуч, ми цінуємо зліва більше.

У цій статті я представлю дванадцяти теорії і методики гнучкої розробки. Це тільки перший крок у новий світ-процес розробки програмного забезпечення.


1 - Задоволеність Клієнтів

Нашим головним пріоритетом є задоволення замовника допомогою ранньої і безперервного постачання цінного, але не повнофункціональний, програмне забезпечення. Це означає, що ми розробляємо програмне забезпечення і додавання щонайменше однієї функції на кожній ітерації.

 Давайте уявимо, що ми хочемо створити движок блогу, ми можемо зробити це, використовуючи наступну процедуру:

  1. Створити сторінку відображення блогу; доставки його клієнту
  2. Створити функцію управління користувачами і членства; здачі клієнту
  3. Додати можливість коментування та управління; доставки його клієнту
  4. Так далі і так далі...

Це простий підхід, але замовник бачить реального просування свого програмного забезпечення і дає вам негайний зворотний зв'язок на кожному додатку нової функції. Це може бути ідеальний або вимагає установки, але ви можете швидко реагувати на зміни: безпрограшна ситуація.


2 - адаптуватися до мінливих вимог

 Навіть в кінці циклу розробки, гнучкі процеси дозволяють вітаємо змін на конкурентну перевагу замовника.

 Замовник хоче, щоб проект був завершений швидко і максимально близько до дизайну, намальованого в своєму розумі, як це можливо. Це легко зробити, просто прислухаючись до їх вхідних і бути готові до змін.  Якщо ми здатні швидко реагувати на мінливі вимоги, ми, ймовірно, кращим вибором наших клієнтів ніколи не зробив. Живчик-це все про комунікації і зміни.   Ми робимо речі, як ми попросили їх, роблячи процес розробки програмного забезпечення закінчити швидше. Це досягається завдяки тому, що ми розробляємо невеликі шматочки програмне забезпечення, і зміна вимог не впливають на нас.


3 - Часто Доставляють

 Ми повинні доставити оновлення від декількох тижнів до декількох місяців; Чим коротший часовий проміжок, тим краще.

клієнти відчувають себе більш впевненими в нас і наш продукт, так як він оновлюється

 З мого досвіду, клієнти відчувають себе більш впевненими в нас і наш продукт, так як він оновлюється - що дуже важливо для наших відносин з ними.   Ще однією перевагою є зворотній зв'язок від наших клієнтів, що дозволяє нам оперативно реагувати на зміну класів, об'єктів, модулів або навіть архітектура.  Ми не будемо прокидатися після декількох днів або місяців роботи, тільки щоб побачити, що все йде в сміття. Розглянемо гіпотетичну ситуацію:

 Вас попросили створити модуль, який буде відображати деякі прості тексту контент-менеджер. Раптом змінилися вимоги і треба додати форму, необхідно відправити електронного листа на вказану адресу.   Крім того, форма повинна бути що набудовується, щоб користувач міг додавати нові поля та визначення валідаторів. Отже, ви в основному повинні забути про оригінальний простий текст вимоги. Як скоро ви хотіли б дізнатися про ці зміни?

Якщо ви працюєте над проектом з клієнтом і часто доставляють, ви будете знати про ці зміни швидше, і такі зміни, як це буде простіше для вас обох.


 4 - Постійно Працювати Разом

Це може виявитися найскладнішим принципі, щоб звикнути до, якщо ви розробляєте програмне забезпечення в старовинному стилі водоспаду.  Ви, як розроблювач, як правило, не говорять на одній мові, як вашого клієнта, але ви можете знайти способи, щоб підтримувати смислове спілкування з ними.   Один з кращих способів, на мій погляд, описати все з простої історії, яка говорить нам, розробник, для якого ця функція, відповідальності і навіщо воно потрібне взагалі.  Звичайно, це стає легшим, чим більше ми працюємо з нашим клієнтом. Ще один корисний підхід поведінки у розвитку (БДР), але це тема для іншої статті.


 5 - Створення проектів з мотивованих людей

 Дайте ви людям працювати з навколишнім середовищем і підтримку, яка їм необхідна, і, насамперед, довіряти їм, щоб зробити роботу.

 Важливо забезпечити привабливий атмосфера і всі необхідні інструменти для створення гарного програмного забезпечення. Фірми втрачають своїх кращих працівників, в основному тому, що вони дійсно не піклуються про них.   Віра в те, що розробники можуть створювати, тестувати і розгортати програмне забезпечення на сервері, використовуючи FTP-клієнт і редагування відео файли десь загубилося. Якщо ви ще не засуджені ті старі звички, ви краще зробити це зараз.

 Утримання співробітників-це лише одна з переваг, ви також можете збільшити програмного забезпечення в більш швидкому темпі. Просто подумайте про це: написання повторно використовуваного коду, автоматичних тестів та автоматизованого розгортання на будь-якому сервері (серед іншого) може позитивно вплинути на час розвитку. Ми зазвичай думаємо, що ми уповільнити проект, тому що ми повинні навчитися використовувати корисні інструменти, як Дженкінс, ГІТ, СВН, Герріт, Behat і т. д. Чесно кажучи, ми робимо, але ми можемо використовувати ці інструменти і концепції в майбутніх проектах.


6 - використовувати спілкування лицем до лиця

Це найбільш ефективний спосіб донесення інформації до наших клієнтів і командою розробників.

 Хто не отримав перевантажені та/або гнів, бачачи 6,255,384 листів у вашій поштовій скриньці, тому що ваша компанія вимагає всі розмови будуть "на папері"?  Я особисто бачив, що кілька разів в моєму житті, і я не рекомендую працювати в компанії з такими звичками. Лицем до лиця розмови, роблять спілкування легким і плавним, і дозволяє нам дати більше інформації.  Ми можемо використовувати вербальні і невербальні способи спілкування, щоб показати нашій команді, що ми думаємо. Це явно швидше, ніж надсилати одне одному повідомлення.

 Але насамперед ми повинні довіряти один одному; довіра легко, накопиченого в середовищі, яка заохочує до спілкування лицем до лиця.


 7 - вимірювання прогресу в роботі програмного забезпечення

 Це одне з моїх улюблених правил; це дозволить нам вільно працювати згідно з нашим власним процесів. Розробники програмного забезпечення відрізняється від інших співробітників, тому, природно, вони повинні розглядатися як такі.  З мого особистого досвіду, я навчився не судити кого-небудь з команди розробників поки робота не буде зроблена.  Розробники не хочуть створювати шкідливе програмне забезпечення, і вони мають менше шансів зробити це, якщо ми дозволимо їм працювати у відповідності із власними уподобаннями.  Зрештою, клієнт щасливий, коли роботу вони доручили це зробити правильно; вони не дбають, як це було зроблено.


 8 - підтримувати постійний темп

 Гнучкі процеси сприяють сталому розвитку, забезпечуючи постійне темп збережеться на невизначений термін.

 Живчик найбільш відомі переваги (наприклад, прийняття мінливі вимоги, швидко реакція до зворотного зв'язку і т. д.) широко вітається, але найголовніша перевага, на мій погляд, є можливість точно визначити час, протягом якого проект або об'єкт буде споживати.   Через декілька поставок, команда розробників буде виробляти найбільш цінні бізнес: ємність. Потужність-це кількість роботи команда може зробити за одну ітерацію. Номерний ємності є стабільною після кількох ітерацій, ми можемо не смішні терміни і час оцінки, які "витягли з капелюха", представивши пропозиція нашої компанії до клієнта.

Багато людей кажуть, що це неможливо і запланувавши виявляється більш точною. Я не згоден; графік передбачає, що не буде ніякої помилки або неминучі затримки.

Це ідеальний план для ідеальною командою, і що не існує.


 9 - зверніть увагу на промисловий прогрес

Постійну увагу до нашої галузі підвищує маневреність.

 Ми повинні розвиватися і прогресувати. Ми повинні продовжувати вчитися кожен день, тому що індустрія рухається в такому швидкому темпі.  Як апаратне і програмне забезпечення стає краще, ми повинні тримати вгору-до-дата; в іншому випадку, ми опинимося втрачається в "море Нью" і буде важко повернутися на правильний шлях.

 Рефакторинг-це рішення більшості проблем. Постійно рефакторінгу (коли це необхідно), ми можемо легко застосовувати нові прийоми і поліпшити нашу архітектуру програмного забезпечення.


 10 - простота має важливе значення

 Білл Гейтс сказав:

 Якщо у мене якісь складні роботи, я віддам його ледачий я, тому що вони знайдуть найпростіший спосіб зробити це.

Простота-це золоте правило. Це не означає, що ви повинні бути ледачим, але це не означає, що розробники ускладнюють свою роботу більшу частину часу.   Якщо ви тільки зробити роботу клієнт хоче, без будь-яких додаткових функцій і поліпшень, робоча навантаження буде світліше, і ви будете досягнення ваших цілей. У кінцевому рахунку, це все, що хвилює клієнтів.


11 - Самоорганізації

 Найкращі архітектури, вимоги і проекти, виходити з самоорганізуються команд.

Ми тільки люди, ми не можемо передбачити все.

 Ви коли-небудь були в ситуації, коли ви розробили великі і трудомісткі програми, і провівши незліченні годинник в передній частині екрана, писати тисячі рядків коду і читання статей, підручників і книжок, ти сів, дивлячись на деякі погані (але робочий) код подумав: "Тепер я знаю, як це краще написати"? Я думаю, у нас у всіх були ці моменти.

 Це де одинадцяте правило приходить. У нас є команда розробників, які можуть слідувати принципам тестування розробки через тестування (TDD), де рефакторінгу-це частина процесу.  Якимось магічним чином, наше програмне забезпечення є корисним, красивим, добре написано, перевірено і швидко. Ми тільки люди, ми не можемо передбачити все.

Це все йде від Ідея самоорганізується команди, де кожен учасник має свою роль - не дали або змусили - але одна з них, яка виникла після деякого часу спільної роботи. В цьому і принадність командної роботи.


12 - відображають і регулюють

Через регулярні проміжки часу, ваша команда розробників повинен задуматися про те, як стати більш ефективним і скоригувати свою поведінку відповідно.

 Це може зажадати кілька циклів розвитку, але команда буде працювати в повній гармонії. Навіть при додаванні нових людей в цій команді не було б шкідливо.   Динамічній команді розвитку Все про отримання роботу. Якщо вони працюють в дружній обстановці, вони знайдуть "мелодія праці" і ви побачите, як швидко розробка програмного забезпечення може бути.


Кілька Гнучких Методологій Розробки

 Є кілька методологій з урахуванням і будується на принципах гнучкою. Я не буду описувати їх всі, тому що кожна методика може бути покрита у своїй статті. Я, однак, розповісти про деяких найбільш відомих agile підходів.  Одна річ, щоб пам'ятати, що немає однієї методики, щоб управляти ними всіма. Виберете той, який відповідає вашим потребам, і навіть "налаштувати" його під свої конкретні вимоги.

Скрам

 Створені Кен Швабер та Джефф Сазерленд, Scrum-це бізнес-орієнтована платформа для управління процесами розробки програмного забезпечення. Є багато різних типів методології Scrum; просто пам'ятайте, що головна мета-працювати ефективно та якісно і не дотримуватися правил.

Екстремальне програмування (ХР)

 Створені Кент повернувся, XP-це список з найкращих практик, що розробники повинні дотримуватися при створенні програмного забезпечення.  Це часто називають "розширенням скрама". Ця методика орієнтована на розвиток норм народився, через сутички, а бізнес-орієнтований.

 Ощадлива Розробка Програмного Забезпечення

 Два з основних принципів бережливого є: DALAP (як можна пізніше визначитися) і DAFAP (доставити якомога швидше). Я особисто рекомендую почитати докладніше про цю методологію, як це може бути дуже корисно.

 Є ще методики в Agile сім'ї; я просто посилатися на найпопулярніші варіанти. Якщо ви вирішите використовувати Agile в процесі розробки, ви повинні знати, що ці методології, для того щоб вибрати правильний для вас.


 Заключні Думки

Зробити Agile методи дійсно працюють?

Робити Agile методики дійсно працюють, і методології дійсно так чарівно, як всі говорять? Не завжди.

 Проблема я зіткнувся в компаніях, де гнучкі методи не дають результатів (або навіть гірше), було вибрано невдало методології та відсутність осуду серед своїх користувачів (представники бізнесу, команда розробників і т. д.). Ось чому, на думку цього автора, ви повинні бути впевнені, що всі беруть участь в процесі розуміє правила, і вони знають "що все це значить."

Спасибі за читання!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.