1. На самому початку...
2. Научний підхід
3. Що пішло не так?
4. Ну, добре, раз все так просто ...
5. всюдисуща гнучкість
6. Кращі книги і методології, присвячені гнучкою розробці
7. Книги про цінностях і принципах гнучкою розробки
8. Книги про методологиях гнучкої розробки
9. Книги практичного значення
10. Висновок
11. Примітки
12. Ресурси для скачування

У фільмі «Принцеса-наречена» жахливий пірат Робертс підіймається по мотузці, яку перерізає Віззіні. І коли Робертс не падає, Віззіні вимовляє: «Він не впав? Неймовірне »! На що Ініго Монтойя відповідає: «Чому ти постійно говориш це слово? Мені здається, воно означає не те, що ти думаєш ».

Коли я обговорюю з людьми концепцію гнучкої розробки, я відчуваю себе як Монтойя в описаній сцені. Часом мені здається, що ми говоримо про різні речі. Це зовсім не означає, що я маю рацію, а вони ні. Це говорить лише про те, що навколо сучасного значення терміна «гнучка розробка» виникло певне нерозуміння. 1 Люди, пов'язані з програмуванням, звикли вкладати в слова той сенс, який їм самим здається правильним, особливо коли мова йде про нові технології. В якійсь мірі це виправдано: технології змінюються так швидко, що легко годі й встигнути за новими термінами і скороченнями, які з'являються майже щодня; в результаті ми чіпляємося за звичну термінологію в надії на те, що будемо скоріше праві, ніж ні.

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

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

На самому початку...

До лютого 2001 року слово "agile" ( «гнучкий») означало або «здатний рухатися зі стрімким витонченістю», або «володіє швидким, продуктивним і адаптується характером». 2 У 2001 році це слово почало набувати для програмістів більш специфічне значення. Група з сімнадцяти чоловік, які називали себе організаційними анархістами, 3 але насправді були консультантами з програмування і визнаними лідерами в розробці програмного забезпечення, зібралися в Сноуберде, штат Юта, і дали визначення гнучкої розробки програмного забезпечення. Гнучка розробка - це єдине питання, в якому вони зійшлися в думках, хоча кожен з присутніх мав свої погляди на те, як треба писати високоякісні програми.

Результатом зустрічі в Сноуберде стала угода про спільну позицію, яка була названо Маніфестом гнучкої розробки. 4 Я вже розповідав про це маніфесті, проте не зайвим буде повторити чотири основних положення, оскільки вони створюють основу розуміння передбачуваного значення Гнучкої розробки (з великої літери «Г»). Ці пункти формулюються у вигляді переваг, що віддаються одним аспектам програмування перед іншими:

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

Ось, власне, і все. Положення здаються простими і зрозумілими. І все ж це формулювання призвела до виникнення різних інтерпретацій і більшого нерозуміння, ніж в разі будь-якого іншого відомого мені терміна. Чому так сталося? Можу припустити три причини.

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

По-друге, навіть коли люди знають про іншому значенні слова «гнучкий», вони мимоволі думають про власне визначенні цього слова. Можливо, вони читали статті та книги про гнучку розробці і навіть намагалися застосувати деякі методи, які зробили б їх проекти більш «гнучкими» (згідно зі своїм власним визначенням). На жаль, людям властиво спотворювати передбачуване значення терміна «гнучкий», і це стосується навіть експертам і тим, хто деякий час брав участь в русі за гнучку розробку. Досить взяти участь в одній з конференцій, присвячених гнучкою розробці, і ви зрозумієте, що я маю на увазі. Багато хто прийшов до висновку, що гнучка розробка подібна мистецтва: «Я впізнаю її, коли бачу», і «Це дуже особисте визначення». У квітні 2006 року хтось із учасників заявив, що йому вдалося реалізувати «повномасштабну» гнучку розробку. Коли я запитав, що він має на увазі, я отримав відповідь, що це блочне тестування і постійна інтеграція. Ці підходи можна витлумачити на підтримку основних чотирьох положень гнучкої розробки, але самі по собі вони не еквівалентні їй.

Остання причина випливає з визначення основних положень. Ці положення вже не раз обговорювалися, проте багато людей, дивлячись на них, задають цілком справедливе запитання про містяться в них протиставленнях. Наприклад, «всеосяжна документація» протиставляється «працюючій програмі». Здається, що ці визначення мають на увазі протистояння цих аспектів один одному, але фактично цього немає логічного підтвердження. Так що в результаті ми маємо чотири пари цінностей, протиставлені один одному творцями Маніфесту гнучкої розробки. У цій статті я не прагну оскаржити обгрунтованість їх вибору, а просто хочу сказати, що ви не можете вважати свої процеси гнучкою розробкою, якщо не погодитеся з таким протиставленням і не надасте перевагу першій цінності над другою в кожної згаданої парі. Якщо ви вирішите, що всеосяжна документація важливіша, ніж окремі люди і взаємодії, то це означає, що вам, строго кажучи, не вистачає слів для обговорення гнучкої розробки в порівняльної манері. Це третя причина непорозуміння в розмовах про гнучку розробці. Багато з нас не згодні з цими вихідними противопоставлениями.

Научний підхід

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

Якщо прийняти за вихідний документ Маніфест гнучкої розробки, то можна ухвалити, що будь-яка організація або проект, які прагнуть впровадити гнучку розробку, повинні цінувати характеристики, згадані першими в кожному з чотирьох визначень (наприклад, «співпраця з клієнтом»), вище, ніж характеристики , згадані другими (наприклад, «обговорення умов контракту»). Якось Алістер Кокберн (Alistair Cockburn) сказав мені, що гнучка розробка - це лише одна позиція в просторі з шістнадцяти можливих положень. Вони мав на увазі, що якщо розглядати кожну пару цінностей, то ви можете віддати перевагу або НЕ віддати перевагу першу цінність другий. Це двійкове рішення, а оскільки пар чотири - виникає шістнадцять можливих комбінацій. Мені здається, це найпростіший і чіткий спосіб представлення гнучкої розробки. Він дозволяє уникнути проблем, пов'язаних зі спробою розрізнення ступенів гнучкої розробки. Спираючись на опис Кокберн, ми можемо вирішити, чи стосується організація або проект до гнучкої розробки чи ні. Якщо організація володіє цими цінностями і застосовує їх у своїй роботі, то можна вважати, що вона використовує гнучку розробку. Якщо ні - то ні.

Можна також підійти до гнучкої розробки з точки зору заперечення, пославшись на Джеффа Фоксфорті (Jeff Foxworthy). 5 Якщо ви цінуєте процеси і інструменти не менше, ніж взаємодія людей, то ви не ведете гнучку розробку. Якщо ви цінуєте всеосяжну документацію не менш, ніж працюючу програму, то ви не ведете гнучку розробку. Якщо ви цінуєте обговорення умов контракту не менше, ніж співпраця з клієнтом, то ви не ведете гнучку розробку. Якщо ви цінуєте роботу по плану не менше, ніж реакцію на зміни, то ви знову ж таки не ведете гнучку розробку.

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

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

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

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

Що пішло не так?

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

Один з них говорить: «Будуйте проекти навколо мотивованих особистостей. Дайте їм необхідне середовище і підтримку і довірте їм виконання роботи ». Як реалізувати цю раду? В першу чергу потрібно запитати, хто такі мотивовані особистості? Деякі люди прагнуть лише до матеріальної вигоди. Інші хочуть бути частиною чудової команди. Мотивовані особистості однієї команди можуть руйнівно впливати на іншу команду. Якщо ваш кадровий резерв заздалегідь відібраний вашою організацією, є ймовірність, що вам не вдасться вибрати для своєї проектної групи таких особистостей, які вписуються в ваше визначення вмотивованості. Чи можна в такій ситуації реалізувати гнучку розробку?

Інший принцип говорить: «Гнучкі процеси сприяють стійкій розробці. Спонсори, розробники і користувачі повинні вміти витримувати постійний темп як завгодно довго ». Зрозуміло, що якщо опустити планку нижче і працювати, не напружуючись, то можна протриматися як завгодно довго. Очевидно, що під цим принципом мається на увазі зовсім інше.

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

Мати інтерпретацію гнучкої розробки досить просто. Куди складніше прийти до правильної інтерпретації. Жоден віщун не зможе дати певної відповіді на питання, чи належать ваш проект або організація до гнучкої розробки. І ви будете абсолютно праві, якщо запитаєте: «Ну і що»? Якщо ви ефективно створюєте програми, що відповідають вимогам зацікавлених осіб, то з вами все в порядку. Ви завжди повинні прагнути до досконалості, але обов'язково відповідати ярлику? Завжди було проблематично слідувати CMM і CMMI, RUP і іншим методологій. Люди і організації зациклюються на досягненні певного рівня «сертифікації» замість того, щоб сконцентруватися на досягненні кінцевої мети, яка полягає в постачанні програмного забезпечення. Методології та практичні методи - це лише засіб, а не сама мета.

Ну, добре, раз все так просто ...

Одним з питань, заданих на конференції Agile2006 в Міннеаполісі, було питання: «Якщо гнучка розробка настільки проста, звідки взялося стільки книг, що розповідають про її досягненні»? Це було сказано ніби жартома, але в цьому питанні є і серйозна сторона. У моєму шкільному кабінеті є ціла полиця, майже повністю заповнена книгами про гнучку розробці. Їх там більше тридцяти. І ще пара десятків книг лежить у мене вдома. Це дуже багато. Звідки ж взялося стільки книг про гнучку розробці?

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

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

всюдисуща гнучкість

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

Нещодавно я заходив в книжковий магазин и купивши книгу про програмування на мові Ruby. На задній стороні обкладинки Було написано: «Ruby - це гнучкий об'єктно-орієнтована мова програмування ...». Автори розсудліво не стали писати слово «гнучкий» з Великої літери, хоча я не впевнений, что середньостатістічній читач зверне на це увагу. Чи справді Ruby підтримує цінності, описані в Маніфесті гнучкої розробки? Це питання може здатися дивним, проте логічно він таким і є. Адже там, де мова йде про маркетинг, логіка може бути не настільки важлива. Використання слова «гнучкий» для залучення уваги покупців дозволяє вам зробити перший крок в розвиток ділових відносин. (Сподіваюся, з часом у нас з'являться більш кмітливі покупці, які зададуть потрібні питання і оцінять гнучкість розробки об'єктивно.)

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

Кращі книги і методології, присвячені гнучкою розробці

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

Книги про цінностях і принципах гнучкою розробки

Гнучка розробка програмного забезпечення: кооперативна гра (Agile Software Development: the Cooperative Game), 2-е видання, Алістер Кокберн (Alistair Cockburn), Addison-Wesley Professional, 2006, ISBN 0321482751.

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

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

Гнучка і итерационная розробка програм - керівництво для менеджерів (Agile & Iterative Software Development A Manager's Guide), Крейг Ларман (Craig Larman), Addison-Wesley, 2004, ISBN 0131111558.

Крейг Ларман - видатний вчитель програмування. Особливо це стосується об'єктно-орієнтованого програмування. Він добре знайомий з різними методологіями і знає, як їх застосовувати. У цій книзі Ларман описує ітераційні методи, Scrum, XP, RUP і Evo. Scrum і XP дещо не вписуються в сектор гнучкої розробки, тоді як RUP і Evo більш традиційні (і спираються на планування). Ларман порівнює і протиставляє різні методології, щоб допомогти читачам оцінити їх переваги та вирішити, який процес найкращим чином підходить для їх проектів і організацій.

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

Баланс гнучкості і дисципліни - керівництво для збентежених (Balancing Agility and Discipline A Guide for the Perplexed ), Баррі Бем (Barry Boehm) і Річард Тернер (Richard Turner), Addison-Wesley, 2004, ISBN 0321186125.

Ця книга адресована менеджерам, які вийшли з великих організацій і проектів або володіють пристойним досвідом проектування програм (але не програмування). 7 Бем і Тернер - викладачі, що мають багатий досвід роботи з великими проектами, багато з яких належали до оборонної промисловості. Вони підходять до теми, намагаючись виявити перспективні боку - місця, які найбільше підходять для застосування тієї чи іншої методології. Бем добре відомий розробкою моделі оцінки проекту COCOMO, він написав багато конструктивних статей з проектування програм, включаючи статті, що описують итерационную розробку. 8

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

Книги про методологиях гнучкої розробки

Гнучка розробка програмного забезпечення за допомогою Scrum (Agile Software Development with Scrum), Кен Швабер (Ken Schwaber) і Майк Бідл (Mike Beedle), Prentice Hall, 2001., ISBN 0130676349.

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

Книга описує методологію Scrum словами його творців, Швабер і Бідла. Цю книгу варто прочитати хоча б для того, щоб зрозуміти, як гнучка розробка може використовуватися для управління проектами.

Екстремальне програмування: прийняття змін (Extreme Programming Explained: Embrace Change), 2-е видання, Кент Бек (Kent Beck) і Синтія Андрес (Cynthia Andres), Addison-Wesley Professional, 2004, ISBN 0321278658.

Перше видання цієї книги, ймовірно, сприяло початку просування гнучкої розробки більшою мірою, ніж що-небудь інше. Насправді деякі практики прирівнюють екстремальне програмування (XP) до гнучкої розробки. Для розробників програм XP являє собою методологію, спрямовану на вирішення проблем, з якими їм доводиться стикатися. Бек, до якого в другому виданні приєдналася Синтія Андрес, описує фундаментальні принципи, які стосуються найбільш вживаним серед розробників програм на принципах гнучкою розробки (або тим, які вважаються найбільш вживаними). Я сказав, що вони вважаються найбільш вживаними, оскільки є кілька організацій, які насправді можуть використовувати всі ці методи у своїй роботі, проте як і раніше наполягають на застосуванні XP.

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

Впровадження екстремального програмування (Extreme Programming Installed), Рон Джеффріс (Ron Jeffries), Енн Андерсон (Ann Anderson) і Чет Хендриксон (Chet Hendrickson), Addison-Wesley Professional, 2000., ISBN 0201708426.

Це другий том великої серії книг про XP, опублікованих видавництвом Addison-Wesley. Його варто прочитати, тому що він описує практичні методи застосування XP і розповідає про те, як вони використовувалися членами вихідної групи проекту XP. 9 Книга написана дуже грамотно, так що ви сповна відчуєте, що значить працювати з проектом XP. Саме ця книга переконала мене в тому, що жоден з практичних методів XP не відноситься до того типу проектів, з якими я б погодився працювати. Крім того, книга переконала мене в існуванні ряду дійсно корисних методів, з якими мені слід познайомитися. І хоча з тих пір XP пішло далеко вперед, ця чудова книга не втрачає своєї актуальності і рекомендується до прочитання будь-яка не має досвіду групі перед тим, як вирушати в першу подорож по XP.

Книги практичного значення

Розробка, заснована на тестуванні: практичне керівництво (Test Driven Development: A Practical Guide), Девід Астелс (David Astels), Prentice Hall Ptr, 2003 ISBN 0131016490.

Мені здається, що розробка, заснована на тестуванні (TDD), є одним з найважливіших методів, які дали рух гнучкою розробці. Вона акцентується на якості і покладає відповідальність за якість на розробника. Вона вимагає зосередження на якості протягом всього циклу розробки, незалежно від використовуваної методології. Ця книга є чудовим введенням в TDD. Саме вона продемонструвала мені силу простого тестування.

Практика блочного тестування в Java за допомогою JUnit (Pragmatic Unit Testing in Java with JUnit), Ендрю Хант (Andrew Hunt) і Девід Томас (David Thomas), The Pragmatic Programmers, LLC, 2003 ISBN 0974514012.

Ця книга доповнює попередню практичним радою про те, як реалізувати принципи TDD. Видавництво The Pragmatic Programmers випустило дивовижну серію книг, що розповідають програмістам про новинки технологій. Ця книга належить до їх раннім публікаціям. Книгу слід прочитати всім програмістам, які пишуть на мові Java і бажаючим досягти успіху в написанні блокових тестів. Книга розглядає блочне тестування в контексті TDD і дає читачеві всі необхідні засоби для написання, управління і автоматизації блокових тестів.

Історії користувачів (User Stories Applied), Майк Кон (Mike Cohn), Addison-Wesley Professional, 2004, ISBN 0321205685.

Схоже на те, що історії користувачів можуть стати найкращим методом розробки технічних завдань для багатьох гнучких проектів, хоча прийнятні і інші підходи, такі як сценарії використання. Історія користувача - це невеликий фрагмент функціональності, який клієнт може описати на каталожної картці. Це відповідає дуже малому ітераційного підходу, що застосовується в XP і інших методах гнучкої розробки. Подібно написання сценаріїв використання, написання історій користувачів є майстерність, з яким потрібно навчитися, і яке слід застосовувати на практиці. Майк Кон дає найкраще введення в написання історій користувачів з усіх, які я зустрічав. Його книга має таке ж значення для історій користувачів, як книга Алістера Кокберн (Alistair Cockburn) для сценаріїв іспользоанія. 10 Якщо ви працюєте зі сценаріями використання і не читали книгу Кокберн, Кон викладе вам повний курс написання і застосування історій користувачів до вашого проекту. Він наводить безліч прикладів, крізь які явно проглядає багатий досвід роботи з реальними проектами. Якщо ви аналітик і хоч трохи зацікавлені в історіях користувачів, обов'язково прочитайте цю книгу.

Планування екстремального програмування (Planning Extreme Programming), Кент Бек (Kent Beck) і Мартін Фоулер (Martin Fowler), Addison-Wesley Professional, 2000., ISBN 0210710919.

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

інше

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

Принципи, шаблони і практичні методи гнучкої розробки програм (Agile Software Development Principles, Patterns, and Practices), Роберт К. Мартін (Robert C. Martin), Prentice Hall, 2002 ISBN 0135974445.

Це книга для розробників, написана розробником розробників. Дядечко Боб Мартін - досвідчений розробник, глибоко розуміє принципи об'єктно-орієнтованого і Гнучкого програмування. У цій книзі дядечко Боб об'єднує ці поняття, демонструє розробникам силу принципів об'єктно-орієнтованої розробки та розповідає про те, як використовувати їх в проектах гнучкої розробки. Ця книга повинна бути в бібліотеці кожного розробника.

Екстремальне проектування програм: практичний підхід (Extreme Software Engineering: A Hands-On Approach), Деніел Х. Стейнберг (Daniel H. Steinberg) і Деніел У. Палмер (Daniel W. Palmer), Prentice Hall, 2003 ISBN 013 047 812.

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

Висновок

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

Раджу почати читати перераховані вище книги, а також інші книги таких авторів, як Мері Поппендік (Розробка в умовах обмеженого бюджету) (Mary Poppendieck, Lean development), Скотт Амблер (Бази даних) (Scott Ambler, Databases), Джим Хайсмит (Практичні методи управління) (Jim Highsmith, Management practices) та інших авторів, які або зробили безпосередній внесок в просування гнучкої розробки, або створили принципи і методи, добре працюють з групами і проектами гнучкої розробки. Сподіваюся, що, як і мені, вам зустрінуться книги, в яких ви знайдете ідеї, які зможете випробувати зі своїми колегами, проектами і організацією. Безсумнівно, ви зіткнетеся і з безліччю непотрібних книг - не тому, що вони погані, а тому, що вони не відповідають вашим потребам. Станьте поінформованим споживачем - і ви підвищите свою цінність для своєї організації.

Примітки

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

2 З онлайнового словника Merriam-Webster: http://www.merriam-webster.com/ .

3 Див. Історію Маніфесту гнучкої розробки: http://www.agilemanifesto.org/history.html .

4 http://www.agilemanifesto.org .

5 Джефф Фоксфорті (Jeff Foxworthy) - комік, добре відомий своїми жартами в стилі: «Якщо ви ... то ви - реднек» ( «селюк», представник сільського робітничого класу південній частині США, які традиційно вважаються простаками).

6 http://www.agilemanifesto.org/principles.html .

7 Свою думку про відмінність цих понять я висловив в грудневій статті 2005: http://www.ibm.com/developerworks/rational/library/dec05/pollice/index.html .

8 Баррі Бем (Barry Boehm), «Спіральна модель розробки і удосконалення програм» (A Spiral Model of Software Development and Enhancement), ACM SIGSOFT Software Engineering Notes, серпень 1986.

9 Цей проект, що випустив тисячу книг, називався Chrysler Comprehensive Compensation System і був запущений в 1995 році. Вважається, що в цьому проекті були застосовані, записані і перетворені в методологію, яку тепер ми називаємо XP, всі практичні методи екстремального програмування.

10 Написання ефективних сценаріїв використання (Writing Effective Use Cases),, Алістер Кокберн (Alistair Cockburn), Addison-Wesley Professional, 2000., ISBN 0201702258. Якщо ви працюєте зі сценаріями використання і не читали цієї книги, то ви багато чого втратили.

Ресурси для скачування

Схожі тими

Підпишіть мене на повідомлення до коментарів