Минулої п’ятниці мені вдалося побувати на конференції присвяченій підходу керування - Скрам (SCRUM) яка є одним із під напрямків Аджайлу (Agile). Я викладу кілька моїх думок з цього приводу.

Що таке «Скрам» і з чим його їдять? Покопайте і-нет він знає (; Як мінімум офіційний звіт (лінк самого низу). Коротко, на відмінну класичного «водоспадного» (посходинкового) підходу розробки – розробка архітектури, планування, кодування, тестування, делівері. Являє собою розробку малими циклами (14 – 30 днів, у деяких «кроликів» 7), кожен з яких закінчується делівері. Замовник представлений однією особою – Product Owner (PO) щоб не було конфлікту вимог, команда - спільнотою зі спільною відповідальністю (без прожект менеджера) – яку координує скрам-майстер (виконує функції координатора і не має права командувати і давити авторитетом). РО представляє «список побажань» заповнений по пріоритетності, команда має право «порадного» голосу – що робити першим (аля, ми не можемо розширити функціонал так як вимога його написати стоїть нижче). Детальніше читайте на спец сайтах.  

Сліпе слідування будь-якій методиці нідочого хорошого не приводить, так як ідеальних вихідних умов не буває. Отож розіб’ємо огляд на два «шару» ( замовника і команди розробки ).

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

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

Якщо клієнт хоче почути кінцевий термін і скільки це коштуватиме – «Скрам» тут більш зашкодить. Повного і кінцевого естімейту на початку розробки не передбачено.

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

Зате методика звітування на висоті. Схема нижче (вибачайте хлопці, малюнки скомунізджені з офіційного звіту):

Можна це оформити у вигляді дошки з наліпками

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

Кожен день варто розпочинати з трьох запитань до себе:

1 Що я за вчора зробив?

2 Що я планую сьогодні зробити?

3 Які я маю проблеми? (доповідачі мали на увазі «не робочі» (а-ля сервак лежить), та думаю робочі також підуть, щоб обмізкувати кого можна покопати в цьому напрямку…).

Чітке визначення цілей значно активізує, особливо коли бачиш, що вони не досягаються (власний досвід)…

Також, гарно складаються вимоги до проекту (а–ля список що зробити – to-do list) шаблон такий - As a <user> I can <do> so that <value>. Гарно? Без двозначностей! Та спробуйте увіпхнути сюди, вимогу базового функціоналу чи ще якусь «розмиту» вимогу. Не вийде, роботи у «складачів вимог» добавиться, та це на краще! Проблеми з різним трактуванням зникнуть (мрії, при бажанні все можна трактувати двозначно, наприклад у <value> вставити шмат тексту «подібно до …» ): ).

______________________________________________

Даний зріз не претендує на повноту і не ставить собі за ціль розкрити моє бачення «Скраму», а лише описує риси які мені найбільш запам’ятались і їх можна використовувати у «реальному житті» і байдуже яким словом це буде називатись. http://www.agileukraine.org/2008/02/scrum-training-lviv-report.html